Agent不会自主选择工具？别只加工具不训练

给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的操作往往更高效、更精确。举个例子，在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，首先得有高质量的interlea ved GUI-Tool trajectories。但现实是，这类数据非常稀缺。真实工具接口往往与应用绑定、覆盖不完整，维护成本高；收集真实GUI-Tool混合轨迹又需要复杂的环境接入和人工标注。已有的GUI数据虽然规模很大，但大多是GUI-only trajectories，只教模型如何点击和输入，并没有告诉模型何时应该用工具替代冗长的GUI操作。

ToolCUA的第一步，就是把这些GUI-only数据盘活，顺便完成第一阶段的hybrid bootstrapping。论文提出了Interlea ved GUI-Tool Trajectory Scaling Pipeline：从已有GUI轨迹出发，利用MLLM合成grounded tool library，再把GUI-only trajectories转换成interlea ved GUI-Tool trajectories。

整个pipeline可以概括为三个步骤：

1. Trajectory-aware synthetic tool library construction。对每条GUI轨迹，模型会分析任务目标、动作序列和截图描述，从真实操作流程中抽象出可调用的工具。例如从Chrome设置流程中抽象出chrome_open_language_settings，从LibreOffice表格操作中抽象出读取工作簿信息、创建透视表等工具。这些工具不是凭空生成的API模板，而是grounded in concrete trajectory beha vior——从真实的GUI行为中抽象出来的工具能力。
2. Tool trajectory generation with next-state grounding。给定合成工具库和原始GUI轨迹，MLLM生成一个功能等价的tool-only trajectory，并为每一步预测tool response。随后通过next-state grounding，将工具执行效果锚定到原始GUI轨迹中的下一帧截图，验证工具步骤和可见状态变化是否一致。
3. Interlea ved GUI-Tool trajectory generation。最后，系统不会简单地把所有GUI操作都替换成工具，而是随机采样部分工具调用，再替换回对应的GUI子序列，形成多种GUI与Tool交错的轨迹。这个设计非常关键：它让模型看到不同tool a vailability下的决策边界，也自然产生了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，并通过反馈校准模型在局部边界上的选择。简单说：先把interlea ved 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是当前轨迹的步数，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 (A verage 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真正学会了选路

ToolCUA的提升到底来自哪里？论文里的ablation很清楚地给出三条结论。

第一，如果没有interlea ved GUI-Tool trajectory data，online RL本身学不会可靠的tool use。

当去掉offline interlea ved 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能力。模型需要先通过interlea ved 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比pu re GUI training更有效。

论文进一步比较了pu re 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

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Agent不会自主选择工具？别只加工具不训练要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题