Anthropic 把 Claude Tag 放进值班表，CI/CD 故障 median 14 分钟被定位

你有没有凌晨两点被 PagerDuty 吵醒的经历？

我有过。那次是一个依赖服务的超时阈值被改错，整条链路开始熔断。人爬起来、开电脑、翻日志、找同事、回滚，前前后后折腾了四十多分钟。最后发现，真正花在定位上的时间其实不到五分钟，其余全在上下文切换和找人确认。

所以当 Anthropic 放出那组数字时，我是真的愣住了，他们把 Claude Tag 放进 CI/CD on-call 值班表，作为故障的一线响应者。事故发生后，Claude 发布首份基于证据的分析，中位时间 14 分钟。最快一次，3 分钟内就验证完修复并确认错误率回到基线。

14 分钟。不是幻觉，不是 demo，是真实跑在 Anthropic 内部 CI 管道上的 Agent。

这不是一个客服机器人

很多人第一反应是，又是营销话术吧？让大模型回回工单那种？

坦率的讲，我一开始也这么想。但仔细看完 Anthropic 那篇博客，发现它跟客服机器人完全是两码事。

Claude Tag 在这里干的活，是 on-call 工程师的第一响应。事故发生后，它要做的是这几件事，

从 Slack 事故频道读取告警和上下文；
调用 Datadog 或 Grafana 查看指标、日志和追踪；
打开 GitHub，读取相关代码、PR、近期提交和 CI 运行记录；
基于证据写出一份事故分析；
如果需要，给出修复建议或验证修复是否生效。

说得更直接点，它不是一个回答问题的聊天窗口，而是一个被授权访问生产环境只读数据、能在事故发生后自主调查的 Agent。

这个区别非常关键。过去的 AI 应用大多是「你问一句，我答一句」。而 Claude Tag 在 CI/CD 场景里是「事件驱动」的。告警来了，它自己开始跑，自己决定查什么，自己产出结论。

你想想看，这不就是我们在 LangGraph 里画过无数次的那个循环吗？状态节点、工具调用、观察、行动、再评估。Anthropic 只不过把它真的挂到了生产环境的告警通道上。

为什么 CI/CD 是最适合 Agent on-call 的第一战场

你可能会问，为什么偏偏是 CI/CD？

我觉得这个选择特别妙。CI/CD 故障有几个特别适合 Agent 的特点。

第一，数据结构化程度高。构建失败、测试失败、部署失败，日志、指标、追踪、代码变更、PR 描述，这些信息几乎都是文本或可查询的。Claude 最擅长的就是读文本、找关联、做推理。你让它去排查一个网络抖动导致的偶发超时，它可能会抓瞎；但你让它看一段失败的单元测试和对应的代码提交，它的表现会好得多。

第二，失败场景相对收敛。CI/CD 的问题虽然五花八门，但大致逃不出几类，代码提交引入的回归、依赖版本冲突、环境配置漂移、权限或密钥过期、测试 flaky。这些模式的重复度很高，Agent 完全可以通过历史案例学习怎么做初步分类。

第三，试错成本低。CI/CD 故障通常不会直接影响真实用户。生产环境的 on-call 让人紧张，是因为一旦判断失误可能直接造成资损或服务降级。但 CI 管道失败，最坏的情况也就是发布阻塞，大不了重新跑一遍。这个容错空间让 Anthropic 敢把 Agent 放上来练手。

第四，人有明确的角色可以保留。Claude Tag 做的是「一线响应」，不是「最终决策」。它出分析报告，人类工程师做判断和修复。这种分工既发挥了 Agent 的速度优势，又保留了人的最终责任。

所以 Anthropic 这一步，不是冒进，而是精明。他们选了一个数据丰富、场景收敛、容错空间足够、还能让人类保底的战场。

证据链，而不是猜谜

那 Claude Tag 到底是怎么做到 14 分钟定位的？

关键在它的工作方式不是「看日志然后蒙一个原因」，而是建立一条证据链。

Anthropic 提到，Claude 会基于证据（evidence-based）发布分析。这四个字听起来普通，其实含金量很高。大多数工程师排查问题时，脑子里会同时闪过十几个假设，是不是这次提交改了配置？是不是依赖升级破坏了兼容性？是不是测试环境网络不稳定？

人厉害的地方在于能凭直觉快速排除。但直觉也有代价，有时候你会被先想到的假设带偏，花半小时盯着一个错误方向。

Claude Tag 的做法更像是系统性的穷举。它会先把告警和最近变更关联起来，然后逐个检查可能的证据。Slack 里有没有人提到类似问题？GitHub 上这次失败的 PR 改了哪些文件？Datadog 里错误率是从哪个时间点开始跳的？这些证据被收集起来后，Claude 再写成一个结构化的分析。

这种「先收集证据，再下结论」的流程，对复杂 CI 故障尤其有用。我见过太多事故，最后根因都不是最先想到的那个。Agent 不会因为面子或直觉而坚持错误方向，它只会根据证据调整结论。

不过这里也有一个容易被忽略的点，证据的质量决定了分析的质量。如果日志没打全、指标命名混乱、PR 描述写成「fix bug」，那 Claude 再强也查不出什么。Anthropic 能把 Agent 跑起来，前提是他们的工程数据本身就有一定治理水平。

所以这件事给我们的启示，不只是「买个 Claude 就能省一个 SRE」。更深层的问题是，你的 CI/CD 数据是不是足够透明、可追溯、可查询？如果不是，Agent 来了也只能抓瞎。

工具链是 Agent 的「手」，而不是模型参数

另一个让我印象深刻的细节是，Claude Tag 并不依赖一个更强大的基础模型版本。它用的是 Claude Tag，也就是 Anthropic 的 Agent 框架，加上一系列工具权限。

这些工具包括，

Slack 频道访问，能读取事故相关的对话；
Datadog 和 Grafana 的查询权限；
GitHub 的代码、PR、Actions 记录读取；
一个被称为「skills files」的知识库。

这个组合非常有意思。它说明 Agent 的能力边界，越来越不取决于模型本身有多少参数，而取决于它能调用多少工具、能访问多少上下文、能记住多少组织知识。

我在做 LangGraph 项目时也有类似感受。你给一个 Agent 配好工具、状态管理和记忆，它就能完成很多看似需要「智能」的任务。但反过来，如果工具接口设计得烂、状态切分得乱、记忆检索不到，再大的模型也没用。

Anthropic 这次公布的「通用设置套件」也印证了这个趋势。他们不只是开源一个 prompt，而是把整套工具接入、权限配置、Slack 集成、GitHub skills 的部署方式都放了出来。有一件事已经很清楚了，未来评估一个 Agent 方案的好坏，可能不是看它用了哪个模型，而是看它的工具生态和集成深度。

我跟你说，这对做工程的人来说其实是好事。模型能力正在快速商品化，真正建立壁垒的反而是你的工具链和数据资产。

skills files 才是隐形护城河

我想多说几句 Anthropic 提到的 skills files。

这个名字听起来不性感，但它可能是整个系统里最关键的一块。skills files 不是 prompt，不是微调权重，而是组织内部沉淀下来的「操作记忆」。它可能包含常见故障的排查路径、特定服务的依赖关系、历史事故的根因记录，甚至是团队内部的命名约定和约定俗成的检查顺序。

这些东西原本散落在 Confluence、Notion、Slack 频道、老员工的脑子里。Agent 来了之后，它们第一次有机会被结构化成可调用、可检索、可组合的知识单元。

我跟你说，这才是真正的护城河。模型大家都能买到，但你的事故处理经验、你的代码库上下文、你的监控命名习惯，这些是经过无数次失败才沉淀下来的东西。Agent 能不能在你的组织里跑得好，很大程度上取决于这些隐性知识有没有被整理出来。

反过来看，如果一个团队连一份像样的 on-call 手册都没有，那上了 Claude Tag 也只会是一场灾难。Agent 会问 Datadog，但 Datadog 里的指标名可能连人都要猜半天。它会读 PR，但 PR 描述可能全是「update」和「fix」。它会翻 Slack，但 Slack 里可能全是表情包和「我看看」。

所以 Agent on-call 倒逼的不只是技术升级，更是工程文档化和知识管理。这是个好消息，也是个坏消息。好消息是，一旦你把这部分做好了，Agent 能放大你的能力。坏消息是，很多人的组织能力根本配不上这套系统。

14 分钟不是终点，而是新的起点

Anthropic 披露的数据确实漂亮，14 分钟中位时间，最快 3 分钟验证修复。但我们也得冷静一点。

这些数字是在 Anthropic 自己的环境里跑出来的。他们的 CI 规模、日志规范、工具集成度、告警质量，跟普通公司很可能不是一个量级。你把同样的 Claude Tag 丢进一个日志靠 grep、PR 描述靠猜、监控全靠人工盯屏的团队，效果会大打折扣。

另外，CI/CD 故障只是事故响应的一个子集。真正让人头疼的生产事故，往往涉及跨系统推理、业务上下文、甚至是组织沟通。Agent 在这些场景里的表现，还需要更多验证。

还有一个长期问题，当 Agent 越来越深地参与运维决策，责任边界怎么划分？如果 Claude Tag 给出了一条错误建议，导致修复方向走偏，责任算谁的？是模型厂商、是部署团队、还是最终拍板的人？

这些问题现在没有标准答案。但我觉得，Anthropic 这次发布最大的价值，不是证明 Agent 已经可以取代 SRE，而是证明 Agent 已经可以在一个受控、可观测、可回滚的环境里承担真实工作。

这是一个从 demo 到 production 的跨越。

SRE 会被替代吗？我的看法是不会，但工作会变

每次这种新闻出来，评论区都有人问，SRE 是不是要失业了？

我跟你看法不一样。Claude Tag 不是来抢饭碗的，它是来改变分工的。

你想想，一个 SRE 的时间都花在哪？很大一部分其实是「信息收集」，翻日志、查监控、比对版本、找相关 PR、问 Slack 里谁最近改了这块。这些工作重要，但不性感。它们消耗大量认知资源，却不需要太多创造力。

Agent 最擅长干的就是这类活。它不会累，不会漏看一条日志，不会因为凌晨两点脑子不清醒而忽略一个关键指标。它可以在事故发生的第一秒就开始收集证据，等人类工程师进场时，桌子上已经摆着一份整理好的分析报告。

那人类做什么？人类做判断、做决策、做沟通、做根因复盘。Agent 告诉你「错误率从 02:17 开始跳，对应 PR #4821」，人类来决定要不要回滚、怎么回滚、通知哪些团队、要不要启动事故流程。这些判断涉及业务上下文、风险权衡和组织协调，短期内 Agent 还做不了。

所以更可能的未来是，SRE 的人数不一定减少，但他们会从「翻日志的人」变成「定义排查策略的人」。他们不再是被告警牵着走，而是去设计 Agent 的 skills files、优化工具接口、设定升级策略和人工介入的触发条件。

这其实是好事。SRE 最痛苦的部分被自动化了，最有价值的部分被放大了。

我们能从今天开始做什么

说了这么多，回到一个更实际的问题，普通团队能从这件事里学到什么？

第一，先别急着买 Claude。Agent on-call 的效果，80% 取决于你的工程基础，而不是模型。如果你们的 CI 日志还是一团糟，告警没有统一格式，PR 描述没人认真写，那上了 Agent 也只是多了一个会读垃圾数据的观众。

第二，从整理知识开始。把你们最常见的 10 种 CI/CD 故障列出来，每种故障写一份排查清单。这就是最原始的 skills files。把它放进 Agent 能访问的地方，哪怕只是一个 Markdown 文件，也比什么都没有强。

第三，给工具接口做标准化。Datadog、Grafana、GitHub、Slack，这些工具的 API 权限能不能被 Agent 安全地调用？查询参数是不是清晰？返回的数据是不是人类可读？这些细节决定了 Agent 能不能真正用起来。

第四，先拿低风险场景试水。不要一上来就让 Agent 处理核心支付链路。可以从测试失败分析、构建失败定位、文档缺失提醒这种低风险高频率的任务开始，逐步建立信任。

最后，保持人的最终决策权。Agent 可以快、可以全、可以不眠不休，但它不应该有回滚生产环境的权限。至少现在不应该。

它真正改变的是什么

回到开头那个凌晨两点的故事。

如果当时有一个 Agent 能在 3 到 14 分钟内告诉我，「错误率从 02:17 开始跳，对应 PR #4821 修改了超时阈值，建议回滚并重新跑测试」，我会省掉大量时间。我可以更快地进入修复状态，而不是在混沌中摸索。

这就是我觉得 Anthropic 这件事最打动人的地方。它没有吹嘘通用人工智能，也没有说 SRE 要失业了。它只是把 Agent 放进一个具体、有限、有明确输入输出的工作流里，然后给出了真实的数据。

而这个工作流，恰好是很多技术团队每天都在经历的痛点。

所以不管你是做 LangGraph、Spring Cloud、DevOps 还是 MLOps，这件事都值得你多看两眼。Agent 的形态正在从「聊天工具」变成「工作流里的一个节点」。这个节点可以读 Slack、查监控、翻代码、写分析，然后等人来做最终决策。

它不完美。它需要配套的数据治理和工具集成。它需要明确的责任边界。

但它已经进来了。

14 分钟这个数字，可能会很快被压缩到 10 分钟、5 分钟，甚至更短。而到了那个时候，我们不会再问「Agent 能不能处理 CI/CD 故障」，只会问「我们的 CI/CD 数据准备好被 Agent 处理了吗」。

这才是 Anthropic 这次发布给我最大的冲击。

不是模型更强了。而是 Agent 开始认真地、可量化地，接管我们曾以为只有人才能做的工作了。

这种接管不是替代，而是重塑。它会把工程师从重复、低效、反人性的信息收集里解放出来，让他们把认知资源花在最需要判断力和创造力的地方。它也会倒逼组织把散乱的知识沉淀成结构化的资产，让工程文化从「靠人扛」转向「靠系统扛」。

下一次 PagerDuty 在凌晨响起时，我希望迎接我的不是一片空白和满屏日志，而是一份已经整理好的、基于证据的分析。哪怕它只是告诉我从哪开始看，也值了。

14 分钟只是个开始。真正的变化，是我们开始相信 Agent 可以在值班表里占一个位置了。