AI Agent 的失败根源不在推理，在于状态管理

TL;DR — 大多数 agent 失败被归咎于推理能力差，但真正的罪魁祸首通常是编排循环将聊天记录当作真理。聊天记录是有损压缩，将有损压缩后的状态进行重新规划会在每次迭代中几何级地放大错误。修复方法是架构层面的：将记忆与信念分离，对已验证状态打检查点，并限制循环在未验证假设下可以运行的时间。

当一个 agent 失控——订错了航班、删错了文件、无休止地循环调用已经成功的工具——事后分析几乎总是把锅甩给模型。"它产生了幻觉。""它没有仔细推理。""我们需要更聪明的基础模型。"这种诊断很让人安心，因为那是别人要去解决的问题。但它通常也是错的。

在大量生产环境的 agent 事故中，真正的失败点位于编排循环，而非模型的推理能力。具体来说：循环将自己的聊天记录当作关于世界的真相来源，但聊天记录是对实际发生事情的有损、人类可读的压缩。每一次重新规划的步骤都是从那个压缩版本中重新推导意图和状态。早期引入的错误不会保持不变——它们会不断累积。

聊天记录不是状态

几乎每个 agent 框架——ReAct 风格的循环、计划-执行-反思模式、多 agent 编排器——都使用相同的基础机制：向一个持续运行的上下文追加一条观察结果，把整个上下文反馈给模型，让模型决定下一步行动。这很优雅，也是这个模式四处流行的原因。但这也是一种类别错误。

聊天记录记录的是 agent 所说的发生的事情，经过了工具输出在传入过程中被摘要、截断或改写的过滤。它不是数据库。它没有模式、没有不变量、没有办法区分"API 调用返回了这个确切的 JSON"和"模型在几个回合前对这个 JSON 的概括"。一旦工具结果被压缩以适应上下文预算，该摘要就成为每个后续决策的新真理——即使没有人验证过这个摘要是否准确。

这在单个回合内没问题。在十个回合之后就成问题了。一个文件列表被压缩成"目录里有几个配置文件"在一个回合内是合理的压缩。但到了第五个重新规划周期，一个行动是基于"只有几个配置文件"这个假设做出的——而实际数量很重要，却从未被重新检查。

为什么编排框架让问题更糟，而不是更好

为使 agent 更强大而构建的工具往往放大了这个确切问题。添加"记忆"的框架通常指的是两件事之一：更长的上下文窗口，或者一个检索语义相似历史片段的向量存储。两者都不能恢复真相。更长的窗口只是推迟了必须进行摘要的时刻。检索层返回的是过去观察的最相关片段，而不是已验证的当前状态——它是记忆的记忆。

多 agent 编排以不同方式叠加了这个问题。当一个规划 agent 将子任务交给工作 agent，并收到工作 agent 做了什么的人类语言报告时，规划 agent 再次基于摘要运作——这次是由另一个模型生成的，这个模型有自己的动机让自己听起来自信和完整。把三四个 agent 串联起来，你就得到了一个附加了工具调用的传话游戏。每一跳都从前一跳的文本中重新推导信念，而链条中没有任何人在将文本与实际系统状态进行核对。

失败模式不是"模型糊涂了"。而是架构从未给任何组件提供一种方式在行动前问"这仍然是真的吗？"

错误几何级累积，而非线性

这一点很重要，因为它改变了你对 agent 可靠性工程的思考方式。单个工具调用 95% 的成功率单独看似乎不错。通过一个规划循环串联八个这样的调用——每一步的计划都依赖于前一步摘要状态的准确性——你面对的不是 0.95，而是接近 0.95 的八次方，对于独立部分而言——对于非独立部分更糟，因为循环早期的糟糕摘要不会只失败一次，它会腐蚀每一个后续步骤推理所依据的前提。

这就是 agent 演示看起来很棒而生产 agent 系统令人失望的深层原因。三步演示很少碰到累积区域。一个无人值守运行一小时的二十步 agent 完全处于累积区域之中。失败不是稀有边缘情况堆积——而是基于未验证状态重新规划的几何特性成为可靠性方程中的主导项。

真正有效的修复

修复不是更聪明的模型。而是将 agent 框架混为一谈的两样东西分开：关于发生了什么事的记忆，和关于当前世界状态的信念。记忆可以是有损的——它用于叙事连续性，让模型能够连贯地解释自己的行为。信念不能有损，因为每一个行动都基于它。

具体来说，这意味着：

结构化状态，而非文本状态。 维护一个显式的状态对象——文件计数、记录 ID、确认令牌、账户余额——仅通过已验证的工具输出更新，绝不通过模型的转述更新。模型每轮读取这个对象，而不是从上下文重新推导它。

在有后果的行动之前重新获取。 任何具有现实世界副作用的行动（写入、支付、删除）都应该在之前触发对相关状态的全新读取，而不是依赖几个回合前的读取。这相当于 agent 的乐观锁。

限制循环深度以对抗未验证假设。 如果一个计划已经运行了 N 次迭代而没有经过真相检查点的验证，强制执行一次重新接地步骤或升级给人类，而不是让循环继续从前面的猜测中推断。

将摘要视为可命名、可测试的操作。 如果你压缩工具输出以节省上下文，该压缩步骤值得与 RAG 中的检索步骤同等的审视——编写测试来检查摘要是否保留了下游计划所依赖的事实，而不仅仅是检查它读起来是否流畅。

这一切都不需要更聪明的模型。它需要承认"agent 可靠性"在很大程度上是一个穿着推理问题外衣的状态管理问题。业界本能地是用更大的上下文窗口或更有能力的基础模型来对付不稳定的 agent，这在边际上有时有帮助。但一个推理完美的模型，如果被喂的是一幅过时的或被转述的世界图景，仍然会自信地采取错误的行动——因为从它所处的位置来看，那个转述就是世界。

令人不安的暗示

如果这个论点是正确的，那么很多 agent 基准测试测量的就是错误的东西。单轮工具使用准确率几乎无法说明一个循环在二十次迭代中是否能保持稳定，因为失败模式只有在状态有足够时间从信念中漂移时才会出现。对生产 agent 真正重要的基准测试是那些运行时间足够长以使累积效应显现的测试，并且特别要在循环中注入状态变化来观察 agent 是否注意到它的世界图景已经过时。大多数当前的评估没有这样做，这就是为什么这么多在演示中看起来很棒的 agent 在无人值守运行的第二周悄悄失败的部分原因。