E2B Desktop Sandbox：把圖形桌面當成 LLM 的可丟棄執行環境
E2B Desktop Sandbox for LLMs. E2B Sandbox with desktop graphical environment that you can connect to any LLM for secure computer use.
秒懂
- 它是什麼？
- 這個專案提供一個隔離的虛擬桌面，讓 LLM 或自動化腳本以滑鼠、鍵盤與螢幕串流操作 GUI 程式。本文拆解它的 SDK 邊界、串流限制與採用前該驗證的事項。
- 適合誰用？
- 如果你要讓 LLM 或自動化腳本操作 GUI 程式，而且能接受把執行環境交給 E2B 的雲端沙箱、以 E2B_API_KEY 計費與管理，這個專案值得先跑 examples/basic-python 驗證。若你的流程需要同時觀察多個應用程式視窗、需要自架且不連外、或需要把桌面狀態長期保留，它就不合適，因為官方明講同一時間只能有一個串流，而 sandbox 是可 kill 的短生命週期資源。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 2 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「LLM 需要一個看得到畫面、點得到按鈕的環境」
多數 LLM 工具鏈假設任務可以化約成 API 呼叫或命令列指令。但大量真實工作沒有 API：內部後台的審核介面、只有桌面版的舊系統、需要拖曳與右鍵選單的圖形工具。E2B Desktop Sandbox 針對的正是這一類情境，README 開頭把它定位成 open source secure virtual desktop ready for Computer Use，每個 sandbox 彼此隔離，且可以自行安裝依賴。
目標讀者是已經在用 E2B Sandbox、想往上疊一層圖形介面的開發者，以及在做 computer use agent 的團隊。README 直接列出兩個自家示範：Open Computer Use 標榜用 100% 開源 LLM，Surf 則是 OpenAI Computer Use Agent 的 Next.js 應用。這兩個例子說明了它的典型用法：模型負責決定下一個動作，SDK 負責把動作送進桌面。
它不是給人遠端辦公用的虛擬桌面。串流、滑鼠控制、視窗列舉這些 API 都是為了讓程式呼叫而設計，不是為了讓使用者長時間坐在裡面工作。
沙箱、SDK 與串流服務的三層分工
從 README 可見的介面來看，架構分成三層。底層是 E2B Sandbox，README 寫明 Desktop Sandbox 建構於其上，這也解釋了為什麼第一步是申請 E2B API key 並設定環境變數 E2B_API_KEY。中間層是桌面控制 API，Sandbox.create() 取得一個 desktop 物件後，可以 launch 應用程式、wait 等待、get_current_window_id 取得作用中視窗、get_application_windows 列出某個應用程式的所有視窗，以及一整組滑鼠操作。上層是串流服務，stream.start 啟動、stream.get_url 取得觀看網址、stream.stop 停止。
資料流是單向的命令與畫面：你的程式送出點擊座標或鍵盤輸入，沙箱內的桌面執行，畫面再透過串流位址回傳。滑鼠 API 的粒度很細，README 列出 double_click、left_click、right_click、middle_click、scroll、move_mouse、drag、mouse_press、mouse_release，其中 left_click 與 right_click 等可以帶 x、y 座標，scroll 的正負代表上下方向。這種設計意味著模型必須自己知道要點哪裡，SDK 不會幫你辨識畫面元素。
值得注意的是串流與控制的耦合程度。stream.start 可以指定 window_id，只串流單一視窗；不指定時串流整個桌面。get_current_window_id 取的是當前作用中視窗，get_application_windows 則回傳某個應用程式的視窗清單，兩者搭配才能鎖定特定視窗。
安裝與最小可跑範例
Python 端安裝指令是 pip install e2b-desktop，JavaScript 端是 npm install @e2b/desktop。前置條件只有一個：設定環境變數 E2B_API_KEY。
README 的 Python 範例流程是：from e2b_desktop import Sandbox，desktop = Sandbox.create()，接著 desktop.launch('google-chrome')，註解提到也可以是 vscode、firefox 等。然後 desktop.wait(10000) 等十秒讓應用程式開啟，再 desktop.stream.start(window_id=desktop.get_current_window_id(), require_auth=True)，用 desktop.stream.get_auth_key() 取出授權金鑰，最後 desktop.stream.get_url(auth_key=auth_key) 印出串流網址。任務結束後呼叫 desktop.kill()，這行在範例中是註解掉的，但註解寫明 Kill the sandbox after the tasks are finished。
JavaScript 版本逐項對應，只是駝峰命名：Sandbox.create()、desktop.launch()、desktop.wait()、desktop.stream.start({ windowId, requireAuth })、desktop.stream.getAuthKey()、desktop.stream.getUrl({ authKey })。
串流本身有幾種開法。最單純的是 desktop.stream.start() 之後 get_url()；要唯讀不給互動，用 get_url(view_only=True)，JavaScript 是 getUrl({ viewOnly: true })。要密碼保護就傳 require_auth=True，再拿 get_auth_key() 產生的金鑰去換網址。停止一律是 stream.stop()。
一次只能開一條串流，這是最硬的限制
README 對串流的警告寫得很直白：指定應用程式串流時，若目標應用程式尚未開啟會拋錯；應用程式關閉時串流也跟著結束；而且 Creating multiple streams at the same time is not supported，你得先停掉當前串流，再為另一個應用程式開新的。基本範例的註解也重複了同一件事：There can be only one stream at a time。
這個限制直接決定了哪些任務做不了。如果你的 agent 需要在瀏覽器查資料、同時在終端機看輸出、又在編輯器改檔案，而且希望全程有人或模型盯著三個視窗，這個設計不支援。變通方式是整個桌面一起串流，不指定 window_id，這樣至少看得到全部畫面，但就失去了單視窗串流的聚焦效果。
另一個容易踩到的是時序。範例示範 desktop.wait(10000) 這種固定等待，而不是等待某個就緒訊號。應用程式啟動時間會隨映像內容與機器負載變動，固定秒數在示範裡夠用，在自動化流程裡就得自己處理重試，否則 launch 之後立刻取視窗 ID 可能拿到空的清單。
還有一點是資源生命週期。範例把 kill 註解掉，是因為示範需要你手動去看串流；但在正式流程裡忘記 kill 就等於讓沙箱持續存在。這部分是 E2B 平台的計費與配額問題，README 沒有交代細節。
與其他做法的差異：托管沙箱對上自架容器
同類需求常見的替代路線是自己用 Docker 加虛擬顯示器（例如 Xvfb 之類的方案）在 CI 或自架機器上跑圖形程式，再自己接 VNC 或 noVNC 做畫面傳輸。兩者的差別不在能不能畫出桌面，而在誰負責隔離、生命週期與網路暴露面。
自架路線把這些全部留給你：映像要自己維護、每個任務的容器要自己開自己收、串流端點要自己保護。好處是資料不出自己的網路，桌面狀態可以掛載保存，也能同時開多個顯示器。E2B Desktop Sandbox 把這些包成 SDK 呼叫，代價是執行環境在 E2B 的雲端，你必須持有 E2B_API_KEY，且受限於平台的沙箱規格與計費方式。README 沒有提供自架部署的說明，也沒有列出映像內預裝軟體的完整清單，只以 google-chrome、vscode、firefox 舉例。
另一種差異在抽象層次。有些 computer use 框架把「看畫面、決定座標、點擊」整條迴圈綁在一起；這個專案只提供桌面操作原語與串流，模型與決策邏輯由你決定。README 列出的 Open Computer Use 與 Surf 都是建在它之上的應用，而不是它的一部分。這種切法讓替換模型變得容易，但也意味著畫面理解、動作解析、錯誤重試都要自己寫。
維護與授權：SDK 已經搬走，這個倉庫留的是範本與範例
README 開頭的 NOTE 是採用前必須先讀的一段：@e2b/desktop 與 e2b-desktop 的 SDK 原始碼已經移到 E2B monorepo，位於 packages/desktop-js 與 packages/desktop-python，SDK 的 issue 與 PR 要開在那裡。這個倉庫保留的是 sandbox template 與 examples。
對維護成本的影響很實際。你追蹤的版本號來自 @e2b/desktop-python 與 @e2b/desktop 這兩個套件，近期釋出記錄顯示 Python 端到 2.4.2、JavaScript 端到 2.3.1，兩邊版本號不同步，升級時要分別確認。但改動這些套件的討論不在你正在讀的這個倉庫裡，如果你只 watch 這裡，SDK 的行為變更可能不會出現在你的通知中。
授權是 Apache-2.0。這個授權允許商業使用與修改，並附帶專利授權條款，但要求保留版權與授權聲明，修改過的檔案需標註變更。實際的合規判斷要看你怎麼散布與是否修改，這不是法律意見，遇到具體情況請找法務。另外要注意的是，SDK 採用 Apache-2.0 不等於 E2B 的托管服務也免費，API key 背後是商業平台，授權條款管的是程式碼，不是服務使用。
誰該採用，先驗證哪三件事
適合的團隊有兩類。一是已經在用 E2B Sandbox、需要讓 agent 操作圖形程式的開發者，因為 API key、沙箱模型、生命週期管理都可以沿用，學習成本只落在桌面這層 API。二是在做 computer use 研究或原型、需要快速取得一個可丟棄的圖形環境，且不在乎執行環境在雲端的團隊。README 提供的 examples/basic-python、examples/basic-javascript 以及 streaming-apps 兩個範例目錄，是最短的驗證路徑。
不適合的情況同樣明確。需要同時觀察或操作多個應用程式視窗的流程，會撞上單一串流的限制。需要自架、資料不出內網、或需要把桌面狀態保存下來重複使用的場景，這個專案沒有對應說明。只想跑命令列任務的話，圖形桌面這一層完全是多餘開銷。
驗證順序建議從最小範例開始：先跑 examples/basic-python，確認 E2B_API_KEY 可用、Sandbox.create() 能起來、launch 加上 wait 之後 get_current_window_id 拿得到有效值。第二步測串流，開 require_auth=True 並確認沒有金鑰時 get_url 回傳的網址進不去。第三步才是把你的實際應用程式塞進桌面映像，因為 README 沒有列出映像內容清單，你需要的軟體是否已預裝、能否自行安裝，只能實測。這三步都過了，再來談把 agent 接上去。
編輯結論
如果你要讓 LLM 或自動化腳本操作 GUI 程式，而且能接受把執行環境交給 E2B 的雲端沙箱、以 E2B_API_KEY 計費與管理，這個專案值得先跑 examples/basic-python 驗證。若你的流程需要同時觀察多個應用程式視窗、需要自架且不連外、或需要把桌面狀態長期保留，它就不合適，因為官方明講同一時間只能有一個串流，而 sandbox 是可 kill 的短生命週期資源。採用前先確認三件事：你的 E2B 方案對 sandbox 執行時間與並行數的限制、桌面映像內預裝了哪些應用程式（README 只舉了 google-chrome、vscode、firefox 等例子）、以及 SDK 原始碼已移到 e2b-dev/E2B 的 packages/desktop-js 與 packages/desktop-python，issue 與 PR 要開在那裡。
社群筆記