五面分诊树：当常规操作手册不再适用时的 AI 轮值指南

页面告警在凌晨 2:47 响起。智能体（Agent）正向客户支持工单发送语气错误的回复，延迟仪表盘显示平稳，错误率正常，而且由于过去 12 小时内没有进行过任何部署，没有任何东西可以回滚。值班工程师打开了运维手册（runbook），滑过了“重启工作线程池”和“扩容队列”，直到翻到底部，也没发现任何能与眼前告警相匹配的内容。他们在凌晨 3:04 开始阅读系统提示词（system prompt）。到凌晨 3:31，他们仍在阅读。

这是全新的故障形态。那些为“高延迟意味着重启 Pod，5xx 错误增加意味着回滚部署，队列深度增加意味着扩容工作线程池”而设计的轮值制度，已无法应对此类问题。第一直觉——回滚部署——是错误的，因为根本没有部署：模型在版本化别名（versioned alias）后静默升级了，第三方工具的响应结构发生了偏移，提示词版本在不同区域间出现了偏差，或者评估集在几周前就已失效，而回归问题一直在持续累积。告警是真实的。运维手册却保持沉默。AI 值班现在已经成为一门独立的学科，试图将其强行套入现有的轮值体系，只会产生那种在告警发生时，所有人第一步都是在通话中相对无言、第一次开始阅读提示词的方案。

本文的核心观点是：处理 AI 告警的正确第一步不是“部署中改变了什么”，而是“五个维度中的哪一个发生了偏移”——如果团队没有预先构建排障树、冻结按钮、回放测试框架以及针对新故障模式的严重程度判定准则，那么每次故障发生时，都要在通话中耗费一个小时来学习这些教训。解决方案并非依靠英雄主义。它源于产生传统 SRE 的同一种本能：将排障流程化，为各个维度增加监控，并反复演练响应过程。

在通话开始时明确哪个维度发生了偏移

AI 排障树的第一条分支不是“最后一次部署是什么”——而是“五个维度中哪一个是变化的源头？”这五个维度分别是：代码、模型、提示词、工具和数据。每一次告警都可以归结为其中之一的偏移。值班人员在头五分钟内的工作是带着具体的检查项逐一排查每个分支，而不是凭直觉猜测。

一个可行的排障清单如下所示：

• 代码变更（Code change）。 拉取受影响服务的部署日志。如果过去 24 小时内有任何涉及智能体循环（agent loop）、提示词组装、工具分发器（tool dispatcher）或响应解析器的代码发布，该分支即为高风险项。
• 模型变更（Model change）。 将模型别名解析为其当前的具体版本。将其与上一次成功的评估运行中记录的版本进行对比。检查模型提供商的状态页面，查看是否有升级、弃用或容量事件。别名背后的静默升级是“没有任何部署但一切都变了”最常见的原因。
• 提示词变更（Prompt change）。 将提示词注册中心与上一个已知良好版本进行比对（diff）。许多提示词回归仅仅是非工程师在配置 UI 中进行的三个单词的修改。有些则是跨区域的版本偏差，即某次标志位（flag）滚动发布导致两个区域运行在不同的提示词版本上，从而引发了区域性告警。
• 工具变更（Tool change）。 将工具的 Schema 与智能体测试时使用的版本进行比对。检查工具自身的状态页面。许多“智能体表现异常”的告警最终发现是下游 API 开始返回一个新字段，或者停止返回一个旧字段，导致智能体的解析器静默回退到了较差的路径。
• 数据变更（Data change）。 检查检索索引（retrieval index）版本、索引语料库的新鲜度时间戳、嵌入（embedding）模型版本以及分块（chunking）配置。一次使用略微不同分块策略的重新索引，可以在不改变任何代码的情况下改变回答质量。

这种规范要求清单必须在所有人开始阅读提示词 之前，按顺序在五分钟内运行完毕。阅读提示词是深度钻研。排查五个维度是故障分级（triage）。这两者是不同的工作，混为一谈会导致通话结束时有三名工程师都在看提示词，却没有一个人去查模型别名的日志。

在展开调查前冻结所有变量维度

在确定了发生偏移的维度后，第二步动作是冻结系统的其余部分。传统的事件响应通过停止部署来冻结代码。AI 事件响应必须同时冻结五件事：已解析的模型版本、提示词版本、智能体使用的每一个工具 Schema、检索索引版本，以及智能体框架（harness）本身的配置。

这至关重要，因为调查是在与偏移赛跑。当值班人员在阅读提示词时，提示词注册中心可能正接收来自另一个时区产品经理的热修复。当值班人员在比较模型行为时，别名可能会静默解析到更新的检查点（checkpoint）。当值班人员在调试工具输出时，上游 API 可能会发布一个针对导致该告警的 Bug 的修复方案。凌晨 3 点针对五个移动目标开始的调查，到凌晨 5 点时可能无法产生任何可用的证据。

冻结按钮必须是一个真实的工具，而不仅仅是一种规范。在实践中，它看起来像：

• 一个注册中心级别的锁定（pin），在故障期间将受影响维度的每个别名转换为具体版本，并在冻结解除前拒绝任何对这些记录的写入。
• 一个金丝雀风格的流量切分，在系统其余部分继续提供服务的同时，将一部分流量保留在冻结的版本上，以便调查时拥有“之前”与“之后”的样本进行对比。
• 一个审计日志，准确记录故障发生时锁定的具体版本，以便在事后回顾（postmortem）中，当被问及“这次回归是真实存在的还是测量误差”时，有一个可复现的快照可供参考。

冻结是 AI 领域的 kubectl cordon。它并不能解决问题，但它能为值班人员提供一个稳定的调查环境。如果没有它，值班人员运行的每一次诊断实际上都是在比较系统的两个快照，而这两个快照甚至可能不属于同一个版本向量。

建立回放工具，让“模型在此输入下的表现是否不同”成为一个 30 秒内就能解决的问题

经典的类比是核心转储 (core dump)。当服务器崩溃时，运维人员拥有堆栈跟踪、堆、输入和环境。他们可以在沙盒中重现崩溃。AI 智能体 (AI agents) 直到最近才拥有这种原语 (primitive)，而这种缺失是导致 AI 故障 MTTR 过长的最大原因。

回放工具是一个捕获系统，对于每一个生产环境的追踪 (trace)，它都会记录每次模型调用和工具调用的确切输入，以及产生输出的版本向量 (version vector)。值班人员随后可以将该工具指向任何过去的追踪，交换一个变量——模型版本、提示词修订、工具定义 (tool schema) 或检索结果——保持其他所有变量不变，然后问：“如果只改变这一点，这个追踪会产生不同的答案吗？”关于确定性回放 (deterministic-replay) 的文献已经为此原语争论了两年，而工具链终于赶上了：Message-Action Trace 记录、拦截非确定性依赖并从记录的追踪中提供服务的重放桩 (replay stubs)，以及作为智能体框架的一部分而非作为附加观测层提供的工具。

回放工具为值班人员提供的是时钟级别的鉴别诊断。告警显示“智能体正在发送语气错误的回复”。值班人员从受影响的时间窗口中提取捕获的追踪。他们针对当前提示词运行旧版模型，针对当前模型运行旧版提示词，以及针对两者运行旧版工具定义。在 90 秒内，他们就能隔离出五个维度中哪一个是导致回退的原因，并有一个具体的追踪作为证据附加到事故频道。相比之下，另一种选择是：盯着提示词看一个小时，提出不成熟的假设，最后提交一条注释说“我觉得是模型升级的问题，我们下周再看吧”。

回放工具还将故障排查从取证练习转化为可重现的测试用例。一旦回退被定位到单个维度，该追踪就会变成回归测试，团队会在修复的同时将其检入代码库。下一次破坏这种特定行为的无声升级会在触发客户投诉之前，先在失败的评估 (eval) 中触发告警。

针对旧分类法中不存在的故障模式重新划分严重级别

经典的严重程度分级标准是围绕可用性和正确性这两个二元属性构建的。系统要么在线，要么离线。交易要么完成，要么失败。AI 的故障模式不符合这种分类法。智能体是在线的，交易完成了，输出是错误但看似合理的，用户信任了它，而下游后果将在三天后客户投诉升级时显现。

如果分级标准用“嗯，API 返回了 200，所以它是 Sev3”来掩盖这一点，那么这个标准就会让值班轮转倾向于错误的事故。解决方案是增加与系统实际发生的故障模式相匹配的严重程度维度：

• 输出质量回退 (Output quality regression)。系统在线，但一个可衡量的质量指标——有效请求的拒绝率、格式一致性、指令遵循得分、语气校准——已偏离阈值。如果影响收入相关界面，则为 Sev2；如果影响非关键界面，则为 Sev3；如果影响安全相关界面，则为 Sev1。
• 自信的错误答案 (Confident wrong answers)。系统在线，但智能体在没有表达不确定性的情况下产生错误输出。默认 Sev1；这种故障模式在于缺失了下游系统和人类用户所依赖的对冲信号 (hedging signal)。
• 未经授权的操作 (Unauthorized action)。智能体调用了它不该调用的工具，或者调用工具时的参数超出了批准的范围。如果操作不可逆，则为 Sev1；否则为 Sev2。
• 成本激增 (Cost spike)。单个请求的 Token 支出在工作负载没有相应变化的情况下超过了预算阈值。默认 Sev2；这里的故障模式是“账单在与下一次告警赛跑”。

新标准在组织上强制要求值班人员以处理旧故障的紧迫感来处理这些新的故障模式。一条提示“模型开始撒谎”的告警与一条提示“数据库宕机”的告警具有相同的优先级，正是因为在这两种情况下，与用户之间的信任契约都遭到了破坏。如果不明确进行这种校准，团队会发现“错误但看似合理”的告警被路由给了一个有着四小时 SLA 的初级工程师，而每次起草客户沟通函时都要从头开始。

对值班轮转进行交叉培训，或者进行拆分

最后一步是人员配置。最擅长分布式系统故障排查的工程师很少是那个能从对话记录中发现拒绝式偏移 (refusal-style drift) 的人。最擅长提示词调试的工程师很少是那个能阅读 Kubernetes 事件流的人。幼稚的方案——“我们在值班轮转中加入 AI 环节”——会导致告警落在那些在操作手册 (runbook) 设计会议上声音最大的人身上。真正的解决方案是以下两种模式之一。

第一种模式是交叉培训。轮转中的每位工程师都要经历 90 天的学徒期，期间他们会跟班处理 AI 告警，对捕获的事故运行故障排查树，并提交至少一个涉及提示词、工具定义或模型别名的修复。认真执行这一方案的组织会付出一段时间的磨合成本，但会获得一个能够处理两种类型告警的轮转机制。不执行这一方案的组织最终每次都会将 AI 告警路由给同样的三个人的身上，而这三个人会在两个季度内精疲力竭。

第二种模式是拆分值班轮转。AI 值班成为一个独立的学科，拥有自己的一线轮转、自己的 MTTR 计算方式、自己的事后分析模板和自己的严重程度分级。经典的 SRE 轮转处理可用性、容量和基础设施；AI 值班轮转处理模型、提示词、工具和数据偏移。对于跨越这两个维度的事故，两个团队共享一条升级路径。这比交叉培训成本更高，但当 AI 业务规模大到足以证明需要专门的人力，且故障模式分化到通才不如专才时，这就是正确的答案。

绝大多数团队默认采用的是那种行不通的模式：单一轮转、没有交叉培训，并默认为“AI 告警会交给 AI 团队处理”。告警在凌晨 2:47 响起，AI 团队在另一个时区睡觉，值班人员打开操作手册，第一步就是电话里的相对无言。

Runbook 必须抢在下一次报警前发布

这种值得正视的错误源于工作的形态。AI On-call 的纪律并非在故障期间建立的。它建立在故障发生的间隙，遵循固定的时间节奏，由这样一支团队打造：他们认定“模型开始胡说八道”是一类值得提前进行工程化预案的报警。这些工作——故障分诊树、冻结按钮、回放测试框架、严重程度分级标准、值班轮换设计——看起来像是没有即时回报的基础设施投入，直到某天早晨报警响起，Runbook 要么能扛住压力，要么溃不成军。

在 2026 年，完成这些工作的团队并不是那些拥有最强模型或最昂贵可观测性技术栈的团队。相反，面对“哪些表现发生了偏移”时，他们的 On-call 响应是一份 5 分钟的检查清单，而非 30 分钟的 Prompt 阅读练习；他们的故障处理频道能在前 10 分钟内生成冻结的版本向量；他们的故障复盘最终会为该链路附上一个回归测试。行业的其他公司最终也会达到这一水平，但他们将不得不通过一次又一次的宕机换取这一进步。