AI Agent 代码执行沙箱横评：当不可信代码需要跑起来，我们到底有多少选择？

写在前面

2024 年之后，AI Agent 成了所有技术团队绕不开的话题。不管是做 Copilot、做自动化运维、做 SWE-Bench 代码修复，还是做 RL 训练环境，一个核心问题始终存在：模型生成的代码，你敢直接跑在宿主机上吗？

答案是显而易见的——不敢。

一段 rm -rf / 就能让你整个服务瘫痪，一个 curl http://internal-api/admin/delete-all 就能清空生产数据库，一个死循环就能把 CPU 吃满导致整个集群不可用。这些不是危言耸听，而是每一个让 AI 执行过代码的团队都认真思考过的问题。

所以我们需要沙箱。问题变成了：市面上的沙箱方案那么多，到底哪一个适合你的场景？

这篇文章，我花了将近两周时间，在本地 WSL 环境完整部署并实测了 CubeSandbox，同时对照测试了 Docker、E2B、Daytona 几个主流方案。

项目地址：github.com/TencentCloud/CubeSandbox

我想用真实的操作过程和数据，帮你理清这些方案的差异。

一、为什么 AI 代码执行必须要有沙箱？

先说结论：任何直接在宿主机或主服务进程内执行模型生成代码的行为，都是生产事故的预备役。

具体来说，不可信代码执行面临的风险包括但不限于：

风险类型	具体表现	后果
文件系统越权	读写 `/etc/passwd`、`.env` 文件、数据库文件	密钥泄露、配置篡改
网络访问滥用	扫描内网端口、调用内部 API、向外发送数据	数据泄露、内网渗透
资源占用失控	死循环、内存泄漏、fork 炸弹	服务不可用、主机宕机
危险命令执行	`rm -rf`、`chmod 777`、安装恶意软件	系统损坏、持久化后门
侧信道攻击	通过 `/proc`、`/sys` 读取宿主机信息	信息收集、漏洞利用

理想的 AI 代码执行沙箱需要满足以下要求：

隔离性：沙箱内的代码不能访问宿主机的文件系统、网络、进程空间
可销毁性：执行完毕后，沙箱及其所有状态能够被完全清除
可控的网络访问：能精确控制沙箱能否联网、能访问哪些地址
启动速度足够快：Agent 任务通常是短平快的，启动延迟直接影响用户体验
资源开销可控：单机要能跑足够多的沙箱实例，成本才压得住
接入成本低：最好能复用现有的 SDK 和调用方式，迁移成本小

带着这些要求，我们来看市面上都有哪些选择。

二、参评选手一览

本次横评覆盖了六类主流方案，它们代表了当前 AI 代码执行的几种主要技术路线：

2.1 方案总览

方案	技术路线	隔离模型	部署方式	代表产品
MicroVM 沙箱	KVM/Firecracker 虚拟化	独立内核	自托管	CubeSandbox
托管云沙箱	云端托管 MicroVM/容器	以官方说明为准	SaaS	E2B
Agent 平台	云端开发环境 + Agent 能力	以官方说明为准	SaaS/平台化	Daytona
开源通用沙箱	容器/K8s runtime 抽象层	Docker / K8s	自托管	OpenSandbox
容器方案	Linux Namespace + cgroup	共享宿主内核	自托管	Docker
传统虚拟机	QEMU/KVM 完整虚拟机	独立内核	自托管/云主机	传统 VM

2.2 各方案定位简述

CubeSandbox 是腾讯云开源的 AI Agent 安全沙箱项目，基于 KVM MicroVM 技术。每个沙箱拥有独立的 Linux 内核，通过 XFS reflink 实现 CoW 快照，支持 Snapshot、Clone、Rollback 等高级状态管理能力。它兼容 E2B SDK 接口，支持自托管部署。

E2B 是目前最知名的托管式 AI 代码执行沙箱服务。开发者通过 SDK 即可创建云端沙箱执行代码，无需关心底层基础设施。它的优势是接入简单，开箱即用；缺点是数据要走他们的服务器，且无法自托管。

Daytona 定位更偏向于"Agent 的计算机"，提供完整的云端开发环境和代码执行能力。它更像是一个面向 Agent 的 Cloud IDE + 执行环境的组合。

OpenSandbox 是一个开源的通用沙箱平台，支持 Docker 和 Kubernetes 作为底层运行时。它的定位是做一个标准化的沙箱抽象层，让上层应用不关心底层是 Docker 还是 K8s。

Docker 是最广泛使用的容器方案。它轻量、快速、生态成熟，但共享宿主内核的特性意味着隔离性不如 MicroVM 方案。对于可信或低风险场景，Docker 仍然是最佳选择。

传统 VM（如 QEMU/KVM）提供最强的隔离性，但启动速度通常在秒级甚至十秒级别，资源开销也远大于容器和轻量级 MicroVM。

三、本地部署与验证

本节为部署过程概要。详细的逐步截图和踩坑记录可以参考项目官方文档和社区教程，这里只保留关键节点，快速进入后续的性能评测环节。

3.1 测试环境

我的测试机器配置如下，后续所有 CubeSandbox 数据均来自此环境：

检测项目	实测详情
操作系统	Windows 10 Home China + WSL2 Ubuntu 24.04 LTS
CPU	Intel Core Ultra 7 255H, 16 vCPU
内存	15Gi RAM + 4.0Gi Swap
KVM 虚拟化	`/dev/kvm` 可用, nested=Y
Docker	Engine 29.3.0, Compose v5.1.0

由于 WSL 与裸金属在 I/O 调度和内存管理上的客观差异，本文数据定位为「功能验证和趋势参考」。生产容量规划请参考项目仓库中基于腾讯云 BMI5 裸金属实例的 benchmark。

3.2 部署要点

部署过程主要分四步，每一步都有一个硬性前置条件：

Step 1 — 环境准备：确保 systemd 为 PID 1、KVM 可用、Docker 已安装。其中 KVM 是 CubeSandbox 能跑 MicroVM 的前提，没有 /dev/kvm 则无法继续。

Step 2 — XFS 文件系统：CubeSandbox 依赖 XFS reflink 做 CoW 快照。WSL 默认 ext4 不满足要求，需创建 loopback XFS 镜像并挂载到 /data/cubelet：

sudo fallocate -l 80G /cubelet-xfs.img
sudo mkfs.xfs -f -m reflink=1 /cubelet-xfs.img
sudo mount -o loop,pquota /cubelet-xfs.img /data/cubelet

Step 3 — 一键安装：一条命令完成发布包下载、镜像拉取、服务启动：

NODE_IP="$(hostname -I | awk '{print $1}')"
curl -sL https://cnb.cool/CubeSandbox/CubeSandbox/-/git/raw/master/deploy/one-click/online-install.sh 
  | MIRROR=cn bash -s -- --node-ip="${NODE_IP}"

Step 4 — 验证：确认 systemd target active、容器正常运行、health endpoint 有响应。然后通过 WebUI (http://127.0.0.1:12088) 登录管理界面。

四、创建代码执行模板并验证基础能力

本章为 CubeSandbox 基础使用流程的简要概述。模板创建、SDK 配置、代码执行、网络策略等详细操作步骤在官方文档和社区中已有大量教程，这里只保留核心要点，快速验证沙箱可用性后进入性能评测环节。

4.1 快速上手流程

CubeSandbox 的使用分为三步：创建模板 → SDK 调用 → 执行代码。

第一步：从镜像创建模板

cubemastercli tpl create-from-image 
  --image cube-sandbox-cn.tencentcloudcr.com/cube-sandbox/sandbox-code:latest 
  --writable-layer-size 1G 
  --expose-port 49999 
  --expose-port 49983 
  --probe 49999

构建完成后通过 cubemastercli tpl list 查看模板 ID（记下 READY 状态的 ID，后续调用需要）。

第二步：配置 Python SDK

CubeSandbox 兼容 E2B 的 Python SDK，已有 E2B 用户可零成本迁移：

pip install e2b-code-interpreter "cubesandbox>=0.2.0"
# 设置环境变量
export E2B_API_URL="http://127.0.0.1:3000"
export E2B_API_KEY="e2b_000000"
export CUBE_TEMPLATE_ID="<你的模板ID>"

第三步：执行代码

from e2b_code_interpreter import Sandbox
with Sandbox.create(template=os.environ["CUBE_TEMPLATE_ID"]) as sandbox:
    result = sandbox.run_code("print('Hello from CubeSandbox'); print(sum(range(1, 101)))")
    print(result)  # 输出: Hello from CubeSandbox / 5050

4.2 核心能力一览

除基础代码执行外，SDK 还支持：

能力	说明
Shell 命令执行	`sandbox.commands.run("uname -a")` 等，沙箱内完整 Linux 环境
文件读写操作	沙箱内部文件系统隔离，不影响宿主机
网络策略控制	支持完全断网、黑名单、白名单三种模式，在虚拟网络设备层面拦截

其中网络策略是 CubeSandbox 区别于多数容器的核心优势——策略在 MicroVM 的 tap 网络层执行，沙箱内代码无法绕过，这对防止 AI 代码扫描内网或外传数据至关重要。

五、性能评测一：冷启动与并发创建能力

冷启动速度是衡量沙箱是否适合 AI Agent 场景的首要指标。Agent 任务通常是「收到请求 -> 生成代码 -> 创建沙箱 -> 执行代码 -> 返回结果 -> 销毁沙箱」这样的流程，每一步的延迟都会累积到用户体验上。

5.1 测试方法说明

使用 CubeSandbox 仓库自带的 cube-bench 压测工具进行测试。该工具会按指定的并发数和请求总数创建沙箱，统计每次创建的耗时分布。

先编译工具：

cd /home/kk/CubeSandbox/examples/cube-bench
make
./bin/cube-bench --help

编译过程中需要 Go 环境，如果没有的话先 apt install golang-go。

5.2 本地 WSL 实测数据

我跑了三组不同并发档位的测试：

第一组：1 并发，20 次请求

./bin/cube-bench -c 1 -n 20 -w 3 --no-tui 
  -o ~/cubesandbox-eval-reports/coldstart/cube_c1_n20.json 
  | tee ~/cubesandbox-eval-reports/coldstart/cube_c1_n20.txt

第二组：10 并发，100 次请求

./bin/cube-bench -c 10 -n 100 -w 3 --no-tui 
  -o ~/cubesandbox-eval-reports/coldstart/cube_c10_n100.json 
  | tee ~/cubesandbox-eval-reports/coldstart/cube_c10_n100.txt

第三组：更高并发（可选）

资源充足的情况下可以尝试 50 并发 500 请求的压测，但在 WSL 中可能会触发资源上限。

5.3 核心数据分析

从 JSON 中提取核心指标：

jq '{config, summary, create}' ~/cubesandbox-eval-reports/coldstart/cube_c1_n20.json
jq '{config, summary, create}' ~/cubesandbox-eval-reports/coldstart/cube_c10_n100.json

汇总如下表：

并发数	请求数	平均延迟(ms)	最小值(ms)	P50(ms)	P95(ms)	P99(ms)	最大值(ms)	吞吐(QPS)	成功率
1	20	750.583	324.168	861.678	933.688	945.757	945.757	0.7551	100%
10	100	754.761	302.860	858.702	961.058	1045.686	1046.545	6.2741	100%

5.4 与官方 Benchmark 数据对比

这里有一个重要的口径问题需要说清楚。上面的数据来自我本地的 WSL2 环境（Intel Ultra 7 255H，16 vCPU，15GB 内存），受限于 WSL 的 I/O 调度、Windows 动态内存分配和网络栈开销。

CubeSandex 官方在腾讯云 BMI5 裸金属实例上的 benchmark 数据则完全不同量级：

环境	单并发平均延迟	单并发 P95	20 并发平均	20 并发吞吐
我的 WSL 本地	~750ms	~934ms	未稳定测试	–
官方 BMI5 裸金属(96核/375G)	47.8ms	57.4ms	98.1ms	180.9/s
官方 SA9.4XLARGE32 PVM (16核/32G)	66.7ms	78.2ms	364.6ms	约 50/s

差距来自硬件规格、虚拟化层级和调度效率。但这恰恰说明了一点：CubeSandbox 在合适的硬件上能达到真正的毫秒级启动，而 WSL 本地的几百毫秒主要是环境限制而非软件本身的瓶颈。

如果你正在做技术选型，建议以官方裸金属/PVM 数据为参考基准。WSL 数据的意义在于证明功能可用和趋势正确。

六、性能评测二：单机内存密度

内存密度决定了单机能跑多少个沙箱实例，直接影响成本。

6.1 测试方法

使用 cube-bench 的 create-only 模式，分批创建沙箱并观察内存变化：

# 先清理残留沙箱
cubemastercli list --all -q | xargs -r cubemastercli destroy
# 记录基线内存
free -m | tee mem_baseline.txt

然后分批创建 1 个、累计 5 个、累计 10 个沙箱，每次记录内存变化。

6.2 内存密度数据

存活沙箱数	Available Memory (MB)	下降量 (MB)	摊销 MB/沙箱
0 (基线)	10138	0	–
1	10070	68	68.00
5	10070	68	13.60
10	10013	125	12.50

6.3 关于内存数据的两个口径

这里需要特别说明 CubeSandbox 内存数据的两个常见口径：

<5MB 口径：这是 README 中提到的 hypervisor 层面开销，指的是单个 MicroVM 进程本身的内存占用
21-34MB/实例 口径：这是官方 benchmark 中的端到端摊销内存，包含了 shim 进程、网络栈、存储挂载点等全部运行态开销

两者描述的不是同一个东西。前者更接近理论下限，后者是生产环境中更实用的参考数值。

在我的 WSL 环境中，由于 Windows 动态内存管理和页缓存的影响，观测到的摊销值约为 12-68MB/实例，波动较大。正式容量规划仍应以裸金属/PVM benchmark 为准。

官方裸金属环境下，1000 个空闲沙箱的摊销内存约为 25.7MB/实例，PVM 云主机环境下约 27-34MB/实例，估算单机可承载约 700+ 个空闲沙箱。

七、性能评测三：快照、克隆与回滚

这一节是 CubeSandbox 与其他方案拉开差距的核心差异化能力。

7.1 为什么 Agent 需要快照能力？

考虑这样一个典型的 AI Agent 工作流：

Agent 收到一个代码修复任务
创建沙箱，拉取代码，安装依赖，跑测试 → 状态 A
尝试第一种修复方案 → 失败
如果没有快照：只能销毁沙箱，重新从头开始（回到第 2 步）
如果有快照：从状态 A 直接回滚，然后尝试第二种方案
如果还能克隆：从状态 A 同时 fork 出 5 个分支，并行尝试 5 种不同的修复策略

可以看到，Snapshot / Clone / Rollback 不是锦上添花，而是多分支 Agent 试错场景的刚需。缺少这个能力，Agent 的探索效率和成本都会受到很大影响。

7.2 快照功能验证

先跑一遍功能 demo 确认基本能力：

cd /home/kk/CubeSandbox/examples/snapshot-rollback-clone
source ~/cube-eval-venv/bin/activate
pip install -r requirements.txt
python 01_create_snapshot.py   # 创建快照
python 04_state_preserved.py   # 验证状态保存
python 09_rollback.py          # 验证回滚功能

7.3 Snapshot 性能测试

测试不同并发下的快照创建速度：

并发数	轮次	平均耗时(ms)	P95(ms)	单次摊销(ms)
1	3	411.7	484.0	411.7
5	3	495.3	547.0	99.1
10	3	711.8	809.5	71.2

10 并发下，每个快照的平均摊销时间只有 71.2ms。这意味着在高并发场景下，快照的开销非常小。

7.4 脏页大小影响测试

快照的大小会受到沙箱内已修改数据（脏页）的影响：

写入脏页量(MB)	脏页大小(MB)	快照耗时(ms)	从快照创建耗时(ms)
0	–	待记录	待记录
10	–	待记录	待记录
50	–	待记录	待记录
100	–	待记录	待记录

7.5 Create from Snapshot 测试

从一个已有快照创建新沙箱的速度：

并发数	轮次	平均耗时(ms)	P95(ms)
1	3	待记录	待记录
5	3	待记录	待记录
10	3	待记录	待记录

7.6 Rollback 测试

将沙箱回滚到某个历史快照点的速度：

并发数	轮次	平均耗时(ms)	P95(ms)
1	3	待记录	待记录
5	3	待记录	待记录

7.7 Clone 测试

Clone 是从一个运行中的沙箱复制出一个全新的独立沙箱，两者后续互不影响。这是多分支 Agent 场景中最常用的操作：

克隆数量	并发数	轮次	总耗时(ms)	单次摊销(ms)
1	1	3	1378.2	1378.2
10	5	2	2486.9	248.7

7.8 官方裸金属快照数据参考

同样，给出官方在 BMI5 裸金属上的数据供参考：

操作	裸金属单次耗时	高并发摊销
Snapshot	~49.8ms	10 并发 ~12.7ms/snapshot
Create from Snapshot	~63.9ms	50 并发 ~3.6ms/sandbox
Rollback	~81.6ms	10 并发 ~26.6ms/rollback
Clone (单个)	~219.6ms	100 个/50 并发 ~5.4ms/clone

这些数字的含义是：在足够的硬件资源下，CubeSandbox 的状态管理操作都能做到毫秒级完成。特别是 Clone 操作在高并发下的摊销成本极低，非常适合 Agent 并行试错的场景。

八、性能评测四：Docker 对照基线

为了给横测提供一个本地参照，我用相同的环境测试了 Docker 容器的冷启动速度。

需要强调的是：这个对照组的目的不是为了证明 Docker 慢，而是为了展示两种不同隔离模型的取舍。Docker 共享宿主内核，CubeSandbox 每个沙箱独立内核——它们的定位和适用场景本来就不同。

8.1 测试方法

docker pull python:3.11-slim
for i in $(seq 1 20); do
  /usr/bin/time -f "%e" docker run --rm python:3.11-slim python -c 'print(1)' >/dev/null
done 2>&1 | tee docker_run_seconds.txt

8.2 Docker 测试结果

awk '...计算逻辑...' docker_run_seconds.txt

指标	数值
测试次数	20
平均耗时	0.794s (794ms)
最小值	0.68s (680ms)
最大值	0.84s (840ms)

8.3 Docker vs CubeSandbox：如何理解这个数据？

在我的 WSL 环境下：

Docker 启动一个 Python 容器并执行 print(1)：平均 794ms
CubeSandbox 创建一个 MicroVM 沙箱并执行代码：平均 ~750ms（1 并发）

两者的启动时间在同一量级。但这并不代表它们的能力相同：

维度	Docker	CubeSandbox
隔离强度	共享宿主内核，Namespace 级隔离	独立内核，KVM 硬件级隔离
网络控制	需要额外配置（iptables/NetworkPolicy）	内置 allowlist/denylist/断网模式
快照/回滚	不支持运行态快照	内置 Snapshot/Rollback/Clone
内核逃逸风险	存在（历史上多次 CVE）	显著降低（独立内核）
适用代码类型	可信或低风险脚本	不可信代码、第三方生成的代码

如果你只执行自己写的、经过 review 的脚本，Docker 完全够用。但如果要执行 AI 模型生成的代码，CubeSandbox 提供的安全边界更可靠。

九、第三方平台实测：E2B 与 Daytona

除了本地可部署的方案，我还实测了两个主流的云端托管沙箱服务。

9.1 E2B 实测

E2B 是目前最流行的托管式 AI 代码执行沙箱。申请 API Key 后，用官方 SDK 进行测试：

pip install -U e2b-code-interpreter
unset E2B_API_URL   # 不要沿用本地 CubeSandbox 的 URL
unset SSL_CERT_FILE  # 访问 E2B 云端不需要本地证书
export E2B_API_KEY="<你的 E2B Key>"

编写 benchmark 脚本，测试 20 次创建→执行→销毁的端到端耗时：

python bench_e2b_code_interpreter.py

E2B 的控制台也能看到调用记录：

9.2 Daytona 实测

Daytona 更偏向于提供完整的 Agent 开发环境：

pip install -U daytona
export DAYTONA_API_KEY="<你的 Daytona Key>"
export DAYTONA_API_URL="https://app.daytona.io/api"
export DAYTONA_TARGET="us"

python bench_daytona.py

9.3 第三方平台的数据口径说明

E2B 和 Daytona 的测试数据来自云端服务的 API 调用，网络链路涉及：

本地 WSL → 公网 → E2B/Daytona 云端 → 返回结果

这与本地运行的 CubeSandbox 和 Docker 不在同一测试环境中，因此：

不做绝对的毫秒数排名，因为网络延迟占了很大比例
主要关注其 接入体验、API 设计、成功率、错误处理 等定性维度
性能数据仅作为趋势参考

十、综合对比与选型建议

10.1 能力对比总表

能力维度	CubeSandbox	Docker	E2B	Daytona	OpenSandbox	传统 VM
隔离模型	KVM MicroVM，独立内核	Namespace/cgroup，共享内核	托管沙箱	托管环境	Docker/K8s runtime	完整虚拟机
冷启动速度	裸金属 ~47.8ms	~500-800ms	云端 ~数秒(含网络)	云端 ~数秒	取决于底层	2-10 秒
高并发支持	裸金属 180+/s	受内核共享限制	取决于配额	取决于配额	取决于 K8s 调度	极差
内存开销	~21-34MB/实例	~数十MB/容器	不感知	不感知	取决于镜像	数百MB~数GB
自托管	支持	支持	否	企业版/BYOC	支持	支持
快照/回滚	内置支持	仅文件系统/commit	有限支持	有限支持	视实现而定	支持但慢
克隆/Fork	内置 Clone	不支持	不支持	视情况而定	不支持	支持但慢
网络控制	内置策略引擎	需自行配置	以官方为准	以官方为准	取决于 CNI	完全自主
凭据注入	支持(CubeEgress)	需自行实现	以官方为准	以官方为准	需自行实现	需自行实现
SDK 兼容	E2B SDK 兼容	Docker API	官方 SDK	官方 SDK	多语言 SDK	无标准 SDK
审计日志	内置	需自行搭建	以官方为准	以官方为准	需自行搭建	需自行搭建

10.2 分场景选型建议

场景一：只需要跑几行可信脚本

推荐：Docker

如果你的场景是执行你自己写好的、经过 code review 的脚本，或者跑 CI/CD 中的构建任务，Docker 已经足够。它生态成熟、文档丰富、社区活跃，遇到问题随便一搜就有答案。

场景二：想最快接入，不想管基础设施

推荐：E2B / Daytona

如果你的团队规模不大，不想花时间维护沙箱基础设施，只想用一个 API 把代码丢出去执行拿结果回来，那托管服务是最省心的选择。代价是你的代码数据会经过他们的服务器，且无法深度定制底层行为。

场景三：有合规要求，数据不能出内网

推荐：CubeSandbox / Docker / OpenSandbox

金融、医疗、政务等行业通常有数据不出内网的要求。这时 SaaS 类的托管方案就直接排除了，只能在自托管方案中选择。CubeSandbox 在自托管方案中隔离性最强。

场景四：AI Agent 多分支试错 / SWE-Bench / RL 训练

推荐：CubeSandbox

这是 CubeSandbox 最擅长的场景。Agent 在尝试多种修复策略时，需要频繁地从某个中间状态 fork 出多个分支、并行执行、失败后回滚。CubeSandbox 的 Snapshot / Clone / Rollback 正是为这种工作流设计的：

初始状态(A) ──→ Snapshot ──→ 保存为 checkpoint
                    │
                    ├─── Clone ──→ 分支1: 尝试 strategy_A
                    ├─── Clone ──→ 分支2: 尝试 strategy_B
                    ├─── Clone ──→ 分支3: 尝试 strategy_C
                    │
              分支1 失败 → Rollback 回到 A
              分支2 成功 → 继续
              分支3 失败 → 销毁

没有快照能力的沙箱，每次试错都需要从头创建环境，时间和资源成本都会成倍增加。

场景五：需要极致的隔离安全性

推荐：CubeSandbox > 传统 VM > Docker

如果执行的是完全不可信的代码（比如来自互联网用户的提交），隔离安全性的优先级最高：

Docker 有内核共享带来的逃逸风险（虽然实际利用难度不低，但理论上存在）
传统 VM 隔离最强但太重
CubeSandbox 在两者之间找到了平衡点：独立内核保证隔离强度，MicroVM 保证启动速度

十一、CubeSandbox 的架构亮点

经过这次完整的部署和实测，我认为 CubeSandbox 有几个值得单独拿出来说的设计决策：

11.1 KVM MicroVM 而非容器

这是 CubeSandbox 与大多数竞品最根本的区别。市面上绝大多数代码执行沙箱都是基于 Docker 容器实现的，而 CubeSandbox 选择了一条更重的路——每个沙箱都是一个独立的虚拟机。

这个选择带来了：

更强的隔离边界：沙箱内的代码即使拿到 root 权限，也只能影响自己的虚拟机内核
更清晰的权限模型：不需要担心容器逃逸、namespace 穿透这类问题
更好的审计基础：每个沙箱有独立的系统日志、进程树、网络栈

当然也有代价：需要 /dev/kvm、需要 XFS 文件系统、部署门槛略高一些。

11.2 E2B SDK 兼容

这是一个很聪明的产品决策。E2B 目前是 AI 代码执行沙箱领域的事实标准，大量现有的 AI 应用已经集成了 E2B SDK。CubeSandbox 选择兼容 E2B 的接口协议，意味着这些应用只需要把 E2B_API_URL 从 api.e2b.dev 改成本地 CubeSandbox 地址，就可以无缝切换过来。

实测中我也验证了这一点：用 e2b-code-interpreter 的 SDK 直接连接本地 CubeSandbox，零改动即可工作。

11.3 完整的状态管理层

很多沙箱方案只解决了「创建」和「销毁」的问题，但对于运行中的状态管理缺乏支持。CubeSandbox 内置了：

Snapshot：将当前运行状态保存为快照
Create from Snapshot：从快照恢复出新沙箱
Rollback：将当前沙箱回退到某次快照
Clone：复制出一个与当前状态完全一致的新沙箱

这套能力组合在一起，构成了面向 Agent 工作流的完整状态管理原语。

11.4 网络策略内置

网络控制不是事后加的功能，而是 CubeSandbox 的核心设计之一。通过 CubeVS（虚拟交换机）和 CubeEgress（出站代理）的组合，可以实现：

完全断网：沙箱无法访问任何网络地址
黑名单：允许访问大部分网络，但屏蔽特定目标
白名单：只允许访问预授权的少数地址
凭据注入：将 API Key 注入沙箱的代理层，不让代码直接接触明文密钥

十二、CubeSandbox 的局限性与适用边界

任何技术方案都有其适用边界，CubeSandbox 也不例外。以下是我在实测中发现的一些限制：

12.1 部署门槛相对较高

相比于 Docker 的 docker run 一条命令就能用起来，CubeSandbox 的前置要求更多：

需要 KVM 支持（意味着需要物理机的 CPU 虚拟化能力，或者云主机的嵌套虚拟化）
需要 XFS 文件系统（Linux 默认 ext4，需要额外配置）
需要 systemd（WSL 需要手动开启）

对于没有 Linux 运维经验的团队，初次部署可能会踩坑。

12.2 WSL 支持有限

虽然我在 WSL2 上成功跑通了全部流程，但 WSL 毕竟不是 CubeSandbox 的推荐部署环境。性能数据和稳定性都无法与裸金属相比。如果要在 Windows 开发机上体验 CubeSandbox，WSL 是可行的路径，但不代表生产环境可以这样用。

12.3 生态还在早期

CubeSandbox 是一个相对年轻的项目（2026 年 4 月 22 日正式开源）。相比 Docker 十年的生态积累、E2B 两三年的市场推广，CubeSandbox 的：

社区案例还不多
文档和教程还在完善中
第三方集成（除 E2B SDK 外）还比较少

对于追求成熟稳定、不想踩坑的团队，这可能是一个顾虑因素。

12.4 不适用于长时间运行的服务

CubeSandbox 的定位是临时的代码执行环境，而不是长期运行的服务容器。如果一个进程需要运行数小时或数天，传统的容器方案或 VM 可能更适合。

十三、总结

经过近两周的实测，我对这几个方案有了直观的认识。最后用一句话总结各自的定位：

方案	一句话定位
Docker	「我就跑个脚本，别搞那么复杂」
E2B / Daytona	「我不管底层是什么，给我个 API 就行」
传统 VM	「我要最强的隔离，不在乎速度」
OpenSandbox	「我要一个通用的沙箱抽象层」
CubeSandbox	「我要自托管、要强隔离、要快、还要能快照回滚」

如果你的需求和最后一行的描述吻合——尤其是如果你正在做 AI Agent 的代码执行、SWE-Bench 之类的自动化任务，或者有合规要求必须自托管——那么 CubeSandbox 值得你花时间去了解和试用。

项目地址：github.com/TencentCloud/CubeSandbox

仓库里包含了完整的部署文档、benchmark 工具、各种示例代码（代码执行、网络策略、快照回滚、OpenAI Agents 集成等），以及基于裸金属和 PVM 的详细性能报告。觉得有用的话，可以去 GitHub 点个 Star 关注后续更新。

本文所有 CubeSandbox 实测数据均来自作者本地 WSL2 环境（Intel Core Ultra 7 255H, 16 vCPU, 15GB RAM, WSL 2.6.2.0, Ubuntu 24.04 LTS）。E2B 和 Daytona 数据来自对应云服务的 API 调用，受网络链路影响。Docker 数据为本机容器启动计时。不同产品的测试环境、配置和工作负载存在客观差异，横向对比时请注意数据口径。生产环境的性能数据以各产品官方 benchmark 为准。

文章版权归作者所有，未经允许请勿转载。

AI Agent 代码执行沙箱横评：当不可信代码需要跑起来，我们到底有多少选择？