OpenGCUA 解析：少了 53% 步數，電腦 Agent 就更可靠嗎？（2026）

2026 年 10 月 15 日，阿里巴巴 Alibaba Token Hub 的 MAI-UI 團隊在 arXiv 提交了〈OpenGCUA: Toward a Fully Open Stack for Generalist Computer Use〉。這篇 OpenGCUA 解析想追問：同一個模型換一套操作方式，就能少走許多步；但少走的，是與模型往返的回合，還是完成工作所需的時間？

先看作者改了什麼，再拆開評測分數，最後判斷這些結果如何影響你的選用與驗收。系統設計能放大既有模型的能力，但一次程式做更多事，也讓「這一步到底做對了什麼」更值得查清楚。

OpenGCUA 解析：從會點滑鼠，走向會選擇操作方法

Computer-use agent 是會操作電腦的代理。圖形介面（GUI）讓它看畫面、點按鈕；命令列（CLI）、應用程式介面（API）與輔助使用樹，則提供另一種取得狀態與下指令的方法。輔助使用樹可以把介面元素的角色、名稱與狀態變成結構化資料，讓程式有機會直接找到目標。

OpenGCUA 把重點放在模型每一回合的三種選擇：需要看什麼、用什麼方法做，以及如何保存進度。它研究的兩項設計，是把操作寫成可執行程式，以及把部分觀察與任務狀態決策交給模型。Agent Harness 入門可以先補上「模型之外，誰負責執行與回傳結果」這一層。

想像你要替一批文件加上日期。逐次點按，可能每完成一格就要把畫面送回模型；預先列出一串動作，可以少些往返，但遇到意外視窗時，後面的動作可能已經排錯。可執行程式則能先讀取結果，再決定繼續、重試或停下。這個例子說明的是控制方式的差別，並非本文實測。

因此，關鍵問題不只是工具清單長不長，而是下一個動作能否根據剛剛發生的事改變。一次輸出可以承載更完整的程序，模型也必須把檢查與停止條件寫得足夠明確。

這次開放了什麼：研究預覽，與下一版計畫分開看

The release does not yet include a trained model.

中文：這次發布尚未包含一個訓練完成的模型。

OpenGCUA 論文 v1，Introduction

這句話界定了新聞的性質：作者用既有模型研究系統設計，並將 GCUA 模型列為後續方向。目前可核對的官方程式庫列出 OSWorld 整合範例、八個模型的評測軌跡，以及初步的 macOS harness 與跨裝置 SDK。這些材料讓研究者可以追查操作路徑；「完整開放堆疊」仍包含要繼續完成的工作。

對一般使用者，開放程式不等於下載後就能放心交付任何工作。對研究者，價值則很具體：你可以問某一次提升究竟來自取得新工具、執行方式，還是觀察與上下文管理。可拆開的證據，比一支剪輯完成的展示更適合回答這個問題。

OpenGCUA 解析評測：19.6 分與 53%，各自量了什麼？

作者在 OSWorld-v2 v2.1 的 82 題離線子集比較八個模型。對照組是已能批次操作的 GUI-only 配置，完整 OpenGCUA 配置則加入程式執行與相關工作流設計。論文報告，跨模型平均 partial score 從 45.3 升至 64.9，增加 19.6 分；每題步數的相對降幅先在各模型內計算，再平均為 53.0%。這些都是作者在該設定下的觀察，AlphaLab 未執行這套模型評測。

Each step is one model call

中文：每一步是一次模型呼叫。

OpenGCUA 論文 v1，Efficiency as a First-Class Metric；節錄

這個定義很重要。一回合程式可以包含好幾次點按、迴圈與檔案讀寫。因此 53% 衡量的是模型往返回合的減少，不能直接改成滑鼠動作減少 53%、完成時間縮短 53%，或帳單下降 53%。把數十個動作裝進一回合，呼叫數確實變少；那段程式仍然需要執行，也可能花時間等待。

分數也要拆開。OSWorld 原始研究的評測設計分別處理完整完成與部分得分。partial score 可以給未全部完成的任務部分分數；64.9 分不表示 64.9% 的工作已完整交付。想把這個差別用在自己的評測，可讀 AI Evals 入門。

這張成績單足以支持一個有邊界的判斷：在作者設定的離線工作與對照配置裡，系統設計值得重視。它並未直接測出你每天的郵件、網站與帳號流程會改善多少；挑選比較對象時，應先看是否同題、同版本、同工具權限，再看名次。

最有意思的機制：一次做更多事，也要更清楚何時驗收

單看完整配置，難以把改善全部歸因於某一個零件。論文也安排了 GUI、GUI＋CLI 與程式執行的拆組對照。這讓「多開一個命令列工具」與「把多種操作放進同一段可分支的程序」成為兩個可分開問的問題。

接著是觀察。作者的按需截圖機制，讓模型決定下一次輸入是否需要新畫面；環境仍會在每一步留下截圖紀錄。減少送進模型的圖片，與停止記錄操作，是兩件事。若任務只是檔案計算，文字結果可能已經足夠；若剛改了版面，視覺核對就可能有不可替代的資訊。

進度也一樣。模型把狀態寫成 claimed_verified，只表示它宣稱已查驗。該狀態需要對得上實際產物與獨立檢查。AgentSWE 的交付評測從另一個問題切入：漂亮的完成報告，能否對回最後交出的版本？

假設代理說「所有欄位已填完」，好的下一步是逐一檢查必要欄位、保存後重新打開檔案，並核對原始內容是否被意外改動。這些條件由需求決定，不能只由剛寫完程式的代理自行挑選。一次程序做越多事，完整記錄與外部驗收就越有價值。

真實 Mac 的觀察：可以暴露問題，還不足以替所有工作排名

報告另列四項 macOS 工作：試算表、PDF 填表、購物研究與旅館比較。這一部分使用初步 real-device harness，主表採每個任務選定的一次執行；作者也把若干較早的案例與主表區分。適合把它當作具體失敗機制的線索，不能把四題成績換成廣泛工作可靠率。

真實桌面的難處，很容易被乾淨示範藏起來。使用者切換視窗後，桌面截圖可能不是代理想查的頁面；上一秒的座標，也可能已被另一個視窗蓋住。選定某個分頁來觀察、對指定資源下指令，才有機會把目標綁得更清楚。

跨裝置介面可以統一呼叫方式，但各平台能做的事情與權限仍要逐項核對。能讀到背景視窗，不能直接推論所有操作都能在背景完成。若你關心的是「實際交給助手後，哪些資料會離開裝置、如何中止」，Atticus 的本機、雲端與撤權教學提供另一種以使用流程觀察責任邊界的方式。

AlphaLab 的判讀：我同意系統設計值得升級，存疑的是把省回合當成可靠度

一、我同意：比較模型之前，先把操作空間說清楚

如果一組只能點畫面，另一組能直接讀檔、查結構化狀態與執行計算，分數反映的是模型與工具共同形成的系統。這樣比較很有實用價值，前提是清楚交代各組得到了什麼。採購時，你真正買下的是整條可運作的流程；研究模型能力時，則需要把工具差異拆開。

二、我存疑：把決策交給模型，會在哪裡失去可見性？

少送一張畫面，可以省去重複資訊，也可能錯過需要重新確認的變動。這個取捨要靠任務證據回答。系統可以允許模型選擇觀察時機，同時讓不可省略的檢查留在執行層：例如寫入前核對目標、送出前確認範圍，以及保存後檢驗檔案。這些是採用時應設計的要求，不是本篇已驗證 OpenGCUA 全部具備的保障。

三、回合數、成本與完成率，應各有一張收據

最少回合的程序，可能把大量工作塞進一次長輸出；便宜的模型，也可能在失敗後需要更多人工補救。把「每次嘗試花多少」改成「每份合格交付共花多少」，才會把重試、檢查與修補算進來。時間則從收到任務量到合格產物，不只記 API 回應速度。

四、開放軌跡的價值，在於讓別人找到反例

可檢視的失敗路徑，能幫你判斷漏欄位、目標選錯與自稱完成究竟在哪裡發生。下一份更有說服力的證據，會是不同團隊在固定條件下重跑，再用新的工作檢查效果是否保留。論文作者所屬團隊也在推進自家系統與後續模型；這是要求可重跑對照的理由，並不是否定結果的理由。

下一步：挑一件可復原的工作，把「完成」寫成可檢查條件

想理解這條路線，先從 官方評測軌跡挑一題，對照最初需求、程式做過的事、最後產物與評分。不要只看最後一句「完成」。若要自行試用，先用假資料與副本，將讀取、修改、送出分成不同驗收點；外部傳送與帳號操作先保留明確授權。

你可以準備一個含缺漏欄位的小文件，要求代理整理成新檔，並明列哪些內容必須保留。記下完整完成與否、總耗時、實際用量，以及你補救了多久。下一次改設定時，保持考題與驗收條件相同。建立 Agent Harness 的教學可以補上這些紀錄要放在哪裡。

OpenGCUA 值得關注的，是讓電腦操作的設計可以被拆開研究。省下回合是工程進展；當每一步都能指回正確目標、每份交付都能通過需求檢查，才開始接近你願意放心委託的工作。