CI/CD 接入 Agent：把智能放进流水线的正确位置

把 agent 接进 CI/CD 不是"让 AI 自动发版"，而是要精确定位它该在哪个环节出现。我按流水线顺序梳理一遍。 提交前（本地钩子）。可以让 agent 做格式化、静态检查、生成变更说明。这一层的特点是快，不能放重任务，否则开发体验会很差。Claude Code 侧有钩子机制，可以绑到提交、推送这些事件上。 构建阶段。agent 在这里的价值是解释失败。构建报错往往信息量很大但可读性差，让 agent 读日志、定位原因、给出修复建议，能显著减少排查时间。这个用法我认为是性价比最高的。 测试阶段。两个方向：一是让 agent 生成测试用例，覆盖人工容易漏的边界情况；二是让 agent 分析测试失败，区分是代码问题还是测试本身的问题。后者的价值常被低估，因为"测试写错了"和"代码写错了"需要完全不同的处理。 审查阶段。跑审查 agent，输出按严重程度排序的问题清单。注意误报率，太高的话团队会直接忽略所有提示，那就等于没接。 发布阶段。这一层要非常克制。我建议 agent 只做"准备和验证"，不做"决定和执行"。具体是：让它生成发布说明、检查配置一致性、验证健康检查接口，但按下发布按钮的必须是人。 上线后。可以让 agent 做日志巡检、异常聚类、生成故障时间线。这些工作量大但模式固定，适合机器做。 落地上的几条经验： 一，从低风险环节开始。先接构建失败分析，团队感受到价值之后再往前后扩。 二，每个环节都要有跳过机制。紧急发版时不能被 agent 卡住。 三，成本要可见。CI 里的 agent 调用很容易失控，设好每次运行的 token 上限。 四，结果要沉淀。把 agent 的分析结论存档，它本身就是一份运维知识库。 一句话：agent 在流水线里的角色应该是"分析员和助手"，不是"决策者和执行者"。