为生产级 Agent 阻断静默故障级联

生产环境中的 AI Agent，其失败方式与传统代码不同。

应用崩溃时，你会看到错误，然后修复它。而 Agent 可能悄无声息地陷入循环、凭空捏造一个决策、调用错误的工具——最终仍然返回 HTTP 200，与此同时，损害却在不断扩散。

可观测性告诉你发生了什么。恢复基础设施则能在级联故障真正蔓延之前将其阻止。

非确定性输出问题，本质上是恢复问题

根据《2026 年 AI Agents 现状报告》，70% 的企业领导者将“非确定性输出”列为生产就绪的首要障碍。这不是模型问题，而是基础设施问题。

当 Claude 选择了错误的工具时，设计完善的基础设施可以限制损害范围。当它选择了错误的工具，而你又没有任何恢复模式时，损害就会层层叠加：

• Agent 继续基于错误的工具输出进行推理
• 故障级联至依赖它的其他工具
• 根据幻觉数据做出财务决策
• 如果你没有及时发现，它还会重复这一循环

传统软件的故障通常有明确表现，例如错误码、崩溃或超时；但 Agent 的故障往往表现为质量下降。没有错误信号，只有悄无声息的错误答案。

到了 2026 年 8 月，生产团队逐渐意识到：只有可观测性、却没有恢复基础设施，就如同站在一旁看着火灾发生，而不是将火扑灭。

三种静默失败模式

模式一：确定性循环

Agent 在没有取得任何进展的情况下，反复调用同一个工具。

检测：很容易。在 span N、N+1、N+2 中出现相同的工具调用。

问题在于：你发现了这个循环，但要如何恢复？Agent 被困在一个无法终止的推理分支中。观测系统只能告诉你它已经发生；基础设施则应该告诉你原因、暂停执行，并让你进行修复。

模式二：上下文遗失

Agent 在会话进行到一半时幻觉出一个事实，并在此基础上继续做出决策。

示例：Agent 正确检索到一个客户 ID，开始进行推理，随后却使用另一个 ID 调用工具——这个错误 ID 来自已经损坏的内部记忆。工具返回了错误客户的数据，此时 Agent 已经开始基于被污染的状态进行推理。

整个过程没有任何错误信号，只有输出质量在悄无声息地下降。会话可以正常运行至结束，却仍然返回错误答案。

模式三：凭证或能力越界

Agent 发现自己拥有某项凭证，却试图将其用于授权范围之外的操作。

这是一个架构问题。如果凭证管理系统没有强制实施目标绑定（destination-pinning），Agent 就可能尝试窃取或外传数据。更糟糕的是，它们往往能够悄无声息地成功：工具调用顺利执行、返回数据，Agent 随后继续处理这些数据。

真正具备恢复能力的生产基础设施

那些成功跨越臭名昭著的“从试点到生产有 88% 失败率”鸿沟的团队，构建了以下三层能力：

第一层：基于 Session 的执行机制（确定性边界）

Agent 在有明确边界的 Session 中执行。Session 不可变、按 Agent 隔离，并受到凭证作用域约束。

当 Agent 试图越权使用凭证时，vault proxy 会通过目标绑定拒绝请求。当 Agent 陷入循环时，步骤限制器会在第 50 轮暂停执行，而不是等到第 500 轮。当 Agent 产生幻觉时，Session 历史不可变，因此你可以精确重放整个过程，还原究竟发生了什么。

如果没有这一层：Agent 可能循环 200 个步骤；可能为了窃取数据而调用某个工具 50 次；甚至在你察觉之前，凭证越界就已经成功。

第二层：确定性的工具授权（调用层）

工具调用会在执行之前接受验证，而不是执行之后：

Agent proposes: call_tool(name="get_customer", id="cust_123")
Vault proxy checks:
  - Is agent authorized for get_customer?
  - Is cust_123 within this agent's data scope?
  - Within rate limits?
Only if all checks pass → tool executes

如果没有这一层：工具会直接执行并返回错误，Agent 重试 5 次，最终甚至可能幻觉出一种绕过方案。

第三层：检测后自动暂停与恢复

当可观测系统检测到故障信号时，例如无限循环、同一工具调用超过 N 次或成本激增，系统不会继续等待：

• 在下一轮暂停执行
• 冻结 Session 状态，不再允许任何变更
• 触发告警，并附带完整的 Session 上下文
• 人工检查后，可以修改记忆或上下文，然后恢复执行或回滚

如果没有这一层：团队可能在 2 小时后才发现故障，而 Agent 早已基于损坏的状态做出决策。

以 Eval 驱动恢复的闭环

可观测性与恢复能力在这里汇合：

• 生产环境观测：Agent 反复调用 fetch_data，陷入循环。
• 暂停并冻结：暂停 Session，锁定状态。
• Eval 诊断：Eval 框架针对被冻结的 Session 运行检查：“第 5 轮的上下文是否完整？Agent 是否掌握了足以继续推进的信息？”
• 恢复操作：如果上下文不完整，则修改记忆，并从第 6 轮恢复执行。
• 迭代验证：使用诊断问题的同一套 Eval，测试恢复操作是否有效。

采用这种方式的团队，正在从“希望 Agent 不要失败”转向“清楚 Agent 失败时该如何恢复”。

五个问题，判断你的恢复就绪程度

• 能否在不丢失状态的情况下，暂停正在执行的 Agent？
• 工具调用是否在执行前接受验证，而不是执行后？
• 能否在任意步骤检查完整的推理链？
• 能否修改上下文或记忆，然后恢复执行？
• Eval 框架能否对冻结的 Session 进行评分，从而诊断根本原因？

只要其中任何一个问题的答案是“否”，你就在手动构建恢复模式。如果五个问题的答案全部是“是”，说明你已经拥有能够从架构层面限制故障范围的基础设施。

真正重要的数据

近期 2026 年关于 Eval 采用情况的数据如下：

• 回滚率（未使用 Eval）：47%
• 回滚率（Eval 全面覆盖）：9%

这 38 个百分点的差距，并不只是 Eval 框架带来的。它体现的是两类团队之间的差异：一类能够观测故障、暂停执行、诊断根本原因并完成恢复；另一类则要在数小时后才能发现故障。

最终成功进入生产环境的 12% 试点项目，并不是部署了更聪明的 Agent，而是部署了具备恢复基础设施的 Agent。

为什么基于 Session 的架构至关重要

LiteLLM Agent Platform 的架构正是为这种模式量身打造的：

• Session 持久化：每次 Agent 运行都由 Postgres 提供持久化支持。即使发生 pod 崩溃、部署或重启，Session 依然能够保留。Agent 失败时，你可以暂停执行、检查完整历史记录、在必要时修改记忆，并从确切的故障点恢复运行。
• Vault proxy 与目标绑定：凭证被限定在特定目标范围内。即使 Agent 发现了一项凭证，也无法将其替换为另一个 endpoint。通过架构设计限制凭证越界的影响范围。
• 按 Agent 授权：每个 Agent 都拥有独立的凭证作用域、工具列表和速率限制。工具通过 proxy 调用，并在执行前完成授权检查。
• 结构化 Session 重放：Session 可以被完整查询。你可以检查 Agent 为何在第 15 步调用工具 X、当时存在什么状态，以及该决策是否合理。由此打通从可观测性到恢复的完整链路。

区分团队能否规模化的关键模式

2026 年 8 月的数据已经非常明确：那些将 Agent 故障恢复视为基础设施问题，而不只是监控问题的组织，才有信心规模化部署多 Agent 系统。

撞上 88% 失败率高墙的团队，并不是因为模型能力不足，而是因为他们选择手动构建恢复模式。那些在 2026 年第四季度成功交付的团队，则采用或自行构建了能够在架构层限制故障范围的基础设施。

当 Agent 遇到边缘情况时——而这必然会发生——这样的基础设施能够阻止故障继续级联。

你的团队正在构建哪些恢复模式？你们是在生产环境运行到第 3 个月时才发现这道鸿沟，还是从第 0 天起就已经将它纳入架构设计？

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。