什麼是CubeSandbox？AI Agent的沙盒解決方案
CubeSandbox是一個專為AI Agent打造的開源沙盒，以速度、隔離性與E2B相容性為核心。以下是開發者應該關注它的原因。
上週我花了幾個晚上閱讀 CubeSandbox 的程式碼庫。不是在生產環境中執行它——這個專案自 4 月 21 日才公開，而我對一個工具的判斷通常需要更多的實際執行時間。但其架構決策足夠有趣，值得在新聞週期接管框架之前，記錄下它們對代理基礎設施的意涵。
如果你構建的代理需要執行不受信任的程式碼——任何涉及程式碼解釋、瀏覽器自動化、強化學習訓練，或任何「思考 → 執行 → 反饋」循環（模型決定要執行什麼）的場景——沙箱基礎設施不是次要考量。它是在負載下最先崩潰的部分。CubeSandbox 是其中一個答案。這篇文章探討它是什麼、為何設計選擇至關重要，以及哪些團隊應該評估它。不是關於你是否應該切換。
CubeSandbox 是什麼，以及騰訊開源了什麼
核心架構與定位
CubeSandbox 是一個用於 AI 代理的開源沙箱服務，由騰訊雲於 2026 年 4 月 21 日在 Apache 2.0 授權下發布。GitHub 上的程式碼庫 包含完整的技術棧：API 閘道、協調器、節點代理、網路層、Hypervisor。不是 SDK，不是託管服務的封裝。你需要自行部署。
技術聲明，直接取自 README：
- 完全可用的沙箱冷啟動時間低於 60ms。
- 每個實例記憶體開銷低於 5MB。
- 96 核伺服器上約 2,000 個並發沙箱。
- 透過 RustVMM + KVM 實現硬體級別隔離，每個沙箱都有自己的 Guest 核心。
- E2B SDK 協議相容性——只需更換一個環境變數即可完成遷移。
程式碼庫大約一半是 Rust，支援層使用 Go 和 C。架構概覽文件 將其分解為：CubeAPI（E2B 相容的 REST 閘道）、CubeMaster（叢集協調器）、CubeProxy（請求路由器）、Cubelet（節點生命週期管理器）、CubeVS（基於 eBPF 的網路隔離），以及 CubeHypervisor + CubeShim（虛擬化層；CubeShim 實現了 containerd 的 Shim v2）。README 中列出了上游項目：Cloud Hypervisor、Kata Containers、virtiofsd 和 containerd-shim-rs——對於這個領域的人來說不應感到意外。
實際上：它是一個與 Firecracker 同屬架構家族的 microVM 沙箱，但採用了獨立的 VMM 實現。實現品質在騰訊的裸機測試平台之外是否依然可靠，是個開放性問題。這從 README 中無法得知。
為何 E2B 相容性很重要
CubeSandbox 中最有趣的設計選擇不是 60ms 冷啟動。而是刻意的 E2B SDK 相容性。
E2B 已幾乎成為代理程式碼執行的預設選擇。Manus 使用它。大量需要執行模型生成程式碼的 LLM 應用首先考慮它。其 SDK 協議——from e2b_code_interpreter import Sandbox，指向 URL，執行程式碼——是這個類別中最接近事實標準的介面。
透過鏡像該協議，CubeSandbox 繞過了大多數「替代方案」面臨的問題：讓開發者學習新的 SDK。遷移路徑是一個環境變數。現有的代理程式碼無需更改。如果你已經基於 E2B 構建，測試 CubeSandbox 的阻力大約是一個下午，而不是一個季度。
閱讀程式碼庫時，我在這裡停頓了一下。這種相容性的目標不是證明 CubeSandbox「更好」。而是讓實驗成本低廉。這是更明智的賭注。
為何沙箱在代理基礎設施中很重要
隔離、啟動時間和並發性
沙箱同時為代理系統做三件事，你不能犧牲其中一個而不損害其他的。
隔離。 當模型生成程式碼時，你在執行之前不知道它做什麼。共享主機核心的容器是不夠的。Guest 核心中的一個提權漏洞，或一次 Docker 逃逸，代理就能接觸到主機檔案系統、主機憑證、主機網路。MicroVM 透過為每個沙箱提供自己的 Guest 核心來解決這個問題——硬體虛擬化邊界而非命名空間邊界。這與 AWS 開源 Firecracker 用於 Lambda 時的論點相同：對於多租戶程式碼執行，容器的隔離牆太薄。
啟動時間。 決定「我將執行這個 Python 腳本來檢查輸出」的代理，是在毫秒級的時鐘預算內做出這個決定的。如果沙箱需要兩秒才能啟動，反饋循環已經中斷。即使模型很快，產品看起來也很慢。Firecracker 實現了約 125ms 的啟動時間，使 microVM 在無伺服器場景中切實可行。E2B 的託管服務在預熱池的情況下報告約 150–200ms。CubeSandbox 聲稱透過預先配置的資源池和快照克隆實現低於 60ms。如果這個數字成立，它將改變哪些類型的代理循環是實際可行的。我會在自己的硬體上驗證它，才會引用這個數字。
並發性。 每個用戶一個沙箱是簡單的情況。每個代理步驟一個沙箱，每個用戶，數千個代理同時在運行，這才是困難的情況。約束從「一個啟動多快」轉移到「一台機器上能運行多少個」。5MB 每實例的數字，加上 96 核機器上 2,000+ 個，就是密度論點。它是否能在實際工作負載下存活——實際載入 Python 解釋器、瀏覽器、依賴項的沙箱——同樣是個開放問題。
這三者相互制衡。更強的隔離通常意味著更重的虛擬機、更慢的啟動、更低的密度。有趣的 microVM 系統拒絕這種權衡。
為何這在規模化時成為產品瓶頸
對於單用戶原型，這些都不重要。在代理後面放一個 Docker 容器，接受安全債務，發布。成本是不可見的，直到它變得可見。
它在三個時間點變得可見，這三個我都親眼見過：
每步延遲。 在單個推理鏈中呼叫沙箱 20 次的代理，繼承了 20 次冷啟動延遲。每次 200ms，就是 4 秒純基礎設施延遲加到用戶感知的響應時間上。模型沒有變慢。基礎設施變慢了。
多租戶並發。 一旦付費用戶同時運行代理，「每個用戶一個虛擬機」就停止線性擴展。托管費用的增長速度超過收入。要麼共享核心並接受隔離風險，要麼接受更差的利潤率。除了改變底層原語，沒有第三個選項。
實驗到生產的差距。 在本地一次一個沙箱時一切正常。生產環境揭示了快照預熱池的大小是有限的，在負載下冷啟動會回來，你沒有考慮到的 eBPF 網路策略在沙箱相互通信或不應該通信時開始變得重要。這是發布文章中被低估的無趣部分。
CubeSandbox 押注於硬體隔離、低記憶體開銷和低於 60ms 的啟動時間可以同時實現，並且生產團隊一旦碰到這三道牆就會在意。它是否成功是執行和採用的函數。兩者仍是開放問題。
哪些人應該評估 CubeSandbox，哪些人不應該
值得認真看看：
- 已經在使用 E2B 並遇到成本或並發限制，同時考慮自行托管的團隊。遷移確實只需一行程式碼的更改。
- 構建內部代理平台，且有合規性或資料駐留要求而排除第三方雲端的基礎設施團隊。Apache 2.0 + 自行托管是前提條件。
- 任何以高沙箱創建速率運行強化學習訓練循環的人，其中冷啟動成本存在於內部訓練循環中。100ms 的改善乘以數百萬個訓練回合是真實的資金節省。
- 當前設置是「帶強化標誌的 Docker 容器」且其威脅模型已悄然超越這一設置的團隊。切換的誠實時機是在事件發生之前，而非之後。
目前可能跳過：
- 原型和單用戶演示。在低呼叫量下，建立 microVM 叢集的成本是不合理的。
- 沒有裸機存取或支援 KVM 的虛擬機的團隊。硬體要求是真實的——x86_64 Linux 搭配 KVM。不支援巢狀虛擬化的標準雲端虛擬機不符合開箱即用的資格，但 PVM 路徑拓寬了這一點。
- 任何深度使用非 E2B SDK 的人，其中遷移成本超過執行時節省。相容性有幫助；但它並不能完全消除切換成本。
這就是我從閱讀程式碼和文件中能確認的全部。其餘的需要生產執行時間，而我還沒有把它放到那裡。
常見問題
CubeSandbox 解決什麼問題？
它是一個在隔離環境中執行 AI 生成程式碼的執行時，具備低延遲、高並發，且不共享主機核心。它針對的問題是每個代理平台最終都會遇到的：容器對於不受信任的程式碼來說太容易洩漏，傳統虛擬機太慢太重，現有的 microVM 選項要麼是專有的，要麼在操作上很複雜。
它與純容器方法有何不同？
純容器方法共享主機核心。Guest 核心漏洞可到達主機。CubeSandbox 透過基於 KVM 的硬體虛擬化為每個沙箱提供自己的 Guest 核心——這是一個更強的邊界，可以防禦 LLM 在出錯時或用戶試圖使其出錯時可能發出的程式碼類型。報告的記憶體開銷（每個實例低於 5MB）也縮小了歷史上使虛擬機在容器旁邊不具經濟效益的密度差距。
為何 E2B 相容性很重要？
因為嘗試新沙箱的成本通常是一個遷移項目，而不是試用本身。E2B 的 SDK 有足夠的採用率，相容性讓團隊能透過更改一個環境變數來測試 CubeSandbox。這就是「我下個季度再評估它」和「我今晚就把它跑起來」之間的區別。協議選擇在採用方面承擔了繁重的工作。
哪些團隊應該首先測試它？
已經在以不小的規模使用 E2B 的團隊、有合規限制需要自行托管的團隊，以及運行緊密代理循環且冷啟動延遲出現在用戶感知響應時間中的團隊。規模較小的用戶可以等待——早期採用的成本超過節省。
結論
代理底層的基礎設施正在成為一個真實的類別。在 2024 年大部分時間以及進入 2025 年期間，沙箱化是一個次要考量——用任何方便的東西來處理。現在將代理放在真實用戶面前的團隊正在發現，沙箱的選擇塑造了從每請求延遲到每用戶利潤的一切。
CubeSandbox 並未改變底層的物理規律。MicroVM 已經是正確的架構答案；開放的問題始終是實現品質和採用阻力。程式碼庫在第一點聲稱具有競爭力的數字，並透過原生使用 E2B 的協議來解決第二點。這些數字是否在騰訊測試平台之外的生產環境中依然成立，是接下來幾個月將揭示的事情。
我計劃在測試叢集上部署它，並對照我自己的工作負載驗證冷啟動聲明。待驗證。有了數據後我會回來討論這個話題。
相關文章：
