讓 AI 操作電腦，通常有兩條路：像人一樣讀取畫面、移動滑鼠與鍵盤；或跳過介面，直接呼叫軟體提供的結構化工具。直覺上，後者既精準又省成本，但最新研究顯示，工具「放在旁邊」不等於模型會用，也不保證用了就更好。真正的瓶頸，已從能否連接工具，轉向何時選用、參數是否正確，以及如何理解執行結果。
從純視覺操作走向 GUI 與 MCP 混合代理
來源事實：研究團隊在 OSWorld-MCP 的 309 項任務上，把同一套 MCP 工具與操作框架交給推理型及非推理型模型。OSWorld 原始基準包含 369 項真實電腦任務，涵蓋網頁、桌面應用程式、檔案操作及跨應用流程，並以執行後的電腦狀態判定是否完成，而非只看模型說自己成功。原研究見 https://arxiv.org/abs/2608.03327；OSWorld 的設計與任務範圍可由其論文交叉確認：https://arxiv.org/abs/2404.07972。
MCP 在這裡不是另一種「看畫面」技術，而是把可用功能以名稱、說明、輸入參數及輸出結構呈現給代理。官方規格所描述的流程是：客戶端先取得工具清單，由模型選擇工具，再送出呼叫並接收結果；工具定義包含名稱、文字說明與 JSON Schema 輸入格式。也就是說，協定解決的是能力如何被發現與呼叫，沒有替模型完成判斷。規格可參考 https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/server/tools.mdx。
同一批工具，為何一加分、一扣分？
來源事實：在其他條件固定、每種設定各跑五次的比較中，推理型模型加入 MCP 後，平均成功率由 30.5%升至 34.5%，增加 4.0 個百分點；非推理型模型卻由 25.4%降至 19.5%，減少 5.9 個百分點，兩項差異均超過兩個標準誤。後者較常忽略工具、捏造工具名稱，或在任務尚未完成時誤判成功。
但研究沒有證明「推理能力」本身造成差異。兩個模型檢查點除了是否輸出推理軌跡，仍可能存在其他差別；作者因此只把工具決策行為與成績方向視為關聯，而非已確立的因果機制。這項保留十分重要：產品團隊不能僅憑模型標示為 reasoning，就假定接上更多工具一定會改善表現。
工具採用落差：可用不等於會選
309 項任務中有 230 項存在可用工具，但推理型模型只在 55 項任務呼叫工具，相當於全部任務的 17.8%、可觸及任務的 23.9%。非推理型模型更低，分別為 10.4%與 13.9%。換言之，主要問題不是 MCP 伺服器沒有提供能力，而是代理沿用已熟悉的截圖路徑，未形成「先判斷哪條路較合適」的穩定策略。
合理推論：這會改變代理產品的設計重心。與其無限制增加工具數量，開發者更需要建立路由層：哪些任務適合結構化操作、哪些步驟必須保留視覺確認，以及在高風險操作前是否應限制模型自由選路。官方 MCP 架構也把權限、授權與跨伺服器協調交由 host 管理，而不是完全交給模型；相關架構說明見 https://modelcontextprotocol.io/specification/2025-06-18/architecture。
獎勵能讓模型多用工具，卻教不會它正確使用
研究以多輪強化學習給予工具呼叫額外獎勵後，試算表任務的工具採用率由 0.03 升至 0.33，且變化延續到貪婪解碼，顯示選擇行為確實可以被訓練。然而，48 項保留任務沒有出現持續的失敗轉成功；七項保留的試算表工具任務，準確率也未高於基準。
更關鍵的診斷是：工具呼叫在 API 層有 98%至 100%的執行成功率，但需要複雜參數的操作可能完全沒有語意效果。正規表示式尋找取代為 0/23 成功，格式轉換為 0/16；伺服器即使回傳成功，也可能只是指令正常執行、實際上沒有改到任何內容。這清楚區分了兩件事：模型能產生合法呼叫，不代表它理解參數與任務狀態。
截圖也是成本與記憶體管理問題
截圖路徑雖然通用，連續保留影像卻會推高輸入 token 與上下文峰值。研究將影像歷史由四張減為兩張，可把累積輸入約降三分之一、峰值上下文降低近四成，但若只在推論時突然套用，準確率會下降 3.9 個百分點。原因不一定是資訊量不足，也可能是模型訓練時從未學過如何在較精簡的觀察條件下工作。
當研究把相同壓縮規則同時用於訓練與部署，選定檢查點只使用原設定 53%的輸入成本，峰值上下文減少 37%；在未納入訓練的 235 項任務上，成績差異為不顯著的正 0.8 個百分點。完整任務集雖達 37.8%，高於未壓縮基準的 33.0%，但約 4.1 個百分點優勢來自 74 項訓練任務，不能解讀成普遍能力提升。
容易忽略的限制
- 這是 arXiv 預印本結果，且模型與框架範圍有限，尚不足以代表所有商用代理。
- 強化學習成功改變工具採用行為，沒有解決保留任務上的工具語意能力。
- 「呼叫成功就丟棄下一張截圖」可能移除錯誤證據；試算表與簡報操作仍可能需要視覺確認。
- 壓縮後的整體增益集中於訓練分布，論文也明確指出未證實跨作業系統的可擴展性。
對台灣導入者的意義
作者觀點：對準備把代理接進 ERP、辦公軟體、客服後台或內部資料系統的台灣企業而言，採購時不應只問「支援多少 MCP 工具」，而應要求供應商提供工具採用率、語意成功率、誤判完成率及單次任務的上下文成本。尤其涉及財務、訂單或文件異動時，API 回傳成功不應直接等同業務結果正確，還需以狀態查詢、視覺確認或既有系統規則進行驗證。
後續最值得追蹤的指標包括：可觸及任務中真正使用工具的比例、工具呼叫後的實際狀態變更率、加入工具前後是否在多次重跑仍穩定改善、壓縮策略在未見任務上的表現，以及成本下降是否以失去錯誤修正訊號為代價。這篇研究最重要的提醒不是「截圖或工具誰勝出」，而是混合代理需要同時學會選路、正確執行與驗證結果；缺少任何一層，更多工具都可能只是更多失敗方式。