前言

最近在做 AI Agent 相关的项目，遇到一个绕不开的问题：模型生成的代码，怎么安全地执行？

直接跑在宿主机上？不敢。Docker 容器？隔离不够。传统虚拟机？太重了。

于是开始系统性地调研沙箱技术，从原理到主流方案，再到腾讯云最近开源的 Cube Sandbox。这篇文章是我的整理，分享给有同样困惑的同学。

---

一、什么是沙箱（Sandbox）

沙箱，英文 Sandbox，字面意思是"沙坑"。

通俗来讲，就是在电脑里围出一块独立的区域，像一个带围栏的盒子。代码在这个盒子里随便跑，跑崩了、跑歪了，也不会影响到外面的电脑。 盒子和外界之间有一道看不见的墙，里面的出不去，外面的进不来。

在计算机领域，沙箱是一种安全隔离机制，核心思想就一句话：让不可信的代码在一个受控的环境里运行，跑完即销毁，不影响宿主机和外部系统。

技术层面，沙箱通过以下手段实现隔离：

• 文件系统隔离——沙箱内只能访问自己的文件系统，看不到宿主机的目录
• 网络隔离——通过网络策略控制出入站流量，内网访问受限
• 进程隔离——沙箱内的进程与宿主机进程互不可见
• 资源限制——CPU、内存、磁盘 I/O 有上限，防止资源耗尽攻击

沙箱不是防火墙，不是杀毒软件，不是 WAF。它是一个运行时容器，专门用来装你不信任的代码。用完就销毁，不留痕迹。

---

二、沙箱有什么用

我把沙箱的核心价值总结为三个词：防破坏、防泄漏、防残留。

2.1 防破坏

沙箱内的代码删不了宿主机的文件，改不了系统配置，装不了恶意软件。即使代码执行了 rm -rf /，影响范围也仅限沙箱内部。

2.2 防泄漏

通过网络策略，沙箱内的代码访问不了内网服务、数据库、其他微服务。数据传不出去，敏感信息不会通过代码执行泄漏。

2.3 防残留

沙箱用完即销毁。不留进程、不留文件、不留后门、不留临时数据。每次使用都是全新的环境。

---

三、哪些场景需要沙箱

3.1 AI Agent 代码执行（当前最火的场景）

Cursor、Windsurf、Devin、OpenAI 的 Code Interpreter——这些产品背后都有沙箱。模型生成代码，沙箱执行，结果返回给用户。用户看不到沙箱，但沙箱是整个链路的安全底线。

这个场景对沙箱的要求特别高：启动要快（用户体验）、隔离要强（安全底线）、密度要高（成本控制）。传统的 Docker 或虚拟机很难同时满足。

3.2 在线编程教育和在线评测（OJ）

LeetCode、牛客网、各大高校的 OJ 系统。学生提交的代码五花八门，你不可能让每段代码都在服务器上裸跑。沙箱保证每次评测都是隔离的、公平的、安全的。

3.3 安全研究和恶意软件分析

拿到一个可疑样本，想知道它干了什么。直接在自己机器上运行？不可能。放进沙箱里跑，观察行为（文件操作、网络请求、注册表修改），然后销毁。

3.4 浏览器和插件隔离

Chrome 的 Site Isolation、Windows 的 Windows Defender Application Guard（WDAG）——本质上都是沙箱的变体。网页代码在隔离环境里执行，即使有漏洞也不容易影响系统。

3.5 CI/CD 和自动化测试

每次代码提交自动跑测试，测试环境必须是干净的。沙箱保证每次测试都是从零开始，不受上一次的污染。

3.6 多租户 SaaS 平台

多个租户共享一套基础设施，租户之间的代码和数据必须严格隔离。沙箱是实现租户隔离的核心手段之一。

---

四、世界主流的沙箱方案对比

我整理了目前市面上比较有代表性的沙箱方案，做了一个横向对比：

4.1 Docker 容器

• 原理：Linux Namespaces + cgroups，共享宿主机内核
• 优点：生态成熟、启动快（200ms 级）、部署密度高
• 缺点：共享内核，隔离级别不够高。内核漏洞可导致容器逃逸
• 适用场景：信任代码的隔离部署，不适合执行不可信代码

4.2 传统虚拟机（KVM / VMware / VirtualBox）

• 原理：硬件虚拟化，每个 VM 运行独立的操作系统内核
• 优点：隔离最彻底，独立内核
• 缺点：启动慢（秒级）、内存开销大（几百 MB）、部署密度低
• 适用场景：强隔离需求，但对启动速度和密度要求不高的场景

4.3 gVisor（Google）

• 原理：Go 编写的应用层内核，在用户态拦截系统调用
• 优点：比 Docker 安全，比虚拟机轻
• 缺点：兼容性有坑，不是所有系统调用都支持，部分应用跑不起来
• 适用场景：GCP 用户，对兼容性要求不高的场景

4.4 Firecracker（AWS）

• 原理：Rust 编写的 MicroVM，基于 KVM，极致裁剪
• 优点：125ms 启动，5MB 内存开销，AWS Lambda/Fargate 的底层
• 缺点：功能相对精简，热迁移等高级特性有限
• 适用场景：AWS 生态，Serverless 底层

4.5 E2B

• 原理：基于 Firecracker 的商业化 AI Agent 沙箱服务
• 优点：SDK 友好，开箱即用，AI Agent 赛道的事实标准
• 缺点：商业服务，按量付费，成本不低；不开源
• 适用场景：快速接入 AI Agent 代码执行能力

4.6 WASM 运行时（Wasmtime / WasmEdge）

• 原理：WebAssembly 沙箱，从浏览器安全模型衍生
• 优点：启动极快（微秒级），跨平台
• 缺点：生态还在早期，系统调用支持有限，不适合通用代码执行
• 适用场景：边缘计算、插件系统

4.7 横向对比总结

维度	Docker	传统 VM	gVisor	Firecracker	E2B	Cube Sandbox
隔离级别	低	极高	中高	高	高	极高
启动速度	~200ms	秒级	~200ms	~125ms	~200ms	<60ms
内存开销	低	高	中	5MB	-	<5MB
部署密度	高	低	高	高	-	极高
开源	是	是	是	是	否	是
E2B 兼容	否	否	否	否	原生	兼容

---

五、腾讯云 Cube Sandbox 是什么

5.1 基本信息

Cube Sandbox 是腾讯云 2026 年 4 月开源的 AI Agent 安全沙箱服务。

• GitHub：https://github.com/TencentCloud/CubeSandbox
• 官网：https://cubesandbox.com
• 协议：Apache License 2.0
• 技术栈：Rust + KVM + eBPF
• CNCF：已收录至 CNCF Landscape

5.2 技术架构

Cube Sandbox 基于 RustVMM + KVM 构建，底层使用 Cloud Hypervisor 作为 MicroVM 引擎。整体架构包含以下核心组件：

组件	职责
CubeAPI	REST API 网关（Rust），兼容 E2B 协议
CubeMaster	编排调度器，资源调度与集群状态维护
CubeProxy	反向代理，E2B 协议兼容，请求路由
Cubelet	计算节点本地调度，管理单节点所有沙箱生命周期
CubeVS	eBPF 内核态虚拟交换机，网络隔离与安全策略
CubeEgress	出站安全网关（OpenResty），域名过滤、凭证注入、审计
CubeHypervisor + CubeShim	虚拟化层，KVM MicroVM 管理 + containerd Shim v2 接口

5.3 核心能力

极速启动

单并发冷启动 < 60ms，50 并发平均 67ms（P95: 90ms，P99: 137ms）。对比 Firecracker 的 125ms，快了一倍。

硬件级隔离

每个沙箱独立 Guest OS 内核，不是 Docker 的共享内核。配合 eBPF 网络隔离，安全级别接近传统虚拟机。

E2B SDK 兼容

原生兼容 E2B SDK，替换一个 URL 环境变量即可接入，零业务代码改动。已经在用 E2B 的项目可以无缝迁移。

凭证托管

Agent 调用外部 API 的密钥不进沙箱、不进模型上下文、不落日志。在 CubeEgress 网关层注入，沙箱里看不到。

出站管控

域名白名单放行，越权出站当场拦截，全量审计日志。

快照 · 克隆 · 回档

CubeCoW 引擎，百毫秒级检查点，运行中随时快照，回滚到任意状态。RL 训练场景特别适合。

Web 控制台

浏览器打开 :12088，沙箱、模板、节点、版本矩阵一目了然。

模板体系

OCI 镜像一键转模板，模板商店安装官方预置环境，跨节点自动分发。

---

六、v0.5.0 七月更新详解

v0.5.0 于 2026 年 7 月 3 日发布，116 个提交，26 位贡献者。这是 Cube Sandbox 开源以来变更规模最大的版本之一。

6.1 AutoPause / AutoResume：沙箱生命周期自动化

这是我认为 v0.5.0 最重要的特性。

Agent 工作流中的沙箱大部分时间是闲置的——等用户输入、等回调、等 RL 下一轮 rollout。以前这些闲置沙箱占着资源不动，现在平台自动暂停它们，新请求到达时毫秒级唤醒。

技术实现细节：

• 新增 cube-proxy-sidecar 组件，内建 sweeper，通过 last_active 时间戳跟踪沙箱活跃状态
• 闲置超过 timeout_seconds 时，sweeper 通过 CubeMaster → Cubelet 触发暂停
• 暂停时将 MicroVM 完整状态（内存 + 文件系统）快照到磁盘
• 数据面请求到达已暂停沙箱时，CubeProxy 门控拦截，向 sidecar 发起恢复请求
• 并发恢复请求用 singleflight 模式合并，跨副本通过 Redis SETNX 分布式锁协调
• 支持配置资源释放比例 host.quota.paused_resource_release_ratio（0~1），可调最大调度密度或最稳恢复链路

6.2 ARM64 (aarch64) 全栈原生支持

这是腾讯云与 Arm 工程团队数月深度联合研发的成果。不是"能跑就行"，是原生级别适配：

Hypervisor 适配

x86 的 PIO 端口 I/O 重写为 MMIO 内存映射 I/O。KVM 寄存器访问适配上游 API 变更。seccomp 过滤规则按 ARM64 系统调用号差异对齐。

Guest Agent

RPC 就绪信号从 x86 的 ioperm() + PIO 端口写入改为 ARM64 的 /dev/mem 在物理地址处 mmap + ptr::write_volatile。

构建系统

清理所有 x86/amd64 默认假设，支持在 x86 机器上交叉编译 ARM 内核镜像。

CI/CD

一条 docker buildx 命令同时产出 x86 和 ARM 多架构镜像。

部署工具

Terraform 方案同步支持 ARM64 节点。

6.3 Terraform 一键集群部署

生产级 IaC 部署方案。一条命令拉起多节点集群，支持腾讯云 PVM 云服务器。

6.4 网络安全增强

• 入向流量令牌鉴权：每个沙箱分配 traffic_access_token（UUID v4），缺失或错误返回 HTTP 403，令牌值在日志中脱敏
• CubeEgress 启动期 Fail-Closed：安全网关未就绪时默认拒绝所有出站，避免窗口期泄漏
• 出向策略路由：沙箱流量不可绕过安全网关

6.5 其他重要更新

更新项	说明
纯 Go 原生 rootfs 导出管线	绕过 Docker/skopeo/umoci，显著降低内存与构建时间开销
快照运行时锁重构	消除高并发回滚场景的死锁问题
镜像 uid/gid 保留修复	修复非 root 镜像的权限问题
E2B SDK 对齐	补齐完整文件系统与 PTY API
一键升级模式	三路配置合并，升级后自动保留本地配置
CubeEgress 凭证明文注入	支持对纯 HTTP 上游的凭证注入
Kill 路径与生命周期 API	新增 POST /cube/sandbox/timeout 和 POST /cube/sandbox/refresh

---

七、总结

维度	评价
隔离级别	硬件级，独立内核 + eBPF 网络隔离，比 Docker 强一个量级
启动速度	<60ms，目前开源方案中最快
生态兼容	E2B SDK drop-in 迁移，零改动
安全设计	凭证托管 + 出站管控 + 流量令牌，安全链路完整
社区活跃度	3 个月 10 个版本，26+ 贡献者，节奏很快
待完善	K8s 原生部署、Volume、跨机暂停恢复还在路线图中

对于做 AI Agent 的同学来说，Cube Sandbox 是目前开源方案中值得关注的选择。硬件级隔离 + 亚百毫秒启动 + E2B 兼容，这个组合在开源领域是稀缺的。

---

标签：AI Agent、沙箱、Sandbox、Cube Sandbox、腾讯云、安全隔离、MicroVM、KVM、E2B
:::