短文 · Infra Notes

MicroVM × AI Sandbox

容器太松、VM 太胖 —— microVM 把两端的好处凑齐

STATUS · NOTE DATE · 2026-05-11 READ · ~5 MIN
TL;DR
AI agent 跑用户指令、执行任意代码、调用工具 —— 它需要一个能扔进去就跑、跑完就扔的执行环境。容器隔离不够安全、传统 VM 启动太慢。Firecracker 这类 microVM 把"VM 级隔离"和"容器级启动"凑到了一起,成了这一两年 AI sandbox 这层基建的事实标准。

01Agent 为什么需要 sandbox

LLM agent 的能力来自它能"调工具"——读写文件、执行 shell、跑 Python、装包、curl 网页。这些命令是模型动态生成的,谁也不知道下一条会是什么。让 agent 直接跑在主机上,等于把 root 交给一个会幻觉的程序员。

所以 agent 必须有自己的隔离环境:

这套东西过去三十年的名字叫 sandbox。区别只是 —— agent 时代,sandbox 要快得多、便宜得多、隔得严得多

02容器 vs 传统 VM 的取舍

最直觉的方案是 Docker 容器:启动百毫秒级、镜像生态成熟、CI 里早就用滥了。但容器是共享内核的。Linux namespace + cgroup 只挡得住合规程序,挡不住 kernel-level 的逃逸 —— 历年 runc / containerd 都出过 CVE 能让容器内进程拿到宿主机 root。给一个会任意执行代码的 agent 用容器,安全模型上立不住。

另一头是完整 VM(QEMU + KVM 全设备模型)。VM 是 hardware-level 隔离,每个 guest 有独立内核,逃逸面小得多。代价是又胖又慢 —— 一个干净的 Ubuntu VM 启动要好几秒、占好几百 MB 内存、设备初始化拖一长串。给 agent 一会话拉一个完整 VM,成本和延迟都打不住。

CONTAINER → 共享内核 隔离强度 · 弱 启动延迟 · ~100ms 逃逸面:大 MICROVM → 独立内核 / 极简设备 隔离强度 · 强 启动延迟 · ~125ms 两端的好处都拿到 FULL VM → 独立内核 / 全设备 隔离强度 · 强 启动延迟 · 数秒 太胖:扛不住高密度
FIG 1三种隔离方式 · 安全 / 启动 / 密度的三角取舍
SIMULATE · 一个 kernel CVE 落下来会怎样
HOST KERNEL
CONTAINER
agent process
contained
MICROVM
agent process
contained
FULL VM
agent process
contained
共享内核 → kernel CVE 会让容器整个失守;microVM / VM 因为各自有独立内核,宿主内核被攻陷也不一定能横向移动到 guest。

03MicroVM 把两端凑齐

AWS 在 2018 年开源 Firecracker 解决的就是这个问题。Firecracker 是一个用 Rust 写的极简 VMM、跑在 KVM 之上,只支持 virtio 几种最必要的设备,启动路径被砍到能压在 125ms 量级、单 host 能跑上千个 microVM。它把"VM 级隔离"和"容器级启动"凑成了一对,也成了 Lambda / Fargate 的隐藏底座。

Firecracker 在 sandbox 场景额外有两个关键能力:

同类还有 Intel 的 Cloud Hypervisor、QEMU 的 microvm machine type、Google 的 gVisor(其实是用户态内核而非 microVM,但解决同一问题)。

0ms 50ms 125ms ~1s+ 冷启动 kernel + rootfs + init snapshot 唤醒 ~25ms ↑ 第一个会话付的成本 ↑ 之后每次会话都可以从这里起
FIG 2Snapshot / Restore · 把首次初始化的成本摊平到一次
EXPLORE · 拖一拖看 snapshot 攒下多少时间
30
Cold
3750ms
Snapshot
850ms
Cold = N × 125ms3750ms Snapshot = 125ms + (N−1) × 25ms850ms 省下2900ms · 77%

04落地的产品景观

过去两年涌出来一批 AI sandbox 服务,机制大致分两条路线:

产品 机制 典型启动延迟 面向
E2B Firecracker microVM ~150ms 通用 agent runtime
Fly Sprites Firecracker + NVMe + checkpoint ~300ms 带状态的会话
Blaxel microVM + 内存 snapshot ~25ms 极低延迟 resume
Modal 自研 microVM-like runtime sub-second task / 函数
Daytona OCI 容器 + FUSE volume ~90ms 开发环境(容器路线)

注意一个分歧:Daytona 走的是容器路线,赌注是"对 dev sandbox 而言隔离要求没那么强,速度 + 易用更重要"。其他几家都押 microVM——一是面向更敏感的用户输入(金融、医疗),二是 multi-tenant 场景下,隔离强度直接关系到能不能给免费用户开通道

05未来折叠点

MicroVM × AI sandbox 接下来两年要折叠的几件事:

MicroVM × AI sandbox 不是某种新发明,而是两条曲线撞在一起的工程后果:模型可以执行任意代码(需求侧),KVM + Rust + 极简设备模型把 VM 启动延迟拉到 100ms 量级(供给侧)。下一次撞曲线,可能是 WASM。
— 笔者按