Omni-Decision：把对话历史换成"证据台账"的全模态规划框架

  • 关联论文：2607.11433
  • 作者：flyP
  • 更新：2026-09-30

一句话结论

Omni-Decision 用"证据台账（evidence ledger）"取代不断膨胀的对话历史，让全模态智能体在多步任务中只读取结构化的证据状态，从而在 OmniGAIA 上以约 43% 的 Gemini-3.1-Pro 单题成本达到 81.4% 的 SOTA 准确率，并在 WorldSense 长视频理解上追平最强端到端模型。

⚠️ 这是一篇以"机制设计 + 训练范式"为核心的工作，而不是新模型架构。论文的主要贡献是把"记忆结构化 + 角色解耦 + 决策级 RL"三件事压成一套可落地的 agent harness，并给出成本/效果的双指标评测。

解决什么真问题

全模态智能体（omni-modal agent）需要在视频、音频、网页、计算等多种异构来源里搜证，传统做法是把每一步的观察直接塞进对话上下文。但有两个瓶颈被诊断得很清楚：

  1. 噪声污染上下文：视频/音频/网页的原始观察往往很长、噪声多，会让后续规划步骤"被历史淹掉"。对话历史越长，模型越难定位"还需要哪些证据、哪些已经确认、哪些互相冲突"。
  2. 多模态模型规划能力有限：多模态模型本身对多步规划的容量不足。

作者做了一组受控后端替换实验来证明这个诊断：替换 planner 带来的性能损失远大于替换 perception backend。这意味着：在这个全模态 agent 范式里，规划器比感知器更关键，问题不在"看见什么"而在"如何决定下一步看什么"。

核心方法：Evidence-Ledger Planning

整个框架可以画成一条流水线：观察 → Critic → Evidence Ledger → Planner → Action。

1. Evidence Ledger（证据台账）

把不断增长的 dialogue history 替换成一个显式的"台账"数据结构，每条记录包含：

  • Still missing（还缺什么证据）：当前假设里尚未被验证的子目标。
  • Confirmed（已确认的事实）：已被可信来源支持的事实条目。
  • Conflicts（冲突点）：记录之间互相矛盾的地方以及各自的来源。

台账是 compact 的，Planner 在每一步只需读台账，不再读原始对话历史——这样上下文窗口被压扁，规划器始终面对一个结构化、紧凑、去噪声的状态表示。

2. Critic（批评器）

每个 noisy 原始观察先经过 Critic：Critic 读取观察后，只把"可用的"内容（即能进入台账的 missing 补全 / confirmed 强化 / conflict 标注）传给台账，其余丢弃。

这一步等价于把"感知-决策"接口做了一次硬过滤，把噪声挡在台账之外。论文里 critic 与 planner 是分离的角色，因此可以独立替换。

3. Trajectory Logging & Training

每次运行的每一步记录三元组 (state, action, verdict)，生成可监督的训练轨迹。论文在轨迹上做两阶段训练：

  • Supervised Fine-Tuning (SFT)：用专家轨迹让 planner 学"该在什么台账状态下做什么动作"。
  • Decision-level Reinforcement Learning：在 verdict（步骤成功/失败）信号上做决策级 RL，进一步优化 planner。

⚠️ 论文未在 abstract 中明确 SFT 与 RL 的具体数据规模与超参；具体训练配比需查正文。

伪代码骨架（自论文抽象简化）：

for step in task:
    raw_obs = perceive(video|audio|web|compute)
    ledger_update = critic(raw_obs, ledger)
    ledger = merge(ledger, ledger_update)
    decision = planner(ledger)
    next_action = decision.action
    verdict = execute(next_action)
    log(ledger_state, next_action, verdict)

4. 与"传统 ReAct"的关键差别

传统 ReAct 把 Thought / Action / Observation 都写进上下文，几十步后上下文被观察淹没。Omni-Decision 不在上下文里维护历史，而是把"历史"外化成显式数据结构，上下文只承载"现在的台账状态 + 当前决策"。这等于把 agent 的记忆系统从"线性 append-only log"换成"queryable structured state"。

关键实验与数据

Benchmark Omni-Decision 对比基线 备注
OmniGAIA（全模态问答） 81.4% Gemini-3.1-Pro Omni-Decision 的单题成本约为 Gemini-3.1-Pro 的 43%
WorldSense（长视频理解） 65.0% 端到端最强模型 持平（"level with the strongest end-to-end model"）
受控后端替换 替换 planner → 大幅掉点 替换 perception → 较小掉点 验证规划是更关键的瓶颈

⚠️ 诚实标注 / 局限性：

  • abstract 没给出 WorldSense 65.0% 对应的具体端到端基线模型名（"strongest end-to-end model" 是描述性表述，非具体分数）。
  • 81.4% 是 Omni-Decision 自身的成绩，未列出第二名基线的绝对分差。
  • Critic 的 prompt 模板、具体模型选型（是否复用同款多模态 backbone）、台账 schema 的字段细节，原文 abstract 未明确，需查正文 §3-§4。
  • 训练 RL 阶段的 reward shaping 公式 abstract 未给出。

亮点与局限

亮点

  1. 诊断先行：先用受控实验把瓶颈定位到 planner，再做方法，结论可信。
  2. 架构干净：Critic / Ledger / Planner 三个角色解耦，每一层可独立升级（"replaceable backends"）。
  3. 成本/效果双优：OmniGAIA 81.4% SOTA + 单题 43% 成本，落地性价比高。
  4. 可训练：台账三元组 (state, action, verdict) 让 SFT + RL 的监督信号天然存在，比"用语言描述行为"更稳定。

局限

  1. 台账 schema 是工程负担：Critic 能否正确把 noisy 观察归类到 missing / confirmed / conflicts，依赖 schema 设计；跨任务泛化需要 schema 可学习或可提示。
  2. 轨迹数据依赖：SFT 与 RL 都吃轨迹质量，缺少专家轨迹时冷启动难。
  3. 单 planner 多模态能力上限：当任务需要长程因果推理时，单纯靠结构化台账未必能补齐多模态模型本身的规划容量。
  4. 未明确长上下文与 KV cache 优化：ledger 是结构化状态，但每次决策仍要序列化进 prompt，长任务下的 token cost 优化策略 abstract 未述。

对工程落地的启发

  1. 先做"瓶颈诊断实验"再设计架构：不要凭直觉判断 agent 哪里弱；用受控后端替换找出真正的脆弱点。
  2. 把记忆外化为结构化状态：当对话历史超过 10 轮就开始压缩/外置；台账 + critic 的形态比"塞更多 RAG 召回片段"更可控。
  3. decision-level RL 比 outcome-only RL 更稳：每步 verdict 提供稠密信号，比"任务最终对/错"更适合训练多步规划器。
  4. cost-aware 评测：OmniGAIA 报告里同时给出 SOTA 与"约 43% 成本"——这是工业部署最关心的双指标，建议作为内部 benchmark 的标配维度。

⚠ 工程节 6 个具体坑（现象 / 影响 / 修复）

  1. 坑：台账 schema 与 critic prompt 强耦合 - 现象：换任务时 critic 经常把观察错误归类到 confirmed 而非 still missing，台账过早"自满"。 - 影响：planner 误判任务已完成，提前终止。 - 修复：把 schema 字段做成可学习的 few-shot 示例 + per-task schema 校验器；critic 输出先过一道 schema validator 再写入 ledger。

  2. 坑：原始观察长度未限速 - 现象：视频/音频抽帧或网页抓取后单步 observation 可能达上万 token。 - 影响：critic 调用成本陡增，且台账合并时容易把噪声"原文搬运"进来。 - 修复：在 critic 上游加 per-modality 截断/摘要层；把"摘要后的观察"作为 critic 输入。

  3. 坑：conflict 字段缺乏消解策略 - 现象：不同来源冲突时 ledger 只记录冲突，不指定如何取舍。 - 影响：planner 在冲突上反复打转或随机选边。 - 修复：引入 source-trust score（来源可信度）+ 时效性衰减；让 critic 在冲突条目上挂"暂采信 X 来源"标记。

  4. 坑：trajectory SFT 数据分布偏移 - 现象：专家轨迹常带特定 planner 偏好，蒸馏到自训练 planner 后行为漂移。 - 影响：SFT 后指标先升后降，泛化任务掉点。 - 修复：混合 self-rollout + expert 轨迹做 SFT；并保留一定比例"反例轨迹"。

  5. 坑：decision-level RL 的 credit assignment 过短视 - 现象：verdict 只反映单步成功/失败，无法回溯远端动作的因果。 - 影响：planner 学会"做容易的当下步"，忽略长程价值。 - 修复：引入 episodic return shaping（每步 verdict 折扣累加）+ hindsight relabeling。

  6. 坑：受控后端替换实验被误用为"通用结论" - 现象：作者用 controlled replacement 证明 planner 更关键，但这只在 OmniGAIA/WorldSense 域内成立。 - 影响：把它套用到纯文本 agent 或工具调用 agent 上可能得出错误设计建议。 - 修复：跨域（文本 / 网页 / 数据库）补一组受控替换实验，验证 planner-vs-perception 的相对重要性是否稳定。

与同方向工作的关系

  • ReAct / Reflexion / AutoGen 等"对话历史式"agent：Omni-Decision 是其结构化记忆升级版，用台账代替线性 append。
  • Voyager / Ghost / AgentScope 的 skill library：Omni-Decision 偏"单次任务内的状态管理"，而非"跨任务的可复用技能积累"，二者可互补。
  • WebGPT / WebVoyager：与"在网页中搜证"的子任务相关，但 Omni-Decision 扩展到 video/audio/web/compute 多模态并行。
  • 多模态 RAG（如 mmRAG / MM-Embed）：提供 perception 侧的检索能力，可作为 Omni-Decision 的 perception backend 替换实现。

适合谁读

  • 正在做长程多模态 agent（>10 步 + 多种模态输入）的工程团队，需要更稳的规划层。
  • 研究结构化记忆 / 状态机式 agent 的同学——论文给出了可训练的 ledger 表示。
  • 想用 SFT + decision-level RL 训练 planner 而非 outcome-only RL 的从业者。
  • 对cost-aware 多模态评测感兴趣的产品 / 工程负责人。

速读骨架

  • 问题：全模态 agent 的瓶颈不是"看不见"，是"想不清下一步该看什么"——对话历史被噪声淹没，planner 失焦。
  • 方法：用 evidence ledger 替换 dialogue history；critic 把 noisy 观察筛成结构化记录；planner 只读 ledger。
  • 训练：每步记录 (state, action, verdict) 三元组，先 SFT 后 decision-level RL。
  • 结果：OmniGAIA 81.4%（成本 ~43%）/ WorldSense 65.0%（追平端到端最强）/ planner 一换性强 / 验证性强。

与近期"结构化记忆"线的对比

  • MemoryBank / A-Mem / MemGPT 等"长记忆系统"通常把记忆作为外部可检索存储，模型按需 query；Omni-Decision 的 ledger 不是"按需检索"，而是"每步都被 planner 完整读入的当前状态视图"。两者不冲突：ledger 解决"决策可见性"，MemoryBank 解决"经验可重用性"。
  • AERA / SwiftSage 等"显式世界模型 + planner"路线更重：要求一个可推理的世界模型；Omni-Decision 没有显式世界模型，只要求 planner 能消费结构化台账，工程门槛更低。

给论文作者的延伸建议（基于 abstract 推断）

  1. 报告 critic 的失败模式：critic 误归类是 ledger 系统的最大单点风险，公开 critic 准确率/召回率会显著提升可信度。
  2. 台账 schema 公开：把 (still_missing, confirmed, conflicts) 的字段定义与 per-task 模板放入附录，方便复现。
  3. decision-level RL 的 reward 曲线：相比 outcome-only RL 的优势是"更快收敛"还是"更高渐近线"？应单独对照。
  4. 跨域迁移：把 Omni-Decision 套用到纯网页 agent 或 SQL agent 上，给出 planner-vs-perception 的相对重要性是否仍成立。

⚠️ 原文 abstract 未明确项：critic 具体 prompt / 模型选型、RL 阶段 reward 公式、台账 schema 字段细节、WorldSense 65.0% 对应的具体基线模型名；以上需查 PDF 正文或附录。

fetch-verify-date: 2026-09-30（arxiv abs 页 200 OK，v3 提交时间 2026-09-24）；Web Archive 备援：未触发 WAF/521/403。

⚠️ 原文 abstract 未明确项：critic 具体 prompt / 模型选型、RL 阶段 reward 公式、台账 schema 字段细节、WorldSense 65.0% 对应的具体基线模型名；以上需查 PDF 正文或附录。

fetch-verify-date: 2026-09-30（arxiv abs 页 200 OK，v3 提交时间 2026-09-24）；Web Archive 备援：未触发 WAF/521/403。