让 Agent 进入 CI/CD

Loli_Wolf

404人浏览 · 2026-05-29 00:15:00

Loli_Wolf · 2026-05-29 00:15:00 发布

AI 进入交付链路之后，问题不再是“能不能帮我修一个 CI 失败”，而是“能不能在不扩大事故半径的前提下，把修复、验证、发布、观测和回滚串成可审计的闭环”。

从公开资料看，几条线已经很清晰：

Harness 正在把 AI 放进 DevOps 平台本身。Harness AI DevOps Agent 已支持创建/编辑步骤、阶段和流水线，生成并集成 OPA Rego 策略，还能用自然语言操作 Harness GitOps 环境；Harness Agents 产品页则把 pipeline-native autonomous workers 定位为 Limited Preview；Harness Release Agent 当前更像 FME 内的发布/实验助手，而不是全自动发布决策者。
GitLab Duo Agent Platform 把 flows 放进 GitLab UI、IDE 和 CI/CD 执行环境。官方文档明确提到 UI 中的 flows 会在 CI/CD 中运行，可用于转换或修复 CI/CD pipelines，并通过 session 日志支持审计。
GitHub 的 Copilot cloud agent 主要仍是 coding agent，但它运行在 GitHub Actions 资源之上；GitHub Actions 本身的 environments、deployment protection rules、required reviewers、wait timer 和 custom protection rules，构成了 Agent 进入发布链路时可复用的治理底座。
Atlassian Rovo Dev in Bitbucket Pipelines 当前是 beta。它已经能在 Bitbucket Pipelines 中分析 commits、Jira work items、deployment data 和 failed build steps，并支持 Agentic Pipelines 配置。
Feature flag、canary、rollback、OPA/Rego、SBOM、artifact attestation 和合规审批，不应该被看成分散工具，而应该被收敛为同一套“发布决策协议”：Agent 可以建议、生成、诊断和执行低风险动作；对生产状态有不可逆影响、扩大用户影响面、改变合规边界的动作必须进入人工审批或双人复核。

本文建议的核心原则是：Agent 可以加速交付，但不能绕过发布治理；Agent 的自主级别必须由环境、风险、策略和可回滚性共同决定。

能力状态说明

分类	本文含义	写作口径
官方已发布能力	官方文档明确描述、可配置或可使用的能力	可以作为现状引用，但仍要看企业许可证、区域、版本和开关
Preview/Beta/Limited Preview	官方已公开但仍处于预览、beta、实验或受控开关阶段	只能作为趋势和试点方向，不应当写成生产默认能力
工程推断	基于多个公开能力组合后，可以合理设计出的工程模式	必须标注为推断，不能声称厂商已经完整提供
本文建议	面向企业落地的组织、流程、架构和指标建议	是方法论建议，不代表任何厂商官方承诺

为什么现在重要

过去几年，AI 在研发里的主战场是 IDE、代码补全、单元测试和 PR。进入 2026 年，真正的变化是 Agent 开始靠近交付系统：

CI/CD 是软件组织的事实控制面。谁能改 pipeline、跳过测试、重跑部署、调整流量，谁就能改变生产状态。
AI 生成代码会提高变更频率。变更更多之后，传统的人工排队审批和手工发布窗口会成为瓶颈。
交付风险不是单点质量问题，而是链路风险：依赖漏洞、镜像来源、SBOM 缺失、测试不足、flag 配错、canary 判断错误、rollback 未演练，任何一处都可能让“看似小改动”变成线上事故。
合规要求正在从文档抽查转向机器可读证据。审批记录、构建来源、artifact attestation、SBOM、策略评估结果、部署历史、回滚记录，都需要能被审计。

因此，AI 交付治理的目标不是让 Agent “自动发布生产”，而是让 Agent 在可控范围内承担重复、可验证、可回滚的工作，把人类审批留给真正需要判断责任和风险的节点。

国内外产品与实践调研

Harness：从 DevOps Agent 到 pipeline-native Agents

官方已发布能力：

Harness AI DevOps Agent 文档描述了创建和编辑 steps、stages、pipelines 的能力，并提到它可以生成和集成 OPA Rego policies，用于满足合规标准。
同一文档还描述了 GitOps Operations：Agent 可以查询 GitOps 数据，触发操作，生成 GitOps workflow 的 pipeline snippets；支持的资源包括 GitOps Agent、Application、Cluster、Repository、ApplicationSet、Events、Pod Logs、Managed Resources、Resource Tree 等。
在 GitOps 应用操作中，文档列出 list/get/create/update/sync/bulk sync/refresh/cancel operation/run resource action 等动作；对 Kubernetes 资源动作，文档列出 Deployment 的 restart/pause/resume/scale，以及 Argo Rollouts 的 promote-full、abort、retry 等。
Harness Continuous Delivery 文档把 rolling、blue-green、canary、basic 等部署策略放在同一套 CD best practices 中，并说明 Harness 支持治理策略、rollback automation、concurrency controls。
Harness Continuous Verification 会用 APM/logging 等健康源验证部署；文档说明 Verify step 可在发现异常时触发 rollback。
Harness FME steps 可以作为 pipeline steps 执行，覆盖创建/更新 feature flag、设置 targeting rules、调整 traffic allocation、kill flag、restore flag 等操作，并支持 approvals、notifications、failure strategies。
Harness Release Orchestration 的 manual activities 和 approvals 文档强调，手工活动用于审批、签核、证据收集和人工验证，审批与输入会进入 audit trail。

Preview/Beta/Limited Preview：

Harness Agents 产品页把 “Pipeline-Native AI Agents” 标为 Limited Preview。它的定位是 autonomous AI workers，运行在 Harness pipelines 内，继承 pipeline context、permissions、secrets 和 governance controls。

工程判断：

Harness 的确定性价值不在“聊天式生成 pipeline”，而在 Agent 与 pipeline execution、RBAC、secrets、OPA、feature flag、GitOps、verification、rollback、audit trail 的天然邻近性。Agent 离生产越近，越应该运行在这种已有治理语境里，而不是运行在外部脚本或个人电脑上。

GitLab：CI Fix Flow 与 Duo Agent Platform

官方已发布/公开能力：

GitLab Duo Agent Platform 文档把 agents、flows、sessions、knowledge graph 等能力放进 GitLab 生命周期。GitLab Get Started 文档明确说，flows 可以完成多步骤任务，例如从 MR 触发安全扫描、代码评审、生成测试、起草文档；也包括 UI 中用于转换或修复 CI/CD pipelines 的 flows。
Flows 文档说明，flows 可在 IDE 和 GitLab UI 中使用；UI 中的 flows 会直接运行在 GitLab CI/CD 中。
Flow execution 文档说明，当 flows 在 CI/CD 中执行时，会使用 composite identity 限制访问，创建临时 workload pipeline，并限制工具范围；默认网络访问只到 GitLab instance。
Sessions 文档和 Get Started 文档说明，agent 活动会被 session 记录，可用于调试、学习和审计。

状态边界：

GitLab Flows 文档记录了版本演进：GitLab 18.4 作为 experiment 引入，18.7 进入 beta，18.8 foundational flows generally available，custom flows 在 18.8 为 beta。企业落地时要按自己的 GitLab 版本和部署形态核对。

工程判断：

GitLab 的 CI Fix Flow 更适合作为“修复建议 + MR/patch + 重新运行验证”的模式，而不是直接在失败 pipeline 上热修生产。CI/CD pipeline 本身是可变更的高权限资产，Agent 对 .gitlab-ci.yml 的修改应当走 MR、CODEOWNERS、required approvals 和 pipeline validation。

GitHub：Copilot cloud agent 与 Actions 治理底座

官方已发布/公开能力：

GitHub Copilot cloud agent 使用 GitHub Actions minutes 和 Copilot premium requests。它的主要能力仍围绕 coding tasks：研究仓库、改代码、运行测试、提交 PR。
GitHub 支持用 .github/workflows/copilot-setup-steps.yml 定制 Copilot cloud agent 的开发环境，这意味着 Agent 的可复现环境可以被代码化。
GitHub Actions environments 提供 deployment protection rules，包括 required reviewers、wait timer、deployment branch/tag rules，并支持 GitHub Apps 驱动的 custom protection rules。第三方系统可以作为观测、变更管理、代码质量或其他配置系统，参与部署是否放行的判断。
GitHub artifact attestations 可以为构建产物提供来源和完整性声明，记录 workflow、repository、organization、environment、commit SHA、triggering event 等 provenance 信息。

工程判断：

GitHub 的交付治理重点不是让 Copilot cloud agent 自己发布，而是把 Copilot 生成的修复和 PR 纳入 Actions 的现有门禁。Agent 可以诊断 Actions 失败、生成 patch、补测试；生产部署仍应由 environments、required reviewers、attestations、branch protection 和 custom protection rules 承担边界控制。

Atlassian Rovo Dev：Agentic Pipelines 进入 Bitbucket

官方 Beta 能力：

Rovo Dev in Bitbucket Pipelines 当前明确标为 beta。官方文档说明，它可以解析 commits、Jira work items 和 deployment data，生成变更对客户影响的摘要，也可以分析 failed build steps，用自然语言解释失败原因并建议修复。
Bitbucket Agentic Pipelines 支持用 Rovo Dev 或 Claude Code 作为 agent provider，并建议为 Agentic Pipelines 创建 dedicated user account，以保持权限和归属一致。
Advanced agentic configuration 支持 rovo-config.yaml、prompt files、MCP servers，以及在 bitbucket-pipelines.yml 中覆盖配置。

工程判断：

Rovo Dev 的优势是 Atlassian graph：Jira work item、Bitbucket commit、PR、pipeline、deployment data 可以被放到同一个上下文里。风险是 agent identity 和权限归属必须清楚，否则“谁触发、谁批准、谁负责”会模糊。

OPA/Rego、SBOM、SLSA 与供应链门禁

官方/权威资料：

Open Policy Agent 是通用 policy engine，使用 Rego 对结构化输入做策略判断，可用于 Kubernetes、CI/CD、API gateway 等场景。
OPA 的 CI/CD PR check 文档给出一个典型模式：用 Rego 根据变更文件决定哪些检查必须运行，策略可测试、可复用、可审计。
CISA 2025 SBOM Minimum Elements 草案强调 SBOM 是软件组件清单，可帮助组织识别漏洞、评估风险、做出使用和部署决策，并强调机器可处理格式。
GitLab dependency scanning by SBOM 文档说明，依赖扫描会生成 CycloneDX SBOM，并扫描直接和传递依赖的已知漏洞；GitLab 也说明该能力在不同版本中经历 experiment、beta、limited availability 和 GA 的阶段。
SLSA security levels 把 build provenance 作为供应链安全的关键分层；GitHub artifact attestations 可用于建立构建来源和完整性保证。

工程判断：

Agent 不应该“口头判断”一个 release 是否合规。它最多生成候选 Rego、解释策略失败、修复配置；真正的放行应该来自可测试 policy、SBOM 扫描结果、artifact attestation、签名、环境审批和审计记录。

AI 参与发布治理的参考架构

这张图里，Agent 的合理位置有四类：

生成与修复：修复 pipeline、补测试、解释失败、生成 Rego 草案、生成 rollback plan。
汇总与建议：汇总 release notes、变更影响、SBOM 差异、canary 观测结果、审批材料。
低风险执行：重跑失败的非生产 job、创建 staging 环境、更新非生产 flag、生成 MR。
受控生产动作：在审批、策略和回滚条件满足时，执行 canary promote、abort、kill flag、rollback 等动作。

核心工程机制拆解

1. CI Fix Flow：让 Agent 修 pipeline，但不要让它绕过 pipeline

推荐链路：

CI 失败后，Agent 拉取 job log、失败测试、最近 commit、pipeline config、依赖缓存和 runner 环境信息。
Agent 做失败分类：代码错误、测试 flaky、依赖锁变更、runner 环境问题、凭证/权限问题、pipeline YAML 错误。
Agent 生成最小 patch，优先开 MR/PR，而不是直接 push 到默认分支。
重新运行 CI，并把“失败原因、修改点、验证结果、剩余风险”写入 MR/PR 评论。
对 pipeline 文件、部署脚本、权限配置、生产环境变量的修改，强制 CODEOWNERS 或平台团队审批。

可自动化的动作：

读取失败日志和测试报告。
重跑失败 job，前提是平台允许且不会触发生产副作用。
为明显的 lint、format、依赖锁、测试断言错误生成 patch。
给出 flaky test 识别和隔离建议。

必须人工审批的动作：

修改 CI/CD 权限、secrets、runner image、部署脚本。
跳过安全扫描、跳过测试、降低覆盖率门槛。
修改生产部署 job、release branch 规则、审批规则。
把失败标记为“可忽略”并继续生产发布。

2. Policy-as-Code：把“发布规则”变成 Agent 也必须服从的机器规则

Agent 很适合生成 Rego 草案，但不适合成为最终裁判。策略要经过版本管理、单元测试和审查。

典型策略输入包括：

变更范围：文件、目录、服务、接口、数据库 migration。
环境：dev、staging、prod、regulated-prod。
产物：镜像 digest、SBOM、签名、attestation、构建 workflow。
风险：漏洞等级、依赖变化、权限变化、flag 类型、用户影响比例。
运行状态：canary 指标、错误率、延迟、SLO burn rate、告警状态。

示例策略方向：

package release.gate

deny[msg] {
  input.environment == "prod"
  not input.approvals.security
  msg := "production release requires security approval"
}

deny[msg] {
  input.environment == "prod"
  input.sbom.critical_vulnerabilities > 0
  msg := "critical vulnerabilities must be remediated or waived"
}

deny[msg] {
  input.changed_files[_] == ".github/workflows/deploy.yml"
  not input.approvals.platform
  msg := "deployment workflow changes require platform approval"
}

本文建议：

Rego 由 Agent 起草，人类维护；策略库必须像代码一样 review。
CI 和 CD 使用同一套策略 bundle，避免“PR 阶段通过、部署阶段失败”的割裂。
每一次策略拒绝都要产出机器可读原因，Agent 可以据此生成修复建议。
对合规豁免建立 waiver 对象：谁批准、批准多久、影响哪些服务、到期如何复查。

3. SBOM 与 artifact attestation：发布前要知道“发的是什么、从哪里来”

在 AI 加速变更后，SBOM 和 provenance 的价值会更高，因为人类 reviewer 更难手工追踪每个依赖和构建来源。

建议把以下内容作为 release evidence：

构建产物 digest，而不是可变 tag。
CycloneDX 或 SPDX 格式 SBOM。
依赖扫描结果，包括 direct 和 transitive dependencies。
高危漏洞处置结果：修复、误报、风险接受、临时豁免。
构建 provenance 或 artifact attestation。
生成产物的 workflow、commit SHA、触发事件和环境。

Agent 可以做：

对比本次 SBOM 与上次生产版本的差异。
解释新引入依赖的风险。
根据策略失败原因生成升级依赖或替换依赖的 MR。
汇总 release evidence 给审批人。

Agent 不应做：

自行批准 critical vulnerability waiver。
自行把无 attestation 的 artifact 推到生产。
自行把可变 tag 当作生产发布依据。

4. Feature Flag：把 deploy 和 release 分离

Feature flag 是 Agent 进入发布治理的关键缓冲层。没有 flag，回滚往往意味着重新部署；有 flag，很多产品行为可以通过 targeting、traffic allocation、kill switch 快速收敛。

官方资料显示，Harness Feature Flags/FME 支持 progressive delivery，FME pipeline steps 可执行创建、更新、设置 targeting、调整 allocation、kill flag、restore flag 等动作。

本文建议的 flag 治理模型：

场景	Agent 可做	必须审批
新功能默认关闭	生成 flag 定义、SDK 接入建议、清理任务	合并代码和生产发布仍走 PR/发布审批
内部用户灰度	更新非生产或内部 segment targeting	如果内部 segment 包含真实客户数据，需要数据/合规确认
小流量 canary	根据模板生成 1%/5%/10% 流量计划	首次生产放量、跨关键客户放量
指标异常	建议 kill flag，生成影响说明	可配置为自动 kill，但必须事先经过策略批准
flag 清理	识别长期 100% 或 0% 的 stale flag，生成删除 MR	删除仍需 owner review

关键点是：flag 本身也是生产配置。Agent 修改 flag 不能绕过审计，尤其不能绕过环境权限、owner、审批和变更窗口。

5. Canary 与 rollback：先定义可恢复性，再定义自动化级别

Canary 不是“先发一点点”这么简单，而是一套以观测指标驱动的发布状态机：

自动 rollback 的前提：

回滚路径经过演练。
数据库 migration 有兼容策略或 rollback plan。
Feature flag 可作为快速 kill switch。
健康指标有明确阈值，且有“无数据即失败”的策略。
rollback 动作本身被审计。

不建议自动 rollback 的场景：

涉及不可逆数据迁移。
涉及支付、风控、结算、权限、合规报送。
指标异常可能来自外部流量或观测系统故障。
rollback 会造成更大业务损失，例如协议版本不兼容。

自动/人工审批边界表

动作	默认建议	理由	可放宽条件
读取 CI 日志、测试报告、pipeline 配置	自动	只读、低风险	需遵守敏感日志脱敏
重跑非生产 CI job	自动	可重复、影响小	限制频率和成本
修复 lint/format/test fixture 并开 PR	自动	变更可 review	PR 必须通过 CI
修改 pipeline YAML	人工审批	可能改变控制面	仅限非部署 job 且 CODEOWNERS 通过
修改 secrets、OIDC、runner 权限	人工审批	高权限资产	不建议放宽
生成 OPA/Rego 策略草案	自动	不直接生效	合并策略必须 review
启用/禁用生产 OPA 策略	人工审批	影响所有发布	紧急封禁策略可走 break-glass
生成 SBOM 差异和漏洞解释	自动	只读分析	无
批准高危漏洞豁免	人工审批	风险接受责任不可外包	不建议放宽
创建 staging 环境或 preview environment	自动	可销毁、影响小	成本配额与 TTL
生产 canary 初始部署	人工审批	开始影响真实用户	低风险服务可按策略自动
canary 扩大流量	条件自动	可基于指标放量	SLO、错误率、告警均通过
kill feature flag	条件自动	快速止血	仅限预先标记为 kill-switch 的 flag
rollback 到上一个已知健康版本	条件自动	恢复服务	需已演练且无不可逆 migration
跳过测试、安全扫描或审批	人工审批	治理绕过	必须 break-glass、限时、留痕
生产发布完成签核	人工或自动摘要 + 人工确认	涉及责任归属	低风险内部服务可自动归档

管理者视角：组织、流程、指标、风险

组织设计

建议把 AI 交付治理拆成四类 owner：

平台团队：负责 CI/CD 模板、runner、权限、OPA bundle、artifact attestation、发布平台。
安全团队：负责 SBOM、SCA、SAST、漏洞豁免、供应链策略。
SRE/运维团队：负责 canary 指标、SLO、rollback runbook、incident 处置。
业务研发团队：负责服务 owner、flag owner、变更解释、灰度目标和发布验收。

Agent 的 owner 不能是“模型供应商”。企业内部必须明确：哪个团队维护提示词、工具权限、策略库、审批规则、审计报表和事故复盘。

流程设计

推荐采用四级自主度：

等级	名称	Agent 权限	适用场景
L0	只读分析	读取日志、配置、指标，生成解释	CI 失败诊断、发布影响摘要
L1	生成建议	生成 patch、Rego 草案、release checklist	PR/MR、策略草案、审批材料
L2	受控执行	在非生产或低风险环境执行动作	preview env、staging deploy、重跑 CI
L3	条件生产执行	在策略、审批、指标满足时执行生产动作	canary promote、kill flag、rollback
L4	自主生产发布	Agent 自行决定并执行生产发布	当前不建议作为企业默认目标

指标体系

不要只看“Agent 修复了多少 pipeline”。建议至少看：

Lead time for changes：从 PR ready 到 production 的时间。
Change failure rate：发布后 rollback、hotfix、incident 比例。
Mean time to recovery：从异常到恢复的时间。
Deployment frequency：生产发布频率。
CI repair time：红 pipeline 到绿 pipeline 的时间。
Policy override rate：策略豁免和 break-glass 次数。
Auto rollback precision：自动 rollback 中真正有效的比例。
Flag debt：过期 flag、无 owner flag、长期 100% flag 数量。
SBOM coverage：有 SBOM 和 attestation 的生产 artifact 比例。
Human approval latency：人工审批等待时间和驳回原因分布。

主要风险

权限漂移：Agent 为了“修复”问题获得过大的写权限。
审批空心化：人类只点 approve，不看证据。
策略债务：OPA/Rego 规则无人维护，变成误报或阻塞。
Flag 债务：flag 长期不清理，导致行为组合不可预测。
回滚幻觉：以为能 rollback，但数据库、消息、外部 API 已不可逆。
供应链盲区：AI 修复引入新依赖，却没有 SBOM diff 和漏洞评估。
上下文注入：issue、PR comment、commit message 或 pipeline log 中的恶意内容影响 Agent 行为。

工程师/架构师视角：系统边界与落地细节

1. Agent Runtime 要隔离在发布控制面之外

Agent 可以调用发布平台 API，但不应该拥有发布平台管理员权限。建议采用：

独立 service account 或 dedicated user account。
最小权限 token，按环境和动作拆分。
每个工具调用带 action id、actor、request id、policy decision id。
高风险工具使用 admission control：先评估策略，再执行 API。
所有 effectful operation 进入 audit log。

2. 交付上下文要结构化

不要只把一大段日志塞给模型。建议把 release context 组织成结构化对象：

release:
  service: payment-api
  environment: prod
  artifact:
    image_digest: sha256:...
    source_commit: abc123
    attestation: present
  sbom:
    format: cyclonedx
    critical_vulnerabilities: 0
    high_vulnerabilities: 2
  change:
    files:
      - src/payment/refund.go
      - db/migrations/20260524_add_refund_index.sql
    risk_tags:
      - database
      - payment
  gates:
    tests: pass
    policy: pass
    approvals:
      security: pending
      service_owner: approved
  rollout:
    strategy: canary
    initial_percentage: 1
    rollback_plan: documented

这样做的好处是：OPA 可评估、Agent 可解释、审批人可阅读、审计系统可归档。

3. GitOps 场景下，Agent 不应直接修改集群状态作为唯一事实来源

GitOps 的核心是 Git 作为期望状态。Agent 可以：

读取应用 health、sync status、resource tree、events、logs。
生成变更 PR。
在策略允许时触发 sync、refresh、abort、rollback。

但建议避免：

长期绕过 Git 直接 patch live cluster。
在没有 PR/MR 的情况下改生产 manifests。
让 Agent 同时改 Git、改 cluster、改 observability threshold，导致审计无法还原。

4. 回滚要分层

建议在发布模板里同时定义四层恢复手段：

层级	恢复动作	适用问题	关键前提
L1	Kill feature flag	新功能逻辑异常	功能在 flag 后，默认可关
L2	Canary abort / traffic shift back	新版本局部异常	流量可控，旧版本仍在
L3	Deployment rollback	新 artifact 异常	上一版本可用，schema 兼容
L4	Data repair / incident runbook	数据污染或外部副作用	人工主导，审计完整

Agent 最适合自动触发 L1/L2，谨慎触发 L3，不应自主触发 L4。

总结一下

AI 交付治理的本质，是把 Agent 从“能做事”约束为“只能在正确边界内做正确的事”。CI/CD、Feature Flag、GitOps、canary、rollback、OPA、SBOM 和审批不是 Agent 的阻碍，而是 Agent 可以进入生产链路的前提。

短期内，企业最现实的落地路径不是追求 L4 自主生产发布，而是先把 L0-L2 做扎实：让 Agent 读懂失败、生成修复、补齐证据、更新非生产环境、解释策略失败。然后在少数低风险服务上试点 L3：策略通过、指标通过、可回滚、可审计时，允许 Agent 执行 canary promote、kill flag 或 rollback。

判断这套体系是否成熟，不看 Agent 发布了多少次，而看三个问题：