# Agent 現在能使用電腦了嗎？我們有資料了 > 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt) > 原作者：Fabrizio Serafini (@fabrisera2000) · 策展與摘要：EasyVibeCoding · 平台：X (Twitter) · 熱度：🔥 · 日期：2026-08-12 > 原始來源：https://x.com/fabrisera2000/status/2086831520824934589 ## 證據與延伸閱讀 - [Agent 現在能使用電腦了嗎？我們有資料了](https://x.com/fabrisera2000/status/2086831520824934589) — 一手來源 - [OSWorld-Verified 基準最高達 85%](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/cf4b86f64519b275.jpg) - [推論成本每小時 6-8 美元且具 70-80% 毛利](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/eebc8bba1ec3467b.jpg) ## 中文摘要 # Agent 現在能使用電腦了嗎？我們有資料了 這件事看似顯而易見，但如果你離開矽谷，走進世界其他地方，告訴人們：「有一種東西叫作 Agent，它們相當聰明，可以和你一起完成工作，也能自動化部分重複性的工作內容。」那麼你很可能收到的第一個問題就是：「它們能使用電腦嗎？」 這是個好問題！它們真的做得到嗎？我們未來幾十年要在實體經濟中解鎖的長期生產力潛力，會貫穿許多非常日常的工作：Agent 能不能（用比喻的方式）一天 24 小時、每週 7 天坐在辦公桌前，可靠地使用網頁瀏覽器、填寫表單、點擊正確按鈕，而且不犯錯？這正是 Business Process Outsourcing（BPO，商業流程外包）的領域。過去 BPO 問的是「這項工作能不能外包？」如今則出現了全新的 Agentic 前沿。我們去年曾寫過這個主題，當時 computer use 領域大多還只是各種展示。從那之後，發生了很多事。 模型進步的速度，比幾乎所有人的預期都快。使用電腦的 Agent 開始能在大規模正式環境，以及範圍狹窄、可重複的工作流程中穩定運作：更新系統中的正式記錄、透過入口網站搬移資料、處理工單、核對記錄，以及處理那些沒有乾淨 API 的軟體長尾。只要搭配適當的基礎架構，如今 computer-use 能力已經可以部署，用來大規模處理端到端任務；過去這些任務不是需要人類監督，就是必須由人類親自完成。 現階段，運用 computer-use 的工作流程遠稱不上完美：當工作偏離 runbook 時，Agent 仍然很脆弱；而對某些快取難以實作的使用情境（後文會詳述）來說，成本也高到不一定划算。但我們已經看到它們被部署在正式環境中，處理標準化的後勤工作，尤其是那些原本必須由人員手動點擊老舊系統的工作。考量到運用 computer-use 的工作流程具備 24/7 可用性，以及最重要的、能隨需求擴展的結構性優勢，成本曲線開始顯得相當有吸引力。 第一波 computer-use 基礎架構的重點，是讓 Agent 具備能力：看見畫面、點擊、輸入，以及從錯誤中恢復。下一波的重點，則是讓它們能在真實企業中發揮作用。當原始的 UI 導覽逐漸成為模型層的商品化能力，模型就不再是主要瓶頸，持久性的優勢也會往技術堆疊上層移動：context、權限、流程知識、驗證、升級處理、錯誤處理、快取，以及真正理解某個特定客戶組織如何完成工作的實戰知識，並據此映射出端到端的工作流程。換句話說，前沿問題正從「Agent 能使用電腦嗎？」轉向「它能可靠地完成這項工作嗎？」 # 從人類監看每個步驟，到真正自主的工作流程 ![Claude Fable 5 以 85% 的 OSWorld-Verified 得分位居榜首，展現電腦使用效能在一年間從約 42% 提升至 85%。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/cf4b86f64519b275.jpg)
展開數據表
項目數值
Claude Sonnet 3.728
OpenAI Operator38.1
Claude Sonnet 442.2
OpenAI GPT-5.247.3
Claude Sonnet 4.561.4
Claude Opus 4.566.3
Claude Opus 4.672.7
OpenAI GPT-5.475
Claude Opus 4.778
OpenAI GPT-5.578.7
Claude Opus 4.883.4
Claude Fable 585
Human Baseline~72%
一年前，最強的 computer-use 模型在 OSWorld-Verified 上的分數是 42%；如今最好的模型已達 85%，高於人類在相同任務上約 72% 的表現（也就是說，它成功完成了 100 項任務中的 85 項）。在正式環境中，這些通用前沿模型的運作方式，和它們在基準測試中的方式很相似：各個實驗室透過 API 暴露 computer use 能力——模型取得螢幕截圖，回傳點擊與鍵盤輸入；OpenAI 的 CUA 還會在可用時加入無障礙樹或 DOM 資料——接著，開發者會把這個迴圈包裝在自己的 harness 中：一個沙盒化的 VM 或瀏覽器，再加上周邊的協調、驗證與重試邏輯。幾乎沒有人會為此部署消費者產品（例如 Claude、ChatGPT agent mode）；創辦人與企業通常是直接建構在原始 API 之上，或向提供封裝服務的供應商購買。能力上的躍升，正是讓這些架構變得可行的關鍵。正如一位在這個領域創業的創辦人所說：「直到 2026 年 2 月的 Opus 4.6 之前，模型本身都還不夠好，無法獨立在正式環境中使用。」在過去十八個月的某個時間點，computer use 能力從展示跨越到了可以在現場部署。 當然，基準測試不一定是評估實際部署可行性的最佳代理指標。OSWorld 計算的是完成的任務數，因此 85% 仍然代表 100 項中有 15 項失敗；而商業流程必須每個步驟都完成，整體流程才算成功。後勤工作不會依照常態分佈給分：如果每個輸出都要由人員審查，那就沒有節省任何人力。（這和目前程式撰寫領域發生的事情類似：稀缺資源不再是撰寫程式碼，而是替程式碼背書。） 我們發現，理解真正重要的因素，最好的方式是超越基準測試，聚焦在核心問題上：一項商業流程能不能透過 computer-use 能力可靠地自動化？從這個角度來看，差異最大的其實是模型周邊的一切——也就是當零售商入口網站一夜之間改變版面時，如何進行驗證、升級處理，以及錯誤處理。 也許最明顯的訊號是：我們訪談過的一位營運人員，每月執行數百萬項自動化任務，卻說不出究竟是哪個模型在執行這些任務；他根本不需要知道。供應商會像雲端服務供應商更換硬體一樣，在底層替他更換模型。但他確實信任使用電腦的 Agent 來執行這些任務。簡單說，當最重度的使用者不再查看排行榜時，排行榜就已經不再是重點。 因此，上面的圖表解釋了為什麼 2026 年會有正式環境部署，而 2024 年還沒有。接下來，真正決定這些部署能否運作的，就是其他所有事情——而這也是本文其餘內容要討論的主題。 # Agent 擅長遵循協定 我們和多個在正式環境中執行 computer-use 工作流程的團隊進行了交流，從他們的經驗中得知，遵循協定的任務表現最好。不出所料，當工作流程變得更複雜、準確性也更難驗證時，使用電腦的 Agent 就容易失敗。整體而言，使用電腦的 Agent 最擅長的是標準化、可重複，而且具備清楚明確路徑的任務。真正被解鎖的是那些沒有乾淨 API 的軟體長尾；否則，人員就只能手動點擊 UI 來完成工作。實際上的工作包括：更新 CRM 中的記錄、QA、登入政府與保險入口網站、從資料庫與法規頁面擷取資料、處理零售訂單、處理合約，或在 ServiceNow 中處理 IT 工單。 我們認為，使用者的實際聲音，比任何理論都更能說明這件事。以下是幾個例子：一家 CPG 資料平台向我們說明，他們每月執行約 1,500 萬至 2,000 萬次自動化入口網站互動，並將 Agent 作為手寫 scraper 的自我修復備援方案。當零售商入口網站變更 UI 時，Agent 會診斷故障、修復自動化流程，讓資料持續流動，甚至在人類工程師看到錯誤之前就完成處理。他們告訴我們，導入之後，負責維護 scraper 的工程團隊人數減半，並將釋出的員額重新分配到其他工作流程。另一個案例來自一家全球系統整合商：我們得知，他們目前有 27 個運作中的工作流程使用 computer use Agent，每天處理約 1,500 至 2,100 張 IT 工單；最終目標是將低利潤託管服務合約中的 20% 至 25% 人力重新部署到其他工作。最後，一家代理商向我們展示了他們如何將招募流程端到端自動化：候選人面試結束後，立即把資料填入求職者追蹤平台。為了完成這件事，他們使用的是便宜的非前沿模型，因為它「已經能完成我們需要的一切，而且做得很好」。 最清楚的模式是：理論上，computer-use Agent 能夠操作電腦並解決任務，但實際上要嘛沒有明確的「什麼才算做好」（也就是難以評估），要嘛沒有可靠的方法判斷任務是否成功。通常，以下兩種情況很快就會產生問題： 1. 你無法交叉核對輸出——例如讓 Agent 從合約中擷取付款條件，並填入 ERP。如果它把「net 60」讀成「net 30」，這筆記錄看起來完全合理，也能通過所有視覺檢查，直到錯誤的發票寄出之前，都沒有人會發現。 2. 在某些情況下，任務執行當下根本沒有可用來驗證成功的訊號——例如讓 Agent 在保險入口網站提交理賠申請：申請順利送出，畫面顯示「已收到」，任務完成。但兩天後，理賠人員打電話到辦公室，表示在處理理賠前需要確認保單號碼。負責提交理賠申請的人類會接起電話，三十秒內就能處理完；Agent 不知道這通電話曾經發生，理賠申請就這樣悄悄卡住。更聰明的模型無法解決「真實結果要到一週後才透過某人辦公桌上的一通電話出現」的流程問題，除非 harness 從一開始就設計成能處理這種邊緣情況。 # 買方在意的是基礎架構 對我們訪談的買方來說，模型本身很少是決定性因素，因為「現在的模型已經夠好了」。實際上，他們評估並付費的是模型周邊的一切：能在大規模環境中可靠執行、通過安全性審查，以及證明 ROI 的基礎架構。使用者不在乎解決方案是否採用某個特定的前沿模型；他們在意的是，這個方案能不能在大規模環境中可靠地真正完成任務。就這麼簡單。 因此，失敗模式比任何基準測試都更重要；而且從一開始就必須把失敗設計成一等公民，因為無法妥善處理失敗的解決方案，永遠不會在正式環境中被採用。我們在實務上看到的一個例子，也是多次遇到的一種模式是：Agent 先執行一次工作流程，系統將它快取成確定性程式碼；從此之後，每次執行都改用便宜、可重複的程式碼，只有在流程出現問題時，模型才會再次介入——診斷問題、修復流程，然後重新快取。透過這種方法，單次執行成本會隨著工作流程的生命週期逐漸下降，而更便宜的模型只會進一步降低帳單。這種方法有趣的地方，在於它如何處理不確定性。過去，確定性程式碼只會直接失敗，或是每次出錯都必須由人員審查與修復；在這裡，Agent 會自行吸收這些不確定性。這是一種設計來面對失敗的方法，也顯示出買方真正願意獎勵、並大規模採用的能力。 在我們訪談的使用者中，沒有遇到更複雜的使用案例，這表示市場仍在逐步處理容易取得的成果。不過，在必須面對更困難的任務之前，還有一長串工作流程可以用這種方式自動化。 # 模型不是差異化因素，context 才是 對創辦人而言，更重要的轉變在於：哪些東西正在商品化。過去，打造使用電腦的 Agent，意味著要和 Selenium 或 Playwright 搏鬥，或是近來使用 Stagehand，並將 DOM 或影片錄製串接起來，以擷取工作流程。如今，整個執行層都正在被抽象化，就像 Claude Code 將程式開發 Agent 周邊的鷹架抽象化一樣。如果點擊正確按鈕不再是困難的部分，那它就不再是護城河。 不出所料，工作流程的 context 與知識才是持久的。困難不在於 Agent 能不能導覽 SAP 畫面，而在於它是否理解某家公司實際上如何完成工作：其中的內部經驗、內部術語、偏好的格式、該在什麼時候升級給誰、如何處理失敗，以及如何可靠地驗證輸出。實務上，這些 context 存在於 runbook、存取權限與憑證、測試案例，以及工作流程偏離預定腳本時所使用的護欄中；而且越來越多時候，只要一段某人完成一次工作的錄影就足以提供這些資訊。這些內容沒有任何一部分是通用的，全部都與公司有關，而且往往還與某個團隊特別相關。不過，這正是專注的初創公司通常比模型供應商更擅長解決的那種具體、樸實又不光鮮的問題。因此，我們認為下一代 Agentic 同事會建立在應用程式與 context 層，而不是模型層。 我們訪談的買方明確證實了這一點。他們挑選供應商時，會看產品能否在不增加額外工作的情況下回報節省了多少工時，以及初階工程師能否操作這套產品。現階段，護城河不是前沿能力，而是成為一家企業被允許、也有能力在正式環境中大規模使用的供應商。 # 真正的轉折點在經濟性，而不只是技術 ![Computer-Use Agent 的每小時典型成本為 6 至 8 美元，與海外 BPO（約 10 美元）約略打平，並顯著低於美國後勤人力（30 至 45 美元）。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/eebc8bba1ec3467b.jpg)
展開數據表
Typical (USD)Observed Range (USD)Text Label
Computer-Use Agent (Inference)6-83-15$6–8 typical ($3–15 range)
Offshore BPO (India, Fully Loaded)108-15~$10 ($8–15)
US Back-Office (Fully Loaded)36.5-39.530-45$30–45 fully loaded
成本資料同樣令人鼓舞。請把上面的數字視為數量級估算，而不是精確報價。如今執行 Agent 的推論成本大約是每小時 6 至 8 美元，但實際範圍可能落在 3 至 15 美元之間，取決於 harness 的建構方式——多久截一次螢幕截圖、攜帶多少 context，以及有多少工作可以交給確定性程式碼處理。這些數字描述的是使用前沿模型，讓 Agent 一張接一張螢幕截圖地操作 UI 的情況——也就是最昂貴的模式。設計良好的 harness 會只在真正需要時才使用這種模式，並讓便宜的確定性程式碼處理可重複的部分。不是每個工作流程都能用這種方式最佳化，但能夠最佳化的情況，混合成本會快速下降。因此，這項比較應該視為最壞情況；即便如此，Agent 相較於完整計算後每小時約 10 美元的離岸 BPO，成本也大致打平；相較於每小時約 30 至 45 美元的美國後勤人力，則可達到 70% 至 80% 的毛利。到了正式環境中，harness 對實際成本的影響，和模型本身一樣大。 速度方面也有同樣的前提。在 Agentic 模式下，Agent 仍然比人類慢，而且差距不小——人類兩到三分鐘完成的任務，Agent 可能需要八到十分鐘；學術基準測試顯示的差距甚至更大。確定性執行則相反：程式碼的執行速度比任何人類都快。但對 Agentic 工作而言，重點不是速度，而是 Agent 能全天候運作、成本只是美國人力的一小部分，而且不需要透過招募人員來擴大規模。 這種比較適用於 BPO 買方與營運團隊；但如果你是銷售 Agent 工時的一方，單位經濟性就不同了，因為在真實環境中，成本較難預測。COGS 包括推論與重試成本（也就是說，失敗的執行仍然會消耗 token）；當 context 增長或螢幕截圖頻率提高時，利潤也會被壓縮。供應商會依照任務、工時或結果定價，而每種方式根據工作流程的變異程度，都有不同的風險特性。此外，還有監控、維護與人工升級處理等實務成本；這些成本也會被計入價格，就像使用人力時一樣。目前還沒有適用所有情況的商業模式，答案會因垂直領域而異。 而且，經濟性只會越來越好——推論成本持續下降，開放原始碼模型也已經足以處理越來越多這類工作流程。對於 Agent 能可靠解決的任何任務而言，嵌入 computer-use 能力很可能會比使用人力方便得多。因此，真正的問題已經不再是經濟性是否成立，而是能可靠解決的任務集合究竟能擴展到多遠；接下來的發展方向也正是如此。 # 接下來要往哪裡走？ 過去一年，實驗室與一波初創公司已投入數億美元，打造 computer-use 的 RL 環境——也就是讓模型練習真實任務，並因完成任務而獲得獎勵的沙盒。Mechanize、Habitat、Fleet、Chakra、Deeptune、Matrices 與 Originator 等公司，正在前沿模型底層建立訓練與評估基礎。這些投入所帶來的成果，會呈現為更好的推理能力、更好的狀態追蹤，以及對行為異常應用程式更高的容忍度。模型在正式環境中仍然需要經過謹慎的 harness，才能穩定運作——執行結果快取就是最明顯的例子——但原始能力已經透過這些訓練基礎架構被刻意買下來，而且只會隨時間持續進步。 不過，架構是另一回事。目前大多數部署在正式環境中的 computer-use 系統，都是單一 Agent：一個模型、一項任務、一次工作階段。隨著工作流程變得更複雜，延遲成為限制，多 Agent 架構開始變得重要。例如，由 planner 拆解工作流程，executor Agent 平行處理子任務；而長時間執行的 Agent 又會帶來自己的問題：記憶、信任，以及會隨時間累積的失敗率。目前在這方面做有趣工作的團隊，都在打造客製化的協調機制，因為標準框架尚不存在。Claude Code 的類比很有啟發性：當程式開發 Agent 成熟後，一個鷹架層便出現，用來將協調機制抽象化。同樣的事情很可能也會發生在運用 computer-use 能力的工作流程上，而這個抽象層正是該領域中最有趣、尚未解決的基礎架構問題之一。 從這裡開始，未來的發展會沿著三條路線前進：準確性、延遲與成本。準確性最重要；正如我們上文所說，這代表著炫酷展示與真正解決問題之間的差異——能夠捕捉異常、檢查自己的工作，並且只在真正需要時才升級處理。延遲則是最可能讓人感到意外的部分：有些團隊目前已經改用以無障礙樹為基礎，而不是依賴螢幕截圖，來降低延遲。Standard Intelligence 的通用電腦操作模型，是以 1,100 萬小時、每秒 30 個畫面的影片資料集訓練而成；這初步顯示，讓目前 Agent 變慢的逐步螢幕截圖迴圈，是可以解決的問題，而不是永久存在的成本。隨著推論變得更便宜，以及更小型的非前沿模型接手例行點擊，成本也會持續下降。除了這三個方向之外，還有安全性與治理問題（例如憑證、稽核記錄、資料保留、prompt injection，以及責任歸屬與權限管理）。 企業目前已經能夠、也確實正在從 computer-use Agent 中受益，前提是使用在高流量、步驟重複、商業規則穩定，但介面老舊或缺少 API 的狹窄工作流程上。現階段，它們最適合處理那些具備即時、可由機器觀察的成功證據，失敗後果可以接受，且有清楚升級路徑的任務。不過，隨著上述發展持續推進，相關改進是真實且快速的，使用電腦的 Agent 將能更適合更多類型的工作。 只能說——computer-use 能力的未來一片光明！ ## 標籤 Agent, ComputerUse, 產業趨勢, OpenAI