视觉智能体真正卡住的，不是会不会调用工具
一个用户发来几张商品照片，说：“帮我把前两样加入购物清单，顺便查一下它们网上卖多少钱。”
这听起来像一个普通的多模态任务。模型看图，识别香蕉和牛奶，然后调用购物、搜索、列表管理这些工具。只要模型会看图、会调用函数，事情似乎就结束了。
但真正的任务经常不是这样展开的。用户可能第二轮又补一张图，说“这个也不错”。第三轮又改主意：“不要第一个，换成海报右下角那个活动。”图片可能早在十几轮工具调用之前就发过；清单里可能已经有同名商品；用户还可能把图里的文字读错，让模型判断到底听用户的，还是相信视觉证据。
这时，“视觉工具调用”就不再是看图问答后面接一个 API。它要求模型把视觉证据变成可执行参数，把参数落到一个会被修改的状态环境里，还要在多轮对话中记住哪些视觉线索仍然有效。
Apple 这篇论文提出的 MM-ToolSandBox，抓住的正是这个缝隙。它不是再问模型“图里有什么”，而是问：当图里的信息必须驱动 511 个工具、16 个应用域、2–5 轮对话和真实状态变更时，今天的多模态智能体到底能不能把事情办完？
先把问题拆开：看见、决定、执行，不是一件事
我们可以先想一个最小例子。
用户发来一张餐厅海报，上面有日期、地点、价格和一个二维码。用户说：“帮我把这个活动加到日历里，再把地址发给 Alex。”如果这是普通 VQA，模型只要回答“活动在周五晚上七点”就够了。但在工具调用环境里，正确答案只是中间产物。
模型要先从图里抽出日期、时间、地点、活动名。然后决定要调用日历工具和联系人/消息工具。再把“周五晚上七点”解析成具体时间戳，把“Alex”解析成通讯录里的某个人，把地址填进消息正文。最后，评测不是看模型说得像不像，而是看日历状态和消息状态有没有真的按预期改变。
这里有三个容易混在一起的能力。
第一是视觉落地。模型必须知道图里哪个数字、哪个单词、哪个对象是任务相关证据。
第二是工具规划。模型要在大工具空间里找到合适工具，并按正确顺序调用。MM-ToolSandBox 默认暴露的是完整 511 工具注册表，但不是一次性塞进提示词，而是让智能体用 search_tool 按需检索工具，再用 LRU 维持工作集。
第三是状态执行。工具调用不是聊天里的装饰，它会创建、更新或删除实体。一个任务有没有完成，要看最终世界状态，而不是看模型有没有自信地说“我完成了”。
这就是这篇论文的核心设定：图像不是 prompt 里的静态附件，而是环境里的“一等视觉对象”。图片有稳定 ID，可以跨轮引用，可以被工具处理，也会出现在完整轨迹里接受评测。
这个评测难在哪里：不是手写 258 道题那么简单
MM-ToolSandBox 的 benchmark 最终有 258 个经人工验证的 nominal scenarios，外加 50 个交互式 UI 变体。每个场景需要 3–6 张图片、2–5 轮用户交互，覆盖 1,284 张独立图片。图片来源不是单一数据集，而是文档、自然场景文字、真实世界图片、图表、信息图、软件 UI 截图等八类视觉数据源。
这很重要。因为如果只用一种图像，模型可能是在“适配题型”；而这里的任务更接近真实助手：今天看发票，明天看海报，后天看截图，所有视觉证据都可能要变成工具参数。
论文把场景组织在三条轴上。
第一条是信息流类型。视觉输入如何变成动作？有的任务是 aggregate，把多张图的信息合并成一个动作；有的是 compare，在多个选项里选最好；有的是 filter，只挑符合条件的项；有的是 compute，需要从图里读数再计算；还有 validate、lookup chain、cross-reference。它们对应的不是“题目类别”，而是数据处理原语：union、argmax、where、derived column、check、correlated subquery、join。
第二条是对话挑战。标准任务之外，用户可能中途改目标，可能提供错误描述，任务可能要求修改或删除已有实体，而不是只创建新东西。
第三条是图片到达方式。图片可以 upfront 一开始全给，也可以 progressive 分轮给，也可以 late 到后面才出现，或者 mixed 混合出现。这个设计很聪明，因为它把“多图工作记忆”单独拉出来测：如果图在第一轮就出现，后面几十次工具调用之后还要回头引用，难度和图片刚刚出现完全不同。
场景不是纯手工写出来的。论文设计了六阶段生成管线：先从 10,466 张候选图片里判断哪些图像有可行动内容，留下 6,428 张；再按相关域和 CLIP 相似度聚成 3–6 张图片的组；再给每组评估哪些信息流和图片到达模式自然可行；随后生成多轮场景、实例化初始和最终实体状态，用 LLM critic 按七条质量标准过滤。
数字上，这条漏斗从 1,152 个生成场景，到 599 个通过 Stage 6 critic，再平衡采样 300 个，最后经过 oracle solvability check 和人工专家 review，留下 258 个。oracle 不是普通解题模型，而是拿到 expected tools、expected entity changes 和完成标准的 Claude 4.5 Opus；场景要同时满足 Entity F1 ≥ 0.9 和 Agent Judge 通过，才算可解。
这使得 benchmark 的主张更扎实：模型失败时，不太可能只是因为题目本身不可执行。
评测方式：为什么“说完成了”不算完成
MM-ToolSandBox 用两个层次评测。
第一个是状态验证。每个场景都有初始世界状态和期望最终状态。评测会比较实际的创建、更新、删除实体，使用 Hungarian matching 对齐实体，再按字段类型计算相似度：ID 和数值精确匹配，自由文本用 ROUGE-L，时间字段做 datetime verification。这个指标叫 Entity F1。
第二个是轨迹评审。Agent Judge 看完整对话、工具调用和图片，分别检查五件事：任务是否完成、是否遵循具体指令、工具使用是否有效、是否没有副作用、信息是否正确。只有五项全过，Agent Success Rate 才算通过。
这比只看最终数据库更严格。一个模型可能把最终状态大致改对了，但漏掉用户要求的细节；也可能动作流程正确，却把图片上的数字看错。论文还报告了人工一致性：Agent Judge 和人类标注在 100 条轨迹上的 agreement 是 88%，Cohen’s κ = 0.748，并且偏保守——更容易低估而不是高估 Agent SR。
为了避免“用户模拟器太差导致智能体被冤枉”，论文固定用 GPT-5.4 做用户 simulator，并单独用 User Judge 检查用户行为。去掉用户失败的场景后，模型排名保持不变；Agent SR 和 User SR 的相关系数 r = 0.81，说明用户质量问题没有改变主结论。
结果最刺眼的地方：最好模型也没到 50%
主实验评测了 12 个强多模态模型，从 4B 开源权重到 frontier proprietary systems。默认设置是 Code-Execution interface、完整 511 工具、最多 100 步，并对支持的模型开启 thinking。
结果很直接：没有一个模型 Agent SR 过半。
Claude 4.5 Opus 是最高的，Agent SR 48.8%，Entity F1 0.848。Gemini 3.1 Pro 是 48.1%，KIMI 2.6 和 GPT-5.4 thinking-high 都是 41.5%。GPT-5.4 thinking-high 的 Entity F1 达到 0.865，是表里最高，但 Agent SR 仍只有 41.5%。这说明最终状态部分正确不等于完整任务通过。
thinking 确实有帮助。GPT-5.4 从 no thinking 的 29.1% Agent SR，提升到 thinking-medium 的 36.1%，再到 thinking-high 的 41.5%；Entity F1 也从 0.794 提升到 0.865。模型规模也有帮助。Qwen 3.5 系列从 4B 的 11.6% 到 27B 的 34.9%，Agent SR 提升超过 23 个百分点。
但帮助不等于解决。评测把任务压到“能看、会想、会调工具、会维护状态”这个交叉点上，任何一环不稳都会让五项判定中的某一项失败。
情景分析也有两个有趣现象。
一是 upfront 图片最难。论文说，所有图片一开始就给，比 progressive 到达低了将近 20% success-rate gap。直觉上我们可能以为“一次性给全信息”更容易，但在长轨迹里恰好相反：后续工具调用和对话轮次会把早期图片挤进长期视觉记忆，模型需要在很久之后准确回指。
二是信息流类型差异很大。以 Claude 4.5 Opus 为例，lookup chain 这类更接近单图顺序检索的任务 Agent SR 约 0.739；filter 和 aggregate 这类需要多图综合的任务降到约 0.437 和 0.370。换句话说，当前模型更擅长“沿线索找下一个”，不擅长“同时拿住多张图并做集合操作”。
真正的失败故事：大模型不是不知道该做什么，而是看错了
论文最值得讲的不是排行榜，而是失败分析。
研究者把失败分成四类。Factual error：任务流程做对了，但从图片中抽错信息，比如看错对象、读错数字。Task failure：主流程没完成，找不到资源、漏步骤、陷入循环。Incomplete execution：事实和任务完成了，但漏了具体指令。Uncontrolled behavior：做了额外副作用。
在强模型上，最大类不是规划失败，而是 factual error。
Claude 4.5 Opus 的 132 个失败里，70 个是 factual error，占 53.0%；task failure 只有 31 个，占 23.5%。GPT-5.4 thinking 的失败里，factual error 占 50.3%。KIMI 2.6 是 49.0%。Qwen 3.5-397B-A17B 是 50.9%。
更细地看 Claude Opus 的 70 个 factual error，object misidentification 有 29 个，fine-grained text extraction error 有 16 个。也就是说，模型常常已经会走正确流程：它知道要查哪个工具、改哪个实体、问不问用户。但它把图里的对象或文字读错了。
这就是论文标题之外真正有价值的结论：对强模型来说，视觉工具调用的瓶颈不只是“工具调用能力”，而是“视觉精度”。
规模曲线让这个结论更清楚。Qwen 3.5-4B 时，task failure 占主导，约 51% 失败来自规划/执行问题。到 27B，task failure 降到 30%，factual error 升到 51%。再到 Opus，factual error 是 53%，task failure 只有 23%。
这像一个能力交叉点：小模型主要问题是“不知道该做什么”；大模型主要问题变成“知道该做什么，但看错了什么”。
这个区分很重要，因为它指向不同的改进路线。小模型可能需要更好的规划、工具检索、代码执行和长程控制。强模型则需要更可靠的 OCR、细粒度对象识别、多图引用、视觉证据绑定，甚至需要在执行前对关键视觉字段做校验，而不是单纯加更多 thinking token。
UI 模式：另一个还没打开的前线
论文还做了一个 50 场景的 UI subset。这里任务底层不变，但智能体不能只用文本和工具完成，而要动态渲染交互式界面，让用户通过按钮、选择等方式给出私人偏好。
结果更低。KIMI 2.6 在这个子集上 Agent SR 最高，也只有 26.0%；Claude 4.5 Opus 是 20.0%；Qwen 397B 是 10.0%；GPT-5.4 thinking 只有 2.0%。平均步数膨胀到 75–93 左右。论文判断，主要瓶颈是 UI rendering 本身：模型经常生成不了可用、具备正确 affordance 的界面，随后进入重试循环。
这部分目前更像探索性结果，但它提醒我们：如果未来智能体不只是调用 API，而是即时生成用户可操作界面，那么“会设计一个可交互状态机”会成为比文本工具调用更硬的一层能力。
这篇论文证明了什么，没有证明什么
这篇论文证明了几件事。
第一，在一个固定 harness、固定评测协议下，当前强多模态模型面对多图、多轮、大工具空间、状态变更任务时，Agent SR 仍低于 50%。这不是单轮 VQA 的难，而是视觉证据到工具执行链条的难。
第二，benchmark 的失败不是单纯由不可解题目或用户模拟器导致。论文用 oracle solvability、人类 review、User SR 控制和 judge-human agreement 做了多层质量约束。
第三，对强模型来说，主要失败模式已经从“不会规划”转向“视觉事实错误”。53% 这个数字不是泛泛而谈的“视觉还不够好”，而是来自失败根因分类：流程对了，图读错了。
但它没有证明所有视觉智能体都低于 50%。论文也诚实说了，所有模型都在同一个固定 harness 下跑；不同模型如果定制 scaffolding、工具检索策略、视觉校验模块，可能会有更高性能。因此这些数字更像“标准化设置下的模型能力比较”，不是每个模型的最优上限。
它也没有完全消除评测偏差。Agent Judge 用 Claude 4.5 Sonnet，oracle 过滤用 Claude 4.5 Opus，可能对 Claude 系模型有家族偏好；场景生成用 Gemini-3.1-Pro，也可能让任务结构带有生成模型偏置。人工验证降低了风险，但不能把偏差归零。主结果还是 single-run，没有正式置信区间；论文提到同设置下约 1.6 个百分点标准差，但未来需要更系统的方差分析。
所以，更准确的读法不是“Apple 证明了某某模型不行”。更有用的读法是：当我们把视觉输入放进真实代理工作流，很多看似已经解决的能力会重新暴露边界。模型可以会调用工具，可以会多轮对话，可以会看图；但把三者锁在一起，要求每个视觉字段都可靠地落到状态变更上，今天的系统仍然很脆。
这也是 MM-ToolSandBox 的价值。它把“视觉智能体”从演示视频里的流畅交互，拉回到一个可检查的问题：图像证据有没有被正确绑定？工具参数有没有来自真实视觉证据？状态有没有按预期改变？失败到底是规划错、执行漏，还是视觉精度不够？
下一代多模态 agent 的关键，可能不只是让模型更聪明地想，而是让它在行动之前更精确地看，并且知道自己看的哪一部分正在支撑哪一个工具参数。