第二章 · 六个项目一览：从发动机到整车

对应原始文档：sandbox-landscape.md

2.1 开始之前：几个会反复出现的词

在讨论这 6 个项目之前，先把几个核心术语讲清楚。后面不再重复解释。

KVM（Kernel-based Virtual Machine）：Linux 内核自带的虚拟化功能。它允许你在一台物理机上创建多个相互隔离的”虚拟机器”，每个虚拟机器以为自己是一台独立的电脑。类比：一栋公寓楼里的每个房间——每间房有独立的门锁、电表、水表，住户之间互不影响。KVM 是这栋楼的”隔断系统”。

microVM（微虚拟机）：一种极度精简的虚拟机。传统虚拟机（像 VirtualBox）会模拟一整台电脑——BIOS、USB、声卡、显卡全都有。microVM 只保留最少的必需品（网卡、硬盘、串口），所以启动快、内存小。类比：传统 VM 是五星级酒店房间（电视、浴缸、迷你吧一应俱全），microVM 是胶囊旅馆（只有床和灯，但门锁一样结实）。

宿主机（host）：运行虚拟机的那台真实物理机器。类比：公寓楼的楼体本身。

客户机（guest）：虚拟机内部的操作系统和程序。类比：公寓楼里的住户。

隔离（isolation）：确保一个执行环境里的操作不会影响到另一个环境。隔离强度从低到高：共享内核（容器）→ 软件拦截（gVisor）→ 硬件虚拟化（microVM）。

系统调用（syscall）：应用程序请求操作系统做事的方式。比如”打开文件”、”发送网络包”、”创建进程”——这些操作应用不能自己做，必须请求操作系统（内核）帮忙。类比：你在餐厅里不能自己去厨房拿食材，必须跟服务员点菜——点菜就是 syscall。

容器（container）：一种轻量级的隔离技术（Docker 就是最知名的容器技术）。容器通过 Linux 的 namespace 和 cgroup 机制让应用”以为”自己在独立的系统里，但实际上和宿主机共享同一个内核。类比：办公室里的隔间——看起来是独立空间，但大家共享同一个空调系统（内核）。如果空调出了问题（内核漏洞），所有隔间都受影响。

OCI（Open Container Initiative）：容器的行业标准。定义了”一个容器应该长什么样、怎么启动、怎么管理”。类比：USB 接口标准——只要你的设备符合 USB 规范，就能插到任何 USB 口上用。

2.2 全景对比：数字说话

几个直觉性的观察：

Daytona 星数最高——但这不代表技术最强。它是产品最完整（Dashboard、VNC、MCP Server 全有）、发布最早的项目，星数反映的是市场需求和产品力。

CubeSandbox 启动最快——60ms 比 Firecracker 的 125ms 还快一倍。这不是因为它用了更快的硬件，而是因为它预先创建好了 VM 模板，用 Copy-on-Write 快照”瞬间交付”。后面第四章会详细讲这个技巧。

gVisor 不需要 KVM——这是唯一一个可以在没有硬件虚拟化支持的环境下工作的强隔离方案。Mac 上没有 KVM，但可以跑 gVisor。

2.3 隔离方式：核心分歧点

6 个项目最根本的差异在于「怎么把不可信代码关进笼子」。可以归纳为三条路线：

路线 A：硬件虚拟化（KVM microVM）

代表：Firecracker、CubeSandbox、Kata Containers

原理：用 CPU 的硬件特性（VT-x / AMD-V）在硬件层面隔离。每个沙箱是一个独立的虚拟机，有自己的”假 CPU”、”假内存”、”假硬盘”。即使沙箱里的代码攻破了内核，也出不来——因为它的”内核”只是虚拟机里的内核，不是宿主机的真实内核。

类比：在楼里建了实体墙壁和防火门的独立房间。住户之间有物理隔断——要闯入邻居的房间，必须先砸穿墙壁（KVM 漏洞），再破掉防火门（hypervisor 漏洞），难度极高。

优点：隔离最强。攻击者需要同时找到两个独立漏洞（guest 内核漏洞 + KVM/hypervisor 漏洞）才能逃逸。

缺点：需要 KVM 支持（Mac 全系列没有）、启动比纯容器慢（60-200ms vs <1ms）、每个实例需要独立内存。

路线 B：用户态内核（软件拦截）

代表：gVisor

原理：不用硬件隔离，而是在用户空间实现一个”假内核”（叫 Sentry）。应用的每个系统调用都被 Sentry 拦截和处理——应用以为自己在和真内核对话，实际上在和一个 Go 程序对话。

类比：不是给你一间真的房间，而是给你一个 VR 头盔——你以为自己在一间真实的房间里，但其实所有的”墙壁”和”家具”都是模拟的。你触摸到的每一面”墙”都经过了 VR 系统的处理和过滤。

优点：不需要 KVM（Mac 也能跑）、启动是进程级的（毫秒级）、灵活。

缺点：Linux 有超过 400 个系统调用，Sentry 不可能完美实现每一个。有些程序（特别是用了高级内核特性的程序）可能跑不起来或行为不对。另外，模拟不是真隔离——如果 Sentry 代码本身有 bug，隔离就可能被绕过。

路线 C：容器级增强隔离

代表：Daytona

原理：在标准 Docker 容器的基础上，叠加内核、文件系统、网络三层隔离。不是 VM 级别的物理隔断，但比裸容器强得多。

类比：在隔间的基础上加了三把锁——门锁（内核隔离）、储物柜锁（文件系统隔离）、WiFi 密码（网络隔离）。不是墙壁，但比没有锁安全很多。

优点：启动快（90ms）、生态兼容好（Docker 镜像直接用）、产品功能丰富。

缺点：共享宿主机内核。Linux 内核每年有几十个安全漏洞（CVE），其中一些可以从容器内突破到宿主机。在多租户场景下，这是一个持续存在的风险。

三条路线的终极取舍

安全性 ↑ ───────────────────────────────────────→
       │
       │  Docker 容器    Daytona    gVisor    CubeSandbox/Firecracker/Kata
       │  （共享内核     （三层锁    （软件     （硬件隔离，
       │   无额外隔离）   容器级）   拦截）     VM 级别）
       │
灵活性 ↓ ───────────────────────────────────────→

没有一个方案能同时做到”最安全 + 最快 + 最灵活”。每个项目都在这三个维度上做了不同的取舍。理解这个取舍关系，是理解整个领域的钥匙。

2.4 谁在用这些项目？真实世界的例子

• AWS Lambda / Fargate：底层用 Firecracker。每次你调用一个 AWS Lambda 函数，背后就是一个 Firecracker microVM 在 <125ms 内启动、执行你的代码、然后销毁。
• Perplexity / Manus：用 E2B 执行 AI 生成的代码。你在 Perplexity 里让 AI 跑一段 Python 分析数据，代码跑在 E2B 的沙箱里。
• Google GKE：用 gVisor 的 runsc 运行时来隔离 Kubernetes Pod。
• OpenAI Codex：用 OS 级沙箱（bwrap + seccomp），不是 microVM，但思路类似——限制 Agent 代码的文件和网络访问。
• 各大银行的 K8s 集群：用 Kata Containers 满足合规要求（监管要求 VM 级隔离，容器隔离不够）。

2.5 语言生态对比

一个值得注意的趋势：做底层隔离的项目（Firecracker、CubeSandbox、Kata）都选了 Rust。这不是巧合——虚拟化层是整个安全链条的最后一道防线，一个内存漏洞就可能导致沙箱逃逸。Rust 的编译期内存安全检查在这个场景下是决定性优势。

2.6 代码量级对比：通读成本

CubeSandbox 在所有硬件隔离方案中代码量最小。这是它对犀牛鸟参赛者最友好的一个属性——你能在几天内通读核心路径，理解整个架构。

2.7 学习价值排序

如果你的目标是「理解 AI 代码沙箱设计」，推荐的学习顺序：

1. CubeSandbox — 代码精简 + 架构清晰 + E2B SDK 兼容设计值得研究 → 最适合作为第一个通读的项目
2. Firecracker — 赛道基石（34.7K star），理解微虚拟化的基准实现 → 理解”CubeSandbox 的底层同源技术做了什么”
3. E2B — 理解”沙箱即服务”的产品形态 + SDK 设计 → 理解”CubeSandbox 兼容的是什么接口”
4. gVisor — 理解”第三条隔离路线” → 拓宽技术视野
5. Daytona — 产品设计参考 → 理解市场需求
6. Kata Containers — OCI/K8s 标准化参考 → 了解企业云原生生态

2.8 读完本章你能做什么

• 能说出 6 个项目各自的核心隔离方式和一句话定位
• 能解释 microVM、用户态内核、容器级隔离三条技术路线的区别
• 能判断”哪个项目通读成本最低”“哪个项目在生产中被大规模使用”
• 心里有了一张「项目关系地图」，后面每读一章都往这张图上加细节

导读目录：README.md 上一章：第一章 · 这个领域在解决什么问题 下一章：第三章 · 隔离的五个层级：从「不设防」到「硬件防弹」