给Agent同时接上GUI操作和工具调用，准确率反而下降了——这一反直觉的发现，正成为当前AI Agent落地中最棘手的拦路虎。模型在图形界面和API工具之间陷入“选择困难”：该点按钮时偏要去调接口，该调接口时却死磕菜单，两头乱窜，越帮越忙。这种“混合动作空间”的混乱，暴露了现有模型在路径决策上的根本短板。
针对这一挑战，复旦大学与通义实验室MobileAgent团队联合提出了ToolCUA——一个专门面向GUI-Tool混合动作空间的Computer Use Agent。核心目标非常清晰：让模型学会什么时候走GUI路径，什么时候切换到工具调用，以及什么情况下根本不该碰工具。
从实验结果看，这条路线相当能打。ToolCUA-8B在OSWorld-MCP上拿到了46.85%的准确率，不仅超过了Claude-4-Sonnet，还逼近了Claude-4.5-Sonnet的水准。更值得关注的是，它完成任务的平均步数仅为14.93步，是所有对比模型中最短的——这意味着它不只更准，还更高效。
目前，代码、模型权重已全面开源，社区可以直接复现和验证这一方法的有效性。
从行业背景来看，随着桌面端Agent从实验室走向真实场景，单一依赖GUI操作或纯工具调用的方案暴露出各自局限性：GUI操作泛化性强但执行缓慢，工具调用速度快却依赖先验知识覆盖。理想状态是二者结合，但实际试验表明——直接把工具能力接到强模型上，并不会自动带来性能提升，反而可能引发更严重的“路径困惑”。
在hybrid GUI-Tool动作空间中，Agent每一步都站在岔路口：左边是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之间会不会选路。
要让模型学会这种路径选择，首先需要高质量的interleaved GUI-Tool trajectories。但现实中，这类数据极度稀缺：真实工具接口往往与特定应用绑定、覆盖不完整、维护成本高；而收集真实GUI-Tool混合轨迹又需要复杂的环境接入和人工标注。
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。具体来说，先在D_all上进行warmup SFT，学习多模态工具调用知识，包括工具用途、参数、返回结果，以及工具执行后的状态变化。随后，模型在D_critical上进行single-turn RL，在明确的GUI-Tool switching steps上采样多个completion，并通过反馈校准模型在局部边界上的选择。
这一阶段的核心思路是：先把interleaved GUI-Tool数据合成出来，再让模型先学会会用工具和在局部切换点上别选错。
如果说第一阶段解决的是模型“先要进入”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是当前轨迹的步数，s̄是同组rollout的平均步长，S_max是最大执行步数。ToolCUA不拿一个固定阈值来判定长还是短，而是做group-relative comparison：如果某条成功轨迹比组内平均更短，就给线性bonus；如果更长，就做衰减。这样设计的好处是，模型会自然倾向于探索更短的成功路径。而在很多场景里，更短的路径恰恰意味着：用一个高层工具替代一长串冗余GUI操作。因此，R_length本质上是在鼓励模型发现更高效的GUI-Tool execution path。
所以，这一阶段的核心并不是让模型调用更多工具，而是让它学会两件事：什么时候工具真的合适，什么时候这条执行路径真的更短。
为了验证效果，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%。在具体应用域上，也有明显提升，例如在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的提升到底来自哪里？论文里的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的结果也说明，这种训练范式带来的不是单点收益，而是更强的跨平台泛化能力。
为了更直观地理解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模式，通过截图识别对话框和按钮坐标，执行点击操作，完成界面上的最后一步。
这正是ToolCUA想解决的问题：它不是试图用Tool替代所有GUI，也不是退回纯GUI操作，而是在真实环境里学习两种action space的协同与切换。工具负责结构化、确定性的操作，GUI负责处理工具无法覆盖的交互状态，二者互补。
在agent热潮的推动下，computer use agent正在更积极地探索真实世界里的落地路径。ToolCUA为社区揭示了一个关键现象：一旦进入hybrid action space，现有CUA和部分强基座模型会出现明显的路径困惑，甚至导致准确率下降。团队通过staged training paradigm在hybrid action training上做了一次有益探索，并验证了这一路线的有效性。
接下来，更值得继续和推进的方向，是构建更大规模的CUA工具，训练更大规模的CUA基座模型，让CUA原生具有hybrid actions的能力，更好地解决人类复杂问题。从目前的结果来看，这一思路已经展现出了明确的可行性和巨大潜力。当Agent不再“两头乱窜”，而是学会在GUI和Tool之间自如切换，桌面自动化可能真正迎来质变。
项目网站：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
