复旦通义CUA训练范式：Agent工具选择新解法
## 传统CUA的局限性：原子化操作与工具调用的矛盾
传统CUA通常依赖原子化GUI操作（点击、输入、拖拽、滚动），虽然泛化能力强（理论上可见按钮即可操作），但存在显著缺陷：步骤冗长、误差叠加，在复杂任务中易引发级联错误（cascading errors）。
相比之下，工具调用或基于API的操作往往更高效、更精确。例如在LibreOffice中批量处理表格数据，纯GUI方案需要繁琐的菜单点击与参数配置，而工具调用可能仅一个API即可完成。
最直观的做法是让Agent同时具备GUI与Tool能力。然而实验揭示了一个反直觉现象：**直接将工具接入强模型，并不会自动提升性能。**
在混合GUI-Tool动作空间中，Agent每一步都面临岔路口：左边GUI，右边Tool。GUI泛化性强但执行缓慢，Tool响应快速却依赖覆盖范围与上下文条件。若模型缺乏路径选择能力，将出现两类典型失败：
- **工具使用不足**：存在更高效工具时，模型仍几乎锁定GUI路线。
- **工具滥用**：模型频繁调用工具，但时机不当或粒度不合理，反而降低任务成功率。
论文将此问题定义为**最优GUI-Tool路径选择**：在长程任务中动态决定何时使用GUI动作、何时调用工具，以形成更高效可靠的执行轨迹。
上图左侧表格直接给出了这一反直觉现象：将工具接入强模型后，结果并非总是更好。
Qwen3VL-8B几乎不使用工具，平均工具调用仅0.003次，准确率从29.0%降至28.2%；Qwen3VL-235B则明显倾向调用工具，平均工具调用达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间做出正确路径选择**。
## 如何盘活GUI-only数据？—— Interleaved GUI-Tool Trajectory Scaling Pipeline
要让模型学会GUI-Tool路径选择，首先需要高质量的interleaved GUI-Tool轨迹。但现实中此类数据极为稀缺。真实工具接口往往与应用场景绑定、覆盖不全且维护成本高；收集真实混合轨迹则需要复杂的环境接入和人工标注。
现有GUI数据虽然规模庞大，但绝大多数为纯GUI轨迹，只教会模型如何点击和输入，并未告知何时该用工具替代冗长GUI操作。
ToolCUA的第一步，就是盘活这些GUI-only数据，并顺势完成第一阶段的混合引导。
论文提出**Interleaved GUI-Tool Trajectory Scaling Pipeline**：从已有GUI轨迹出发，利用MLLM合成具身工具库，再将GUI-only轨迹转换为interleaved GUI-Tool轨迹。
整个流程可归纳为三个步骤：
### 1. 轨迹感知的合成工具库构建
对每条GUI轨迹，模型分析任务目标、动作序列及截图描述，从真实操作流程中抽象出可调用的工具。例如从Chrome设置流程中抽象出`chrome_open_language_settings`，从LibreOffice表格操作中抽象出读取工作簿信息、创建透视表等工具。这些工具并非凭空生成的API模板，而是基于具体轨迹行为——从真实GUI操作中抽象出的工具能力。
### 2. 基于下一状态接地（Next-State Grounding）的工具轨迹生成
给定合成工具库与原始GUI轨迹，MLLM生成功能等价的纯工具轨迹，并为每一步预测工具响应。随后通过下一状态接地，将工具执行效果锚定到原始GUI轨迹中的下一帧截图，验证工具步骤与可见状态变化是否一致。
### 3. Interleaved GUI-Tool轨迹生成
最后，系统并非简单地将所有GUI操作替换为工具，而是随机采样部分工具调用，再替换回对应GUI子序列，形成多种GUI与Tool交错的轨迹。这一设计至关重要：它让模型观察到不同工具可用性下的决策边界，自然产生GUI→Tool与Tool→GUI的关键切换步骤。
最终，ToolCUA的数据集包含约4k个独特工具，覆盖细粒度、中粒度、粗粒度多级精度，约180k步数据用于预热SFT，并从关键切换步骤中采样5k条用于单步强化学习。
### 工具引导的GUI RFT
基于这些数据，ToolCUA进一步执行**工具引导的GUI RFT**。此阶段目标不是直接学习完整长程策略，而是先为模型打下可用的混合基础。
具体而言，ToolCUA先在D_all上开展预热SFT，学习多模态工具调用知识，包括工具用途、参数、返回结果以及工具执行后的状态变化。随后，模型在D_critical上进行单步强化学习，在明确的GUI-Tool切换步骤上采样多个完成候选，通过反馈校准模型在局部边界上的选择。
这一阶段的核心是：**先合成interleaved GUI-Tool数据，再让模型学会使用工具并在局部切换点避免选错。**
## 第二阶段：在线智能体强化学习
如果说第一阶段解决的是模型先进入混合动作空间，那么第二阶段解决的是：**模型如何在真实环境中学会轨迹级别的路径选择。**
ToolCUA的第二阶段为**在线智能体强化学习**。这一步不再只优化单步动作，而是在真实GUI-Tool环境中进行长程推出，让模型学习完整任务轨迹上的路径选择。
团队首先构建了同时具备GUI动作和工具调用的高可用Sandbox用于智能体强化学习，并为工具返回结果设计了更结构化的格式以方便模型理解。
智能体强化学习优化的核心是**工具高效路径奖励**：
其中，R_fmt和R_acc分别是标准格式奖励与任务成功奖励；R_tool和R_length则是ToolCUA专门设计的两项轨迹级奖励，且仅在成功轨迹上激活，避免模型从失败执行中学习错误偏好。
### 工具适当性奖励
数据构建时，每个任务附带一个任务级别的工具有益标记：t_b = 1表示该任务适合使用工具，t_b = -1表示不适合。同时，c表示整条轨迹中的工具调用次数。R_tool奖励的不是更多工具调用，而是更精确的两种行为：
- 对于适合工具的任务，成功轨迹中确实调用了工具。
- 对于不适合工具的任务，成功轨迹中没有滥用工具。
它正是要解决前面提到的混合困惑：某些模型该用工具时不用，有些则在不该用时乱用。R_tool的作用，就是将工具是否合适这一因素从任务成功中单独分离出来进行训练。
### 路径效率奖励
这里，s是当前轨迹的步骤数，s̄是同组推出的平均步长，S_max是最大执行步数。ToolCUA不采用固定阈值判定长短，而是进行组内相对比较：
- 若某条成功轨迹比组内平均更短，则给予线性奖励。
- 若更长，则做衰减惩罚。
此举优点在于：模型会自然倾向于探索更短的成功路径。许多场景中，更短的路径恰恰意味着用一个高层工具替代一长串冗余GUI操作。因此，R_length本质上是鼓励模型发现更高效的**GUI-Tool执行路径**。
所以，这一阶段的核心并非让模型调用更多工具，而是让它学会两件事：**什么时候工具真的合适，以及什么时候这条执行路径真的更短。**
## 评测结果：ToolCUA-8B超越Claude-4-Sonnet
ToolCUA主要在OSWorld-MCP上评测。该基准测试在传统OSWorld基础上引入了混合GUI-Tool动作空间，覆盖典型GUI动作、150+工具和主流桌面应用，适合衡量模型在真实混合动作空间中的执行能力。
评测指标包括：
- **准确率**：任务成功率
- **工具调用率**：是否正确完成任务，并在工具有益任务中使用工具，在非工具有益任务中避免工具
- **平均完成步数**：衡量执行效率
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的平均完成步数仅为**14.93步**，是表中所有模型里最低的。这说明ToolCUA不仅完成了更多任务，也学会了用更短路径完成任务。
与Qwen3-VL-8B-Instruct相比，ToolCUA的整体工具调用率从**8.41%**提升至**24.32%**，平均完成步数从**19.34**降至**14.93**。这表明模型不仅更会做任务，也更会判断何时应该调用工具。
训练阶段中，在线智能体强化学习仅使用单应用Linux任务，并刻意排除了multi_apps域用于越分布验证。结果显示，在保留的多应用任务上，ToolCUA从基线的**9.8%**和预在线RL阶段的**18.5%**提升至**23.9%**。在具体应用域上，ToolCUA也有显著提升，例如在libreoffice_calculation上从**19.6%**升至**34.8%**，在vs_code上从**66.7%**升至**94.4%**。
进一步地，ToolCUA还在WindowsAgentArena上评测。尽管训练数据和沙箱均来自Linux桌面环境，ToolCUA在未见过的Windows桌面应用上达到**33.8%**准确率，超越Qwen3-VL-8B-Instruct的**26.4%**、Qwen3-VL-32B-Instruct的**30.9%**，也超越Qwen3-VL-235B-A22B的**32.1%**。这说明ToolCUA学到的并非特定任务模板，而是更接近一种可迁移的**混合动作编排**能力。
## 消融实验：三个关键发现
ToolCUA的提升来自何处？论文的消融实验清楚给出三条结论。
**第一，缺少interleaved GUI-Tool轨迹数据时，在线强化学习本身无法学会可靠的工具使用。**
当移除离线interleaved GUI-Tool引导，直接从Qwen3-VL-8B-Instruct基线开始进行在线智能体强化学习时，模型的整体准确率虽仍会上升，但很难真正学会稳定的工具调用行为。最典型现象是：工具调用率长期偏低，训练后期也仅约**15%**；工具调用次数在大部分训练过程中接近**0**。这说明仅凭轨迹级别的在线奖励，不足以让以GUI为中心的基座模型自然产生可靠的混合切换能力。模型需要先通过interleaved监督获得工具知识与切换先验。
**第二，缺少工具高效路径奖励时，模型无法学习稳定且高效的路径。**
同样在强化学习动态中可以看到，移除R_tool和R_length后，仅保留标准R_acc与R_fmt，准确率曲线明显更不稳定，在训练步**8-11**左右出现下降，最终与完整ToolCUA之间相差约**7个点**。同时，工具调用率和工具调用次数没有稳定上升趋势，轨迹长度也未能持续下降。这说明任务成功奖励本身不足以教会模型何时工具合适以及何种路径真正高效。
**第三，混合GUI-Tool训练比纯GUI训练更有效。**
论文进一步比较了纯GUI训练与混合GUI-Tool训练。纯GUI pipeline从基线**29.03%**提升至SFT后**34.93%**，再到智能体强化学习后**42.05%**；而GUI+Tool pipeline中，RFT已达到**38.13%**，完整ToolCUA进一步达到**46.85%**。这表明混合GUI-Tool动作空间本身就是一个更高保真的训练环境。模型不仅学习视觉接地，也在此过程中学会何时使用结构化工具替代冗余GUI操作。WindowsAgentArena的结果也说明，这种训练范式带来的是更强的**跨平台泛化能力**，而非单点收益。
## 案例展示：真实的协同与切换
为了更直观地理解ToolCUA的能力，我们来看两个实际案例。
**案例一：LibreOffice Calc任务**
用户要求在一个名为Sheet2的新工作表创建两个数据透视表，分别统计产品和销售渠道对应的总收入。
纯GUI方法通常需要选择数据范围、打开菜单、配置字段、确认参数，步骤冗长且易出错。ToolCUA则先调用工具读取工作簿信息和工作表内容，识别数据结构与字段位置，然后直接调用create_pivot_table生成透视表。
此案例并非说明工具永远优于GUI，而是：当任务核心为结构化表格操作时，工具可以绕过脆弱的逐步GUI导航，以更确定的方式完成任务。
**案例二：VS Code的信任对话框**
任务是将/home/user/data1和/home/user/data2两个文件夹加入当前工作区。ToolCUA先连续调用add_folder工具，将两个目录加入VS Code工作区。此步骤非常适合工具调用，因为路径明确、操作结构化、目标可验证。
但工具调用完成后，VS Code弹出“Do you trust the authors?”的信任确认对话框。此状态无法通过简单工具调用闭环。此时ToolCUA切换回GUI动作，点击“Yes, I trust the authors”。
完成界面上的最后一步。
这正是ToolCUA要解决的问题：它不是用工具替代所有GUI，也不是退回纯GUI操作，而是在真实环境中学习两种动作空间的**协同与切换**。
## 总结与展望
在Agent热潮推动下，Computer Use Agent正积极探索真实世界的落地路径。ToolCUA为社区揭示了一个关键现象：一旦进入混合动作空间，现有CUA和部分强基座模型会出现明显的路径困惑，甚至导致准确率下降。
团队通过分阶段训练范式在混合动作训练上做了一次有益探索，并验证了该路线的有效性。接下来，更值得持续推进的方向是构建更大规模的CUA工具库，训练更大规模的CUA基座模型，让CUA原生具备混合动作能力，更好地解决人类复杂问题。
- 项目网站：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