Claude 14 分钟出报告，修复还得人来签

44 个测试在晚上十点突然不跑了。

换成很多团队的日常，这时候值班工程师大概已经掀开电脑，开始在功能开关、测试配置和日志之间来回切窗口。Anthropic 的那位 CI 工程师没有先这么干，他在 Slack 里叫来 Claude，问它看到了什么。

Claude 顺着证据找到了那枚当天早上启用的功能开关，判断测试就是从那里消失的，也给出了可以回退的建议。真正按下回退按钮的仍然是人。三分钟后，Claude 再次检查跳过规则和错误率，确认系统回到了基线。

这是 Anthropic 在 8 月 18 日公开的 CI/CD 值班案例。过去几个月，Claude Tag 一直在他们的 CI 事故频道里担任一线响应者。每次事故的第一份态势报告由它起草，基于证据的初步分析中位耗时 14 分钟，最快的案例用 4 分钟找到了根因。

好家伙，14 分钟。

很多发布稿写到这里，大概就会顺势把标题改成「AI 接管运维」，再配一张机器人盯着几十块监控大屏的图。可我把官方的整套流程看完，真正让我觉得有点子牛逼的地方，反而是 Claude 没有接管什么。

它是第一响应者，不是事故总指挥。

一线响应和自动处置之间，Anthropic 留了一道很宽的权限缝。那道缝，才是普通团队最值得抄的部分。

14 分钟快在并行追证据

一次 CI 事故很少只有一条线索。你得看 Grafana 的指标，翻日志，核对 PagerDuty 的告警时间，再去 GitHub 找刚合并的 PR，到 Kubernetes 看工作负载，回 Slack 对齐谁刚改过配置。

这些系统每一个都不神秘，麻烦在于它们分散。人类值班时，时间经常不是花在推理上，而是花在登录、切窗口、重写查询条件、复制时间戳和重新建立上下文上。查到第五个系统时，前两个系统里看到的细节已经开始从脑子里往外掉。

Anthropic 的做法是让 Claude Tag 启动一条动态调查工作流。一个编排 Agent 负责拆线索，多个执行 Agent 分别去查指标、日志、代码、集群和事故频道，再把证据交回来。所有来源通过 MCP 连接器 接入。MCP 可以理解成 Agent 访问外部工具的统一插座，模型不必为每个系统重新学一套交互方式。

并行的价值不是让六个模型一起表演热闹，而是把六段等待时间叠在一起。日志查询还在跑时，另一个执行 Agent 已经去对照最近的部署；GitHub 变更还在收集时，指标侧已经开始核验错误率从哪个时间点抬头。

交回来的也不是一句「我怀疑是功能开关」。它得是一份 SITREP，也就是事故态势报告，里面要有时间线、假设、证据、影响范围和下一步建议。

这块需要注意一下。模型的回答速度从来不等于事故响应速度。真正减少 MTTR，也就是平均修复时间的，是把找证据、对时间线和排除错误假设这些机械劳动并行化。没有接入真实监控和代码记录，再聪明的模型也只能在聊天框里算命。

所以 14 分钟不是一个单纯的模型跑分。它其实是工具接入、并行调度、调查手册和权限设计一起给出来的系统成绩。

617 行调查手册，比长提示词管用

这套系统还有一个很容易被忽略的细节。Anthropic 没让 Agent 每次看到告警都自由发挥。

官方提到，一类影子流量分歧故障的调查手册足足有 617 行。工程师把自己平时怎么查这类问题，按真实事故一轮轮教给 Claude，沉淀成可版本管理的 Markdown 文件。更细的故障类型则放在公开的调查手册目录里。

这不是在提示词里写一句「请像资深 SRE 一样认真分析」。那种话看着很有气势，出了事故基本等于给空气贴工牌。

真正能复用的手册会告诉 Agent 先查哪个指标，时间窗该怎么选，哪些配置只能当假设，什么证据能推翻当前判断，什么时候必须升级给人。每一步都能被日志验证，也能在代码审查里被同事改掉。

团队还维护了一份 lessons.md，记录每次事故发生了什么、根因是什么、修复做了什么，以及哪一步最容易踩坑。新事故开始时，Claude 会先读最近经验。某种模式重复出现得够多，再从经验日志晋升为正式调查手册。

我看到里面一句话笑了一下。作者曾经根据配置文件先做了推断，没先看指标，于是 Claude 把教训记成了「先查数据，再做推断。配置只能告诉你哪里可能出错，指标才告诉你刚才哪里真的出了错」。

这句话比很多 Agent 记忆方案都朴素。

记忆不是把所有历史聊天塞回上下文。有效记忆得经过分层，刚发生的个案先进事故日志，反复验证过的模式才进入稳定手册。一个负责保存现场，一个负责约束动作。全塞在一起，旧事故里的偶然细节很快就会冒充新规律。

坦率讲，很多团队想做值班 Agent 时，第一反应是换更强模型。可如果调查经验还散落在几个人脑子里，告警规则写在控制台，事故复盘躺在文档角落，换模型只会得到一个更会自信猜测的聊天机器人。

Anthropic 公开的 on-call 套件选择从团队历史事故里生成排障手册，再把 Agent 放进频道做只读诊断。顺序很克制，先把经验变成可执行文本，再谈自动化。

回滚按钮故意没有塞进同一只手

文章最关键的一段，不在 14 分钟，也不在多 Agent。

Claude Tag 会建议是否排空 Kubernetes 节点，是否临时扩容，或者提交一个修复 PR。但 PR 仍由值班工程师审核、合并和部署。开头那次 44 个测试消失，Claude 找到了功能开关，人类同事执行回退，Claude 再负责验证。

调查和处置被分开了。

这是很现实的风险账。调查猜错一次，代价通常是多花几分钟换条线索。自动回滚猜错一次，可能把局部 CI 问题扩大成整条交付链路停摆。两个动作看起来只差一个按钮，失败成本完全不是一个量级。

Anthropic 确实还有能控制金丝雀流量和功能开关的 Claude Code Agent，但官方特意说明，那是另一套 Agent，使用工程师自己的权限，负责渐进式部署。检测、调查、部署没有被揉成一个万能账号。

这个设计很重要。一个 Agent 如果既能读生产日志、又能修改代码、还能直接改集群和回滚部署，一次提示注入、一次身份误判或者一个错误假设，就可能沿着整条权限链滑到底。权限越完整，事故半径越大。

更稳的做法是给每个角色独立身份。Claude Tag 用自己的服务账号读取必要数据，调查动作全部留审计记录。写操作交给另一条经过审批的路径。高风险动作还要绑定明确的人类负责人、变更单和 CI 门禁。

不是哥们，Agent 能替你熬夜，不代表它也该替你背锅。

生产系统终究得有人签字。这个人不一定亲手跑完每条查询，但得知道证据来自哪里、动作会改什么、失败以后怎么退回来。

普通团队从影子值班开始

Anthropic 的工具栈很豪华，Claude Tag、Slack、Grafana、PagerDuty、GitHub、Kubernetes 和一串连接器都齐了。普通团队没必要照着采购清单抄。真正能搬走的是那条权限爬坡路线。

起步时，让 Agent 只做影子值班。它可以读取告警、指标、日志和部署记录，但不能写配置，也不能执行修复。每次事故让它产一份带时间范围、证据链接、置信度和待验证假设的报告，与人类值班结论对照。跑上十几次以后，你才会知道它擅长哪类故障，又会在哪些地方一本正经地跑偏。

告警触发继续保持确定性。错误率连续多久超过多少，是否处于部署窗口，哪些服务必须立即叫人，这些规则写进版本库，不交给模型临场决定。Agent 可以建议调整阈值，但改规则仍走审查。厉害了，最像传统运维的那一层，反而是整套 Agent 系统的地基。

影子值班跑稳后，再开放低风险写入。所谓低风险，不是让它直接动生产，而是允许它更新事故记录、生成查询链接、补充 lessons.md，或者开一个等待审核的修复 PR。每个动作都应该幂等，重复执行不会造成二次伤害；也要能追到谁发起、Agent 看过什么、最终谁批准。

再往前走，才轮到自动处置。适合自动化的通常是可逆、范围小、验证快的动作，例如调整一小部分金丝雀流量，或者关闭刚开启的功能开关。动作之后必须自动检查错误率、延迟和测试恢复情况，超时没有回到基线就停止，并立即叫人。

数据库迁移、权限修改、大范围扩容和跨服务回滚，还是留给人。不是模型永远做不到，而是这些动作的验证周期长、影响面大，错误恢复又贵。自动化不是越多越先进，能把事故半径锁住才算工程。

还得监控这套事故响应系统自己。Agent 有没有漏掉告警，报告里的证据链接是否能打开，14 分钟是不是逐渐变成 40 分钟，经验日志会不会越写越乱，某个连接器失效后系统是否还在假装调查。这些都要进入新的仪表盘。

Anthropic 把汇总 Agent 叫 ci-weather，它会整理事故频道、构建指标、合并队列和部署延迟，生成给全公司看的 CI 天气报告。官方也承认，报告格式改了好几轮。模型可以很快搭出管道，真正让人愿意读的表达，还是团队自己的审美。

这事儿挺有意思。大家总盯着 Agent 能不能替人按按钮，Anthropic 展示的却是一套更朴素的分工，机器负责不知疲倦地收集证据、追线索、写报告和验证结果，人负责批准那些失败成本高的动作。

回到晚上十点消失的 44 个测试。最漂亮的部分不是 Claude 找到了功能开关，而是整个顺序没有乱。

Claude 先把证据摆上桌，人来决定回退，Claude 再确认世界恢复正常。

值班 Agent 真正该抢走的，是半夜里那些耗神的查证工作，不是那支签字的笔。