ToolCUA:面向计算机使用智能体的最优GUI-工具路径编排方法 ToolCUA: Towards Optimal GUI-Tool Path Orchestration for Computer Use Agents
通过合成GUI-工具混合轨迹与两阶段RL,让8B模型学会在合适的时机切换GUI与工具调用,在OSWorld-MCP上达到46.85% SOTA。
前置知识
Computer Use Agent (CUA)
能够在真实桌面环境中通过截图理解屏幕状态,执行click/type/scroll等原子GUI操作来完成用户任务的智能体,通常基于多模态大语言模型构建。其代表性评测基准包括OSWorld、WindowsAgentArena等。
本文的核心对象就是CUA,需要理解CUA如何在桌面截图和工具接口之间做决策,才能理解'最优GUI-Tool路径选择'这一研究问题。
MCP (Model Context Protocol) 工具调用
MCP是一种结构化的工具调用协议,智能体可以调用API级别的工具函数(如libreoffice_set_fill_color、create_pivot_table),相比GUI操作具有更高的效率和精度,但受服务覆盖和稳定性限制。每种工具有明确的函数签名、参数语义和返回值。
本文的hybrid action space中工具调用就是基于MCP协议实现的,Rtool奖励和TIR指标都围绕MCP工具的合理调用展开,是论文技术方案的基础。
GRPO (Group Relative Policy Optimization)
一种强化学习算法,通过在每个prompt下采样一组候选回答,使用组内相对优势(而非绝对奖励)来更新策略。它省去了单独训练价值网络的成本,在LLM/MLLM的后训练中广泛使用,DAPO是其改进版本,引入动态过滤保留含正负样本的组。
本文在单步RL和在线agentic RL两个阶段都使用GRPO(或其变体DAPO)作为策略优化器,是训练范式的核心算法。
轨迹级监督 vs 步级监督
步级监督只关心当前一步动作是否合理(局部最优),而轨迹级监督关心整条执行路径是否高效、可靠(全局最优)。在GUI-Tool混合空间中,一次切换决策会重塑后续所有步,需要轨迹级反馈。
本文的核心论点是'最优GUI-Tool路径选择是轨迹级策略学习问题',作者设计Tool-Efficient Path Reward正是为了在轨迹层面提供反馈,这一区分贯穿整篇论文。
OSWorld / OSWorld-MCP 基准
OSWorld是基于QEMU真实桌面镜像的CUA评测基准,涵盖Chrome/VSCode/LibreOffice等多应用任务;OSWorld-MCP在其上扩展了150+ MCP工具,提供feasible tasks子集,并通过TIR等指标评估工具调用合理性,本文主要在该基准上评测。
这是论文实验的主战场,所有性能数字、对比基线、ablation结果都基于OSWorld-MCP的feasible任务报告(共333个),需要理解其任务划分和指标含义。
研究动机
现有Computer Use Agent (CUA)在hybrid action space(同时支持原子GUI操作click/type/scroll和高级工具调用MCP API)上普遍表现出'最优路径困惑'(optimal path confusion)。论文Table 1给出了诊断性数据:Qwen3VL-8B在加入工具后工具调用平均只有0.003次/轨迹,几乎完全保持GUI中心化(工具欠用),准确率从29.0%掉到28.2%;而Qwen3VL-235B则走向另一极端,平均调用6.10次工具,准确率反从41.1%掉到38.1%;EvoCUA-32B调用7.49次工具,准确率暴跌12.0%(从52.6%到40.6%);甚至Claude-4.5-Sonnet也下降13.5%。这表明仅把hybrid action space暴露给MLLM并不能带来提升,反而会让模型在'该走GUI还是该切工具'的分叉路口迷路。深层原因有两个:一是高质量的interleaved GUI-Tool轨迹数据极其稀缺(真实工具轨迹收集昂贵且环境脆弱),二是现有监督信号要么是步级模仿(只看单步合理性)要么是最终任务完成奖励(不区分'及时切换工具'与'绕远路的纯GUI')都缺乏轨迹级反馈,无法让模型学到切换能否带来更优路径。
本文的目标是本文的目标是提出一个端到端的Computer Use Agent——ToolCUA——通过两阶段训练范式,使模型学会在hybrid action space中做'最优GUI-Tool路径选择',即动态判断何时继续用GUI、何时切到工具调用,从而形成既高效又可靠的任务执行轨迹。具体目标包括:在OSWorld-MCP基准的feasible任务上达到46.85%准确率(8B规模下SOTA,相对baseline提升约66%),在工具调用合适的任务上提升TIR,在保证成功率的同时缩短ACS(平均完成步数),并通过out-of-distribution验证(未见过的multi_apps Linux任务和Windows桌面任务)证明该能力可泛化。
与已有工作不同的是，本文的独特切入角度是'在hybrid action space下做trajectory-level的GUI-Tool orchestration',而现有工作要么是纯GUI方法(如UI-Tars、EvoCUA、GUI-Owl)缺乏工具能力,要么是简单暴露工具接口却缺乏对切换时机的训练(典型LLM tool-use研究也主要关注single-turn或局部工具选择)。具体来说,作者提出三点原创:(1)Interleaved GUI-Tool Trajectory Scaling Pipeline——不依赖真实工具收集,而是从OpenCUA/ScaleCUA等存量GUI轨迹出发,让MLLM合成工具库并把GUI轨迹改写为混合轨迹,得到10k条合成混合轨迹和5k个critical switching steps;(2)Tool-Bootstrapped GUI RFT两阶段训练范式——先用SFT打基础,再对切换点做单步RL优化;(3)Tool-Efficient Path Reward——把Rtool(工具调用合理性)和Rlength(路径效率)整合到GRPO中,在轨迹层提供反馈,迫使模型'该用工具时用、不该用时不用、用了就走更短路径'。这三者形成闭环,既解决数据稀缺也解决监督信号不足。
核心方法
ToolCUA的整体思路可以概括为'合成数据打底 + 分阶段RL提升'。直觉上,如果让模型在hybrid action space中'自由发挥',它会出现'要么完全不用工具,要么乱用工具'的两极化失败;因此需要在训练信号中同时注入(a)会做工具调用的基本功,(b)在合适时机会切换的判断力,(c)走最短路径的效率观。技术路线分三步:第一步用MLLM(Kimi-K2.5/Claude-4.5-Sonnet)从纯GUI轨迹合成工具库,并把GUI轨迹改写成interleaved GUI-Tool轨迹(10k条)以及切出critical switching steps(5k条);第二步以Qwen3-VL-8B-Instruct为基座,先在Dall上做warmup SFT(3 epoch,8x8 GPU)得到Msft,再在Dcritical上用GRPO做single-turn RL(group size 32, lr 1e-6)得到Mrft;第三步在OSWorld-MCP真实GUI-Tool环境中(约250个Docker沙箱)做Online Agentic RL,使用Tool-Efficient Path Reward(Rtool+Rlength)与DAPO风格的动态过滤,多轮GRPO迭代约25步,得到最终ToolCUA-8B。
核心创新是把'GUI-Tool切换决策'建模为trajectory-level policy learning问题,并通过'合成数据 + 切换点RL + 路径奖励'三位一体的方式解决。区别于已有工作:(1)与GUI-only方法(UI-Tars/EvoCUA)相比,首次在8B规模上系统性地引入结构化工具调用并设计混合训练;(2)与已有hybrid工具系统(multi-agent+API/SDK)相比,不依赖真实工具轨迹收集,而是从存量GUI数据'逆向合成'工具库和混合轨迹(这是pipeline的关键原创);(3)与单步GRPO/模仿学习相比,设计了Rtool(用任务级tb∈{1,-1}标签解耦工具使用与任务成功)和Rlength(相对组均值的步数奖励,使用线性+指数分段函数),专门在轨迹层提供'该不该切换+切了之后路径是否更短'的反馈信号。这种'合成数据驱动的两阶段RL+轨迹级路径奖励'的组合是本文与现有CUA工作最本质的差异。
方法步骤详情
数据合成阶段(Interleaved GUI-Tool Trajectory Scaling Pipeline):输入为OpenCUA(8.5k条/110k步)+ScaleCUA(300条/20k步)+自收集sandbox轨迹(1.2k条/62k步),共10k条/192k步。先按执行质量/任务长度/应用域做过滤和domain balance,保证源分布稳定;然后用MLLM对每条GUI轨迹分析'任务目标+动作序列+密集截图描述',合成候选工具库,工具从单步封装(如chrome_open_settings)到多步复合(如chrome_open_language_settings)分为L0 fine-grained(2,000个)、L1 mid-grained(1,900个)、L2+ coarse-grained(450个)三层,共4,350个唯一工具;接着让MLLM生成功能等价的tool-only轨迹,并对每个tool step用next-state grounding(将工具结果与原GUI轨迹中对应的下一帧截图对齐)+bottom-up merging(合并相邻细粒度步骤)做校验;最后随机将部分tool call替换为对应的GUI动作序列,并把对应工具从可用列表中移除以模拟'部分工具不可用'的现实场景,得到Dall(10k条interleaved轨迹/180k步)和Dcritical(5k个GUI↔Tool切换点)。训练阶段:第一步Warmup SFT用标准交叉熵损失L_SFT=-Σlog πθ(at|st)在Dall上训3 epoch得到Msft;第二步Single-turn RL on Critical Steps用GRPO在Dcritical上(group size 32, lr 1e-6)采样多个候选回答并对切换决策给出奖励,得到Mrft;第三步Online Agentic RL在OSWorld+OSWorld-MCP混合的真实GUI-Tool沙箱(每个任务最大30步)中进行多轮GRPO,奖励函数为R=R_fmt+R_acc+λ·R_tool+β·R_length,其中λ=0.4、β=0.2、Smax=30,Rtool在tb=1且c>0或tb=-1且c=0时取1否则0,Rlength按当前步s与组均步s̄分段线性/指数衰减计算;最后借鉴DAPO做动态过滤,只保留同时含成功和失败样本的rollout组,迭代约25步得到ToolCUA-8B。
技术新颖性
技术新颖性体现在三个层面。第一,数据层面的'逆向合成'思路:已有hybrid工具数据收集方法要么依赖真实环境(昂贵)、要么从代码生成工具(覆盖窄),本文是首次提出'让MLLM从存量GUI轨迹中归纳出工具签名+生成对应的tool trajectory+通过next-state grounding回链到GUI截图'的完整合成流程,并在10k条轨迹规模上验证了可行性;Figure 7的可视化显示合成的4,350个工具在投影空间中按应用域和粒度形成清晰分簇,说明合成工具不是套模板而是真的捕捉到了GUI操作的结构。第二,训练层面的'切换点定向RL':大多数agentic RL在整条轨迹上做稀疏奖励优化,本文创新性地把'GUI↔Tool切换点'单独抽出,用single-turn GRPO做密集监督,这在CUA训练中尚属首次。第三,奖励设计层面,提出两个解耦的轨迹级信号:Rtool用任务级tb标签把'该不该调用工具'和'任务成功与否'解耦(避免模型为了拿Racc而走纯GUI长路径,或为了拿Rtool而乱调工具),Rlength用组内相对步数+分段函数自然鼓励'用工具压缩冗余GUI'。这三个新颖点联合起来,使8B模型在hybrid基准上首次超过同尺寸GUI-Owl-1.5-8B(43.84%)和更强的Gemini-3.1-Pro(41.14%)。
实验结果
主要实验在OSWorld-MCP(feasible tasks,共333个,238个tool-beneficial+95个non-tool-beneficial)上进行,关键发现如下。Table 2主结果:ToolCUA-8B取得46.85% Overall Accuracy,在8B规模上达到SOTA,相对Qwen3-VL-8B-Instruct baseline(28.23%)提升约18.6个百分点(相对+66%),比同尺寸GUI-Owl-1.5-8B(43.84%)高3.0个百分点,并超过Gemini-3.1-Pro(41.14%)和Claude-4-Sonnet(43.54%),与最强Claude-4.5-Sonnet(48.35%)差距不到2%。分项看,在Tool-Beneficial Tasks上ToolCUA达到45.80%(baseline 27.73%,+18.07),TIR从0.00%提升到15.13%,ACS从20.37降到15.11;在Non-Tool-Beneficial Tasks上达到49.47%(baseline 29.47%,+20.00),TIR从29.47%提升到47.37%。Overall TIR从8.41%升到24.32%(+15.91),ACS从19.34降到14.93(-4.41),是所有评测模型中最低的,说明模型既'该用工具就用'也'不该用时不用'。Table 1的诊断对比进一步佐证hybrid训练的价值:ToolCUA是表中唯一在hybrid设置下比pure GUI表现更好的模型(46.8% vs 42.9%,+3.9),其他模型加入工具后准确率全部下降。Figure 5的跨任务泛化显示:baseline在multi_apps/chrome/calculation/impress等多个子任务上低于18.5%,经coldstart RFT后多数提升到30-50%,最终ToolCUA在vs_code上达到94.4%、impress 75.0%、chrome 50.7%,特别是在训练未见的multi_apps OOD任务上从9.8%→18.5%→23.9%。Table 4的跨平台泛化:在WindowsAgentArena(未见过的Windows桌面)上达到33.8%,超过baseline的26.4%(+7.4pp)和Qwen3-VL-235B-A22B(32.1%)。Figure 6的ablation显示两个关键现象:(a)w/o Interleaved data(去掉冷启动直接做online RL)的TIR始终在15%以下、tool calls接近0,说明没有合成数据基础,模型学不到工具调用;(b)w/o Our path reward(用vanilla GRPO替代Rtool+Rlength)的准确率在step 8-11出现明显下跌,最终落后ToolCUA约7个百分点,曲线不稳定,说明轨迹级路径奖励是稳定提升的关键。Table 3的hybrid vs pure GUI对比:pure GUI SFT从29.03%→34.93%、加Agentic RL后到42.05%,而hybrid RFT(38.13%)就已超过pure GUI SFT,完整ToolCUA(46.85%)再高4.8个百分点,验证了hybrid action space提供了更高保真度的训练环境。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| OSWorld-MCP Overall (feasible) | Accuracy (%) | 46.85 | Qwen3-VL-8B-Instruct 28.23 | +18.62 (relative +66%) |
| OSWorld-MCP Tool-Beneficial Tasks | Accuracy (%) | 45.80 | 27.73 | +18.07 |
| OSWorld-MCP Non-Tool-Beneficial Tasks | Accuracy (%) | 49.47 | 29.47 | +20.00 |
| OSWorld-MCP Overall TIR | Tool Invocation Rate (%) | 24.32 | 8.41 | +15.91 |
| OSWorld-MCP Overall ACS | Average Completion Steps | 14.93 | 19.34 | -4.41 (lowest among all models) |
| OSWorld-MCP multi_apps (OOD) | Accuracy (%) | 23.9 | Qwen3-VL-8B-Instruct 9.8 | +14.1 (cross-task generalization) |
| WindowsAgentArena (cross-platform OOD) | Accuracy (%) | 33.8 | Qwen3-VL-8B-Instruct 26.4 | +7.4, also beats Qwen3-VL-235B-A22B 32.1 |
| OSWorld-MCP vs_code | Accuracy (%) | 94.4 | Qwen3-VL-8B-Instruct 57.1 | +37.3 |
| OSWorld-MCP libreoffice_impress | Accuracy (%) | 75.0 | Qwen3-VL-8B-Instruct 46.7 | +28.3 |
局限与改进
局限性可分为作者自述和读者观察两个层面。作者在Appendix A中明确指出四点:(1)合成管道受限于源GUI轨迹的状态帧和应用域覆盖,合成数据的多样性'耦合'于源数据,例如OpenCUA(8.5k)和ScaleCUA(300)的domain imbalance会传递到下游;(2)工具合成质量依赖于MLLM本身的能力,内测中用Qwen3.5-Plus替代Claude-4.5-Sonnet/Kimi-K2.5后生成效率和轨迹质量明显下降,意味着大规模复现需要付费API;(3)合成工具'不绑定具体实现',可扩展但泛化强,真实部署仍依赖工具成熟度与反馈组织方式;(4)评测基准单一,主要在OSWorld-MCP上评估,缺乏更广泛的GUI-Tool协调基准,跨benchmark验证有限。从实验结果本身还可以观察到的局限:第一,TIR虽从8.41%升到24.32%,但在Tool-Beneficial Tasks上仍只有15.13%,远低于Claude-4.5-Sonnet的42.02%,说明在'应该用工具'的判断上还有较大提升空间,模型仍偏保守;第二,合成工具库4,350个工具、19.75个候选/轨迹,但在评测时实际执行的MCP工具主要是LibreOffice和VSCode类,Figure 7虽然显示工具空间按域分散,但评测中GIMP/VLC等域的绝对准确率仍较低(如vlc上baseline+ToolCUA均<35%),表明合成数据对部分长尾应用覆盖不足;第三,Online Agentic RL每个ablation跑约6天、需250个Docker+8x8 GPU训练+4x8 GPU推理,资源门槛高,且只有约25步收敛,后续是否稳定不衰减未充分验证;第四,Critical steps的定义是GUI↔Tool相邻切换点,但论文没有给出这些点的人工评估准确率,合成critical的可靠性有不确定性。
独立分析的弱点
独立分析可以看到四个可改进的弱点。第一,合成工具的'工具签名稳定性'问题:论文提到'synthesized tools are not tied to a specific concrete implementation',虽然带来泛化性,但评测时实际可调用的MCP工具来自OSWorld-MCP(150+真实工具),合成工具与真实工具的schema并不完全一致,这种mismatch可能导致训练-评测gap,改进方向是在合成阶段显式约束工具签名遵循目标环境的schema(如OSWorld-MCP的真实API spec)。第二,Rtool的tb标签是任务级二值(1/-1),粒度较粗,无法区分'该用哪个粒度的工具'(fine vs mid vs coarse),改进方向是引入工具粒度感知的奖励项,或把tb扩展为基于子目标的连续分数。第三,Online RL只用OSWorld单应用任务(不含multi_apps),虽然提升了OOD但也意味着在'多应用协作'上的切换策略只通过合成数据学习,缺少真实环境反馈,改进方向是在multi_apps任务上做有针对性的RL finetune,或设计课程学习从单应用到多应用过渡。第四,Figure 6显示w/o Interleaved data的TIR在训练结束仍只有约15%,说明即使有path reward,仅靠在线RL也学不会工具调用,这从反面证明冷启动数据的质量上限可能决定了模型能力上限,改进方向是引入更多高质量真实工具轨迹(尽管昂贵)或采用self-play式工具合成。
未来方向
作者在Appendix A中提出三个未来方向:(1)扩展hybrid GUI-Tool action space到mobile和web环境,探索不同接口结构下GUI与工具的平衡;(2)构建更轻量、更多样化的hybrid GUI-Tool环境,降低agentic RL对重型sandbox的依赖;(3)研究异步RL框架,解耦训练和推理时rollout,提高长horizon策略优化的可扩展性和稳定性。基于本文成果还可以延伸的方向包括:把Tool-Efficient Path Reward思想迁移到multi-agent CUA(让不同agent共享Rtool+Rlength协同优化);把合成pipeline用于其他domain(如mobile GUI轨迹合成mobile-tool轨迹);探索在更小的模型(1B/3B)上能否保留hybrid能力(论文用8B,理论上pipeline不依赖模型规模);研究'工具调用预算约束'下的动态规划,把每次工具调用视为有cost的决策,引入cost-aware RL;以及把GUI-Tool切换的critical steps作为可解释性窗口,让模型在决策时输出自然语言理由,提升CUA的可调试性和安全性(论文在Broader Impact中也提到部署需要transparent action logging)。
复现评估
复现性方面,论文明确给出代码链接https://github.com/X-PLUG/ToolCUA,数据和训练细节较为充分。开源情况:代码开源,但合成数据(10k条interleaved轨迹+5k个critical steps)未明确声明是否公开release(附录C.2只给出统计:OpenCUA 8.5k/ScaleCUA 300/自收集1.2k→共10k/192k步→合成10k混合/180k步,4,350 unique tools,L0/L1/L2+分别为2,000/1,900/450,平均每轨迹工具池19.75、实际执行7.89)。数据方面,基础GUI轨迹来自OpenCUA和ScaleCUA(已开源),但其中1,200条sandbox收集轨迹为内部数据,外部无法直接获得。算力方面,完整复现需要:8x8 GPU做SFT(3 epoch)+8x8 GPU做single-turn RL+8x8 GPU训练 + 4x8 GPU推理 + 约250个Docker沙箱做online RL(约6天/每个ablation),总计约30+ GPU天和大量分布式环境,门槛较高;另外依赖Kimi-K2.5或Claude-4.5-Sonnet做工具合成(付费API),Qwen3.5-Plus效果明显下降。难度评估:总体复现难度'中高',pipeline各模块定义清晰(Appendix C.5有详细ablation protocol),但需要复现者自建OSWorld-MCP环境、配置verl框架的解耦训练-推理基础设施、设计agent-readable tool return format,且Tool-Efficient Path Reward中超参数λ=0.4、β=0.2、Smax=30的选择和DAPO动态过滤的group保留策略都需仔细调参,否则online RL容易出现Figure 6中的训练曲线震荡。
论文图表
图(a)对比了纯原子GUI动作(CLICK/CLICK/TYPE/SCROLL长链)与GUI-Tool混合动作(CLICK/MCP-based tool call/SCROLL短链),在LibreOffice改一整列颜色的任务中,工具调用用一次libreoffice_set_column_values API即可完成。图(b)柱状图显示ToolCUA-8B在OSWorld-MCP feasible任务上46.85%超越Qwen3.5-397B-A17B(40.84%)、Gemini-3.1-Pro(41.14%)、Claude-4-Sonnet(43.54%)、Qwen3-VL-EvoCUA-32B(40.54%)等,仅次于Claude-4.5-Sonnet(48.35%)。
是论文的'封面图',直观展示hybrid action space的优势和主要benchmark成绩,也是motivation和results两节的核心视觉证据。
概念示意图,展示当hybrid action space同时暴露给agent时,智能体面临'继续走GUI路径'还是'切换到工具路径'的分叉路口,已有模型因为没有切换策略而走错分支,要么完全不动工具、要么乱切换,导致任务失败或路径冗长。
是定义'optimal path confusion'这一核心问题的视觉抽象,与Table 1的数据互为表里,帮助读者理解hybrid action space为什么不是'免费午餐'。
跨平台泛化结果。Qwen3-VL-8B-Instruct 26.4% / Qwen3-VL-32B-Instruct 30.9% / Qwen3-VL-235B-A22B 32.1% / ToolCUA-8B 33.8%。虽然训练完全在Linux沙箱上进行,ToolCUA在未见过的Windows桌面环境上仍超过所有Qwen3-VL系列基线。
是'训练平台≠测试平台'的跨平台泛化证据,证明hybrid action space的orchestration能力不依赖于具体操作系统,具备可迁移性。
四列子图分别展示Test accuracy、TIR、MCP tool calls、Trajectory completion steps随训练步数的变化。三条曲线对比完整ToolCUA、w/o Interleaved data(去掉冷启动RFT,直接online RL)、w/o Our path reward(用vanilla GRPO替代Rtool+Rlength)。w/o Interleaved data的TIR始终<15%、tool calls接近0,accuracy约35-40%;w/o Our path reward的accuracy在step 8-11出现明显下跌,最终落后ToolCUA约7个百分点;完整ToolCUA的accuracy稳定上升,TIR和tool calls逐步增长,trajectory steps有下降趋势。
是论文最关键的ablation图,直接证明'合成数据冷启动'和'Tool-Efficient Path Reward'两个核心组件缺一不可,是method节最有说服力的实验证据。
案例分析:在LibreOffice Calc任务'创建两个pivot table按product和sales channel统计revenue'中,ToolCUA依次调用get_workbook_info、env_info(Sheet1)、switch_active_sheet(Sheet2)、create_pivot_table(PivotTable1)、create_pivot_table(PivotTable2)等工具,用5步完成。分析指出GUI-only方法需要'繁琐且易错'的数据范围选择和菜单导航,而tool调用直接生成pivot table,效率优势明显。
展示'工具替代冗余GUI'的具体执行轨迹,让读者直观感受hybrid编排的实际价值,也是解释为何ToolCUA的ACS最低的关键证据。
案例分析:在VSCode任务'把/home/user/data1和/home/user/data2加入workspace'中,ToolCUA先用osworld_mcp_code.add_folder工具两次添加目录(Step 1-2),然后识别到VSCode弹出'I trust the authors'信任对话框需要GUI操作,切换为computer_use工具的click coordinate [596, 627]点击确认按钮(Step 3),最后terminate status=success(Step 4)。
展示'GUI和Tool在同一任务中无缝切换'的最直接证据:工具完成主要工作,GUI收尾弹窗,完美诠释了orchestration的价值。