复旦×通义CUA训练范式：破解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调用或API-based操作往往更高效、更精准。例如在LibreOffice中批量处理电子表格，纯GUI方式需要一串繁琐的菜单点击与参数配置，而工具调用可能一条API指令就立竿见影。

看似最自然的方案，是让Agent同时掌握GUI与Tool两种操作能力。但实验数据揭示了一个反直觉的现实：简单地将Tools接入强模型，并不能自动提升性能。

在hybrid GUI-Tool action space中，Agent每一步都面临岔路口：左侧是GUI，右侧是Tool。GUI泛化性虽强但行动迟缓，Tool虽快却依赖覆盖范围与上下文条件。一旦模型缺少路径选择能力，就会暴露两类典型失效场景：

Tool使用不足：即使存在更高效的工具，模型仍固执地走GUI路线。

Tool滥用：模型频繁调用工具，但调用时机错误、调用粒度不当，反而降低任务完成率。

论文将这个难题定义为最优GUI-Tool路径选择：在长程任务中动态决定何时使用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路径选择，首先需要高质量的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、轨迹感知的合成工具库构建。

针对每条GUI轨迹，模型会分析任务目标、动作序列与截图描述，从真实操作流程中抽取出可调用的工具。例如，从Chrome设置流程中抽象出chrome_open_language_settings，从LibreOffice表格操作中抽象出读取工作簿信息、创建透视表等工具。这些工具并非凭空生成的API模板，而是grounded in concrete trajectory beha vior——从真实的GUI行为中抽象出的工具能力。

2、基于下一帧状态锚定的工具轨迹生成。

给定合成工具库与原始GUI轨迹，MLLM生成一个功能等价的tool-only trajectory，并为每一步预测tool response。随后通过next-state grounding，将工具执行效果锚定到原始GUI轨迹中的下一帧截图，验证工具步骤与可见状态变化是否一致。

3、交错的GUI-Tool轨迹生成。

最后，系统不会机械地将所有GUI操作替换为工具，而是随机采样部分工具调用后，再替换回对应GUI子序列，形成多种GUI与Tool交错的轨迹。这个设计至关重要：它让模型感知不同tool a vailability下的决策边界，自然产生了GUI -> Tool和Tool -> GUI的critical switching steps。

最终，ToolCUA的数据集包含约4k个独特工具，覆盖细粒度、中粒度、粗粒度多级粒度，约180k steps数据用于warmup SFT，此外从critical steps中采样出5k条用于单步强化学习。

基于这些数据，ToolCUA进一步执行Tool-Bootstrapped GUI RFT。这一阶段的目标并非直接学习完整的长期策略，而是先为模型打下可用的混合基础。

具体来说，ToolCUA先在D_all上进行warmup SFT，学习多模态工具调用知识——包括工具用途、参数、返回结果，以及工具执行后的状态变化。随后，模型在D_critical上进行single-turn RL，在明确的GUI-Tool switching steps上采样多个completion，并通过反馈校准模型在局部边界上的选择。

这一阶段的核心可概括为：先合成交错GUI-Tool数据，再让模型学会工具使用，并在关键切换点上避免选错路径。

在线智能体强化学习与工具高效路径奖励机制

如果说第一阶段解决的是让模型进入hybrid action space，那么第二阶段解决的核心问题就是：模型如何在真实环境中掌握trajectory-level的路径选择。

ToolCUA的第二阶段是在线智能体强化学习。这一步不再局限于单步动作优化，而是在真实的GUI-Tool环境中进行long-horizon rollout，让模型学习完整任务轨迹上的路径选择。

团队首先构建了同时支持GUI actions和Tool calls的高可用Sandbox用于agentic RL，并为工具返回结果设计了更结构化的格式，便于模型理解。

Agentic RL的优化核心是工具高效路径奖励机制：

其中，R_fmt和R_acc分别为标准格式奖励与任务成功奖励；R_tool和R_length则是ToolCUA专门设计的两项轨迹级奖励，且仅在成功轨迹上激活，避免模型从失败执行中习得错误偏好。

第一项是工具适用性奖励。

在数据构建时，每个任务附带一个task-level的tool-beneficial标记：t_b = 1表示该任务适合使用工具，t_b = -1表示不适合。同时，c表示整条轨迹中的tool calls数量。

因此，R_tool奖励的并非更多工具调用，而是更精确的两种行为：对于适合工具的任务，成功轨迹中确实调用了工具；对于不适合工具的任务，成功轨迹中反而没有滥用工具。

它要解决的正是前面提到的hybrid confusion：部分模型该用工具时不用，有些模型则在不该用时乱用。R_tool的作用，就是将工具是否合适这个因素从任务成功中单独剥离出来进行训练。

第二项是路径效率奖励。

这里，s是当前轨迹的步数，bar{s}是同组rollout的平均步长，S_max是最大执行步数。ToolCUA不采用固定阈值判断长短，而是进行组内相对比较：

如果某条成功轨迹比组内平均更短，给予线性奖励；如果更长，则进行衰减。

这种设计的好处是：模型会自然倾向于探索更短的成功路径。在许多场景中，更短的路径恰恰意味着——用一个高层工具替代一长串冗余GUI操作。因此，R_length本质上是在鼓励模型发现更高效的GUI-Tool执行路径。

所以，这一阶段的核心并非让模型调用更多工具，而是让它学会两件事：何时工具确实适用，何时执行路径确实更短。

OSWorld-MCP达到46.85%，相对提升约66%

ToolCUA主要在OSWorld-MCP上接受评估。该基准测试在传统OSWorld基础上引入了hybrid GUI-Tool action space，覆盖典型GUI actions、150+个工具和主流桌面应用，非常适合衡量模型在真实混合动作空间中的执行能力。

评估指标包括：

• Accuracy：任务成功率
• TIR：是否正确完成任务，并且在tool-beneficial tasks中使用工具，在non-tool-beneficial tasks中避免工具
• ACS：平均完成步数，衡量执行效率

ToolCUA-8B在OSWorld-MCP上取得46.85%的准确率，相比Qwen3-VL-8B-Instruct基线的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步，在所有模型中最低。这说明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从基线的9.8%和pre-online RL阶段的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%的准确率，超越了Qwen3-VL-8B-Instruct的26.4%、Qwen3-VL-32B-Instruct的30.9%，以及Qwen3-VL-235B-A22B的32.1%。

这说明ToolCUA学到的并非某些特定任务模板，而是更接近一种可迁移的混合动作编排能力。

ToolCUA真正学会路径选择的关键

ToolCUA的提升究竟来自何处？论文中的消融实验给出了三条清晰的结论。

第一，缺少interlea ved GUI-Tool trajectory数据，online RL本身无法习得可靠的tool use。

当移除offline interlea ved GUI-Tool bootstrapping，直接从Qwen3-VL-8B-Instruct基线开始执行online agentic RL时，模型的overall accuracy虽然会继续提升，但很难真正建立稳定的工具调用行为。

最典型的现象是：TIR长期偏低，训练后期也仅达到约15%；tool calls在大部分训练过程中接近0。

这说明，仅凭trajectory-level online reward，不足以让一个GUI-centric基座模型自然产生可靠的hybrid switching能力。模型必须首先通过interlea ved supervision获取工具知识和切换先验。

第二，缺少工具高效路径奖励，模型无法学习稳定且高效的路径。

同样在rl_dynamics中可以看到，移除R_tool和R_length后，仅保留标准的R_acc与R_fmt，accuracy曲线明显更不稳定，在训练step 8-11左右出现下滑，与完整ToolCUA之间存在约7个点的差距。

与此同时，TIR和tool-calls缺乏稳定的上升趋势，trajectory length也缺少持续下降。这说明，任务成功奖励本身不足以教会模型何时工具是合适的，以及什么路径才是真正高效的。

第三，混合GUI-Tool训练比纯GUI训练更有效。

论文进一步比较了纯GUI训练与混合GUI-Tool训练。

GUI-only pipeline从基线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中创建两个透视表，分别统计product和sales channel对应的total revenue。

纯GUI方法通常需要选择数据范围、打开菜单、配置字段、确认参数，步骤繁冗且容易出错。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空间的协同与切换。

混合动作训练：下一代CUA训练范式

在Agent热潮的推动下，Computer Use Agent正在加速探索真实世界中的落地路径。

ToolCUA为社区揭示了一个关键现象：一旦进入hybrid action space，现有CUA和部分强基座模型会出现明显的路径困惑，甚至导致准确率下降。

团队通过分阶段训练范式在hybrid action training上进行了有益探索，并验证了这一路线的可行性。

接下来的方向，是构建更大规模的CUA工具库，训练更大规模的CUA基座模型，使CUA原生具备hybrid actions能力，更好地解决人类复杂的真实问题。

来源：互联网