做AI Agent的人，现在基本绕不开一个问题：大模型生成的代码、调用的工具、执行的命令，凭什么相信它是安全的？我自己的答案是：根本不信。所以沙箱不是可选项，而是默认前提。为了这事我把主流的隔离方案都试了一遍，最后把重心放在Firecracker这套微虚拟机方案上，从运行路径到安全边界都仔细过了一遍，踩坑不少，收获也很多。

这里先解释一下Firecracker到底是什么。它是AWS开源的一个轻量级虚拟机监控器（VMM），基于KVM硬件虚拟化技术，把每个“虚拟机”做成极小极轻的microVM形态。单个microVM的额外内存开销不到5MiB，从启动到实例运行最快能做到125毫秒以内，AWS Lambda和Fargate底层跑的就是这套。对Agent沙箱来说，我们的诉求恰好和Serverless高度重合：隔离要够硬、启动要够快、密度要够高、用完就能扔。

这篇文章我会先讲为什么Agent场景最终会选中Firecracker而不是Docker或gVisor，再拆一条完整的运行路径，从API请求到GuestOS里的Agent进程起来，最后把安全边界一层层剥开，附带我在真实环境里踩过的坑和排查记录。适合正在设计Agent执行环境、或者想给自己跑模型加一层“防手贱”机制的人参考。

1. 为什么Agent沙箱首选Firecracker而不是Docker或gVisor

1.1 从需求先说清楚：Agent跑代码为什么非要沙箱

大模型本身没有执行能力，Agent要真正干活，就得把“意图”翻译成代码、命令、API调用，然后丢给某个环境去跑。听起来很顺畅，但这里藏着一个大麻烦：模型生成的内容是不可信的。Prompt注入、工具参数构造、上下文里被塞进恶意指令，这些事情已经在真实业务里反复出现。你让Agent去查个数据库，它可能因为一段被污染的上下文，把不该执行的命令也执行了。

更现实的压力在于，Agent的未来形态一定包含自主写代码、自主调Shell、自主操作浏览器这类能力，这些能力本质上等于把键盘交给了一个“精神状态不稳定”的实习生。如果没有沙箱，它一个误操作就能删库、改配置、外发数据。所以沙箱要解决的核心问题不是“防病毒”，而是隔离风险：让Agent在受限环境里撒野，但别影响到宿主系统、其他服务和真实数据。

我自己在选型时给自己列了几条硬指标。第一，隔离必须是内核级的，不能只靠权限和命名空间；第二，启动时间要足够快，因为Agent任务往往是短时任务，几秒钟的冷启动会拖垮体验；第三，资源占用要小，能让几百个沙箱同时跑在一台机器上；第四，默认网络策略要可关可限，很多Agent任务根本不需要访问外网。这四条列完，Docker容器已经出局了，gVisor勉强能看，Firecracker则几乎是为这个需求量身定做的。

1.2 三种主流隔离方案对比：容器、gVisor和Firecracker怎么选

我见过不少团队用Docker当Agent沙箱，理由是简单、生态好、镜像随便拉。但容器的隔离本质是“共享内核+命名空间+cgroup”，攻击者一旦拿到容器里的root权限并发起内核漏洞利用，宿主机内核就直接暴露在攻击面下。内核0day对容器来说不是“会不会被打穿”的问题，而是“什么时候被打穿”的问题。

gVisor走的是另一条路：在用户态拦截并模拟系统调用，相当于给每个沙箱配了一个“翻译层”。好处是兼容性好一些，坏处是性能损耗明显，有些依赖原生syscall的程序（比如涉及io_uring、ptrace的）会直接罢工。对Agent场景来说，模型可能会生成各种底层操作代码，gVisor的兼容性风险不可控。

Firecracker则是把隔离边界直接拉到硬件层。每个microVM都有自己的内核、自己的地址空间，通过KVM在CPU层面做隔离。GuestOS里的进程即使拿到root权限、即使发起了危险的系统调用，也只会打到自己的内核上，对宿主机的影响被硬件边界挡住。对比一下就很清楚：

选Firecracker并不是因为它没有缺点，而是因为Agent沙箱这个场景的“不可信”属性太强。既然代码来源可能是模型“现场生成”的，那就要用最坏假设来设计，而不是用“通常没事”的心态来赌。

2. Firecracker运行路径全拆解：API进程、VMM进程与GuestOS启动

2.1 控制面与数据面分离：为什么API和VMM必须是两个进程

第一次看Firecracker源码时，最让我意外的是它把整个运行时拆成了两个进程。你启动一个firecracker二进制，它会先把自己fork成API进程和VMM进程。API进程负责监听Unix Domain Socket，接收宿主机发来的REST请求；VMM进程才是真正持有KVM文件描述符、管理vCPU线程和virtio设备的地方。

这个设计的安全价值很直接：控制面挂了不影响数据面。如果攻击者通过恶意的curl请求把API进程打崩，正在运行的microVM完全不受影响，VMM进程继续跑GuestOS里的任务。反过来，如果VMM进程出了严重问题，API进程还活着，宿主机管理端可以继续发命令做清理。两个进程之间只有极少的初始通信，之后各管各的。

实际操作时，默认的API监听地址是/tmp/firecracker.socket，你通过curl --unix-socket发起请求。每个microVM一个socket，互不干扰。对Agent编排平台来说，这意味着可以很方便地为每个Agent实例创建独立的控制通道，回收时杀掉socket进程就行。我见过有人把这个路径做进编排系统的服务发现里，我觉得是非常自然的用法。

2.2 从curl命令到microVM就绪：启动流程每一步做了什么

Firecracker没有像QEMU那样的“交互式控制台”，一切操作都通过API完成。启动一个microVM的流程其实可以归纳为四个请求：配置内核、配置磁盘、配置机器规格、启动实例。

• 第一步，PUT /boot-source，指定内核镜像路径和启动参数。内核镜像通常是vmlinux或bzImage，Firecracker要求内核开启了virtio支持。
• 第二步，PUT /drives/rootfs，挂载根文件系统镜像。这里可以指定is_read_only，直接把磁盘做成只读的，后面细说。
• 第三步，PUT /machine-config，设置vcpu数量、内存大小、是否开启SMT等。这个配置会在实例启动时一次性应用。
• 第四步，PUT /actions，请求体里写{"action_type": "InstanceStart"}，VMM立刻开始启动流程。

实例启动后，VMM加载内核到Guest物理内存，建立初始页表，设置CPU寄存器入口，然后让vCPU进入KVM运行状态。Guest内核开始自举：解压自身、初始化virtio设备驱动、挂载根文件系统、启动PID 1（通常是init或直接指定为容器的init程序）。整个过程在普通硬件上跑完也就是一百多毫秒。

这里有一个容易忽略的细节：boot参数里的console=ttyS0 reboot=k panic=1 pci=off几乎是标配。console=ttyS0是为了把内核日志输出到串口，方便用日志接口排查；pci=off是因为Firecracker不用PCI设备模型，告诉内核别扫PCI总线，能省不少启动时间。

2.3 Agent进程在GuestOS里的落地方式

内核起来了，根文件系统挂上了，接下来才是重头戏：Agent进程本身怎么跑进去。我试过两种方式，各有适用场景。

第一种是“预装进镜像”法。做rootfs的时候直接把Agent二进制、依赖库、启动脚本全部塞进文件系统，然后让PID 1进程在init脚本里把Agent拉起来。这种方案的好处是启动路径最干净，GuestOS一就绪Agent就在跑，没有额外的通信环节；缺点是镜像要跟着Agent版本频繁更新，升级一次就要重新打包一次rootfs。

第二种是“外挂下发”法。GuestOS里只装一个通用的Agent daemon（比如一个能接收任务的常驻进程），由宿主机通过vsock或MMDS（MicroVM Metadata Service）下发具体的任务负载和执行参数。这种方式将“运行环境”和“任务内容”解耦，镜像可以长期不变，任务参数走通道动态下发。我在生产环境里更推荐这种做法，因为Agent任务的内容随机性很强，不可能每次更新任务都去重新做镜像。

vsock是Firecracker内置的虚拟机通信机制，和宿主机之间建立一条专门的安全通道，不暴露网络端口。宿主机端可以打开/dev/vsock对应的socket，Guest端走/dev/vsock设备，两边约定端口号即可通信。我在实测中把agent的模型编排请求、任务输入、执行结果全部走vsock传输，干净利落。

还要提醒一点：GuestOS内部的Agent进程尽量不要用root跑。虽然microVM已经有了硬件隔离，但Guest内部软件的纵深防御仍然要做，Guest里的root一旦被拿到，攻击者可以改Guest内核模块、清理日志、篡改文件，给取证和审计带来麻烦。我的习惯是在Guest里创建一个低权限用户，Agent进程以该用户身份运行，文件系统关键目录对它只读。

3. 安全边界不会只有一层：Jailer、seccomp与只读根文件系统

3.1 Jailer怎么把VMM关进“笼子”

很多人以为Firecracker本身就是全部安全边界，其实Firecracker官方推荐的生产启动方式是要通过Jailer的。Jailer是Firecracker项目自带的一个安全加固工具，作用是把VMM进程本身关进一个“笼子”里，即使VMM进程被攻破，攻击者能做的事也被限制到极小。

Jailer做的第一件事是chroot。它会给每个microVM创建独立的chroot目录，把VMM二进制放进去，然后把工作目录、socket文件全部移到这个目录下。chroot之后，VMM进程能看到的文件系统就只剩下这个目录，宿主机的/etc、/home、/proc全部不可见。第二件事是切换用户，通过--uid和--gid参数把进程降权到专用UID/GID，禁止以root运行。

第三件事是绑定cgroup。Jailer会把VMM进程加到指定的cgroup中，从而限制它的CPU、内存、PID数量、设备访问范围。这样即使Guest攻击了VMM，也没办法把宿主机的CPU吃满、把内存耗尽、或者create一堆进程拖垮系统。

我用Jailer启动时的典型命令长这样：

jailer --id agent-demo \ --exec-file /opt/firecracker/firecracker \ --uid 1000 --gid 1000 \ --chroot-base-dir /var/lib/firecracker-jail \ --seccomp-level 2

执行完这条命令后，Jailer会完成chroot、降权、cgroup绑定、seccomp过滤，然后把控制权交给真正的VMM进程。在我自己的环境里，所有生产实例都强制走Jailer，直接裸跑firecracker二进制只在调试时用，这是一个不能讨价还价的原则。

3.2 seccomp过滤如何收敛内核攻击面

如果说Jailer控制的是“VMM能碰什么”，seccomp控制的就是“VMM能调用什么”。Firecracker的seccomp策略默认允许极少的系统调用集合，其他的系统调用一旦发出，直接被内核返回错误码，连进入VMM进程的机会都没有。

注意，这个过滤是作用在VMM进程上的，不是作用在GuestOS里的。GuestOS有自己的内核，Agent在自己内核里随便调syscall都会被Guest内核处理，影响不到宿主机。seccomp保护的是VMM本身：如果攻击者先攻破了VMM进程，想进一步利用漏洞打宿主机内核，第一道坎就是这些syscall过滤规则。

Firecracker的--seccomp-level参数有0、1、2三种级别。0是完全关闭过滤，适合在开发环境跑；1是过滤已知危险syscall；2是白名单模式，效果最强但也最严格。我在生产环境用级别2，实测下来没有遇到误拦，因为Firecracker官方对这部分的维护相当积极。

如果你需要确认seccomp是否在拦截，可以看宿主机的dmesg或audit日志。我遇到过几次Guest启动失败的情况，查日志发现是内核模块加载相关的syscall被拦了，把Firecracker升级到新版后问题消失。这种坑后面我会专门讲。

3.3 最小网络策略与不可变根文件系统

对Agent沙箱来说，网络往往是最大的风险面。Firecracker的默认配置是很让人安心的：不配网卡就没有任何网络。也就是说，GuestOS里跑的程序默认不能访问外网、不能访问宿主机的其他服务，这让许多数据外泄路径直接被封死。

如果某些Agent任务真的需要网络，我的做法是只给它一条虚拟网卡（通过tap设备），然后在宿主机上用iptables/ebpf规则把它限制到最小出站范围。比如只允许访问白名单域名，或者只允许走HTTPS的443端口，其余流量一律丢弃。Firecracker还支持对网卡做限速，在API中配置tx_rate_limiter和rx_rate_limiter，这样可以防止Agent跑一个Scapy流量风暴把出口带宽打满。

文件系统方面，我把rootfs全部设置为只读挂载。具体在API的PUT /drives/rootfs请求里加"is_read_only": true，这样Guest里的Agent即使被攻破，也没办法篡改系统文件、植入持久化后门、改启动脚本。临时数据统一写到内存文件系统tmpfs里，沙箱一停，内存一释放，所有痕迹跟着消失。

这条“只读系统+内存临时目录”的组合，好处是每个沙箱都变成了一次性用品：启动时是干净状态，运行时只能写内存，销毁后什么都不留。对Agent这种高不确定性的执行体来说，这种“用完即焚”的模型正好对路。

4. 实操记录：从零搭建一个最小Agent沙箱环境

4.1 准备内核、rootfs与Firecracker二进制

实操第一步是凑齐三个东西：Firecracker二进制、Guest内核镜像、最小根文件系统。Firecracker本身可以从官方release页面下载静态编译好的压缩包，解压后直接能用，不需要编译依赖。

# 下载并解压Firecracker v1.6.0 curl -LO https://github.com/firecracker-microvm/firecracker/releases/download/v1.6.0/firecracker-v1.6.0-x86_64.tgz tar xzf firecracker-v1.6.0-x86_64.tgz cd release-v1.6.0-x86_64 sudo cp firecracker /usr/local/bin/ sudo cp jailer /usr/local/bin/

内核镜像可以用Firecracker官方发布页里配套的linux内核二进制，里面已经编译好了virtio驱动和最小化配置，省去自己编译内核的麻烦。如果你有特殊要求再自行定制内核，否则直接用官方内核是最稳的。

根文件系统我用的是Ubuntu base镜像加debootstrap做出来的，这样在Guest里调试包管理和依赖比较顺手。先把目录填满，再打成ext4镜像。

# 制作一个512MB的rootfs镜像 dd if=/dev/zero of=rootfs.ext4 bs=1M count=512 mkfs.ext4 rootfs.ext4 # 挂载并填充系统文件 mkdir /mnt/agent-root mount rootfs.ext4 /mnt/agent-root debootstrap --arch=amd64 jammy /mnt/agent-root # 这里需要chroot进去设置root密码、添加agent用户、放Agent二进制 umount /mnt/agent-root

这一步最花时间的是chroot进去后的配置：设置网络、加上基本的动态库、把Agent启动脚本放到/etc/rc.local或systemd服务里。我建议第一次做的时候尽量精简，能用busybox就busybox，镜像越小启动越快，排查问题越容易。

4.2 通过API socket启动第一个microVM

环境准备好后，先起一个API socket，然后用curl发请求。这是Firecracker最典型的操作方式，所有步骤都在命令行里可见，出了问题方便逐步排查。

# 终端1：启动Firecracker，指定API socket路径 sudo ./firecracker --api-sock /tmp/firecracker.sock

# 终端2：配置内核 curl --unix-socket /tmp/firecracker.sock -i \ -X PUT 'http://localhost/boot-source' \ -H 'Accept: application/json' \ -H 'Content-Type: application/json' \ -d '{ "kernel_image_path": "/path/to/vmlinux.bin", "boot_args": "console=ttyS0 reboot=k panic=1 pci=off" }' # 配置根文件系统（只读） curl --unix-socket /tmp/firecracker.sock -i \ -X PUT 'http://localhost/drives/rootfs' \ -H 'Accept: application/json' \ -H 'Content-Type: application/json' \ -d '{ "drive_id": "rootfs", "path_on_host": "/path/to/rootfs.ext4", "is_root_device": true, "is_read_only": true }' # 配置机器规格：2 vCPU，512MB内存 curl --unix-socket /tmp/firecracker.sock -i \ -X PUT 'http://localhost/machine-config' \ -H 'Accept: application/json' \ -H 'Content-Type: application/json' \ -d '{ "vcpu_count": 2, "mem_size_mib": 512, "smt": false }' # 启动实例 curl --unix-socket /tmp/firecracker.sock -i \ -X PUT 'http://localhost/actions' \ -H 'Accept: application/json' \ -H 'Content-Type: application/json' \ -d '{"action_type": "InstanceStart"}'

如果一切正常，Guest Linux会开始启动，控制台日志会输出到Firecracker进程的终端。你会看到内核从解压、初始化virtio设备到挂载rootfs、启动init的完整过程，全程不到两秒。启动成功后再去Guest里检查一下进程，Agent应该已经在跑了。

4.3 放入Agent程序并配置资源限制

Agent程序的放置方式我前面说了，强烈建议用vsock外挂下发，而不是打死在镜像里。这样你需要先在Guest里跑一个常驻Agent daemon，监听vsock端口。

我自己的实现是这样的：Guest内的daemon用一个小型HTTP服务跑在vsock之上，宿主机通过专用socket给它发JSON格式的任务，里面包括要执行的Python代码、Shell命令参数、以及一些环境变量。daemon收到任务后，在受控的临时目录里执行，把stdout、stderr、退出码打包返回。整个通信不经过网络栈，没有TCP/IP暴露，干净利落。

资源限制方面，除了在machine-config里指定vCPU和内存，Firecracker还支持块设备和网络的速率限制。比如给根文件系统的读流量加一个Token Bucket限制：

curl --unix-socket /tmp/firecracker.sock -i \ -X PATCH 'http://localhost/drives/rootfs' \ -H 'Accept: application/json' \ -H 'Content-Type: application/json' \ -d '{ "drive_id": "rootfs", "path_on_host": "/path/to/rootfs.ext4", "is_root_device": true, "is_read_only": true, "rate_limiter": { "bandwidth": { "size": 1048576, "one_time_burst": 1048576, "refill_time": 100 }, "ops": { "size": 100, "one_time_burst": 100, "refill_time": 100 } } }'

这样即使Guest里的Agent写了个死循环疯狂读磁盘，也不会拖垮宿主机的IO。对CPU的进一步限制可以在宿主机cgroup v2里对Jailer进程做配额管理，限制它最多使用多少个CPU时间片。

5. 排查实录：我踩过的那些坑与对应解法

5.1 /dev/kvm不存在或被拒绝：检查权限与嵌套虚拟化

Firecracker依赖KVM，因此宿主机必须有/dev/kvm设备，并且运行用户要有访问权限。如果你在自己的电脑上装好了Firecracker却发现Guest起不来，第一步就是检查这个。

ls -l /dev/kvm

如果设备不存在，大概率是CPU不支持虚拟化，或者BIOS里没开VT-x/AMD-V，又或者你本身就跑在一台云主机上，而云厂商没有开启嵌套虚拟化。第二种常见的情况是你在Docker容器里跑Firecracker，那容器需要--device=/dev/kvm和足够的权限，才能把KVM设备透传进去。

如果/dev/kvm存在但权限不对，把运行用户加到kvm组就行：

sudo usermod -aG kvm $USER

这个坑本身不难，但很容易在环境初始化时被忽略，一旦出现，后面的所有流程都白搭，所以我把检查KVM这一步写成了部署脚本里的第一条前置校验。

5.2 seccomp过滤误伤导致Guest启动失败

Jailer在生产环境开--seccomp-level 2后，有时候Guest会莫名其妙启动失败，宿主机日志里出现类似SECCOMP_RET_TRAP或系统调用被拒绝的记录。

我遇到过一次是因为内核需要加载某个模块，触发了VMM进程里的init_module系统调用，而该调用不在白名单里。Firecracker的设计原则是“宁可拒绝，不可放过”，所以它直接返回错误，Guest启动流程就卡住了。

排查思路是先确认是不是seccomp的原因：把--seccomp-level临时降到1，重启实例，如果Guest能起来，基本可以断定是seccomp白名单过严。接下来看宿主机日志定位具体被拦截的是哪个syscall，然后判断是升级Firecracker版本（新版本白名单更全），还是在Jailer配置里单独放行。千万不要为了省事把seccomp关了上生产，那是拿命在赌。

5.3 只读根文件系统下的临时数据与快照恢复问题

把rootfs设为只读后，第一个发现就是很多程序喜欢往/var/log、/var/run、/tmp写东西。如果不处理，这些进程一启动就会因写失败而退出。

解决方案是把这些目录挂成tmpfs，让Guest内可写区域只存在于内存。比如在Guest的init脚本里加上：

mount -t tmpfs tmpfs /tmp mount -t tmpfs tmpfs /var/log mount -t tmpfs tmpfs /var/run

这样Agent跑起来的日志、临时文件都在内存里，沙箱停止即清空。我建议你把日志接收也做进vsock通道，定时把日志拉到宿主机持久化，不然Guest一销毁日志也跟着没了。

快照恢复是Firecracker很有用的功能，但注意第一，恢复时的Firecracker版本和启动时的版本必须一致，跨版本恢复容易出问题；第二，CPU特性必须兼容，所以生产环境要固定CPU型号或用cpu_template来统一特性集。这几点如果没做到，恢复出来的Guest可能出现非法指令或莫名panic，排查起来相当痛苦。

5.4 资源不足与OOM：内存配置别拍脑袋

Firecracker的microVM内存是按需分配的，但Guest内核的加载、rootfs的页缓存都会消耗宿主物理内存。如果你把mem_size_mib配得太小，比如64MB，某些Agent任务一跑起来就可能触发Guest内核的OOM killer，把Agent进程杀掉。

我的建议是最小从256MB起步，带Python运行时的话512MB起步，真正跑模型推理任务的再往上加。另外宿主机要给Firecracker留出足够的预留内存，别把整机内存都分光了，否则宿主机自身出现OOM会影响所有沙箱的稳定性。

我还习惯在编排系统里统一加一层健康检查：定时通过vsock向Guest发心跳包，如果几次都没响应，说明沙箱可能已经卡死，直接销毁重启一个新的microVM，保证Agent任务高可用。

最后说点个人体会

把Agent放进Firecracker这件事，技术上并不算复杂，真正难的是对“安全边界”始终保持敬畏。我见过太多人只配了Docker就敢让模型跑代码，也见过有人把所有安全机制全堆上之后被兼容性问题磨掉了耐心。我的建议是：隔离层选最硬的，Guest内软件做最小化，网络策略默认全关，然后定期升级Firecracker、关注release notes里的安全修复。

我自己有个小习惯，每次新版本发布后都会在一个临时环境里跑一遍“沙箱逃逸演练”——用常见的提权手法、内核模块加载、设备文件访问等手段去尝试折腾Guest，确认它还是安安分分待在笼子里。这套动作虽然不能证明绝对安全，但至少能在问题真正发生之前心里有底。

如果你也在做Agent沙箱或者类似的不可信代码执行环境，欢迎沿着这条路径自己搭一套试试。先说清楚：第一次跑通的时候，你会觉得“不过如此”；等你真正遇到一个被Guest折腾到宿主机毫无反应的场景，然后意识到Firecracker的隔离替你扛住了所有的时候，你才会明白这个“不过如此”到底值多少。