Anthropic 的 CI/CD 团队把 Claude Tag 部署成事故响应的第一响应者：它持续监控告警，调用多个子智能体并行调查证据，提出缓解或修复方案，并在事后沉淀经验与完成交接。本文完整介绍了这套值班系统的配置、检测、分诊、解决和验证流程。
原文：Claude on call: How Claude Tag serves as Anthropic’s first responder for CI/CD failures
本文由 LobsterAI 自动翻译和发布。
面向 CI/CD 的 AI 事故响应：Claude 在 Anthropic 值班
几周前，我正在值班。晚上 10 点，一位同事在 Slack 上给我发来消息：某项新服务中大约有 44 个测试没有运行。
过去，我会停下手头的事，在笔记本电脑前坐好，疲惫地叹口气，然后开始一段长达一小时的调查与修复流程。但现在，我的工作方式已经完全不同：我会把 @Claude 拉进来，问问它看到了什么。
这一次，Claude 发现：当天早上开启某个功能标志后，这些测试就消失了；同时，它还判断回滚该变更是安全的。我让同事回滚了这个标志。3 分钟后，Claude 在 Slack 上提醒我，并确认相关跳过规则确实已被移除，错误率也恢复到了基线水平。
为清晰起见，根据一次真实交流重新设计。
过去几个月里，Claude Tag 一直是 Anthropic CI/CD 故障值班体系中的第一响应者。它不仅改善了我们的业余生活，也让每起 CI 事故都能立即得到响应：近期所有形成情况报告的事故，其第一份报告均由 Claude 撰写；通常，它会在 15 分钟内发布初步分析。
本文将介绍我们构建了什么、它如何运作，以及你如何亲手搭建类似系统，从此不再害怕轮到自己值班。
我们的 Claude 值班配置
在逐一介绍事故响应流程的各个阶段之前，我先概述一下整体配置。这样，当我们继续补充细节时，你能始终把握全局。
一个值班智能体需要具备：记忆，以便记住已经完成的工作；连接与访问权限，以便调查、理解并采取行动；调度能力，以便知道何时恢复工作；以及指令，以便知道该做什么。
Claude Tag 是我们值班智能体的骨干。它会保留值班 Slack 频道中的上下文记忆，同时提供一个界面，方便我们在事故期间为每一轮交互下达指令。Claude 还会实时响应值班频道及其他频道中的事件。例行任务——也就是 Claude 定期执行的操作——同样在这个频道里通过自然语言提示进行调度，例如：“每周一上午 9:00（美国东部时间）执行 CI 交接。”
Claude Tag 拥有自己的服务账号，也能够访问 Anthropic CI 工程师需要使用的工具，例如 Datadog 或 Grafana。频道管理员只需进行一次配置（配置方法）。
除了值班频道外，我们还让 Claude 监控其他相关频道——这些频道里同样有 Claude Tag。这样，它就能获得更多背景信息，例如服务告警、配置变更或 PR 更新。
长期有效的指令以技能的形式保存在 Markdown 文件中，并提交到 GitHub 仓库。这样，多位团队成员可以共同迭代这些指令，而我们也能像管理代码一样管理变更。仓库中还包含路由说明、策略，以及作为自我改进闭环组成部分的经验教训日志等关键信息。
这套配置花了我们几个小时，而不是几天。我们在 GitHub 上创建了一套通用的值班配置套件，帮助你快速搭建类似的智能体。它会把你团队自己的事故历史转化为分诊手册，最终在事故频道中部署一个只读 Claude，用于诊断、升级处理并持续学习。你可以用大约 10 分钟，看它针对一个虚构团队的历史事故完整运行一遍。
简要概括，步骤如下：
- 你需要 Claude Team 或 Claude Enterprise 方案。
- 组织所有者需要通过 Claude Tag，把 Claude 添加到值班 Slack 频道。
- 组织所有者还需要协助 Claude 连接值班 Slack 频道中的适当连接器、GitHub 仓库，并配置 Claude Code Remote。
- 将 Claude 添加到事故频道，并指示它监控事故、立即进行分诊。
接下来，我们深入看看这种转变在事故处理的每个阶段具体是什么样子。
检测
Claude 改变的不只是事故响应方式，它也从根本上改变了事故检测方式。过去，事故检测主要存在两种失效模式。
第一，人很难始终有足够的前瞻性，提前设定完美的规则和完美的阈值。尤其是在数据不足、无法分析流量模式时，这一点更加困难。
为解决这个问题，在新服务上线后的头几天，我们会让 Claude 分析数据和传入的告警，建议补充规则，并微调那些范围过宽或过窄的规则。
第二种主要失效模式是告警疲劳：检查并甄别每一条触发的告警非常乏味。但 Claude 不会像人类一样疲劳。
Claude 会监控每个告警频道中的所有相关告警，并按照根目录 oncall.md 文件里的标准，判断问题能否等到第二天早上处理，还是必须立即呼叫值班人员。例如，在通过数据分析完成规则调优后，文件中可能会出现这样的规则：“如果错误率超过 2%、持续时间超过 5 分钟，并且当前不是已知的部署窗口，就呼叫值班人员；否则将其写入 lessons.md。”
Claude 值班告警流程还可以通过另外两种方式触发：
- CI 团队成员可以直接在值班频道中报告问题，就像开头提到的 44 个测试消失事件。
- 公司中的任何人都可以通过内部页面创建事故。如果事故被标记为 CI 基础设施事故，系统就会为其创建一个 Slack 频道，我们的值班 Claude 会接手处理。
这里的关键结论是：告警流程是确定性的，而值班升级既包含确定性路径，也包含智能体式路径。
分诊
让 Claude 过滤告警噪声是一回事，但真正节省时间的是调查过程。事故创建后，Claude 发布第一份基于证据的分析所需时间中位数为 14 分钟；在最快的案例中，它会在 4 分钟内就在首份报告里指出根本原因。
当某条告警升级为事故时，Claude 往往已经在我们的 Slack 频道中准备好一项有证据支撑的假设，供我们审查。Claude Tag 会启动一套动态工作流：一个编排智能体拉起多个执行子智能体，分别调查每项依赖和每个事实来源。
对我们而言，这些来源包括 Grafana、日志存储、PagerDuty、GitHub、Kubernetes 和 Slack 事故频道——它们全部通过 MCP Connectors 接入。Claude 可以并行追踪多条线索，从而帮助缩短 MTTR（平均恢复时间）。
各执行智能体会把调查结果报告给编排智能体；后者再综合这些信息，以连贯的情况报告（SITREP）呈现出来。
编排智能体和执行智能体并不是在毫无方向地搜索。它们由一项调查技能引导，而每一类错误还对应着更详细的 Markdown 参考文件。
例如，我们为“影子流量结果分歧”类错误编写了一项 617 行的调查技能，其中编码了我在一次典型调查中会执行的每个步骤。我是在某次事故期间，与 Claude 逐轮协作排查问题，然后让它根据这段经历生成该文件的。
lessons.md 同样会指导 Claude 进行故障排查。这个 Markdown 文件持续记录我们解决过的每起事故：发生了什么、根本原因是什么、如何修复，以及有哪些值得记住的坑。Claude 会自动向其中追加内容。每次新调查开始前，它都会先读取这个文件，因此它提出的第一个假设，会优先参考近期发生过的事情。
如果同一种模式反复出现，我们就会把它提升为调查技能本身的一部分。我最喜欢的一条记录，是 Claude 针对我写下的：我曾在查看指标之前，先根据配置文件作出了假设。如今，lessons.md 中写着：“先查询数据，再提出理论。配置告诉你什么可能出错；指标告诉你什么确实出了错。”
即便具备这些工具和上下文，Claude 也不总能第一次就判断正确。人的直觉与经验依然重要。Claude Tag 让团队能够以“多人协作模式”排查事故：我们中的任何人都能实时引导调查，或补充新的假设，共同解决问题。
为清晰起见，根据一次真实对话重新制作。
解决
如果 Claude 能升级处理并排查告警，它是否也能直接修复问题？不同团队的答案会有所不同，下面是我们的做法。
我们团队的大多数部署都位于功能标志之后。我在 Claude Code 中创建了一个独立智能体，它使用我的权限，能够在这些功能标志后执行渐进式部署。
发布流程的第一阶段通常包括：由 Claude 管理金丝雀流量、监控问题，并自动提高或降低某项功能标志的启用比例。这部分内容完全可以单独写成一篇文章，因此这里不再展开。
Claude Tag 还会通过以下方式帮助团队解决问题：
- 告诉我们是否需要排空 Kubernetes 集群的某些区域，或将其标记为不可调度。
- 指导我们如何扩容部分基础设施，以应对需求激增。虽然这种情况并不常见，但当 Claude 直接给出可执行的缓解措施时，非常有帮助。
- 最常见的是，以 PR 的形式提供修复方案，供值班人员审查、合并和部署，从而快速解决问题。
验证、沟通与交接
Claude 会使用许多与调查阶段相同的 MCP Connectors 和工具，验证修复是否按预期生效。作为 oncall.md 长期指令的一部分，它还会把事故复盘写入 lessons.md，并为交接情况报告准备内容。
为了跨多起事故传达完整情况，我们创建了一个名为 ci-weather 的智能体。它会汇总每个事故 Slack 频道的信息、构建指标、合并队列统计和部署延迟，然后向一个公司内所有人都能查看的公共频道发布一份“新闻编辑部风格”的报告。现在，当工程师想判断是否应该暂停合并，或者想知道“CI 到底出了什么问题”时，可以直接查看这个频道，而不必再来询问我们。
坦白说，我们反复迭代了几次报告格式。Claude 可以一次性生成一项用于编写状态报告的技能，但真正决定报告是否易读的，是团队特有的审美与偏好。这是人与人之间的沟通问题，不是管道连接问题。
最后，Claude 会在 lessons.md 中为自己记录日志，而我们也希望每周一为人类生成交接报告。Claude 会生成每日和每周摘要，使下一位团队成员能够从前任停下的位置继续工作。
从监控事故，到监控事故响应系统
与 2021—2025 年相比，我们的软件工程师目前平均每季度交付的代码量增长到了原来的 8 倍。与此同时，我们仍然保持着很高的质量门槛：每个 PR 都有一位明确指定的人类负责人；每项变更都必须经过批准才能合并；每项变更都要通过同一套 CI 检查关卡。但要跟上智能体式编程的速度，唯一的办法就是采用智能体式 CI。
Claude 接手了我工作中那些乏味的部分——下班后的突发打扰和事故沟通——让我能够专注于真正能提高系统可靠性的中长期架构改进。
我们所构建系统中最棒的一点，是它没有让人感到支离破碎。我们的值班流程原本就在 Slack 中；现在，Claude 只是加入了这个频道。
开始使用：
- 你需要 Claude Team 或 Claude Enterprise 方案。
- 组织所有者需要通过 Claude Tag，把 Claude 添加到值班 Slack 频道。
- 组织所有者还需要协助 Claude 连接值班 Slack 频道中的适当连接器、GitHub 仓库，并配置 Claude Code Remote。
- 将 Claude 添加到事故频道，并指示它监控事故、立即进行分诊。
本文由 Anthropic 技术人员 Sachin Malhotra 撰写，Anthropic 员工 Michael Segner 参与贡献。