📄 Sandboxed Coding Agents are Competitive Omni-modal Task Solvers

#强化学习 #基准测试

7.9/10 | 创新 1.6/2 | 严谨 1.3/1.5 | 实验 1.1/1.5 | 清晰 1/1 | 影响 0.4/1.5 | 开源 0.8/1.5 | 复现 0.5/0.5 | 工程 1.2/1.5

7.9/10 | 前25% | #强化学习 | #强化学习 | #基准测试 | arxiv

👥 作者与机构

论文作者为Dongping Chen, Xuanao Huang, Zhihan Hu, Qingyuan Shi, Dianqi Li, Tianyi Zhou。机构包括马里兰大学(University of Maryland)和穆罕默德·本·扎耶德人工智能大学(MBZUAI)。

💡 毒舌点评

这篇论文像一个聪明的“工具人”(编码代理)突然发现自己能干“多媒体专家”(原生全模态模型)的活,而且还干得又快又省(少令牌)。作者不仅展示了这个现象,还像产品经理一样分析了“工具人”的故障模式,并手把手教它(Code-X训练)以及设计了新的“技能考核标准”(TerminalBench-O)。优点是思路清晰,实证充分,对“原生感知必要性”这个假设发起了有价值的挑战。缺点在于,部分实验设计有“田忌赛马”的嫌疑,比较基准的选择和设置可能对原生模型不够公平;结论的普适性被自身承认的局限性所削弱;且“处理”任务的新基准(TerminalBench-O)虽然立意好,但目前结果过于惨淡,难以支撑起“下一个前沿”的宏大宣言。总体是一篇扎实的系统性工作,但离改变范式还有一段距离。

📌 核心摘要

本文挑战了“全模态任务必须由原生全模态模型解决”的传统假设。研究发现,仅具备文本+图像访问能力的沙箱化编码代理,通过编写代码、调用ffmpeg、Whisper等工具从原始媒体中提取证据,能够将全模态任务转化为检索与信息处理问题。在OmniGAIA等多个基准上,此类代理(如GPT-5.4 xhigh)的性能可匹配甚至超越Gemini 3.1 Pro等原生全模态模型,同时消耗的令牌更少。论文通过失败分类法和过程级评估分析了代理的局限,并提出三种技能注入方法以提升性能。为探索开源能力,论文提出Code-X训练方案(SFT+可验证奖励RL)和OmniCoding数据集,并在Qwen开源模型上获得提升。此外,论文引入了首个面向全模态处理任务的基准TerminalBench-O,揭示当前代理在该任务上的不足。

🔗 开源详情

  • 代码:https://github.com/Dongping-Chen/OmniCoding (论文明确提供)
  • 模型权重:论文中未提及模型权重下载链接。(Code-X训练的模型权重未开源)
  • 数据集:论文提及了“OmniCoding”数据集(6,035个样本),但未提供直接下载链接。(GitHub仓库可能包含数据或说明)
  • Demo:论文中未提及。
  • 复现材料:论文中提及了Code-X训练配方及附录中的实现细节,但未明确说明是否会单独发布训练数据或完整环境配置。
  • 论文中引用的开源项目:
    • Terminus-KIRA:论文中未提及具体链接。
    • SWE-agent:论文中未提及具体链接。
    • OpenHands:论文中未提及具体链接。
    • Agentless:论文中未提及具体链接。
    • Meta-Harness:论文中未提及具体链接。
    • SkillsBench:论文中未提及具体链接。
    • OmniAgent:论文中未提及具体链接。
    • Agent-Omni:论文中未提及具体链接。
    • LensWalk:论文中未提及具体链接。
    • Whisper (ASR模型):论文中未提供下载链接。
    • ffmpeg / ffprobe:标准工具,无特定链接。
    • Tesseract OCR:标准工具,无特定链接。
    • OpenCV:标准工具,无特定链接。
    • Librosa:标准工具,无特定链接。
    • ImageMagick:标准工具,无特定链接。
    • yt-dlp:标准工具,无特定链接。

🏗️ 方法概述和架构

论文的核心方法是构建并评估一个沙箱化编码代理(Sandboxed Coding Agent)框架,用于解决全模态任务。该框架不依赖端到端的多模态感知模型,而是将原始媒体文件视为环境状态,通过代理与沙箱环境的交互来完成任务。

  1. 任务与环境建模:每个全模态任务被定义为 \(x=(q, \mathcal{F}, \mathcal{Y})\),其中 \(q\) 是自然语言指令,\(\mathcal{F}\) 是输入文件集(可能包含视频、音频、图像等),\(\mathcal{Y}\) 是可接受的答案集。沙箱环境提供一个基于Ubuntu的工作区,预装了常见多媒体工具(ffmpeg、ffprobe、Tesseract OCR、OpenCV、Librosa等)和Python环境,代理可通过终端访问这些工具。
  2. 代理交互流程:与原生全模态模型直接将文件打包进模型上下文不同,沙箱代理的流程是:(q, \mathcal{F}) \rightarrow \text{将文件置入工作区} \rightarrow \text{终端交互轨迹} \tau \rightarrow \text{提取答案} \hat{y}。代理收到指令和文件路径后,通过工具调用(如执行shell命令)来检查文件、编写并运行脚本、生成中间产物(转录文本、采样帧、OCR文本、时间戳等),最终从轨迹 \(\tau\) 中解析出答案 \(\hat{y}\)(通常在<answer>标签内)。
  3. 工具使用与技能注入:代理的核心能力在于其工具使用模式。分析表明,代理会形成一个分阶段的工具流水线:使用ffprobe/ffmpeg检查和变换媒体,使用whisper进行语音识别,使用python3运行自定义脚本,并使用web_search进行外部知识检索。论文发现,媒体提取、转录和外部搜索带来了最稳定的性能提升。为进一步提升性能,论文研究了三种技能注入方法:
    • 校准集自迭代:代理根据小型校准集和二元正确性反馈迭代修订自己的技能文档。
    • 日志驱动自蒸馏:一个独立的代理从执行日志中提取成功和失败模式,并据此生成技能文档。
    • 人类在环技能:提供由人类专家编写的工作流技能。 结果表明,基于执行轨迹的自蒸馏效果最佳,能显著提升代理在OmniGAIA上的准确率。
  4. Code-X训练方案:为了将上述能力迁移到开源模型,论文提出了Code-X训练方案。
    • 数据集构建:构建了OmniCoding数据集,包含6035个可验证的问答对,每个对关联视频/音频/图像文件。数据来源于四个已有基准,并经过规范化、验证性和交叉审查步骤处理。
    • 训练流程:采用“监督微调(SFT)预热 + 基于可验证奖励的强化学习(RL)”的方案。
    • 奖励设计:设计了过程感知的可验证奖励 \(R(x, \tau)\),它包含三个部分:1) 三档基础奖励(正确答案、格式正确但答案错误、其他);2) 惩罚项 \(r_{\text{mod}}\),当任务包含视频/音频但代理未调用对应工具时触发;3) 惩罚项 \(r_{\text{tool}}\),惩罚格式错误、不允许的工具调用、尝试答案泄露等行为。奖励还应用了组级归一化、零方差掩蔽等机制。
    • 训练基础设施:RL系统将沙箱化轨迹生成与策略优化解耦。轨迹生成器在隔离工作区中运行当前策略,收集轨迹并计算奖励;优化器仅根据轨迹令牌序列、旧策略概率和奖励标量进行GSPO更新。
  5. TerminalBench-O基准:为评估代理在“全模态处理”(而非理解)任务上的能力,论文提出了TerminalBench-O基准。它包含50个真实世界任务(涵盖视频、音频、图像、文档和跨模态),要求代理生成具体输出(如编辑后的视频、结构化报告)。评估采用多维度加权评分和严格的门控条件(格式、ID一致性等),强调过程级验证。

图1

图2

💡 核心创新点

  1. 问题重构:首次系统性地论证并实证表明,仅具备文本和图像能力的通用编码代理,通过沙箱化的工具使用范式,能够有效解决大量音视频任务,挑战了“原生端到端全模态感知是必要条件”的常规认知。
  2. 过程级分析与改进:提出了全模态终端代理的失败分类法,并基于200条轨迹的过程级评估进行深入分析。在此基础上,探索了三种无需重训基础模型的技能注入方法,其中日志驱动自蒸馏方法表现优异。
  3. 开源训练方案:提出了完整的Code-X训练方案(SFT+可验证奖励RL)和配套的OmniCoding数据集,为在开源模型上激发类似全模态代理能力提供了可复现的基线。
  4. 新基准导向:引入了首个针对“全模态处理”(Many-modality Processing)任务的基准TerminalBench-O,填补了从“理解”到“处理”的评估空白,明确了当前代理能力的边界。

📊 实验结果

论文在四个基准上对多种编码代理和原生全模态模型进行了全面评估,核心结果如下:

主要结果(Table 1)

模型/系统推理框架OmniGAIA (Easy/Med/Hard/Avg)Social Omni (L1/L2 Q1 Acc)LVOmniBench (Easy/Med/High/Avg)VideoZeroBench (L3)
原生全模态LLM
Gemini 3.1 Pro77.8 / 63.8 / 52.6 / 66.190.0 / 62.080.1 / 71.8 / 48.0 / 69.017.6
Gemini 3 Flash67.2 / 46.9 / 37.2 / 51.785.0 / 67.072.2 / 64.1 / 32.0 / 59.017.8
Qwen 3 Omni19.7 / 10.6 / 9.0 / 13.361.0 / 39.030.6 / 17.9 / 28.0 / 25.05.2
MiMo V2 Omni33.9 / 22.5 / 19.1 / 25.864.0 / 40.051.4 / 25.2 / 24.0 / 35.07.4
Qwen 3.5 Omni Plus43.5 / 39.4 / 29.0 / 38.788.0 / 40.058.3 / 35.9 / 44.0 / 46.010.4
编码代理(本文发现)
GPT-5.4 LowCodex63.1 / 53.8 / 44.9 / 55.064.0 / 59.058.3 / 46.2 / 36.0 / 48.021.0
GPT-5.4 MediumCodex66.4 / 55.0 / 43.6 / 56.471.0 / 49.072.2 / 43.6 / 40.0 / 53.024.0
GPT-5.4 HighCodex70.4 / 60.0 / 50.0 / 61.472.0 / 51.066.6 / 59.0 / 44.0 / 58.027.2
GPT-5.4 xHighCodex82.0 / 75.0 / 64.1 / 75.075.0 / 60.066.7 / 64.1 / 32.0 / 57.027.6
Claude Opus 4.6CC74.6 / 69.4 / 57.7 / 68.654.0 / 68.047.2 / 41.0 / 28.0 / 40.0-
Claude Sonnet 4.6CC73.8 / 62.5 / 48.8 / 63.3---
MiniMax-M2.7CC38.5 / 34.4 / 23.1 / 33.328.0 / 46.050.0 / 15.4 / 24.0 / 30.05.8
Kimi K-2.5CC72.1 / 50.6 / 39.7 / 55.646.0 / 50.055.6 / 28.0 / 41.0 / 43.015.6
工具使用代理 (GPT-5.4 High)
OmniAgent-77.9 / 63.1 / 55.1 / 66.455.0 / 56.050.0 / 21.0 / 28.0 / 33.012.2
Agent-Omni-54.1 / 41.9 / 19.2 / 41.137.0 / 48.056.0 / 28.0 / 20.0 / 36.05.0
纯文本编码代理
GPT-5.4 High (禁用图像)Codex70.5 / 63.8 / 56.4 / 64.474.0 / 48.052.8 / 38.5 / 28.0 / 41.019.0

主要发现:

  1. GPT-5.4 xHigh在OmniGAIA上以75.0%的平均准确率超越Gemini 3.1 Pro(66.1%),在VideoZeroBench上也以27.6%超越Gemini 3 Flash(17.8%)。
  2. 增加推理计算量(从low到xHigh)能一致提升编码代理性能。
  3. 编码代理消耗的令牌显著少于原生全模态模型(图3),因其通过工具选择性提取信息。
  4. 技能注入(特别是日志驱动自蒸馏)能大幅提升性能,将OmniGAIA平均准确率从61.4%提升至76.7%(图7)。
  5. 在纯文本消融中,禁用图像的GPT-5.4 High在OmniGAIA上仍具竞争力(64.4%),但在视觉密集型任务(LVOmniBench, VideoZeroBench)上性能骤降,暴露了当前基准的部分任务可被文本捷径解决。

开源模型结果(Table 4)

模型/设置OmniGAIA Avg.Social Omni Avg.LVOmniBench Avg.VideoZeroBench L3
强基线
OmniAtlas-Omni-30B-A3B20.8(未完整报告)34.06.0
Codex-GPT-5.4 Low55.0(未完整报告)48.021.0
Qwen3.5-9B
Direct MLLM20.044.433.07.2
Baseline (direct image)18.341.730.05.9
Code-X (Ours, SFT)23.148.633.09.5
Code-X (Ours, RL)28.172.253.015.8
Δ vs Direct MLLM+40.5%+62.6%+60.6%+119.4%
Qwen3.6-27B
Direct MLLM38.266.751.07.4
Baseline (direct image)24.452.840.013.0
Code-X (Ours, SFT)43.375.060.018.4
Δ vs Direct MLLM+13.4%+12.4%+17.6%+148.6%

注:表4中Social Omni Avg.指Level1与Level2 Q1 Acc的某种平均,具体计算方式原文未明确,此处按原文表格呈现。

TerminalBench-O结果(Table 5)

模型推理框架通过率 (%)平均分
GPT-5.5 LowCodex240.68
GPT-5.5 MediumCodex180.69
GPT-5.5 HighCodex240.71
GPT-5.5 xHighCodex240.71
GLM-5.1 (V)†CC160.69
DeepSeek V4 Pro (V)†CC120.64
DeepSeek V4 Flash (V)†CC100.60
Kimi K2.6CC80.56
MiniMax M2.7 (V)†CC40.55
† 表示无原生视觉能力的模型使用了Qwen3.5-Flash实现的图像读取功能。

图3

图4

⚖️ 评分理由

  • 创新性 (1.6/2):问题定义清晰,挑战了一个重要假设。将编码代理范式应用于全模态任务是一个新颖的视角。失败分类法和过程级评估也提供了有价值的框架。但核心方法(工具使用、训练范式)并非全新,更多是巧妙的整合与验证。
  • 技术严谨性 (1.3/1.5):实验设计整体合理,控制了变量(如推理计算量)。但部分比较可能对原生全模态模型不完全公平(例如,原生模型是否针对特定基准进行了优化?编码代理使用的工具集是否恰好是该类任务的“捷径”?)。Code-X奖励设计细节虽已给出,但过程奖励的泛化性未充分验证。
  • 实验充分性 (1.1/1.5):实验覆盖多个模型、基准和消融,比较全面。然而,对开源模型的验证仅限于9B和27B规模,且Code-X RL仅在部分基准上超越了Direct MLLM基线(在OmniGAIA上27B SFT甚至低于Direct MLLM)。论文承认了API限制导致的对比不完整。开源模型与顶级闭源代理差距仍然巨大。
  • 清晰度 (1.4/1.5):论文写作清晰,结构完整,从问题提出、方法设计、实验验证到讨论都逻辑连贯。失败案例研究(图4、图6)和轨迹可视化有助于理解。
  • 影响力 (0.4/1):对AI智能体社区和多模态系统设计有启发,推动了对“感知”与“处理”能力的区分。但核心贡献在代理框架和工具使用,而非语音/音乐/音频信号处理本身的创新,因此对语音/音乐/音频领域的直接技术推动有限。
  • 开源 (0.8/1.5):提供了代码仓库链接(https://github.com/Dongping-Chen/OmniCoding)和数据集描述(OmniCoding),但未提供模型权重下载链接,数据集也未提供直接下载地址,降低了可复现性和即时使用价值。
  • 可复现性 (0.7/1.5):承诺开源,提供了训练方案和环境细节。但依赖闭源前沿模型(GPT-5.4, Claude Opus 4.6)进行主要结论验证,开源模型的结果提升有限且不全面,使得完整复现本文核心发现(代理超越原生全模态模型)存在门槛。
  • 工程/实践价值 (1.2/1.5):展示了如何用现有工具构建强大的全模态处理管道,具有很高的实用价值。为开发者提供了新的思路。TerminalBench-O指明了未来挑战。

🚨 局限与问题

  1. 比较公平性存疑:论文将“编码代理+工具”作为一个系统与原生全模态模型进行端对端比较。然而,原生模型可能并未被专门优化以在这些特定基准上达到极致性能(如使用外部工具)。比较更像“专用系统”对“通用基础能力”的评估。此外,编码代理使用的工具链(ffmpeg, Whisper等)可能恰好是解决现有基准任务的有效甚至“作弊”方式(如通过OCR或ASR绕过视觉感知),这削弱了结论的普适性。
  2. 结论推广受限:作者已承认局限,但更深层次的问题是,本文证明的是“工具使用能力”而非“原生视觉/听觉理解能力”在这些任务上的有效性。因此,结论更准确地说是“对于当前设计的、依赖特定信息检索模式的全模态基准,强工具使用代理可以胜出”,而非“原生感知总是不必要的”。
  3. 开源模型贡献不足:Code-X方案在开源模型上的提升显著,但绝对性能仍远低于闭源代理和原生模型。27B模型在OmniGAIA上仅43.3%,而GPT-5.4 xHigh是75.0%。这使得“开源能力激发”的说法显得力度不足。
  4. 新基准(TerminalBench-O)尚处雏形:尽管立意高远,但当前所有模型在TerminalBench-O上的通过率极低(最高24%),平均分也很低。这可能表明基准难度设置过高、评估方式过于严格,或者当前代理架构根本无法胜任此类复杂的“处理”任务。它目前更多地暴露了问题,而非验证了方法的优越性。
  5. 过程奖励的泛化性:Code-X中设计的复杂奖励函数包含多个手工设定的权重和惩罚项,其在不同任务、模型上的泛化能力和最佳设置未得到充分验证。

📷 论文图片

图5


← 返回 2026-06-03 语音/音乐/音频论文速递