热点来源：Claude Blog（Anthropic）- 《Claude Tag 如何担任 Anthropic CI/CD 故障的一线响应者》（https://claude.com/blog/ai-ci-cd-on-call）
附：Anthropic 开源 on-call 搭建套件 oncall-kit（https://github.com/anthropics/oncall-kit）

晚上 10 点，值班中的工程师 Sachin Malhotra 收到同事 Slack：一个新服务约 44 个测试没触发。以前他得合上手里的活、掏出笔记本、开始一小时的"调查-修复"流程。现在他只做一件事：在频道里 @Claude，问它看到了什么。

这次 Claude 的回答是：测试消失是因为当天早上一个 feature flag 被打开，回滚是安全的。同事回滚后，3 分钟 Claude 在 Slack 里确认 skip 规则已移除、错误率回到基线。

这不是演示——过去几个月，Claude Tag 就是 Anthropic CI/CD 故障的一线响应者。每一次有情况报告的事故，Claude 都是首份报告的作者，中位 14 分钟发布基于证据的首份分析，最快案例 4 分钟内就在首份报告中指出根因。

一、值班智能体的四个要素

Anthropic 的 CI 工程师把值班智能体拆成四块：

1. 记忆：记得做过什么、之前发生过什么；
2. 连接与访问：能查数据、能动手（Datadog、Grafana 等工具）；
3. 排班：知道什么时候该回来干活；
4. 指令：知道遇到事情该怎么做。

支撑这些的底座是 Claude Tag：它在值班 Slack 频道里持有跨会话记忆，也提供事故期间每轮指令的接口；排班用自然语言就能配，例如 “run CI handoff every Monday at 9:00am EST”。Claude Tag 有自己的服务账号，管理员一次性接好 Datadog、Grafana 这些工具；它还能加入其他相关频道（服务告警、配置变更、PR 更新）获取额外上下文。

核心设计：值班指令以 Markdown 文件的形式提交到 GitHub 仓库，像管代码一样管 prompt，团队成员可以并行迭代。

二、检测阶段的两个失败模式

值班智能体不只是响应快，它先解决了检测环节两个人类固有的失败模式。

失败模式 1：人类很难预设完美规则。尤其新服务还没积累流量数据时，阈值定宽定窄全靠猜。解法：Claude 观察新服务前几天的数据和告警，主动建议新规则、微调过宽或过窄的规则。

失败模式 2：告警疲劳。逐条核验每个告警极其枯燥，而 Claude 不会疲劳。它会监控告警频道里的每条告警，按 oncall.md 里的标准判断：能等到早上，还是需要立刻 page 值班人。规则长这样：

# oncall.md（示意，格式参考 Anthropic 的 oncall-kit 模板）
- 错误率 > 2% 且持续超过 5 分钟，且不在已知部署窗口内
  → page 值班人
- 否则 → 记入 lessons.md，等早上处理

解释：这是两条确定性判定规则，第一行是升级条件（三个子条件同时成立才 page），第二行是兜底路径（记入经验文件）。好处是判定逻辑完全可审、可改、可测试，Claude 只执行分类，不自由发挥"要不要打扰人"。

触发事故有三条路径：CI 团队成员在值班频道直接报告（开头 44 个测试的例子）；公司内部 page 系统打开事故，若是 CI 基础设施事故会自动建一个 Slack 频道，值班 Claude 接单。

这里有个值得记住的原则：告警判定是确定性的，而升级处理既有确定性路径，也有智能体路径。

三、Triage：编排者 + 执行者的并行调查

事故升级后，Claude Tag 启动一个动态工作流：编排智能体（orchestrator）拉起多个执行子智能体（executor），并行调查每个依赖和数据源——Grafana、日志库、PagerDuty、GitHub、Kubernetes、事故 Slack 频道，全部通过 MCP Connectors 接入。执行者把发现回报给编排者，编排者综合成一份连贯的 SITREP（情况报告）。多路并行是缩短 MTTR（平均修复时间）的关键。

两个关键支撑：

lessons.md——每次已解决事故的运行日志：发生了什么、根因、修复、值得记住的坑。Claude 会自动追加。每次新调查从读它开始，所以首条假设总是从"最近发生过什么"起步。同一模式重复出现足够多次，就把它提升为正式调查技能。

调查技能——GitHub 仓库里为每类 bug 准备的详细参考文件。作者举例：shadow divergence 类 bug 的调查技能有 617 行，编码了他典型调查的每一步。它是怎么来的？一次事故中作者和 Claude 逐轮排障，结束后让 Claude 把这段经历写成了文件。

四、踩坑复盘：三个真实教训

这篇博客最有价值的部分，是作者毫不掩饰的踩坑记录。

教训 1：先查数据，再提理论。作者有一次从配置文件直接做假设，没先看指标。现在 lessons.md 里躺着 Claude 写的一条：query the data first, then theorize——先查数据再理论化。配置文件告诉你哪里可能出错，指标告诉你到底哪里出错了。

教训 2：Claude 不是每次都第一次就对。解决办法不是撤掉智能体，而是接受"人机共排查"：Claude Tag 支持多玩家模式，人和 Claude 都能实时引导调查方向、补充假设，一起完成排查。人类直觉和经验仍然重要。

教训 3：报告格式要反复迭代。Claude 可以一次生成一个状态报告技能，但"可读性取决于团队口味，这是人类沟通问题，不是管道问题"。ci-weather 这个跨事故报告智能体的格式，团队迭代了好几次才定稿。

五、修复、验证与交接

修复路径因团队而异，Anthropic 常用的三种：K8s 集群需要 drain/cordon 时给出指示；响应需求激增时给出扩容建议（不常见但极有用）；最常见的，直接产出修复 PR，值班人审查、合并、部署。

验证环节复用调查时的 MCP Connectors：确认修复真的生效，并按 oncall.md 的要求把 post-mortem 写进 lessons.md。

交接分两层：Claude 自己靠 lessons.md 保持连续性；对人，Claude 每个工作日/每周产出摘要，周一值班人能无缝接手。另有 ci-weather 智能体把各事故频道的状况、构建指标、合并队列统计、部署滞后汇总成新闻稿式报告，发到全员可见的频道——工程师不用再追着问"CI 怎么了"。

背景数字：Anthropic 软件工程师人均每季度代码产出是 2021-2025 年的 8 倍，质量门槛没降（每个 PR 有具名负责人、合并要审批、过同一套 CI 关卡）——跟上智能体编程速度的，只能是智能体 CI。

六、想自己搭？用 oncall-kit

Anthropic 把整套方案开源成了 oncall-kit（GitHub 仓库），它会把你自己团队的历史事故转成 triage 手册，并在事故频道留下一个只读 Claude：诊断、升级、学习。用测试数据跑通大约 10 分钟。起步清单：

1. Claude Team 或 Enterprise 套餐；
2. 组织管理员通过 Claude Tag 把 Claude 加入值班 Slack 频道；
3. 在频道里接好 connectors、GitHub 仓库，配好 Claude Code Remote；
4. 把 Claude 加入事故频道，指示它监控事故并立即 triage。

小结

这个案例最值得学的不是"用 Claude 值班"这个动作，而是它的工程化程度：指令进 Git 仓库、经验沉淀成 lessons.md、模式升级成调查技能、人机协同留了多玩家接口。值班智能体不是一个 chatbot 挂进频道，而是一套会自己积累经验的事故响应系统。