本页目录7
- Claude Tag 是 Anthropic 内部搭建的 Slack 值班代理，依赖跨频道记忆、CI 工具连接、定时任务和 markdown 形式的指导说明四项能力
- 检测阶段依据 oncall.md 里的规则（如错误率>2%持续5分钟）判断是否需要立即通知，其余记录进 lessons.md 供复盘
- 分诊阶段用编排代理+并行执行子代理调查 Grafana、日志、PagerDuty 等多个数据源，中位 14 分钟产出首份分析报告（SITREP），最快 4 分钟点出根因
- 解决阶段可回滚特性标志、调整 Kubernetes、给出扩容建议，或直接以 PR 形式提交修复交工程师审核
- 验证与交接由 ci-weather 代理汇总事件、构建指标与部署延迟，发布公司可见的值班报告，减少对工程师的临时打扰
- 官方开源了 oncall-kit 仓库，包含分诊参考文件、ONCALL.md 模板和测试用例，可在约10分钟内跑通一个虚构团队的值班演示
本文是对官方文章的中文要点摘要，完整内容以原文为准：https://claude.com/blog/ai-ci-cd-on-call
这篇文章出自 Anthropic 持续集成（CI）团队的一名工程师，介绍了他们如何用 Claude 搭建了一套名为「Claude Tag」的值班第一响应系统，专门处理 CI/CD 故障。文中给出的开场案例是：某次 44 个测试失败，Claude Tag 在几分钟内定位到根因是一次特性标志（feature flag）上线导致的，并给出了安全回滚建议。
系统架构：Our Claude on call setup
Claude Tag 作为值班骨干，依赖四项能力：
- 跨 Slack 频道的记忆，能串联同一事件在不同频道里的讨论
- 访问 CI 相关工具的连接权限，通过 MCP 连接器打通 Datadog、Grafana、PagerDuty、GitHub、Kubernetes 等系统
- 例行任务调度，定时巡检和生成报告
- markdown 形式的指导说明，即存放在 GitHub 仓库里的「技能」文件，规定 Claude 该如何判断、该查哪里、该怎么写报告
Claude Tag 拥有独立的服务账户，搭建这套系统所需时间是「数小时」而非「数天」。需要 Claude Team 或 Enterprise 方案，并配合 Claude Code Remote 完成部署配置。
检测：Detection
Claude 会持续监控相关告警，依据 oncall.md 里写明的规则判断是否需要立即拉响（例如「错误率 > 2% 且持续 5 分钟」这类阈值），不满足触发条件的信号则记录进 lessons.md 留档。触发路径有两种：自动告警规则命中，或团队成员在 Slack 里报告 / 内部提交 CI 基础设施事件。Claude 还会分析新服务的历史数据，主动建议调整告警规则以减少误报。
分诊：Triage
这是整套系统的核心环节。Claude 通过动态工作流启动一个编排代理（orchestrator）和多个并行执行子代理（executor），分别去查 Grafana、日志存储、PagerDuty 等不同数据源，编排代理再把结果汇总成一份 SITREP（情况报告）。调查过程由细化的参考 markdown 文件指导——文中举例提到一份长达 617 行、专门用于排查「阴影散异（shadow divergence）」类 bug 的调查技能文件。lessons.md 里积累的历史事件记录会帮助 Claude 更快形成初始假设。官方数据：首份分析报告通常在 14 分钟内（中位数）发布，最快 4 分钟就能定位根因。
解决：Resolution
由于 Anthropic 大多数部署都挂在特性标志之后，Claude 会用独立代理管理灰度发布并持续监控是否出问题。其他解决路径还包括：
- 给出 Kubernetes 集群层面的操作建议
- 提供基础设施扩容指令
- 直接以 PR 形式给出修复方案，交由工程师审查后再部署——而不是自动合并
验证、沟通与交接：Verification, communication, and handoff
Claude 用同一套 MCP 连接器验证修复是否生效（文中的 3 分钟是某次具体事件里的情节——「Claude 三分钟后在 Slack 上找我确认 skip 规则确实已移除」，不是通用统计），并把故障后总结写回 lessons.md，形成可复用的知识库。另有一个独立代理叫 ci-weather，负责汇总所有事件、构建指标和部署延迟数据，发布到公司内公开可见的频道，减少工程师被反复「@」询问进展的打扰。每周一会产出面向人类的交接报告，Claude 同时生成日报与周报，方便值班同事接力（文中的「每周一上午 9:00 EST」出现在演示自然语言排程的例子里，不是交接报告本身的固定时刻）。
效果与思路转变
文章提到，Anthropic 工程师人均季度代码交付量相比 2021–2025 年提升了约 8 倍——这是全公司层面的既有事实（原文链向 recursive-self-improvement 页），文章用它来论证「agentic 编码的节奏只能靠 agentic CI 跟上」，并非把这 8 倍归功于 Claude Tag。同时原文强调质量线未降：每个 PR 有具名负责人、每次变更需批准合并、都过同一套 CI 门禁。核心逻辑是：Claude 承接了值班中琐碎、打断节奏的重复劳动，让工程师能把精力放到长期架构改进上。作者把 Claude Tag 定位成 Slack 频道里「团队的一员」，而不只是一个告警脚本。文章标题也点出了下一步的关注方向——从「监控事件」转向「监控这套事件响应系统本身」的可靠性。
如何上手：oncall-kit
官方在 GitHub 开源了 oncall-kit 仓库，内容包括：
- 一套通用的 setup kit
triage文件夹下按 bug 类别整理的参考 markdown 文件templates文件夹里的ONCALL.md模板- 一组测试用例，约 10 分钟内即可跑通一个虚构团队的值班演示
lessons.md日志模板
文章结尾再次强调该方案需要 Claude Team 或 Enterprise 方案，并给出了这个开源 setup kit 的链接，鼓励读者据此快速搭建自己团队的 Claude 值班系统。