Agent 时代 CI 工具选型
本文目录 11 个章节
Agent 时代 CI 工具选型
abstract · 知识演化层 本文不是来源原文，而是基于现有 CI 实践、两轮工具调研与官方资料持续维护的当前综合。修改时保留依据、分歧、边界和重要演化原因。
当前结论
Jenkins 仍在持续维护。截至 2026-09-02，官方 weekly 版本为 2.579，LTS 为 2.568.2；它不是停止发展的旧项目，也不需要为了“Agent 时代”而被强行淘汰。
本次选型真正要解决的不是“哪套 CI 最智能”，而是：
选择一个开源、可完整自托管、能调度 Windows/macOS/Linux 原生主机、确定性执行构建，并可被 Agent 通过 API 操作的 CI 基础设施。
在这一约束下，当前决策是：
- 新建系统优先验证 Woodpecker CI：架构轻、Pipeline 描述克制、具有 OpenAPI，Windows 与 macOS 可以使用 Local backend 执行原生工具链。
- 以 Jenkins 作为成熟度基线和第二方案：异构节点、复杂工具链与长期工程实践更成熟；如果已有稳定 Jenkins，没有充分收益证据就不迁移。
- 最终选择必须经过同一真实工程的对照 PoC，不能仅凭产品理念、配置语法或“Agent-native”宣传决定。
这不是最终绑定某个产品的结论，而是当前最小风险的验证顺序。
核心原则：Agent 管不确定性，CI 管确定性
Agent 适合处理：
- 把自然语言需求转换为可审阅的 Pipeline 配置；
- 判断失败日志中哪些信息重要，分析可能原因；
- 提议修改代码、依赖或构建流程；
- 选择需要重跑的流程并调用 CI API；
- 将诊断结果和修复建议交给人或策略审批。
CI 继续负责：
- 按固定条件调度指定操作系统和工具链；
- 执行 checkout、compile、test、package、sign 和 publish；
- 产生确定的退出码、测试结果、日志、制品与哈希；
- 执行超时、并发、凭据、审批和权限策略；
- 用同一套流程验证 Agent 提出的修改。
这一分工与 软件质量是反馈系统 的认识一致：Agent 可以解释反馈并提出下一步，CI 负责生成可重复、可比较的反馈事实。
“Agent-native”首先是 Agent 与 CI 的协作方式，不要求 CI 内部把 LLM 变成每个 Pipeline 的执行节点。第一阶段不把非确定性推理放进编译、测试、签名和制品生成的关键路径。
硬约束
| 约束 | 验收方式 |
|---|---|
| 开源、完整自托管 | 控制面与执行节点都可以部署在自己的基础设施，不依赖厂商 SaaS |
| 异构原生节点 | Windows 可运行 MSBuild、Unity、Unreal；macOS 可运行 Xcode、codesign、Unity；Linux 可运行容器和常规工具链 |
| Pipeline 可审阅 | 配置进入 Git，能够 diff、review、rollback 和追溯 |
| Agent 可操作 | API 至少覆盖节点、触发、状态、取消、重试和日志；Pipeline 变更可通过 Forge API 提交 |
| 确定性 | 同一代码、配置和环境产生可复现的步骤、退出状态和制品 |
| 权限可控 | Token 最小授权，秘密不进入 Pipeline、提示词或日志，危险操作可设置人工/策略门禁 |
| 可持续维护 | 项目有稳定发布、安全更新、可接受的升级成本和恢复方案 |
Pipeline 的“机器构建”不等于必须通过 CI Server API 直接修改生产配置。更安全的默认路径是：
Agent → 修改 Pipeline-as-Code → Git diff/PR → CI 读取并执行
CI API 负责运行期操作，Forge API 负责配置变更。这样可以把 Git 作为 Agent 修改确定性基础设施的审计层。
候选方案
| 方案 | 与硬约束的匹配 | 当前定位 |
|---|---|---|
| Woodpecker CI | 开源、自托管；OpenAPI；Local backend 支持 Windows/macOS；Pipeline-as-Code | 新系统第一候选 |
| Jenkins | 开源、自托管；成熟异构节点；Remote API、Jenkinsfile、JCasC | 成熟度基线与第二方案 |
| Gitea Actions | Gitea 与 Runner 均可自托管，host runner 可运行原生工具链 | 只有同时需要自建 Git Forge 时重点评估 |
| GitLab Self-Managed + Runner | 跨平台 Runner 和 API 完整 | 能力充分但平台明显更重；仅需 CI 时性价比低 |
| GoCD | Pipeline API 设计完整，跨平台 Agent 成熟 | 架构值得参考，但维护资源和长期演进风险较高 |
| Dagger | 开源、可编程、可移植的 DAG 执行层，对 Agent 友好 | 可嵌入 CI；不单独承担异构主机调度控制面 |
| Buildkite | Windows/macOS/Linux 自托管 Agent 成熟 | 控制面是 SaaS，不满足完整本地部署的硬约束 |
GitHub Actions、GitLab Duo、Harness 等 Agentic CI/CD 能力值得观察，但云平台绑定、授权模式或系统重量使它们不成为本次自托管 CI 底座的优先答案。
第一候选：Woodpecker CI
Woodpecker 的设计原则强调 KISS，并明确认为 Pipeline 配置不应成为图灵完备语言。这个取向适合将 Pipeline 收敛为确定性的 DAG，把复杂判断留给 Pipeline 外部的 Agent。
它与需求匹配的能力包括：
- Server 负责 Webhook、解析、调度、状态、日志和 API；Agent 负责执行任务；
- Local backend 官方支持 Windows 和 macOS，可直接调用本机 PowerShell、MSBuild、Xcode、Unity 等工具；
- 官方提供 OpenAPI，覆盖 Agent、Pipeline、队列、状态、取消、重启、审批和日志等运行期资源；
- Pipeline 默认保存在仓库的
.woodpecker.yaml或.woodpecker/中，适合由 Agent 通过分支和 PR 修改； - Configuration Extension 可以在未来按受控规则生成或改写 Pipeline，但第一阶段没有必要引入。
需要正视的边界：
- Local backend 没有隔离，任务与 Woodpecker Agent 使用相同用户和文件系统，只能用于可信仓库与可信 Pipeline；Agent 进程不能以高权限用户运行。
- Local backend 当前不支持 services；依赖数据库等服务的测试需要自行管理环境，或交给 Linux 容器节点。
- 官方 API 页面标记为
dev，PoC 必须检查接口稳定性、权限粒度和升级兼容性。 - 制品存储、签名机、缓存和下载接口必须纳入实测，不能从“能运行 Pipeline”推断整条交付链已经完整。
第二方案：Jenkins
Jenkins 的优势不是概念新，而是多年积累的跨平台节点、插件生态、故障处理经验和复杂工程兼容性。现有的 Jenkins 分布式构建 与 Jenkins Pipeline 笔记记录了这一底座的实际使用经验。
如果采用 Jenkins，应主动收敛它：
Jenkins Controller
├── JCasC：控制器与插件配置可重建
├── Declarative Jenkinsfile：项目流程进入 Git
├── minimal plugin set：减少升级和供应链风险
└── Windows/macOS/Linux Nodes：执行原生工具链
Jenkins Remote Access API 可以查询对象、触发参数化构建，并借助客户端创建任务、停止构建和读取状态；但接口来自长期演化，路径和配置形态不如统一 OpenAPI 整洁。这个问题可以先由一层 Agent 工具适配解决，不足以单独构成迁移理由。
Jenkins 已出现 MCP Server 和 AI Agent 插件，说明生态正在适应 Agent 工具调用与 Agent Pipeline。但这些插件属于可选增强，不是选择 Jenkins 的核心理由，也不应让非确定性 Agent 取代编译、测试和签名门禁。
Agent 操作接口
第一版不急于建设独立服务。优先根据最终 CI 的 OpenAPI 或 Remote API，提供一个薄的 Agent Skill、MCP Server 或客户端封装：
ci.nodes.list / get
ci.pipeline.get / validate / propose_change
ci.run.start / get / cancel / retry
ci.logs.get / stream
ci.artifacts.list / download
其中 pipeline.propose_change 通过 Forge API 创建分支或 PR，而不是绕过 Git 直接改生产 Pipeline。只有出现以下真实瓶颈时，才把适配层升级为独立的 CI Control Gateway：
- 同时长期维护 Woodpecker 与 Jenkins 等多个后端；
- 不同 CI 的认证、权限和审计无法由现有 Agent 工具统一管理；
- 需要稳定的跨 CI 协议供多个 Agent 或系统共同调用。
这能保留未来替换底层 CI 的可能，同时避免在选型尚未完成时先造一套控制平台。
对照 PoC
Woodpecker 与 Jenkins 使用同一份真实工程、同一批机器和同一组验收任务：
Windows：checkout → dependency → MSBuild/Unity → test → package
macOS：checkout → dependency → Xcode/Unity → test → codesign → package
Linux：checkout → container build → test → package
Agent：修改流程 → 发起审阅 → trigger → status → stream log → cancel/retry → 获取制品
PoC 至少记录：
- 首次部署、节点接入和灾难恢复成本；
- Pipeline 配置的清晰度、复用性和审阅体验；
- API 覆盖率、认证方式、权限粒度与日志可解析性；
- Windows/macOS 原生构建、代码签名、缓存和制品管理的可靠性；
- 失败后的诊断、重试、断线恢复与节点清理；
- Agent 完成“建流程—运行—读日志—提出修复—重跑”闭环所需的额外适配代码；
- 升级、安全补丁、插件或扩展依赖和日常维护成本。
选择规则：Woodpecker 若在真实异构工程中保持可靠，且 Local backend 的信任边界可接受，则采用 Woodpecker；若 Jenkins 显著减少工具链兼容、节点管理和边缘故障成本，则保留 Jenkins。不以架构洁癖抵消已经被工程实践证明的可靠性。
边界与待验证问题
- Woodpecker 在 Windows/macOS 长任务、断线重连、工作区清理和并发调度上的实际稳定性仍需 PoC 验证。
- 两套系统对代码签名、GPU/游戏引擎许可证、超大制品和局域网缓存的支持成本尚未比较。
- API 是否能以足够细的只读、执行、取消和配置权限授权给 Agent，需要部署后验证。
- 当前维护状态和版本号具有时间性；作出部署决定前应重新检查发布记录和安全公告。
- Agent 作为 Pipeline 内部插件属于后续议题，不影响当前底层 CI 选型。
资料来源
- Jenkins weekly changelog；Jenkins LTS changelog
- Jenkins Remote Access API
- Jenkins Pipeline as Code；Jenkins Configuration as Code
- Jenkins MCP Server Plugin；Jenkins AI Agent Plugin
- Woodpecker Core ideas
- Woodpecker Local backend
- Woodpecker OpenAPI；Configuration Extension
- Woodpecker releases
- Gitea Actions Runner labels
- GitLab Runner supported platforms；GitLab Jobs API
- GoCD API；GoCD project status
- Dagger introduction
- Buildkite Pipelines architecture
演化记录
- 2026-09-02：合并两轮选型讨论，并以开源、完整自托管、异构原生节点、API 可操作和确定性执行为硬约束，将 Woodpecker CI 与 Jenkins 确定为对照 PoC 的两个候选。