生产环境 AI 故障响应：当你的智能体在凌晨 3 点出错时

一家金融科技创业公司的多智能体成本追踪系统在没人察觉的情况下运行了 11 天。原因是：智能体 A 向智能体 B 寻求澄清，智能体 B 向智能体 A 寻求帮助以解释回复。两者都没有打破循环的逻辑。在人类查看发票之前，每周 127 美元的账单变成了 47,000 美元。

没有抛出错误，没有触发告警，延迟也正常。系统正完全按照设计运行——只是在永远运行下去。

这就是 AI 事故真实的样子。它们不是堆栈跟踪和 500 错误。它们是无声的行为失效、失控的循环，以及在生产规模下以十足信心交付的似是而非的错误答案。你现有的故障响应手册几乎肯定没有涵盖其中的任何一种。

为什么你的故障响应手册还没准备好

传统的事故响应是围绕二进制故障模式构建的。一个服务要么正常运行，要么宕机。数据库要么可以访问，要么不可访问。一个请求要么返回 200，要么抛出异常。修复周期——重现故障、编写测试、修复代码、验证测试通过——是确定性的。

LLM 系统打破了所有这三个假设。

首先，故障是非二进制的。一个智能体可以成功执行每一步，但仍然产生错误的结果。加拿大航空（Air Canada）的聊天机器人返回了 200 OK，却发明了一个根本不存在的退款政策。一个法律 AI 生成了指向看起来很真实但纯属虚构的法院案例的引用。从系统的角度来看，这些系统工作正常，它们只是错了。

其次，故障无法可靠地重现。用户报告你的智能体错误分类了他们的请求并采取了破坏性行动。你重新运行完全相同的输入，智能体表现得却很正确。故障是真实的——它发生在生产环境中，具有特定的上下文窗口状态、检索结果和 Token 采样路径——但你无法根据需要重现它。

第三，爆炸半径跨越服务边界。当一个智能体失效时，它可能已经写入了你的数据库、发送了电子邮件、调用了外部 API 或生成了子智能体。故障并不局限于一个服务内部；它会传播到智能体在故障会话期间接触到的每一个系统。一个智能体在忽略停止命令的同时删除了 10,000 封电子邮件，这并不是假设——而是一个有记录的 2025 年事故。

这意味着：AI 的事故响应需要不同的检测模型、不同的分流方法和不同的事后复盘格式。

检测：停止关注错误率

大多数生产 LLM 系统中的监控缺失是结构性的。传统的观测性关注系统性能指标：错误率、延迟、吞吐量。当 AI 系统产生自信的错误答案时，这些指标保持沉默。

对 90 个 AI 应用的 300 万条用户评论的研究发现，大约 1.75% 的评论明确指出了幻觉——这代表了数百万用户经历了未抛出任何系统级错误的故障。Whisper 的医疗转录模型在近 40% 的案例中产生了有害或令人担忧的幻觉。这些都没有触发任何告警。

真正能检测 LLM 质量下降的指标是行为层面的：

Token 长度分布漂移。 以 25 个 Token 为区间，建立输出长度分布的 7 天滚动基准。每天计算针对该基准的 KL 散度。在实证研究中，≥0.15 的散度阈值与大约 87% 的用户感知质量下降相关。异常短的输出信号可能意味着截断或拒绝；异常长的输出通常信号意味着冗长的幻觉或上下文混淆。

嵌入向量中心点漂移。 收集每日输出的嵌入向量，计算它们的中心点，降低维度，测量与历史基准的余弦相似度。当相似度降至 0.82 以下时，你的模型的响应分布在语义上发生了偏移。嵌入向量漂移分析平均能在第一条用户投诉到达你的支持队列前 11 天检测到退化。

LLM 作为裁判评分。 运行一个辅助模型（比主模型更小、更便宜），从依据性、任务完成度和事实一致性等维度对一定比例的生产环境响应进行评估。任何维度上的评分下降 0.3 分都是可采取行动的信号。这是捕捉“看似合理但错误”这一故障模式的唯一可靠方法。

金丝雀提示词。 维护一组固定的输入，按计划运行，并且你已知其正确输出。这些是你针对提供商静默模型更新的冒烟测试。当提供商更新底层模型时（通常没有公告），你的金丝雀评分会在任何面向用户的指标变化之前发生变化。

拒绝率指纹识别。 跟踪触发安全层或拒绝的请求百分比。突然的变化表明你的提供商已经更新了模型行为。这个信号捕捉安全层修改的速度比任何其他检测方法快 3–5 天。

这五个信号结合在一起——加权并组合成一个综合健康评分——比传统基础设施指标的任何组合都能实现更可靠的检测。

故障排查：究竟哪里出了问题

2025 年加州大学伯克利分校的一项研究分析了七个多智能体框架中的 1,600 多个带有注释的执行追踪（execution traces）。由此产生的故障分类法极具启发性：43.8% 的故障是系统设计问题（步骤重复、不知晓终止条件、任务定义错误），32% 是智能体间的失配（推理-动作不匹配、任务偏离），23.5% 是任务验证失败（错误的验证、过早终止）。

核心结论是：79% 的智能体故障源于规范和协作问题，而非模型限制或基础设施停机。你的模型没问题，出问题的是你的架构。

这改变了故障排查的优先级。当智能体事故发生时，不要先假设 LLM 坏了。首先要问：

• 检索上下文是什么？ 在你的追踪中，低检索评分、错误的文档数量或缺失的上下文表明这是检索故障，而非模型故障。
• 工具调用的参数是什么？ 检查每一次工具调用。如果一个工具被反复调用且参数完全相同，那就是进入了死循环。如果一个工具的调用参数并未出现在原始请求中，那就是提示词注入或上下文泄露。
• Token 预算是多少？ 检查追踪中的 finish_reason: length。模型在推理中途达到上下文限制时，会返回截断的、通常是不连贯的响应。这看起来像是幻觉，但实际上是信息丢失。
• 运行的是哪个模型版本？ 模型提供方的更新经常会在不破坏 API 兼容性的情况下改变模型行为。将 Span 中的 gen_ai.response.model 属性与你的预期进行对比。它们可能会有所不同。
• 运行的是哪个提示词版本？ 如果你没有对提示词进行版本管理，这个问题就无法回答——这本身就是一个问题。

特别是对于多智能体系统，要在排查模型层之前先排查协作层。在表现出行为漂移（behavioral drift）的系统中，智能体之间的冲突——即一个智能体的输出为另一个智能体的输入创建了无效状态——增加了 487%。当多个智能体似乎同时出错时，问题通常出在它们之间的消息 Schema，而不是模型本身。

故障止损：未雨绸缪的紧急开关

AI 系统的故障止损在三个层面运行。

基础设施止损是紧急停机开关。它必须在智能体自身的推理路径之外运行——通过编排层、访问控制或基础设施策略来实现——因为处于降级状态的智能体无法被信赖能正确地自行终止。OpenClaw 事件中，一个智能体删除了 10,000 封邮件并忽略了停止指令，原因就是停止机制本身是一个提示词级别的指令。一个足够混乱的智能体将会忽略提示词。

你的紧急开关需要：全局硬停机（在 30 秒内撤销工具权限、停止排队的作业、锁定部署流水线）、针对每个智能体的断路器（确保一个失控的智能体不会耗尽所有其他智能体的 Token 预算），以及一条文档化的启动路径，让值班工程师无需了解内部架构即可操作。

成本止损是不可妥协的，却长期未受到重视。在最坏的 10 万次循环场景下，单个 Claude Opus 智能体在一次会话中就能产生数千美元的费用。默认的成本失控模式是：智能体 A 派生了智能体 B，两者都没有循环检测逻辑，账单呈指数级增长，直到几天后人类看到发票。必要的防护栏包括：单次会话的硬性 Token 预算、迭代上限、动作哈希去重（检测相同的工具是否正被以相同的参数重复调用），以及当支出超过阈值时终止会话的基于成本的断路器。

功能止损是优雅降级。为你的系统定义一个降级阶梯：全智能体模式 → RAG-only 模式 → 关键词搜索 → 静态响应。当全智能体模式失效时，你需要一种在调查问题的同时提供有用服务的方法。大多数团队直到发生事故时才开始思考这个问题。设计降级方案的时机是在事故发生前，而不是发生时。

非确定性系统的根因分析

标准的根因分析（RCA）流程在 LLM 系统中会失效，因为故障可能无法复现，而且除非你在事故前进行了埋点，否则证据可能根本不存在。

你在事故响应方面能做出的最重要的架构决策是：在需要之前，记录每一次生产环境的 LLM 调用及其完整上下文。提示词版本、模型版本、检索结果、工具调用和响应、Token 计数、结束原因、会话 ID、用户 ID、请求 ID。如果你在事故发生时没有这些数据，你就是在盲目重建现场。

有了这些数据，有效的 RCA 应遵循组件隔离法：

• 将故障会话的追踪数据与正常会话的基准线进行对比
• 按维度隔离：同一用户、同一查询类型、同一模型版本、同一时间窗口
• 检查故障是否与任何部署事件相关联（提示词更改、模型更新、检索索引刷新、工具 Schema 更改）
• 对于工具调用故障，检查工具的 API 契约是否在未更新智能体工具描述的情况下发生了变化

LLM 根因分析的结构性限制在于，你无法可靠地复现故障执行过程。你的事后复盘必须基于生产环境中实际运行的情况——即实际的追踪数据——而不是基于复现的行为。这就是为什么日志留存不是可选项，以及为什么将日志采样率降低到 100% 以下会产生缺口，而这些缺口恰恰会在你最需要它们的时候出现。

能真正沉淀经验的事后分析报告（Post-Mortem）格式

大多数 AI 事后分析报告（Post-Mortem）之所以失败，是因为它们使用了错误的抽象层次。“模型产生了幻觉”不是根本原因。“模型提供了错误信息”也不是根本原因。这些只是对症状的描述。

具备可操作性的 AI 事后分析报告应锚定在可回答的问题上：

• 在故障发生时，为模型提供了什么样的检索上下文（Retrieval Context）？它是否充足？
• 提示词（Prompt）的版本是什么？最近是否有变动？
• 在上一次已知正常运行与本次事故之间，供应商是否更新了底层模型？
• 是否存在 Token 预算压力从而导致了内容截断？
• 进行了哪些工具调用（Tool Calls）？顺序是什么？每个调用的返回值是什么？
• 最近是否有任何工具的 API 发生了变化，而 Agent 的描述未能反映这一点？

结束 AI 事后分析的纠正措施应该是工程产物：针对失败用例的新评估（Eval）覆盖、能捕获回归问题的金丝雀提示词（Canary Prompt）、熔断器配置、检索质量检查，或者模型版本锁定（Model Version Pin）。如果没有能检测回归问题的具体测试，“优化我们的提示词”就不能算作纠正措施。

一个能持续提升事后分析质量的实践是：在报告文档中附上完整的会话追踪（Session Trace）。记录每一次 LLM 调用、每一次工具触发以及每一次 Token 计数。当你在六个月后重新审视这份报告，或者当一名新工程师在调试类似的故障时，会话追踪是了解当时真实情况的唯一途径。

构建与问题匹配的响应文化

相比于技术模式，组织对最初几次事故的响应方式更为重要。如果团队将“AI 表现异常”视为一次性偶发事件，而不是一种需要投入资源解决的故障类别，那么同样的事故将会无限期地重复发生。

改变现状的三种实践：

将行为健康（Behavioral Health）作为一等公民 SLI。 在传统的延迟和错误率 SLI 之外，为输出质量定义服务水平指标（SLI）——例如：归因得分（Groundedness Scores）、任务完成率、LLM-as-judge 评分。当行为 SLI 下降时，即使没有触发任何错误报错，也应被视为一起事故。

在需要之前就做好埋点。 全会话追踪、金丝雀提示词、模型版本锁定、Token 预算日志——如果这些手段没有在事故发生前部署到位，那么事故发生后再去补救也无济于事。这种埋点的成本很低，但在没有埋点的情况下调查生产环境中的 AI 事故，其代价是非常高昂的。

针对 AI 故障模式进行桌面演练。 如果供应商静默更新了基础模型会发生什么？如果工具 API 发生了变化，导致你的 Agent 描述不再准确会发生什么？如果你的检索索引返回了过时或被恶意投毒的文档，又会发生什么？这些故障模式是可预测的；而在你亲自走一遍流程之前，事故响应流程中的漏洞往往并不明显。

生产环境中的 AI 系统，其可靠性不会超过运营它们的团队。那些运营得好的团队仅仅是接受了这样一个事实：“能运行”和“运行正确”是两种截然不同的属性——并据此构建了他们的事故响应流程。