別光給Agent加Tool了，它根本選不明白！

復旦×通義團隊 投稿
量子位 | 公眾號 QbitAI

給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 calls或API-based operations往往更高效、更精確。例如在LibreOffice里批量處理表格，GUI-only方案可能需要一串冗長的菜單點擊和參數配置，而工具調用可能一個API就能完成。

看起來最自然的方案，是讓Agent同時擁有GUI和Tool。但實驗發現一個非常反直覺的事實：直接把tools接到強模型上，并不會自動提升性能。

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

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

Tool overuse：模型頻繁調用工具，但調用時機不對、調用粒度不對，反而降低任務成功率。

論文將這個問題定義為optimal GUI-Tool path selection：在長程任務中動態決定何時使用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 path selection，首先需要高質量的interleaved GUI-Tool trajectories。但現實中，這類數據非常稀缺。

真實工具接口往往應用相關、覆蓋不完整，而且維護成本高；而收集真實GUI-Tool混合軌跡又需要復雜的環境接入和人工標注。

已有GUI數據雖然規模很大，但大多是GUI-only trajectories，只教模型如何點擊和輸入，并沒有告訴模型何時應該用工具替代冗長GUI操作。

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

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

整個pipeline可以概括為三個步驟:

1、Trajectory-aware synthetic tool library construction。

對每條GUI軌跡，模型會分析任務目標、動作序列和截圖描述，從真實操作流程中抽象出可調用的工具。

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

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

2、Tool trajectory generation with next-state grounding。

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

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

3、Interleaved GUI-Tool trajectory generation。

最后，系統不會簡單地把所有GUI操作都替換成工具，而是隨機采樣部分工具調用，再替換回對應GUI子序列，形成多種GUI與Tool交錯的軌跡。

這個設計非常關鍵：它讓模型看到不同tool availability下的決策邊界，也自然產生GUI -> Tool和Tool -> GUI的critical switching steps。

最終，ToolCUA的數據中大約包括了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。這一階段的目標，不是直接學完整長程策略，而是先給模型打下一個可用的hybrid foundation。

具體來說，ToolCUA先在D_all上進行warmup SFT，學習多模態工具調用知識，包括工具用途、參數、返回結果，以及工具執行后的狀態變化。

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

這一階段做的事情是：先把interleaved GUI-Tool數據合成出來，再讓模型先學會會用工具和在局部切換點上別選錯。

Online Agentic RL與Tool-Efficient Path Reward

如果說第一階段解決的是模型先要進入hybrid action space，那么第二階段解決的就是：模型如何在真實環境里學會trajectory-level的路徑選擇。

ToolCUA的第二階段是Online Agentic RL。這一步不再只優化單步動作，而是在真實GUI-Tool environment中進行long-horizon rollout，讓模型學習完整任務軌跡上的路徑選擇。

團隊首先構建了同時具備GUI actions和Tool calls的高可用Sandbox用于agentic RL，并且為工具返回結果設計了更加結構化的格式便于模型理解。

Agentic RL優化的核心是Tool-Efficient Path Reward:

其中，R_fmt和R_acc分別是標準格式獎勵與任務成功獎勵；R_tool和R_length則是ToolCUA專門設計的兩項軌跡級獎勵，并且它們只在成功軌跡上激活，避免模型從失敗執行里學到錯誤偏好。

第一項是Tool Appropriateness Reward (R_tool)。

在數據構建時，每個任務會帶一個task-level的tool-beneficial標記：t_b = 1表示這個任務適合用工具，t_b = -1表示這個任務不適合用工具。與此同時，c表示整條軌跡里的tool calls數。

于是，R_tool獎勵的不是工具調用更多，而是更精確的兩種行為:

對于適合工具的任務，成功軌跡里確實調用了工具。

對于不適合工具的任務，成功軌跡里反而沒有亂用工具。

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

第二項是Path Efficiency Reward (R_length)。

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

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

如果更長，就做衰減。

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

所以，這一階段的核心并不是讓模型調用更多工具，而是讓它學會兩件事：什么時候工具真的合適，什么時候這條執行路徑真的更短。

OSWorld-MCP上達到46.85%，相對提升約66%

ToolCUA主要在OSWorld-MCP上評測。這個benchmark在傳統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%。

同時，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 steps，是表中所有模型里最低的。這說明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從baseline的9.8%和pre-online RL stage的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% accuracy，超過Qwen3-VL-8B-Instruct的26.4%、Qwen3-VL-32B-Instruct的30.9%，也超過Qwen3-VL-235B-A22B的32.1%。

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

為什么ToolCUA真正學會了選路

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

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

當去掉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獲得工具知識和切換先驗。

第二，如果沒有Tool-Efficient Path Reward，模型學不會穩定且高效的路徑。

同樣在rl_dynamics里可以看到，去掉R_tool和R_length后，只保留標準的R_acc與R_fmt，accuracy曲線會明顯更不穩定，在訓練step 8-11左右出現下降，最終與完整ToolCUA之間有大約7個點的差距。

與此同時，TIR和tool-calls也沒有穩定上升趨勢，trajectory length也缺少持續下降。

這說明，任務成功獎勵本身不足以教會模型什么時候工具是合適的和什么路徑才是真正高效的。

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

論文進一步比較了pure GUI training和hybrid GUI-Tool 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本身就是一個更高保真的訓練環境。模型不只是學visual grounding，也在這個過程中學會何時應該用結構化工具替代冗余GUI操作。

WindowsAgentArena的結果也說明，這種訓練范式帶來的不是單點收益，而是更強的跨平臺泛化能力。

真正的GUI-Tool協同

為了更直觀地理解ToolCUA的能力，可以看兩個實際案例。

第一個是LibreOffice Calc任務：用戶要求在一個名為Sheet2的新sheet中創建兩個pivot tables，分別統計product和sales channel對應的total revenue。

GUI-only方法通常需要選擇數據范圍、打開菜單、配置字段、確認參數，步驟冗長且容易出錯。

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 space的協同與切換。

Hybrid action training，下一代CUA訓練范式

在agent熱潮的推動下，computer use agent正在更積極地探索真實世界里的落地路徑。

ToolCUA為社區揭示了一個關鍵現象：一旦進入hybrid action space，現有CUA和部分強基座模型會出現明顯的路徑困惑，甚至導致準確率下降。

團隊通過staged training paradigm在hybrid action training上做了一次有益探索，并驗證了這一路線的有效性。

接下來，更值得繼續和推進的方向，是構建更大規模的CUA工具，訓練更大規模的CUA基座模型，讓CUA原生具有hybrid actions的能力，更好地解決人類復雜問題。

項目網站：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