MMTB: Evaluating Terminal Agents on Multimedia-File Tasks
📄 MMTB: Evaluating Terminal Agents on Multimedia-File Tasks #基准测试 #音视频 #系统设计 🔥 60/10 | 前25% | #基准测试 | #系统设计 | #音视频 | arxiv 学术质量 6.7/8 | 影响力 0.8/2 | 可复现性 0.8/1 | 置信度 高 👥 作者与机构 第一作者:Chiyeong Heo(POSTECH GSAI) 通讯作者:Jungseul Ok(POSTECH GSAI, POSTECH CSE) 作者列表:Chiyeong Heo(POSTECH GSAI)、Jaechang Kim(POSTECH GSAI)、Junhyuk Kwon(POSTECH GSAI)、Hoyoung Kim(National AI Research Lab)、Dongmin Park(Krafton AI)、Jonghyun Lee(Krafton AI)、Jungseul Ok(POSTECH GSAI, POSTECH CSE) 💡 毒舌点评 本文定义了一个重要的评估缺口(多媒体文件工作流),并提出了对应的基准(MMTB)和评估框架(Terminus-MM)。核心贡献在于填补空白和提供系统性的消融证据。然而,论文的“现实世界”代表性存在根本性缺陷:1)所有任务均在受控、自包含的沙箱中完成,与真实工作流中充满干扰、网络依赖和复杂交互的环境相去甚远;2)声称的“付费工作流”来源仅体现在任务描述的灵感上,但实际任务经过了高度简化和包装,例如,105个任务中60个(57%)被最佳系统同时解决失败,这强烈暗示任务难度或现实性不足。此外,Terminus-MM的“原生感知”工具(listen_audio, watch_video)被严重黑箱化,其内部调用的模型(例如是Gemini的原生能力还是独立的ASR/VLM模型)未做任何说明,这使得“原生访问”与“命令行工具”的对比在公平性上存疑,因为前者的计算成本和延迟可能已被外部化。 📌 核心摘要 要解决什么问题:现有的终端代理基准主要关注文本、代码和结构化文件,缺乏对现实世界中广泛存在的、需要直接操作音频/视频文件的多媒体文件工作流(Multimedia-File Tasks)的评估。 方法核心是什么:本文提出了一个多模态终端代理基准MMTB(包含105个来自真实付费工作流的任务)和一个多媒体终端代理框架Terminus-MM。Terminus-MM扩展了Terminus-2和Terminus-KIRA,增加了原生音频感知工具listen_audio和原生视频感知工具watch_video。其关键设计是“工作空间感知的工具路由”或“模态掩码”机制:在任务开始时,框架扫描工作空间的文件扩展名,动态确定存在的媒体模态(音频、视频、图像),并只向代理的LLM后端暴露与之对应的感知工具。 与已有方法相比新在哪里:首次在终端代理评估中引入内容感知(Content-aware)和跨文件工作流(Cross-file workflow)的多媒体任务。系统性地证明了原生多模态访问(直接理解音频/视频内容)相较于通过命令行工具(如ffmpeg、ASR)进行间接转换和处理,在效率和成本上的显著优势。 主要实验结果如何:在Gemini-3.1-Pro模型上,提供完整原生模态访问(文本+图像+音频+视频)的Terminus-MM取得了最高成功率(二元成功率0.371,部分成功率0.469),显著优于仅文本访问的Terminus-2(0.124, 0.162)。消融实验表明,原生音频和视频访问是性能提升的主要贡献。当原生模态缺失时,依赖命令行工具转换会导致API成本平均增加1.63x至7.72x,最差情况超过30x。移除动态工具路由(模态掩码)会导致性能下降(如Gemini-3.1-Pro上二元成功率从0.371降至0.324)。失败分析显示,Terminus-MM的主要失败原因是模型推理错误(47%),而商用CLI工具Codex CLI则有更高比例的工具操作相关失败(尤其是超时,39%)。 实际意义是什么:为开发和评估能够处理现实世界多媒体文件工作流的AI代理提供了标准化基准;揭示了原生多模态感知对于提升代理效率、降低成本和可靠性的关键作用;为未来多媒体代理系统的设计指明了方向。 主要局限性是什么:未提供与人类专家基线的直接比较;基准任务规模(105个)和多样性可能不足以完全覆盖所有现实场景;所有评估均在固定10分钟预算内进行,未探索更长预算下的行为;“原生感知”工具的内部实现细节未公开。 🔗 开源详情 代码:https://github.com/mm-tbench/multimedia-terminal-bench 模型权重:论文中未提及提供模型权重下载链接。论文中使用的Qwen3.5-122B、GPT-5.2、Gemini-2.5-Flash、Gemini-3.1-Pro、Sonnet-4.6等均为第三方闭源模型或需通过API/订阅服务访问。Terminus-MM作为工具框架,其本身不包含模型权重。 数据集:MultiMedia-TerminalBench (MMTB) 数据集。获取链接:https://huggingface.co/datasets/mm-tbench/mmtb-media。数据集包含Per-asset media licenses记录在各任务的media.toml中,以CC-BY, CC0, 和 public-domain为主,并包含一个符合Croissant 1.0标准的元数据文件。 Demo:论文中未提及在线演示链接。项目主页为:https://mm-tbench.github.io/multimedia-terminal-bench/ 复现材料:论文详细描述了评估设置,包括任务格式(Harbor任务)、评估协议、代码仓库和附录中的实现细节。完整的复现需要代码仓库、任务数据集以及访问所使用的模型API。 论文中引用的开源项目: Terminal-Bench:论文中的基准测试格式和部分任务设计参考自此项目。链接:https://github.com/terminal-bench/terminal-bench Terminus-2:作为基础的文本终端代理框架。链接:https://github.com/terminal-bench/terminal-bench (Terminal-Bench项目的一部分) Terminus-KIRA:增加了原生图像感知的终端代理框架,采用Apache-2.0许可。链接:https://github.com/terminal-bench/terminus-kira ffmpeg:广泛使用的音视频处理命令行工具。链接:https://ffmpeg.org/ LilyPond:用于乐谱排版的音乐记谱语言和程序。链接:https://lilypond.org/ FluidSynth:软件合成器,用于将MIDI转换为音频。链接:https://www.fluidsynth.org/ Kokoro-82M:论文中提及的一个采用Apache-2.0许可的语音合成模型,用于生成实验中的合成语音。 Godot:开源游戏引擎,用于生成游戏QA任务的视频素材。链接:https://godotengine.org/ Wav2Lip:用于口型同步的视频合成工具。链接:https://github.com/Rudrabha/Wav2Lip reportlab / wkhtmltopdf:用于PDF文档生成的工具。链接:https://www.reportlab.com/ 和 https://wkhtmltopdf.org/ matplotlib:用于生成图表和示意图的Python库。链接:https://matplotlib.org/ music21:用于分析和处理音乐表示的Python工具包。链接:https://web.mit.edu/music21/ 相关基准测试与框架(未直接提供代码链接,但在论文中被引用比较): WebArena / VisualWebArena OSWorld OmniBench JointAVBench AVTrustBench OmniPlay VideoWebArena Claude Code Codex CLI SWE-bench / MLE-bench / AppWorld 🏗️ 方法概述和架构 本文的核心工作是设计并构建一个名为MMTB(MultiMedia-TerminalBench)的评估基准,以及一个用于在该基准上评估的多媒体终端代理框架Terminus-MM。该系统旨在评估终端代理在处理以音视频文件为核心对象的复杂工作流时的能力。 ...