复旦×通义团队投稿
量子位 | 公众号 QbitAI
给 Agent 同时接上 GUI 操作和工具调用，准确率反而下降了。
模型根本不会在 GUI 和 Tool 之间选择。该点按钮的时候去调 API，该调 API 的时候又死磕菜单，两头乱窜，越帮越忙。
为应对这一挑战，复旦大学和通义实验室 MobileAgent 团队联合提出 ToolCUA，一个面向 GUI-Tool 混合动作空间的 Computer Use Agent。
核心目标就一个：让模型学会什么时候走 GUI，什么时候切 Tool，什么时候不该调工具。
结果相当能打。
ToolCUA-8B 在 OSWorld-MCP 上拿到 46. 85% 准确率，超过 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 轨迹，模型会分析任务目标、动作序列和截图描述，从真实操作流程中抽象出可调用的工具。
例如从 Chrome 设置流程中抽象出 chrome_open_language_settings，从 LibreOffice 表格操作中抽象出读取工作簿信息、创建透视表等工具。
这些工具不是凭空生成的 API 模板，而是 grounded in concrete trajectory behavior，也就是从真实 GUI 行为中抽象出来的工具能力。
2、Tool trajectory generation with next-state grounding。
给定合成工具库和原始 GUI 轨迹，MLLM 生成一个功能等价的 tool-only trajectory，并为每一步预测 tool response。
随后通过 next-state grounding，将工具执行效果锚定到原始 GUI 轨迹中的下一帧截图，验证工具步骤和可见状态变化是否一致。
3、Interleaved GUI-Tool trajectory generation。
最后，系统不会简单地把所有 GUI 操作都替换成工具，而是随机采样部分工具调用，再替换回对应 GUI 子序列，形成多种 GUI 与 Tool 交错的轨迹。
这个设计非常关键：它让模型看到不同 tool availability 下的决策边界，也自然产生 GUI -> Tool 和 Tool -> GUI 的 critical switching steps。
最终，ToolCUA 的数据中大约包括了 4k 个 unique tools，覆盖 fine-grained、mid-grained、coarse-grained 多级粒度，大约有 180k steps 数据用于 warmup SFT，还从 critical steps 中 sample 出 5k 条用于 single-turn RL。
基于这些数据，ToolCUA 进一步执行Tool-Bootstrapped GUI RFT。这一阶段的目标，不是直接学完整长程策略，而是先给模型打下一个可用的 hybrid foundation。
具体来说，ToolCUA 先在D_all 上进行 warmup SFT，学习多模态工具调用知识，包括工具用途、参数、返回结果，以及工具执行后的状态变化。
随后，模型在D_critical 上进行 single-turn RL，在明确的 GUI-Tool switching steps 上采样多个 completion，并通过反馈校准模型在局部边界上的选择。
这一阶段做的事情是：先把 interleaved GUI-Tool 数据合成出来，再让模型先学会会用工具和在局部切换点上别选错。
Online Agentic RL 与 Tool-Efficient Path Reward
如果说第一阶段解决的是模型先要进入 hybrid action space，那么第二阶段解决的就是：模型如何在真实环境里学会 trajectory-level 的路径选择。
ToolCUA 的第二阶段是Online Agentic RL。这一步不再只优化单步动作，而是在真实 GUI-Tool environment 中进行 long-horizon rollout，让模型学习完整任务轨迹上的路径选择。
团队首先构建了同时具备 GUI actions 和 Tool calls 的高可用 Sandbox 用于 agentic RL，并且为工具返回结果设计了更加结构化的格式便于模型理解。
Agentic RL 优化的核心是Tool-Efficient Path Reward:
其中，R_fmt 和R_acc 分别是标准格式奖励与任务成功奖励；R_tool 和R_length 则是 ToolCUA 专门设计的两项轨迹级奖励，并且它们只在成功轨迹上激活，避免模型从失败执行里学到错误偏好。
第一项是Tool Appropriateness Reward (R_tool)。
在数据构建时，每个任务会带一个 task-level 的 tool-beneficial 标记：t_b = 1 表示这个任务适合用工具，t_b = -1 表示这个任务不适合用工具。与此同时，c表示整条轨迹里的 tool calls 数。
于是，R_tool 奖励的不是工具调用更多，而是更精确的两种行为:
对于适合工具的任务，成功轨迹里确实调用了工具。
对于不适合工具的任务，成功轨迹里反而没有乱用工具。
它要解决的正是前面提到的 hybrid confusion：有些模型明明该用工具却不用，有些模型则在不该用的时候乱用。R_tool 的作用，就是把工具是否合适这件事从任务成功里单独拎出来训练。
第二项是Path Efficiency Reward (R_length)。
这里，s是当前轨迹的步数，\bar{s}是同组 rollout 的平均步长，S_max 是最大执行步数。ToolCUA 不拿一个固定阈值来判定长还是短，而是做 group-relative comparison:
如果某条成功轨迹比组内平均更短，就给线性 bonus。
如果更长，就做衰减。
这样设计的好处是，模型会自然倾向于探索更短的成功路径。而在很多场景里，更短的路径恰恰意味着：用一个高层工具替代一长串冗余 GUI 操作。因此，R_length 本质上是在鼓励模型发现更高效的GUI-Tool execution path。
所以，这一阶段的核心并不是让模型调用更多工具，而是让它学会两件事：什么时候工具真的合适，什么时候这条执行路径真的更短。
OSWorld-MCP 上达到 46.85%，相对提升约 66%
ToolCUA 主要在 OSWorld-MCP 上评测。这个 benchmark 在传统 OSWorld 的基础上引入了 hybrid GUI-Tool action space，覆盖典型 GUI actions、150+ tools 和主流桌面应用，适合衡量模型在真实混合动作空间中的执行能力。
评测指标包括:
- Accuracy：任务成功率
- TIR (Tool Invocation Rate)：是否做对任务，并且在 tool-beneficial tasks 中使用工具，并在 non-tool-beneficial tasks 中避免工具
- ACS (Average Completion Steps)：平均完成步数，衡量执行效率
ToolCUA-8B 在 OSWorld-MCP 上取得46. 85% accuracy，相比 Qwen3-VL-8B-Instruct baseline 的28. 23%，相对提升约66%。
同时，ToolCUA 超过了 GUI-Owl-1.5-8B (43. 84%)、Gemini-3.1-Pro (41. 14%)和 Claude-4-Sonnet (43. 54%)，并接近 Claude-4.5-Sonnet (48. 35%)与 GUI-Owl-1.5-32B (48. 05%)。
更重要的是效率指标。ToolCUA 的 ACS 仅为14. 93 steps，是表中所有模型里最低的。这说明 ToolCUA 不只是完成了更多任务，也学会了用更短路径完成任务。
与 Qwen3-VL-8B-Instruct 相比，ToolCUA 的 overall TIR 从8. 41%提升到24. 32%，ACS 从19. 34降到14. 93。这说明模型不仅更会做任务，也更会判断什么时候应该调用工具。
在训练阶段，Online Agentic RL 只使用单应用 Linux 任务，并刻意排除了 multi_apps domain，用于 OOD 验证。
结果显示，在 held-out multi_apps 任务上，ToolCUA 从 baseline 的9. 8%和 pre-online RL stage 的18. 5%提升到23. 9%。
在具体应用域上，ToolCUA 也有明显提升。例如在 libreoffice_calculation 上从19. 6%提升到34. 8%，在 vs_code 上从66. 7%提升到94. 4%。
更进一步，ToolCUA 还在 WindowsAgentArena 上进行评测。
尽管训练数据和 sandbox 都来自 Linux 桌面环境，ToolCUA 在 unseen Windows desktop apps 上达到33. 8% accuracy，超过 Qwen3-VL-8B-Instruct 的26. 4%、Qwen3-VL-32B-Instruct 的30. 9%，也超过 Qwen3-VL-235B-A22B 的32. 1%。
这说明 ToolCUA 学到的并不只是某些特定任务模板，而是更接近一种可迁移的hybrid action orchestration能力。
为什么 ToolCUA 真正学会了选路
ToolCUA 的提升到底来自哪里？论文里的 ablation 很清楚地给出三条结论。
第一，如果没有 interleaved GUI-Tool trajectory data，online RL 本身学不会可靠的 tool use。
当去掉 offline interleaved GUI-Tool bootstrapping，直接从 Qwen3-VL-8B-Instruct baseline 开始做 online agentic RL 时，模型的 overall accuracy 虽然也会继续上升，但它很难真正学会稳定的工具调用行为。
最典型的现象是：TIR 长期偏低，训练后期也只到约15%；tool calls 在大部分训练过程中都接近0。
这说明，仅靠 trajectory-level online reward，并不足以让一个 GUI-centric base model 自然长出靠谱的 hybrid switching 能力。模型需要先通过 interleaved supervision 获得工具知识和切换先验。
第二，如果没有 Tool-Efficient Path Reward，模型学不会稳定且高效的路径。
同样在 rl_dynamics 里可以看到，去掉R_tool 和R_length 后，只保留标准的R_acc 与R_fmt，accuracy 曲线会明显更不稳定，在训练 step 8-11左右出现下降，最终与完整 ToolCUA 之间有大约7 个点的差距。
与此同时，TIR 和 tool-calls 也没有稳定上升趋势，trajectory length 也缺少持续下降。
这说明，任务成功奖励本身不足以教会模型什么时候工具是合适的和什么路径才是真正高效的。
第三，Hybrid GUI-Tool training 比 pure GUI training 更有效。
论文进一步比较了 pure GUI training 和 hybrid GUI-Tool training。
GUI-only pipeline 从 baseline 29. 03%提升到 SFT 后34. 93%，再到 agentic RL 后42. 05%；而 GUI+Tool pipeline 中，RFT 已经达到38. 13%，完整 ToolCUA 进一步达到46. 85%。
这表明 hybrid GUI-Tool action space 本身就是一个更高保真的训练环境。模型不只是学 visual grounding，也在这个过程中学会何时应该用结构化工具替代冗余 GUI 操作。
WindowsAgentArena 的结果也说明，这种训练范式带来的不是单点收益，而是更强的跨平台泛化能力。
真正的 GUI-Tool 协同
为了更直观地理解 ToolCUA 的能力，可以看两个实际案例。
第一个是 LibreOffice Calc 任务：用户要求在一个名为 Sheet2 的新 sheet 中创建两个 pivot tables，分别统计 product 和 sales channel 对应的 total revenue。
GUI-only 方法通常需要选择数据范围、打开菜单、配置字段、确认参数，步骤冗长且容易出错。
ToolCUA 则先调用工具读取 workbook 信息和 sheet 内容，识别数据结构与字段位置，然后直接调用 create_pivot_table 生成透视表。
这个案例展示的不是工具永远比 GUI 好，而是: 当任务核心是结构化表格操作时，Tool 可以绕过脆弱的逐步 GUI 导航，用更确定的方式完成任务。
第二个案例来自 VS Code。任务是将/home/user/data1 和/home/user/data2 两个文件夹加入当前 workspace。
ToolCUA 先连续调用 add_folder 工具，把两个目录加入 VS Code workspace。
这一步非常适合工具调用，因为路径明确、操作结构化、目标可验证。
但工具调用完成后，VS Code 弹出了 Do you trust the authors?的信任确认对话框。
这个状态不是简单 tool call 就能闭环的。
此时 ToolCUA 切换回 GUI action，点击 Yes, I trust the authors。
完成界面上的最后一步。
这正是 ToolCUA 想解决的问题：它不是试图用 Tool 替代所有 GUI，也不是退回纯 GUI 操作，而是在真实环境里学习两种 action space 的协同与切换。
Hybrid action training，下一代 CUA 训练范式
在 agent 热潮的推动下，computer use agent 正在更积极地探索真实世界里的落地路径。
ToolCUA 为社区揭示了一个关键现象：一旦进入 hybrid action space，现有 CUA 和部分强基座模型会出现明显的路径困惑，甚至导致准确率下降。
团队通过 staged training paradigm 在 hybrid action training 上做了一次有益探索，并验证了这一路线的有效性。
接下来，更值得继续和推进的方向，是构建更大规模的 CUA 工具，训练更大规模的 CUA 基座模型，让 CUA 原生具有 hybrid actions 的能力，更好地解决人类复杂问题。
项目网站：https://x-plug.github.io/ToolCUA/
代码仓库：https://github.com/X-PLUG/ToolCUA
模型地址：https://huggingface.co/mPLUG/ToolCUA-8B
Mobile-Agent 系列：https://github.com/X-PLUG/MobileAgent
