OSWorld 實測前必讀：把多模態代理丟進真實桌面環境的基準測試
[NeurIPS 2024] OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments
秒懂
- 它是什麼？
- OSWorld 用虛擬機跑 Ubuntu 與 Windows，讓代理透過滑鼠鍵盤操作真實應用程式，再用執行腳本驗證結果。本文拆解它的環境抽象、驗證機制與部署成本，並說明什麼情況下你該改用靜態截圖基準。
- 適合誰用？
- 如果你在訓練或評估會操作真實桌面軟體的代理，而且願意負擔虛擬機的部署與維護成本，OSWorld 是目前少數提供可執行驗證而非人工評分的公開基準。若你只需要評估模型對單張截圖的視覺理解，或無法提供 KVM、VMware 這類虛擬化環境，這個專案會帶來不成比例的負擔，改用靜態截圖問答資料集更合適。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
OSWorld 要解決的是評分問題，不是操作問題
多模態代理的評測長期卡在一個矛盾上：任務越接近真實使用情境，就越難自動判定成功。早期做法多半是給模型一張截圖、要它輸出下一步動作，再拿這個動作跟標準答案比對。這種方式便宜、可重現，但它衡量的是動作序列的相似度，不是任務有沒有完成。代理可能點錯位置卻因為動作字串吻合而得分，也可能用完全不同的路徑把事情辦成卻被判錯。
OSWorld 選擇把代理放進真正的作業系統裡。README 對它的定位是「Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments」，環境是跑在虛擬機中的 Ubuntu 或 Windows，代理透過滑鼠與鍵盤事件操作應用程式，而不是在模擬的 UI 樹上打轉。任務涵蓋的範圍由 evaluation_examples 目錄下的資料決定，官方另外提供了 Data Viewer 供人瀏覽。
目標讀者很明確：做代理訓練或評測的研究團隊，以及需要一套可重複的桌面自動化驗收標準的工程團隊。它不適合只想快速試玩模型能力的人，因為光是讓環境跑起來就要先處理虛擬化平台與映像檔。
DesktopEnv 這層抽象，把虛擬化平台與基準邏輯切開
這個專案在 2024 年 6 月做了一次重構，README 的說法是「refactor the code of environment part to decompose VMware Integration」，把平台整合從環境邏輯中拆出來，之後陸續支援 VirtualBox、AWS、Azure 等。拆出來的成果就是 DesktopEnv 這個類別，供應商由 provider_name 參數決定，作業系統由 os_type 決定。
這個切法的實際意義是：基準任務的定義、初始狀態的準備、以及結果驗證，都寫成和平臺無關的形式；換一個 provider 不需要改任務本身。對照之下，如果每個任務都直接呼叫 vmrun 或特定的雲端 API，要新增一個執行後端就得改動所有任務程式碼。
驗證機制是這套設計的關鍵一環。任務的成功與否不是由模型自評，而是由環境端執行的檢查腳本判定，也就是讀取虛擬機內的實際狀態。這讓「代理說它完成了」和「系統確認它完成了」成為兩件事。README 沒有在本文可見範圍內列出完整的驗證腳本清單，具體每個任務檢查哪些檔案或設定，需要直接讀 evaluation_examples 底下的內容才能確認。
初始狀態的準備同樣是環境端負責。官方在 2025 年 5 月提供了預先下載好的檔案，放在 Google Drive 上，README 說明這是給 init state setup 用的。少了這包檔案，環境初始化時得自行下載，會拉長每次執行的前置時間。
四種執行後端，成本與限制各不相同
README 把部署路徑分成幾類，選擇哪一條會直接影響你能跑多少任務、以及跑一次要多久。
第一類是桌面或裸機上的 VMware 與 VirtualBox。安裝流程是先 git clone 專案、cd 進去、執行 pip install -r requirements.txt，Python 版本需大於等於 3.10，官方建議用 Conda 管理環境。接著安裝 VMware Workstation Pro，Apple 晶片機器要改用 VMware Fusion，然後設定 vmrun 指令。驗證方式是執行 vmrun -T ws list，成功的話會列出目前執行中的虛擬機。VirtualBox 是備援選項，但 README 直說平行化以及 Apple 晶片上的 macOS 支援可能不夠好。
第二類是 Docker，適用於非裸機的伺服器。前提是主機支援 KVM，在 Linux 上執行 egrep -c '(vmx|svm)' /proc/cpuinfo，回傳值大於零代表處理器應該支援。macOS 主機一般不支援 KVM，官方建議改用 VMware。使用時在初始化 DesktopEnv 時帶入 provider_name 為 docker、os_type 為 Ubuntu 或 Windows。這裡有個容易被忽略的維運細節：README 提醒實驗若被中斷訊號打斷，可能留下殘餘容器，長期累積會影響系統效能，清理指令是 docker stop $(docker ps -q) && docker rm $(docker ps -a -q)。
第三類是 Modal，透過 VM Sandboxes 執行。需要 pip install 'modal>=1.5.0'、執行 modal setup 認證，再用 python -m desktop_env.providers.modal.setup --os Ubuntu 把磁碟映像檔推上去，最後以 python quickstart.py --provider_name modal --headless true 執行。
第四類是 AWS，README 在 2025 年 7 月的更新中提到新增支援，並稱透過平行化可以把評估時間壓到一小時以內。這個數字來自官方公告，不是獨立驗證的結果，實際表現取決於你開的執行個體數量與任務總數。
另外有一條輕量路徑：如果你只想用環境、不跑基準任務，可以直接 pip install desktop-env，這是專案發佈到 PyPI 的套件。
虛擬機是它的力量，也是它最貴的地方
OSWorld 最實在的限制不是模型能力，而是執行成本。每個任務要在一個完整的作業系統裡跑，從開機、還原快照、到套用初始狀態，都需要時間與資源。單機序列執行時，任務數乘上單次開機時間就是你的下限，這也是為什麼官方在 AWS 支援與 OSWorld-Verified 的更新裡反覆強調平行化。
平台限制同樣具體。macOS 主機不支援 KVM，所以 Docker 路線在 Mac 上走不通，只能退回 VMware。Apple 晶片機器上，VirtualBox 的 macOS 支援被 README 標為可能不夠好。也就是說，你的硬體與作業系統會直接決定哪條路可行，不是偏好問題。
環境的穩定性是另一個變數。Docker 路線的殘餘容器問題說明了一件事：這個基準的執行狀態是有副作用的，中斷後不會自動回到乾淨狀態。要做可重複的實驗，你得自己處理容器清理、快照還原與映像檔版本控管。
還有一個版本陷阱。官方在 2025 年 7 月推出 OSWorld-Verified，README 明講修正了社群回報的多個問題，並要求「compare your OSWorld results with the new benchmark results when running the latest version」。這意味著跨版本的分數不可直接比較。如果你的論文或內部報告引用的是舊版數字，跟新版排行榜放在一起會失真。
最後，這個專案不適合當成桌面自動化的生產工具。它的驗證腳本是為了評分而寫的，不是為了在企業環境中穩定執行業務流程。把它當成 RPA 框架來用，會遇到與評測完全不同的可靠性要求。
和螢幕截圖問答基準的差異在哪
最直接的替代方案是靜態截圖問答類基準，例如把 UI 畫面截圖後問模型「下一步該點哪裡」。這類資料集的優點是成本極低：不需要虛擬機、不需要開機、可以大量平行、結果完全可重現。它們衡量的是視覺理解與常識推理，對於模型選型的前期篩選很有用。
差別在於回饋迴路。靜態基準裡，模型的每個決策都是獨立的，它看不到自己上一步造成的畫面變化。OSWorld 的環境會把動作的後果回饋給代理，包含開啟錯誤的視窗、彈出對話框、或是應用程式進入意料之外的狀態。這種多步互動中的錯誤累積，是靜態基準結構上測不到的。
反過來說，OSWorld 付出的代價是執行時間與環境複雜度，而且任務的成敗綁在驗證腳本的正確性上。如果某個任務的檢查邏輯寫得太寬鬆，代理可能用取巧的方式通過；寫得太嚴格，則會誤判合理的替代解法。靜態基準沒有這個問題，因為它的評分標準就是答案本身。
選擇的判準因此不是哪個比較好，而是你想回答哪個問題。要比較模型對介面的理解程度，靜態截圖足夠。要驗證代理能否在真實系統中完成端到端任務，就得接受虛擬機的成本。
授權與長期維護的實際盤算
專案採用 Apache-2.0 授權，這對研究與商業內部使用都是相對寬鬆的選擇，允許修改與再散布，也包含專利授權條款。需要留意的是授權涵蓋的是程式碼，不涵蓋你另外下載的虛擬機映像檔、預先準備的初始狀態檔案，以及各應用程式本身的授權。這些資源各有自己的條款，README 只提供下載連結，沒有在可見範圍內說明其授權狀態。以上是對授權文字的一般理解，不構成法律意見，實際使用前應自行確認。
維護成本的來源有三塊。第一是虛擬化平台本身，VMware 的產品線與授權條件在近年有變動，README 的安裝指引會隨之更新，你的環境也得跟著調整。第二是映像檔與初始狀態檔案，官方把預先下載的檔案放在 Google Drive，這類外部託管連結的長期可用性不由程式碼倉庫保證。第三是版本升級，從 v0.1.0 到 v0.1.16 的發佈節奏，加上 2025 年的 OSWorld-Verified 大改版，說明這個基準仍在演進，鎖定一個版本並記錄對應的映像檔版本，比持續跟進主線更容易維持實驗的可比較性。
如果你的團隊打算把它納入持續整合流程，先想清楚容器殘留與快照還原要怎麼自動化，這兩件事不處理，跑久了結果會飄。
編輯結論
如果你在訓練或評估會操作真實桌面軟體的代理，而且願意負擔虛擬機的部署與維護成本，OSWorld 是目前少數提供可執行驗證而非人工評分的公開基準。若你只需要評估模型對單張截圖的視覺理解，或無法提供 KVM、VMware 這類虛擬化環境，這個專案會帶來不成比例的負擔，改用靜態截圖問答資料集更合適。動手前先確認三件事：你的 Python 版本是否大於等於 3.10、vmrun -T ws list 是否回傳可用的虛擬機清單、以及你的主機是否支援 KVM（在 Linux 上執行 egrep -c '(vmx|svm)' /proc/cpuinfo 檢查看回傳值是否大於零）。最後記得，2025 年 7 月之後官方推出了 OSWorld-Verified，README 明確要求把結果與新版基準數字比較，別拿舊版的成績去對照新版的排行榜。
社群筆記