跳转至

PoS:用显式信念状态识别并打破 Belief Trapping

📊 Level ⭐⭐ | 13.9KB

核心命题:把"Agent 忙了很久却没做成事"变成可计算、可诊断、可干预的过程

南开大学、阿里云、清华大学提出 Belief Trapping(信念受困):智能体持续与环境交互,但与目标相关的信念演化已无法带来有意义的任务进展——表现为原地重复、在若干状态间循环,或不断探索却没触及真正未解决的问题。论文《Beyond Memory: Harnessing Long-Horizon Agents with Explicit Belief States》(arXiv:2610.01415,github.com/luoyu100/PoS)的回答是 PoS(Progression of States):持续维护显式信念状态,用 Belief Health 衡量任务进展,检测到受困后按受困模式与缺口类型实施 Trapping-Aware Recovery。

论文用 ALFWorld 的真实案例点题:把加热后的杯子放进柜子——智能体先把杯子放进微波炉再放进柜子,随后陷入"反复查看柜子"的循环,无效行为重复 36 次直到耗尽行动预算,漏掉的是"加热"这一步;使用完整交互历史的 Raw Trajectory 基线用完 50 步仍失败,PoS 在 17 步内完成同一任务。同类困境在 GUI Agent(反复点击而界面停在原处)与 Coding Agent(一遍遍读同一文件却不进入有效修改与验证)上重复出现,共同问题是:系统能否在预算耗尽之前判断当前行动是否仍在推进关键要求。

为什么"历史越来越长"不等于"当前状态越来越清楚"

长程任务中的信息会过时:杯子刚才在微波炉里、现在可能已被拿走;一次工具调用表达"要做什么",返回的观察才说明"实际发生了什么";前几轮看似合理的判断也可能被新证据推翻。完整轨迹保留顺序、记忆与压缩帮助筛选整理——它们提供证据基础,但每次选动作时智能体仍需把分散信息重新拼成对当前任务的理解,判断哪些结论继续成立、哪些已经失效。PoS 把这步显式化:这里的"信念"指智能体基于已有证据形成的当前理解(既有直接观察,也有仍待检验的推断),可以被更新、被检查,也可能出错。

机制一:把当前世界与剩余要求放进同一份状态

  • 世界表示:用实体(杯子、微波炉、柜子)、状态(杯子是否热、微波炉是否关闭)、关系(杯子位于哪里、由谁拿着)组织与任务相关的世界;状态与关系保留来源、置信度与可用支持证据以便后续核对。只保留会影响行动、结果判断与目标完成的信息——加热任务需要记住温度与位置,"单纯记录曾经操作过微波炉并不够"。
  • 未解决要求分两类:信息缺口(Epistemic Gap)=还需要弄清楚的事;达成缺口(Achievement Gap)=还需要通过行动改变的事。若没有证据确认杯子是否变热就需补充信息;若已知杯子未加热就需真正完成加热。该划分同时用于诊断:排查服务故障时"数据库等待还是 JVM 内部处理造成延迟"是信息缺口,下一步应寻找能区分两种解释的证据,而不是继续收集与判断无关的日志。
  • Active Gap:面对多个未解决要求时选定一个当前优先处理的缺口;智能体仍能看到完整任务状态,但行动获得明确焦点,该缺口解决后再推进后续要求。

机制二:Belief Sentinel——写下来的状态要经得起证据检查

显式记录状态后还有一个隐忧:这份状态本身也是模型生成的,错误判断写进去会让后续决策持续沿错误前提展开。因此一次行动返回新观察后,PoS 先生成候选更新,再交给 Belief Sentinel 核对两件事:①内部是否自洽(同一个微波炉不能同时被记为打开和关闭);②更新是否得到交互证据支持(只看到杯子被放入微波炉,不足以把"已经加热"写成确定事实)。发现问题后结合证据修正,经过校验的状态才进入后续决策;公开实现中若修复后仍未通过检查,则保留此前已提交的状态。这也为受困检测提供前提:先核对状态变化是否可信,再判断这些变化是否构成进展——但内部自洽、与观察相容并不保证任务在前进(智能体完全可能准确记住"杯子还没热",然后继续查看柜子)。

机制三:Belief Health——把 Belief Trapping 变成可计算问题

不能仅凭动作重复就认定受困:相同工具的多次调用可能在收集不同证据;反过来每一步都换工具,也可能一直绕开关键问题。PoS 因此关注的是未解决要求持续存在时,经过校验的信念是否仍在发生有助于任务的变化:先为每次状态转移标记进展,再在最近 K 次经过校验的转移上观察三个互补信号——执行任务的单步进展(缩小当前缺口、获得必要信息,或推进一条合理的完成路径)、诊断任务中相关推断的置信度是否发生超过阈值的变化(置信度降低也可能代表排除了错误解释,同样计入变化),以及第三个推进/重复信号。

三者组合成可解释的启发式指标 Belief Health(信念健康度)Hₜ(E、A 分别为信息缺口与达成缺口,健康度越低受困信号越强)。组合原则:持续未解决的要求与进展停滞或信念重复共同出现时形成较强受困信号——内层 max 保留停滞与重复中较强的异常(避免一种明显迹象被较弱的稀释)、乘以缺口持续度把异常与长期未解决要求关联、外层 max 关注两类缺口中受阻更明显的一类。由此得到两个反直觉但关键的判断规则:任务尚未完成本身不会单独触发受困判断;部分单步获得正向进展标签,也不能掩盖持续存在的状态循环。论文的设置是积累 8 次经过校验的转移后启动检测,当 Hₜ ≤ 0.25 时进入受困诊断。

机制四:Trapping-Aware Recovery——把受困诊断变成行动约束

健康度回答"是否需要干预",恢复机制回答"该改变哪段行为、恢复什么进展"。诊断拆成两个维度:行为模式(Static 世界状态局部不变 / Cycle 在先前出现过的状态间周期性循环 / Drift 世界状态虽变化但与当前缺口相关的部分没有推进;按此顺序判定,无法匹配时用通用恢复)与被阻塞的缺口类型(比较非空信息缺口与达成缺口的持续度,取更顽固的一类:前者需要能区分解释的新证据,后者需要真正改变任务状态)。同一个"原地停滞"可能分别要求换一种调查方向,或执行一直被遗漏的动作——模式约束负责打破无效行为,缺口约束负责明确下一步必须恢复的进展(原地停滞则抑制无效的"状态-动作"重复、循环则打破重复转移、偏离目标则重新对齐 Active Gap)。

恢复约束作为额外条件交回原来的智能体,由它继续选动作,当前 Active Gap 保持不变;每次新转移经校验后重新计算健康度,高于阈值即释放临时约束、仍然受困则更新诊断与约束——受困检测、约束生成与恢复后重新评估构成持续闭环。论文的 RCA-100 案例 t024 展示了这条链路:Kimi-K3 已发现 inventory 服务慢请求与垃圾回收活动升高同时出现,却无法区分"数据库等待"与"JVM 内部处理";PoS 识别出"原地停滞+信息缺口",要求停止无效重复、寻找能区分两种解释的证据,智能体随后选择检查 CPU 活动;恢复过程中间仍经历三次低进展动作,之后 CPU 证据与已有垃圾回收观察共同促成信念修订。该次运行共 28 个动作,最终提交的 inventory /memoryPressure 同时匹配基准标注的故障实体与类型。

实验:四类任务、三个模型、12 组设置全胜

设置:ALFWorld 与 LOCA-Bench 要求多轮操作完成目标(134 / 525 案例,LOCA-Bench 汇总七种环境描述长度),RCA-100 与 ClinDiag 要求持续获取证据完成故障或医学诊断(103 / 604 案例);基础模型 Qwen3.7-Plus、Kimi-K3、GLM-5.3,每个基础模型下 PoS 的执行、信念维护与校验组件使用同一模型;对照方法覆盖完整轨迹(Raw Trajectory)、ACON、PACE、HiAgent,以及显式维护任务状态的 LongHorizon-Harness;PoS 无须为这些任务更新基础模型参数。

主结果:PoS 在全部 12 组"基准 × 模型"设置中取得文中比较方法里的最高整体指标(ALFWorld、LOCA-Bench 为任务成功率,RCA-100 为故障类型与实体联合准确率,ClinDiag 为诊断准确率)。以 Qwen3.7-Plus 为例:ALFWorld 从最强对照 72.39% → 88.81%(+16.42pp,相对 +22.68%);RCA-100 联合准确率 28.16% → 38.83%(+10.67pp,相对 +37.89%)——同时覆盖"让世界发生目标所需的改变"与"通过证据逐步明确判断"两种任务结构。

消融与对照:移除一致性校验后 ALFWorld 88.81% → 73.88%、LOCA-Bench 56.38% → 44.57%(说明状态更新可靠对需要频繁协调环境变化与新观察的执行任务尤其重要);移除受困诊断及其恢复后 RCA-100 38.83% → 33.98%,三个模型在该基准降幅 4.85-6.79pp;保留检测但把针对性约束换成通用的"请尝试恢复"提示时,Qwen3.7-Plus 四个基准上 PoS 的针对性恢复都更高。受困模式分布与任务类型对应:ALFWorld 中循环最常见,RCA-100 中 Drift 占 55.93%,ClinDiag 中 Static 占 78.25%——"只让智能体'换个办法',未必能说明它究竟应当换掉哪段行为、以及需要补齐什么"。

长上下文压力:LOCA-Bench 把环境描述从 8K 扩到 256K tokens,各方法总体下降,而 PoS 在 96K-256K 区间相对稳定,256K 设置下三个模型分别比同设置最强对照高 10.67-16.00 个百分点——与设计思路相符:每次收到新观察就更新现有任务状态、后续决策围绕当前条件展开,减少从长历史反复重建任务状态的需要。

代价与边界:RCA-100 / Qwen3.7-Plus(103 案例平均)中,PoS 把联合准确率从 Raw Trajectory 的 24.27% 提升到 38.83%,但方法总 token 消耗达原始轨迹基线的 5.06 倍;其中执行智能体本身 token 消耗减少约 20.9%,额外开销来自信念维护与 Sentinel——即"用额外推理投入换诊断准确率"。PoS 仍依赖基础模型理解证据的能力,信念健康度用于识别进展停滞、并不直接验证最终答案:即使状态内部一致且与已有观察相容,仍可能包含因领域知识不足形成的错误判断。作者给出的后续方向是更紧凑的潜在世界状态表示(减少反复生成文本的开销)与在状态更新中引入领域知识检索(帮助模型解释专业证据)。

与相关实体的关系

  • 与 ReHarness 记忆反向传播 同属"长程 Agent 状态/记忆治理",但 ReHarness 修的是反思内容(反向修订错题本),PoS 修的是当前世界与剩余要求的显式表征,并额外引入"是否仍在推进"的可计算判据。
  • 与 主动记忆 的差异:后者关注"何时该记/该取",PoS 关注"记下来的东西是否仍成立、是否带来了进展"。
  • 论文以 LongHorizon-Harness 为对照之一(显式维护任务状态的路线),PoS 的增量在于把"状态维护"与"进展度量+受困恢复"闭环,而非仅维护状态本身。
  • 与 Agent Harness 演化论 的运行时分层视角互补:PoS 可视为 Harness 中"状态/观测层"的一种可复现实现,且给出 5.06× token 代价这一工程取舍的量化公开数据。
  • AIOps 验证场景(RCA-100 的"数据库等待 vs JVM 内部处理"信息缺口)与阿里云云原生在可观测性方向的实体(云监控 2.0 智能聚类归因)同源,但后者是平台产品侧、本文是算法与方法侧。

→ 原文存档