CubeSandbox與E2B生產級Agent對比

我是 Dora。最近，我們在生產環境中有一個代理程式在執行工具呼叫。協調器沒有問題，LLM 也沒有問題，瓶頸出在沙盒層——每次代理程式需要執行一段生成的程式碼時，我們就要付出 200ms 的冷啟動時間，有時更長，有時佇列還會抽風。在每個工作階段約 40 次工具呼叫的情況下，這累積起來是相當可觀的牆鐘時間。

於是我開始尋找替代方案。目前大家似乎都在比較的是 CubeSandbox vs E2B。這篇文章是我花了兩週時間閱讀這兩個專案、部署其中一個，以及無法部署另一個（稍後會提到）之後的發現。

先說一個快速免責聲明：我與這兩個專案都沒有商業關係。兩者都是開源的。以下的比較是託管與自託管之間的取捨，而不是「好人 / 壞人」的評判。

CubeSandbox vs E2B 快速一覽

兩個專案以大致相同的方式解決同一個問題：啟動一個微型虛擬機器、執行不受信任的程式碼、再關閉它。兩者發布的效能數字也處於同一水準。實際的差異在於產品形式。

CubeSandbox 是騰訊雲於 2026 年 4 月以 Apache 2.0 授權發布的開源沙盒即服務堆疊，基於 RustVMM 和 KVM 構建。他們 repo 中的主要數據：冷啟動低於 60ms、每個沙盒約 5MB 記憶體、原生相容 E2B SDK（只需更換一個 URL 環境變數）。它以完整的可自託管堆疊形式發布，而不僅僅是一個函式庫。

E2B 同樣是開源的（也是 Apache 2.0），基於 Firecracker 微型虛擬機器構建，成立於 2023 年。使用預熱快照池後，沙盒初始化時間約為 150–200ms。自託管可透過 Terraform 腳本實現，但主要的發布形式是託管雲端服務——Hobby（免費，100 美元額度）、Pro（每月 150 美元 + 用量）、Enterprise（BYOC、本地部署）。自託管使用者是少數，託管是預設方案。

因此，真正的差異軸不是「哪個沙盒更好」，而是：

功能	CubeSandbox	E2B
授權	Apache 2.0	Apache 2.0
主要模式	自託管	託管 SaaS（可自託管）
底層 VMM	RustVMM + KVM	Firecracker (KVM)
發布的冷啟動時間	`<60ms`	~150–200ms
每個沙盒記憶體	~5MB	~5MB
SDK 相容性	E2B SDK 直接替換	原生 E2B SDK
GPU 支援	需要支援 KVM 的 x86_64 Linux；上游無原生直通	與 Firecracker 相同的 GPU 限制
運維負擔	你自己運行叢集	E2B 運行叢集（託管）

以上數字取自各專案自身的 repo 和發布說明，並非我自己跑的基準測試。請將其視為廠商發布的數據——方向性有參考價值，但不能替代你自己的測試。

託管與自託管的取捨

這才是真正的決策，而且主要不是技術問題。

選擇 E2B 的託管服務意味著你不需要再考慮微型虛擬機器核心、快照池、KVM 主機和協調器故障轉移。你也不需要考慮成本優化，因為定價已為你設定好。我所在的團隊試用了兩週 E2B Pro——整合確實只需要約一小時，SDK 很簡潔，節省的工程工時是實實在在的。

選擇 CubeSandbox 自託管意味著你自己掌管伺服器。成本變成「底層伺服器的費用是多少」，而不是「我們的用量曲線要花多少」。合規性更容易達成，因為資料不會離開你的邊界。但你也要自行負責值班輪換、核心更新、eBPF 策略調優。CubeSandbox 提供單節點和叢集設置的一鍵部署，這有所幫助，但「一鍵部署」和「生產就緒的叢集」並不是同一回事。

我在這裡停下來思考了幾天，因為答案確實取決於團隊的組成。一個四人新創公司下個季度要交付代理程式，可能不應該自己運行微型虛擬機器叢集。擁有基礎設施工程師和合規要求的團隊，可能應該這樣做。

相容性與遷移問題

CubeSandbox 的 E2B 相容性故事是 CubeSandbox 發布中最有趣的技術主張。根據他們的文件，現有的基於 E2B 的代理程式只需更換一個環境變數，就能將流量路由到自託管的 CubeSandbox 叢集——無需更改程式碼。我個人尚未將生產環境的 E2B 工作負載遷移過去，所以目前姑且相信這個說法，但可以透過閱讀雙方接受的 SDK 呼叫來驗證。表面積很小，雙方都使用相同的沙盒生命週期：建立、執行命令、執行程式碼、終止。

這就是它真正有用的地方：這意味著 CubeSandbox 本質上是 E2B SDK 的自帶基礎設施後端。你可以在 E2B 的託管雲端上開發，當用量達到合理規模時，再將指向轉向自己的叢集。雙方的鎖定論點都變弱了——我認為這對整個類別而言是健康的。

CubeSandbox 的優勝之處

控制權、成本結構與基礎設施所有權

對於任何運行量已大到託管沙盒定價開始出現在月度帳單上的代理程式團隊，CubeSandbox 是更誠實的選擇。你為自己已經熟悉的硬體付費。透過 eBPF (CubeVS) 的出口過濾可在核心層級進行設定。如果你的資料駐留規則要求「這不能離開我們的 VPC」，對自託管沙盒來說是 30 秒的對話，對託管沙盒來說則是更長的對話。

有一件事說得不夠多：自託管代理程式執行環境不是免費午餐。每次執行的邊際成本下降了，固定成本卻上升了。損益平衡點對每個團隊的用量曲線來說都是獨特的。在決定之前先算好數字。如果答案是「我們每月能省 300 美元，但每週要多花兩小時做運維工作」，那並不划算。

團隊應自行測試的效能與密度主張

CubeSandbox 發布了低於 60ms 的冷啟動時間，騰訊雲透過 HPCwire 的發布說明將其描述為「行業平均水準（150ms）的三分之一」。他們還聲稱單台物理機可運行 2,000 個以上的沙盒。這些數字來自騰訊雲內部的生產工作負載，而非合成基準測試——這比合成測試更好，但那仍然是他們的工作負載，不是你的。

在相信這些主要數字之前，我會測試以下幾點：

在你實際的快照大小下的冷啟動時間（5GB 的模板與 200MB 的模板表現不同）
p99 的並發行為，而不僅僅是平均值——CubeSandbox 發布了 50 並發下 67ms 的平均回應時間，這很有希望，但與 p99 不同
你的特定依賴項是否能在 RustVMM 的精簡核心上正常運行，不出意外

這是我的資料的終點。我在單台支援 KVM 的虛擬機器上部署了 CubeSandbox，大約半個下午就讓它開始提供沙盒服務。我尚未在發布說明中的密度數字下進行壓力測試。任何聲稱在這個專案公開三週後就做到這一點的人，可能是在誇大其詞。

E2B 仍然勝出的地方

CubeSandbox vs E2B 比較的另一半：如果你不想考慮基礎設施，E2B 勝出。這句話聽起來像是在輕視，但這才是實際的結論。

具體來說：

託管的 E2B SDK 更成熟。有更多食譜範例、更多 LangChain/LlamaIndex 整合，以及更長的追蹤記錄。
Manus、Perplexity 的程式碼分析、Hugging Face 的 Open R1——規模化的生產參考案例已經存在。CubeSandbox 在騰訊雲內部有生產參考案例，這是真實的，但外部案例研究仍在編寫中。
E2B 文件涵蓋桌面沙盒、從 Dockerfile 建立模板、檔案持久性以及開箱即用的 24 小時工作階段生命週期。CubeSandbox 更為簡樸——README 和範例涵蓋核心生命週期，而非長尾功能。
Firecracker 本身是一個已知量。AWS Lambda 在其上運行。Firecracker 專案自 2018 年起就在生產環境中運行。CubeSandbox 基於 RustVMM 的堆疊在公眾眼中較新，即使它在騰訊內部已經運行了一段時間。

如果你下個季度要交付 v1 代理程式產品，且沒有基礎設施人員，E2B 的託管方案是阻力更小的路徑。不用在沙盒叢集上費力的時間，就是花在代理程式本身的時間。對很多團隊來說，這值得每月 150 美元。

代理程式團隊的決策框架

經過兩週的研究，以下是我實際會使用的框架。這是我找到的最實用的 AI 代理程式沙盒比較捷徑之一：

每月沙盒使用量低於約 5 萬小時、無合規要求、無基礎設施團隊 → E2B 託管。不用繼續讀了。
用量超過此標準，或有嚴格的資料駐留要求，或你已在運行 Kubernetes/微型虛擬機器 → CubeSandbox 自託管。經濟帳翻轉了，而且你有能力運維它。
介於兩者之間 → 從 E2B 託管開始。用 SDK 構建。當帳單開始讓人心疼，或合規部門開始提問時，SDK 相容性意味著遷移只需更換一個 URL。這種靈活性是整個比較中最被低估的特性。
你需要在沙盒內進行代理程式推理的 GPU 直通 → 兩者都不太好。上游 Firecracker 原生不支援 GPU 直通，CubeSandbox 繼承了類似的限制。對於這種工作負載，請考慮 gVisor 或 Daytona。

我會抵制的思維框架是：「CubeSandbox 的技術更好，因此它獲勝。」微型虛擬機器沙盒的選擇是一個產品形式的選擇。在發布的規格上，技術大致相當。日常成本是運維層面的。

常見問題

以下是我在進行 CubeSandbox vs E2B 評估時，團隊成員不斷問我的問題。

CubeSandbox 是 E2B 的直接替換嗎？

對於 E2B SDK 的表面來說，是的——這是設計使然。該專案將自己定位為與 E2B 相容的執行環境，你只需更換一個環境變數。對於核心沙盒生命週期之外的功能（從 Dockerfile 建立模板、桌面沙盒、託管可觀測性），答案是「尚未」。

自託管實際上會增加多少工作量？

需要一台（或一組）支援 KVM 的主機、核心/映像管理、監控、快照池調優、網路出口策略以及值班。騰訊雲的發布說明描述了單節點和叢集設置的「一鍵部署」，但將其等同於生產級叢集是過於樂觀的。請規劃 1–2 週的設置時間，以及每週持續少量的人力投入。

哪些工作負載最能從微型虛擬機器沙盒中受益？

任何需要大規模針對不受信任的輸入執行模型生成程式碼的場景。普通 Docker 的共享核心風險是反對容器用於此目的的標準論點——每個主要的代理程式平台出於這個原因都已放棄共享核心隔離。如果你的代理程式只從固定的可信腳本允許清單中執行沙盒程式碼，你可能根本不需要微型虛擬機器。

團隊應該首先對哪些方面進行基準測試？

按此順序測試三件事：在你實際模板大小下的 p99 冷啟動時間；每美元硬體（自託管）或每美元帳單（託管）的沙盒密度；突發負載下的故障模式。主要數字——低於 60ms vs 約 150ms——是真實的，但它們描述的是廠商有利條件下的平均值。你的工作負載不會與任何一個廠商的工作負載相符，這才是進行基準測試的唯一理由。