CubeSandbox:腾讯云出品、专为AI智能体打造的亚60毫秒MicroVM沙箱

CubeSandbox 是一个开源、兼容 E2B 的沙箱服务,基于 RustVMM 和 KVM 构建。它能在不到 60 毫秒内为AI智能体代码执行创建硬件级隔离的 MicroVM,单个沙箱内存开销不到 5MB。

  • ⭐ 10739
  • Rust
  • KVM
  • eBPF
  • Apache-2.0
  • 更新于 2026-07-29

Orca:并行运行 Claude Code、Codex 与 Cursor 的智能体开发环境(ADE)herdr:为同时运行多个 AI 智能体打造的终端复用器

CubeSandbox架构图,展示CubeAPI、CubeMaster、CubeProxy、Cubelet、CubeVS和CubeEgress组件
CubeSandbox 架构图 —— 官方图示来自 github.com/TencentCloud/CubeSandbox

CubeSandbox 是什么? #

CubeSandbox 解决的是比本站其他多智能体工具更窄、也更深的一个问题:不是"怎么同时运行多个编码智能体",而是"怎么让AI智能体执行不可信代码时,碰不到它不该碰的东西"。这是腾讯云给出的开源方案——一个基于 RustVMM 和 KVM 构建的高性能沙箱服务,每个沙箱都在轻量级 MicroVM 中拥有自己独立的内核。

🔗 GitHubhttps://github.com/TencentCloud/CubeSandbox 🌐 官网https://cubesandbox.com

腾讯云于 2026 年 4 月以 Apache-2.0 协议(附腾讯版权声明)发布 CubeSandbox,到 2026 年 7 月底已达到 1.07 万以上 GitHub star,并被收录进 CNCF Landscape 的 AI 原生基础设施类目下。


为什么要用 MicroVM,而不是直接用容器? #

Docker 容器靠共享内核的命名空间机制做隔离——速度快,但一台主机上所有沙箱仍共用一个内核,一旦某个沙箱出现内核级漏洞,就可能变成整台主机的问题。传统虚拟机用每个实例独立内核解决了这个问题,但代价是启动时间(以秒计)和内存占用都大得多。

CubeSandbox 的思路是:用 KVM MicroVM 加上激进的资源池化,能不能在不付出传统虚拟机那种成本的前提下,拿到接近虚拟机级别的隔离:

指标Docker 容器传统虚拟机CubeSandbox
隔离级别低(共享内核命名空间)高(独立内核)独立内核 + eBPF
启动速度约200毫秒以秒计亚60毫秒(单并发)
内存开销低(共享内核)高(完整操作系统)单沙箱不到5MB(项目自报)
部署密度单节点数千个(项目自报)
兼容 E2B SDK部分可直接替换

以上是项目自己发布的基准测试数字(裸金属环境,详见其性能基准测试报告),本文未做独立复现验证。

CubeSandbox在不同沙箱规格下的内存开销图表
不同规格下的内存开销 —— 官方图表来自 github.com/TencentCloud/CubeSandbox


核心功能 #

功能说明
超快启动资源池化+快照克隆跳过冷启动开销,平均亚60毫秒
硬件级隔离每个沙箱在自己的 KVM MicroVM 中拥有独立内核
兼容 E2B SDK改一个环境变量即可用 CubeSandbox 替换 E2B Cloud
高密度部署内核共享+写时复制(CoW)让单沙箱开销不到5MB;支持暂停/恢复
网络安全基于 eBPF 的沙箱间隔离与出站流量过滤,配合支持按域名/路径/方法策略的 L7 安全代理
快照与回滚百毫秒级粒度的检查点;可随时回滚或从某个保存状态分叉出新沙箱
Volume 框架兼容 E2B 的可插拔存储卷,拥有独立生命周期,可在多个沙箱间共享
ARM64 支持除 x86_64 外,编译、构建、部署全链路原生支持 ARM64

架构 #

组件职责
CubeAPI高并发 REST API 网关(Rust),兼容 E2B
CubeMaster集群编排器——把请求分发给对应的 Cubelet,管理资源调度和集群状态
CubeProxy反向代理,把 E2B 协议请求路由到对应的沙箱实例
Cubelet单节点本地调度组件,管理该节点上全部沙箱实例的完整生命周期
CubeVS基于 eBPF 的虚拟交换机,提供内核级网络隔离
CubeEgress基于 OpenResty 的出站安全网关——域名过滤、凭证注入、访问审计
CubeHypervisor / CubeShim虚拟化层——CubeHypervisor 管理 KVM MicroVM,CubeShim 实现 containerd Shim v2 API,接入标准容器运行时

部署 #

CubeSandbox 需要支持 KVMx86_64 Linux 主机。项目文档了三条路径:

  1. PVM(云主机) —— 推荐路径;可在普通云主机上部署,不需要裸金属或嵌套虚拟化
  2. 裸金属 —— 直接部署,包括用 Terraform 一键搭建腾讯云生产集群
  3. 开发环境(QEMU 虚拟机) —— 用于没有 KVM 访问权限时的测试,项目明确标注因性能较差不建议用于生产

部署完成后自带一个 Web 控制台:

http://<控制节点IP>:12088

进去之后:先看 Overview 页面确认节点健康,再从 模板商店 装一个模板,然后创建沙箱、实时查看日志流。

CubeSandbox在50并发下的沙箱创建基准测试
并发下的沙箱创建延迟 —— 官方图表来自 github.com/TencentCloud/CubeSandbox


使用场景 #

1. 安全运行不可信的智能体代码 #

给每个AI编码智能体生成的代码分配独立 MicroVM,而不是共享内核的容器,这样即使某个沙箱被攻破也无法波及主机或其他沙箱。

2. 高密度多租户智能体平台 #

不到5MB的开销加上暂停/恢复支持,是为了让平台能在单台物理节点上更经济地运行大量智能体会话。

3. 迁移出 E2B Cloud #

出于成本或数据驻留的考虑,把现有基于 E2B SDK 的代码指向自建的 CubeSandbox 集群,而不是 E2B 的托管服务。

4. 强化学习训练环境 #

项目自己的演示视频里包含一个 SWE-Bench 强化学习用例,利用快速的快照/克隆/回滚在训练回合之间重置智能体环境。


路线图上还没做完的部分 #

根据项目公开的路线图,有几项尚未完成:完整的 E2B API 对等兼容(目前只是部分实现)、基于 CRD/Operator 的 Kubernetes 原生部署(目前是基于 Helm)、跨节点暂停/恢复,以及针对崩溃虚拟机或卡住的 shim 进程的自动故障恢复。在把生产基础设施押在这些具体功能上之前,值得先确认一下进度。


相关仓库 #

仓库用途
E2BCubeSandbox 对标兼容的沙箱 SDK/协议
firecracker-microvmAWS 的 MicroVM 技术,业内另一种类似的基于 KVM 的隔离方案

相关文章 #


结语 #

CubeSandbox 押注的是:AI智能体执行代码需要虚拟机级别的隔离,但不该付出虚拟机级别的成本——通过 KVM MicroVM 实现独立内核、亚60毫秒启动、单沙箱开销不到5MB,外面包一层兼容 E2B 的 API。它是基础设施级别的工具,不是笔记本上的玩具:需要真正的 KVM 访问权限,面向的是需要规模化运行智能体代码执行的团队,而不是想利用午休时间试试看的独立开发者。

最适合谁:正在搭建AI智能体平台、需要以高密度、强隔离方式运行不可信的、由智能体生成的代码,同时又不想承担传统虚拟机全部开销的团队。

GitHubhttps://github.com/TencentCloud/CubeSandbox


自建部署推荐基础设施 #

CubeSandbox 明确需要支持 KVM 的硬件——不是所有档位的 VPS 都支持嵌套虚拟化:

  • DigitalOcean —— 覆盖 14 个以上全球区域,60 天 200 美元免费额度;部署 CubeSandbox 前先确认所选 droplet 规格支持 KVM/嵌套虚拟化。
  • HTStack —— 香港 VPS,从中国大陆访问延迟低。这正是 dibi8.com 所在的机房,经过生产环境实战验证。

以上为联盟链接——不会让你多花一分钱,但能帮助 dibi8.com 持续运营。

最后更新:2026-07-29

参考与来源 #

📦 出现在以下合集中

💬 留言讨论