Open Computer Use：用開源 LLM 操作 E2B 桌面沙箱的路線與代價

它把「操作電腦」拆成三種模型，而不是一個大模型全包

多數電腦操作代理的做法是把螢幕截圖丟給一個多模態模型，讓它同時判斷畫面上有什麼、該點哪裡、下一步做什麼。Open Computer Use 沒有這樣做。它的 config.py 把模型分成三個角色：grounding_model 負責把「那個按鈕」對應到實際座標，vision_model 負責理解畫面內容，action_model 負責決定下一個動作。README 給的預設範例是 grounding 用 OSAtlasProvider，vision 用 GroqProvider 的 llama3.2，action 用 GroqProvider 的 llama3.3。

這個切法的直接後果是：你可以讓一個小模型專門做座標定位，把昂貴的推理留給 action。供應商清單也反映了這種分工，Llama 3.2 被標註為 vision only，Llama 3.3 是 action only，OS-Atlas 與 ShowUI 只做 grounding，Gemini 2.0 Flash、GPT-4o、Claude、Pixtral 這幾組才同時掛 vision 與 action。如果你手上只有一個全能模型，這個架構對你沒有好處，你只是多寫兩層轉接。

沙箱在雲端，串流在本機：資料實際怎麼流動

README 的架構圖與描述指向一個明確的拓撲。代理程式跑在你的機器上，透過 E2B API key 開出一個雲端 Linux 桌面沙箱，然後用鍵盤、滑鼠與 shell 指令去操作它。畫面的即時串流回傳到你的本機顯示，所以你能看著它動。

這裡有個容易被忽略的設計選擇：它選擇 Ubuntu 作為沙箱系統，但 README 說「designed to work with any operating system」。這句話的份量取決於你怎麼用。沙箱本身是雲端的，你本機跑什麼系統不影響代理邏輯，真正被綁住的是沙箱映像。使用者可以隨時暫停並對代理下新指令，這個互動點在 README 的 features 裡被列為一項，代表它不是單向的批次執行，而是可以中途介入的迴圈。

需要說清楚的是，README 沒有交代暫停是透過什麼機制實作，也沒有說明串流的延遲量級。這兩點在文件裡是空白，只能靠實際跑起來才知道。

啟動流程：從 poetry 到第一個 prompt

前置條件是 Python 3.10 或更新版本、git、一組 E2B API key，以及至少一個 LLM 供應商的 API key。README 的安裝指令是 brew install poetry ffmpeg，這暗示它預設讀者用 macOS 或 Linux 的 Homebrew 環境，Windows 使用者要自己找對應做法，文件沒有給。

取得程式碼是 git clone https://github.com/e2b-dev/open-computer-use/，進到目錄後建立 .env，至少要填 E2B_API_KEY。其餘的 key 按 config.py 裡選了哪些 provider 決定，Hugging Face Spaces 不需要 key，但 README 另外標註 HF_TOKEN 是 required，理由是繞過 Gradio 的速率限制。這條註記值得注意：grounding 走 OS-Atlas 或 ShowUI 時，你其實是在呼叫 Hugging Face Spaces 上的服務，不是本地推論。

裝完依賴用 poetry install，啟動是 poetry run start。要直接帶指令進去，README 給的例子是 poetry run start --prompt "use the web browser to get the current weather in sf"。文件說明顯示串流會在 Python 程式啟動後幾秒內出現。

grounding 依賴外部 Spaces 是這套設計最脆的一環

README 把 OS-Atlas 與 ShowUI 列在 HuggingFace Spaces 底下，並要求提供 HF_TOKEN 來避開 Gradio 速率限制。這兩件事放在一起看，結論很清楚：如果你選這兩個 grounding 模型，你的代理穩定性取決於一個你無法控制的外部服務，以及你的 token 額度。

這不是實作瑕疵，而是取捨。用現成的 Spaces 換取不用自己部署視覺定位模型，代價是把一個推論環節外包出去。想避開這條路，就得改用同時支援 vision 與 action 的模型，例如 Gemini 2.0 Flash、GPT-4o 或 Claude，讓 grounding 由同一個模型兼任，但這樣就失去了三模型分工的好處，也回到單一模型的成本結構。

文件沒有說明這兩個 Spaces 的可用性保證，也沒有提供本地部署的替代路徑。如果你的場景不能容忍第三方服務中斷，這是需要先驗證的點。

什麼情況下它會是錯的工具

第一種情況是你需要本機執行。整個架構建立在 E2B Desktop Sandbox 之上，桌面在雲端，本機只負責顯示串流與下指令。如果你的合規要求是資料與操作都不出本地機器，這個前提就不成立，換模型也救不回來。

第二種情況是你只需要單一步驟的視覺問答。三模型分工的價值在於把定位、理解、決策拆給不同成本的模型，如果你的任務根本不需要定位座標，多出來的 provider 抽象只是多一層要維護的程式碼。

第三種情況是你要跨平台桌面自動化。README 說設計上支援任何作業系統，但沙箱是 Ubuntu，實際被驗證的環境就是 Ubuntu。把它當成 Windows 或 macOS 桌面代理來規劃，是超出文件所描述的範圍。

還有一個文件層面的限制：README 鼓勵使用者為新模型或 provider 發 PR 更新 providers.py，這代表供應商清單的完整度取決於社群提交，不是專案保證的覆蓋範圍。

對照 Anthropic 的 computer use：託管與自組的差別

Anthropic 的 computer use 走的是另一條路。它把螢幕理解與動作決策放在同一個模型裡，開發者接的是單一 API，不需要自己組 grounding、vision、action 三個槽位，也不需要決定哪個模型負責哪一段。代價是你被綁在那個模型上，模型換代時你的行為也會跟著變。

Open Computer Use 反過來，它把模型選擇權交出來，README 明確說支援 10+ LLM，並列出 Fireworks、OpenRouter、Llama API、Groq、DeepSeek、Google、OpenAI、Anthropic、Moonshot、Mistral AI 等來源。你甚至可以同時用 Groq 跑 vision、用 OS-Atlas 跑 grounding，這種混搭在單一 API 的方案裡做不到。

差別不在功能多寡，在責任歸屬。託管方案幫你處理模型間的協調，自組方案把協調留給你，包括每個模型的輸入格式、輸出解析，以及當某一個供應商掛掉時的行為。這個專案選了後者，所以它的 providers.py 會一直是整個專案最需要維護的檔案。

授權與後續維護成本

授權是 Apache-2.0，這是寬鬆授權，允許商用與修改，附帶專利授權條款。這裡不提供法律意見，實際使用前請自行確認你的部署情境是否符合條款，特別是如果你要把修改後的版本再散布出去。

維護成本主要落在兩個地方。一個是 providers.py，README 直接寫明新增模型或 provider 要發 PR 更新這個檔案，意味著供應商 API 變動時，適配層要跟著改。另一個是 config.py，三個模型槽位的組合會直接影響你的 API 帳單與失敗模式，換模型等於換一組行為，不是換一個參數。

專案的發布紀錄在提供的資料裡沒有檢索到任何 release，所以無法從版本號判斷升級節奏。要知道目前狀態，只能看 master 分支的提交。這是採用前應該自己確認的事實，不該從 README 的完整度去推測。

編輯結論

如果你要的是一個能替換模型、能觀察每一步動作的電腦操作代理，而且願意接受 E2B 沙箱與至少一組 LLM 供應商 API key 這兩個外部依賴，Open Computer Use 值得先跑一次 poetry run start 看它的串流與暫停行為。如果你需要的是本機執行、不想把桌面交給雲端沙箱，或只想用單一模型解決所有步驟，這個專案的分工設計反而會增加你的整合成本。動手前先確認三件事：config.py 裡三個模型槽位分別由誰填、你的供應商是否同時支援 vision 與 action、以及 HF_TOKEN 是否已設好，否則 grounding 模型會撞上 Gradio 的速率限制。

官方來源

1. e2b-dev/open-computer-use on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README