企业官网建设流程全解析

目录

一、为什么这件事比“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 应调用窄工具，而不是持有宽泛 Shell

2、失败应可见、可恢复

（二）从告警疲劳到“调查疲劳”的新风险

六、企业落地：不能照搬连接器清单，要重建控制系统

（一）第一阶段：用两周做“可行性审计”，而不是直接接生产

1、盘点数据与流程成熟度

2、建立能力映射与缺口表

（二）第二阶段：历史挖掘、人工访谈与知识建模

1、先从真实事故中提炼故障家族

2、只让人回答无法从数据挖掘的问题

（三）第三阶段：离线回放与 Shadow 运行

1、建议的最小评测表

2、设置明确的退出和回退条件

（四）第四阶段：有限上线与分层授权

七、必须正视的局限：模型错误只是风险清单的第一项

（一）可观测性不成熟时，Agent 会把噪声组织得更像答案

1、建立“拒绝下结论”的能力

2、防止自动化偏见

（二）知识可能过期、污染或被提示注入

（三）成本、延迟和可用性本身会成为新的 SLO

1、把“快速检查”和“深度调查”分层

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.md：Skill 只依赖“指标源、日志源、代码托管、寻呼系统”等抽象能力，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 SRE：Postmortem 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 failures（Anthropic，2026-08-18）

anthropics/oncall-kit：Claude-assisted on-call 官方参考实现

oncall-kit README：事故闭环、五阶段设置、权限边界与评测方法

oncall-kit 的 ONCALL.md 模板

oncall-kit 的 lessons.md 模板

Google SRE Book：Postmortem Culture — Learning from Failure

Google SRE Book：Managing Incidents

DORA：Software Delivery Performance Metrics

NIST AI 600-1：Generative AI Profile