復(fù)旦×通義團(tuán)隊(duì) 投稿
量子位 | 公眾號(hào) QbitAI

給Agent同時(shí)接上GUI操作和工具調(diào)用，準(zhǔn)確率反而下降了。

模型根本不會(huì)在GUI和Tool之間選擇。該點(diǎn)按鈕的時(shí)候去調(diào)API，該調(diào)API的時(shí)候又死磕菜單，兩頭亂竄，越幫越忙。

為應(yīng)對(duì)這一挑戰(zhàn)，復(fù)旦大學(xué)和通義實(shí)驗(yàn)室MobileAgent團(tuán)隊(duì)聯(lián)合提出ToolCUA，一個(gè)面向GUI-Tool混合動(dòng)作空間的Computer Use Agent。

核心目標(biāo)就一個(gè)：讓模型學(xué)會(huì)什么時(shí)候走GUI，什么時(shí)候切Tool，什么時(shí)候不該調(diào)工具。

結(jié)果相當(dāng)能打。

ToolCUA-8B在OSWorld-MCP上拿到46.85%準(zhǔn)確率，超過Claude-4-Sonnet，逼近Claude-4.5-Sonnet。

代碼、模型權(quán)重已全面開源。

混合動(dòng)作空間下的路徑困惑

傳統(tǒng)的CUA主要依賴原子化GUI操作，例如點(diǎn)擊、輸入、拖拽、滾動(dòng)。這類操作泛化性強(qiáng)，只要界面上能看到按鈕，理論上模型就能點(diǎn)；但它也有明顯短板：步驟長、誤差容易累積，在復(fù)雜任務(wù)中很容易出現(xiàn)cascading errors。

相反，tool calls或API-based operations往往更高效、更精確。例如在LibreOffice里批量處理表格，GUI-only方案可能需要一串冗長的菜單點(diǎn)擊和參數(shù)配置，而工具調(diào)用可能一個(gè)API就能完成。

看起來最自然的方案，是讓Agent同時(shí)擁有GUI和Tool。但實(shí)驗(yàn)發(fā)現(xiàn)一個(gè)非常反直覺的事實(shí)：直接把tools接到強(qiáng)模型上，并不會(huì)自動(dòng)提升性能。

在hybrid GUI-Tool action space中，Agent每一步都站在一個(gè)岔路口：左邊是GUI，右邊是Tool。GUI泛化強(qiáng)但慢，Tool快但依賴覆蓋與上下文條件。如果模型缺少路徑選擇能力，就會(huì)出現(xiàn)兩類典型失敗:

Tool underuse：明明有更高效的工具，模型仍然幾乎只走GUI路線。

Tool overuse：模型頻繁調(diào)用工具，但調(diào)用時(shí)機(jī)不對(duì)、調(diào)用粒度不對(duì)，反而降低任務(wù)成功率。

論文將這個(gè)問題定義為optimal GUI-Tool path selection：在長程任務(wù)中動(dòng)態(tài)決定何時(shí)使用GUI actions、何時(shí)調(diào)用tools，從而形成更高效、更可靠的執(zhí)行路徑。

上圖左側(cè)的表格直接給出了這個(gè)反直覺現(xiàn)象：一旦把tools接到強(qiáng)模型上，結(jié)果并不總是更好。

Qwen3VL-8B幾乎不使用工具，平均tool calls只有0.003，準(zhǔn)確率從29.0%降到28.2%；Qwen3VL-235B則明顯更傾向于調(diào)用工具，平均tool calls達(dá)到6.10，步驟數(shù)從25.9降到17.4，但準(zhǔn)確率反而從41.1%降到38.1%。

Claude系列同樣說明了這一點(diǎn)。

Claude-4-sonnet在加入工具后步驟數(shù)從23.6降到19.2，但準(zhǔn)確率從47.7%降到43.5%；Claude-4.5-sonnet的步驟數(shù)從23.3降到19.1，但準(zhǔn)確率從61.9%降到48.4%。

這說明，混合動(dòng)作空間真正難的不是有沒有工具，而是模型在GUI和Tool之間會(huì)不會(huì)選路。

第一階段：數(shù)據(jù)合成與Tool-Bootstrapped RFT

要讓模型學(xué)會(huì)GUI-Tool path selection，首先需要高質(zhì)量的interleaved GUI-Tool trajectories。但現(xiàn)實(shí)中，這類數(shù)據(jù)非常稀缺。

真實(shí)工具接口往往應(yīng)用相關(guān)、覆蓋不完整，而且維護(hù)成本高；而收集真實(shí)GUI-Tool混合軌跡又需要復(fù)雜的環(huán)境接入和人工標(biāo)注。

已有GUI數(shù)據(jù)雖然規(guī)模很大，但大多是GUI-only trajectories，只教模型如何點(diǎn)擊和輸入，并沒有告訴模型何時(shí)應(yīng)該用工具替代冗長GUI操作。

ToolCUA的第一步，就是把這些GUI-only數(shù)據(jù)盤活，并順勢(shì)完成第一階段的hybrid bootstrapping。

論文提出Interleaved GUI-Tool Trajectory Scaling Pipeline：從已有GUI軌跡出發(fā)，利用MLLM合成grounded tool library，再將GUI-only trajectories轉(zhuǎn)換成interleaved GUI-Tool trajectories。

整個(gè)pipeline可以概括為三個(gè)步驟:

1、Trajectory-aware synthetic tool library construction。

對(duì)每條GUI軌跡，模型會(huì)分析任務(wù)目標(biāo)、動(dòng)作序列和截圖描述，從真實(shí)操作流程中抽象出可調(diào)用的工具。

例如從Chrome設(shè)置流程中抽象出chrome_open_language_settings，從LibreOffice表格操作中抽象出讀取工作簿信息、創(chuàng)建透視表等工具。

這些工具不是憑空生成的API模板，而是grounded in concrete trajectory behavior，也就是從真實(shí)GUI行為中抽象出來的工具能力。

2、Tool trajectory generation with next-state grounding。

給定合成工具庫和原始GUI軌跡，MLLM生成一個(gè)功能等價(jià)的tool-only trajectory，并為每一步預(yù)測tool response。

隨后通過next-state grounding，將工具執(zhí)行效果錨定到原始GUI軌跡中的下一幀截圖，驗(yàn)證工具步驟和可見狀態(tài)變化是否一致。

3、Interleaved GUI-Tool trajectory generation。

最后，系統(tǒng)不會(huì)簡單地把所有GUI操作都替換成工具，而是隨機(jī)采樣部分工具調(diào)用，再替換回對(duì)應(yīng)GUI子序列，形成多種GUI與Tool交錯(cuò)的軌跡。

這個(gè)設(shè)計(jì)非常關(guān)鍵：它讓模型看到不同tool availability下的決策邊界，也自然產(chǎn)生GUI -> Tool和Tool -> GUI的critical switching steps。

最終，ToolCUA的數(shù)據(jù)中大約包括了4k個(gè)unique tools，覆蓋fine-grained、mid-grained、coarse-grained多級(jí)粒度，大約有180k steps數(shù)據(jù)用于warmup SFT，還從critical steps中sample出5k條用于single-turn RL。

基于這些數(shù)據(jù)，ToolCUA進(jìn)一步執(zhí)行Tool-Bootstrapped GUI RFT。這一階段的目標(biāo)，不是直接學(xué)完整長程策略，而是先給模型打下一個(gè)可用的hybrid foundation。

具體來說，ToolCUA先在D_all上進(jìn)行warmup SFT，學(xué)習(xí)多模態(tài)工具調(diào)用知識(shí)，包括工具用途、參數(shù)、返回結(jié)果，以及工具執(zhí)行后的狀態(tài)變化。

隨后，模型在D_critical上進(jìn)行single-turn RL，在明確的GUI-Tool switching steps上采樣多個(gè)completion，并通過反饋校準(zhǔn)模型在局部邊界上的選擇。

這一階段做的事情是：先把interleaved GUI-Tool數(shù)據(jù)合成出來，再讓模型先學(xué)會(huì)會(huì)用工具和在局部切換點(diǎn)上別選錯(cuò)。

Online Agentic RL與Tool-Efficient Path Reward

如果說第一階段解決的是模型先要進(jìn)入hybrid action space，那么第二階段解決的就是：模型如何在真實(shí)環(huán)境里學(xué)會(huì)trajectory-level的路徑選擇。

ToolCUA的第二階段是Online Agentic RL。這一步不再只優(yōu)化單步動(dòng)作，而是在真實(shí)GUI-Tool environment中進(jìn)行l(wèi)ong-horizon rollout，讓模型學(xué)習(xí)完整任務(wù)軌跡上的路徑選擇。

團(tuán)隊(duì)首先構(gòu)建了同時(shí)具備GUI actions和Tool calls的高可用Sandbox用于agentic RL，并且為工具返回結(jié)果設(shè)計(jì)了更加結(jié)構(gòu)化的格式便于模型理解。

Agentic RL優(yōu)化的核心是Tool-Efficient Path Reward:

其中，R_fmt和R_acc分別是標(biāo)準(zhǔn)格式獎(jiǎng)勵(lì)與任務(wù)成功獎(jiǎng)勵(lì)；R_tool和R_length則是ToolCUA專門設(shè)計(jì)的兩項(xiàng)軌跡級(jí)獎(jiǎng)勵(lì)，并且它們只在成功軌跡上激活，避免模型從失敗執(zhí)行里學(xué)到錯(cuò)誤偏好。

第一項(xiàng)是Tool Appropriateness Reward (R_tool)。

在數(shù)據(jù)構(gòu)建時(shí)，每個(gè)任務(wù)會(huì)帶一個(gè)task-level的tool-beneficial標(biāo)記：t_b = 1表示這個(gè)任務(wù)適合用工具，t_b = -1表示這個(gè)任務(wù)不適合用工具。與此同時(shí)，c表示整條軌跡里的tool calls數(shù)。

于是，R_tool獎(jiǎng)勵(lì)的不是工具調(diào)用更多，而是更精確的兩種行為:

對(duì)于適合工具的任務(wù)，成功軌跡里確實(shí)調(diào)用了工具。

對(duì)于不適合工具的任務(wù)，成功軌跡里反而沒有亂用工具。

它要解決的正是前面提到的hybrid confusion：有些模型明明該用工具卻不用，有些模型則在不該用的時(shí)候亂用。R_tool的作用，就是把工具是否合適這件事從任務(wù)成功里單獨(dú)拎出來訓(xùn)練。

第二項(xiàng)是Path Efficiency Reward (R_length)。

這里，s是當(dāng)前軌跡的步數(shù)，\bar{s}是同組rollout的平均步長，S_max是最大執(zhí)行步數(shù)。ToolCUA不拿一個(gè)固定閾值來判定長還是短，而是做group-relative comparison:

如果某條成功軌跡比組內(nèi)平均更短，就給線性bonus。

如果更長，就做衰減。

這樣設(shè)計(jì)的好處是，模型會(huì)自然傾向于探索更短的成功路徑。而在很多場景里，更短的路徑恰恰意味著：用一個(gè)高層工具替代一長串冗余GUI操作。因此，R_length本質(zhì)上是在鼓勵(lì)模型發(fā)現(xiàn)更高效的GUI-Tool execution path。

所以，這一階段的核心并不是讓模型調(diào)用更多工具，而是讓它學(xué)會(huì)兩件事：什么時(shí)候工具真的合適，什么時(shí)候這條執(zhí)行路徑真的更短。

OSWorld-MCP上達(dá)到46.85%，相對(duì)提升約66%

ToolCUA主要在OSWorld-MCP上評(píng)測。這個(gè)benchmark在傳統(tǒng)OSWorld的基礎(chǔ)上引入了hybrid GUI-Tool action space，覆蓋典型GUI actions、150+ tools和主流桌面應(yīng)用，適合衡量模型在真實(shí)混合動(dòng)作空間中的執(zhí)行能力。

評(píng)測指標(biāo)包括:

• Accuracy：任務(wù)成功率
• TIR (Tool Invocation Rate)：是否做對(duì)任務(wù)，并且在tool-beneficial tasks中使用工具，并在non-tool-beneficial tasks中避免工具
• ACS (Average Completion Steps)：平均完成步數(shù)，衡量執(zhí)行效率

ToolCUA-8B在OSWorld-MCP上取得46.85% accuracy，相比Qwen3-VL-8B-Instruct baseline的28.23%，相對(duì)提升約66%。

同時(shí)，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%)。

更重要的是效率指標(biāo)。ToolCUA的ACS僅為14.93 steps，是表中所有模型里最低的。這說明ToolCUA不只是完成了更多任務(wù)，也學(xué)會(huì)了用更短路徑完成任務(wù)。

與Qwen3-VL-8B-Instruct相比，ToolCUA的overall TIR從8.41%提升到24.32%，ACS從19.34降到14.93。這說明模型不僅更會(huì)做任務(wù)，也更會(huì)判斷什么時(shí)候應(yīng)該調(diào)用工具。

在訓(xùn)練階段，Online Agentic RL只使用單應(yīng)用Linux任務(wù)，并刻意排除了multi_apps domain，用于OOD驗(yàn)證。

結(jié)果顯示，在held-out multi_apps任務(wù)上，ToolCUA從baseline的9.8%和pre-online RL stage的18.5%提升到23.9%。

在具體應(yīng)用域上，ToolCUA也有明顯提升。例如在libreoffice_calculation上從19.6%提升到34.8%，在vs_code上從66.7%提升到94.4%。

更進(jìn)一步，ToolCUA還在WindowsAgentArena上進(jìn)行評(píng)測。

盡管訓(xùn)練數(shù)據(jù)和sandbox都來自Linux桌面環(huán)境，ToolCUA在unseen Windows desktop apps上達(dá)到33.8% accuracy，超過Qwen3-VL-8B-Instruct的26.4%、Qwen3-VL-32B-Instruct的30.9%，也超過Qwen3-VL-235B-A22B的32.1%。

這說明ToolCUA學(xué)到的并不只是某些特定任務(wù)模板，而是更接近一種可遷移的hybrid action orchestration能力。

為什么ToolCUA真正學(xué)會(huì)了選路

ToolCUA的提升到底來自哪里？論文里的ablation很清楚地給出三條結(jié)論。

第一，如果沒有interleaved GUI-Tool trajectory data，online RL本身學(xué)不會(huì)可靠的tool use。

當(dāng)去掉offline interleaved GUI-Tool bootstrapping，直接從Qwen3-VL-8B-Instruct baseline開始做online agentic RL時(shí)，模型的overall accuracy雖然也會(huì)繼續(xù)上升，但它很難真正學(xué)會(huì)穩(wěn)定的工具調(diào)用行為。

最典型的現(xiàn)象是：TIR長期偏低，訓(xùn)練后期也只到約15%；tool calls在大部分訓(xùn)練過程中都接近0。

這說明，僅靠trajectory-level online reward，并不足以讓一個(gè)GUI-centric base model自然長出靠譜的hybrid switching能力。模型需要先通過interleaved supervision獲得工具知識(shí)和切換先驗(yàn)。

第二，如果沒有Tool-Efficient Path Reward，模型學(xué)不會(huì)穩(wěn)定且高效的路徑。

同樣在rl_dynamics里可以看到，去掉R_tool和R_length后，只保留標(biāo)準(zhǔn)的R_acc與R_fmt，accuracy曲線會(huì)明顯更不穩(wěn)定，在訓(xùn)練step 8-11左右出現(xiàn)下降，最終與完整ToolCUA之間有大約7個(gè)點(diǎn)的差距。

與此同時(shí)，TIR和tool-calls也沒有穩(wěn)定上升趨勢(shì)，trajectory length也缺少持續(xù)下降。

這說明，任務(wù)成功獎(jiǎng)勵(lì)本身不足以教會(huì)模型什么時(shí)候工具是合適的和什么路徑才是真正高效的。

第三，Hybrid GUI-Tool training比pure GUI training更有效。

論文進(jìn)一步比較了pure GUI training和hybrid GUI-Tool training。

GUI-only pipeline從baseline 29.03%提升到SFT后34.93%，再到agentic RL后42.05%；而GUI+Tool pipeline中，RFT已經(jīng)達(dá)到38.13%，完整ToolCUA進(jìn)一步達(dá)到46.85%。

這表明hybrid GUI-Tool action space本身就是一個(gè)更高保真的訓(xùn)練環(huán)境。模型不只是學(xué)visual grounding，也在這個(gè)過程中學(xué)會(huì)何時(shí)應(yīng)該用結(jié)構(gòu)化工具替代冗余GUI操作。

WindowsAgentArena的結(jié)果也說明，這種訓(xùn)練范式帶來的不是單點(diǎn)收益，而是更強(qiáng)的跨平臺(tái)泛化能力。

真正的GUI-Tool協(xié)同

為了更直觀地理解ToolCUA的能力，可以看兩個(gè)實(shí)際案例。

第一個(gè)是LibreOffice Calc任務(wù)：用戶要求在一個(gè)名為Sheet2的新sheet中創(chuàng)建兩個(gè)pivot tables，分別統(tǒng)計(jì)product和sales channel對(duì)應(yīng)的total revenue。

GUI-only方法通常需要選擇數(shù)據(jù)范圍、打開菜單、配置字段、確認(rèn)參數(shù)，步驟冗長且容易出錯(cuò)。

ToolCUA則先調(diào)用工具讀取workbook信息和sheet內(nèi)容，識(shí)別數(shù)據(jù)結(jié)構(gòu)與字段位置，然后直接調(diào)用create_pivot_table生成透視表。

這個(gè)案例展示的不是工具永遠(yuǎn)比GUI好，而是: 當(dāng)任務(wù)核心是結(jié)構(gòu)化表格操作時(shí)，Tool可以繞過脆弱的逐步GUI導(dǎo)航，用更確定的方式完成任務(wù)。

第二個(gè)案例來自VS Code。任務(wù)是將/home/user/data1和/home/user/data2兩個(gè)文件夾加入當(dāng)前workspace。

ToolCUA先連續(xù)調(diào)用add_folder工具，把兩個(gè)目錄加入VS Code workspace。

這一步非常適合工具調(diào)用，因?yàn)槁窂矫鞔_、操作結(jié)構(gòu)化、目標(biāo)可驗(yàn)證。

但工具調(diào)用完成后，VS Code彈出了Do you trust the authors?的信任確認(rèn)對(duì)話框。

這個(gè)狀態(tài)不是簡單tool call就能閉環(huán)的。

此時(shí)ToolCUA切換回GUI action，點(diǎn)擊Yes, I trust the authors。

完成界面上的最后一步。

這正是ToolCUA想解決的問題：它不是試圖用Tool替代所有GUI，也不是退回純GUI操作，而是在真實(shí)環(huán)境里學(xué)習(xí)兩種action space的協(xié)同與切換。

Hybrid action training，下一代CUA訓(xùn)練范式

在agent熱潮的推動(dòng)下，computer use agent正在更積極地探索真實(shí)世界里的落地路徑。

ToolCUA為社區(qū)揭示了一個(gè)關(guān)鍵現(xiàn)象：一旦進(jìn)入hybrid action space，現(xiàn)有CUA和部分強(qiáng)基座模型會(huì)出現(xiàn)明顯的路徑困惑，甚至導(dǎo)致準(zhǔn)確率下降。

團(tuán)隊(duì)通過staged training paradigm在hybrid action training上做了一次有益探索，并驗(yàn)證了這一路線的有效性。

接下來，更值得繼續(xù)和推進(jìn)的方向，是構(gòu)建更大規(guī)模的CUA工具，訓(xùn)練更大規(guī)模的CUA基座模型，讓CUA原生具有hybrid actions的能力，更好地解決人類復(fù)雜問題。

項(xiàng)目網(wǎng)站：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