你让 AI Agent 执行代码，用什么隔离环境？
Docker。大多数人的第一反应。简单、轻量、大家都会用。
但你有没有想过，Docker 的隔离本质上是"共享内核"——所有容器跑在同一个 Linux 内核上，靠 Namespace 和 cgroup 做隔离。换句话说，如果一段 LLM 生成的恶意代码找到了内核漏洞，一个容器被攻破，整台机器都可能沦陷。
在 AI Agent 场景下，这个问题被放大了。Agent 执行的是不可信代码——模型生成的，可能是任何东西。你需要的是真正的硬件级隔离，而不是"大概率够用"的 Namespace 隔离。
腾讯云上周开源了 CubeSandbox，一个专门为 AI Agent 设计的安全沙箱服务。4.8K Star，基于 RustVMM 和 KVM 构建，60ms 冷启动，单实例内存开销不到 5MB，而且原生兼容 E2B SDK 接口。
这个项目值得好好聊聊。
AI Agent 执行代码和传统软件开发有个根本区别：代码来源不可信。
普通开发者写的代码，虽然也有 Bug，但至少意图是可控的。而 LLM 生成的代码，可能是 Prompt 注入的结果，可能是模型幻觉的产物，也可能是用户精心构造的攻击载荷。
这意味着你不能只考虑"正常代码会不会崩"，还得考虑"恶意代码能不能逃逸"。
Docker 的 Namespace 隔离在这件事上不够硬：
传统虚拟机（VM）能做到硬件级隔离，每个 VM 有独立内核，安全没问题。但 VM 太重了——启动要几秒到几十秒，内存开销动辄几百 MB。Agent 场景需要频繁创建、销毁沙箱，VM 根本跟不上节奏。
CubeSandbox 就是冲着这个矛盾来的：要 VM 级别的安全隔离，也要容器级别的启动速度和资源开销。
CubeSandbox 的底层技术栈是 KVM MicroVM + eBPF 网络隔离 + Rust 重写。
每个沙箱都是一个轻量级虚拟机，运行独立的 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 内存开销的来源——大部分内存是共享的。
CubeSandbox 的 CubeVS 组件用 eBPF 在内核态做网络转发和隔离，比传统的用户态 bridge 或 iptables 性能更高、延迟更低。支持细粒度的出站流量过滤策略，可以精确控制每个沙箱能访问哪些网络资源。
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 便宜在共享内核——这恰恰是安全问题。
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 保证性能和安全。
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 的付费服务，迁移成本就是改一个环境变量。
适合用的场景：
不太适合的场景：
限制条件：只支持 x86_64，需要 KVM 硬件虚拟化支持。ARM 支持暂时没有。
CubeSandbox 的开源对 AI Agent 生态是个好事。之前要在安全隔离和性能之间二选一，现在有了第三个选项。而且 Apache 2.0 许可证，商用也没问题。
腾讯云已经在自家生产环境跑过大规模验证，稳定性能打几分得你自己测，但至少不是玩具项目。4.8K Star 和 321 Fork，社区热度也不低。
如果碰巧你手里有一台裸金属服务器，花半小时搭起来试试。至少，下次再有人跟你说"Docker 隔离够了"的时候，你可以拿出点不同的东西聊聊。
作者: itech001
来源: 公众号：AI人工智能时代
主页: https://www.theaiera.cn，每日分享最前沿的AI新闻和技术。
本文首发于 AI人工智能时代，转载请注明出处。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。