TOBench：面向真实世界工具使用智能体的任务导向全模态基准

# TOBench：面向现实世界工具使用智能体的任务导向全模态基准测试
来源：https://arxiv.org/html/2605.16909
刘志强¹² 董文慧¹\* 谭一浪³ 屈宇文¹ 尹浩辰⁴ 司晨阳¹
¹南京大学 ²华中科技大学 ³西南交通大学 ⁴香港中文大学
https://github.com/Pi3AI/TOBench

###### 摘要

工具使用智能体正越来越多地被期望在现实专业工作流中运行，它们必须解读多模态输入、协调外部工具、检查中间产物，并在生成最终结果前修正自身行动。然而，现有基准测试往往将工具使用、计算机使用和多模态推理分开评估，导致基准设置与现实世界端到端全模态工具使用之间存在差距。为弥合这一差距，我们提出TOBench——一个面向任务导向全模态工具使用的基准测试与评估平台。TOBench包含来自两大宏观任务族——*客户服务*和*智能创作*——的100个可执行任务，覆盖20个子类目切片，并由27个MCP服务器（含324个工具）提供支持。TOBench的核心设计是*闭环多模态验证*：智能体必须执行工具、检查渲染或转换后的产物，并在输出不符合任务特定要求时自行修正。为使此类评估具备可扩展性和可验证性，TOBench将基于MCP的执行与任务特定的接地评估器，以及用于场景发现、任务实例化、评估器合成和人工审核的半自动化构建管道相结合。对15个当代智能体模型的实验表明，TOBench仍极具挑战性：通常被认为是最强编码智能体模型之一的Claude Opus 4.6仅达到32.0%的任务成功率，远低于94.0%的人类基准水平。我们期望TOBench能作为评估和推进下一代全模态工具使用智能体（通过闭环多模态验证）的实用基础。

## 1 引言

参照图注：图1：领先LLM在TOBench上的表现。Qwen 3.5 Plus以41.0%的模型得分最高，而大多数其他模型低于30.0%。人类基准为94.0%，突显了显著的性能差距，表明现实世界多模态工具调用任务仍有很大的改进空间。

基于GPT-4[1 (https://arxiv.org/html/2605.16909#bib.bib58)]和GPT-4o[10 (https://arxiv.org/html/2605.16909#bib.bib59)]等基础模型驱动的工具使用语言智能体，正从孤立的函数调用转向与网络服务、办公软件、知识源和外部应用的实际交互。模型上下文协议（MCP）进一步加速了这一转变，为连接智能体与多样化工具和服务提供了标准接口。因此，近期基准测试在评估API使用、函数调用、规划和基于MCP的工具交互方面取得了实质性进展，包括τ\\tau-bench[30 (https://arxiv.org/html/2605.16909#bib.bib4)]、ToolBench[22 (https://arxiv.org/html/2605.16909#bib.bib2)]、BFCL[20 (https://arxiv.org/html/2605.16909#bib.bib11)]、ToolTalk[5 (https://arxiv.org/html/2605.16909#bib.bib3)]、Toolathlon[14 (https://arxiv.org/html/2605.16909#bib.bib16)]、MCP-RADAR[6 (https://arxiv.org/html/2605.16909#bib.bib20)]、MCP-Bench[28 (https://arxiv.org/html/2605.16909#bib.bib23)]和MCP-Universe[18 (https://arxiv.org/html/2605.16909#bib.bib22)]。然而，现有基准测试在现实专业工作流方面仍存在关键缺口。许多实际任务并非纯文本或纯API：智能体可能需要读取截图或文档、从音频或视频中提取信息、编辑电子表格或演示文稿、渲染输出、检查结果是否符合视觉和语义约束，并在必要时修正产物。这种多样性缺口不仅仅是增加更多工具名称或更长的工具列表。难点在于协调工具执行与多模态感知、产物转换，以及在不断变化的工作空间状态上进行迭代验证。OSWorld[29 (https://arxiv.org/html/2605.16909#bib.bib8)]、VitaBench[8 (https://arxiv.org/html/2605.16909#bib.bib19)]、M3-Bench[35 (https://arxiv.org/html/2605.16909#bib.bib25)]和OmniGAIA[15 (https://arxiv.org/html/2605.16909#bib.bib28)]等多模态与计算机使用基准测试将评估范围扩展到文本之外，但多模态感知和工具使用仍常被作为独立能力评估。工具使用基准测试通常强调模式保真度、工具选择或最终状态检查，而多模态基准测试则侧重于感知、GUI控制或最终答案质量。现实的全模态工作流需要同时具备所有这些能力：智能体必须感知异构输入、通过可执行工具行动、检查中间产物，并在任务特定约束下自行修正。

为弥合这一差距，我们提出TOBench——一个面向任务导向全模态工具使用的基准测试与评估平台。TOBench包含来自两大宏观任务族——*客户服务*和*智能创作*——的100个可执行任务，覆盖20个子类目切片，并由27个MCP服务器（含324个工具）提供支持。任务设计基于现实用户需求和专业角色，而非合成工具组合，其中许多任务需要对文档、图像、音频、视频、电子表格、幻灯片、搜索、浏览器自动化和文件操作进行跨工具组合。TOBench的核心设计是*闭环多模态验证*。TOBench不将工具使用视为一次性的动作序列（随后进行最终答案匹配），而是要求智能体执行工具、检查渲染或转换后的产物，并在产物不满足任务要求时修正自身行为。每个任务都配有一个接地验证器，结合基于代码的检查、工具调用约束、格式约束和多模态产物检查。这使得该基准测试成为一个可执行平台，用于评估完整的感知-行动-检查-修正循环。

对15个当代智能体模型的实验表明，TOBench远未饱和。如图1 (https://arxiv.org/html/2605.16909#S1.F1)所示，评估的最强模型Qwen3.5-Plus仅达到41.0%的任务成功率，而人类基准达到94.0%。我们的失败分析表明，错误集中在不可靠的工具执行、不正确的工具参数、多模态推理失败，以及在停止前缺乏自我验证。这些结果表明，闭环多模态验证是下一代全模态工具使用智能体不可或缺的评估原语。

## 2 相关工作

表1：TOBench与代表性相关基准测试在规模和能力维度上的比较。符号：✓=支持，✗=不支持。每种特征的详细说明见附录B.1 (https://arxiv.org/html/2605.16909#A2.SS1)。

### 2.1 工具使用、长程、MCP基准测试

工具增强LLM的基础工作确立了外部工具使用的核心能力[25 (https://arxiv.org/html/2605.16909#bib.bib30),31 (https://arxiv.org/html/2605.16909#bib.bib29),21 (https://arxiv.org/html/2605.16909#bib.bib32),26 (https://arxiv.org/html/2605.16909#bib.bib31)]。随后的智能体框架和基准测试将评估扩展到多步执行、规划和可重复性，包括ToolBench、BFCL、ToolTalk、Toolathlon、τ\\tau-bench、GAIA、τ2\\tau^2-Bench及相关套件[22 (https://arxiv.org/html/2605.16909#bib.bib2),20 (https://arxiv.org/html/2605.16909#bib.bib11),5 (https://arxiv.org/html/2605.16909#bib.bib3),14 (https://arxiv.org/html/2605.16909#bib.bib16),30 (https://arxiv.org/html/2605.16909#bib.bib4),19 (https://arxiv.org/html/2605.16909#bib.bib14),3 (https://arxiv.org/html/2605.16909#bib.bib15)]。近期基于MCP的基准测试，如MCP-RADAR、MCPToolBench++、MCP-Universe、MCP-Bench和OSWorld-MCP[6 (https://arxiv.org/html/2605.16909#bib.bib20),4 (https://arxiv.org/html/2605.16909#bib.bib21),18 (https://arxiv.org/html/2605.16909#bib.bib22),28 (https://arxiv.org/html/2605.16909#bib.bib23),11 (https://arxiv.org/html/2605.16909#bib.bib24)]进一步强调了实时工具生态系统。这些工作揭示了工具选择、模式保真度和长程执行中的关键挑战，但大多仍以文本为主，并未明确评估多模态产物上的检查-修正循环。

### 2.2 多模态与计算机使用智能体基准测试

OSWorld、AndroidWorld、VisualWebArena、VitaBench、τ\\tau-Voice、MMDR-Bench、VisualAgentBench、ProSoftArena、M3-Bench、Tool-LMM、UniVA和OmniGAIA将评估范围扩展到GUI接地和多模态交互[29 (https://arxiv.org/html/2605.16909#bib.bib8),23 (https://arxiv.org/html/2605.16909#bib.bib50),13 (https://arxiv.org/html/2605.16909#bib.bib35),8 (https://arxiv.org/html/2605.16909#bib.bib19),24 (https://arxiv.org/html/2605.16909#bib.bib64),9 (https://arxiv.org/html/2605.16909#bib.bib69),17 (https://arxiv.org/html/2605.16909#bib.bib63),2 (https://arxiv.org/html/2605.16909#bib.bib74),35 (https://arxiv.org/html/2605.16909#bib.bib25),27 (https://arxiv.org/html/2605.16909#bib.bib10),16 (https://arxiv.org/html/2605.16909#bib.bib26),15 (https://arxiv.org/html/2605.16909#bib.bib28),33 (https://arxiv.org/html/2605.16909#bib.bib75),7 (https://arxiv.org/html/2605.16909#bib.bib76),12 (https://arxiv.org/html/2605.16909#bib.bib77),36 (https://arxiv.org/html/2605.16909#bib.bib78),32 (https://arxiv.org/html/2605.16909#bib.bib79)]。TOBench与此类方法最为接近，但有三个不同之处：它针对现实专业任务完成，使用统一的基于MCP的工具生态系统，并将评估集中于通过任务特定接地验证器进行的迭代产物检查。表1 (https://arxiv.org/html/2605.16909#S2.T1)从基准规模、生态系统假设和多模态执行需求的角度总结了这一比较。

## 3 TOBench

TOBench评估智能体能否使用可执行工具完成现实的全模态任务。每个任务实例指定用户指令、任务资产、可用工具环境和用于确定成功与否的接地验证器。这些组件共同定义了一个专业角色、多模态输入、一个可执行工具生态系统和一个任务特定的验证路径。

### 3.1 任务形式化

参照图注：图2：TOBench构建管道概览。TOBench将任务组织成两个宏观任务族——客户服务和智能创作，通过用户指令、多模态输入、可执行MCP工具和领域规则进行实例化，并通过基于实际工具执行的生成-检查-修正循环验证每个任务。

我们将每个TOBench实例形式化为一个可执行平台 h=\(I,E,S,A,O,T,C,V\)，(1)
其中I\\mathcal\{I\}表示任务指令包，E\\mathcal\{E\}是可执行MCP环境，S\\mathcal\{S\}是潜在执行状态，A\\mathcal\{A\}是动作空间，O\\mathcal\{O\}是观察空间，T\\mathcal\{T\}是转移动态，C\\mathcal\{C\}是经批准的评估标准，V\\mathcal\{V\}是接地验证器。指令包为 I=\(u,r,d,x\)，(2)
其中uu是用户请求，rr是分配给智能体的专业角色，dd表示智能体需要遵循的简洁领域规则，xx收集多模态输入资产。与静态问答基准测试不同，环境E\\mathcal\{E\}既包含可调用工具，也包含工作空间中的可变产物。在时刻tt，潜在状态分解为 st=\(s_t^{tool},s_t^{ws},s_t^{ext},h_t\)∈S，(3)
其中sttools\_t^\{tool\}捕捉工具侧运行时状态，swss\_t^\{ws\}是当前工作空间产物，stexts\_t^\{ext\}是通过工具暴露的任何外部世界状态，hth\_t是交互历史。这种分解对TOBench很重要，因为许多任务需要修改文件、渲染中间产物，以及基于时间敏感信息进行接地。智能体动作空间包含工具使用和自然语言交互： A=Atool∪Atext, attool=\(mt,θt\)，(4)
其中mtm\_t是可用的MCP工具，θt\\theta\_t是其参数。观察同样混合了工具输出、渲染产物和文本反馈： O=Otool∪Orender∪Otext。(5)
执行动态由 (s_{t+1},o_{t+1})∼T(s_t,a_t) (6)
支配，因此工具调用可能更新文件或外部状态，然后返回结构化输出，而渲染或检查动作则暴露多模态证据，从而触发修正性的后续步骤。这导致了一个轨迹 τ=\(I,s0,a1,o1,...,aT,oT\)，(7)
这明确表明TOBench评估的是完整的感知-行动-检查-修正循环，而不仅仅是最终答案字符串。特别是，许多创作任务需要闭环模式：智能体首先生成一个产物，然后通过渲染或检查获得otrender∈Orendero\_t^\{render\}∈O\_render，然后才决定是否需要修正。

参照图注：图3：TOBench中工具、任务难度和任务场景的分布。左：每个工具被调用的次数，显示长尾工具使用分布。中：任务难度分布。右：任务在客户服务和智能创作两个高层次类别中的场景分布。

### 3.2 TOBench构建框架

图2 (https://arxiv.org/html/2605.16909#S3.F2)展示了TOBench的总体构建管道。我们通过选择全模态MCP工具、发现以用户为中心的场景、实例化可执行任务，以及为闭环验证策划多模态资产，从现实专业场景构建任务。

全模态MCP工具选择。我们将Toolathlon[14 (https://arxiv.org/html/2605.16909#bib.bib16)]的MCP栈扩展到全模态工作流。我们保留了浏览器自动化、检索、办公编辑、文件系统和搜索等广泛有用的工具，并增加了用于PPT编辑、文本转语音、语音识别以及视频或音频处理的多模态服务器。我们还实现了两个基准测试特定的服务器：图像生成服务器和图像处理工具包，以支持创作任务和闭环视觉检查。最终基准测试集成了27个MCP服务器和总共324个工具。这种多样性是必要的，因为许多任务需要跨工具组合，而不是单一API。完整清单见附录A (https://arxiv.org/html/2605.16909#A1)。

全模态场景发现。我们从现实用户需求而非合成工具组合出发。我们的场景发现提示以*类别*、*子类别*和可用的MCP服务器作为输入，并要求语言模型以JSON格式生成10个候选场景。每个候选场景包含场景名称、生动的描述。