任务很简单：把一个加热后的杯子放进柜子。一个智能体先把杯子放进微波炉，再放进柜子，随后陷入反复查看柜子的循环。这个无效行为重复了 36 次，直到耗尽行动预算，任务仍然没有完成。
漏掉的是加热这一步。这是论文在 ALFWorld 仿真任务中展示的一个真实案例：使用完整交互历史的 Raw Trajectory 基线用完 50 步仍然失败，而 PoS 在 17 步内完成了同一任务。动作一直在发生，关键要求却始终没有被满足。
图 1：加热杯子任务中的两条执行路径。原始轨迹基线漏掉加热环节后持续查看柜子；PoS 显式保留尚未完成的加热要求，并在停滞时引导恢复。
智能体仍在调用工具、接收观察、生成下一步计划，看起来始终在工作，但“把杯子加热”这一关键要求始终没有得到推进。类似的困境也出现在其他交互任务中：GUI Agent 反复点击，界面却停留在原处；Coding Agent 一遍遍读取相同文件，迟迟没有进入有效的修改与验证。操作记录不断增加，尚未解决的问题却依然存在。这些场景共同提出了一个问题：系统能否在预算耗尽之前，判断当前行动是否仍在推进关键要求，并在进展停滞时调整行动方向？
南开大学联合阿里云等机构的研究团队，将这一问题明确为 Belief Trapping（信念受困）：智能体持续与环境交互，但与目标相关的信念演化已无法带来有意义的任务进展。它既可能表现为原地重复，也可能是在几个状态间循环，或不断探索却没有触及真正未解决的问题。
为此，研究团队提出 PoS（Progression of States）。它持续维护显式信念状态，记录当前世界与未解决要求。在此基础上，用 Belief Health 衡量任务进展，在检测到受困后，依据受困模式与缺口类型实施 Trapping-Aware Recovery。从识别“已经卡住”到决定“怎样恢复进展”，构成了 PoS 的核心闭环。
在四个基准、三个基础模型组成的 12 组实验设置中，PoS 的整体指标均高于论文纳入比较的其他方法。这个结果背后的问题也很具体：怎样把“Agent 忙了很久，却没做成事”转化为可计算、可诊断、可干预的过程？
论文标题：Beyond Memory: Harnessing Long-Horizon Agents with Explicit Belief States
研究机构：南开大学、阿里云、清华大学
论文地址：https://arxiv.org/abs/2610.01415
项目主页：https://luoyu100.github.io/projects/progression-of-states/project/
开源代码：https://github.com/luoyu100/PoS
历史越来越长，当前状态却未必越来越清楚
Cloud Native
长程任务中的信息会过时。杯子刚才在微波炉里，现在可能已经被拿走、一次工具调用表达了要做什么，返回的观察才能说明实际发生了什么、前几轮看似合理的判断，也可能被新证据推翻。
完整轨迹保留了事情发生的顺序，记忆和压缩机制则帮助筛选、整理这些记录。它们提供了重要的证据基础。但每次选动作时，智能体仍需要把分散的信息重新拼成对当前任务的理解，确定哪些结论继续成立，哪些已经失效。
PoS 把这一步显式化。这里的“信念”指智能体基于已有证据形成的当前理解，其中既有直接观察，也有仍待检验的推断。它可以被更新、被检查，也可能出错。要判断任务有没有推进，首先要有一份能够跨时间比较的当前状态。
把当前世界和剩余要求放进同一份状态
Cloud Native
第一步是明确“现在是什么情况”。PoS 用实体、状态和关系组织与任务相关的世界：杯子、微波炉和柜子是实体，杯子是否热、微波炉是否关闭是状态，杯子位于哪里、由谁拿着，则通过关系表达。状态和关系还保留来源、置信度，以及可用的支持证据，方便后续核对。
这份表示只保留会影响行动、结果判断和目标完成的信息。例如，加热杯子的任务需要记住温度与位置，单纯记录“曾经操作过微波炉”并不够。
第二步是明确“还差什么”。PoS 把未解决的要求分成两类：信息缺口（Epistemic Gap）是还需要弄清楚的事，达成缺口（Achievement Gap）是还需要通过行动改变的事。如果没有证据确认杯子是否变热，就需要补充信息，如果已经知道杯子未加热，就需要真正完成加热。
这一划分也适用于诊断。排查服务故障时，“数据库等待还是 JVM 内部处理造成延迟”是一个信息缺口。下一步应当寻找能区分两种解释的证据，而不是继续收集与判断无关的日志。
面对多个未解决要求，PoS 会选定一个当前优先处理的 Active Gap。智能体仍然可以看到完整的任务状态，但行动有了明确焦点，这个缺口解决后，再推进到后续要求。
图 2：PoS 的整体流程。左侧构建当前世界和未解决要求，中间围绕 Active Gap 选择动作，底部的 Belief Sentinel 检查更新并记录进展，右侧在受困时生成临时恢复约束。
写下来的状态，也要经得起证据检查
Cloud Native
显式记录状态之后，还需要解决一个问题：这份状态本身也是模型生成的。如果它把错误判断写进去，后续决策就可能持续沿着错误的前提展开。
因此，一次行动返回新观察后，PoS 先生成候选更新，再交给 Belief Sentinel 检查。它主要核对两件事：内部是否自洽，以及更新是否得到交互证据支持。比如，同一个微波炉不能同时被记为打开和关闭，只看到杯子被放入微波炉，也不足以把“已经加热”写成确定事实。
发现问题后，智能体结合证据修正更新，经过校验的状态才进入后续决策。公开实现中，如果修复后仍未通过检查，就保留此前已提交的状态。这也为受困检测提供了前提：先核对状态变化是否可信，再判断这些变化是否构成进展。
不过，内部自洽、与观察相容，并不意味着任务一定在前进。智能体完全可能准确记住“杯子还没热”，然后继续查看柜子。识别 Belief Trapping，需要把视线从某一次正确记录，移到一段时间内的信念变化。
Belief Trapping 如何成为一个可计算的问题
Cloud Native
不能仅凭动作重复，就认定智能体已经受困。相同工具的多次调用可能在收集不同证据，反过来，每一步都换工具，也可能一直绕开关键问题。PoS 因此关注的是：未解决要求持续存在时，经过校验的信念是否仍在发生有助于任务的变化。
它先为每次状态转移标记进展，再在最近 K 次经过校验的转移上观察三个信号。执行任务的单步进展，包括缩小当前缺口、获得必要信息，或推进一条合理的完成路径。诊断任务则看相关推断的置信度是否发生超过阈值的变化。置信度降低也可能代表排除了错误解释，因此同样计入变化。
基于这三个互补信号，PoS 构建了一个可解释的启发式指标 ——Belief Health（信念健康度）：
这里，E、A 分别表示信息缺口与达成缺口，健康度越低，受困信号越强。组合遵循的原则是：持续未解决的要求，与进展停滞或信念重复共同出现时，形成较强的受困信号。内层 max 保留停滞与重复中较强的异常，避免一种明显迹象被另一种较弱迹象稀释；乘以缺口持续度，将异常与长期未解决的要求关联起来；外层 max 则关注两类缺口中受阻更明显的一类。因此，任务尚未完成并不会单独触发受困判断，而部分单步获得正向进展标签，也不能掩盖持续存在的状态循环。
图 3：同一任务在不同阶段的健康度示意。前一个窗口仍有中间进展，后一个窗口只剩持续未解决的要求与重复状态。
论文设置在积累 8 次经过校验的转移后启动检测，当信念健康度 Hₜ ≤ 0.25 时，进入受困诊断。
Trapping-Aware Recovery
把受困诊断变成行动约束
Cloud Native
健康度回答了“是否需要干预”，恢复机制还要回答“该改变哪段行为，以及恢复什么进展”。PoS 将诊断拆成两个维度。
第一个维度是行为模式。Static 表示世界状态局部不变，Cycle 表示在先前出现过的状态间周期性循环，Drift 表示世界状态虽然变化，与当前缺口相关的部分却没有推进。判定按上述顺序进行，无法匹配具体模式时使用通用恢复。
第二个维度是被阻塞的缺口类型。PoS 比较非空信息缺口与达成缺口的持续度，选取更顽固的一类：前者需要能区分解释的新证据，后者需要真正改变任务状态。相同的“原地停滞”，可能分别要求换一种调查方向，或者执行一直被遗漏的动作。
公式中的 
表示受困模式，
表示检测窗口，X 是被阻塞的缺口类型，Bₜ 与 Δₜ 分别是当前信念和 Active Gap。两组约束共同作用：模式约束负责打破无效行为，缺口约束负责明确下一步必须恢复的进展。
图 4：受困诊断同时考虑行为模式与缺口类型。每个格子组合“如何打破当前行为模式”和“需要恢复哪一种进展”，形成对下一步动作的约束。
因此，对原地停滞，约束会抑制无效的状态 — 动作重复，对循环，打破重复转移，对偏离目标，重新对齐 Active Gap。它们还要与另一条要求配合：取得有区分力的证据，或产生与目标有关的状态改变。以杯子任务为例，只让智能体“别再查看柜子”仍不充分，还需要让后续动作推进“杯子变热”这一未完成要求。
恢复约束作为额外条件交给原来的智能体，由它继续选择动作，当前 Active Gap 保持不变。每次新转移经过校验后，系统重新计算健康度：高于阈值就释放临时约束，仍然受困则更新诊断与约束。受困检测、约束生成和恢复后的重新评估，共同构成了一个持续闭环。
论文中的 RCA-100 案例 t024 展示了这一过程。Kimi-K3 智能体已经发现 inventory 服务的慢请求与垃圾回收活动升高同时出现，却迟迟无法区分数据库等待和 JVM 内部处理两种解释。PoS 识别出“原地停滞＋信息缺口”，要求停止无效重复，寻找能够区分两种解释的证据。
智能体随后选择检查 CPU 活动。恢复过程中间仍经历了三次低进展动作，之后获得的 CPU 证据与已有垃圾回收观察共同促成了信念修订。该次运行共执行 28 个动作，最终提交的 inventory /memoryPressure 同时匹配基准标注的故障实体与类型。
四类任务，三个模型，提升是否能够重复出现
Cloud Native
研究团队在两类任务上评估 PoS。ALFWorld 和 LOCA-Bench 要求智能体通过多轮操作完成目标，RCA-100 和 ClinDiag 则要求智能体持续获取证据，完成故障或医学诊断。四个基准分别评估 134、525、103 和 604 个案例，其中 LOCA-Bench 的整体结果汇总了七种环境描述长度。
实验使用 Qwen3.7-Plus、Kimi-K3 和 GLM-5.3。对每个基础模型，PoS 的执行、信念维护和校验组件都使用同一模型，比较方法覆盖完整轨迹、ACON、PACE、HiAgent，以及显式维护任务状态的 LongHorizon-Harness。PoS 无须为这些任务更新基础模型参数。
图 5：论文 teaser 左侧的四基准对比。每组为同一基础模型下的最强对照与 PoS；图标依次对应 Qwen3.7-Plus、Kimi-K3 和 GLM-5.3。ALFWorld、LOCA-Bench 为任务成功率，RCA-100 为故障类型与实体联合准确率，ClinDiag 为诊断准确率。各面板纵轴范围不同，具体数值见柱顶标注。
PoS 在全部 12 组“基准 × 模型”设置中取得了文中比较方法里的最高整体指标。以 Qwen3.7-Plus 为例，ALFWorld 从最强对照的 72.39% 提升至 88.81%，增加 16.42 个百分点，对应 22.68% 的相对提升；RCA-100 联合准确率从 28.16% 提升至 38.83%，增加 10.67 个百分点，对应 37.89% 的相对提升。
这组结果同时覆盖了“让世界发生目标所需的改变”和“通过证据逐步明确判断”两种任务结构。进一步的消融与恢复对照，则用来检验：持续校验状态、识别受困并施加针对性约束，各自带来了什么。
维护状态的两个环节，都有作用
Cloud Native
表 1：Qwen3.7-Plus 下的一致性校验与受困诊断恢复消融。数值为各基准整体指标，单位为百分比。移除一致性校验、或移除受困诊断及其恢复后，四个基准均出现下降。
在 Qwen3.7-Plus 上，移除一致性校验后，ALFWorld 从 88.81% 降至 73.88%，LOCA-Bench 从 56.38% 降至 44.57%。执行任务需要频繁协调环境变化与新观察，这组结果说明，保持状态更新可靠对这类任务尤其重要。
移除受困诊断及恢复后，Qwen3.7-Plus 的 RCA-100 联合准确率从 38.83% 降至 33.98%，三个模型在这一基准上的降幅为 4.85 至 6.79 个百分点。校验帮助智能体维护有依据的理解，恢复则在当前调查路线不再有效时，把动作重新导向未解决要求。
恢复方式本身也有区别。论文进一步保留受困检测，把具体的恢复约束换成通用的“请尝试恢复”提示，在 Qwen3.7-Plus 的四个基准上，PoS 的针对性恢复都取得了更高的最终任务指标。
图 6：不同任务的受困模式与恢复效果。上图展示检测到的受困事件中各模式的占比；
下图对比 Qwen3.7-Plus 使用通用恢复提示和 PoS 针对性恢复时，在全部评测案例上的最终任务指标。
这种针对性与任务差异相对应：ALFWorld 的受困事件中循环最常见，RCA-100 中偏离当前目标的 Drift 占比为 55.93%，ClinDiag 中原地停滞的 Static 占比为 78.25%。只让智能体“换个办法”，未必能说明它究竟应当换掉哪段行为，以及需要补齐什么。
当环境描述增长到 256k
Cloud Native
LOCA-Bench 还提供了一个压力测试：把环境描述从 8K 扩大到 256K tokens，观察智能体能否在更长上下文中完成任务。随着长度增加，各方法的表现总体下降。PoS 在 96K 至 256K 区间的表现相对稳定，在 256K 设置下，三个模型分别比同设置的最强对照高出 10.67 至 16.00 个百分点。
图 7：LOCA-Bench 上，环境描述由 8K 增长到 256K 时的任务成功率。
蓝色实线为 PoS，横轴表示环境描述长度（8K-256K）。
这一结果与 PoS 的设计思路相符：每次收到新观察，就更新现有的任务状态，后续决策可以围绕当前条件展开，减少从长历史中反复重建任务状态的需要。随着背景信息增多，持续维护哪些信息仍然影响当前决策，变得更加重要。
更可靠的状态维护，也有计算代价
Cloud Native
PoS 把额外的推理计算用于信念构建、更新和校验。论文在 RCA-100、Qwen3.7-Plus 设置下统计了每个案例的平均输入与输出 token 总量，结果显示了这项投入的实际代价。
表 2：RCA-100 上 103 个案例的平均开销。执行智能体对应 Task Agent；
方法总量还包括信念构建与 Sentinel，K 表示千 tokens。
在 RCA-100、Qwen3.7-Plus 设置下，PoS 将联合准确率从原始轨迹基线的 24.27% 提升至 38.83%，方法总 token 消耗达到原始轨迹基线的 5.06 倍。其中，执行智能体本身的 token 消耗减少约 20.9%，额外开销来自信念维护与 Sentinel 。PoS 在这组实验中体现了更高诊断准确率和额外推理投入与诊断准确率之间的取舍。
PoS 仍然依赖基础模型理解证据的能力。信念健康度用于识别进展停滞，并不直接验证最终答案。即使状态内部一致，与已有观察相容，仍可能包含因领域知识不足而形成的错误判断。论文讨论了两条后续方向：用更紧凑的潜在世界状态表示减少反复生成文本的开销，以及在状态更新中引入领域知识检索，帮助模型解释专业证据。
回到开头的杯子任务，36 次无效查看把问题暴露得很清楚：当智能体仍在行动时，系统需要有能力判断进展是否已经停下。PoS 将 Belief Trapping 明确为需要检测和干预的状态，用显式信念提供观察基础，用健康度识别停滞，再让恢复约束指向真正未解决的要求。
PoS 的代码已开源，提供完整框架、原始轨迹基线、两种消融配置，以及方法说明和复现指南。项目页还提供进展监测、受困恢复和执行案例的交互演示。
本文第一作者罗宇，南开大学智能运维课题组博士二年级，师从孙永谦副教授，目前在阿里云担任算法实习生。他的研究聚焦长程、多轮交互中的信念状态与主动推理，以及自进化智能体，结合大模型推理、记忆、检索增强和强化学习构建协作式多智能体系统。已在 ICML、EMNLP、KDD、ASE、TOSEM 等会议与期刊发表 10 篇论文，代表工作包括 Graph of States（ICML 2026）和 OpsAgent（ASE 2026）。
本文通讯作者孙永谦，南开大学软件学院副教授、博士生导师，长期从事智能运维（AIOps）研究，关注云原生、数据中心、超算与智算等场景中的故障机理，同时开展多智能体协作与大模型推理优化研究，推动面向复杂系统的智能决策。
