Tencent 開源 CubeSandbox：60ms 冷啟動，AI Agent 沙箱基礎設施的新基準線

AI Agent 需要一個地方執行 LLM 生成的程式碼——這個地方必須快、必須隔離、必須能大規模平行部署。2026 年 4 月 21 日，Tencent Cloud 以 Apache 2.0 授權公開了他們在生產環境中已靜默運行多年的答案：CubeSandbox。

為什麼 Agent 沙箱是個難題

Agent 生成的程式碼在執行前，你對它做的事情幾乎一無所知——它可能刪除檔案、存取網路、嘗試提權。容器（Docker）提供命名空間隔離，但共享 Host Kernel，存在容器逃逸風險。傳統虛擬機提供核心級隔離，但冷啟動要數秒，記憶體開銷動輒數十 MB。

CubeSandbox 選擇了第三條路：MicroVM，以 RustVMM 和 KVM 為基礎，給每個 sandbox 一個獨立的 Guest OS kernel，然後把啟動時間壓進 60ms。

核心數字（已在 GitHub 官方 benchmark 驗證）

冷啟動：單一並發低於 60ms；50 並發平均 67ms，P95 = 90ms，P99 = 137ms
記憶體佔用：每實例低於 5MB（即使 sandbox 規格設定達 32GB）
部署密度：單台 96 核實體機器可同時運行 2,000+ 個 sandbox
E2B 相容性：100% 相容 E2B Python SDK 與 OpenAI Python SDK，替換只需改一個環境變數

這些數字不只是 benchmark——Tencent Cloud 表示，在開源之前，CubeSandbox 已在 Tencent Cloud 生產環境中處理超過 100 億次呼叫。外部客戶 MiniMax 使用它在 Agentic RL 訓練中每分鐘調度數十萬個 sandbox 實例。Tencent Cloud 自己的 Yuanbao AI 程式設計場景遷移至 Cube 後，資源核心小時消耗下降 95.8%。

技術實作：速度來自哪裡

冷啟動壓縮到 60ms 依賴四個技術組合：

資源池預配置（Resource Pool Pre-provisioning）：預先初始化 MicroVM 資源，繞過啟動時的冷初始化
快照複製（Snapshot Cloning）：從已知狀態快速複製，而非從零啟動
EPT Lazy Load：延遲頁表初始化，降低啟動階段的 overhead
鎖優化：低層級鎖競爭調優

記憶體佔用壓到 5MB 則依靠 Rust 重寫（消除 GC overhead）、Copy-on-Write（CoW）記憶體重用，以及 reflink 磁碟共享。

網路隔離由 CubeVS 負責，以 eBPF 在 kernel 層執行沙箱間的嚴格網路隔離與細粒度 egress 流量過濾。

GitHub 目前（2026-04-24）有 1.3k stars，89 forks，已發布 v0.1.0。

這對開發者意味著什麼

最直接的影響是：自建 AI Agent 沙箱基礎設施的成本大幅降低。E2B 是這個市場目前的主要 SaaS 提供商，Cube 完全相容其 SDK，意味著遷移的工程成本幾乎為零——只換一個 URL 環境變數。

「一鍵部署到私有環境」是 Tencent 強調的差異化點。對於需要資料不出境、或希望控制沙箱基礎設施的企業，這是一個實質選項。

但需要說清楚的是：CubeSandbox 是 infrastructure，不是 hosted service。你還需要自己管理部署、擴縮容、監控與維護。如果你只是想要「能用的 sandbox」而不想碰基礎設施，E2B 的 SaaS 仍然有其位置。

「開源」背後的商業邏輯

Tencent 選擇在這個時間點開源 CubeSandbox，和大量中國科技公司的開源策略一致——用高品質開源項目建立技術信任度、吸引開發者生態、並為 Tencent Cloud 的商業服務導流。

CubeSandbox 的生產驗證規模（100 億呼叫）是真實的護城河，但開源之後，社群是否會形成、貢獻者是否會進入、E2B 是否會改變定價策略，都還是未知數。這是一個起跑點，而不是終局。