Anthropic 把内部 CI/CD 的一线值班交给了 Claude Tag。8 月 18 日公开的这份说明里，最能说明问题的数字有两个：故障单开出来之后，Claude 发出第一份有证据支撑的分析，中位耗时 14 分钟；顺利的时候，4 分钟就能在初始报告里点出根因。
促成这件事的背景写得很直白——工程师人均每季度交付的代码量涨到了原来的 8 倍。产出翻上去之后，构建失败、测试抖动、部署回滚这些事的绝对数量跟着涨，而排查一次往往要占掉一个多小时，还经常落在非工作时段。
Claude 手里有哪些钥匙
这套东西能跑起来，靠的是权限配置而非模型本身。Claude 通过 MCP 连接器拿到了一组访问权：Grafana 和日志存储用来看指标和堆栈，Datadog 补监控，GitHub 用来翻提交、查改动、提 PR，Kubernetes 用来给出集群层面的处置建议，PagerDuty 和若干 Slack 群组用来收告警、发结论。它有自己独立的服务账号，行为可审计。
告警要不要叫醒人，判断规则直接写成了自然语言。文章给的例子是：错误率高于 2% 且持续超过 5 分钟，同时不在已知的发布窗口内，就呼叫值班。这类阈值以前躺在监控系统的配置文件里，改一次要走发版流程；写成 Claude 能读的规则之后，调整成本降到了改一行文字。除了自动告警，团队成员和内部事件页也能手动触发。
分诊阶段是并行的
故障进来，Claude 起一个编排代理，再由它派出多个子代理并行去查不同的依赖：一个翻日志，一个比对最近的提交，一个看指标曲线。这套”动态工作流”的产物就是那份 14 分钟的分析。
支撑判断的是两类文件。一类是技能文件，按故障类型写成调查手册，其中一份专门讲某一类难缠 bug 的排查路径，长度 617 行。另一类是 lessons.md，每次事件收尾后由 Claude 自己追加，下次遇到相似模式先查这里。这两类文件都放在 GitHub 里，跟代码走同一套评审流程。
修复环节留了人的位置。最常见的产出是一个 PR，等工程师评审后再决定要不要部署；灰度靠特性开关控制流量；涉及集群的，Claude 给出排空、隔离或扩容的建议，执行由人拍板。改完之后，它用同一套工具把修复验证一遍。
剩下的活儿归谁
Anthropic 明确保留了几件事给人：中长期的架构改进；在共享模式下和 Claude 一起补假设，因为它并不总是第一次就判断对，需要人的直觉往回拽；PR 的评审门禁；还有沟通口径——状态报告的格式来回改了好几轮才符合团队口味，这部分自动化没吃下来。
交接也被产品化了。每周有汇总报告，日常有摘要，另一个叫 ci-weather 的代理把多起事件编成对外可见的状态说明。
一笔容易被跳过的账
8 倍这个数字，摆在”为什么要做”和”做成之后怎么样”两头，含义并不相同。它先是压力来源：同样规模的团队，交付量涨 8 倍，故障工单不会原地不动。它同时也是这套值班系统能成立的前提——假如代码还是人一行行敲出来的，故障的形态、频率和可解释性都会更贴近工程师的直觉，AI 分诊的边际收益不会这么明显。AI 大量参与写代码之后，让 AI 来做第一层排查，链路上是接得上的。
落地门槛也写清楚了：需要 Claude 的 Team 或 Enterprise 计划，工具连接和权限配置初期要花几个小时。对多数团队来说，难点大概率不在接线，而在敢不敢把一个能提 PR、能调集群的服务账号交出去。
参考来源：Anthropic 官方博客、CocoLoop；14 分钟中位分诊、4 分钟最快根因定位、8 倍季度交付量与 617 行技能文件长度均按公司公开说明核对。