长程智能体中的陈旧世界模型问题

一个 AI Agent 在第 3 轮读取了一个文件，在第 4 轮到第 30 轮对其内容进行推理，然后在第 31 轮将修改后的版本写回磁盘。然而，该文件在第 17 轮时被另一个进程修改过。Agent 悄无声息地用陈旧的版本覆盖了较新的版本。没有抛出异常，没有触发警报。从外部看，Agent 成功完成了任务。

这就是陈旧世界模型（Stale World Model）问题，它是生产环境中的 Agent 系统中最少被讨论的故障模式之一。与上下文窗口溢出或工具调用失败（这些会表现为错误）不同，世界模型陈旧会导致 Agent 在利用过时信息做出决策的同时，看起来仍在正常运行。这种失败是无声的，通常是不可逆的，并且会随着任务长度的增加而累积。

什么是世界模型，以及它为何会变得陈旧

每个 Agent 都会维护一个对外部现实的隐式模型：它读取过的文件内容、收到的 API 响应、查询过的数据库值、被告知的用户偏好。这个模型是根据工具调用结果逐步构建的，并存在于上下文中。一旦该上下文快照与世界的实际状态发生背离，Agent 就在基于虚假信息进行操作。

发生这种情况有四种不同的机制。

Agent 推理时的外部状态变化。 外部系统不会等待 Agent 完成。数据库行被更新，文件被编辑，配置值被更改，API Schema 版本更新。Agent 在读取状态的那一刻绑定了该状态的早期快照，而没有任何机制通知它该快照现在已经错误了。

累积噪声导致的上下文污染。 随着 Agent 的执行，它们在上下文中积累了工具响应、错误消息、中间推理过程和助手轮次。在第 5 轮看起来像是有用的诊断信息的错误输出，到了第 40 轮基础问题解决后，就会变成严重的误导信息。思维链中出现的幻觉会被下游引用，仿佛它们是事实。一个错误进入记录，之后的每一轮推理都基于受损的前提。

指令离心作用。 Transformer 注意力机制偏向于近期性。在第 1 轮发出的系统提示词指令，到了第 60 轮时获得的有效注意力权重比第 2 轮时要少。目标、约束和行为护栏并没有消失——它们只是随着执行历史的增长而变得越来越“微弱”。这表现为目标漂移（Goal drift）：动作在语法上是有效的，但已逐渐偏离了原始意图。

跨会话失忆。 长期运行的任务通常跨越多个推理会话。Agent 从检查点恢复，读取进度摘要，并将其视为事实——而不去核实底层世界是否与摘要描述的一致。如果会话之间状态发生了变化，且没有人刷新摘要，Agent 就会根据一个已不存在的世界描述进行操作。

错误累积的数学逻辑

这个问题的严重程度是任务长度的函数。单轮 Agent 几乎不受影响：它们读取状态，执行一次操作，然后退出。但运行 20 步、50 步或 200 步的 Agent 则有着完全不同的故障特征。

其底层的数学逻辑是乘法性的。如果每步的可靠性为 85%——这是前沿模型在定义明确的子任务上的合理数值——那么一个包含 10 个步骤的任务成功率仅为 20%。这不只是模型质量问题，而是架构问题。每一步使用陈旧状态作为输入，都有可能产生一个悄悄编码了错误的输出，而该输出又会成为下一步的输入。

经验数据证实了这条曲线的形状。在短期编程任务中，前沿模型的成功率超过 70%。但在相同任务的长期版本中（需要 30 步以上的协调），同样模型的成功率下降到大约 23%。对故障模式的分析发现，这些长期故障中约有 36% 直接归因于上下文漂移和目标漂移，而非模型推理质量。模型推理是正确的；它只是在对一个陈旧的世界图像进行推理。

一项 2026 年关于前沿模型在 AI Agent 任务完成情况的研究发现，在人类认为常规的多步办公任务中，完成率仅在 1.7% 到 24% 之间。Agent 失败并不是因为它们无法推理。它们失败是因为它们无法在任务执行过程中保持其外部状态模型与现实同步。

失败的具体表现

陈旧世界模型故障最糟糕的一点在于它们看起来是多么平淡无奇。以下是三个具体例子。

一个 AI 编程助手被授予了内部文档系统的访问权限。工程师使用它来获取一项重大变更的实现指导。该助手从一个过时的 Wiki 页面检索了建议——该文档在几个月前就被取代了——它提供的指导不仅是错误的，而且与正确流程完全相反。遵循该建议的 Agent 和工程师引入了一个缺陷并传播到了生产环境，在 48 小时内造成了六位数的订单损失。该助手并没有发生故障；它检索到的信息在其世界模型中被视为最新的。

一个被指派“冻结”代码库任务的 Agent，通过从之前会话积累的上下文（包括对已完成的数据迁移步骤的引用）来解读指令。基于它认为有效的未完成工作，它删除了一个包含近 2,500 条记录的生产数据库（代表了九天的手动数据录入），然后生成了合成记录来填补空白——因为它的世界模型认为数据需要以特定的形式存在。没有产生任何错误，任务看起来已完成。

一个在广泛使用的 CLI 工具内存子系统中记录的竞争条件展示了此问题的结构化版本。当 Agent 执行写入操作时，它会读取目标文件以生成供用户批准的预览，然后缓存计划的内容。当用户批准时，缓存的内容被写入磁盘——而没有重新读取文件以检查在预览和执行之间的间隔内文件是否发生了变化。如果文件在读取和写入之间被修改，较新的版本就会被悄悄覆盖。这是一个教科书式的检查时间到使用时间（Time-of-Check to Time-of-Use, TOCTOU）脆弱性，它出现在数百万开发者每天使用的生产工具中。

框架带给你了什么 —— 以及没带给你什么

构建 Agent 最常用的框架在持久化和崩溃恢复方面取得了实质性进展。但在状态新鲜度（state freshness）方面，它们尚未取得可比的进展。

LangGraph 的检查点（checkpointing）系统是目前最成熟的。它将完整的图状态序列化到持久化后端（SQLite、Redis、Postgres），并且 interrupt() 函数创建了显式的人工审核关口。这很好地处理了跨会话场景：从 LangGraph 检查点恢复的 Agent 可以重构其所处的位置。但它无法保证它所恢复到的世界与其检查点所描述的世界相匹配。框架忠实地保存了 Agent 的状态；但它无法保存 Agent 无法控制的外部状态。

Anthropic 的托管 Agent 架构通过分离三个关注点更周全地解决了这个问题：会话（session，一个作为外部事实来源的追加型事件日志）、载具（harness，Claude 循环和工具路由）以及沙箱（sandbox，执行环境）。通过将会话日志作为权威记录——而不是 Agent 的上下文窗口——该架构在“Agent 所相信的”与“实际发生的”之间建立了一种分离。但即便是这样也无法解决外部状态同步问题。如果 Agent 上次读取的文件此后被修改了，没有任何框架能自动检测到这一点。

每个框架共同的缺陷在于：状态管理工具处理持久化和崩溃恢复，但不负责检测持久化状态何时与现实发生了偏离。检查点知道 Agent 相信什么状态，但它不知道该状态是否仍然真实。

五种真正有效的模式

鉴于目前还没有框架能自动解决这个问题，构建长期运行 Agent 的工程师需要显式地实现新鲜度保证。

即时检索优于缓存读取。 与其在第 3 轮读取文件并在接下来的 50 轮中根据缓存结果进行推理，不如存储对资源（文件路径、查询、URL）的引用，并在使用点重新获取。这虽然增加了工具调用开销和延迟，但它消除了一整类过期读取（stale-read）漏洞。对于任何将被写入的资源，在写入前立即重新读取是必选项。

写入前的状态哈希。 为每个具备写入能力的工具实现一个薄包装层，该层读取目标资源的当前状态，计算哈希值，并将其与 Agent 上次读取该资源时观察到的哈希值进行比较。不匹配意味着自 Agent 上次读取以来，资源已被外部修改——此时应中止写入并重新读取。这是将乐观并发控制应用到 Agent 的工具使用中。

为所有检索到的上下文设置 TTL。 Agent 依赖的每一项外部状态都应该带有明确的过期时间。用户偏好可能在数小时内有效；API 模式（Schemas）可能有效数小时；文件内容可能有效数分钟——或者直到写入前夕；实时数据可能仅有效数秒。当 TTL 到期时，Agent 在行动前必须重新获取。要区分数据类型；单一的全局策略要么过于激进（不断重新获取稳定数据），要么过于宽松（对易变资源保留过期数据）。

在决策边界设置漂移包络（Drift envelopes）。 在执行任何产生副作用的操作之前，Agent 应该验证一组定义好的不变量是否仍然成立。这可以实现为一个结构化的预检（Pre-flight check）：

• 资源的哈希值是否与我上次读取时一致？
• 我即将调用的 API 模式是否发生了变化？
• 我被授予的权限是否仍然有效？

如果任何检查失败，应中止并重新读取，而不是基于过期的假设继续进行。对于高风险操作——写入、外部 API 调用、金融交易——应将此预检视为强制性而非可选。

事件驱动协作优于共享可变状态。 当多个 Agent 或服务共享状态时，最安全的架构是 Agent 响应事件而不是轮询共享资源。Agent A 发出一个完成事件；Agent B 在收到该事件时开始运行。这消除了两个 Agent 同时读取、修改和写入同一资源的竞态窗口。从共享状态迁移到事件驱动协作的工程团队报告称，竞态条件和过期上下文漏洞大幅减少——而这正是世界模型陈旧性所导致的故障类别。

核心原则

这些模式背后所需的底层转变是：在每次访问时都将外部状态视为不可信的——而不只是在会话开始时。

经验丰富的后端工程师会自动将此原则应用于分布式系统。你不会无限期地缓存数据库行并假设它没有改变；你不会在启动时只读取一次配置文件后就再也不读。你设计系统时会考虑到你观察到的状态可能不是当前存在的状态。

Agent 开发者往往没有应用同样的纪律，因为 Agent 的世界模型感觉像是内部状态。但它不是。它是外部状态的一个快照，缓存由于上下文窗口内，带有大多数系统从未显式化的隐式 TTL。

你的 Agent 对世界持有的每一个假设都有有效期。无论是文件内容、API 模式、用户偏好还是组织的审批层级——该假设在捕获的那一刻是真实的，但此后一直在退化。构建生产级 Agent 意味着构建能够使该过期时间显式化、在采取重大行动前进行检查、并以足够低的成本频繁刷新的系统。

在长任务跨度下保持可靠的 Agent，并不是那些在孤立状态下推理能力更强的 Agent。而是那些能够正确判断其世界观是否仍值得信任的 Agent。