很多团队把 Agent 接进告警中心、Git 平台和发布流水线希望它代查失败任务、补跑构建或自动回滚。⚠️ 真正容易出事故的地方不是 shell 命令失败而是命令全都成功最后才发现处理错了构建。同一个服务一天可能触发几十次 pipeline。 如果 Agent 只拿到“服务名 时间窗口 一段报错日志”它很容易把“最像”的那次构建认成目标最后动作却落到了错误制品上。[外链图片转存中…(img-Gj4aQzqW-1778199439338)]图 1最危险的不是构建失败而是修错那一次Agent 为什么会在 CI/CD 上修错构建第一层根因是很多链路把“失败告警”当成完整上下文却没有把workflow_run_id、rerun_attempt、commit SHA和目标环境冻结成执行参数。 同一条主干分支在半小时内连续发布三次时Agent 很容易把最新成功构建、上一次失败构建和当前待修构建混成一个事件。第二层根因是制品血缘在多数平台里并不天然连通。 构建日志属于 CI镜像摘要在制品库部署记录又在 CD如果索引层没有把build - artifact digest - deployment record串起来模型看到的只是相似文本。✅ 血缘链只要断一段回滚和补发就可能做错对象。[外链图片转存中…(img-ipZnPsd0-1778199439343)]图 2日志相似不等于目标相同血缘才是主键一组 Build Provenance 回放实验在一组47次真实发布故障回放里团队把策略分成三档。 基线组只给 Agent 告警文本和最近20条流水线记录第二组补上 Build Provenance把分支、提交、触发人、重跑次数和环境一起过滤第三组再补 Artifact Lineage要求每次动作都命中同一个镜像摘要和部署记录。方案修错构建率回滚成功率人工接管次数中位处置时长只检索告警与日志17%62%1311 minBuild Provenance6%81%812 minArtifact Lineage0%91%513 min结果很直接真正把事故率打下来的不是让模型“再谨慎一点”而是先把目标构建缩到唯一。️ 当执行器先确认workflow_run_id对应的commit SHA、镜像摘要和目标环境一致时Agent 才有资格去做 rerun、rollback 或 redeploy。incidentresolve_incident(alert_id)runfind_pipeline_run(serviceincident.service,commit_shaincident.commit_sha,envincident.environment,rerun_attemptincident.rerun_attempt,)artifactget_artifact_by_run(run[workflow_run_id])deploymentget_deployment_record(envincident.environment,artifact_digestartifact[digest],)assertdeployment[status]in{failed,degraded}assertartifact[digest]incident[expected_digest]execute_recovery(run,artifact,deployment)这段闸门的重点不是多查几张表而是让所有动作都围绕同一个 lineage key 收敛。 一旦digest、环境或重跑代次对不上链路就必须停下不能因为“日志很像”就继续修。[外链图片转存中…(img-ESoS0Mdy-1778199439344)]图 3先定位唯一构建再谈自动修复真正该补的是制品血缘而不是更多日志很多团队发现 Agent 修错构建后会继续往知识库里塞更多失败案例和日志模板。❗ 这类补法通常只能提升“看懂报错”的能力却不能提升“找准对象”的能力。更稳的做法是把workflow_run_id、job_id、commit SHA、artifact digest、release ID和deployment ID做成统一检索键。再往前走一步执行前加一次 preflight 对账也很关键。 当前线上跑的是哪个digest待回滚的是哪次发布目标环境是不是同一个租户与 region这些都该在按钮按下前比对完成。笔者认为CI/CD Agent 真正要学会的不是更多平台 API而是尊重“同一次构建只能有一个被证明的身份”。⭐图 4制品血缘补齐后自动化才有资格接管发布动作未来 3 到 6 个月发布 Agent 会从“会修”转向“只修对的那次”接下来3到6个月真正能进生产的发布 Agent大概率都会把 Build Provenance、Artifact Lineage 和 preflight reconcile 做成第一类能力。 难点不是生成动作建议而是让建议只绑定当前事故对应的那次构建谁先把这条身份链做实谁就更可能把自动修复推到值班体系。一句话总结CI/CD 场景里最危险的错误不是修不动而是修得太像。 如果现在的 Agent 仍主要依赖日志相似度和最近时间窗口来认目标它自动化掉的不是人工而是最后一道确认。你们现在的发布 Agent绑定的是一段报错文本还是一条完整的制品血缘链