AREX Feed Article
Claude 官方开发者账号公布 CI 值班智能体 Claude Tag：自动写 SITREP 并维护 lessons.md，模板与 skills 一并公开
北京时间 9 月 9 日 5 时 31 分，Claude 官方开发者账号 @ClaudeDevs 发文宣布：其 CI（持续集成）团队的值班（on-call）第一响应者是一个名为 Claude Tag 的智能体，它读取告警（alerts）、指标（metrics）与日志（logs），据此撰写 SITREP（态势报告，situation report），并在处置过程中持续维护 lessons.md，把学到的经验记下来。称团队正在公开这套配置，包括模板与 skills，希望其他团队也能用上；同一分钟连发的给出了博客全文链接。
随推文公开的《Claude on call: How Claude Tag serves as Anthropic's first responder for CI/CD failures》由 Anthropic 技术成员 Sachin Malhotra 执笔、Michael Segner 参与，写明这套系统已在 Anthropic 生产环境运行数月。推文与博客中的能力描述、效果数字均出自 Anthropic 自己，属于官方自述口径，尚无第三方独立验证。
图：博客插图「三条告警路径汇入同一判定循环」，Claude 依据 oncall.md 中的规则决定呼叫值班人，还是记入 lessons.md。
oncall.md 先过滤：能等到早上的告警不呼叫真人
按博客介绍，整套系统的「骨干」是 Claude Tag 本身：它在值班 Slack 频道里保存记忆、在事故期间提供逐轮指令，并对频道事件实时行动；例行任务用自然语言调度，例如「每周一早上 9 点运行 CI handoff（交接）」。Claude Tag 有自己的服务账号，可以使用 Anthropic CI 工程师的工具（如 Datadog、Grafana），并作为成员加入其他相关频道，获取服务告警、配置变更、PR 动态等上下文。
故障进入值班闭环有三条路径。第一条是告警：Claude 监测每个相关告警，按仓库根目录 oncall.md 文件中的标准决定是呼叫值班人，还是「留到早上」。博客给出的规则示例是：「错误率高于 2% 且持续超过 5 分钟、且不在已知发布窗口内，则呼叫值班人；否则写进 lessons.md。」第二条是人工报障：CI 团队成员在值班频道报告问题。博客开头举的例子是某晚 10 点，同事说一个新服务约有 44 个测试没在跑；Claude 查明测试是当天早上某个 feature flag 打开后消失的，且回滚安全，作者请同事回滚，3 分钟后 Claude 在 Slack 确认 skip 规则已移除、错误率回到基线。第三条是内部事故单：全公司任何人都可以提交，若被标记为 CI 基础设施事故，系统会自动开一个 Slack 频道，值班 Claude 接管。
博客解释为什么要把过滤交给 Claude：人类很难一直预置阈值完美的规则，尤其在数据不足时，所以 Claude 会分析新服务最初几天的数据与告警，建议补充新规则、校准过宽过窄的既有规则；另一个原因是告警疲劳：逐条核验告警是苦差事，而「Claude 不会像人一样疲劳」。博客的总结是：告警环节是确定性的，升级环节则兼有确定性路径与智能体路径。
中位 14 分钟给出首份证据分析，最快 4 分钟点名根因
事故升级后，Claude Tag 会启动一个动态工作流：一个编排（orchestration）智能体拉起多个执行（executor）子智能体，分别调查每个依赖与事实来源：Grafana、日志存储、PagerDuty、GitHub、Kubernetes、Slack 事故频道，全部经 MCP（Model Context Protocol，模型上下文协议）连接器接入。多线索并行是为了缩短平均修复时间（MTTR）；执行智能体把发现交回编排智能体，由后者综合成一份连贯的 SITREP。
图：博客中 SITREP 生成流程示意：每个 agent 只读一个数据源，由工作流汇总成一份 SITREP，全部只读。
执行智能体的调查有章可循：由 investigation skill 引导，并配有按 bug 类别编写的参考 markdown 文件。其中一份针对 shadow divergence 类故障的调查 skill 有 617 行，是作者在一次事故中与 Claude 逐步排查后、让 Claude 据此生成的。调查开始前，Claude 会先读 lessons.md，这份文件记录每一次已解决事故的经过、根因、修复与「值得记住的坑」，由 Claude 自动追加；同一个模式出现足够多次，就被「晋升」进调查 skill。博客引用了作者最喜欢的一条 lessons 条目，是 Claude 写作者的：「先查数据，再提理论。配置告诉你可能哪里出错；指标告诉你实际出了什么。」
团队自述的效果数字是：最近每一起有 SITREP 的事故，首份态势报告都由 Claude 撰写，通常 15 分钟内给出首轮分析；事故开启后，首份有证据支撑的分析中位用时 14 分钟；最快的案例在第一份报告里 4 分钟点名根因。博客也承认 Claude「不是每次都能第一次就答对」，值班频道支持 multi-player 模式，人可以在事故进行中实时引导调查方向或补充假设。
处置与交接：Claude 提议，人拍板执行
Claude 能否直接动手修复事故，博客的回答是「因团队而异」。在 Anthropic，多数部署在 feature flag 之后，作者另建了一个带自己权限的 Claude Code 智能体负责渐进式发布：管理 canary 流量、监控指标、自动把 flag 的比例调上或调下。更常见的修复形态是 PR：Claude 给出修复，值班人 review、合并、部署；它也会提示是否需要 drain、隔离 Kubernetes 集群的某些部分，或在需求激增时给出扩容指令。修复落地后，Claude 用调查阶段同一批连接器核验指标是否回到基线，并按 oncall.md 中的常设指令，把事后总结写进 lessons.md、产出交接 SITREP。
面向人的汇报由另一个叫 ci-weather 的智能体完成：它汇总各事故频道的记录、构建指标、merge queue（合并队列）统计与部署滞后情况，向全公司可读的公共频道发布「新闻稿式」报告，工程师决定是否合入代码前先看这个频道，而不是到处问「CI 怎么了」。博客坦言报告格式迭代了很多次：「Claude 能一次写好生成状态报告的 skill，但让它好读的是团队自己的口味。这是人的沟通，不是管道。」此外，团队每周一要给人类做交接报告，Claude 定期产出日摘要与周摘要，让下一位值班人接手。
博客给出的背景自述是：Anthropic 软件工程师的人均季度交付代码量是 2021～2025 年水平的 8 倍，质量门槛保持不变：每个 PR 都有具名的负责人、每处变更都要审批、都要过同一套 CI 门禁；作者的结论是，「跟上 agentic coding（智能体写代码）的只能是 agentic CI」。
公开套件 oncall-kit：模板、skills 与 48 起虚构事故的测试集
上手这套配置需要满足博客列出的条件：Claude Team 或 Claude Enterprise 套餐；组织 owner 通过 Claude Tag 把 Claude 加进值班 Slack 频道；接好对应的连接器、GitHub 仓库并配置 Claude Code Remote；再把 Claude 加进事故频道，指示它监测并即时分诊（triage）。
公开材料的主体是 GitHub 仓库 ，Apache-2.0 许可，README 自称「参考实现（reference implementation），不维护、不接受贡献」。仓库里 templates 目录下有 ONCALL.md（值班常设策略模板，含待填充的 {{占位符}}）、STACK.md、lessons.md 等模板；skills 目录下有 oncall-setup、triage、handoff、weather 四个 skill，每个都是 markdown 指令文件，triage 还带 references 子目录（test-failures、merge-queue、runner-infra、deploy-rollout 等）。模板在就划好边界：策略值由人设定、改动走 PR；事故由人类宣布，Claude 只能提议「某件事值得开事故」，永远不会自己宣布。
设计上有两个取向。其一是不绑定厂商：skills 只写「能力」（指标源、日志存储、分页器、代码托管），由安装时生成的 STACK.md 把能力映射到频道里实际连接的工具，把 Datadog 换成 Grafana 不必改任何 skill。其二是固定分工：按 CLAUDE.md，Claude 负责收集证据、提议、验证、沟通，人类决定缓解什么、何时缓解。试用也很直接：clone 仓库后在 Claude Code 里粘贴 test-fixtures/RUNBOOK.md 中的一句话指令，约 10 分钟即可看完整套流程跑完一个虚构团队的 48 起历史事故：挖掘、起草 playbook、签署门禁、对照答案卷（ANSWER-KEY.md）评分，全程不碰真实系统；这套夹具同时充当仓库的回归测试。
官方自述口径下，两个执行细节还没有答案
本稿能核验的是推文、博客与公开仓库的内容本身。博客中展示的 Slack 对话截图均标注为「为清晰起见，按真实交流重绘（redesigned/recreated for clarity）」，不是原始记录。截至本稿核验时，主推文已获得 1,772 次点赞、1,238 次收藏与 219,189 次浏览。
回复串里已经出现两类具体的执行问题。 问：经验条目是让 Claude 直接编辑，还是排队等人工接受； 提醒，第一响应者会对每一条告警（包括抖动告警）出动，token 花费记在「没有人认领的 CI key」上，建议按任务记录 token 数，看清分诊的真实成本。另一条回复把判断标准具体化： 提议把同一批事故各跑两遍，一遍不带经验、一遍带着积累的 lessons 条目，对比诊断与恢复时间，检验「记忆是让智能体在下一次事故里变得更好，还是只是更自信」。