\n
\n
\n
< img id="wx_img" src="https://www.qbitai.com/wp-content/uploads/imgs/qbitai-logo-1.png" width="400" height="400">
别光给Agent加Tool了，它根本选不明白！复旦×通义提出全新CUA训练范式
量子位 | 公众号 QbitAI
给Agent同时接上GUI操作和工具调用，准确率反而下降了。
模型根本不会在GUI和Tool之间选择。该点按钮的时候去调API，该调API的时候又死磕菜单，两头乱窜，越帮越忙。
通义实验室MobileAgent团队
，一个面向GUI-Tool混合动作空间的Computer Use Agent。
核心目标就一个：让模型学会什么时候走GUI，什么时候切Tool，什么时候不该调工具。
ToolCUA-8B在OSWorld-MCP上拿到
Claude-4-Sonnet
Claude-4.5-Sonnet
代码、模型权重已全面开源。
混合动作空间下的路径困惑
传统的CUA主要依赖原子化GUI操作，例如点击、输入、拖拽、滚动。这类操作泛化性强，只要界面上能看到按钮，理论上模型就能点；但它也有明显短板：步骤长、误差容易累积，在复杂任务中很容易出现cascading errors。
相反，tool calls或API-based operations往往更高效、更精确。例如在LibreOffice里批量处理表格，GUI-only方案可能需要一串冗长的菜单点击和参数配置，而工具调用可能一个API就能完成。
看起来最自然的方案，是让Agent同时拥有GUI和Tool。但实验发现一个非常反直觉的事实：
直接把tools接到强模型上，并不会自动提升性能。
在hybrid GUI-Tool action space中，Agent每一步都站在一个岔路口：左边是GUI，右边是Tool。GUI泛化强但慢，Tool快但依赖覆盖与上下文条件。如果模型缺少路径选择能力，就会出现两类典型失败:
Tool underuse
：明明有更高效的工具，模型仍然几乎只走GUI路线。
Tool overuse
：模型频繁调用工具，但调用时机不对、调用粒度不对，反而降低任务成功率。
optimal GUI-Tool path selection
：在长程任务中动态决定何时使用GUI actions、何时调用tools，从而形成更高效、更可靠的执行路径。
上图左侧的表格直接给出了这个反直觉现象：一旦把tools接到强模型上，结果并不总是更好。
Qwen3VL-8B几乎不使用工具，平均tool calls只有0.003，准确率从29.0%降到28.2%；Qwen3VL-235B则明显更倾向于调用工具，平均tool calls达到6.10，步骤数从25.9降到17.4，但准确率反而从41.1%降到38.1%。
Claude系列同样说明了这一点。
Claude-4-sonnet在加入工具后步骤数从23.6降到19.2，但准确率从47.7%降到43.5%；Claude-4.5-sonnet的步骤数从23.3降到19.1，但准确率从61.9%降到48.4%。
这说明，混合动作空间真正难的不是有没有工具，而是
模型在GUI和Tool之间会不会选路
第一阶段：数据合成与Tool-Bootstrapped RFT
要让模型学会GUI-Tool path selection，首先需要高质量的interleaved GUI-Tool trajectories。但现实中，这类数据非常稀缺。
真实工具接口往往应用相关、覆盖不完整，而且维护成本高；而收集真实GUI-Tool混合轨迹又需要复杂的环境接入和人工标注。
已有GUI数据虽然规模很大，但大多是GUI-only trajectories，只教模型如何点击和输入，并没有告诉模型何时应该用工具替代冗长GUI操作。
ToolCUA的第一步，就是把这些GUI-only数据盘活，并顺势完成第一阶段的hybrid bootstrapping。
Interleaved GUI-Tool Trajectory Scaling Pipeline
：从已有GUI轨迹出发，利用MLLM合成grounded tool library，再将GUI-only trajectories转换成interleaved GUI-Tool trajectories。
整个pipeline可以概括为三个步骤:
1、Trajectory-aware synthetic tool library construction。
对每条GUI轨迹，模型会分析任务目标、动作序列和截图描述，从真实操作流程中抽象出可调用的工具。