---
title: "Agent 时代 CI 工具选型"
author: "Perrin Yong"
author_profile: https://www.pystone.net/profile/
published_by: "Perrin Yong"
canonical: https://www.pystone.net/notes/agent-era-ci-tool-selection/
type: note
content_role: synthesis
source_type: "synthesis"
visibility: public
id_stability: rename-stable
source_path: "10-计算机、信息技术与工程/03-软件工程与质量保障/CI-CD与质量保障/CI-CD工具链/Agent时代CI工具选型.md"
content_hash: cfa061b6078cb411dedf1d42ab9c53924f8f41b1ff71202bb0ff6bfe383e5496
knowledge_version: 224c990773de.5fa8af6e39fa
site_commit: 224c990773de166d23a886306577dd90379529ce
notes_commit: 5fa8af6e39fa3891d1b9b4832bfa6c4e0ecaaf0a
---
# Agent 时代 CI 工具选型

> **abstract · 知识演化层**
> 本文不是来源原文，而是基于现有 CI 实践、两轮工具调研与官方资料持续维护的当前综合。修改时保留依据、分歧、边界和重要演化原因。

## 当前结论

Jenkins 仍在持续维护。截至 2026-09-02，官方 weekly 版本为 2.579，LTS 为 2.568.2；它不是停止发展的旧项目，也不需要为了“Agent 时代”而被强行淘汰。

本次选型真正要解决的不是“哪套 CI 最智能”，而是：

> 选择一个开源、可完整自托管、能调度 Windows/macOS/Linux 原生主机、确定性执行构建，并可被 Agent 通过 API 操作的 CI 基础设施。

在这一约束下，当前决策是：

1. **新建系统优先验证 Woodpecker CI**：架构轻、Pipeline 描述克制、具有 OpenAPI，Windows 与 macOS 可以使用 Local backend 执行原生工具链。
2. **以 Jenkins 作为成熟度基线和第二方案**：异构节点、复杂工具链与长期工程实践更成熟；如果已有稳定 Jenkins，没有充分收益证据就不迁移。
3. **最终选择必须经过同一真实工程的对照 PoC**，不能仅凭产品理念、配置语法或“Agent-native”宣传决定。

这不是最终绑定某个产品的结论，而是当前最小风险的验证顺序。

## 核心原则：Agent 管不确定性，CI 管确定性

Agent 适合处理：

- 把自然语言需求转换为可审阅的 Pipeline 配置；
- 判断失败日志中哪些信息重要，分析可能原因；
- 提议修改代码、依赖或构建流程；
- 选择需要重跑的流程并调用 CI API；
- 将诊断结果和修复建议交给人或策略审批。

CI 继续负责：

- 按固定条件调度指定操作系统和工具链；
- 执行 checkout、compile、test、package、sign 和 publish；
- 产生确定的退出码、测试结果、日志、制品与哈希；
- 执行超时、并发、凭据、审批和权限策略；
- 用同一套流程验证 Agent 提出的修改。

这一分工与 [软件质量是反馈系统](https://www.pystone.net/notes/software-quality-as-feedback-system/) 的认识一致：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 直接修改生产配置。更安全的默认路径是：

```text
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 分布式构建](https://www.pystone.net/notes/jenkins-pipeline-distributed-builds/) 与 [Jenkins Pipeline](https://www.pystone.net/notes/jenkins-pipeline-install-basics/) 笔记记录了这一底座的实际使用经验。

如果采用 Jenkins，应主动收敛它：

```text
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 或客户端封装：

```text
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 使用同一份真实工程、同一批机器和同一组验收任务：

```text
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 至少记录：

1. 首次部署、节点接入和灾难恢复成本；
2. Pipeline 配置的清晰度、复用性和审阅体验；
3. API 覆盖率、认证方式、权限粒度与日志可解析性；
4. Windows/macOS 原生构建、代码签名、缓存和制品管理的可靠性；
5. 失败后的诊断、重试、断线恢复与节点清理；
6. Agent 完成“建流程—运行—读日志—提出修复—重跑”闭环所需的额外适配代码；
7. 升级、安全补丁、插件或扩展依赖和日常维护成本。

选择规则：Woodpecker 若在真实异构工程中保持可靠，且 Local backend 的信任边界可接受，则采用 Woodpecker；若 Jenkins 显著减少工具链兼容、节点管理和边缘故障成本，则保留 Jenkins。**不以架构洁癖抵消已经被工程实践证明的可靠性。**

## 边界与待验证问题

- Woodpecker 在 Windows/macOS 长任务、断线重连、工作区清理和并发调度上的实际稳定性仍需 PoC 验证。
- 两套系统对代码签名、GPU/游戏引擎许可证、超大制品和局域网缓存的支持成本尚未比较。
- API 是否能以足够细的只读、执行、取消和配置权限授权给 Agent，需要部署后验证。
- 当前维护状态和版本号具有时间性；作出部署决定前应重新检查发布记录和安全公告。
- Agent 作为 Pipeline 内部插件属于后续议题，不影响当前底层 CI 选型。

## 资料来源

- [Jenkins weekly changelog](https://www.jenkins.io/changelog/)；[Jenkins LTS changelog](https://www.jenkins.io/changelog-stable/)
- [Jenkins Remote Access API](https://www.jenkins.io/doc/book/using/remote-access-api/)
- [Jenkins Pipeline as Code](https://www.jenkins.io/doc/book/pipeline/pipeline-as-code/)；[Jenkins Configuration as Code](https://www.jenkins.io/projects/jcasc/)
- [Jenkins MCP Server Plugin](https://plugins.jenkins.io/mcp-server/)；[Jenkins AI Agent Plugin](https://plugins.jenkins.io/ai-agent/)
- [Woodpecker Core ideas](https://woodpecker-ci.org/docs/development/core-ideas)
- [Woodpecker Local backend](https://woodpecker-ci.org/docs/administration/configuration/backends/local)
- [Woodpecker OpenAPI](https://woodpecker-ci.org/api)；[Configuration Extension](https://woodpecker-ci.org/docs/usage/extensions/configuration-extension)
- [Woodpecker releases](https://github.com/woodpecker-ci/woodpecker/releases)
- [Gitea Actions Runner labels](https://docs.gitea.com/runner/labels/)
- [GitLab Runner supported platforms](https://docs.gitlab.com/runner/install/requirements/)；[GitLab Jobs API](https://docs.gitlab.com/api/jobs/)
- [GoCD API](https://api.gocd.org/current/)；[GoCD project status](https://www.gocd.org/2023/02/13/gocd-project-status/)
- [Dagger introduction](https://docs.dagger.io/getting-started/introduction/)
- [Buildkite Pipelines architecture](https://buildkite.com/docs/pipelines/architecture)

## 演化记录

- 2026-09-02：合并两轮选型讨论，并以开源、完整自托管、异构原生节点、API 可操作和确定性执行为硬约束，将 Woodpecker CI 与 Jenkins 确定为对照 PoC 的两个候选。