AI 代码沙箱/微虚拟化 开源项目全景对比

调研时间：2026-06-22 目的：横向对比 CubeSandbox 与同赛道项目的隔离策略与性能取舍，为犀牛鸟参与做知识储备

6 个项目一览

设计思路对比

隔离方式（核心差异）

每个项目对”怎么把不可信代码关进笼子”这个问题给出了不同答案：

精简微虚拟化模式（Firecracker）：砍掉传统 VM 的 BIOS、USB、PCI 等设备模型，只保留网卡、磁盘、串口、定时器，用 KVM 做硬件隔离。类比：把一间五星级酒店房间（QEMU）精简成一间太空舱旅馆——只有床和灯，但门锁一样结实，入住速度快十倍。

Rust 原生 + E2B 兼容模式（CubeSandbox）：同样基于 RustVMM/KVM 硬件隔离，但专为 AI Agent 场景设计——60ms 冷启动、<5MB 单实例内存、兼容 E2B SDK 接口，且支持自托管。类比：Firecracker 是发动机，E2B 是租车平台，CubeSandbox 做了一台自己能开、也能上租车平台的车——引擎和 Firecracker 同源（RustVMM），但方向盘接口和 E2B 通用。

云端沙箱即服务模式（E2B）：在 Firecracker 之上封装云端 API，开发者用 SDK 创建沙箱 → 执行代码 → 拿结果 → 销毁，不用管底层 VM。类比：不自己开车也不买车，打开 App 叫一辆网约车，用完即走。

AI 沙箱基础设施模式（Daytona）：内核、文件系统、网络三层都做隔离，90ms 创建实例，面向 AI 代码执行场景。类比：给每个住客分配独立的房间（内核）、独立的储物柜（文件系统）、独立的 WiFi 网络（网络隔离），三把锁一起上。

用户态内核模式（gVisor）：不用硬件虚拟化，而是在用户态实现一个”假内核”（Sentry），拦截应用的所有系统调用。类比：不是给你一间真的隔间，而是给你一个”模拟器”——你以为你在操作真系统，其实每个操作都经过一层翻译和过滤。

轻量 VM 容器模式（Kata Containers）：每个容器跑在独立的轻量 VM 里，外部仍然通过 OCI/CRI 标准接口管理。类比：看起来和普通集装箱（容器）一模一样的接口，但每个集装箱里面其实是一个密封的独立房间（VM），隔离级别从”隔板”升级到”墙壁”。

隔离技术对比

CubeSandbox 的 60ms 冷启动是所有基于硬件虚拟化方案中最快的，同时保持了与 Firecracker 同级别的内存占用。

语言生态对比

CubeSandbox 和 Firecracker 是仅有的两个纯 Rust 项目，在性能和内存安全方面有语言级优势。

AI Agent 专用能力对比

Firecracker、gVisor、Kata Containers 是通用隔离引擎，不提供面向 AI Agent 的上层 SDK。CubeSandbox 的差异化在于：既有 Firecracker 级别的硬件隔离，又有 E2B 级别的 Agent SDK 兼容，同时支持自托管。

代码量级对比

Daytona:          ~大型项目（TypeScript，功能覆盖广）
Firecracker:      ~数百文件（Rust，精简但底层复杂）
gVisor:           ~数千文件（Go，完整用户态内核实现）
Kata Containers:  ~大型项目（Rust/Go，多组件架构）
E2B:              ~中型项目（TypeScript/Go，云服务 + SDK）
CubeSandbox:      ~精简（Rust，聚焦 AI 沙箱核心路径）

CubeSandbox 代码量在同类硬件隔离方案中最精简，通读成本最低。gVisor 代码量最大，因为要在用户态重新实现大量系统调用。

学习价值排序

从”理解 AI 代码沙箱设计”的角度：

1. CubeSandbox — Rust 代码精简，RustVMM 架构清晰，E2B SDK 兼容设计值得研究，最适合通读理解”AI 沙箱怎么做”
2. Firecracker — 赛道基石（34.7K star），理解微虚拟化的基准实现，CubeSandbox 的底层同源技术
3. E2B — 理解”沙箱即服务”的产品形态，Agent SDK 设计参考，是 CubeSandbox 兼容的目标接口
4. gVisor — 理解”不用硬件虚拟化也能隔离”的另一条路，用户态内核设计有学术价值
5. Daytona — Star 数最高（57.6K），AI 沙箱产品设计参考，TypeScript 生态
6. Kata Containers — 理解”VM + 容器”融合思路，OCI/CRI 标准接入参考

推荐阅读路线

1. 先通读 CubeSandbox 的核心路径（Rust，精简，2-3 天）
2. 对比 Firecracker 的 microVM 实现（理解”CubeSandbox 的底层同源技术做了什么”）
3. 对比 E2B 的 SDK 设计（理解”CubeSandbox 兼容的是什么接口”）
4. 如果时间允许，读 gVisor 的 Sentry 实现（理解”不用 KVM 的隔离方案怎么做”）

这个阅读顺序会让你从”理解一种 AI 沙箱实现” → “理解底层隔离引擎” → “理解上层 SDK 设计” → “理解替代隔离方案”递进。

Coding Agent 内建沙箱 vs microVM 平台

上面的 6 个项目是独立的沙箱/虚拟化项目。生产 Coding Agent（Codex、Claude Code、Cursor）则在 Agent 内部内建了不同层级的隔离机制：

核心洞察：OS sandbox（Codex 路线）和 microVM（CubeSandbox/E2B 路线）解决的是同一问题的不同侧面。单用户自用场景下 OS sandbox 在延迟和复杂度上有优势；多租户代码执行服务需要 microVM 的硬件级隔离。详见 Coding Agent 沙箱对照。