深度 · 小互解读

Anthropic 把 Claude 拉进值班群：半夜系统报警，它先起来查

过去人工排查动辄超过一小时；现在 Claude Tag 7×24 小时驻守 Slack，中位 14 分钟给出首份证据分析。

一分钟速览
  • Claude Tag 先接管 CI/CD 告警后的连续搜证和首报，人类继续掌握生产变更。

传统值班和 Claude 第一响应，有什么不同

Anthropic 工程师 Sachin Malhotra 分享了他们已经运行数月的 CI/CD 值班方案：让 Claude Tag 常驻 Slack 值班群和告警群，充当 7×24 小时第一响应人。

同一次告警，两种处理方式

差别不只是更快，而是谁在持续做第一轮调查

点选一种方式聚焦；默认并排对照。

人工串行工程师被告警叫醒后开始找证据
> 1 小时一次人工调查动辄超过一小时
  1. 被动打断晚上被 page，必须立刻切换上下文。
  2. 逐个查系统手动打开监控、日志、代码、部署记录与事故频道。
  3. 阈值两难太敏感会告警疲劳，太宽松又可能漏掉事故。
Agent 并行Claude Tag 先调查，人类再复核与决策
14 分钟首份证据分析中位数；最快 4 分钟命中根因
  1. 7×24 驻守常驻 Slack 值班群和告警群，自动接住第一轮信号。
  2. 并行搜证多个 Agent 同时查监控、日志、代码、集群和历史事故。
  3. 带证据交付输出时间线、根因假设和建议，交给工程师判断。
核心变化：机器承担连续搜证，人类保留生产决策。
Anthropic 自报数据。14 分钟为首份证据分析中位数，4 分钟为最快首报命中根因。

Anthropic 自报，Claude 给出首份基于证据的分析报告，中位时间是 14 分钟；最快案例在 4 分钟内就在首报中指出根因。这里说的是第一轮调查结果，不是事故完全修复时间。

一个真实案例发生在晚上 10 点：新服务约有 44 项测试没有运行。Claude 把问题定位到当天开启的 read-mode feature flag；人类执行回退；3 分钟后，Claude 再次检查并确认规则恢复、错误率回到基线。

它不是一个 Bot，而是一套值班系统

Claude 能持续值班，靠的不是一段万能提示词，而是频道上下文、Git 知识、工具连接和多 Agent 调查共同工作。

不是一个 Bot，而是四层运行系统

能记、能查、会回来、按规则行动

01 · 频道载体
Claude Tag

保留值班频道上下文，实时响应事故与人类指令。

02 · 证据能力
Service account + MCP

读取监控、日志、pager、代码、集群与事故频道。

03 · 时间触发
Routines

按事件或日程重新运行，例如周一生成 handoff。

04 · 知识控制面
Skills + ONCALL.md + lessons.md

把调查、升级、路由和经验放进 Git 审查。

四层缺一不可：连接决定能看到什么，文件决定该怎么判断。

调查方法和事故经验都保存在 Git 中。lessons.md 记录每次事故的根因、修复和教训，不同故障有各自的调查手册；shadow divergence 故障甚至有一份 617 行的调查 skill。

真正值得复制的不是“617 行”这个数字，而是它的生成方式：工程师在真实事故中和 Claude 逐步排查，事后再把过程整理成 skill。一次性教训先进入 lessons.md，同一模式反复出现后才晋升为正式手册。里面最重要的一条原则是：先查数据，再做理论推测——配置只能说明哪里可能出错，指标才能说明实际发生了什么。

一次事故，Claude 怎么处理

一次事故的闭环

先分诊，再搜证；辅助修复，最后验证并学习

点击四个阶段，查看它读什么、做什么、交付什么。

读取

告警频道、人类报告、内部 incident 页面，以及新服务上线后的流量与告警数据。

执行

确定性监控负责触发信号；Claude 依据 ONCALL.md 和现场上下文判断严重度与升级路径。

交付

立即 page 人类，或写入 morning log 等白天处理。

读取

lessons.md、故障 playbook、Grafana、日志、PagerDuty、GitHub、Kubernetes 与 Slack。

执行

执行 Agent 分头读取 source of truth；先查数据再推测。人类可随时提出反例或补充假设。

交付

带证据链接的 SITREP：发生了什么、可能根因、下一步怎么做。

读取

已验证的根因假设、feature flag、集群状态与代码或配置差异。

执行

内部高权限 Agent 可升降 canary；Claude 也可建议 drain/cordon、扩容或生成修复 PR。

交付

可审阅的操作计划或 PR；值班工程师负责关键生产变更。

读取

修复后的同一组监控、日志、测试结果与事故线程。

执行

确认指标回到基线，记录根因与修复，重复模式再晋升为 playbook。

交付

验证结论、lessons.md 更新、每日和每周交接，以及 ci-weather 公共状态。

公开 oncall-kit 默认只读；Anthropic 内部的 canary Agent 具有更高权限，二者不能混为一谈。

这里有两条重要边界。第一，监控告警仍是确定性系统，Agent 负责结合上下文判断是否升级；第二，Claude 不一定第一次就判断正确，人类可以随时提出反例、增加假设，让它回到数据继续验证。

这四步构成完整闭环：先过滤和升级告警，再并行调查证据，随后辅助修复，最后确认指标恢复并把经验写回系统。ci-weather 还会把多个事故、构建指标、合并队列和部署延迟汇成公共状态报告，减少其他工程师反复追问 CI 是否正常。

Anthropic ci-weather 流程图：事故频道、构建指标、合并队列和部署滞后汇入 Claude Tag，再写入 SITREP store，供任何人查询。
发布者原图。共享状态面减少其他工程师反复打断 CI 团队。

不过，状态报告并不是让 Claude 生成一次就结束。Anthropic 团队反复调整过格式，因为报告是否好读，取决于团队自己的沟通习惯——这是人类沟通问题，不只是技术管道。Claude 还会生成每日和每周交接，让下一位值班人接着处理。

有一条权限边界必须讲清：Anthropic 内部另有带工程师权限的 Claude Code Agent，可以自动升降 feature flag 的 canary 流量；公开的 oncall-kit 默认只读，生产变更仍由人执行。

其他团队怎么开始

Anthropic 称这套基础配置花了几个小时，而不是几天。最短路径只有四步：

  1. 开通 Claude Team 或 Enterprise，把 Claude Tag 加进 Slack 值班群；
  2. 接入监控、日志、PagerDuty、GitHub、Kubernetes 等 Connectors，并配置 Claude Code Remote；
  3. 用团队自己的历史事故生成 lessons.md、排查手册和升级规则；
  4. 先让 Claude 只读调查、输出诊断，人类核对可靠后再考虑增加权限。

官方 setup kit 还提供了一套约 10 分钟的虚构事故演练，可以先理解流程，不必直接连接生产系统。

它最终替工程师省掉的，不只是几次手工查询，而是机械调查、夜间打断和重复事故沟通，把人的时间还给中长期架构与可靠性建设。

来源
Claude on call: How Claude Tag serves as Anthropic’s first responder for CI/CD failuresSachin Malhotra·2026-08-18·查看主材料
延伸
anthropics/oncall-kit·When AI builds itself·A harness for every task: dynamic workflows in Claude Code
本站说明
内部效果数据来自 Anthropic 自报；公开 oncall-kit 是只读、未维护的参考实现。