#基准测试 #音视频 #系统设计

🔥 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模型）未做任何说明，这使得“原生访问”与“命令行工具”的对比在公平性上存疑，因为前者的计算成本和延迟可能已被外部化。

📌 核心摘要

1. 要解决什么问题：现有的终端代理基准主要关注文本、代码和结构化文件，缺乏对现实世界中广泛存在的、需要直接操作音频/视频文件的多媒体文件工作流（Multimedia-File Tasks）的评估。
2. 方法核心是什么：本文提出了一个多模态终端代理基准MMTB（包含105个来自真实付费工作流的任务）和一个多媒体终端代理框架Terminus-MM。Terminus-MM扩展了Terminus-2和Terminus-KIRA，增加了原生音频感知工具listen_audio和原生视频感知工具watch_video。其关键设计是“工作空间感知的工具路由”或“模态掩码”机制：在任务开始时，框架扫描工作空间的文件扩展名，动态确定存在的媒体模态（音频、视频、图像），并只向代理的LLM后端暴露与之对应的感知工具。
3. 与已有方法相比新在哪里：首次在终端代理评估中引入内容感知（Content-aware）和跨文件工作流（Cross-file workflow）的多媒体任务。系统性地证明了原生多模态访问（直接理解音频/视频内容）相较于通过命令行工具（如ffmpeg、ASR）进行间接转换和处理，在效率和成本上的显著优势。
4. 主要实验结果如何：在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%）。
5. 实际意义是什么：为开发和评估能够处理现实世界多媒体文件工作流的AI代理提供了标准化基准；揭示了原生多模态感知对于提升代理效率、降低成本和可靠性的关键作用；为未来多媒体代理系统的设计指明了方向。
6. 主要局限性是什么：未提供与人类专家基线的直接比较；基准任务规模（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。
• 论文中引用的开源项目：
  1. Terminal-Bench：论文中的基准测试格式和部分任务设计参考自此项目。链接：https://github.com/terminal-bench/terminal-bench
  2. Terminus-2：作为基础的文本终端代理框架。链接：https://github.com/terminal-bench/terminal-bench (Terminal-Bench项目的一部分)
  3. Terminus-KIRA：增加了原生图像感知的终端代理框架，采用Apache-2.0许可。链接：https://github.com/terminal-bench/terminus-kira
  4. ffmpeg：广泛使用的音视频处理命令行工具。链接：https://ffmpeg.org/
  5. LilyPond：用于乐谱排版的音乐记谱语言和程序。链接：https://lilypond.org/
  6. FluidSynth：软件合成器，用于将MIDI转换为音频。链接：https://www.fluidsynth.org/
  7. Kokoro-82M：论文中提及的一个采用Apache-2.0许可的语音合成模型，用于生成实验中的合成语音。
  8. Godot：开源游戏引擎，用于生成游戏QA任务的视频素材。链接：https://godotengine.org/
  9. Wav2Lip：用于口型同步的视频合成工具。链接：https://github.com/Rudrabha/Wav2Lip
  10. reportlab / wkhtmltopdf：用于PDF文档生成的工具。链接：https://www.reportlab.com/ 和 https://wkhtmltopdf.org/
  11. matplotlib：用于生成图表和示意图的Python库。链接：https://matplotlib.org/
  12. music21：用于分析和处理音乐表示的Python工具包。链接：https://web.mit.edu/music21/
  13. 相关基准测试与框架（未直接提供代码链接，但在论文中被引用比较）：
      • WebArena / VisualWebArena
      • OSWorld
      • OmniBench
      • JointAVBench
      • AVTrustBench
      • OmniPlay
      • VideoWebArena
      • Claude Code
      • Codex CLI
      • SWE-bench / MLE-bench / AppWorld

🏗️ 方法概述和架构

本文的核心工作是设计并构建一个名为MMTB（MultiMedia-TerminalBench）的评估基准，以及一个用于在该基准上评估的多媒体终端代理框架Terminus-MM。该系统旨在评估终端代理在处理以音视频文件为核心对象的复杂工作流时的能力。

整体流程概述： 系统整体分为两个独立但协同的部分：基准构建流程和代理评估流程。基准构建流程（如图2a所示）从真实世界工作流中筛选、设计、验证并打包任务，形成标准化的、自包含的Harbor任务单元。代理评估流程则将不同的终端代理（包括Terminus家族变体和商用CLI工具）置于统一的沙箱化工作空间中执行任务，并依据预设的验证器对最终生成的工件进行自动评分。

主要组件/模块详解：

1. MMTB基准任务库：

   • 功能：提供105个结构化、可验证的多媒体文件处理任务，覆盖媒体制作、企业合规等5大类16个子类。
   • 内部结构/实现：每个任务遵循Terminal-Bench提出的Harbor格式，包含五个固定组件：(i) 指令，明确目标但不透露答案；(ii) 工作空间，一个包含多媒体文件和必要支撑文件的容器化文件系统；(iii) 允许的终端/工具接口，定义代理可使用的命令行工具；(iv) 输出模式，指定所需工件的路径和格式；(v) 工件验证器，用于评分最终产出。任务设计源于Upwork/Fiverr等平台的付费工作场景，确保现实性。媒体文件来源于公开许可的公共档案或控制性合成内容。
   • 输入输出：输入是预配置的沙箱环境和任务指令；输出是代理在沙箱内生成的特定文件或数据（如JSON、CSV、处理后的视频）。
   • 关键设计选择：采用工件级评分（Artifact-level Evaluation）而非轨迹评分，聚焦于代理是否能完成端到端的可交付成果，这更贴近真实工作流的需求。使用Harbor格式使任务自包含、可复现、且与代理无关。基准总计包含536个媒体文件和6小时54分钟的计时音视频内容。

2. Terminus-MM代理框架：

   • 功能：作为评估载体，为代理提供感知和操作多媒体文件的环境。其核心创新在于引入了原生音频/视频感知工具和工作空间感知的工具路由机制。
   • 内部结构/实现：Terminus-MM建立在Terminus-2（纯文本终端）和Terminus-KIRA（增加原生图像感知view_image）之上。它新增了两个核心原生感知工具：listen_audio（用于直接理解音频内容）和watch_video（用于直接理解视频内容）。最关键的是工作空间感知的工具路由（Workspace-aware Tool Routing）或模态掩码（Modality Masking）机制（算法1）。在任务开始时，框架会递归扫描工作空间的文件（最大深度6层），根据文件扩展名（如.mp3, .mp4等）动态确定当前任务存在的媒体模态（音频、视频、图像），并只向代理的LLM后端暴露与之对应的感知工具。例如，一个只含视频文件的工作空间将只提供view_image和watch_video工具，而不会提供listen_audio。此路由是确定性的，不依赖任务指令或内容。
   • 输入输出：输入是Harbor任务包；输出是代理与LLM交互产生的命令和文件操作，以及最终写入指定路径的工件。框架记录所有日志（包括提示词、输出令牌、墙上时间）以供分析。
   • 组件间的数据流与交互：交互循环为：Harbor提供初始状态（工作空间+指令）→ Terminus-MM根据初始工作空间状态，通过模态掩码过滤，生成可用工具列表（包括始终保留的execute_commands和task_complete）→ 将工具列表和当前状态提供给LLM → LLM决定调用工具（执行命令或感知）→ 框架执行工具并更新工作空间状态 → 将新状态反馈给LLM。此循环持续直到代理调用task_complete或超时（所有评估固定为10分钟）。

架构图/流程图：

图1：展示了MMTB任务的一个实例和两种代理处理方式的对比。左侧是任务描述和文件。右侧上方是原生多模态代理（如Terminus-MM）的工作方式：它可以直接“观看”视频和“聆听”音频来理解内容。右侧下方是文本代理（如Terminus-2）的工作方式：它必须通过一系列中间命令（如ffmpeg提取帧、whisper转录音频）来间接获取信息，这引入了额外的处理步骤、时间和信息损失。

图2：展示了MMTB的构建流程和统计信息。子图(a)是构建流程：从163个候选场景出发，经过任务设计、自动化验证（构建检查、可解性检查、基线评估）、基线审查和人工审核，最终得到105个任务。子图(b)展示了5个元类别和16个细粒度类别的任务分布。子图(c)展示了多标签能力标签的分布，体现了任务对不同感知和推理能力的要求。

专业术语解释：

• 终端代理（Terminal Agent）：指能够在命令行环境中自主执行操作、使用工具、完成复杂任务的AI系统。
• 原生感知工具（Native Perception Tools）：指框架直接提供给LLM的、用于直接理解图像、音频或视频原始内容的接口（如view_image, listen_audio, watch_video），与需要通过编写并执行命令行脚本（如调用FFmpeg、Whisper）来间接获取信息的“命令行工具”相对。
• 工件级评分（Artifact-level Evaluation）：只评估代理最终生成的结果文件是否符合要求，而不评估其推理过程或执行路径。
• Harbor任务格式：一种将评估任务标准化、容器化的格式，包含指令、工作空间、工具接口、输出规范和验证器。
• 工作空间感知的工具路由（Workspace-aware Tool Routing）：Terminus-MM的动态机制，根据任务工作空间中实际存在的文件类型，来决定向代理暴露哪些感知工具。

💡 核心创新点

1. 填补评估空白：提出了首个专注于多媒体文件工作流的终端代理基准（MMTB）。如表1所示，现有的终端代理基准（如Terminal-Bench）和多媒体理解基准（如OmniBench）均未结合“在持久化文件系统中，以多媒体文件为工作对象进行操作并产生可验证工件”这一核心场景。MMTB在“内容感知”和“跨文件工作流”两个维度上均实现了覆盖。
2. 提出Terminus-MM框架：设计并实现了一个支持原生音频和视频感知的终端代理框架。它不仅是简单地增加工具，更关键地是实现了工作空间感知的工具路由（模态掩码），能根据任务提供的文件类型动态配置可用的感知工具，避免工具冗余导致的注意力分散或资源浪费，这本身就是一种系统设计上的贡献。
3. 揭示原生访问的关键作用：通过系统的消融实验（表4, 6）和成本分析（表5），定量证明了对于多媒体任务，直接、原生的模态访问在效率和成本上显著优于通过命令行工具进行间接转换和处理。这为未来多媒体代理的设计提供了明确的实证依据和方向指引。

📊 实验结果

主要基准与结果： 论文在MMTB上评估了多个终端代理配置，关键结果汇总于表3。

最强配置（Gemini-3.1-Pro + Terminus-MM）取得了37.1%的二元成功率和46.9%的部分成功率。

消融实验：

1. 模态访问消融（表4）：在Gemini-3.1-Pro上，从仅音频（T+A, 0.257）或仅视频（T+V, 0.286）开始，逐步增加图像和另一模态感知，最终在全模态（Terminus-MM, T+I+A+V）达到最高性能（0.371）。这表明音频和视频感知都是关键，且二者结合及图像辅助能带来进一步提升。

   Harness	模态访问	二元成功率↑	部分成功率↑	API成本↓	时间↓
   Terminus-A	T+A	0.257	0.349	$1.992	493s
   Terminus-V	T+V	0.286	0.395	$1.118	417s
   Terminus-IA	T+I+A	0.333	0.406	$1.742	460s
   Terminus-IV	T+I+V	0.333	0.432	$1.283	434s
   Terminus-MM	T+I+A+V	0.371	0.469	$1.228	442s
   表4：在Gemini-3.1-Pro上的模态阶梯消融。

2. 成本开销分析（表5）：当原生感知不可用时，代理通过命令行工具（如转录、提取帧）来获取所需模态信息，会导致显著的开销。该分析仅针对两者都成功的任务，且部分系统缺失了任务所需的模态。

   Harness	模态访问	n	API成本比 (平均/最差)	轮次比 (平均/最差)
   Terminus-2	T	7	4.12x / 26.48x	1.00x / 2.71x
   Terminus-KIRA	T+I	4	1.63x / 3.40x	1.39x / 2.00x
   Terminus-A	T+A	14	4.38x / 19.37x	1.77x / 3.83x
   Terminus-V	T+V	13	1.84x / 11.64x	1.15x / 2.17x
   Terminus-IA	T+I+A	13	4.20x / 30.11x	2.21x / 8.10x
   Terminus-IV	T+I+V	14	7.72x / 42.49x	2.01x / 5.88x
   Terminus-AV	T+A+V	4	2.00x / 6.08x	1.28x / 2.06x
   表5：通过命令行转换工具检查多媒体文件的开销（相对于Terminus-MM）。

3. 模态掩码消融（表6）：移除动态工具路由（Terminus-MM w/o modality masking），即总是暴露所有感知工具，会导致性能下降。例如，在Gemini-3.1-Pro上，二元成功率从0.371降至0.324。这证明了智能配置工具集对于代理高效工作的重要性。

   骨干模型	Harness	二元成功率↑	部分成功率↑
   Gemini-2.5-Flash	Terminus-MM w/o modality masking	0.171	0.267
   Gemini-2.5-Flash	Terminus-MM	0.229	0.305
   Gemini-3.1-Pro	Terminus-MM w/o modality masking	0.324	0.426
   Gemini-3.1-Pro	Terminus-MM	0.371	0.469
   表6：模态掩码消融研究。

不同任务子集的性能（表12， 表14）：

• 按能力标签（如图3， 图9）：在需要“视听对齐”、“语音理解”或“视觉感知”的任务上，具有相应原生访问能力的Terminus家族框架（特别是MM）展现出明显优势。
• 按元类别：在“企业与合规”和“个人与教育”等类别中，Terminus-MM相比文本基线取得了显著更高的成功率。

系统对比与失败分析： 图3：Terminus-MM（Gemini-3.1-Pro）与Codex CLI（GPT-5.2）在任务解决上的交集。只有11个任务两者都解决，6个仅Codex CLI解决，28个仅Terminus-MM解决，60个两者都未解决。

图4：Terminus-MM与Codex CLI失败原因的分布对比。Terminus-MM的失败主要归因于“模型推理错误”（47%），而工具操作相关的失败（设置、执行、失败）占比较小（24%）。相比之下，Codex CLI的失败有更高比例源于工具使用问题，特别是超时（工具设置39%），反映了通过命令行工具处理多媒体的额外脆弱性和复杂性。

🔬 细节详述

• 训练数据：MMTB基准包含105个任务。媒体文件来源于公开许可的公共档案（NASA, MIT OpenCourseWare, archive.org, Wikimedia Commons, Freesound等），少数为控制性合成内容（如使用Kokoro-82M TTS生成的对话）。所有资产的许可证信息在media.toml中记录，并包含符合Croissant 1.0标准的元数据文件。
• 损失函数：不适用。本工作是基准测试和评估框架，不涉及模型训练。
• 训练策略：不适用。
• 关键超参数：
  • 代理交互预算：所有评估均固定为10分钟（600秒）的墙上时钟时间。
  • LLM后端：使用了Qwen3.5-122B, GPT-5.2, Gemini-2.5-Flash, Gemini-3.1-Pro以及商用CLI工具自带的模型（Sonnet-4.6 for Claude Code）。具体版本信息见附录A.2表8。
  • Terminus-MM动态路由：算法1中文件扫描的最大深度max_depth=6。
• 训练硬件：不适用（评估运行在Daytona托管沙箱中，通过API调用模型，未使用本地GPU）。 推理细节：代理通过API与LLM交互，采用模型供应商默认的推理设置。评估记录包括提示词令牌（未应用缓存折扣）、输出令牌和墙上时间。API成本按统一代理公式计算：cost = n_input r_input + n_output * r_output，其中r_input和r_output是模型的公开费率。
• 正则化或稳定训练技巧：不适用。
• 评估协议细节：采用二元成功率和部分成功率。二元成功率需超过任务特定的阈值τ_i。部分成功率为所有任务的部分得分平均值。评估仅看最终工件，不看轨迹。

⚖️ 评分理由

• 创新性：2.0/3 论文在问题定义上具有清晰的创新性，成功识别并定义了“多媒体文件工作流”这一重要的评估缺口，并通过表1清晰展示了其与现有工作的区别。Terminus-MM的框架设计，特别是工作空间感知的工具路由（模态掩码），是一个实用且巧妙的系统创新，能有效减少工具冗余。然而，核心方法更多是现有技术（原生感知接口、Harbor框架、LLM代理循环）的有效集成和系统性评估，而非提出全新的算法或理论突破。原生感知工具（listen_audio, watch_video）的具体实现未公开，降低了方法论上的新颖性。
• 技术严谨性：1.5/2 论文的技术阐述严谨、清晰。实验设计合理，控制了变量（如模型骨干、预算），进行了多维度消融（模态、工具路由、任务类别）。分析深入，不仅报告了成功率，还分析了成本开销（表5）、失败原因（图4）和任务解决策略的差异（图3）。主要扣分点在于：1) 所有评估均基于单次运行（附录A.4提到“单种子”），未报告多次运行的标准差或置信区间，结果的稳健性存疑；2) 缺乏与人类专家基线的严格对比，且作者承认直接比较“不公平且复杂”。
• 实验充分性：1.5/2 实验覆盖了多种LLM骨干（4种）和代理类型（控制框架与商用工具），提供了充足的消融实验来支撑主要结论。分析了不同任务类别（表14）和能力标签（表12，13）下的性能差异。主要不足在于：基准规模（105任务）对于一个旨在代表“现实世界”的基准来说仍然有限，且图3显示超过一半（60/105）的任务对两个最强系统都是失败的，这既显示了空间，也暗示任务可能过于困难或现实性不足；未探索不同时间预算或更复杂的多步骤工作流对性能的影响。
• 清晰度：1.0/1 论文写作非常清晰，结构良好。图表（如图1，图2，图9）有效地传达了核心概念和实验结果。算法1明确描述了关键机制。附录提供了丰富的细节。读者可以很好地理解基准的构建方法和评估流程。
• 影响力：0.7/1 工作为终端代理和多模态AI评估设立了一个新的、重要的方向。MMTB有望成为未来研究的重要基准。Terminus-MM的设计思想（原生感知+智能工具管理）可能影响未来的代理架构。其影响力受限于“终端代理”这一相对具体的应用场景，以及基准任务可能存在的“理想化”倾向。
• 可复现性：0.8/1 论文提供了代码仓库、基准数据集（Hugging Face）的链接，并在附录中详细说明了实现细节（模型版本、API路由、成本计算方法）。基准任务以自包含的Harbor格式发布。复现主要评估实验所需的资源和关键设置已公开。扣分点在于：1) 未提供完整复现指南文档；2) Terminus-MM的关键原生感知工具（listen_audio, watch_video）的内部实现是黑箱，第三方无法精确复现其感知行为。

总分：7.0/10

🚨 局限与问题

1. 论文明确承认的局限：
   • 缺乏人类基线：作者明确指出，人类专家通常不使用终端工具，而是使用专业GUI软件（如Premiere, Audacity），因此直接比较不公平且复杂，留待未来工作。
   • 预算固定：所有评估在固定的600秒预算下进行，未测试更长预算是否会缓解某些失败（如工具设置超时）。
   • 任务范围：基准不涵盖直播、实时交互媒体、超长视频（>1小时）等内容。
2. 审稿人发现的潜在问题：
   • 评估设置的单一性与稳健性缺失：所有Terminus家族实验仅使用“单次运行”（未说明是否有多次随机种子），报告的性能数字缺乏统计显著性或方差信息，这削弱了结果的稳健性，特别是在性能差异较小的情况下（如Terminus-2与Terminus-KIRA在部分模型上的对比）。
   • “原生感知”工具的黑箱性：论文没有详细说明listen_audio和watch_video工具内部具体使用了何种模型或技术（例如，是调用了Gemini的原生多模态能力，还是封装了单独的ASR/VLM模型）。这影响了“原生访问”与“命令行工具”对比的公平性，因为前者的计算成本和延迟可能被隐藏或外部化。
   • 商用代理集成的复杂性：对Codex CLI和Claude Code的评估是在其“原生”循环中进行的，这与控制的Terminus框架不同。虽然这反映了真实使用情况，但使得对比（如图4的失败分析）的解释需要谨慎，因为性能差异可能源于LLM、工具链和框架的综合差异，而非单一因素。
   • 任务难度与真实世界距离：虽然任务源于真实工作，但经过“筛选”和“包装”后，可能已简化或理想化。超过一半的任务（60个）被最佳系统同时解决失败，这可能表明任务要么过于困难，要么其现实性代表性不足。对于真正的、充满模糊性和意外情况的现场工作流，代理的表现可能更差。
   • 结论的普适性：论文得出的“原生访问优于命令行工具”的结论，是在一个固定预算（10分钟）和特定模型（主要是Gemini）上得出的。对于更长的预算或不同的LLM，该结论是否成立需要验证。

← 返回 2026-05-13 论文速递