ProgressCompass：具身进度奖励模型若缺乏正确上下文便会迷失

TL;DR 现有具身进度奖励模型在需要上下文的长期任务中即使读取完整历史也会迷茫；ProgressCompass 用通用 VLM 自动补充上下文，让冻结模型进度误差降低 63%、排名一致性提升 76%。

问题

问题背景

具身智能体任务长度不断增加，仅靠最终成功/失败信号已不足以指导学习与监控，细粒度的进展估计成为刚需。Progress Reward Models (PRMs) 以逐步进展分数作为密集奖励、验证器与监控器，是当前过程监督的核心组件。

现有方法局限

现有 PRMs 大多基于当前观察帧直接回归进展分数，假设当前帧携带足够信息。这一假设在短任务中成立，但在长任务中往往失效：进展高度依赖之前发生的事件，例如需要回忆早前状态（State Recall）、跟踪固定步骤顺序（Sequence Tracking）、区分外观相似但进展不同的帧（Recurrence Disambiguation）。现有基准主要覆盖短任务，进展可直接从当前观察读出，导致 context-dependent progress estimation 这一关键场景未被系统评估，PRM 在需要上下文时的能力被高估。

为什么这个问题难/重要

长任务中上下文依赖的进展估计本质上是部分可观测问题，仅凭当前帧无法推断全局状态。即便让 PRM 读取完整历史，模型仍可能无法有效整合长序列中的相关信息，论文诊断显示，提供正确上下文后，相同模型的进展误差降低 77–82%。该问题直接影响 PRM 在真实长时程操控任务中的可靠性，是过程监督从演示到部署的瓶颈。业界对长时程任务的过程监督与可靠中间反馈关注度持续上升。

行业类比

类似视频理解模型需要结合历史帧判断当前动作是否完成，或自动驾驶中需要记忆之前路况来推断当前驾驶进展——缺失上下文会导致错误的状态认知。

核心洞察

• 上下文依赖的进度估计是当前具身 PRM 基准中的盲区，ContextProgress-Bench 首次系统暴露该问题。现有基准多假设当前观测足够判断进度，但长任务中关键信息常缺失或需历史关联。该工作通过三种上下文依赖类型（状态回忆、序列跟踪、复发消歧）构建受控评估，发现主流 PRM 即使读取完整历史仍误差较高，证明瓶颈不在模型容量而在上下文供给，为后续研究指明方向。
• 正确上下文的注入比模型架构升级更能提升 PRM 性能，配对实验显示五个模型错误率下降 77-82%。这一发现挑战了“更大模型或更长历史窗口”的常规改进路线，强调信息组织与选择的优先级。在相同输入格式下仅改变指令中的上下文，同一模型即可大幅提升，说明 PRM 的能力被低估，应重视输入侧设计而非仅堆参数或数据。
• ProgressCompass 将上下文供给解耦为通用 VLM 的代理循环，使冻结 PRM 无需微调即可显著进步。与端到端训练或专用记忆模块不同，该方法利用现成 VLM 在推理时动态检索和集成任务所需上下文，降低了部署门槛并保持通用性。实验显示冻结 PRM 错误率降低 63%，排名一致性提高 76%，为长程具身任务中的奖励建模提供了轻量高效的改进方案。

方法

输入

ProgressCompass 接收三类输入：任务指令（自然语言描述）、当前观察帧（图像或状态）、以及历史帧序列（可能为完整轨迹或滑动窗口）。核心挑战在于当前帧往往不足以判断进度，需追溯先前的状态或步骤。

关键模块

ProgressCompass 是一个自主智能体循环（autonomous agentic loop），包含两个角色：

1. 现有 PRM（冻结参数）：保持原有输入格式（如当前帧+指令），输出一个进度分数或排名。PRM 可能是视频理解模型、多模态 Transformer 等，但均未针对上下文依赖进行专门训练。
2. 通用 VLM（例如 GPT‑4V 或类似模型）：作为上下文提取器，根据任务指令和历史帧，动态生成三类上下文信息：
   • 状态回忆：识别先前出现但当前帧缺失的关键物体或属性。
   • 序列跟踪：确定已完成步骤和下一步骤的顺序关系。
   • 重现消歧：区分外观相似但处于不同进度阶段的帧。

循环流程：PRM 先基于当前输入给出初始估计；然后 VLM 分析 PRM 的输入与任务要求，补充缺失上下文（如文本描述、关键帧标记或伪状态表示）；将上下文注入 PRM 的指令或输入中，重新运行 PRM 得到更新后的估计。若估计变化较大或不确定性高，可迭代多次，直到稳定。

输出

输出为校准后的进度分数或步骤排名，可直接用于稠密奖励、验证器或监控器。

与同类方法的差异点：ProgressCompass 不微调 PRM，也不设计专用的上下文编码器，而是通过外部通用 VLM 动态供给上下文，在不改变原 PRM 结构的前提下显著提升长任务进度估计的准确性与排序一致性。

实验

实验设计

论文构建 ContextProgress-Bench，包含 24 个 manipulation tasks、120 个 episodes，覆盖三类上下文依赖：State Recall、Sequence Tracking、Recurrence Disambiguation。采用配对诊断：每个 PRM 保持相同输入格式，但在一次运行中指令注入正确上下文，另一次不注入。随后评估 ProgressCompass 循环，利用现有通用 VLM 自主提取上下文并重新定向 PRM。

关键发现

五个现有 PRM 即使读取完整历史仍会迷失，估计进度误差较大。注入正确上下文后，同一批模型误差降低 77–82%，说明限制不在模型能力而在上下文缺失。ProgressCompass 包装冻结的 PRM 后，误差进一步降低 63%，排名一致性提升 76%，证明 agentic loop 能有效补充上下文。

与基线对比

相比直接使用 PRM 进行进度估计，ProgressCompass 不修改模型权重，仅通过外部 VLM 提供上下文，既保持灵活性又大幅提升性能。与单纯注入完整历史相比，ProgressCompass 的自主循环能针对性提取关键信息，避免冗余干扰，在长程任务中更有优势。

行业影响

落地场景

ProgressCompass 可嵌入长程具身智能任务的产品化流程，例如仓储机器人多步拣选、自动驾驶复杂路口序列决策、智能家居多步骤操作、企业级 RPA（机器人流程自动化）长流程监控。在电商仓储场景中，机器人执行“取货→扫码→装箱→贴标→搬运”等多环节任务，传统 PRM 仅看当前帧会误判进度，导致错误奖励或漏报异常；接入 ProgressCompass 后，可通过调用通用 VLM 补全历史上下文，显著提升每步进度估计准确性。

商业价值

1. 降本：提升 PRM 在长任务中的进度估计精度，减少人工标注密集奖励的依赖，加速策略训练收敛，降低训练算力与人力成本。
2. 增收：在部署阶段提供更可靠的进度监控与异常检测，减少任务失败率和人工介入频率，提升自动化产线吞吐量。
3. 体验提升：用于消费级机器人或智能助理时，能更准确地判断任务完成度，及时给出反馈，减少用户等待与困惑。

与现有产品/工作流的接口

ProgressCompass 以 agentic loop 形式包装现有 PRM，无需重新训练模型，只需在 PRM 上游新增一个上下文检索模块（调用通用 VLM）。该模块可作为独立微服务部署，通过 gRPC/REST 接口向 PRM 提供增强指令。可集成到 ROS 2 节点、自动驾驶中间件（如 Apollo/Autoware）或企业 RPA 平台的任务监控层。与 RLHF 流程结合时，可作为自动化的 reward shaper，替代部分人工反馈。

实际部署时，可先基于开源的 ContextProgress-Bench 对环境进行诊断，识别任务是否存在上下文依赖，再决定是否启用 ProgressCompass 循环，避免不必要的算力开销。

局限

• **对通用 VLM 的依赖与额外开销**：ProgressCompass 的核心是调用通用 VLM 为 PRM 提供缺失的上下文，但 VLM 本身可能存在视觉理解偏差或幻觉，尤其在**State Recall** 和 **Recurrence Disambiguation** 这类视觉相似场景中。此外，该 agentic loop 需要多次调用 VLM，增加了推理时的计算成本和延迟，对实时性要求高的机器人系统不友好。论文未讨论 VLM 输出错误时如何纠错或回退。
• **基准规模与验证范围有限**：**ContextProgress-Bench** 仅包含 24 个操作任务和 120 个 episode，虽然覆盖三类上下文依赖，但任务多样性和样本量仍偏小，统计显著性有限。所有实验均在模拟环境中完成，没有在真实机器人上验证，模拟到现实的差距（sim-to-real gap）未被探讨。此外，基准只涉及 manipulation 任务，未覆盖导航、服务等其它 embodied 任务类型，结论的泛化性有待进一步检验。
• **与同类工作的对比局限**：论文聚焦于上下文依赖的 progress estimation，但未与其它类型的 dense reward 方法（如基于视频预测的 reward、基于语言指令的 progress 估计）进行充分对比，也未探索更长期的任务（如超过百步的连续操作）或动态环境中的上下文漂移。此外，ProgressCompass 需要预先定义任务的预期转移（expected transition），这一假设在实际开放世界任务中可能不成立。