60ms 冷启动、5MB 内存：腾讯开源的这个沙箱让 Docker 安全隔离像笑话

你让 AI Agent 执行代码，用什么隔离环境？

Docker。大多数人的第一反应。简单、轻量、大家都会用。

但你有没有想过，Docker 的隔离本质上是"共享内核"——所有容器跑在同一个 Linux 内核上，靠 Namespace 和 cgroup 做隔离。换句话说，如果一段 LLM 生成的恶意代码找到了内核漏洞，一个容器被攻破，整台机器都可能沦陷。

在 AI Agent 场景下，这个问题被放大了。Agent 执行的是不可信代码——模型生成的，可能是任何东西。你需要的是真正的硬件级隔离，而不是"大概率够用"的 Namespace 隔离。

腾讯云上周开源了 CubeSandbox，一个专门为 AI Agent 设计的安全沙箱服务。4.8K Star，基于 RustVMM 和 KVM 构建，60ms 冷启动，单实例内存开销不到 5MB，而且原生兼容 E2B SDK 接口。

这个项目值得好好聊聊。

本文提纲

1. 为什么 AI Agent 需要专用沙箱
2. CubeSandbox 的核心技术方案
3. 性能数据：与 Docker、传统 VM 的实测对比
4. 架构拆解：6 个组件各司其职
5. 4 步跑起来：从零到第一个沙箱
6. 谁该用，谁不该用

为什么 AI Agent 需要专用沙箱

AI Agent 执行代码和传统软件开发有个根本区别：代码来源不可信。

普通开发者写的代码，虽然也有 Bug，但至少意图是可控的。而 LLM 生成的代码，可能是 Prompt 注入的结果，可能是模型幻觉的产物，也可能是用户精心构造的攻击载荷。

这意味着你不能只考虑"正常代码会不会崩"，还得考虑"恶意代码能不能逃逸"。

Docker 的 Namespace 隔离在这件事上不够硬：

• 共享内核：所有容器共用宿主机内核。内核漏洞 = 全部容器沦陷
• Namespace 不是安全边界：Linux 内核文档自己都说了，Namespace 是为了"封装"，不是"安全隔离"
• 逃逸漏洞频发：CVE-2024-21626（runc）、CVE-2022-0492（cgroup）……每年都有容器逃逸漏洞

传统虚拟机（VM）能做到硬件级隔离，每个 VM 有独立内核，安全没问题。但 VM 太重了——启动要几秒到几十秒，内存开销动辄几百 MB。Agent 场景需要频繁创建、销毁沙箱，VM 根本跟不上节奏。

CubeSandbox 就是冲着这个矛盾来的：要 VM 级别的安全隔离，也要容器级别的启动速度和资源开销。

CubeSandbox 的核心技术方案

CubeSandbox 的底层技术栈是 KVM MicroVM + eBPF 网络隔离 + Rust 重写。

KVM MicroVM：真正的独立内核

每个沙箱都是一个轻量级虚拟机，运行独立的 Guest OS 内核。不是共享，不是模拟，是真的硬件虚拟化。任何一段代码最多只能影响自己所在的沙箱，不可能穿透到宿主机。

关键在于"Micro"——CubeSandbox 用 Rust 重写了虚拟化层（CubeHypervisor），基于 Cloud Hypervisor 做了定制裁剪，把 Guest OS 精简到最小可运行状态。没有 systemd，没有多余驱动，没有 GUI，只保留沙箱运行所需的最小环境。

快照克隆：跳过初始化

冷启动 60ms 的秘密在于不做冷启动。

CubeSandbox 维护一个预置的资源池（Resource Pool），沙箱模板预先构建好，放在内存里。创建新沙箱时，直接从模板做快照克隆（Snapshot Clone），跳过整个 OS 引导和初始化过程。用户拿到的是已经处于"Ready"状态的沙箱实例。

MERMAID_BLOCK_0

就像 Docker 的 layered image，但 CubeSandbox 用的是 CoW（Copy-on-Write）内存复用。一千个沙箱共享同一份基础内存页，只有各自修改的部分才单独分配。这就是单实例 5MB 内存开销的来源——大部分内存是共享的。

eBPF 网络隔离：内核态虚拟交换机

CubeSandbox 的 CubeVS 组件用 eBPF 在内核态做网络转发和隔离，比传统的用户态 bridge 或 iptables 性能更高、延迟更低。支持细粒度的出站流量过滤策略，可以精确控制每个沙箱能访问哪些网络资源。

性能数据：与 Docker、传统 VM 的实测对比

CubeSandbox 在 README 里给出了对比数据，我整理了一下：

维度	Docker 容器	传统 VM	CubeSandbox
隔离级别	低（共享内核 Namespace）	高（独立内核）	极高（独立内核 + eBPF）
启动速度	~200ms	秒级	< 60ms
内存开销	低（共享内核）	高（完整 OS）	< 5MB
部署密度	高	低	极高（单机数千实例）
E2B SDK 兼容	❌	❌	✅

几个值得注意的细节：

启动延迟：单并发 60ms。50 并发下平均 67ms，P95 90ms，P99 137ms。注意这是从"发起创建请求"到"沙箱完全可用"的端到端时间，包含了网络开销。在裸金属环境测试。

内存开销：≤ 32GB 规格的沙箱，基础内存开销都在 5MB 以内。规格增大时开销只略微上升，因为共享内存页不变，增加的主要是 CoW 的差量部分。

对比 Docker 的 200ms：Docker 的 200ms 看起来也不慢，但那是"容器启动"时间，不包含镜像拉取和初始化。而 CubeSandbox 的 60ms 是"拿来就用"的完整时间。更重要的是，Docker 便宜在共享内核——这恰恰是安全问题。

架构拆解：6 个组件各司其职

MERMAID_BLOCK_1

组件	职责
CubeAPI	兼容 E2B 的 REST API 网关，用 Rust 写的，替换 URL 就能从 E2B 无缝迁移
CubeMaster	集群编排调度器，接收 API 请求，分发到对应节点的 Cubelet
CubeProxy	反向代理，兼容 E2B 协议，把请求路由到对应沙箱实例
Cubelet	单节点管理组件，负责沙箱实例的完整生命周期（创建、暂停、销毁）
CubeVS	eBPF 内核态虚拟交换机，网络隔离和安全策略执行
CubeHypervisor & CubeShim	虚拟化层，管理 KVM MicroVM；CubeShim 实现 containerd Shim v2 接口，可以跟 Kubernetes 生态集成

整个架构的设计思路很清晰：API 层兼容 E2B 降低迁移成本，调度层支持单机到集群的弹性扩展，计算层用 Rust 保证性能和安全。

4 步跑起来：从零到第一个沙箱

CubeSandbox 的部署体验做得很顺滑。前提条件是一台开启了 KVM 的 x86_64 Linux 机器（WSL 2 也可以）。

第 1 步：克隆并准备环境

git clone https://github.com/tencentcloud/CubeSandbox.git
cd CubeSandbox/dev-env
./prepare_image.sh   # 下载并初始化运行环境
./run_vm.sh          # 启动环境

第 2 步：一键安装 CubeSandbox 服务

# 国内用户
curl -sL https://cnb.cool/CubeSandbox/CubeSandbox/-/git/raw/master/deploy/one-click/online-install.sh | MIRROR=cn bash

# 海外用户
curl -sL https://github.com/tencentcloud/CubeSandbox/raw/master/deploy/one-click/online-install.sh | bash

第 3 步：创建沙箱模板

cubemastercli tpl create-from-image \
  --image ccr.ccs.tencentyun.com/ags-image/sandbox-code:latest \
  --writable-layer-size 1G \
  --expose-port 49999 \
  --expose-port 49983 \
  --probe 49999

第 4 步：用 E2B SDK 跑代码

import os
from e2b_code_interpreter import Sandbox

with Sandbox.create(template=os.environ["CUBE_TEMPLATE_ID"]) as sandbox:
    result = sandbox.run_code("print('Hello from Cube Sandbox!')")
    print(result)

没错，这是标准的 E2B SDK 代码。唯一的区别是把 E2B_API_URL 指向本地 CubeAPI 地址。如果你之前在用 E2B 的付费服务，迁移成本就是改一个环境变量。

谁该用，谁不该用

适合用的场景：

• AI Agent 平台需要执行不可信代码——这是最核心的场景
• CI/CD 流水线需要更强的隔离——比 Docker 安全，比 VM 快
• 做强化学习训练（RL），需要频繁创建销毁沙箱环境——SWE-Bench 场景已有 Demo
• 已在用 E2B，想降成本或私有化部署——改个 URL 就行

不太适合的场景：

• 没有裸金属服务器——CubeSandbox 依赖 KVM，普通云虚拟机开不了嵌套虚拟化
• 只需要跑可信代码——Docker 足够，没必要上 MicroVM
• 需要 GPU 直通——目前 README 没提 GPU 支持

限制条件：只支持 x86_64，需要 KVM 硬件虚拟化支持。ARM 支持暂时没有。

CubeSandbox 的开源对 AI Agent 生态是个好事。之前要在安全隔离和性能之间二选一，现在有了第三个选项。而且 Apache 2.0 许可证，商用也没问题。

腾讯云已经在自家生产环境跑过大规模验证，稳定性能打几分得你自己测，但至少不是玩具项目。4.8K Star 和 321 Fork，社区热度也不低。

如果碰巧你手里有一台裸金属服务器，花半小时搭起来试试。至少，下次再有人跟你说"Docker 隔离够了"的时候，你可以拿出点不同的东西聊聊。

---

作者: itech001
来源: 公众号：AI人工智能时代
主页: https://www.theaiera.cn，每日分享最前沿的AI新闻和技术。

本文首发于 AI人工智能时代，转载请注明出处。