MM-ToolSandBox：视觉工具调用代理评估基准与失败模式分析

以下译文用于快速探索和学习，技术术语按需要保留英文；正式引用和精确表述请以原论文为准。

第 1 页

MM-ToolSandBox：一个用于评估视觉工具调用代理的统一框架

Kaixin Ma∗, Di Feng∗, Alexander Metz, Jiarui Lu, Eshan Verma, Afshin Dehghan

Apple ∗同等贡献

我们介绍了 MM-ToolSandBox，这是一个针对视觉化代理工具调用（visually grounded tool-calling agents）的基准测试和评估框架。该框架提供了一个状态化的执行环境，涵盖 16 个应用领域中的 500 多种工具，支持多图像、多轮任务，其中代理必须将逐步到达的视觉输入映射到可执行的工具调用中，同时处理真实的对话现象（目标修订、错误纠正、状态突变）。一个自动化的场景生成流水线通过信息流引导的规划和多阶段质量过滤，生成了多样化的、具有视觉基础的场景，产生了 258 个经人工验证的名义场景和 50 个针对交互式 UI 应用的变体。对 12 种最先进模型的评估，从 4B 参数的开源权重模型到前沿的专有系统，表明当前模型仍缺乏稳健的视觉工具调用能力：即使表现最好的模型，其成功率也低于 50%。我们的失败分析进一步揭示，视觉精度（visual precision）而非仅仅是规划能力，是强大模型的主要瓶颈：2026 年 53% 的失败源于从图像中提取信息错误，尽管任务工作流在其他方面是正确的。随着规模扩大，出现了从规划到精度的交叉现象：较小的模型在决定“做什么”时失败，而较大的模型在感知“看到了什么”时失败，这表明在不同能力水平上改进模型需要 fundamentally different research directions（根本不同的研究方向）。该框架和基准测试已在 https://github.com/apple/ml-mmtoolsandbox 公开。

日期：2026 年 7 月 14 日

1 引言 [cs.CV]

评估基于大语言模型（LLM）的代理在工具增强任务上的表现已成为一个活跃的研究领域，现有的基准测试针对函数调用（Li et al., 2023; Patil et al., 2025）、状态化环境交互（Lu et al., 2025; Trivedi et al., 2024）以及多轮对话动态（Froger et al., 2026; Barres et al., 2025; Xiu et al., 2026）。然而，大多数这些框架仍以文本为中心，无法评估许多具有视觉输入的真实助手任务，例如，用户可能分享截图以诊断问题，或提供活动海报的照片以安排活动。

解决视觉工具调用任务不仅仅需要视觉识别。代理必须从图像中提取与任务相关的信息，将视觉证据映射到正确的工具或代码动作，在状态化环境中执行该动作，并在用户意图演变时继续交互。这使得视觉工具调用成为一种独特的代理能力：模型不仅要理解所展示的内容，还要决定如何通过工具采取行动。

在少数包含视觉输入的基准测试中，图像通常作为初始查询中的静态前缀提供（Wang et al., 2024a），或者任务仅限于单轮用户-代理交互（Xie et al., 2024; Rawles et al., 2025）。此外，许多现有基准测试在相对较小的工具空间下运行，通常仅包含 15–100 种工具（Froger et al., 2026; Wang et al., 2024a; Kong et al., 2025; Lu et al., 2025）。因此，目前缺乏一个统一的框架和基准测试，用于在动态、多轮和大工具空间设置下系统地研究多模态代理的视觉工具调用能力。

为了弥补这一空白，我们引入了 MM-ToolSandBox，这是一个用于评估视觉工具调用代理的多样化模拟框架。MM-ToolSandBox 扩展了 ToolSandBox（Lu et al., 2025）中的状态化工具使用环境，增加了显式的图像处理、视觉专用工具，并支持结构化 Tool-Use（工具使用模式）

1

第 2 页

环境 多模态轨迹 评估 代理裁判 实体数据库 执行模式 代理 用户 工具使用 代码执行 检查标准 证据 图像 “嘿！这些物品中哪些” ✅ 任务完成 代理正确 文档 我应该检查物品 我应该检查物品 在我的购物清单上？” 找到了物品 联系人 lookup(domains=“Shopping) 项 ✅ 工具使用有效性 在购物…清单… 邮件 指令 ✅ 物品 0: 香蕉 交易 物品 1: 无副作用 … ❌ 服务提供商 牛奶 前两个。 … compute_price([0,1]) ✅ 信息正确性 … “它们在网上卖多少钱？” 用户裁判 工具箱抽象 顺便说一句，这个看起来也很棒！ 检查标准 证据 把它加到我的清单上。 相同的基本功能，不同的 ✅ 请求保真度 … 搜索工具 整合层级。 ✅ 对话自然度 用户使用 UI工具 自然语言 … 完整集 中等 迷你 我在购物应用中找到了一个香蕉和牛奶 ✅ 接地一致性 … 视觉工具 } (+500) (+250) (+30) 购物应用。它们售价14.99美元。 ✅ 工具使用有效性 … … 我找到了两种 菠萝，你更喜欢 应用领域 (16) 哪一种？” 状态验证 列 预期 实际 相似度得分 … user_idprod_id 2201 2201 精确精确 1.001.00 消息 笔记 音乐 文件 购物 支付 已添加！ 数量标题 1安迪的清单 1安迪 精确模糊 1.000.65

图1 MM-ToolSandBox 框架概述，用于评估视觉工具调用代理。该框架 支持用户和代理之间的多轮、多图像交互，并提供结构化工具使用和 代码执行接口。该框架包含16个应用领域中的500多个原生工具，涵盖搜索、 UI、视觉和系统级实用程序。评估结合了基于量表的LLM裁判，用于代理和用户角色，以及 静态状态验证检查。

以及代码执行接口，如图1所示。基于此框架，我们构建了一个 视觉工具调用基准测试，旨在捕捉先前工作中缺失的关键挑战。该基准测试 涵盖16个模拟应用领域中的511个工具，并沿三个正交轴组织：七种 信息流类型、四种模拟真实对话偏差的挑战类型，以及四种控制视觉输入何时进入交互的图像 到达模式。由此产生的基准测试包含 258个名义场景，包含1,284张唯一图像，要求代理在庞大且多样化的工具空间中进行多图像、多轮工具 使用。所有场景均由人类专家进一步纠正和验证，以确保可靠的视觉接地、可执行的任务规范和明确定义的完成标准。我们还策划了50个场景以探索交互式UI应用。为了使基准测试构建可扩展 同时保持高质量，我们开发了一种自动化的场景生成管道。该管道通过信息流引导规划、环境状态实例化和 多阶段质量过滤生成视觉接地场景，将标注负担从完全手动构建减少到针对性的人类 审查。最后，我们在我们的基准测试上对最先进的专有和开放权重模型进行了系统评估。我们的结果表明，即使是强大的前沿模型在视觉工具调用方面也面临重大困难，揭示了图像接地推理、多步交互和有状态工具使用方面的持续差距。 深入分析进一步表明，多图像工作记忆是关键瓶颈，不同规模的模型表现出不同的失败模式。

总之，我们的贡献是：1. 用于评估视觉工具调用代理的统一框架和基准测试。2. 可扩展的场景生成管道。3. 对多样化模型的系统评估。

我们在 https://github.com/apple/ml-mmtoolsandbox 向公众发布基准测试和框架。

2 相关工作

工具使用代理基准测试。越来越多的基准测试评估LLM代理在工具增强任务上的表现。API-Bank (Li et al., 2023) 和 BFCL (Patil et al., 2025) 针对大型API集合的单轮和多轮函数调用。ToolSandbox (Lu et al., 2025) 引入了具有在线评估和对话模拟的状态环境。AppWorld (Trivedi et al., 2024) 扩展到9个应用中的457个API，具有丰富的关系数据，尽管 exclusively 在代码执行范式下。最近的更多努力推动向动态环境发展：Gaia2 (Froger et al., 2026) 引入了异步、事件驱动的

2

第 3 页

表 1 代表性工具使用代理基准测试与环境的比较。Visual 指示图像或 UI 观察是否作为输入的一部分。Scenario 区分单轮任务（用户 upfront 提供完整目标，代理自主执行）和多轮任务（代理必须与用户交互以解决歧义、获取缺失信息或处理用户更新）。Env. 描述执行基底，而 Exec. 指定代理接口：Tool 表示结构化函数/工具调用，Code 表示在 Python 环境等运行时中生成可执行代码，UI+Tool 表示通过图形界面和外部工具进行混合交互。

| Benchmark | Visual | Scenario | Environment | Execution | Apps/Domains | Tools | | :— | :—: | :— | :— | :— | :— | :—: | | AppWorld (Trivedi et al., 2024) | ✗ | single-turn | API sim. | Code | mobile apps (9) | 457 | | Toolathlon (Li et al., 2025a) | ✗ | single-turn | MCP/server | Tool | software apps (32) | 604 | | MCP-Atlas (Bandi et al., 2026) | ✗ | single-turn | MCP/server | Tool | mixed domains (36) | 220 | | ToolSandbox (Lu et al., 2025) | ✗ | multi-turn | API sim. | Tool | mobile apps (11) | 34 | | Gaia2 (Froger et al., 2026) | ✗ | multi-turn | API sim. | Tool | service apps | 101 | | ASTRA-bench (Xiu et al., 2026) | ✗ | multi-turn | API sim. | Tool | mobile apps | 51 | | τ 2-Bench (Barres et al., 2025) | ✗ | multi-turn | API sim. | Tool | telecom support | 30 | | GTA (Wang et al., 2024a) | ✓ | single-turn | tool suite | Tool | vision/web tasks | 14 | | OSWorld-MCP (Jia et al., 2025) | ✓ | single-turn | OS/UI | UI+Tool | desktop apps (7) | 158 | | MobileWorld (Kong et al., 2025) | ✓ | multi-turn | OS/UI | UI+Tool | mobile apps | 64 | | MM-ToolSandBox | ✓ | multi-turn | API sim. | Tool+Code | mobile apps (16) | 511 |

评估测试时间感知能力和代理间协作；τ 2-Bench (Barres et al., 2025) 模拟代理-主管交互，揭示通信是关键瓶颈；ASTRA-bench (Xiu et al., 2026) 将评估建立在纵向个人语境之上。GTA (Wang et al., 2024a) 是最早纳入多模态语境的基准之一，但仅在无状态设置下涵盖 14 个工具。SO-Bench (Feng et al., 2026) 评估工具使用代理的视觉结构输出能力，但仅关注单轮交互。Toolathlon (Li et al., 2025a) 进一步将工具使用评估扩展到长周期真实软件工作流，涵盖 32 个软件应用程序和 604 个工具，具有真实的初始状态和基于执行的任务验证。MCP-Atlas (Bandi et al., 2026) 在 36 个真实 MCP 服务器和 220 个工具上的 1,000 个多步任务中评估代理，要求代理从自然语言指令中发现并编排跨服务器的 3–6 次工具调用。尽管取得了这些进展，这些基准测试主要运行在纯文本模式下，在单一执行模式下进行评估，并严重依赖手动场景构建。

视觉代理基准测试。另一条平行的研究路线评估感知并作用于 GUI 输入的代理，即 GUI 代理 (Wang et al., 2025; Li et al., 2025d; Yang et al., 2025)。VisualWebArena (Koh et al., 2024) 和 WebVoyager (He et al., 2024) 评估基于视觉页面理解的网页导航。在操作系统层面，OSWorld (Xie et al., 2024)、AndroidWorld (Rawles et al., 2025) 和 UINavBench (Agrawal et al., 2025) 分别对桌面和移动任务进行基准测试，而 MobileWorld (Kong et al., 2025) 将其扩展到长周期跨应用程序工作流。在多模态搜索中，MMSearch (Jiang et al., 2024) 和 MM-BrowseComp (Li et al., 2025c) 评估需要视觉-语言推理的深度检索。这些基准测试都基于视觉感知，但在图像类型（UI 截图与自然图像）、动作空间（GUI 操作与 API 调用）和评估方式（导航成功与状态验证）方面存在差异。我们的工作占据了一个互补的位置：代理感知在对话期间共享的异构视觉输入（从自然照片到文档、图表和 UI 截图），并必须将它们转化为状态化、多域环境中的高级 API 工具调用，测试的是从感知到工具调用的管道，而非像素级的 UI 操作。

与先前基准测试的功能比较见表 1。

3 MM-ToolSandBox

MM-ToolSandBox 旨在衡量视觉工具调用能力：代理能否理解视觉语境，决定需要哪些工具（或代码），在多轮交互中正确使用视觉工件，并通过基于语境的、多步的交互完成任务。为此，MM-ToolSandBox 继承了 ToolSandbox (Lu et al., 2025) 轻量级、交互式且稳健的设计哲学，同时扩展了基于文本的工具使用

第 4 页

通过显式的视觉伪影处理，将环境映射到视觉设置。为了支持更丰富且更动态的助手场景，我们进一步引入了 AppWorld (Trivedi et al., 2024) 中的领域和工具，从而形成了 16 个模拟应用领域和 511 个原生 Python 工具。这些设计选择共同使 MM-ToolSandBox 成为一个用于原型设计多样化多模态工具调用场景的通用运行时。图 1 提供了我们系统设计的概览。

3.1 架构

每个回合（episode）由一个场景参数化，该场景指定初始和预期的世界状态、可用工具、用户指令、相关的视觉资产以及完成标准。交互随后在代理（agent）、用户和执行环境之间展开。大语言模型（LLM）扮演模拟用户，代理作为任务求解者（处于评估中），而环境则维护共享的世界状态并执行工具调用。代理、用户和环境之间的交互通过两个通道进行。代理与用户之间的前端交互是自然的用户-助手对话，而与环境的后端交互则通过类型化的工具调用进行中介。

工具管理。工具被实现为具有类型化签名和元数据（如角色可见性和状态依赖关系）的原生 Python 函数 (Lu et al., 2025)。由于我们在 MM-ToolSandBox 中提供了超过 500 个工具，在单个提示中暴露完整的注册表是不切实际的。因此，我们提供了一个工具发现的元工具 search_tool，它可以根据工具文档的自然语言查询按需检索相关工具。检索到的工具会被添加到代理的活动集中，而最近最少使用（LRU）淘汰策略则保持工作集的大小受限。为了进一步测试在不同注册表规模下工具使用的鲁棒性，我们从完整的原生工具集中精心策划了三个额外的变体：包含 276 个工具的中规模集、包含 165 个工具的紧凑集以及包含 30 个工具的迷你集。

3.2 多模态交互

多模态交互是本工作的主要焦点。基于 ToolSandbox (Lu et al., 2025) 的消息传递和世界状态设计，我们将图像视为一等公民的视觉伪影，而不是静态的提示附件。每张图片都存储在共享的图像数据库中，被分配一个稳定的标识符，并以与其他环境实体相同的方式被工具和消息引用。这种设计使得视觉伪影在多个回合中具有持久性、可重用性和可追溯性。图像交换通过工具调用进行中介。例如，用户可以在对话过程中通过 send_message_with_image 向代理提供图像，代理也可以在需要时以类似的方式向用户返回视觉伪影。我们进一步提供了专门用于调整大小、注释、绘图、转换图像以及生成交互式 UI 的视觉特定工具和其他实用程序。因此，图像成为结构化交互轨迹的一部分，而不是未被追踪的上下文窗口输入。示例如图 1 所示。

3.3 执行模式

MM-ToolSandBox 实现了两种执行模式来调用工具：自由形式的 Code-Execution 和结构化的 Tool-Use。在 Code-Execution 模式下，模型通过标准的聊天补全进行操作，并在 markdown 围栏代码块中编写 Python 代码，遵循“代码即动作”范式 (Trivedi et al., 2024; Wang et al., 2024b)。框架在持久的沙箱解释器中解析并执行代码，其中注册的工具作为可调用的 Python 函数可用。该接口自然地支持涉及循环、条件语句、中间变量和灵活工具组合的复杂工作流，其缺点在于结构约束较少。在 Tool-Use 模式下，模型通过提供商的结构化工具调用 API 进行操作，这通常由 OpenAI、Anthropic 和 Gemini 支持 (OpenAI, 2025; Anthropic, 2026; Gemini, 2025)。在每一步，模型要么响应用户，要么发出由环境执行的受模式约束的工具调用。该接口易于解析、可审计且对格式错误的输出具有鲁棒性，但对于复杂的控制流或多工具组合可能显得繁琐。为了支持该模式下的程序化编排，我们提供了一个 execute_code 工具来调用相同的沙箱解释器，并且代码执行仍然通过结构化的工具调用接口进行中介。

安全护栏。无论代码如何被调用，执行代理生成的 Python 代码都需要谨慎的保护。遵循 AppWorld 的沙箱执行设计理念 (Trivedi et al., 2024) 的精神，

4

第 5 页

MM-ToolSandBox 通过三层护栏保护解释器：(1) 在执行前拒绝不允许的导入和不安全原语的检查；(2) 限制文件访问、拦截危险系统调用并限制内存使用的运行时限制；以及 (3) 对墙钟时间和输出大小的执行限制。

3.4 评估

MM-ToolSandBox 通过两种互补的机制评估场景（如图 1 右侧所示）。基于状态的验证将初始和最终的世界状态快照与场景预期的实体变化进行比较，提供客观、可重现的结果信号。基于量表的 LLM 裁判评估两个角色的轨迹质量：代理裁判评估代理是否正确完成了任务，而用户裁判检查模拟用户的行为是否连贯。这两种机制共同涵盖了每个场景的结果和过程。具体指标在第 4.3 节中定义。

图 2 说明基准设计维度相互作用的示例场景。代理必须 (1) 从产品图像中提取数值信息（视觉定位），(2) 执行算术运算以确定数量（计算流类型），(3) 在用户中途改变计划时进行适应（目标变更挑战），以及 (4) 处理跨轮次到达的图像（渐进式到达）。评估通过将最终购物车状态与预期的实体差异进行对比来验证。

4 基准

MM-ToolSandBox 基准包含 258 个经过人工验证的场景，涵盖了多样的视觉推理模式、对话挑战和应用领域。每个场景都指定了一个多轮、多图像的任务，要求代理从视觉输入中提取信息，导航大型工具空间，并在模拟设备环境中产生正确的状态变化。我们描述了构建基准的设计维度，随后介绍其组成和统计数据。此外，我们还策划了 50 个用于交互式 UI 应用的变体。场景示例如图 2 所示。更多示例见附录 I。

4.1 设计维度

我们沿三个正交轴构建基准，即信息流类型、挑战类型和图像到达模式，它们共同控制推理模式、对话动态和视觉

第 6 页

每个场景的复杂度。

信息流类型。流类型规定了将视觉输入连接到工具动作的推理模式。我们通过系统地分解将多个信息源与动作输出相关联的操作空间，并基于数据处理原语，推导出七种流类型：聚合（cf. union）：将来自多个源的信息组合成单一动作；比较（cf. argmax）：根据标准评估备选方案以选择最佳项；过滤（cf. where）：选择匹配条件的子集；计算（cf. derived column）：通过计算从输入中推导出新值；验证（cf. check）：在行动之前根据约束验证信息；查找链（cf. correlated subquery）：顺序解析引用，每个引用为下一个提供输入；以及交叉引用（cf. join）：跨源匹配信息并对对应关系采取行动。这些流类型施加了真正不同的推理需求，例如，查找链需要从单个图像中进行顺序检索，而过滤和聚合任务则需要同时综合多个图像中的信息。

挑战类型。我们在合作基线之外控制了任务难度的两个维度。首先，两种对话挑战测试代理对不完美的用户行为的鲁棒性：目标变更：用户在对话中途改变方向，要求代理放弃之前的进展并适应修订后的目标；以及错误纠正：用户提供错误的细节（例如，错误识别图像中的内容），测试代理是检测视觉证据与用户指令之间的差异，还是盲目执行。其次，状态突变通过要求代理更新或删除现有实体（而不仅仅是创建新实体）来控制操作复杂性，这需要实体检索和基于证据的修改，而非无约束的创建。没有任何这些属性的场景构成了仅包含创建操作的合作基线。

图像到达模式。到达模式决定了图像何时进入对话：前置：所有图像在第一轮消息中；渐进：图像分布在多个回合中；滞后：图像在对话末尾到达；或混合：上述三种模式的组合。渐进式交付测试代理是否能在交互演进过程中整合新的视觉上下文，而前置式交付测试同时处理多图像的短期记忆能力，这是一种根本不同的认知需求。

4.2 基准组成

图像来源。我们从八个成熟视觉数据集的测试集中获取图像，涵盖了互补的视觉领域：文档（DocVQA (Mathew et al., 2020), OmniDocBench (Ouyang et al., 2025)）、自然场景文本（HierText (Long et al., 2023)）、真实世界场景（WorldVQA (Zhou et al., 2026)）、图表和绘图（ChartQA-Pro (Masry et al., 2025), ChartMuseum (Tang et al., 2025)）、信息图（InfographicVQA (Mathew et al., 2021)）以及软件 UI 截图（ScreenSpotPro (Li et al., 2025b)）。这种多样性确保了基准性能反映的是一般视觉感知能力，而非对单一图像类型的熟练程度。给定图像集后，我们利用自动场景生成流水线生成多样化且具有挑战性的场景集（详见第 5 节）。每个场景需要 3–6 张图像和 2–5 轮用户交互。总共涵盖 1,284 张唯一图像，分布在 258 个场景中，设计维度的分布如图 4 所示。

UI 模式子集。我们将另外 50 个场景子集转换为 UI 模式，其中相同的底层任务必须通过视觉界面交互而非文本来完成。在此模式下，代理充当动态 UI 设计师：它发现后端工具、收集信息，并通过用户通过按钮点击和选择进行决策的交互式屏幕（产品卡片、选择列表、确认对话框）进行渲染。关键的设计原则是用户的决策标准是私有的，因此代理无法在不提供选项并通过 UI 接收用户选择的情况下完成任务。实体差异（Entity diff）规范保持相同，确保无论交互模态如何，都应用相同的程序化评估。第三位裁判（UI judge）额外评估代理是否渲染了具有正确功能 affordances 的适当交互界面。转换后的 UI 场景如图 9 所示。

为了支持交互式 UI 场景，我们实现了一套专用的 UI 工具，用于在代理、用户以及充当 UI 状态服务器的环境之间调解结构化的视觉交互（图 3）。在前端，代理和用户继续像在其他任何场景中一样使用自然语言进行交流。在后端，代理构建声明式 UI 描述并调用渲染工具；环境进行验证，

6

第 7 页

代理 环境 用户

找到像这样的一家餐厅（附照片） (1)

render_ui_screen(restaurant_ui) (2)

<环境> 渲染后的图像 + 交互元素 (3)

show_ui_to_user() (4)

<环境> UI 截图 + 可点击元素信息 (5)

这里有几家拥有海景的相似餐厅！ (6)

ui_user_interact("restaurant_ui", "book-btn") (7)

<环境> 用户在 Ocean Pearl 上点击了“预订” (8)

Ocean Pearl 的预订已确认！ (9)

用户-代理 工具结果 用户-环境 代理活跃 工具调用 环境-用户 环境-代理 代理等待

图 3 交互式 UI 场景的信息流示例。用户模拟器和代理在前端通过自然语言进行交互，而两者在后端都通过专用的 UI 工具与 UI 服务器环境进行交互。代理通过遵循 A2UI 协议编写 Python 代码来生成新的 UI 屏幕，该代码通过 render_ui_screen 执行。环境渲染生成的 UI 屏幕，并将其作为环境消息返回给用户角色。随后，用户模拟器观察屏幕并通过 ui_user_interact 与其交互，模拟点击和输入等常见 UI 操作。

渲染并存储生成的屏幕，然后连同描述可用交互元素的元数据一起交付给用户。用户随后可以通过专用的交互工具执行点击按钮或填写表单字段等操作，环境将这些操作解析为结构化数据，并将其作为通知转发回代理。这种设计保持了对话界面的自然性和可读性，同时通过类型化的工具调用使每个 UI 状态变更都可审计。UI 工具基于最近发布的 A2UI 协议（Google, 2025a）构建。图 3 展示了 UI 交互的信息流。

4.3 评估协议

默认情况下，我们使用 GPT-5.4（OpenAI, 2026）构建用户模拟器，因为我们发现与其他前沿模型相比，该模型在用户保真度和自然对话方面表现最佳。用户和代理角色的提示词分别见附录 E 和附录 F。

代理实现。为了将模型能力与脚手架隔离开来，所有模型共享一个固定的固定框架（Yao et al., 2023; Wang et al., 2024b）。除非另有说明，代理在纯 Code-Execution 模式下运行

7

第 8 页

接口（第 3.3 节）：它运行一个持久的沙盒 Python 解释器，通过 LRU 工作集下的发现工具从完整的 511 工具注册表中按需发现工具，并将交互步骤限制在 100 步以内（涵盖代理和用户角色），并设有每个场景的挂钟时间限制。对于支持该功能的模型，启用了原生思维（Native thinking）。每个模型都接收相同的代理角色系统提示词（附录 E），并与相同的 GPT-5.4 (OpenAI, 2026) 用户模拟器进行交互，所有轨迹均由 Claude 4.5 Sonnet (Anthropic, 2025a) 评分裁判进行评分。我们有意保持此测试框架固定不变：随着代理脚手架越来越主导最终任务性能 (Anthropic, 2025; OpenAI, 2026)，在共同且规范明确的测试框架下比较模型，才能使性能差异归因于模型本身，而非周围系统。我们在第 6.3 节中单独研究了接口本身对性能的影响。

评估器。每个场景均使用第 3.4 节中描述的机制进行评分。代理成功率（Agent SR）是主要指标：代理裁判接收完整的对话轨迹、工具调用及其结果，然后评估五个独立标准：任务完成、指令遵循、工具使用有效性、无副作用和信息准确性，只有当所有五项均通过时，场景才算通过。完整的代理裁判评分提示词见附录 G。实体 F1 分数（Entity F1）通过匈牙利匹配结合类型感知的列相似度（标识符精确匹配、文本 ROUGE-L、时间戳验证；详见附录 A），以编程方式比较实际实体状态变化与预期规范，从而提供分级部分得分。用户成功率（User SR）评估模拟用户的行为是否连贯，作为健全性检查，以确保用户质量不会混淆代理评估（用户裁判评分标准见附录 H）。我们在附录 B 中显示，User SR 与 Agent SR 高度相关，且排除用户失败场景不会改变模型排名，这证实了报告的性能差异反映了真实的代理能力。我们针对人工标注验证了裁判的保真度：代理裁判与保守偏差（倾向于低估而非高估 Agent SR）的人工标注达到 88% 的一致性（Cohen’s κ = 0.748，实质性一致），而用户裁判虽然 κ 值较低（由用户模拟失败的低发生率驱动），但原始一致性很高（77%）。结合 Agent-SR/User-SR 的高相关性（r = 0.81，图 6a），这表明用户模拟器和裁判都是可靠的（附录 C）。

5 场景生成流水线

我们设计了一个自动化流水线，以规模化生成满足第 4.1 节定义的设计维度的多图像、多轮场景。该流水线分为六个阶段（图 4），生成了第 4 节中描述的基准测试。所有基于 LLM 的阶段均使用 Gemini-3.1-Pro。

阶段 1：图像-工具关联。并非所有图像都自然地激发工具使用。给定来自图像语料库的图像，LLM 识别其中是否包含真正可操作的内容，并将其映射到相关的应用领域和特定的工具功能。严格的过滤确保只有那些既需要视觉提取又需要工具调用的图像（即没有图像就无法完成任务）才能进入下游阶段。

阶段 2：图像聚类与流类型选择。随机分组图像会产生强制的、人为的场景。相反，我们首先根据关联领域对图像进行分组，然后使用 CLIP 嵌入相似度将它们聚类为每组 3-6 个图像，确保每组内的高相关性。对于每个聚类，我们评估每种信息流类型和图像到达模式（定义在第 4.1 节）的可行性。一种轻量级的可行性评估对聚类的每种流类型和每种到达模式进行评分（0-3：从不可能到理想）；仅保留自然匹配（评分 ≥2）的情况。如果没有这种预选择，我们观察到 LLM 会默认选择最简单的可行模式，从而导致推理多样性的坍缩。

阶段 3：大纲生成。在生成完整场景之前，流水线通过从阶段 2 中确定的可接受流类型和图像到达模式中进行加权采样，生成结构化大纲，从而引导基准测试中分布的平衡。大纲指定了用户轮次数量（2–5）、选定的流类型和到达模式、所需工具以及挑战类型（第 4.1 节）。

阶段 4：场景生成。大纲使用特定于流类型的提示模板扩展为完整场景，这些模板编码了分配的信息流结构，确保真正的多步推理，而非独立的并行操作。输出包括每轮的用户查询（带有对视觉内容的指示性引用）、控制何时引入新图像或纠正的转换条件、目标以及所有

第 9 页

图 4 场景生成流程概览（上）及生成的基准分布（下）。 上：每个候选图像首先与相关的应用领域和工具关联（阶段 1），然后通过基于 CLIP 的聚类进行分组，并筛选可行的信息流类型和图像到达模式（阶段 2）。从可行的模式中采样结构化多轮大纲并分配挑战类型（阶段 3），然后扩展为包含指示性视觉引用和工具调用的完整多轮对话（阶段 4）。阶段 5 实例化初始环境状态以及用于确定性基于状态评估的预期最终状态。阶段 6 应用基于 LLM 的质量标准，随后进行代理可解性检查和人类专家审查。下：第 4.1 节中三个设计维度（流类型、图像到达模式和挑战类型）以及来源图像数据集的 258 个最终场景的分布。

引用已解析为自动化评估的具体值，以及预先存在的实体要求，即场景有效所必须存在于环境中的数据（例如，现有的日历事件、联系人或电子邮件线程）。从合成人物池中采样的用户配置文件为涉及个性化信息的场景提供了真实的社会背景。

阶段 5：实体生成。基于状态的评估需要完全指定的环境状态。利用阶段 4 中的预先存在的实体要求，LLM 实例化初始实体（填充环境以使场景有效的具体数据）和最终实体（成功完成后的预期环境状态，包括创建、修改和删除的实体），从而通过比较执行后的实际状态与预期结果来实现确定性评估。

阶段 6：自动化质量过滤。每个场景均由 LLM 评判器根据七项质量标准进行评估：多模态必要性、视觉真实性、自包含性、对话步骤完整性、目标灵活性、视觉接地准确性和场景合理性。通过所有标准的场景随后进行平衡下采样，以维持第 4.1 节中设计维度的多样性。然后，通过第 5.1 节中描述的验证协议对下采样集的可解性和实体正确性进行验证。

5.1 质量验证

为了验证每个发布的场景是否可端到端执行，而不仅仅是格式正确，我们在阶段 6 过滤之上添加了一层最终检查，结合了代理回滚检查和人类专家审查。

代理可解性检查。对于每个场景，我们运行一个代理，其系统提示增强了真实信息：预期的实体状态变化、任务完成标准以及预期工具列表。我们默认使用 Claude 4.5 Opus 作为代理骨干；使用具有完整真实信息访问权限的强大模型建立了场景可解性的上限，且不受模型能力混淆的影响。只有当代理实现近乎完美的实体差异匹配（Entity F1 ≥ 0.9）并通过代理评判器裁决时，场景才算通过；失败的场景将被路由以进行纠正或移除。

人类专家审查。由于代理检查无法检测到技术上可解但在语义上与用户意图不一致的场景，因此通过代理检查的每个场景都会进一步由人类专家审查员进行检查。审查员验证对话、预期工具、实体规范以及

9

第 10 页

表 2 主要结果。除非另有说明，所有模型均在启用思考模式并使用 Code-Execution 接口进行评估。

| Model | Agent Success Rate ↑ | Entity F1 ↑ | Avg. Steps ↓ | | :— | :—: | :—: | :—: | | Qwen 3.5-4B (Qwen, 2026) | 0.116 | 0.641 | 54.5 | | Qwen 3.5-9B (Qwen, 2026) | 0.190 | 0.693 | 53.8 | | Qwen 3.5-27B (Qwen, 2026) | 0.349 | 0.792 | 46.9 | | Qwen 3.5-35B-A3B (Qwen, 2026) | 0.260 | 0.751 | 48.0 | | Qwen 3.5-397B-A17B (Qwen, 2026) | 0.353 | 0.793 | 50.4 | | GLM 4.6V (Hong et al., 2025) | 0.190 | 0.709 | 46.6 | | KIMI 2.6 (KIMI, 2026) | 0.415 | 0.817 | 48.1 | | GPT-5.4 (no thinking) (OpenAI, 2026) | 0.291 | 0.794 | 27.8 | | GPT-5.4 (thinking-medium) (OpenAI, 2026) | 0.361 | 0.811 | 27.6 | | GPT-5.4 (thinking-high) (OpenAI, 2026) | 0.415 | 0.865 | 36.1 | | Gemini 3.0 Flash (Google, 2025b) | 0.364 | 0.619 | 34.9 | | Gemini 3.1 Pro (Google, 2026) | 0.481 | 0.847 | 42.6 | | Claude 4.5 Sonnet (Anthropic, 2025a) | 0.337 | 0.817 | 50.8 | | Claude 4.5 Opus (Anthropic, 2025b) | 0.488 | 0.848 | 40.8 |

图 5 场景分析。(a) 图像到达研究。(b) 场景内的图像数量。(c) 挑战类型。(d) 针对 Claude 4.5 Opus 模型的信息流研究。

挑战类型相互一致，且视觉引用明确指向附加图像。存在局部问题的场景会在原位进行修正并通过预言机重新运行；存在结构性缺陷的场景则被丢弃。

过滤漏斗。整个流水线从 10,466 张候选图像过滤至 258 个最终场景：图像-工具关联保留了 6,428 张可操作图像（61.4%）；聚类和生成产生了 1,152 个场景；第 6 阶段的 LLM 批评家通过了 599 个（52.0%）；平衡下采样选择了 300 个；预言机验证加上人工审查得出了最终的 258 个。

6 实验

我们在 MM-ToolSandBox 基准上评估了 12 个强大的多模态基础模型，涵盖了专有模型（GPT-5.4 (OpenAI, 2026), Gemini-3.1 (Google, 2025b, 2026), Claude 4.5 (Anthropic, 2025b,a)）以及参数范围广泛的开源权重模型（Qwen 3.5 4B – 397B 参数 (Qwen, 2026)，拥有 106B 参数的 GLM 4.6V (Hong et al., 2025)，以及拥有超过 1T 参数的 KIMI 2.6 (KIMI, 2026)）。除非另有说明，所有模型均使用 Code-Execution 接口进行评估，包含完整的 511 个工具集，最大步数为 100 步（包括代理和用户角色）。指标定义见第 4.3 节，包括代理成功率（SR）、用于实体验证的实体 F1 分数以及平均步数。

第 11 页

6.1 主要结果

主要实验结果如表2所示。我们强调四点观察：1. 视觉工具调用对前沿模型来说仍然具有挑战性。即使是性能最强的模型 Claude 4.5 Opus，其代理成功率（Agent Success Rate）也仅为 48.8%，而获得最高实体 F1 分数（Entity F1）的 GPT-5.4 (thinking-high) 也仅达到 0.865。这些结果表明，多步视觉工具调用仍然困难，需要基于图像的推理、状态更新以及与动态用户行为的交互。2. 代理成功率（Agent SR）、实体 F1 分数（Entity F1）和平均步数（Avg. Steps）捕捉了性能的不同方面。Claude 4.5 Opus 在代理成功率上比 GPT-5.4 (thinking-medium) 高出超过 12%，但在实体 F1 分数上仅相差 3%，这反映了过程级任务完成与最终状态一致性之间的差异。平均步数提供了进一步的互补信号，因为更多的步数并不必然导致更高的成功率，如 Qwen 3.5 模型系列所示。3. 推理显著提高了任务完成率。GPT-5.4 在启用原生思维链时显示出明显的提升：代理成功率从没有思维链时的 29.1% 提升至中等思维链时的 36.1% 和高思维链时的 41.5%。实体 F1 分数也从 0.794 增加到 0.865，表明额外的推理预算对于视觉工具调用至关重要。4. 扩大模型规模显著提高了任务完成率。Qwen 3.5 系列提供了跨模型规模的受控比较。性能从 4B 到 27B 有显著提升，代理成功率提高了超过 23 个百分点（从 0.116 到 0.349）。

6.2 场景分布分析

我们进一步研究了模型在 MM-ToolSandBox（第4节）设计的视觉复杂度和信息流模式下的行为。图5a显示，所有图像均在对话初期一次性提供的场景比渐进式图像交付的场景要困难得多，成功率差距接近 20%。这并不令人惊讶，因为对于一次性提供（Upfront）场景，后续轮次通常需要引用对话开始时发送的图像，此时已经过去了数十次工具调用交互，这考验了模型的长上下文视觉指代能力。而延迟（Late）和渐进（Progressive）模式主要在图像到达时同时交付与图像相关的指令，这使得模型更容易定位相关的视觉线索。这一结果表明，多图像工作记忆是当前模型的一个关键瓶颈。图5b进一步考察了随着图像数量增加，模型性能的变化。Qwen 3.5、Claude 4.5 Opus 和 GPT-5.4 的成功率随着图像数量的增加而持续下降，突显了多图像交互的挑战。相比之下，KIMI 2.6 保持相对稳定，表明其对不断增加的视觉上下文具有更强的鲁棒性。图5c比较了不同挑战类型之间的性能。有趣的是，目标变更（goal change）类别产生了最高的成功率（SR），因为完成标准仅捕捉目标变更后需要发生的事情，实质上减少了代理的任务长度/复杂度。另一方面，状态突变（State Mutation）对代理构成了真正的挑战，因为它需要在行动之前在环境中找到必要的实体。最后，图5d报告了 Claude 4.5 Opus 在不同信息流类型下的代理成功率。需要多图像综合的信息流类型（如过滤和聚合）比单图像检索模式（如查找链）困难近两倍，再次突显了模型在视觉推理能力方面需要改进。

6.3 代理设计分析

正如第4.3节所阐述的，围绕模型构建的测试框架越来越影响其最终任务性能。在保持主要比较中的测试框架固定的前提下，我们现在直接研究代理实现设计。

用户模拟研究。由于我们的基准测试侧重于多轮用户-代理交互，用户模拟的质量至关重要。为了验证用户模拟质量不会混淆我们的主要发现，我们在排除所有被判定为用户模拟器失败的场景后，重新计算了代理成功率（Agent SR）和实体 F1 分数（Entity F1）（见附录表5）。尽管存在一些变化，但整体排名完全保持不变，表明用户模拟质量并未混淆结果。

我们在图6a中绘制了使用18个模型 rollout（包括代码执行（Code-Execution）和工具使用（Tool-Use）变体）的用户成功率（User SR）与代理成功率（Agent SR）的关系。强烈的线性关系（r = 0.81）表明，用户模拟质量主要由代理行为驱动：产生不连贯动作、未能回应查询或

第 12 页

0.90 r = 0.81 p < 0.001 0.45 0.5 Tool-use Qwen 3.5-397B-A17B 0.85 Code execution 0.40 GPT-5.4 (no thinking) 0.4 SR 0.35 SR SR 0.80 0.3 User 0.30

0.75 Agent 0.2 Agent 0.25 Code execution 0.1 0.20 0.70 Tool-use 0.0 0.15 0.1 0.2 0.3 0.4 0.5 GPT-5.4 4.5Sonnet 3.5-397B KIMI2.6 Mini(30) Compact(165) Medium(276) (511)Full Agent SR Claude Qwen Toolset

(a) (b) (c)

图 6 (a)。Agent SR 与 User SR 之间的相关性。(b)。比较 Tool-Use 和 Code-Execution 界面设计。(c)。不同工具集界面设计下的 Agent SR。

进入重试循环会破坏用户稳定性，导致较低的 User SR。这证实了表 2 中的性能差异反映了真实的代理能力，而非用户模拟的伪影。

执行模式消融实验 如第 3 节所述，MM-ToolSandBox 支持 Tool-Use 和 Code-Execution 模式。在此，我们研究模型在不同执行接口下的行为。结果如图 6b 所示。比较 Code-Execution 与 Tool-Use 模式，我们发现存在模型依赖的偏好：Claude 4.5 Sonnet 和 Qwen 3.5-397B 强烈偏好 Code-Execution 模式（分别高出 7.7 和 6.6 个百分点），GPT-5.4 对模式不敏感（高出 1.2 个百分点），而 KIMI 2.6 在 Tool-Use 模式下的表现反而强于 Code-Execution 模式（高出 45.0 个百分点）。没有确凿证据表明一种接口优于另一种。结果取决于模型。

工具箱粒度消融实验 我们对工具箱接口进行了消融实验，从完整的 511 工具注册表变化到 30 个超级工具，同时保持底层功能相同，所有层级都调度到相同的后端 API 并产生相同的状态变化。结果如图 6c 所示。Agent SR 在不同工具箱层级之间在小范围内波动，未出现明显的模式。在效率方面，Qwen 呈现出 U 形阶梯曲线：Compact（165 个工具）效率最高，为 45.5 步，Full 和 Medium 居中，分别为 50.4 和 50.3 步，Mini 最慢，为 61.4 步。GPT-5.4 则表现出相反的趋势：步数从 Full（27.8）、Medium（26.7）、Compact（26.5）到 Mini（23.3）单调递减。这种分歧可能反映了模型在处理工具模式复杂性与搜索成本方面的架构差异。

6.4 失败分析

除了聚合指标外，我们对强模型进行了详细的失败分析，以理解代理失败的原因以及能力改进最需要的地方。我们的 LLM 评分裁判针对每个场景评估五个独立标准，即任务完成、指令遵循、工具使用有效性、无副作用和信息准确性。只有当所有五个标准都通过时，场景才算通过。通过检查哪些标准失败以及它们如何共同发生，我们构建了失败的根因分类法。事实错误：任务完成通过，但信息准确性失败。代理执行了正确的工作流，但从图像中提取了错误的信息（例如，错误识别了对象，从图像中读取了错误的值）。任务失败：代理根本无法完成主要操作——缺失整个工作流步骤，找不到资源，或进入不可恢复的循环，这属于规划/执行失败。执行不完整：任务完成和信息准确性均通过，但指令遵循失败。代理完成了任务且事实正确，但遗漏了特定要求，例如遗漏了 N 个项目中的一个。不受控行为：仅无副作用标准失败。代理执行了超出任务范围的非预期操作，例如创建额外实体、留下之前尝试的残留状态等。

12

第 13 页

表 3 失败根本原因分类体系。百分比是相对于每个模型总失败数的比例。

| 模型 | 事实错误 | 任务失败 | 执行不完整 | 行为失控 | | :— | :— | :— | :— | :— | | Claude 4.5 Opus (Anthropic, 2025b) (132) | 70 (53.0%) | 31 (23.5%) | 19 (14.4%) | 12 (9.1%) | | GPT-5.4 (thinking) (OpenAI, 2026) (151) | 76 (50.3%) | 35 (23.2%) | 20 (13.2%) | 20 (13.2%) | | KIMI 2.6 (KIMI, 2026) (151) | 74 (49.0%) | 51 (33.8%) | 14 (9.3%) | 12 (7.9%) | | Qwen 3.5-397B-A17B (Qwen, 2026) (167) | 85 (50.9%) | 53 (31.7%) | 12 (7.2%) | 17 (10.2%) |

<br>

事实错误 任务失败 执行不完整 行为失控

SR: 12% 19% 35% 35% 49%

100 80 60 40 20 0 Qwen 4B Qwen 9B Qwen 27B Qwen 397B Opus

图 7 不同模型规模下的失败根本原因分布。随着模型规模的增长，任务失败（规划）让位于事实错误（视觉精度），成为主要的失败模式。

6.5 UI 模式

表 3 显示，所有模型一半的失败源于事实错误，即代理成功完成了任务工作流并正确使用了工具，但从视觉输入中提取了错误信息。例如，对这 70 起 Claude Opus 失败案例进行子分类，我们发现物体误识别占主导地位（29 例），其次是细粒度文本提取错误（16 例）。这些错误并非规划失败：代理知道该做什么，但无法精确感知所见内容。我们得出结论，视觉精度而非工具使用能力是主要瓶颈。

图 7 追踪了 Qwen-3.5 模型扩展曲线和 Claude 4.5 Opus 的失败分类体系。我们观察到视觉感知错误与规划错误之间的交叉：在 4B 规模时，任务失败占主导地位（占失败总数的 51%），反映出不具备规划和执行多步工作流的能力。到 27B 规模时，任务失败降至 30%，事实错误成为主导模式（51%）。这种交叉延续至 Opus，其中事实错误占失败总数的 53%，而任务失败仅占 23%。结果表明，对于小型模型（低于约 27B 参数），主要瓶颈是代理规划：模型无法弄清楚该做什么。在此规模及以上，规划问题已基本解决，瓶颈转向视觉精度：模型无法准确感知所见内容。这表明在视觉工具调用任务上，改进小型模型与大型模型需要 fundamentally different 的研究方向，即模型扩展揭示了一种从规划到精度的失败模式交叉现象。

我们在图 10 中进一步展示了 Claude 4.5 Opus 代理的一个事实错误案例，并在附录中展示了几个失败错误案例。

作为初步探索，我们在一个包含 50 个场景的 UI 子集上评估了四个模型，其中代理必须渲染交互式视觉界面以辅助用户决策，而不是通过表 4 中的文本进行通信。即使表现最好的模型（KIMI 2.6）其 Agent SR 也仅为 26.0%，相较于其在基于文本的 Tool-Use 模式下相同基础任务上的 45.0% 出现了显著下降。主要瓶颈在于 UI 渲染本身：模型经常无法生成具有正确功能暗示（affordances）的功能性界面，从而触发重试循环，使平均步骤数膨胀至 75-93 步。这些结果表明，即时设计和渲染交互式界面比基于文本的工具调用要困难得多，这为未来基准测试的扩展指明了一个有前景的方向。换句话说，UI 模式揭示了一个新的能力前沿。

13

第 14 页

表 4 UI 模式结果（50 场景子集，Tool-Use 模式）。与相同基础任务上的基于文本的交互相比，所有模型的性能均出现大幅下降。

| Model | Agent SR | UI SR | User SR | Entity F1 | Avg. Steps | | :— | :— | :— | :— | :— | :— | | Claude 4.5 Opus (Anthropic, 2025b) | 0.200 | 0.280 | 0.680 | 0.609 | 74.5 | | GPT-5.4 (thinking) (OpenAI, 2026) | 0.020 | 0.360 | 0.340 | 0.279 | 92.5 | | KIMI 2.6 (KIMI, 2026) | 0.260 | 0.420 | 0.514 | 0.699 | 81.7 | | Qwen 3.5-397B-A17B (Qwen, 2026) | 0.100 | 0.200 | 0.460 | 0.619 | 75.8 |

7 结论

我们介绍了 MM-ToolSandBox，这是一个用于评估视觉接地工具调用代理的统一框架和基准。该框架提供了一个状态感知、多轮、多图像的模拟环境，涵盖 16 个应用领域的 511 个工具，并提供 Code-Execution 和结构化 Tool-Use 接口。配套的基准测试包含 258 个经人工验证的场景，以及 50 个交互式 UI 变体，这些变体由一个可扩展的、由信息流引导的生成管道产生，将标注负担减少到针对性的人工审查。在对 12 个前沿和开源权重模型进行评估后，我们发现视觉工具调用远未解决：即使是最强的模型，其任务完成率也不到一半。

我们的分析揭示了几点观察结果，希望能为未来的工作提供指导。首先，视觉精度而非 Tool-Use 能力是强大模型的主要瓶颈：最强模型超过一半的失败源于误读视觉输入，尽管其任务工作流在其他方面是正确的。与此相关的是，失败模式随规模而变化，较小模型主要在规划（决定做什么）方面失败，而较大模型主要在感知（准确 grounding 所见内容）方面失败，这意味着在不同能力水平上需要不同的研究方向。多图像工作记忆是另一个关键限制，随着图像数量的增加，性能会下降，特别是当需要从长对话早期召回图像时。虽然推理预算和模型规模都能提高任务完成率，但两者均未缩小视觉精度差距。最后，代理 harness 很重要，且其效果因模型而异，因为没有任何单一的执行接口或工具箱粒度在所有情况下都是最优的，这凸显了在统一且明确指定的 harness 下比较模型的价值；此外，交互式 UI 生成成为一个显著更难的领域，与基于文本的工具使用相比，性能出现大幅下降。

8 局限性

我们讨论本工作的以下局限性：我们的主要指标依赖于 LLM 裁判（Claude 4.5 Sonnet），其与人类标注者的一致性达到 88%（κ = 0.748）。虽然这代表了与保守偏差的一致性，但裁判可能会系统地遗漏某些失败模式。此外，同一模型家族中的自我偏好偏差是一个已知效应（He et al., 2024），我们使用 Claude 4.5 Opus 作为可解决性过滤器的 oracle，这两个因素可能会高估 Claude 家族模型的性能。此外，主要结果报告的是单次运行评估，没有置信区间。虽然我们在相同的实验设置下观察到结果方差较低（标准差约为 1.6 个百分点），但未来的工作应正式量化这种方差。自动化管道使用 Gemini-3.1-Pro 进行场景生成，这可能会在任务结构或难度上引入系统性偏差。在自我生成的数据上评估 Gemini-3.1-Pro 可能会高估其性能。人工验证减轻了但并未消除这种风险，因为审查员评估的是合理性，而非穷尽地测试边缘情况。最后，为了保持模型比较的公平性，我们在单一固定的 harness（第 4.3 节）下评估每个模型，而不是针对每个模型调整脚手架。由于代理性能对 harness 敏感，我们报告的数字反映的是模型在此特定标准化设置下的能力，而不是每个模型在定制化的、特定于模型的 harness 下所能达到的最佳性能。系统地探索代理 harness 设计空间是未来工作的一个有前景的方向。

9 致谢

我们要感谢 Andrew Szot 提供的宝贵建议和讨论。

14

第 15 页

参考文献

Harsh Agrawal, Eldon Schoop, Xinlei Pan, Anuj Mahajan, Ari Seff, Di Feng, Ruijia Cheng, Andres Romero Mier Y Teran, Esteban Gomez, Abhishek Sundararajan, 等. UINavBench: 一个用于全面评估交互式数字代理的框架. 在 IEEE/CVF 计算机视觉国际会议论文集 (Proceedings of the IEEE/CVF International Conference on Computer Vision) 中, 页码 23353–23363, 2025.

Anthropic. 有效驾驭长期运行的代理. https://www.anthropic.com/engineering/ effective-harnesses-for-long-running-agents, 2025. Anthropic 工程博客.

Anthropic. 介绍 Claude Sonnet 4.5, 2025a. URL https://www.anthropic.com/news/claude-sonnet-4-5.

Anthropic. 介绍 Claude Opus 4.5, 2025b. URL https://www.anthropic.com/news/claude-opus-4-5.

Anthropic. 使用 Claude 进行工具调用, 2026. URL https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview.

Chaithanya Bandi, Ben Hertzberg, Geobio Boo, 等. Mcp-atlas: 一个针对具有真实 MCP 服务器的工具使用能力的基准测试. arXiv 预印本 arXiv:2602.00933, 2026.

Victor Barres, Honghua Dong, Soham Ray, Xujie Si, 和 Karthik Narasimhan. τ 2-bench: 在双控环境中评估对话代理, 2025. URL https://arxiv.org/abs/2506.07982.

Di Feng, Kaixin Ma, Feng Nan, Haofeng Chen, Bohan Zhai, David Griffiths, Mingfei Gao, Zhe Gan, Eshan Verma, Yinfei Yang, Zhifeng Chen, 和 Afshin Dehghan. So-bench: 多模态大模型的结构化输出评估, 2026. URL https://arxiv.org/abs/2511.21750.

Romain Froger, Amine Benhalloum, Andrey Rusakov, Dheeraj Mekala, Emilien Garreau, Gerard Moreno-Torres Bertran, Grégoire Mialon, Hugo Laurençon, Jean-Baptiste Gaya, Kunal Malkan, Mathieu Rita, Matteo Bettini, Maxime Lecanu, Mengjue Wang, Pierre Andrews, Pierre Menard, Thomas Scialom, Ulyana Piterbarg, Virginie Do, Amar Budhiraja, Ian Yu, Mikhail Plekhanov, Ricardo Silveira Cabral, 和 Vladislav Vorotilov. Gaia2: 在动态和异步环境中对 LLM 代理进行基准测试. 在第十四届国际学习表征会议 (The Fourteenth International Conference on Learning Representations) 上, 2026. URL https://openreview.net/forum?id=9gw03JpKK4.

Gemini. 使用 Gemini API 进行函数调用, 2025. URL https://ai.google.dev/gemini-api/docs/function-calling.

Google. 介绍 A2UI: 一个用于代理驱动界面的开源项目, 2025a. URL https://developers.googleblog.com/ introducing-a2ui-an-open-project-for-agent-driven-interfaces/.

Google. 速度与前沿智能的最佳选择, 2025b. URL https://deepmind.google/models/gemini/flash/.

Google. 复杂任务和将创意概念变为现实的最佳选择, 2026. URL https://deepmind.google/models/gemini/pro/.

Hongliang He, Wenlin Yao, Kaixin Ma, Wenhao Yu, Yong Dai, Hongming Zhang, Zhenzhong Lan, 和 Dong Yu. WebVoyager: 使用大型多模态模型构建端到端的 Web 代理. 在 Lun-Wei Ku, Andre Martins, 和 Vivek Srikumar 编辑的 第 62 届计算语言学协会年会论文集 (Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics) (第 1 卷: 长论文) 中, 页码 6864–6890, 泰国曼谷, 2024 年 8 月. 计算语言学协会. doi: 10.18653/v1/2024.acl-long.371. URL https://aclanthology.org/2024.acl-long.371/.

Wenyi Hong, Wenmeng Yu, Xiaotao Gu, Guo Wang, Guobing Gan, Haomiao Tang, Jiale Cheng, Ji Qi, Junhui Ji, Lihang Pan, Shuaiqi Duan, Weihan Wang, Yan Wang, Yean Cheng, Zehai He, Zhe Su, Zhen Yang, Ziyang Pan, Aohan Zeng, Baoxu Wang, Bin Chen, Boyan Shi, Changyu Pang, Chenhui Zhang, Da Yin, Fan Yang, Guoqing Chen, Jiazheng Xu, Jiale Zhu, Jiali Chen, Jing Chen, Jinhao Chen, Jinghao Lin, Jinjiang Wang, Junjie Chen, Leqi Lei, Letian Gong, Leyi Pan, Mingdao Liu, Mingde Xu, Mingzhi Zhang, Qinkai Zheng, Sheng Yang, Shi Zhong, Shiyu Huang, Shuyuan Zhao, Siyan Xue, Shangqin Tu, Shengbiao Meng, Tianshu Zhang, Tianwei Luo, Tianxiang Hao, Tianyu Tong, Wenkai Li, Wei Jia, Xiao Liu, Xiaohan Zhang, Xin Lyu, Xinyue Fan, Xuancheng Huang, Yanling Wang, Yadong Xue, Yanfeng Wang, Yanzi Wang, Yifan An, Yifan Du, Yiming Shi, Yiheng Huang, Yilin Niu, Yuan Wang, Yuanchang Yue, Yuchen Li, Yutao Zhang, Yuting Wang, Yu Wang, Yuxuan Zhang, Zhao Xue, Zhenyu Hou, Zhengxiao Du, Zihan Wang, Peng Zhang, Debing Liu, Bin Xu, Juanzi Li, Minlie Huang, Yuxiao Dong, 和 Jie Tang. Glm-4.5v 和 glm-4.1v-thinking: 迈向可扩展强化学习的多功能多模态推理, 2025. URL https://arxiv.org/abs/2507.01006.

Hongrui Jia, Jitong Liao, Xi Zhang, Haiyang Xu, Tianbao Xie, Chaoya Jiang, Ming Yan, Si Liu, Wei Ye, 和 Fei Huang. OSWorld-MCP: 对计算机使用代理中的 MCP 工具调用进行基准测试. arXiv 预印本 arXiv:2510.24563, 2025.

Dongzhi Jiang, Renrui Zhang, Ziyu Guo, Yanmin Wu, Jiayi Lei, Pengshuo Qiu, Pan Lu, Zehui Chen, Chaoyou Fu, Guanglu Song, Peng Gao, Yu Liu, Chunyuan Li, 和 Hongsheng Li. Mmsearch: 评估大模型作为多模态搜索引擎的潜力, 2024. URL https://arxiv.org/abs/2409.12959.

15

第 16 页

KIMI. Kimi k2.6: 推进开源编码，2026。URL https://www.kimi.com/blog/kimi-k2-6。

Jing Yu Koh, Robert Lo, Lawrence Jang, Vikram Duvvur, Ming Lim, Po-Yu Huang, Graham Neubig, Shuyan Zhou, Russ Salakhutdinov, 和 Daniel Fried。VisualWebArena：在逼真的视觉网页任务上评估多模态智能体。收录于 Lun-Wei Ku, Andre Martins, 和 Vivek Srikumar 编辑的《第 62 届计算语言学协会年度会议论文集（第一卷：长论文）》，第 881–905 页，泰国曼谷，2024 年 8 月。计算语言学协会。doi: 10.18653/v1/2024.acl-long.50。URL https://aclanthology.org/2024.acl-long.50/。

Quyu Kong, Xu Zhang, Zhenyu Yang, Nolan Gao, Chen Liu, Panrong Tong, Chenglin Cai, Hanzhang Zhou, Jianan Zhang, Liangyu Chen, Zhidan Liu, Steven Hoi, 和 Yue Wang。Mobileworld：在智能体-用户交互和 MCP 增强环境中评估自主移动智能体，2025。URL https://arxiv.org/abs/2512.19432。

Junlong Li, Wenshuo Zhao, Jian Zhao, Weihao Zeng, Haoze Wu, Xiaochen Wang, Rui Ge, Yuxuan Cao, Yuzhen Huang, Wei Liu, Junteng Liu, Zhaochen Su, Yiyang Guo, Fan Zhou, Lueyang Zhang, Juan Michelini, Xingyao Wang, Xiang Yue, Shuyan Zhou, Graham Neubig, 和 Junxian He。The tool decathlon：为多样化、逼真且长周期任务执行评估语言智能体。arXiv 预印本 arXiv:2510.25726，2025a。

Kaixin Li, Ziyang Meng, Hongzhan Lin, Ziyang Luo, Yuchen Tian, Jing Ma, Zhiyong Huang, 和 Tat-Seng Chua。 Screenspot-pro：面向专业高分辨率计算机使用的 GUI 定位，2025b。URL https://arxiv.org/abs/2504. 07981。

Minghao Li, Yingxiu Zhao, Bowen Yu, Feifan Song, Hangyu Li, Haiyang Yu, Zhoujun Li, Fei Huang, 和 Yongbin Li。 API-bank：面向工具增强型大语言模型的综合基准测试。收录于 Houda Bouamor, Juan Pino, 和 Kalika Bali 编辑的《2023 年自然语言处理实证方法会议论文集》，第 3102–3116 页，新加坡，2023 年 12 月。计算语言学协会。doi: 10.18653/v1/2023.emnlp-main.187。 URL https://aclanthology.org/2023.emnlp-main.187/。

Shilong Li, Xingyuan Bu, Wenjie Wang, Jiaheng Liu, Jun Dong, Haoyang He, Hao Lu, Haozhe Zhang, Chenchen Jing, Zhen Li, Chuanhao Li, Jiayi Tian, Chenchen Zhang, Tianhao Peng, Yancheng He, Jihao Gu, Yuanxing Zhang, Jian Yang, Ge Zhang, Wenhao Huang, Wangchunshu Zhou, Zhaoxiang Zhang, Ruizhe Ding, 和 Shilei Wen。Mm- browsecomp：面向多模态浏览智能体的综合基准测试，2025c。URL https://arxiv.org/abs/2508.13186。

Zhangheng Li, Keen You, Haotian Zhang, Di Feng, Harsh Agrawal, Xiujun Li, Mohana Moorthy, Jeffrey Nichols, Yinfei Yang, 和 Zhe Gan。Ferret-UI 2：跨平台掌握通用用户界面理解。收录于《表示学习国际会议》，卷 2025，第 99783–99806 页，2025d。

Shangbang Long, Siyang Qin, Dmitry Panteleev, Alessandro Bissacco, Yasuhisa Fujii, 和 Michalis Raptis。ICDAR 2023 分层文本检测与识别竞赛。arXiv 预印本 arXiv:2305.09750，2023。

Jiarui Lu, Thomas Holleis, Yizhe Zhang, Bernhard Aumayer, Feng Nan, Haoping Bai, Shuang Ma, Shen Ma, Mengyu Li, Guoli Yin, 等。Toolsandbox：面向大语言模型工具使用能力的有状态、对话式、交互式评估基准。收录于《计算语言学协会：NAACL 2025 发现论文集》，第 1160–1183 页，2025。

Ahmed Masry, Mohammed Saidul Islam, Mahir Ahmed, Aayush Bajaj, Firoz Kabir, Aaryaman Kartha, Md Tah- mid Rahman Laskar, Mizanur Rahman, Shadikur Rahman, Mehrad Shahmohammadi, Megh Thakkar, Md Rizwan Parvez, Enamul Hoque, 和 Shafiq Joty。ChartQAPro：一个更多样化且具挑战性的图表问答基准。收录于 Wanxiang Che, Joyce Nabende, Ekaterina Shutova, 和 Mohammad Taher Pilehvar 编辑的 《计算语言学协会：ACL 2025 发现论文集》，第 19123–19151 页，奥地利维也纳，2025 年 7 月。计算语言学协会。ISBN 979-8-89176-256-5。doi: 10.18653/v1/2025.findings-acl.978。 URL https://aclanthology.org/2025.findings-acl.978/。

Minesh Mathew, Dimosthenis Karatzas, R. Manmatha, 和 C. V. Jawahar。Docvqa：面向文档图像视觉问答的数据集。CoRR，abs/2007.00398，2020。URL https://arxiv.org/abs/2007.00398。

Minesh Mathew, Viraj Bagal, Rubèn Pérez Tito, Dimosthenis Karatzas, Ernest Valveny, 和 C. V Jawahar。Infograph- icvqa，2021。URL https://arxiv.org/abs/2104.12756。

OpenAI。OpenAI 开发者函数调用，2025。URL https://developers.openai.com/api/docs/guides/function-calling。

OpenAI。介绍 GPT-5.4，2026。URL https://openai.com/index/introducing-gpt-5-4/。

OpenAI。工程化利用。https://openai.com/index/harness-engineering/，2026。OpenAI 博客。

Linke Ouyang, Yuan Qu, Hongbin Zhou, Jiawei Zhu, Rui Zhang, Qunshu Lin, Bin Wang, Zhiyuan Zhao, Man Jiang, Xiaomeng Zhao, Jin Shi, Fan Wu, Pei Chu, Minghao Liu, Zhenxiang Li, Chao Xu, Bo Zhang, Botian Shi, Zhongying Tu, 和 Conghui He。Omnidocbench：通过综合标注评估多样化 PDF 文档解析，2025。URL https://arxiv.org/abs/2412.07626。

16

第 17 页

Shishir G Patil, Huanzhi Mao, Fanjia Yan, Charlie Cheng-Jie Ji, Vishnu Suresh, Ion Stoica, 和 Joseph E. Gonzalez。 贝叶斯函数调用排行榜（BFCL）：从工具使用到大语言模型的代理评估。在第四十二届国际机器学习会议，2025。URL https://openreview.net/forum?id=2GmDdhBdDk。

Qwen。Qwen3.5：通过原生多模态代理加速生产力，2026年2月。URL https://qwen.ai/blog?id= qwen3.5。

Christopher Rawles, Sarah Clinckemaillie, Yifan Chang, Jonathan Waltz, Gabrielle Lau, Marybeth Fair, Alice Li, William E Bishop, Wei Li, Folawiyo Campbell-Ajala, Daniel Kenji Toyama, Robert James Berry, Divya Tyamagundlu, Timothy P Lillicrap, 和 Oriana Riva。Androidworld：用于自主代理的动态基准测试环境。 在第十三届国际学习表征会议，2025。URL https://openreview.net/forum?id=il5yUQsrjC。

Liyan Tang, Grace Kim, Xinyu Zhao, Thom Lake, Wenxuan Ding, Fangcong Yin, Prasann Singhal, Manya Wadhwa, Zeyu Leo Liu, Zayne Sprague, Ramya Namuduri, Bodun Hu, Juan Diego Rodriguez, Puyuan Peng, 和 Greg Durrett。Chartmuseum：测试大型视觉语言模型的视觉推理能力，2025。URL https: //arxiv.org/abs/2505.13444。

Harsh Trivedi, Tushar Khot, Mareike Hartmann, Ruskin Manku, Vinty Dong, Edward Li, Shashank Gupta, Ashish Sabharwal, 和 Niranjan Balasubramanian。Appworld：一个可控的应用与人物世界，用于基准测试交互式编码代理。 在计算语言学协会第六十二届年度会议论文集（第一卷：长论文），第16022–16076页，2024。

Haoming Wang, Haoyang Zou, Huatong Song, Jiazhan Feng, Junjie Fang, Junting Lu, Longxiang Liu, Qinyu Luo, Shihao Liang, Shijue Huang, 等人。UI-TARS-2 技术报告：通过多轮强化学习推进 GUI 代理。arXiv 预印本，第 arXiv–2509 页，2025。

Jize Wang, Ma Zerun, Yining Li, Songyang Zhang, Cailian Chen, Kai Chen, 和 Xinyi Le。GTA：通用工具代理的基准测试。 在第三十八届神经信息处理系统会议数据集与基准测试轨道，2024a。URL https://openreview.net/forum?id=akEt8QAa6V。

Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng, 和 Heng Ji。可执行代码动作能激发更好的 LLM 代理。 在第四十一届国际机器学习会议，2024b。

Tianbao Xie, Danyang Zhang, Jixuan Chen, Xiaochuan Li, Siheng Zhao, Ruisheng Cao, Toh Jing Hua, Zhoujun Cheng, Dongchan Shin, Fangyu Lei, Yitao Liu, Yiheng Xu, Shuyan Zhou, Silvio Savarese, Caiming Xiong, Victor Zhong, 和 Tao Yu。OSWorld：在真实计算机环境中对开放式任务的多模态代理进行基准测试。 在第三十八届神经信息处理系统会议数据集与基准测试轨道，2024。URL https://openreview.net/forum?id=tN61DTr4Ed。

Zidi Xiu, David Q. Sun, Kevin Cheng, Maitrik Patel, Josh Date, Yizhe Zhang, Jiarui Lu, Omar Attia, Raviteja Vemulapalli, Oncel Tuzel, Meng Cao, 和 Samy Bengio。Astra-bench：结合个人用户上下文评估工具使用代理的推理和行动规划，2026。URL https://arxiv.org/abs/2603.01357。

Zhen Yang, Zi-Yi Dou, Di Feng, Forrest Huang, Anh Nguyen, Keen You, Omar Attia, Yuhao Yang, Michael Feng, Haotian Zhang, 等人。Ferret-UI Lite：构建小型端侧 GUI 代理的经验教训。arXiv 预印本 arXiv:2509.26539，2025。

Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, 和 Yuan Cao。ReAct：协同 语言模型中的推理与行动。在国际学习表征会议（ICLR），2023。

Runjie Zhou, Youbo Shao, Haoyu Lu, Bowei Xing, Tongtong Bai, Yujie Chen, Jie Zhao, Lin Sui, Haotian Yao, Zijia Zhao, 等人。Worldvqa：衡量多模态大语言模型中的原子世界知识。arXiv 预印本 arXiv:2602.02537，2026。

17

第 18 页

A 评估协议细节

A.1 代理成功率 (Agent SR)。

LLM 评分裁判（Claude 4.5 Sonnet）评估五个独立标准，每个标准均按通过/失败打分：

• 任务完成：是否执行了主要操作且工具调用是否成功？

• 指令遵循：所有具体细节（姓名、日期、金额、接收者）是否正确？

• 工具使用有效性：工具的使用是否有效且充分，且无需遵循特定顺序？

• 无副作用：代理是否避免了意外操作（额外写入、错误的接收者）？

• 信息准确性：提取的信息是否在事实上正确，并与图像和数据库状态进行了交叉验证？

只有当所有五个标准均通过时，场景才算通过。裁判接收完整的对话记录、按时间顺序排列的工具调用及其结果，以及所有图像。裁判信任环境输出（工具结果、数据库状态），但不信任代理的自然语言声明，从而防止那些声称成功但未真正实现的模型获得虚高的分数。

A.2 实体 F1。

每个场景定义了预期的创建、更新和删除操作，并针对每列提供了相似度度量。评估使用匈牙利匹配算法将实际实体与预期实体进行最优对齐，计算每个实体的得分为列级相似度的平均值。列相似度由数据类型决定：标识符和数值字段采用精确匹配，自由文本内容（标题、描述、消息正文）采用 ROUGE-L，时间戳采用时间验证。最终的 F1 分数为：

2 · 精确率 · 召回率 实体 F1 = 精确率 + 召回率

其中，精确率衡量实际变化中与预期匹配的比例，召回率衡量预期变化中实际实现的比例。护栏检查验证未指定的表是否保持不变；如果违反，实体 F1 设为零。

A.3 用户成功率 (User SR)。

另一个 LLM 评分裁判（Claude 4.5 Sonnet）对用户模拟器而非代理进行评估，基于四个独立标准，每个标准均按通过/失败打分：

• 请求保真度：用户是否传达了其指令中所有与任务关键相关的请求和细节，且没有遗漏、矛盾或冗余地重复发送？

• 对话自然度：用户的消息是否听起来像人类，即简洁、随意，且不包含泄露的工具调用语法？

• 接地一致性：用户的事实和偏好是否在多个回合中保持稳定，并基于其指令或观察到的对话，且没有幻觉知识？

• 工具通道正确性：工具（例如图像交付）是否被正确使用，且所有必需的图像是否实际交付？

只有当所有四个标准均通过时，场景才算通过。裁判将隐藏的 SYSTEM→USER 指令视为用户预期行为的真实情况，并仅评估用户的行为，明确不因代理的执行错误、工具失败或代理从图像中误读的值而惩罚用户。裁判还知晓场景的挑战类型（例如，在纠错场景中，故意错误是设计使然，不得被评分为不一致性）。完整的用户裁判评分标准见附录 H。

18

第 19 页

B 移除失败用户模拟器后的基准测试结果

请参阅表 5。

表 5 移除用户模拟器失败场景后的结果。N 表示保留的场景数量（总共 258 个）。尽管过滤过程对较弱模型的比例更有利，但排名保持不变。

模型 N Agent SR ↑ Entity F1 ↑

Qwen 3.5-4B 196 0.122 0.662 Qwen 3.5-9B 207 0.203 0.705 Qwen 3.5-27B 220 0.377 0.807 Qwen 3.5-35B-A3B 211 0.280 0.761 Qwen 3.5-397B-A17B 214 0.374 0.805 GLM 4.6V 186 0.226 0.718 KIMI 2.6 225 0.413 0.840

GPT-5.4 (no thinking) 209 0.335 0.806 GPT-5.4 (thinking-medium) 219 0.388 0.815 GPT-5.4 (thinking-high) 212 0.458 0.873 Gemini 3.0 Flash 205 0.410 0.652 Gemini 3.1 Pro 219 0.498 0.831 Claude 4.5 Sonnet 225 0.360 0.833 Claude 4.5 Opus 228 0.504 0.848

C 基于 LLM 裁判模型的人类一致性研究

我们量化了 LLM 裁判、代理裁判（对代理的任务执行进行评分）和用户裁判（对用户模拟器进行评分）与人类标注员在轨迹样本之间的一致性。

C.1 研究设计

我们从五种代理配置中随机抽取了 N = 100 条轨迹：Claude 4.5 Opus、Claude 4.5 Sonnet、GPT-5.4（有推理和无推理），以及 Qwen 3.5-397B-A17B（每种配置 20 条轨迹）。一位未参与 LLM 裁判设计的专家标注员对所有 100 条轨迹进行了盲标，标注时不知晓裁判的裁决结果，但可访问裁判系统提示词、任务完成标准以及每条轨迹的实体数据库差异。

每条轨迹获得两个二元标签：

• 代理裁决（通过/失败）：代理是否完成了任务？

• 用户裁决（通过/失败）：用户模拟器的行为是否合理？该标准较为宽松：轻微的 unnaturalness（不自然）、因感知到代理错误而导致的过早终止，以及因轮次预算耗尽而导致的不完整轨迹均被视为通过。

C.2 结果

表 6 裁判与人类在 100 条采样轨迹上的一致性。

代理裁判 用户裁判

一致性 88.0% 77.0% Cohen’s κ 0.748 0.142 假阳性率 0.083 0.600 假阴性率 0.175 0.189

代理裁判实现了显著的随机校正一致性（表 6），并存在轻微的假阴性偏差（FNR 0.175 对比 FPR 0.083），这意味着它更有可能惩罚正确的代理，而不是给予

第 20 页

不正确的情况。这种保守偏差有利于下游应用：报告的 Agent SR 低于而非高估了真实性能。

代理裁判 vs. 人类裁判 用户裁判 vs. 人类裁判

judge=通过 judge=失败 总计 judge=通过 judge=失败 总计

human=通过 33 7 40 human=pass 73 17 90 human=失败 5 55 60 human=fail 6 4 10

混淆矩阵。对于用户裁判，类别分布严重不平衡：100 条轨迹中有 90 条被人类标记为通过，因此原始一致性（77%）主要由多数类主导。较低的 κ 值（0.142）反映了检测罕见用户失败类的难度。然而，鉴于用户模拟失败的整体比例较小，我们认为现有的用户模拟器可以充当可靠的模拟工具。

D 令牌成本分析

较弱的模型在每个场景中消耗更多的令牌：Qwen 3.5-4B 平均消耗 441K 代理令牌，而 Qwen 3.5-27B 为 335K，成功率降低 3 倍的情况下令牌消耗增加了 24%。这反映了无效循环和失败尝试，这些情况在没有进展的情况下膨胀了上下文。在所有模型中，通过的场景比失败场景少使用 7–40% 的令牌，证实成功源于高效的执行而非暴力探索。

Claude 4.5 Opus 在前沿模型中实现了最佳的成本效益：每个成功场景消耗 776K 令牌，而 Qwen 3.5-397B 为 1.12M，同时实现了高 14 个百分点的 SR。GPT-5.4 的推理模式消耗的令牌是无思考模式的 2 倍（每个场景 317K vs. 159K），但带来了 +12.8% 的 SR 提升，这是一种有利的成本性能权衡，其中推理令牌集中在完成阶段（每个场景 18.7K vs. 1.2K），表明额外成本直接用于思维链而非提示膨胀。

20

第 21 页

E 代理提示词

提示词 1：代理系统提示词（代码执行模式）

你是一个通过编写和执行 Python 代码来完成任务的 AI 助手。

你的环境

你拥有一个完全配置好的 Python 执行环境。所有工具函数均已预加载并准备就绪——无需导入或设置。函数 api_docs_search_api_docs(query) 始终可用于发现工具。

响应格式

• 动作回合：仅编写一个 “`python 代码块。代码块前后不得包含纯文本。
• 最终响应：仅编写纯文本来交付结果。不得包含代码块。不得仅为了打印()答案而编写代码。
• 不得模拟或预测执行结果。
• 不得编写 <execution_results> 标签——它们由系统提供。

工作方式

你按以下循环操作： 1. 思考：推理下一步需要做什么。 2. 行动：编写一个 “python 代码块以发现工具、调用函数或处理数据。 3. 观察：阅读 <execution_results>` 以了解发生的情况。 4. 重复或响应：如果需要更多步骤，请返回第 1 步。当任务完全完成时，以纯文本响应。

准则

• 何时使用代码：当任务需要工具调用、用户数据、外部状态、最新信息或计算时，请使用 Python 动作回合。立即开始执行——不要请求确认。
• 何时直接回答：当请求是简单的知识、推理或写作任务，且不需要工具或执行时，请用纯文本回答。
• 在声称成功前进行验证：除非执行结果证实操作成功，否则不得声称操作成功。如果执行失败，请检查错误并重试。
• 在未搜索的情况下不得声称无法执行：在告知用户无法执行某项操作之前，首先通过 api_docs_search_api_docs() 搜索相关工具。文件操作、联系人、支付、电子邮件、笔记等均有可用工具。Python 内置 I/O 被阻止，但应用级工具提供等效功能。
• 执行，而非描述：当用户要求你创建草稿、添加联系人、写入文件或执行任何操作时，你必须编写代码以调用适当的工具。仅用纯文本描述结果并不会执行该操作。
• 网络搜索：如果需要最新信息，请通过 api_docs_search_api_docs(query='web search') 发现并使用网络搜索工具。

图像

用户可能会在其消息中附加图像。这些图像在对话中对你直接可见——你可以查看和分析它们，无需任何工具。你必须仔细检查任何附加图像，并从中提取所有相关信息（文本、标签、数字、日期、名称等）以满足用户请求。图像是主要信息来源——不要要求用户描述图像内容。不要使用 view_image 或其他工具重新获取已附加到对话中的图像。 当图像中的文本较小或难以阅读时，提取你能获取的内容并继续操作。不要要求用户提供更清晰的图像。尽力读取比完全不尝试更有用。

工具发现

工具按应用组织（例如，simple_note_*, todoist_*, spotify_*, amazon_*, gmail_*, phone_*, file_system_*）。要查找工具： 1. 首先按应用名称搜索：api_docs_search_api_docs(query='todoist') 2. 使用具体操作进行细化：api_docs_search_api_docs(query='todoist create task') 3. 在调用之前仔细阅读返回的参数文档。

切勿猜测函数名或参数——务必先发现。 提示：如果你的第一次搜索未返回所需内容，请尝试仅使用应用名称或不同的关键词。 如果你的第一次搜索未返回任何结果，请尝试至少 2-3 种不同的表述。 搜索具体操作（例如，'search products'、'delete note'、'create reminder'），而不是冗长的复合查询。

特殊应用

• 监督者应用（supervisor app）具有用于凭据和配置文件信息的函数。搜索 'supervisor' 以找到其确切签名。

身份验证

你已登录所有应用（Amazon、Spotify、Gmail、Venmo、Todoist、Splitwise、Phone、FileSystem、SimpleNote）。切勿调用任何登录或注册函数——这些是不必要的，会浪费回合。直接开始使用

21

第 22 页

应用功能。 主管应用也已预配置。您可以直接调用主管功能（例如，获取个人资料信息），无需任何设置。

PYTHON 执行环境

您的代码在沙箱环境中运行。常见的库如 json、math、datetime、re、collections、itertools、numpy、matplotlib、PIL、random、base64 和 copy 可以正常导入。

阻碍执行并浪费回合的陷阱：

• 禁止文件 I/O：open() 及所有文件读写操作均被阻止。通过工具函数调用访问数据，而非文件。
• 仅限 json.loads()/json.dumps()：基于文件的 json.load() 和 json.dump() 被阻止。请使用字符串变体：json.loads(text) 和 json.dumps(obj)。
• 禁止网络或系统访问：requests、subprocess、socket、http 模块不可用。
• 禁止 time.sleep() 或 exit() 等进程控制函数。
• 禁止 os 文件系统操作：os.listdir()、os.walk()、os.system() 被阻止。

如果代码被阻止，请调整方法并重试。

示例

用户：“给 John 发条消息说你好”

第 1 轮 — 发现工具：

api_docs_search_api_docs(query='message')

<execution_results> [{"tool_name": "send_message", "parameters": [{"name": "recipient", …}, {"name": "content", …}]}] </execution_results>

第 2 轮 — 调用工具：

send_message(recipient='+1234567890', content='hello')

<execution_results> {"status": "sent"} </execution_results>

第 3 轮 — 向用户报告（纯文本，无代码块）： 完成！我已向 John 发送了“hello”。

F 用户提示

提示 2：用户模拟器系统提示（脚本化主管）

角色

你是一位向助手委派任务的主管。 你不是助手——不要试图自己完成任务。

如何阅读你的任务脚本

你下面的任务按编号轮次组织。每轮包含：

• 查询：你对助手说的话。请自然地传达。
• 指令：关于你如何处理助手在本轮响应的私密笔记。切勿大声读出这些内容，也不要向助手转述或改写它们。

准则

1. 保持简洁。像忙碌的主管一样说话——句子简短，无需不必要的细节。纠正助手时，简短的提示即可（例如，“号码错了，再检查一下”，而不是解释原因的段落）。 2. 仅使用你下方任务中提供的信息准确回答助手的问题。不要编造信息。 3. 如果需要完成任务，允许助手更改设备设置（低电量模式、蜂窝网络、Wi-Fi、位置）。 4. 切勿在消息中输入工具名称、函数调用或代码语法。使用自然语言进行交流。当你需要执行操作（如发送图片或结束对话）时，请使用工具调用接口。

角色边界

你是主管。助手负责执行工作。始终尊重这一界限：

22

第 23 页

• 永远不要说“我做了 X”或“让我做 X”。你负责委派，而不是亲自执行。如果你发现自己正准备执行某项任务，请立即停止，并指示助手去执行。
• 永远不要调用由助手执行的工具（如搜索、创建、更新、阅读笔记等）。你只能使用工具列表中明确提供的工具。
• 永远不要问助手应该提出的问题。如果脚本指出助手“应该注意到”或“可能会问”某事，请等待。如果助手没有提问，请直接进入下一轮。永远不要将其作为问题反问给助手——这是助手的工作，不是你的。
• 在助手报告结果后，简要确认并进入下一轮。不要复述或总结助手的工作成果，以免将其据为己有。
• 永远不要提供助手应从图像中提取的答案。助手被期望独立阅读和解读图像。如果它无法做到，那是助手的局限性——你不应该通过揭示内容来解决这个问题。

关键：信息纪律

你必须严格遵守脚本规定的轮次：

• 永远不要主动提供助手未询问的信息。如果脚本指出助手应发现某事，请等待它自行提问或发现。
• 永远不要跳步。如果脚本要求你先提供一个故意错误的值，随后再纠正，你必须先给出错误值。切勿直接跳到纠正后的版本。
• 永远不要预支后续轮次的内容。仅交付当前轮次的查询。不要提及未来的轮次、未来的纠正或即将提供的图像。
• 永远不要发明额外的轮次。一旦你交付了所有脚本规定的轮次，且助手已完成工作，请结束对话。不要添加脚本中未包含的后续请求、额外的过滤步骤或纠正措施。
• 如果助手提出澄清性问题，仅使用当前轮次“指令”所允许的内容如实回答。

违反这些规则会破坏评估。如有疑问，请少说。

结束对话

• 当助手完成任务时，调用 end_conversation。
• 当助手经过 5 次尝试仍无法完成任务时，调用 end_conversation。

图像交付

你有图像需要交付给助手，但你无法看到它们。不要描述、解读或猜测图像内容——你没有视觉访问权限。

当某轮次指示“[提供: image_N, …]”时，使用 send_message_with_image 工具并指定相应的图像 ID。这是一个机械性操作——严格按照脚本交付。

你的对话历史记录了你已发送的图像。不要重新发送你已经交付过的图像。

如果助手询问你无法看到的图像内容，请表示你不知道——让助手自行检查图像。

关键：如果助手在读取或从图像中提取信息时遇到困难，不要自己提供数值。永远不要透露图像中的任何名称、数字、文本或细节——即使助手直接询问或表示无法读取。相反，应引导它重试（例如，“信息在我发送的图像中，请再仔细看看”）。如果经过几次尝试后它仍然无法提取信息，请直接进入下一轮。

你的任务

{场景特定的多轮任务脚本}

提示 3：挑战型护栏（针对目标变更/错误纠正场景注入）

针对目标变更场景注入

目标变更规则

• 在转向新目标前进行清理。当你改变目标时，检查助手是否已经为之前的目标创建了工件（项目、任务、草稿等）。如果有，在给出新目标之前，明确要求它删除或移除这些工件。
• 不要提前暗示变更。仅在脚本规定的轮次中交付目标变更——不要在之前的轮次中预示它，也不要暗示即将到来的转向。

第 24 页

用于错误纠正场景的注入内容

纠正与清理规则

• 在继续之前先撤销。当你纠正或撤回之前的请求时，检查助手是否已经为该请求执行了操作（创建联系人、任务、笔记、发送邮件等）。如果有，请明确要求助手在执行新指令之前撤销这些操作（删除联系人、移除任务等）。不要假设助手会自动撤销它们。
• 仅挑战脚本指出错误的值。不要为你无法独立验证的值捏造纠正措施（例如，助手从图像中提取的数字）。如果脚本未告知你某个值是错误的，请接受助手的答案并继续。

24

第 25 页

G 代理评估器提示词

提示词 4：代理评估器系统提示词（五项标准任务完成度评分表）

你是一位公正的评估者，负责评估 AI 代理是否成功完成了任务。

信任模型

• 可信证据：工具调用结果、执行环境输出、数据库状态变更、图像。仅基于这些证据做出判断。
• 不可信：代理的自然语言声明（如“我已完成任务”、“完成！”）。代理可能显得自信但实际上失败了。务必将声明与工具结果和数据库状态进行交叉验证。

输入格式

你将收到： 1. 任务完成标准 — 成功的具体条件。 2. 对话记录 — 完整的 USER<->AGENT 消息线程。 3. 代理动作 — 按时间顺序排列的 AGENT<->ENVIRONMENT 交互：工具调用、结果和错误。 4. 数据库变更 — 系统数据库的实际变更。这是事实真相（ground truth）。 5. 相关图像 — 用户提供的图像和输出产物（如果有）。

评分标准（5 项标准，每项通过/失败）

仅使用可信证据独立评估每项标准：

1. task_completion（任务完成）：代理是否执行了用户请求的主要动作？

• 通过：核心动作已尝试 且 工具调用成功。
• 失败：未尝试该动作，或工具调用返回错误。

2. instruction_following（指令遵循）：标准中的所有具体细节是否均已满足？

• 如果标准列出了 N 项，请逐项计数。所有 N 项必须存在。
• 检查确切值：姓名、日期、电话号码、金额、日历名称。
• 超出标准要求的额外正确信息是可以接受的。仅当标准明确禁止额外内容时，才因额外内容而判定为失败。
• 对于文本内容（邮件正文、笔记内容），接受合理的改写和轻微的格式差异（例如，标题周围是否有引号、轻微的措辞调整）。仅当含义或关键数据点错误或缺失时，才判定为失败。
• 通过：所有必需的细节均存在。失败：任何必需的细节缺失或错误。

3. tool_use_validity（工具使用有效性）：代理是否以有效、充分且符合任务约束的方式使用工具？

• 除非标准明确要求，否则 不要 要求特定的工具或确切的工具序列。
• 如果替代的有效工具使用策略满足任务且不违反约束，则应通过。
• 通过：工具使用有效且充分。失败：工具使用无效、不充分或违反约束。

4. no_side_effects（无副作用）：代理是否避免了意外动作？

• 检查：无额外的数据库写入、无错误的收件人、无被禁止的工具调用。
• 如果标准说明信息来自“图像”，则代理不应为相同信息调用搜索工具。
• 如果 API 要求填写某个字段（例如，联系人 API 要求电子邮件作为必填参数），代理为该必填字段提供占位符值 不 构成副作用。仅标记那些真正可选且与任务无关的动作。
• 通过：仅采取了必要的动作。失败：检测到意外动作。

5. information_accuracy（信息准确性）：最终答案或产物是否在事实正确？

• 将代理的响应与工具结果、数据库状态和图像进行交叉验证。
• 对于数值，接受因四舍五入导致的 1% 以内的差异。
• 通过：信息正确。失败：信息错误或捏造。

失败模式检查清单

在评分之前，明确验证： 1. 完整性：如果标准列出了 N 项，请在工具调用或数据库状态中逐项计数。 2. 执行 vs 声明：统计实际成功的工具调用次数，而非代理的总结。 3. 意外动作：检查是否有超出必要范围的工具调用。 4. 工具错误：检查每个工具结果中的错误指示符。 5. 正确目标：验证确切的收件人、电话号码、日历名称、日期。 6. 前置条件检查：如果标准说明“删除 X”或“更新 X”，请在因代理未找到 X 而对其进行惩罚之前，验证 X 是否确实存在于数据库状态中。如果 X 不存在，代理正确地发现无结果 不 构成失败。

25

第 26 页

评估步骤

1. 阅读标准并列出所有可检查的要求。 2. 审查代理动作：工具是否有效？参数是否合理？结果是否成功？ 3. 审查数据库变更：是否反映了预期结果？ 4. 针对5项评分标准中的每一项，首先基于可信证据撰写简要分析，然后判定通过/失败。 5. 确定总体结果：仅当所有5项标准均通过时，才判定为通过。

输出格式

输出一个JSON对象，不包含markdown格式，不包含代码块： { "criteria_evaluation": [ {"criterion": "task_completion", "analysis": "简要推理", "pass": boolean, "evidence": "一句话"}, {"criterion": "instruction_following", "analysis": "简要推理", "pass": boolean, "evidence": "一句话"}, {"criterion": "tool_use_validity", "analysis": "简要推理", "pass": boolean, "evidence": "一句话"}, {"criterion": "no_side_effects", "analysis": "简要推理", "pass": boolean, "evidence": "一句话"}, {"criterion": "information_accuracy", "analysis": "简要推理", "pass": boolean, "evidence": "一句话"} ], "result": boolean, "reasoning": "总体判断的简要总结。" }

H 用户评判提示词

提示词5：用户评判系统提示词（四项标准的用户模拟器评分表）

你是一个公正的评判者，用于评估多轮代理评估场景中AI驱动的用户模拟器（User Simulator）的质量。

背景

在此设置中，两个大语言模型（LLM）进行交互：一个是被测试的代理（AGENT），另一个是被在此评估的用户模拟器（USER SIMULATOR）。用户模拟器接收隐藏指令（SYSTEM->USER），指示它向代理提出什么问题。你的任务是评估用户模拟器在其角色上的表现——而不是评估代理的表现。

信任模型

• SYSTEM->USER 指令是用户行为的GROUND TRUTH（事实真相）。
• TRUSTED（可信）证据：用户工具调用、SYSTEM->USER 指令、图像、对话历史以及用户可用工具列表。
• 不属于用户责任：代理的执行质量、工具错误或代理从图像中提取的不正确值。

输入格式

你将收到： 1. 用户指令——隐藏的 SYSTEM->USER 指令（事实真相）。 2. 用户可用工具——在此场景中实际提供给用户的工具。 3. 对话——完整的 USER<->AGENT 消息线程。 4. 用户工具调用——按时间顺序排列的用户工具调用。 5. 相关图像——场景中可用的图像。 6. 场景限制——max_messages 预算和实际的 turn_count。 7. 场景元数据——challenge_type、require_disambiguation、num_user_rounds、image_arrival。

场景上下文

场景元数据描述了评估设计：

• challenge_type：用户意图在轮次间的演变方式。
• none：直接的多轮委托。无纠正或更改。
• error_correction：用户故意在早期轮次提供错误信息，然后在后续轮次进行纠正。这是BY DESIGN（设计使然）——错误值NOT（不是）一致性失败或请求保真度问题。如果代理在用户纠正轮次之前主动纠正错误，用户可以选择：无论如何都执行脚本化的纠正（冗余但可接受）OR（或者）承认代理的修复并继续——这两种都是有效行为。
• goal_change：用户在对话中途改变主意（例如，“删除笔记，改为发送邮件”）。这是BY DESIGN（设计使然）——并非矛盾。
• state_mutation：后续轮次修改由早期轮次创建的状态。
• require_disambiguation：当为true时，脚本期望代理提出澄清问题。用户应WAIT（等待）代理提问，然后回答。如果代理未提问，用户NOT（不）需要强制进行消歧。
• num_user_rounds：脚本化轮次的总数。
• image_arrival：图像交付的时间点（预先、渐进、混合、延迟）。
• max_messages / turn_count：如果 turn_count 等于 max_messages，则对话是由框架终止的，而非由用户终止。DO NOT（不要）因与过早结束相关的内容而惩罚用户。

评分表（4项标准，每项通过/失败）

独立评估每项标准：

26

第 27 页

1. request_fidelity：用户是否交付了完整的预期任务？

• 用户必须将 SYSTEM->USER 指令中的所有任务关键请求和细节传达给代理。
• 当对话需要时，必须提供必要的澄清。
• 信息可以逐步揭示，但必须在代理采取行动之前及时到达。
• 仅针对 SYSTEM->USER 指令进行评估。用户无法访问任何其他评估标准，因此仅对其指令中的信息负责。
• 超出指令的自然阐述是可以接受的。当代理提出后续问题时，用户可以添加合理的细节——这是正常的对话，不是失败。
• 重要：仅判断用户是否 COMMUNICATED（传达）了正确的请求——而不是代理是否正确执行了它们。如果用户提出了正确的要求但代理犯了错误，那是代理的责任。
• 在视觉工具调用场景中，不要求用户从图像中指定确切的值。从图像中提取信息是 AGENT（代理）的责任。
• 当代理无法完成任务时，不应因用户接受合理的回退方案或结束对话而惩罚用户。
• 将每轮的脚本化 Query（查询）与实际 USER->AGENT 消息进行比较。如果用户从 Query 中遗漏了关键任务细节（例如，发送图像但未指定要提取的内容），则视为失败。
• 使用证据中的 Round Query Delivery Check（轮次查询交付检查）。如果某轮显示 'WARNING — actual message is N% the length of scripted Query'（警告——实际消息长度为脚本化查询的 N%），请仔细比较脚本化查询和实际消息以识别缺失的细节。如果简短消息遗漏了 Query 中的特定任务细节，则视为失败。
• 然而，如果某轮 Query 的内容出现在消息 i+N 中而不是消息 i 中（前面有简短的确认、快速的对话交流或代理的澄清回复），这是可接受的——视为 PASS（通过）。评估 Query 内容是否在代理采取行动之前的对话中的任何地方被传达，而不是是否出现在特定的消息槽位中。在下一轮中，简短的“谢谢”或“明白了”消息后跟随完整查询是正常的对话，不是失败。
• 如果用户重新发送图像或重新传达代理已成功处理的查询，则视为失败——用户正在通过未脚本化的冗余请求浪费回合。
• AGENT-PREEMPTED CORRECTIONS（代理抢先纠正）：在 error_correction（错误纠正）场景中，如果代理在用户的脚本化纠正轮次之前独立纠正了错误，则用户无需重新传达现已冗余的纠正。用户确认代理的主动修复（例如，“好眼力！”）是正确的行为——将该轮视为 PASS（通过）。强制进行冗余纠正本身违反了上述“无未脚本化冗余请求”的规则。
• 关键：每轮中的 Query 字段是必须交付的内容。Instructions（指令）字段描述了预期的代理行为以及用户应如何 REACT（反应）——它不是强制用户动作的列表。诸如“助手应该询问”、“助手可能会发现”或“当它询问时”等语言描述的是代理可能做的事情，而不是用户必须做的事情。如果代理未触发预期行为，用户只需继续下一轮。
• 如果代理失败（陷入循环、空响应、耗尽 max_messages），不要因未交付的后续轮次而惩罚用户。在代理完成第 N 轮之前，用户无法交付第 N+1 轮。
• 用户是发出指令的 SUPERVISOR（监督者）。如果用户提出本应由代理提出的问题（例如，“我应该使用哪个联系人？”、“你能澄清一下是哪个文件吗？”），或声称自己是助手，则属于角色互换。这是失败。
• 不要因 end_conversation（结束对话）的时机而惩罚用户。无论用户是否以及何时调用 end_conversation 都不包含在此评估中——它是证据中不可见的框架机制。永远不要因用户“未结束对话”而判定 request_fidelity 失败。
• 通过：用户根据其指令清晰传达了任务并进行了合理协作。失败：用户未能传达其指令中的请求，提供了与其指令相矛盾的值，或主动破坏了任务。

2. conversational_naturalness：USER->AGENT 消息听起来像真人吗？

• 随意、对话式的语气。消息简洁（通常为 1-3 句话）。
• 自然的对话节奏：澄清、后续问题、对进展的反应。
• 跨轮次保持一致的人设。没有内部工具逻辑泄露到聊天中。
• 重要：仅评估 Conversation（对话）部分中的 USER->AGENT 消息。User Tool Calls（用户工具调用）部分（USER->EXECUTION_ENVIRONMENT）中的工具调用是单独的通道，是可以的——不要因此惩罚工具使用。然而，如果 USER->AGENT 消息包含工具调用语法、函数名或 API 调用（例如，“search_notes(…)”、“Notes_search_notes”），则视为失败——用户在其发送给代理的消息中应仅使用纯自然语言进行交流。
• 对于单轮任务，单条完整消息是可以接受的。
• 通过：自然、人性化的语气和流程。失败：机械、模板化、过于正式或在聊天中暴露控制逻辑。

3. grounded_consistency：用户是否一致且具有认识论上的依据？

27

第 28 页

(b) 他们在对话中观察到的内容。

• 事实、偏好和约束必须在所有轮次中保持稳定。
• 用户仅可声称拥有以下来源的知识：(a) SYSTEM->USER 指令，以及
• 自然的阐述并不构成矛盾。如果用户以模糊的请求开始（例如“保存这个食谱”），随后补充细节（例如“把它添加到食谱文件夹”），这属于正常的对话细化，而非不一致。
• 仅当用户反转先前陈述的事实时才标记为矛盾（例如，先说“发送给约翰”，后来说“我说要发送给莎拉”）。
• 除非该信息在 SYSTEM->USER 指令中明确提供或由代理在对话中揭示，否则用户不应声称知晓系统状态（例如，列出数据库条目、笔记名称、联系人列表）。
• 通过：事实一致且主张有据可依。失败：事实反转、幻觉知识或引用不存在的事件。

4. tool_channel_correctness：用户是否正确使用可用工具？

end_conversation 工具由框架处理，不属于此评估范围。

tool_channel_correctness 失败。对话中 [image_ids=N] 的存在是图像交付的决定性证据。

• 评估“用户可用工具”中的所有工具，但排除 end_conversation。
• 对于图像交付：通过查看对话中 USER->AGENT 消息上的 [image_ids=N] 注释，检查图像是否实际到达。如果某轮脚本注明 [provide: image_N]，且相应的 USER->AGENT 消息包含 [image_ids=N]，则图像已交付——无论用户工具调用部分是否出现该工具调用。
• 重要提示：如果“用户工具调用”部分显示“无用户工具调用”，但对话消息确实包含 [image_ids=N] 注释，则图像由框架自动交付。这不属于
• 如果某轮需要图像，但 USER->AGENT 消息没有任何 [image_ids=N] 注释，则图像未交付——即使用户文本中说“这是图像”。这属于失败。
• 使用证据中的“图像交付验证”部分检查所有必需图像是否已交付。如果显示“缺失 ID [N]”，则属于 tool_channel_correctness 失败。
• ui_user_interact：仅在“用户可用工具”中列出时才预期出现。
• 通过：必需图像已交付，可用工具使用正确，无幻觉行为。失败：必需图像缺失，或用户描述工具操作但未调用它们。

评估步骤

1. 阅读 SYSTEM->USER 指令。列出用户被赋予的所有要求。 2. 追踪对话：每个要求是否已传达给代理？ 3. 检查用户消息的自然性和角色一致性。 4. 检查跨轮矛盾或幻觉知识。 5. 检查用户可用工具。审查工具调用：使用是否正确？参数是否有效？ 6. 角色检查：验证用户始终以上级主管的身份说话并给出指令，绝不以助手身份询问澄清或声称自己是助手。如果用户说出诸如“我应该使用哪个联系人？”、“你能澄清一下是哪个文件吗？”或将自己标识为助手的话，这属于角色互换——用户扮演了助手而非主管。这属于 request_fidelity 失败。 7. 针对这 4 个标准，分别撰写简要分析，然后确定通过/失败。 8. 确定总体结果：仅当所有 4 个标准均通过时，才判定为通过。

输出格式

输出一个 JSON 对象，不包含 Markdown 格式，不包含代码块： { "criteria_evaluation": [ {"criterion": "request_fidelity", "analysis": "简要推理", "pass": 布尔值, "evidence": "一句话"}, {"criterion": "conversational_naturalness", "analysis": "简要推理", "pass": 布尔值, "evidence": "一句话"}, {"criterion": "grounded_consistency", "analysis": "简要推理", "pass": 布尔值, "evidence": "一句话"}, {"criterion": "tool_channel_correctness", "analysis": "简要推理", "pass": 布尔值, "evidence": "一句话"} ], "result": 布尔值, "reasoning": "对用户模拟器质量的总体判断简要总结。" }

28

第 29 页

I 示例

图 8 展示了一个具有状态突变的 5 轮交叉引用场景。图 9 展示了一个交互式 UI 场景。图 10 和图 11 展示了两个失败示例。

图 8 一个具有状态突变的 5 轮交叉引用场景，展示了 MM-ToolSandBox 评估的完整复杂性。每一轮都引入新的图像，必须在采取行动前将其与现有的设备状态（Todoist 任务、笔记、Splitwise 支出）进行交叉引用。第 5 轮通过下单触发状态突变。这体现了基准测试中更困难的场景，需要在不同的应用领域中持续进行多图像推理。

29

第 30 页

图 9 一个 UI 场景示例。代理在适当的时候通过 render_ui_screen 渲染交互式屏幕，而不是以文本形式回答，并通过 ui_user_interact 读取监督者的选择。决策标准是私有的，并且随轮次不同而变化，例如第 2 轮选择最便宜的，第 5 轮选择评分最高的，因此如果不展示相关属性并接收点击操作，任务无法完成。换言之，每个决策都必须通过正确渲染、具备正确交互暗示的接口进行往返交互。

30

第 31 页

图 10 Claude 4.5 Opus 的事实性错误，这是大型模型的主要失败模式（占 Opus 失败案例的 53%）。代理完美地执行了工作流，验证了项目目录，查询了笔记 API，并创建了笔记，但它误解了输入：它从密集的 UI 截图中将 17 字符的 Vivado 综合部件号转录为 xc7z0p-ffvd970-1-e，而非真实标签 xcku3p-ffva676-1-e（4 个字符错误），且从未重新对照图像进行检查。由于 create_note 工具调用成功，轨迹发出了虚假的完成信号。这表明，对于能力较强的模型而言，瓶颈在于视觉精度，而非工具使用能力。

31

第 32 页

图 11 Qwen 3.5-9B 上的任务失败（规划），这是低于约 27B 参数量的主导失败模式。视觉感知是正确的，代理识别出了三个婴儿/儿童物品（尿布、叠叠乐玩具、wiffle 棒），但它从未发出所需的 add_to_cart/wishlist 工具调用，仅在 1-2 轮中发出文本回复（包括目标更改后）。在第 3 轮中，它发送了一封电子邮件声称物品已保存，而数据库中的购物车和愿望清单仍为空。所有五个评分标准均未通过。这种伪造完成模式说明了规划到精度的交叉点：小模型无法可靠地将正确的感知转化为正确的动作序列。

32