目录一、为什么这件事比“AI 自动修 Bug”更重要一真正的变化发生在工作流1、值班工作的本质是缩短“获得可靠判断”的时间2、事故处置的结束条件不是“代码变了”而是“系统恢复了”二“44 个测试消失”案例透露出的三个工程信号1、异常可能表现为“没有发生”2、配置面与数据面必须交叉验证3、可逆性决定动作边界二、Claude Tag 的完整运行模型四项能力与一条事故闭环一Memory记住的不只是答案而是组织经验1、事件记忆维持当前事故的共同事实2、lessons.md低成本、可累积的经验账本3、Investigation Skill把偶发经验升级为可审查程序3.1 一个可复用调查 Skill 应包含什么3.2 经验晋升要有门槛二Connections / Access连接数量不是能力证据闭环才是能力1、用能力绑定替代供应商绑定2、证据链接必须成为报告的强制字段3、最小权限应细化为“最小证据访问”三Schedules从被动问答变为有节奏的持续工作1、调度应由事件门控而不是无脑轮询2、每个计划任务都要有退出条件四Instructions把组织判断写成可审查的控制面三、事故生命周期把 Agent 放在正确的位置一Detection确定性告警仍然是第一道防线1、Agent 适合补足规则难以覆盖的灰区2、关键寻呼必须有确定性旁路二Triage多 Agent 并行的价值在“分证据域”不在“多投票”1、合理的拆分方式2、主 Agent 必须处理冲突而不是简单多数表决三Resolution建议可以自动化生产决策不能被偷渡1、用风险分层决定自动化深度2、审批界面要展示决策所需信息四Verification恢复必须由观测证明1、验证对象应在处置前写清楚2、只有人能关闭事故五Communication 与 Handoff状态报告本身就是可靠性设施四、真正的护城河证据化知识飞轮一从聊天记忆到“可审查的外部记忆”1、知识对象需要不同的变更权限2、错误答案必须反向修复产生它的系统二历史回放给排障手册做离线评测1、回放集必须防止信息泄漏2、评分不应只看是否猜中根因三Shadow 模式先证明辅助价值再获得流程权重五、与传统自动化的关系Agent 不是替代规则而是填补规则之间的空白一脚本、工作流与 Agent 各自擅长什么1、Agent 应调用窄工具而不是持有宽泛 Shell2、失败应可见、可恢复二从告警疲劳到“调查疲劳”的新风险六、企业落地不能照搬连接器清单要重建控制系统一第一阶段用两周做“可行性审计”而不是直接接生产1、盘点数据与流程成熟度2、建立能力映射与缺口表二第二阶段历史挖掘、人工访谈与知识建模1、先从真实事故中提炼故障家族2、只让人回答无法从数据挖掘的问题三第三阶段离线回放与 Shadow 运行1、建议的最小评测表2、设置明确的退出和回退条件四第四阶段有限上线与分层授权七、必须正视的局限模型错误只是风险清单的第一项一可观测性不成熟时Agent 会把噪声组织得更像答案1、建立“拒绝下结论”的能力2、防止自动化偏见二知识可能过期、污染或被提示注入三成本、延迟和可用性本身会成为新的 SLO1、把“快速检查”和“深度调查”分层2、为连接故障设计降级路径四指标若被当成目标会诱发错误优化八、进一步推演Agent 将如何改变 SRE 与平台工程一值班工程师将从“控制台操作员”转为“证据与风险编辑”1、排障能力不会消失但训练方式会改变2、平台团队将负责“操作知识供应链”二可观测性将从“给人看的面板”升级为“给人和 Agent 共用的证据 API”1、每个关键健康信号都应可机器解释2、变更事件要成为一等公民三组织学习速度将成为 Agentic 运维的核心竞争力九、一套可直接采用的设计原则一十条原则二最小可行架构1、SITREP 最小字段2、lessons.md 最小字段十、结语真正能值班的 Agent是被制度约束的协作者可参考的文章与资料干货分享感谢您的阅读Anthropic 在 2026 年 8 月 18 日公开了 Claude Tag 参与内部 CI/CD 值班的实践。最吸引眼球的案例是约 44 个测试突然停止执行Claude 将异常与当天开启的 Feature Flag 关联起来人工回滚后又在约 3 分钟内验证跳过规则消失、错误率回到基线。然而真正值得研究的并不是“AI 找到了一个 Bug”而是 Anthropic 把 Agent 放进了有告警、有权限、有升级、有验证、有交接、有复盘的生产流程。本文在通读原文与官方参考实现 anthropics/oncall-kit 的基础上重构其完整方法将 Agent 定位为证据驱动的第一响应者以 Memory、Connections / Access、Schedules、Instructions 四项能力构成运行底座以确定性告警守住入口以多 Agent 调查提高并行度以人在回路控制高风险动作并用 lessons.md、调查 Skill、历史回放和 Shadow 运行形成可审计的学习闭环。文章进一步讨论了中国企业落地时应增加的权限分层、数据治理、评测体系、组织机制和成熟度路线图。Agentic On-call 不是“给大模型接几个工具”而是一套新的运维控制系统它优化的首先不是自动修复率而是证据获取速度、诊断质量、沟通一致性与组织学习速度。一、为什么这件事比“AI 自动修 Bug”更重要一最大的变化发生在工作流过去两年软件工程领域对 Agent 的讨论常被“能否独立写代码”“能否自动提交 PR”主导。这样的评价方式很直观却容易忽略生产环境最重要的一层事故响应不是一道静态编程题而是一条跨系统、跨角色、跨时间的协作链。一次 CI/CD 故障可能从测试平台发出告警牵连日志、指标、代码提交、部署记录、Feature Flag、Kubernetes 状态和 PagerDuty 事件根因未必在报错最明显的地方修复也未必等于恢复恢复更不等于事故已经结束。Anthropic 的实践之所以具有代表性正是因为 Claude Tag 不再等待工程师把上下文整理好再提问而是作为 Slack 值班频道里的“第一响应者”持续参与事件。它接收告警或人工报告读取相关证据形成初步判断把可执行建议交给值班工程师随后继续观察修复是否生效并将经验写入可复用的知识载体。根据 Anthropic 原文Claude Tag 在近期有首份情况报告的事故中都承担了首份报告撰写工作通常在 15 分钟内给出第一次分析其首份有证据支撑的分析中位数约为 14 分钟最快案例在 4 分钟内便指出根因。Anthropic 原文这意味着评价标准发生了变化。一个只会回答“这段堆栈可能是什么问题”的模型是故障排查助手一个能在正确时间被触发、访问正确证据、遵循团队规则、标记不确定性、请求人工决策、监控修复结果并完成交接的系统才开始接近值班角色。两者的差异不主要在推理分数而在系统工程。1、值班工作的本质是缩短“获得可靠判断”的时间事故响应常用 MTTD、MTTA、MTTR 等指标描述发现、响应与恢复速度但大模型进入值班流程后最值得单独度量的是“Time to Evidence-grounded Hypothesis”即从事故开启到出现首个可被证据验证的假设所需时间。因为人在半夜被叫醒后真正昂贵的阶段往往不是执行一个回滚命令而是寻找正确入口它是测试选择逻辑、依赖服务、基础设施容量、凭据过期还是刚刚上线的配置Agent 的第一价值是把这段上下文拼装工作压缩。它不必替人做最后决定也能显著降低工程师在多个控制台之间切换、复制链接、对齐时间线和重复解释的成本。如果首份报告能回答“发生了什么、影响多大、证据在哪里、最可能的解释是什么、下一步该查什么”值班工程师就从信息搬运者变成了判断者。2、事故处置的结束条件不是“代码变了”而是“系统恢复了”开发型 Agent 容易把“生成补丁”当作任务完成On-call Agent 则必须区分动作、结果和关闭。回滚 Feature Flag 是动作跳过规则消失和错误率回到基线是结果工程师确认影响解除并关闭事故才是结束。Anthropic 案例中Claude 在人工回滚后继续监控并于约 3 分钟后确认恢复价值恰恰体现在“修复后验证”没有被遗忘。这也是本文最重要的判断之一Agentic On-call 的最小闭环不是“告警—修复”而是“告警—调查—决策—执行—验证—沟通—学习”。任何缺少验证或责任闭环的自动化都会把速度优势转换为新的操作风险。Claude Tag 类系统的正确定位Agent 扩展人的调查带宽但不模糊高风险决策责任。二“44 个测试消失”案例透露出的三个工程信号1、异常可能表现为“没有发生”传统告警擅长检测错误率上升、延迟增加、资源耗尽却不总擅长发现某些本该发生的事情没有发生。测试不再执行属于“负空间异常”没有失败日志反而是测试数量、执行路径或覆盖范围悄悄减少。要识别这类问题系统必须知道正常基线并能把当前观测与配置变化、发布事件进行关联。2、配置面与数据面必须交叉验证Feature Flag 表明“什么可能改变”测试指标和跳过规则表明“实际上发生了什么”。如果只读配置Agent 可能把相关性误判为因果如果只看指标又可能无法定位触发源。Anthropic 文中记录的一条经验是先查询数据、再形成理论配置说明可能出错的路径指标说明真正发生的现象。这个次序应当被固化为排障规则而不是依赖模型临场发挥。3、可逆性决定动作边界同样是修改系统回退一个当天开启、影响边界清楚的 Feature Flag与直接修改数据库、扩缩生产集群或合并复杂代码风险完全不同。成熟的 Agent 系统不应采用“能不能调用工具”的二元权限观而应同时考虑动作可逆性、爆炸半径、证据强度和当前紧迫度。即便技术上能执行也可能只适合生成操作方案、PR 或待审批命令。二、Claude Tag 的完整运行模型四项能力与一条事故闭环一Memory记住的不只是答案而是组织经验Anthropic 将 Memory 列为值班 Agent 的基础能力。这里的“记忆”至少分为三层频道中的短期事件上下文、仓库里可审查的结构化经验以及被提升为调查 Skill 的稳定方法。三层的可信度、生命周期和治理方式不同不能混成一个无限增长的聊天记录。1、事件记忆维持当前事故的共同事实事件记忆需要保存事故编号、开始时间、影响范围、已验证事实、待验证假设、已经执行的动作、当前负责人和下次检查时间。它的目标不是“让 Agent 记得更多”而是避免多人、多轮对话后出现事实漂移。每条关键事实最好附带来源链接、观测时间和有效期例如“错误率为 2.8%”若没有时间窗口和仪表盘查询就不能安全地被后续结论引用。2、lessons.md低成本、可累积的经验账本Anthropic 原文把 lessons.md 描述为每次已解决事故的持续记录包含发生了什么、根因、修复方法和值得记住的注意事项每次新调查先读取它Agent 因此能从近期模式出发。参考实现进一步强调文件中的关键知识高于不可审查的频道记忆并由 Agent 追加、由人定期修剪。oncall-kit README但 lessons.md 不是越长越好。未经结构化的长文件最终会变成新的噪声源。更可靠的字段包括症状指纹、影响面、证据链接、根因分类、缓解动作、验证指标、误导性线索、适用服务、首次记录时间、最近验证时间、可信度和晋升状态。这样才能支持检索、去重、过期检查与质量评估。3、Investigation Skill把偶发经验升级为可审查程序当某一故障模式反复出现单条 lesson 应被提升为 Investigation Skill 或其参考文件。Skill 的本质不是一段“万能提示词”而是一份具备入口条件、证据顺序、停止条件、分支逻辑和升级规则的排障手册。Anthropic 文中提到一个针对 shadow divergence 问题的调查 Skill 达到 617 行并来自工程师与 Claude 在真实事故中的逐步排查过程。这说明高质量 Skill 更像可执行的运维知识而不是风格化指令。3.1 一个可复用调查 Skill 应包含什么第一明确触发症状与排除条件避免拿错手册第二规定先查哪些一手数据防止模型从配置或历史故事过早推断第三为每个假设定义支持证据与反证第四标出哪些查询安全、哪些动作必须审批第五给出报告模板、验证窗口和升级对象第六记录手册来源及适用版本使变更可审计。3.2 经验晋升要有门槛一次事故可能只是偶然组合直接写入长期规则会造成过拟合。参考实现使用 provenance tag 标示一个结论由多少历史事故支持并允许低可信结论保留“未验证”状态。企业可以进一步规定单次经验进入观察区跨两次相似事件后进入候选规则经过负责人评审和历史回放后才进入正式 Skill。这样既保留快速学习也避免错误被自动固化。二Connections / Access连接数量不是能力证据闭环才是能力Claude Tag 通过 MCP 等连接方式访问 Grafana、日志系统、PagerDuty、GitHub、Kubernetes 与 Slack。表面上看这是“把工具都接上”实质上Agent 必须跨越不同数据语义建立同一事故的时间线与因果候选。1、用能力绑定替代供应商绑定oncall-kit 提出 STACK.mdSkill 只依赖“指标源、日志源、代码托管、寻呼系统”等抽象能力STACK.md 再把能力映射到团队真实使用的 Grafana、Datadog、PagerDuty、Opsgenie 等工具。这样更换供应商时不必重写所有排障手册也能明确缺少某种连接会损失什么能力。这一设计值得企业直接借鉴。工具名不应散落在每份 Skill 中连接配置也不应隐含在 Agent 平台后台。能力映射文件应可版本控制至少包含连接名称、只读或可写、数据范围、身份主体、查询限制、敏感字段规则、负责人和最近验证时间。2、证据链接必须成为报告的强制字段参考实现要求首份诊断中的每项重要主张都链接到背后的日志行或仪表盘面板。这样做不仅便于工程师复核也抑制模型把合理猜测写成事实。一个专业的 SITREP 应明确分开“事实、推断、建议”事实附证据和时间戳推断列出置信度及反证建议写明风险、可逆性和审批人。3、最小权限应细化为“最小证据访问”很多团队谈最小权限时只讨论读写而日志和指标读取本身也可能泄露用户数据、密钥、内部拓扑或员工信息。对 Agent 而言更恰当的原则是最小证据访问只允许读取完成当前职责所需的数据范围并在连接层做字段脱敏、时间窗口限制、查询成本限制和审计记录。默认只读是底线不是治理终点。Memory、Access、Schedules、Instructions 共同构成运行底座权限、证据与人工审批贯穿四层。三Schedules从被动问答变为有节奏的持续工作Schedules 让 Agent 知道何时重新工作。事故处置不是一次性查询修复后要等待指标稳定未关闭事件要检查停滞值班交接要按日或按周生成经验手册还要定期回放验证。Anthropic 原文提到可在频道中用自然语言配置例行任务例如每周一固定时间生成 CI 交接。1、调度应由事件门控而不是无脑轮询参考实现的可选 weather 机制强调“安静是常态”每个周期先做低成本判断只有新事故、主干阻塞或恢复、健康等级变化、状态或 ETA 变化、停滞检查等事件门被触发时才向频道发布。持续高频全量调查会造成费用、限流、噪声和注意力稀释最终重演传统告警疲劳。2、每个计划任务都要有退出条件“继续监控直到恢复”听起来合理但如果没有基线、最大时长、采样间隔和升级路径就可能永不结束。一个可靠的验证任务应明确观察哪个指标、基线如何定义、连续多少个窗口满足才算恢复、何时判定无效、超时通知谁、是否允许调整频率。四Instructions把组织判断写成可审查的控制面Instructions 决定 Agent 如何行动。ONCALL.md 负责分页阈值、路由、严重度和升级规则Skill 负责如何调查与报告Routine 负责何时、在哪里运行lessons.md 保存事件经验。参考实现给出一条非常实用的划分如果一条规则决定“何时或在哪里”它属于 Routine如果决定“如何做”且变更前应评审它属于仓库文件分页阈值属于政策应进入 Git。这套划分解决了 Agent 系统常见的“提示词治理缺失”重要规则不再藏在某个管理员的配置界面或一次聊天里而是像代码一样经过 PR、审查、回滚和责任归属。模型可以提出修改但不能悄悄改变组织政策。三、事故生命周期把 Agent 放在正确的位置一Detection确定性告警仍然是第一道防线Anthropic 博文写道告警过程是确定性的而值班升级同时包含确定性与 Agentic 路径。参考实现说得更严格现有告警系统保持主检测器地位达到 page-tier 的告警直接寻呼人Claude 从不成为唯一检测器。两者并不矛盾Agent 可以观察告警、关联多个信号、提出新规则和过滤噪声但不能让非确定性模型成为关键事故的单点入口。1、Agent 适合补足规则难以覆盖的灰区新服务缺少足够历史数据固定阈值容易过宽或过窄多个低等级告警单独看都不严重组合起来却可能指向同一事故某个指标没有越过阈值但趋势与部署事件明显异常。这些场景适合 Agent 做关联、建议和二次分诊。2、关键寻呼必须有确定性旁路对于用户大面积不可用、数据完整性风险、安全事件等高严重度场景确定性规则应直接寻呼人并将同一事件交给 Agent 并行调查。这样即使模型不可用、连接失败或判断错误也不会阻断紧急响应。Agent 是增强路径不应成为不可见的串行依赖。二Triage多 Agent 并行的价值在“分证据域”不在“多投票”Anthropic 的编排 Agent 会启动多个执行子 Agent分别调查指标、日志、PagerDuty、GitHub、Kubernetes 和 Slack 事故频道再由主 Agent 汇总成 SITREP。并行机制可以缩短跨域搜索时间但前提是每个子任务有明确证据域和交付格式。1、合理的拆分方式指标 Agent 回答“异常从何时开始、影响哪些维度、是否与基线偏离”日志 Agent 回答“错误指纹、首发时间、上游下游关联”变更 Agent 回答“窗口内有哪些提交、部署、配置和 Flag 变化”基础设施 Agent 回答“容量、调度、网络、依赖是否异常”历史 Agent 回答“过去是否出现过相同症状及当时的验证方法”。它们提交的是证据包而不是各自写一篇完整结论。2、主 Agent 必须处理冲突而不是简单多数表决多个子 Agent 得到不同假设很正常。主 Agent 应建立候选假设表为每个假设列出支持证据、反证、缺失证据、下一步最小查询和风险。根因判断不能靠“多数 Agent 都这么说”因为它们可能共享同一错误上下文。高质量编排关注证据独立性与信息增益。子 Agent 按证据域并行调查主 Agent 负责冲突消解、置信度管理与统一汇报。三Resolution建议可以自动化生产决策不能被偷渡Anthropic 内部还有具备工程师权限、负责 Feature Flag 渐进发布的独立 Agent但公开的 oncall-kit 采取更保守的边界不自动缓解不直接操作 Flag它可以提供可复制的灰度步骤、打开回滚 PR、说明每一步等待时间和中止指标但执行是人的动作。这个区别非常重要。博客描述的是特定组织内部、特定权限模型下的实践参考实现面向外部团队必须选择可迁移的安全下限。1、用风险分层决定自动化深度可以把动作分成四级。L0 是只读查询和报告可自动执行L1 是创建草稿、Issue、PR 或待审批命令不改变生产状态L2 是可快速回滚、爆炸半径受控的动作例如在预先批准的范围内调整非关键 Flag需要显式审批或双人确认L3 是不可逆或高影响操作如数据迁移、删除资源、全量流量切换应由人工执行并采用独立变更流程。2、审批界面要展示决策所需信息“允许/拒绝”按钮本身并不构成人在回路。如果审批人看不到证据、影响范围、替代方案、回滚步骤和验证标准他只是替系统承担责任。高质量审批包应回答为什么现在做、改什么、影响谁、如何撤回、多久验证、失败后升级给谁。四Verification恢复必须由观测证明验证阶段应回到最初定义事故的健康信号而不是只确认操作成功。例如回滚命令返回 200只能证明控制面接受了请求测试重新执行、错误率回到基线、队列延迟消退才证明用户或流水线体验恢复。验证还需要处理暂时反弹至少连续多个窗口稳定才能降低置信区间内的偶然性。1、验证对象应在处置前写清楚在执行修复前Agent 就应列出成功标准和失败标准。这样可以防止事后挑选对修复有利的指标也方便值班工程师判断是继续观察、回滚修复还是升级事故。2、只有人能关闭事故oncall-kit 的状态模型把 active、stale、mitigated、resolved 区分开。Agent 可以依据多项证据提示事件可能停滞可以观察 mitigated 状态是否复发但进入 resolved 的动作由人完成。这一设计保留了责任链也避免模型因短暂恢复而过早关闭事故。确定性告警负责可靠触发Agent 驱动调查与验证人负责缓解决策和最终关闭。五Communication 与 Handoff状态报告本身就是可靠性设施事故中最常见的浪费之一是不同人反复询问“现在是什么状态”“是否可以合并”“影响还在吗”。Anthropic 建立了名为 ci-weather 的 Agent聚合事故频道、构建指标、合并队列和部署延迟以新闻播报式格式向公共频道发布。团队因此能从统一入口了解 CI 健康而不是频繁打断值班人员。但报告自动生成并不等于报告可读。Anthropic 明确提到报告格式经过多次迭代因为可读性包含团队特定的表达偏好。一个好的交接报告应让没有参与前半段的工程师在几分钟内接手开放事故、当前影响、已排除项、剩余风险、下次检查、待决策事项、相关链接和责任人必须完整。四、真正的护城河证据化知识飞轮一从聊天记忆到“可审查的外部记忆”很多 Agent 项目把 Memory 理解为向量数据库或更长上下文但值班领域更关心记忆能否被审查、纠正、过期和追责。频道记忆便于连续对话却不适合作为分页阈值、路由规则或关键经验的唯一载体。参考实现因此把承重知识放入 Git政策由人修改Skill 由人评审lesson 可由 Agent 追加但由人修剪。1、知识对象需要不同的变更权限政策决定谁会被叫醒、何时升级必须由人通过 PR 修改调查手册决定如何查证可以由 Agent 提议、人审查事件经验可以自动追加但要有来源、可信度和保留期临时事故上下文则随事件关闭归档。把所有知识放在同一数据库、赋予同一写权限会让便利性吞噬治理能力。2、错误答案必须反向修复产生它的系统参考实现提出诊断错误时不只修正当前回答还要修正生成错误的 playbook。一次性误判可在事故线程中纠正重复误判意味着 Skill 或参考文件需要修改。这个机制把“模型偶尔会错”转化为工程可处理的问题找到错误来源修改知识跑回归测试再上线。二历史回放给排障手册做离线评测oncall-kit 的设置流程会从过去 30 到 90 天事故中挖掘模式但刻意保留 5 到 10 个 holdout 事故不参与手册生成验证阶段在新上下文中回放这些未见样本并按正确、部分正确、错误、有害等等级评分。通过门槛为至少 70% 的正确加部分正确且不能出现有害答案。这个数值不是通用行业标准却展示了正确方法上线资格来自证据而不是演示效果。1、回放集必须防止信息泄漏如果同一事故既被用于生成手册又被用于验证结果只是记忆能力而非泛化能力。企业应按时间或故障家族切分数据并保留“新服务、新依赖、新型组合故障”等高难度样本。每次重大 Skill 修改或基础设施变更后重新跑回放才能发现知识漂移。2、评分不应只看是否猜中根因更完整的评分维度包括证据引用是否正确、是否遗漏关键反证、是否提出高风险无审批动作、是否及时升级、是否给出可验证的成功标准、是否把隐私数据带入公开频道、报告是否便于接手。一个根因猜对但过程不可审计的 Agent不适合值班。三Shadow 模式先证明辅助价值再获得流程权重参考实现要求 Agent 先把诊断发到独立评审频道人在原有流程中照常处置。团队记录它的准确度、覆盖度、响应时间和危险建议达到质量门槛后再决定是否让其进入正式频道。两周只是强制复审点不代表自动毕业分页能力还要单独做 go/no-go 决策。这种渐进式上线避免了两种极端一是因为模型不完美而永远停留在实验室二是因为几个精彩演示就直接获得生产权限。Shadow 期的意义不是消除所有错误而是用真实分布测量错误类型并为组织建立可接受风险边界。事故事实先进入结构化经验经聚类、评审和历史回放后再晋升为调查 Skill。五、与传统自动化的关系Agent 不是替代规则而是填补规则之间的空白一脚本、工作流与 Agent 各自擅长什么确定性脚本适合输入清楚、步骤稳定、失败模式已知的任务例如重试失败 Job、查询固定仪表盘、执行预定义回滚工作流引擎适合跨系统编排和审批Agent 擅长在信息不完整时搜索、比较、形成假设和解释。最稳健的架构不是用 Agent 重写所有自动化而是让 Agent 选择、填充和解释经过验证的工具同时让确定性系统执行关键控制。1、Agent 应调用窄工具而不是持有宽泛 Shell与其给 Agent 一个能执行任意命令的生产终端不如提供语义明确的工具如“读取某服务过去 30 分钟错误率”“创建只读诊断快照”“生成回滚 PR”“请求审批调整 Flag”。窄工具能约束输入、输出、权限和审计也更容易在测试环境回放。2、失败应可见、可恢复连接超时、查询限流、日志缺口和工具返回不完整都必须进入报告。Agent 不能把“没有查到”写成“没有发生”。每个工具调用应记录状态、时间、查询范围与重试策略关键证据源不可用时应降低结论置信度并升级给人。二从告警疲劳到“调查疲劳”的新风险Agent 可以减少人检查每条告警的负担却可能制造新的调查噪声大量相似 SITREP、频繁状态更新、不断变化的假设。参考实现用事件门控的 weather 报告和“安静为常态”控制发布频率这一原则同样适用于所有 Agent 输出。质量比数量重要。首份报告可以简短但必须区分事实、假设和下一步只有出现新证据、状态变化或需要决策时才更新。对于同一事件Agent 应维护单一状态源而不是在多个频道复制不同版本。六、企业落地不能照搬连接器清单要重建控制系统一第一阶段用两周做“可行性审计”而不是直接接生产1、盘点数据与流程成熟度首先选择一个边界清晰、事故频率适中、已有稳定值班轮转的服务。列出关键告警、日志、指标、代码与变更记录、事故渠道、值班表、常见故障手册和过去 30 至 90 天事故。若团队连基线、负责人和关闭标准都不清楚Agent 只会更快地暴露混乱不会自动创造可靠流程。2、建立能力映射与缺口表参考 STACK.md 建立能力到工具的映射并记录缺口。缺少部署记录Agent 就难以关联变更日志没有统一 trace 或服务标签跨系统调查会受限事故没有结构化状态交接报告只能依赖聊天推断。缺口要转化为明确的工程改进项而不是通过更长提示词掩盖。二第二阶段历史挖掘、人工访谈与知识建模1、先从真实事故中提炼故障家族按症状而非组织架构聚类事故例如测试失败、测试缺失、合并队列阻塞、制品上传失败、部署回滚、容量不足、凭据过期、依赖服务异常。每个家族形成一份初始参考文件标明数据来源和样本数量。不要在第一天追求覆盖所有故障优先覆盖频率高、证据清楚、处置可逆的模式。2、只让人回答无法从数据挖掘的问题阈值、严重度、升级所有者、维护窗口、业务优先级和风险偏好需要人决定历史日志已经能说明的事实不必反复访谈。这样既减少专家时间也避免把“我们通常这样做”的口头印象误当成真实流程。三第三阶段离线回放与 Shadow 运行离线回放验证手册是否能在未见事故上工作Shadow 运行验证连接、延迟、真实噪声和协作体验。二者不能互相替代。离线集适合快速迭代和回归Shadow 期才能发现权限缺失、频道语义、指标延迟和夜间沟通等现场问题。1、建议的最小评测表每起事故记录首份报告时间、证据正确率、根因方向是否合理、关键反证是否覆盖、升级是否及时、危险建议数、人工采纳率、验证完成率和报告可读性。还要记录“Agent 没有说什么”遗漏有时比错误更危险。2、设置明确的退出和回退条件如果出现无证据高置信结论、越权动作、敏感信息泄露或高严重度漏升级应立即回到 Shadow修复相应工具或 Skill 后重新回放。上线不是单向迁移而是可逆状态。四第四阶段有限上线与分层授权初始上线建议只开放读取、频道汇报、lesson 追加和草稿 PR分页、Flag 调整、扩缩容等能力分别评估。权限授予以工具为单位以服务和环境为范围以时间和审批为条件。任何新增写能力都应带审计日志、速率限制、回滚路径和 named owner。从只读试点到有限授权每一步都由评测与人工关口驱动不按时间自动升级。七、必须正视的局限模型错误只是风险清单的第一项一可观测性不成熟时Agent 会把噪声组织得更像答案Agent 擅长语言组织恰恰因此可能让不完整证据显得非常连贯。如果日志采样不一致、仪表盘口径冲突、部署事件缺失模型仍可能拼出“像根因”的叙述。治理重点应是让证据质量显式化数据缺口、时钟偏差、采样率和查询失败都必须显示在报告中。1、建立“拒绝下结论”的能力高质量 Agent 不只会回答也会在证据不足时停止。团队应奖励正确的不确定性而不是只奖励快速命中。可以规定关键结论至少需要两类独立证据若只有单一相关性必须标记为待验证假设涉及高风险动作时必须列出最强反证。2、防止自动化偏见当 Agent 长期快速地产出专业报告人可能逐渐减少复核形成自动化偏见。应通过抽样审计、反事实演练、强制交叉质询和定期轮换评审人保持警觉。人在回路不是一个 UI 元素而是一项持续训练的组织能力。二知识可能过期、污染或被提示注入日志、Issue、PR 描述和 Slack 消息都可能包含不可信文本。如果 Agent 把工具返回内容当作指令攻击者或无意文本就可能改变其行为。连接层应区分数据与控制指令Skill 应明确忽略证据源中的操作性提示敏感动作只接受受信政策文件和审批系统的指令。lessons.md 也可能被错误结论污染。自动追加时必须附来源定期去重和过期检查正式 Skill 的修改必须 PR 评审。NIST 的生成式 AI 风险管理资料强调应在设计、开发、使用和评估全生命周期纳入可信与风险考虑这与值班 Agent 的持续评测和人类监督要求一致。NIST AI 600-1三成本、延迟和可用性本身会成为新的 SLO多 Agent 并行查询能缩短调查时间也会增加 API 成本、连接器负载和限流概率。值班系统必须为自身定义 SLO首份报告延迟、工具调用成功率、证据链接可访问率、调度准时率、单事故成本和降级模式。模型不可用时现有告警和人工手册仍应工作。1、把“快速检查”和“深度调查”分层低严重度事件先运行廉价分类与去重达到触发条件后再展开多源调查。报告生成与指标轮询也应按状态调整频率。这样既控制成本也避免 Agent 对监控系统产生二次压力。2、为连接故障设计降级路径若日志源不可用报告应明确缺口并从指标、变更记录和历史事故寻找替代证据若多个关键源不可用则应快速升级人而不是持续重试。降级策略同样要写进 Skill 并参加回放测试。四指标若被当成目标会诱发错误优化上线 Agent 后团队可能只追求 MTTR 下降或自动生成报告数量增长。DORA 提醒软件交付性能应同时观察吞吐与不稳定性且不能把单一指标变成竞争目标当前五项指标包括变更前置时间、部署频率、失败部署恢复时间、变更失败率和部署返工率。DORA 指标指南Agentic On-call 也应采用平衡指标速度与准确性、采纳率与危险建议、恢复时间与复发率、自动化覆盖与人工负担同时观察。若 MTTR 下降但误回滚增加系统并没有更可靠。八、进一步推演Agent 将如何改变 SRE 与平台工程一值班工程师将从“控制台操作员”转为“证据与风险编辑”当 Agent 承担日志检索、时间线拼接、初步汇报和验证轮询后人的工作会向三个方向移动定义什么证据足够、判断哪种风险可接受、把反复出现的问题转化为系统性修复。这不是减少专业性而是把专业性从记忆命令和跨屏操作提升到架构判断与治理设计。1、排障能力不会消失但训练方式会改变新人如果只阅读 Agent 结论可能失去亲自形成假设的能力。团队应把 Agent 的证据链用于教学要求新人先独立判断再与 Agent 对照在历史回放中让工程师质询每条证据定期关闭部分自动化进行演练。Agent 应成为可解释的陪练而不是不可见的代驾。2、平台团队将负责“操作知识供应链”未来平台工程不只维护 CI、可观测性和部署系统还要维护连接器、能力映射、Skill 仓库、评测集、权限策略和审计数据。可以把这套体系称为 Operational Knowledge Supply Chain事故产生原始事实结构化经验进入 lesson经评审成为 playbook通过回放和 Shadow 验证后进入生产再由新事故持续校正。二可观测性将从“给人看的面板”升级为“给人和 Agent 共用的证据 API”当前许多仪表盘依赖资深工程师理解隐藏口径。Agent 需要更结构化的元数据指标定义、单位、基线、标签含义、负责人、相关部署和允许的查询范围。日志也需要稳定的服务标识、trace、事件时间和敏感字段分类。为了让 Agent 工作而补齐这些元数据反过来会改善人的排障体验。1、每个关键健康信号都应可机器解释一个面板除了曲线还应暴露查询、阈值依据、时间窗口、数据延迟和“变好/变坏”的方向。这样 Agent 才能可靠比较修复前后而不是凭视觉描述猜测。2、变更事件要成为一等公民代码提交、配置修改、Flag、依赖版本、部署批次和基础设施变更应进入统一事件流。多数事故调查都在问“异常前后发生了什么变化”如果变更事件不可检索Agent 只能做低质量相关性推断。三组织学习速度将成为 Agentic 运维的核心竞争力Google SRE 将复盘视为记录影响、处置、根因和预防行动的正式学习机制并强调无责、评审与广泛分享。Google SREPostmortem Culture Claude Tag 的 lessons.md 和 Skill 晋升机制可以理解为把复盘知识进一步转化为机器可执行的排障程序。但自动写复盘不能取代复盘文化。真正的学习发生在团队审视“为什么当时的信息让这个选择看起来合理”“怎样改变系统让下一位值班者更容易做对”。Agent 可以减少时间线整理和事实收集的 toil却不能代替组织对架构债务和激励机制的反思。九、一套可直接采用的设计原则一十条原则先定义责任边界再连接工具默认把 Agent 定位为调查、建议、验证和沟通者。保留确定性告警旁路高严重度事件直接寻呼人。重要结论必须带证据链接、观测时间和置信度。把事实、推断、建议分栏表达不用流畅语言掩盖不确定性。关键知识放进可版本控制、可评审、可回滚的文件。权限按动作风险、服务范围、环境和时间分层而不只分读写。任何修复在执行前定义验证指标、观察窗口和失败条件。用 holdout 回放与 Shadow 运行证明能力错误后修复 playbook。让事件门控调度安静应是正常状态。事故关闭、政策修改和高风险操作保留明确的人类责任人。二最小可行架构一个最小但专业的版本应包括现有告警系统、只读指标和日志连接、代码与部署事件查询、Slack 事故频道、STACK.md 能力映射、ONCALL.md 政策、至少三类高频故障 Skill、结构化 lessons.md、统一 SITREP 模板、历史 holdout 回放、Shadow 评审频道与完整审计日志。若缺少其中任一项应把缺口和降级行为写清楚。1、SITREP 最小字段事故标识与时间当前影响已确认事实及链接候选假设及置信度已排除项下一步最小查询建议动作及风险验证标准需要谁在何时做决定下次更新时间。首份报告不要求知道一切但必须让人知道“我们知道什么、还不知道什么、正在做什么”。2、lessons.md 最小字段症状指纹相关服务根因缓解验证信号容易误导的线索证据可信度适用版本记录者与日期是否需要晋升为 Skill。定期删除重复、无证据或已过期条目。十、结语真正能值班的 Agent是被制度约束的协作者Claude Tag 的故事容易被讲成“AI 在深夜替工程师找到了 Feature Flag 问题”但这只是表面。更深层的创新是 Anthropic 把模型放进一套完整的运行机制确定性系统负责可靠触发连接器提供受控证据多个 Agent 并行探索主 Agent 汇总并暴露不确定性人决定和执行高风险动作调度器持续验证文件化知识沉淀经验历史回放和 Shadow 模式控制上线风险。因此企业不应把成功标准设为“自动修复了多少 Bug”。更有价值的问题是首份有证据报告是否更快值班工程师是否减少了无意义的跨屏搜索修复后是否稳定完成验证交接是否让新值班者真正接得住重复事故是否转化为新的监控、手册或架构改进危险建议是否被准确拦截这些指标共同决定 Agent 是否真正改善可靠性。未来最成熟的 On-call Agent 可能拥有更强的动作能力但它越强越需要清晰的边界、窄工具、可逆操作、独立审批和持续评测。可靠性从来不是“让系统永不出错”而是让错误更快被发现、更准确被理解、更安全被处置并让组织因此变得更聪明。Claude Tag 的最大启示正是如此Agent 要进入生产不是先获得更多自由而是先进入更严格的流程。可参考的文章与资料Claude on call: How Claude Tag serves as Anthropic’s first responder for CI/CD failuresAnthropic2026-08-18anthropics/oncall-kitClaude-assisted on-call 官方参考实现oncall-kit README事故闭环、五阶段设置、权限边界与评测方法oncall-kit 的 ONCALL.md 模板oncall-kit 的 lessons.md 模板Google SRE BookPostmortem Culture — Learning from FailureGoogle SRE BookManaging IncidentsDORASoftware Delivery Performance MetricsNIST AI 600-1Generative AI Profile