没有模型推理项的故障复盘模板

第一次智能体导致我们团队出现真正的停机事故时，复盘报告的作者打开模板，划过时间线，盯着“根因”字段沉思了良久，然后输入：“队列阻塞恢复的操作指南 (runbook) 有误。” 但实际上操作指南没问题。智能体阅读了指南，认定队列的症状符合另一种场景，并针对该场景运行了恢复脚本。那份文档产生的改进措施——“细化操作指南用词”、“在恢复脚本中增加确认提示”——对于实际的故障模式完全无用。实际情况是一个推理系统推导错误，而模板中没有任何字段知道该如何表达这一点。

自那以后，我看到同样的失败在不同团队中反复上演。模板是为确定性系统设计的。代码做错了，你就修复代码；配置设错了，你就修复配置。复盘文档的模式 (schema) 就是团队关于故障理论的模式，当这个理论无法表达“智能体的计划错了”时，文档就会将实际故障强行降维成模板能表达的最接近的事物——通常是文档缺失或缺乏护栏——从而导致改进措施试图用确定性的修复方案去解决概率性的故障。然后，同一类事故会再次发生，团队下次依然会以同样的方式记录它。

这不仅仅是“我们需要更好的 AI”的问题，而是组织学习文档化的问题。复盘模板是承载学习成果的模式，如果模式错了，学习成果就永远无法落地。

为什么“修复操作指南”总是出现在改进措施中

Google SRE 复盘模板（几乎所有现代事故模板的鼻祖）包含了“触发因素”、“促成因素”、“根因”、“检测”和“我们将做出的改变”等行。每一行都基于一个假设：故障是由系统中某个离散的事物引起的，而这个离散的事物可以被指出并修复。“五个为什么” (Five Whys) 阶梯强化了这一点。你从可观察的症状开始，向下追溯一系列“为什么”问题，直到找到团队可以改变的东西。整个结构旨在将事故转化为一系列代码、配置或流程的差异。

一旦事故中的参与者是一个输出从分布中采样的推理系统，这个结构就会失效。不存在“代码做错了”——代码只是一个 LLM 调用，在给定输入的情况下返回了一个合理的 Token 序列。不存在“配置设错了”——提示词 (prompt) 还是那个正确处理了前一百次事故的提示词。当追问到“为什么模型会输出那个结果？”时，“五个为什么”链条就断了，因为答案不是关于你系统的一个事实，而是关于一个你不拥有的分布的事实。

因此，作者做了模板要求他们做的事情：将故障映射到现有的最接近的字段。“模型的推理错了”变成了“操作指南含义模糊”或“缺失护栏”。从某种意义上说，这些陈述也是正确的——操作指南可以更明确，护栏也可以存在——但它们并不是根因，它们产生的改进措施也无法防止下一例同类故障的发生。

2026 年 3 月的 Firetiger 摄入故障也遇到了类似的情况。复盘报告指出，他们的智能体分诊系统“准确知道问题所在，如果给它相应的工具和连接，它本可以完成回滚”。这句话非常有意思：智能体的正确推论被视为事故中的一个事实，而不是模板可以评估的对象。模板中没有字段来记录“智能体推论了什么以及是否正确”。智能体的角色出现在脚注中，而不是作为故障模型的一个承重组件。

缺失的行长什么样

修复方法是扩展模板，使智能体在事故中的角色成为文档的一等公民，而不是埋没在叙述中的段落。具体来说，增加四个字段：

智能体的推论是什么。 直接陈述智能体对情况的理解——“运维智能体将队列停滞诊断为死锁。”不是它做了什么，而是它相信什么。这是 LLM 等同于“故障发生时的系统状态”的一行，必须从 trace 中逐字获取，而不是转述。

正确的推论应该是怎样的。 智能体遗漏的事实解读——“队列停滞是因为上游生产者停止了发布，而不是因为死锁。”这是改进措施需要弥补的差距。

智能体遗漏了什么信号。 如果可见，本可以改变推论的具体上下文——“生产者的心跳指标不在智能体的工具界面中。”这是一个可操作的抓手。它将对话从“模型错了”（不可操作）转变为“模型在基于不完整的图景进行推理”（可操作）。

什么样的上下文或工具变更能产生正确的推论。 干预措施——“将生产者心跳添加到队列诊断工具返回的数据负载中”——表述为工具或上下文的变更，而不是提示词的微调。“优化提示词”成了新的“修复操作指南”；它将工作推向模型的推理能力，而不是模型进行推理的信息环境。

这四个字段将无法操作的哀叹（“智能体推理错了”）转变为可处理的工程问题（“智能体基于错误的输入进行了推理”）。它们还起到了一种微妙的作用：将复盘的重心从 LLM 调用转移到周围的系统上。模型并不是孤立失败的；它是在团队拥有并可以更改的上下文流水线、工具界面和升级策略中失败的。

优于“AI 出了问题”的四路根本原因分类

一旦模板中有了记录 Agent 推理的行，下一个差距就会出现在根本原因的“分类”上。大多数模板将所有与 LLM 相关的内容都归入一个桶——“AI 故障”，或者越来越多地被称为“模型错误”——这在范畴上相当于在 1995 年写下“电脑坏了”。这掩盖了四种截然不同的故障模式，它们对应着四种不同的修复方案：

• Agent 故障。模型接收到了正确的上下文和正确的工具，但仍然产生了错误的计划。这纯粹是模型能力差距，正确的行动项是增加一个能捕获下一次类似情况的 eval（评估），而不是修改代码。
• 工具故障。根据其拥有的信息，模型的计划是正确的，但它调用的工具返回了错误的数据，或者没有显示相关的字段。修复方案针对的是工具，而不是 Agent。
• 数据故障。Agent 进行推理的上下文是陈旧的、不完整的或损坏的。修复方案位于检索层、缓存或上游记录系统中。
• 人机交接故障。Agent 在错误的阈值下将问题升级给了人类（或者未能升级），人类批准了本该拒绝的计划，或者队列背压问题导致合适的人员从未看到它。修复方案在于升级策略、队列或审核员的信息展示界面。

一个事故通常包含不止一种故障。Firetiger 的报告就是一个清晰的例子：CI 中的竞态条件、构建归因错误，以及一个虽然推理正确但未连接到相应操作的 Agent——三类问题交织在一起。强制你在这四个桶中分配贡献度的模板，可以产生针对正确层级的行动项。而允许你写下“AI 故障”的模板，只会产生一个没人能完成的待办项。

弥合概率间隙的行动项

确定性模板失效的另一个地方是在行动项阶段。行动项的隐含契约是，你可以完成它，且故障不会再次发生。这一契约适用于“向速率限制器部署热修复”。但不适用于“模型给出了自信但错误的诊断”，因为没有任何单一的更改能将这类故障的发生率降至零——你是在移动分布，而不是修补 Bug。

Agent 故障行动项的正确形式借鉴了机器学习团队对待回归的方式：你承诺在“特定的” eval 上实现“可衡量的”故障率降低，而不是“消除”故障。三个具体的模式：

针对遗漏场景的 Eval 覆盖。获取事故的追踪记录（trace），对其进行匿名化，并将其添加到 eval 测试套件中。当该套件在包含此案例的模型版本上运行通过时，该行动项即告完成。这是 LLM 版的回归测试，但有一个重要的区别：它不保证故障不会再次发生，只保证再次发生时能在评估阶段而非生产环境中被检测到。

添加护栏。在工具层或输出层进行确定性检查，以捕获特定形式的错误推理。“如果恢复计划会清空一张表，无论 Agent 的置信度如何，都要求人工显式批准。”护栏是你在不让系统变得更聪明的情况下，让概率系统变得更安全的方法。

升级阈值调整。对决定 Agent 自动执行还是暂停等待人工介入的策略进行定量调整。如果在此次事故中 Agent 的置信度校准有误，行动项就是降低特定类别操作的自主权阈值，并设定一个可衡量的目标：“队列恢复的 Agent 自动执行率从 80% 下降到 30%，在发生五十起事故后重新评估。”

这些看起来都不像“修复 Bug”。它们看起来更像“收紧分布”。这就是工作的本质，模板必须为此留出空间。

保持 Schema 真实性的季度检查

模板会腐烂。组织增加了一行，发布了它，一年后，一半的事故复盘仍然跳过这些新字段，因为事故指挥官正忙于处理紧急情况，习惯性地依赖肌肉记忆。对策不是更严格的模板，而是季度复盘。

复盘的任务是阅读上一季度所有涉及 Agent 的事故复盘，并根据两个问题对它们进行评分。首先，文档是否真正使用了 Agent 特有的字段，还是作者将故障简化成了确定性的行？其次，行动项所针对的故障率是否真的在特定 eval 上呈下降趋势，还是同样的类别在反复出现？第一个问题保持了 Schema 的生命力。第二个问题防止了行动项变成一种仪式。

一个每季度运行一次此类检查的团队，在一年左右的时间里，就能看到哪些事故类别正在收敛（Eval 驱动的行动项正在起作用），哪些类别持平或正在恶化（团队正在像处理工程问题一样处理研究问题，而模板却允许他们这样做）。这种信号比任何单一的事故复盘都更有用，因为它告诉你组织的学习闭环是否真正闭合。

Schema 即学习

复盘文化归根结底是一种组织层面的声明，即团队能够从事故中学习。模板就是学习内容必须适配的 Schema。不完整的 Schema 会导致不完整的学习，而这种差距在团队最努力学习的时刻代价最为昂贵——即在客户可见的故障发生后的几个小时内，此时值班作者仍然处于肾上腺素飙升的状态，他们产出的文档将决定接下来六个月的工作方向。

如果你的模板中没有一行记录 Agent 推断了什么，没有区分 Agent 故障与工具故障的类别，也没有针对概率而非 Bug 的行动项类型，那么你在下一次 AI 事故后提交的文档，将只能准确描述一个已经不复存在的系统所发生的事情。Schema 就是瓶颈。修复 Schema，复盘报告就会开始告诉你关于你实际运行系统的真相。