桌面 Agent 的下一步：不是会操作，而是会调度工具

想象一个桌面 Agent 正在替你整理表格、配置浏览器、修改 VS Code workspace。它既能像人一样点击界面，也能直接调用工具完成结构化操作。

这听起来像是一个更强的 Agent：看到按钮就点，遇到表格就调 API，遇到文件路径就用工具。但真正运行起来后，问题并不在于“能力够不够多”，而在于“每一步该用哪种能力”。工具用少了，Agent 仍然陷在漫长 GUI 路径里；工具用多了，又可能因为时机不对把任务做坏。

这正是 ToolCUA 试图解决的问题。复旦大学和通义实验室 MobileAgent 团队提出的这项工作，将 Computer Use Agent 放到 GUI-Tool hybrid action space 中训练，让模型学习一种更接近真实办公自动化的能力：在 GUI actions 和 tool calls 之间进行路径编排。

• 论文：ToolCUA: Towards Optimal GUI-Tool Path Orchestration for Computer Use Agents

• 网站：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

01 从“会操作”到“会调度”

早期 CUA 的核心能力是视觉 grounding：看见界面元素，然后点击、输入、拖拽或滚动。这条路线非常通用，因为它不依赖特定应用的内部接口，只要界面可见，模型就可以尝试操作。

但当任务变长之后，GUI-only 的弱点会被放大。一次表格透视、一段浏览器设置、一个 IDE workspace 修改，可能都要展开为几十个细粒度动作。路径越长，越容易出现 cascading errors。

工具调用提供了另一种可能。Tool calls 或 API-based operations 可以用更短、更确定的方式完成结构化任务。例如在 LibreOffice 中创建 pivot table，工具可以直接读取 workbook 信息、定位字段、生成透视表，而不必一步步导航菜单。

因此，一个自然设想是：让 Agent 同时拥有 GUI 和 Tool。问题是，二者简单相加并不等于能力自动提升。模型必须学会调度：当前状态适合工具吗？工具调用之后是否还需要 GUI 确认？这个任务是否根本不应该用工具？

ToolCUA 将这个问题称为 optimal GUI-Tool path selection。它关注的是长程任务中每一步如何选择 GUI actions 或 tools，从而得到更可靠、更高效的执行路径。

实验中的 path confusion 非常明显。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%。

这意味着，hybrid action space 的难点不是工具本身，而是模型能否在 GUI 与 Tool 之间做出正确切换。

02 数据从哪里来：把 GUI 轨迹改造成混合轨迹

训练这样的能力需要 interleaved GUI-Tool trajectories。但真实数据很难获得：真实工具接口通常和应用绑定，覆盖有限且维护成本高；真实采集混合轨迹又需要复杂环境接入和人工标注。

已有 GUI-only 数据虽然更多，但它们只告诉模型如何点击和输入，没有告诉模型何时应该把一串 GUI 操作替换为工具调用。

ToolCUA 的做法是提出 Interleaved GUI-Tool Trajectory Scaling Pipeline，从已有 GUI 轨迹出发，合成 grounded tool library，并生成 GUI 与 Tool 交错的训练轨迹。

第一步是 Trajectory-aware synthetic tool library construction。系统根据任务目标、动作序列和截图描述，从真实 GUI 操作流程中抽象工具能力。例如，从 Chrome 设置流程中抽象出 chrome_open_language_settings，从 LibreOffice 表格操作中抽象出读取工作簿信息、创建透视表等工具。

这些工具 grounded in concrete trajectory behavior，不是脱离真实操作流程凭空生成的 API 模板。

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

第三步是 Interleaved GUI-Tool trajectory generation。系统不会把所有 GUI 操作都替换成工具，而是随机采样部分工具调用，再替换回对应 GUI 子序列，形成多种 GUI 与 Tool 交错的轨迹。

这套流程最终得到约 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。模型先在 D_all 上学习工具用途、参数、返回结果和工具执行后的状态变化，再在 D_critical 上针对 GUI-Tool switching steps 做 single-turn RL，校准关键切换位置的局部决策。

03 GUI-Tool Agentic RL奖励设计：不是“多用工具”，而是“用得合适”

只学离线合成数据还不够，因为真实桌面任务是长程的。一个工具调用会改变后续界面状态，一个 GUI 点击也可能影响后续工具是否可用。因此，ToolCUA 进一步进行 Online Agentic RL。

这一阶段在真实 GUI-Tool environment 中做 long-horizon rollout。我们构建了同时支持 GUI actions 和 Tool calls 的高可用 Sandbox，并为工具返回结果设计了更结构化的格式，帮助模型理解环境变化。

核心设计是 Tool-Efficient Path Reward：

R_fmt 和 R_acc 分别对应格式奖励与任务成功奖励。ToolCUA 额外加入 R_tool 和 R_length 两个轨迹级奖励，并且只在成功轨迹上激活，避免从失败执行中学习错误偏好。

R_tool 是 Tool Appropriateness Reward。

每个任务都有 task-level 的 tool-beneficial 标记：t_b = 1 表示适合用工具，t_b = -1 表示不适合用工具。c 表示整条轨迹里的 tool calls 数。

因此，R_tool 鼓励的不是工具越多越好，而是两种具体行为：

• tool-beneficial tasks 中，成功轨迹应该调用工具。

• non-tool-beneficial tasks 中，成功轨迹应该避免乱用工具。

R_length 是 Path Efficiency Reward。其中，s 是当前轨迹步数，\bar{s} 是同组 rollout 的平均步长，S_max 是最大执行步数。ToolCUA 使用 group-relative comparison：成功轨迹比组内平均更短就给线性 bonus，更长则衰减。

这会推动模型寻找更短的成功路径。在很多桌面任务里，更短路径往往意味着找到正确的工具调用点，用高层工具替代冗余 GUI 序列。

04 效率与准确率的大幅提升

ToolCUA 主要在 OSWorld-MCP 上评测。OSWorld-MCP 在传统 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%。

它超过 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，是表中所有模型里最低的。相比 Qwen3-VL-8B-Instruct，overall TIR 从 8.41% 提升到 24.32%，ACS 从 19.34 降到 14.93。

也就是说，ToolCUA 不只是做对了更多任务，还用更合理的工具调用和更短的路径完成任务。

泛化实验中，Online Agentic RL 训练只使用单应用 Linux 任务，并刻意排除了 multi_apps domain。在 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%。

这说明模型学到的是可迁移的 hybrid action orchestration，而不是局限于某些训练任务的模板。

05 消融带来的三点启发

第一，混合轨迹数据是进入 hybrid action space 的门槛。

如果去掉 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 获得工具知识和切换先验。

第二，成功奖励不能替代路径奖励。

去掉 R_tool 和 R_length，只保留 R_acc 与 R_fmt 后，accuracy 曲线会明显更不稳定，在训练 step 8-11 左右出现下降，最终与完整 ToolCUA 有大约 7 个点差距。

与此同时，TIR 和 tool-calls 没有稳定上升趋势，trajectory length 也缺少持续下降。任务成功奖励告诉模型结果对不对，但无法充分告诉模型工具是否合适、路径是否高效。

第三，hybrid training 比 pure GUI 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 本身提供了更高保真的训练环境。模型不仅学习界面 grounding，也学习何时应该用结构化工具替代冗长 GUI 操作。

06 两个混合空间下的真实执行案例

LibreOffice Calc 案例中，用户要求在名为 Sheet2 的新 sheet 中创建两个 pivot tables，分别统计 product 和 sales channel 对应的 total revenue。

GUI-only 路径通常需要选择数据范围、打开菜单、配置字段、确认参数。ToolCUA 则先调用工具读取 workbook 信息和 sheet 内容，识别数据结构与字段位置，然后调用 create_pivot_table 生成透视表。

这类任务的核心是结构化表格操作，工具可以显著减少脆弱的 GUI 导航。

VS Code 案例中，用户要求将 /home/user/data1 和 /home/user/data2 两个文件夹加入当前 workspace。

ToolCUA 先调用 add_folder 工具加入两个目录。这一步路径明确、操作结构化，非常适合工具。

随后 VS Code 弹出 “Do you trust the authors?” 的信任确认对话框。此时 ToolCUA 切回 GUI action，点击 “Yes, I trust the authors”，完成最后一步。

这两个案例共同说明，GUI 与 Tool 的关系不是替代，而是接力。

07 CUA是真实工作流的入口场景

如果未来的 CUA 要真正进入人类工作流，它需要处理的任务不会只属于一个动作空间。真实任务往往一部分适合结构化工具，一部分需要视觉确认，一部分又必须通过 GUI 与应用状态交互。

ToolCUA 给出的方向是：让模型原生学习 hybrid actions，而不是在 GUI-only 模型外面临时拼接工具。训练目标也不应只看任务成败，还要关心工具是否合适、路径是否高效、切换是否发生在正确位置。

从这个角度看，ToolCUA 是该方向是有益的尝试，也是在提示下一代 Claw-like agent 的训练范式：更大规模的 CUA 工具体系、更大规模的 CUA 基座模型，以及更真实的多动作空间环境，可能会成为通往复杂桌面智能体的重要基础。