OpenSandbox 開源 AI 沙箱：為 Agent 自架可控執行環境

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

OpenSandbox 是阿里巴巴技術團隊主導、目前以 opensandbox-group 名義維護的開源 AI 沙箱平台，定位是通用型沙箱基礎設施，讓 AI Agent 能在受控的隔離環境裡執行 Python、Java、JavaScript 等程式碼、操作瀏覽器與虛擬桌面。截至 2026 年 7 月，GitHub 上累積超過 12,000 顆星、1,000 個 fork，是 CNCF Landscape 與 OpenSSF Best Practices 名單上的活躍專案，最近一次提交落在 2026 年 7 月 24 日。

它的賣點很明確：當你不想把 Agent 的執行環境交給 E2B、Modal 這類代管服務，又不想從零拼湊 Docker + cgroups + seccomp + 網路命名空間，OpenSandbox 把這整套隔離執行層打包成一套有 SDK、有 CLI、有生命週期協議的自架方案。Apache-2.0 授權、可商用、可改寫，部署起來就是一台 Linux 伺服器加 Docker。

與 E2B、Modal、純 Docker 的關鍵差異

沙箱基礎設施這個賽道目前分成兩條路線：一是雲端代管（E2B、Modal、Fly Machines），沙箱跑在別人家機房，按執行次數或分鐘計費；二是自架開源（OpenSandbox 與純 Docker 自拼），沙箱跑在你自己的 Linux 伺服器上。OpenSandbox 的位置剛好落在「自架但不從零拼」的中間地帶。

從 Agent 開發者的角度，這張表其實只問一件事：你的 workload 跑在哪？如果可接受跑在第三方雲端、按次付費換掉維運成本，E2B 或 Modal 仍是門檻最低的選擇；若合規、資料主權或成本結構要求落地自家機房，OpenSandbox 把「自架但不想自己設計執行層協議」這個缺口補上。值得注意的是，阿里的 OpenClaw CN IM Docker 鏡像（TechMoon 介紹文）走的是類似的 Docker 打包路線，差別在它把容器用於打包機器人執行環境，而 OpenSandbox 是把容器當作 Agent 執行層的標準化介面。

OpenSandbox 鎖定的五類應用場景

從時序來看，OpenSandbox 是個相對年輕的專案。GitHub 倉庫建立於 2025 年 12 月 17 日，短短七個月內累積到 12,000 顆星、1,000 個 fork，這個速度在開源基礎設施專案裡屬於第一梯隊。對照組是 E2B（同樣鎖定 AI 沙箱賽道，但採商業代管模式）與 Daytona（開源開發環境管理器，定位略有不同），OpenSandbox 把「自架 Agent 執行層」這個缺口填上，是它能快速吸引星標的主因。Trendshift 與 CNCF Landscape 雙雙把它列入追蹤名單，OpenSSF Best Practices 徽章也代表專案在安全性流程上達到社群認可的基準線。

README 把應用場景明確列為五大類：Coding Agents（例如 Claude Code 在沙箱內執行生成的程式碼）、GUI Agents（操作虛擬桌面、VNC 連線的圖形介面）、Agent Evaluation（在可重現的隔離環境跑評測基準）、AI Code Execution（比照 ChatGPT Advanced Data Analysis 的 code interpreter）、以及 RL Training（強化學習訓練 pipeline 的環境供應者）。這五個場景背後共通的需求是可程式化的隔離執行環境，把不可信或高變動性的 code 關進可控制生命週期的容器，再透過統一 API 讓 Agent 呼叫。OpenSandbox 的設計選擇是把這個共通需求抽成 Sandbox Protocol，任何自訂 runtime 都能實作這套協議接上生態。

為什麼 AI Agent 需要沙箱

沙箱本質上是 dual-use 基礎設施：它跟能用自然語言查資料庫的 Data-Analysis-Agent一樣，會去執行模型生成的程式碼，差別在於前者的程式碼可能來自不可信來源、目的也不一定是善意的。常見的三種風險情境是：模型幻覺產生危險指令（例如把 rm -rf 當成清理暫存）、第三方 plugin 夾帶惡意碼、以及 Agent 自動化流程觸發非預期副作用。沙箱的存在不是為了阻擋這些事發生，而是把爆炸半徑收進可重啟、可銷毀的隔離容器。

OpenSandbox 對應的工程手段是所謂的 ephemeral 沙箱：即用即毀。Agent 申請一個指定運行時（例如 Python 3.11）的沙箱實例，執行完腳本、取回結果，沙箱就被銷毀、不留下任何狀態。下一次任務再起一個乾淨的環境，避免依賴衝突與狀態汙染。這跟QuantDinger 自架量化交易工作台用 Docker 把研究、回測、實單執行包成獨立單元的思路一致，只是 OpenSandbox 把這個思路擴展到「任何想讓 Agent 跑 code 的場景」。

隔離強度的四個層級

OpenSandbox 預設使用 Docker 容器隔離，但這個預設不等於多租戶安全。Docker 容器與宿主機共用 Linux kernel，一旦遭遇容器逃逸漏洞（container escape），攻擊者就能跳上宿主機。README 明確指出，處理不可信或高風險 workload 時，要主動切換到強隔離運行時：

• Docker（預設）：共享 kernel，啟動最快、資源損耗最低。適合開發、測試、可信賴的內部任務。
• gVisor：Google 出的 userspace kernel，攔截並重新實作容器發出的 system call，等於在容器與宿主 kernel 之間多塞一層。隔離性高於 Docker，相容性與效能有折損。
• Kata Containers：每個容器跑在獨立的輕量虛擬機裡，hardware-level 隔離，相容於 OCI 規範。資源損耗較大，適合需要強隔離又想保留容器介面的場景。
• Firecracker microVM：AWS Lambda 與 Fargate 同款的 microVM 引擎，啟動時間在毫秒等級、記憶體占用極小，是大型 multi-tenant 平台首選。

OpenSandbox 把這四種 runtime 收進同一套 lifecycle API，部署者依據風險等級選用，不必為了切換隔離層級而重寫 SDK 呼叫。這是它跟純 Docker 自拼最大的拉力之一，自己拼 docker-compose 不難，但要從 Docker 換到 gVisor 或 Kata，往往要改 daemon 設定、重啟 runtime、調整 mount；OpenSandbox 把這個選擇參數化進沙箱協議。

實際選擇時可以這樣想：Docker 適合「你信任你 Agent 會跑的 code」的情境，例如自家內部 pipeline 或開發期的快速迭代；gVisor 拿來面對「不確定 code 會做什麼、但還沒到惡意等級」的灰色地帶，例如接受使用者提交 script 的功能；Kata 與 Firecracker 則是「明確不信任、要當成潛在惡意處理」的場景，例如 multi-tenant SaaS 把不同使用者的 Agent 隔開。OpenSandbox 在文件裡提供一份 secure container runtime guide，詳細說明每種 runtime 的安裝、效能成本、相容性與核心 syscall 攔截面，是部署前必讀的章節。

另一個容易被忽略的細節：gVisor、Kata、Firecracker 三者並非擇一互斥，OpenSandbox 的 K8s runtime 允許在同一個叢集裡依工作負載特性混用，低風險批次任務跑 Docker、使用者提交的 code 跑 Firecracker、敏感內部工具試跑 Kata。這種差異化隔離的設計是大型 Agent 平台才會遇到的工程問題，OpenSandbox 把它收進協議層，避免每個團隊都重新發明一次。

Pin

自架部署的實際流程

把 OpenSandbox 跑起來的最小部署是「一台 Linux 伺服器 + Docker」。先用 osb CLI（OpenSandbox 自己的命令列工具）啟動服務端，這台機器就變成沙箱排程中心，負責管理所有沙箱實例的建立、監控、銷毀。之後透過 SDK 在 Agent 程式裡申請沙箱、投遞任務、取回結果，整個流程像是把 Function-as-a-Service 搬進自家機房。

Python SDK 的安裝就是一行：

pip install opensandbox

申請沙箱、跑一段 Python、取回結果的最小範例長這樣：

import opensandbox

# 申請一個 Python 3.11 runtime 沙箱（生命週期由 SDK 管理）
with opensandbox.create(runtime="python:3.11", cpu=2, mem="2Gi") as sb:
    # 在沙箱內執行腳本
    result = sb.run("print(sum(range(100)))")
    print(result.stdout)        # 執行 stdout
    print(result.exit_code)     # 結束代碼
    # 沙箱離開 with 區塊後自動銷毀

這個範例體現了 OpenSandbox 設計理念的三個重點：第一，生命週期與資源配額在申請時就明確指定（CPU、Memory、runtime 版本），避免「啟動後才發現資源不足」的常見 docker-compose 痛點；第二，沙箱實例透過 context manager 自動回收，即使中間拋出例外也不會留下殭屍容器；第三，SDK 介面在不同 runtime（Docker / gVisor / Kata / Firecracker）之間完全一致，部署者只要改申請參數就能切換隔離層級，不必改動業務呼叫邏輯。

其他語言的套件名分別是：JavaScript / TypeScript 走 @alibaba-group/opensandbox（npm）、Java / Kotlin 走 com.alibaba.opensandbox:sandbox（Maven）、Go 走 github.com/alibaba/OpenSandbox/sdks/sandbox/go、C# / .NET 走 Alibaba.OpenSandbox（NuGet）。README 上有完整的 quickstart 範例，涵蓋 Code Interpreter、瀏覽器自動化（Chrome / Playwright）與桌面環境（VNC、VS Code）三類應用場景。

需要橫向擴展時，OpenSandbox 提供原生 Kubernetes runtime，把沙箱排程交給 K8s 的調度器，能在多節點叢集上跑大規模 Agent eval、RL 訓練或批次任務。README 的 Kubernetes runtime 章節有詳細的部署 yaml 與 nightlies，相關的 CI 也每天跑 K8s 整合測試。

它對 Coding Agent 生態的整合也值得單獨一提：README 的 examples 明確把 Claude Code 列為一級支援的 Coding Agent 範例，沙箱能直接給 Claude Code 當執行環境。這對企業內部想自架 Claude Code 工作流、又不願把生成 code 直接跑在開發機上的團隊來說，剛好填補了一個明確缺口，原本只能靠 Anthropic 官方代管方案或自架隔離 docker，現在多了一條有協議層、有 SDK、可接 K8s 排程的開源路徑。不過讀者要留意，OpenSandbox 本身是執行層基礎設施，Claude Code 的 Agent 決策能力仍由 Anthropic 模型與授權方案決定，兩者是互補關係而非替代。

Pin

Credential Vault 與網段管控

沙箱最容易被忽略的工程細節是怎麼把 API Key 交給 Agent 用。最直覺的做法是寫死在環境變數或設定檔裡，但這等於把 secret 暴露給 workload，一旦容器被攻破，攻擊者就能把 secret 撈走。OpenSandbox 的對應設計是 Credential Vault：在沙箱層注入憑證，讓 Agent 在出站請求時能用、但看不到原 secret。這把「使用權」與「持有權」拆開，等於把最小權限原則落實到沙箱層。

另一個關鍵工程手段是egress 網路管控。沙箱預設允許出站流量，方便 Agent 抓網頁、呼叫 API；但 multi-tenant 或處理敏感資料的場景必須主動設 allowlist，限制沙箱只能連到白名單內的端點。OpenSandbox 提供 per-sandbox egress control（每個沙箱實例獨立設規則）加上 ingress gateway（多種路由策略），讓網段隔離成為沙箱協議的一部分而非外加的防火牆規則。這對Agent Battery這類得長期追蹤 Claude Code、Codex 用量的工具來說，是另一層可疊加的隔離工程。

具體的應用情境是這樣的：假設你的 Agent 要幫使用者查即時匯率、呼叫第三方 LLM、寫入自家資料庫。沒有 egress control 時，沙箱理論上能連到任何 IP，等於把內網拓樸暴露給潛在惡意 code；有了 per-sandbox allowlist，你可以為這個沙箱實例只開放三個目的端（匯率 API、LLM endpoint、特定 DB），其他全部擋下。再搭配 Credential Vault 注入這三個目的端需要的 API key（Agent 看不到原 key、但能透過 SDK 自動簽章呼叫），等於把「最小權限 + 預設拒絕」這兩個零信任原則落實到沙箱層。在內部網路分段已經是基本要求的企業環境，這套設計能與既有防火牆政策無縫接軌。

一個值得知道的命名觀察：alibaba 到 opensandbox-group 的遷移

從 GitHub API 可以看到，OpenSandbox 目前的權威倉庫是 opensandbox-group/OpenSandbox，而舊連結 github.com/alibaba/OpenSandbox 會以 301 重導向到新位置。opensandbox-group 這個 GitHub Organization 成立於 2026 年 6 月 4 日，比起倉庫本身的建立日期（2025 年 12 月）晚了半年多，是專案從阿里巴巴內部品牌切出去成獨立 group 的遷移訊號。

遷移期間最明顯的副作用是套件座標還沒跟上。Maven、npm、Go module 的命名空間仍保留 alibaba 或 alibaba-group 字樣（例如 @alibaba-group/opensandbox、com.alibaba.opensandbox:sandbox），只有 Python 的 pip install opensandbox 採用無品牌前綴。這在開源專案改名過程中相當常見，屬於正常遷移期現象而非惡意重新包裝；部署時只要對照 README 為準、不要把不同名稱空間的套件混用，就不會踩坑。讀者若在其他教學文看到「Alibaba OpenSandbox」與「OpenSandbox from opensandbox-group」並列出現，指的其實是同一個專案。

誰適合用、誰不該用

OpenSandbox 的目標用戶相當明確。第一類是自架 Agent 平台團隊：要在自家機房或自有雲端帳號上跑 Coding Agent、瀏覽器自動化、GUI 自動化的公司，需要可控的執行層協議。第二類是必須執行不可信程式碼的 SaaS：例如程式教學平台、線上 IDE、程式碼評測系統，需要把使用者提交的 code 關進沙箱。第三類是內部 Agent Eval 與 RL 訓練 pipeline：要用大規模、可重現的環境跑評測與訓練任務，Kubernetes runtime 是為這類場景設計的。

相對地，下列三種情境不建議自己架。一是只想偶爾跑一兩個 Agent、總執行時間一天不到幾分鐘，直接用 E2B 或 Modal 按次計費，比維運一台 OpenSandbox 伺服器划算太多。二是沒有 Linux 與 Docker 維運經驗、也沒有 K8s 基礎，OpenSandbox 雖然有完整文件，但部署、監控、網段設定仍是基礎設施工作，跨過這條門檻前會卡很久。三是需要 100% 完全代管、不能碰任何伺服器設定，這類需求只能走商業雲方案，自架工具不適合。

限制與風險

• 預設 Docker 隔離不足以應付 multi-tenant：處理不可信 workload 時，必須主動升級到 gVisor、Kata 或 Firecracker；忘記這一步等於把 Agent 執行層暴露在容器逃逸風險下。
• egress 預設允許出站：沙箱會對外發請求，多租戶場景需自行設 allowlist，否則 Agent 可能把內部資料往外部端點送。
• 資源配額要自己設：CPU、Memory Quota 必須在啟動參數裡明確配置，否則一個失控的 Agent 能吃光整台宿主機資源、影響其他沙箱。
• 套件命名 mid-rebrand 混淆：repo 改名 alibaba → opensandbox-group，但 Maven / npm / Go 套件座標保留舊品牌，新人 import 時容易以為是 fork，得對照 README 釐清。
• 自架成本不為零：Docker on Linux 是最小門檻，但跨到 Kubernetes runtime 後，叢集維運、監控、升級、資源規劃都會變成全職工作。
• 商業支援路徑尚未明朗：Apache-2.0 開源專案，但 README 與官網未明列正式的企業支援方案，企業導入前須自行評估社群管道（Discord / DingTalk）能否滿足 SLA 需求。
• 文件英文為主、社群以中文為輔：README 與官方文件以英文撰寫，但 DingTalk 群組仍是主要中文討論區，遇到問題時的雙語切換成本要算進維運流程。
• Sandbox Protocol 自訂 runtime 學習曲線：要實作自己的 runtime 接上協議，得熟讀 lifecycle API 與 execution API 規格；對只想用預設 runtime 的團隊無影響，但想深度客製的團隊要預留探索時間。

與本機 AI Agent 工具的邊界

OpenSandbox 解決的是伺服器端的 Agent 執行隔離問題，跟「本機 AI Agent」是不同層級的需求。如果你尋找的是用 WebGPU 在 Chrome 本地跑網頁自動化的 on-device-browser-agent，那是跑在使用者機器上的擴充功能；OpenSandbox 則是跑在你自己架的伺服器上、給後端 Agent 呼叫的執行層。兩者可以搭配（Agent 在本機決策、把重活外包給沙箱跑），但定位完全不同，挑選時先釐清需求是端點還是後端。

結論

OpenSandbox 走的不是「最快上手」路線，而是「可控、可擴展、可商用」路線。它把 Agent 執行層從雲端代管服務拉回自家機房，用 Apache-2.0 開源、Docker / K8s 雙 runtime、可切換的四種隔離層級、以及完整的 SDK 族系，把這個過去只能靠商業雲解決的問題變成可自架的工程方案。對於已經在跑 Agent 平台、又需要資料落地或成本控制的團隊，這是一條值得認真評估的路。

對一般個人開發者或只是偶爾寫寫 Agent script 的人，先用 E2B 或 Modal 起手、把基礎設施成本交給代管服務，會是更務實的選擇。等 Agent 進入 production、用量到一定規模、或合規要求把資料收回自家機房，再回頭評估 OpenSandbox 的自架路徑，時機會更成熟。

常見問答

OpenSandbox 是免費的嗎？

軟體本身是 Apache-2.0 開源、可免費使用、可商用、可修改、可再散布。但「自架」不等於「零成本」：你得自己準備 Linux 伺服器、Docker 環境、必要的話還要 Kubernetes 叢集，以及對應的維運人力。商用雲方案（E2B、Modal）把這些維運成本包進 per-execution 費率裡，OpenSandbox 則是把這些成本留給你。

能用來跑 ChatGPT 的 Code Interpreter 嗎？

概念上類似，但定位不同。OpenSandbox 提供比照 ChatGPT Advanced Data Analysis 的 Code Interpreter 環境，能跑 Python、Java、JavaScript，但它是給 Agent 開發者用的基礎設施，不是終端使用者直接互動的產品。你需要自己架服務端、用 SDK 把 Agent 接上沙箱，才能讓終端使用者享受到「上傳檔案、模型在沙箱跑 code、回傳結果」這套體驗。

alibaba 與 opensandbox-group 是同一個專案嗎？

是。GitHub 上 alibaba/OpenSandbox 會 301 重導向到 opensandbox-group/OpenSandbox，是同一套程式碼從阿里巴巴內部品牌遷移到獨立 GitHub Organization 的過程。套件座標（Maven、npm、Go module）目前仍保留 alibaba 字樣，屬於命名空間還沒完全對齊的遷移期現象，不是 fork、也不是仿冒品。對照 README 為準、不要混用不同名稱空間的套件就不會踩雷。