AI Agent 沙箱实战：用 Firecracker 微虚拟机构建可信代码执行环境

AI Agent 干起活来越来越像人了——让它写个脚本，它唰唰就写完；让它跑个爬虫，它也毫不含糊直接开搞。但问题恰恰出在这：你敢让一个会执行任意代码的 Agent 直接跑在自己笔记本或者服务器上吗？答案大概率是不敢。我见过太多团队，Agent 写出来的代码一执行，轻则把宿主机的环境变量搅乱，重则密钥泄露、系统文件被删，场面相当难看。这时候 Agent Sandbox 就成了刚需，而这一两年我身边越来越多的人在聊 Firecracker——AWS 开源的那个微虚拟机 VMM——用它来搭 Agent 隔离环境。这篇文章不打算从零科普虚拟化，而是想从一个实际交付过的角度，把 Firecracker 的运行路径、安全边界、还有那些文档里不会写明白的坑，一次说透。

这套方案适合三类人：一是正在搭建 Agent 代码执行环境、但还没找到合适隔离手段的开发者；二是已经在用 Docker 做沙箱、但心里一直觉得共享内核不踏实的基础设施同学；三是对微虚拟机、KVM 安全模型感兴趣的技术爱好者。看完之后，你能直接照着文中的思路搭一个实验性的 Firecracker 沙箱，并且理解每一步操作背后的安全意义。

1. Agent 为什么需要专用沙箱，Firecracker 的切入点在哪

1.1 Agent 执行代码，怕的不是能力，是边界

先聊聊 Agent 沙箱这个需求到底是怎么被放大的。过去我们写自动化脚本，跑在 CI 上、跑在临时服务器上，出了问题删掉重来就行；但大模型驱动的 Agent 不一样，它生成代码是“生成即执行”，而且经常是自主决定下一步动作。比如一个写数据分析报告的 Agent，它可能需要安装 pip 包、调用外部 API、读写文件；一个网页 Agent 可能要去抓取页面、解析 JS、模拟点击。

这些行为本身没问题，问题在于：你没法预判它生成的每一行代码是安全的。模型可能在推理中被 prompt 注入干扰，也可能只是简单地把一个路径写错了——比如把临时目录写成了/etc，或者把一个删除操作写到了用户主目录上。更麻烦的是，Agent 运行环境里如果恰好有生产环境的密钥、配置，它可能在毫不知情的情况下把这些信息发到不该去的地方。

所以 Agent 沙箱要解决的核心问题不是“代码能不能跑”，而是“代码在哪儿跑、能摸到哪些东西、出事之后怎么收场”。隔离越硬，失控成本就越低。

1.2 Docker、gVisor、Firecracker 到底谁合适

现在业界的隔离方案大概分三个流派：

容器方案（Docker/containerd）。优点是生态成熟、镜像多、性能损耗极小；缺点是所有容器共享宿主内核，一旦有内核提权漏洞，连同宿主一起遭殃。对于那些长期跑不可信代码的业务——比如多租户的在线编译服务——这已经是被反复证明过的高风险选择。

用户态内核方案（gVisor）。Google 的做法是在用户态模拟一个内核层，拦截容器内大部分系统调用，在 host 内核边上再立一道墙。性能损耗比纯容器大，但安全性提升明显。问题是 Agent 代码往往要跑大量文件 I/O、网络、进程 fork，这类负载在 gVisor 上经常性能怪怪的，尤其是 Python 这种性能敏感的解释器 + 原生库组合。

微虚拟机方案（Firecracker / Kata / QEMU）。每个沙箱其实是一台虚拟机，有独立的 guest 内核，和宿主内核彻底解耦。Firecracker 是其中最激进的一个——它砍掉了 QEMU 那种完整设备模拟，只保留极少的 virtio 设备，启动时间压到几百毫秒，内存开销最低可以做到一百多 MB 跑一个 Linux 实例。AWS 的 Lambda、Fargate 就是拿它做底层隔离的。Agent 场景下，代码执行环境的边界需求、多租户隔离需求、快速启动销毁需求，几乎就是照着 Firecracker 的能力模型画的。

这里我直接给一个选型倾向：如果你的 Agent 只跑纯逻辑计算、不碰危险系统调用，用 Docker 省事；如果要在不可信模型输出环境下跑完整代码周期，并且运维上能接受一定的调优成本，Firecracker 是当前最平衡的答案。

1.3 一个为 Serverless 而生的 VMM 的设计观

Firecracker 的定位从第一天起就不是“通用虚拟机管理器”。它是 AWS 为了解决 serverless 场景下“既要强隔离又必须便宜”这个矛盾而造的。用 Rust 实现的 VMM，整个二进制只有几 MB；没有 BIOS、没有 PCI 枚举、没有任何多余的模拟设备；控制面暴露一个尽量薄的 HTTP API，跑在 Unix socket 上；一台宿主机可以稳定跑几百个 microVM，而不是像 QEMU 那样动辄吃几个 GB 内存。

这套设计观放在 Agent 沙箱场景里很有意思：Agent 的任务天然是短时的、并发的、需要快速回收的。一个 Firecracker microVM 从创建到销毁可以做到秒级生命周期，空闲就杀掉，忙碌就扩容，完全不需要维护一堆长时间驻留的容器。而且因为每个 VM 都是独立内核，哪怕 Agent 在里面把系统搞挂了，也只是挂掉它自己那一台，宿主和其他沙箱毫发无伤。

2. Firecracker 运行路径全拆解：从 Agent 请求到 microVM 销毁

2.1 请求编排与沙箱池：从入口到分配

先看整体架构。假设你有一个 Agent 控制面服务（比如部署了一套自托管的 Agent 平台），用户发来一个任务，控制面判断这个任务需要执行代码，于是调用沙箱管理服务，请求分配一个隔离环境。沙箱管理服务维护着一个 microVM 池：提前创建好若干已经启动、处于空闲等待状态的 Firecracker 实例，任务来了直接复用，任务结束就重置或销毁。

用池化而不是每次现场冷启动，这里有一个实际考量：Firecracker 启动一个 microVM 虽然只要几百毫秒，但加上内核镜像读取、rootfs 挂载、网络接口初始化，冷启动总会引入额外延迟。Agent 任务本身已经够不可控了，基础设施上能省的时间别浪费。池子的大小根据峰值并发和单 VM 最大执行时长来估算，保守做法是控制面服务内部做一个简单的水位线调度：池子低于下限就补，高于上限就缩。

每个沙箱会对应一个独立的 Firecracker 进程，进程之间完全隔离。这个“一进程一 VM”的模型是 Firecracker 安全性的骨架，后面讲边界时会再展开。

2.2 镜像配置与启动链路：那些 API 调用背后发生了什么

Firecracker 的控制面是一个放在专用目录里的 Unix socket，你可以用 curl 或它的官方 SDK 直接驱动。下面是启动一个 microVM 的典型配置流程：

第一步，通过 jailer 启动 Firecracker 进程。jailer 会在一个干净的目录里 chroot，摒弃多余 capabilities，并且设置 cgroup 资源限制。

# 以 jailer 方式启动 Firecracker，监听 socket ./firecracker \ --api-sock /srv/jailer/fc-sandbox-01/api.socket \ --exec-file /usr/bin/firecracker \ --uid 1000 \ --gid 1000 \ --chroot-base-dir /srv/jailer \ --netns /var/run/netns/sandbox-01

这里有几个容易忽略的点：--uid/--gid让 Firecracker 进程以非 root 用户运行；--netns让每个沙箱拥有独立的网络命名空间，网络栈完全隔离；chroot 之后，Firecracker 进程能看到的东西被限制在fc-sandbox-01这个目录里。

第二步，通过 API 配置内核和磁盘镜像。

# 配置内核镜像 curl --unix-socket /srv/jailer/fc-sandbox-01/api.socket \ -X PUT "http://localhost/boot-source" \ -H "Content-Type: application/json" \ -d '{ "kernel_image_path": "/opt/agent-kernel/vmlinux-6.1", "boot_args": "console=ttyS0 reboot=k panic=1 pci=off" }' # 配置 rootfs curl --unix-socket /srv/jailer/fc-sandbox-01/api.socket \ -X PUT "http://localhost/drives/rootfs" \ -H "Content-Type: application/json" \ -d '{ "drive_id": "rootfs", "path_on_host": "/srv/jailer/fc-sandbox-01/rootfs.ext4", "is_root_device": true, "is_read_only": false }' # 设置虚拟机规格 curl --unix-socket /srv/jailer/fc-sandbox-01/api.socket \ -X PUT "http://localhost/machine-config" \ -H "Content-Type: application/json" \ -d '{ "vcpu_count": 2, "mem_size_mib": 512 }' # 启动实例 curl --unix-socket /srv/jailer/fc-sandbox-01/api.socket \ -X PUT "http://localhost/actions" \ -H "Content-Type: application/json" \ -d "{\"action_type\": \"InstanceStart\"}"

boot_args里的细节值得琢磨：console=ttyS0把内核日志输出到串口，方便排查；reboot=k防止内核重启导致宿主端异常；panic=1让 panic 后自动重启，至少在 VM 层面快速恢复。pci=off则是 Firecracker 经典参数，因为整个虚拟设备模型走 mmio 而不是 PCI 枚举，关掉 PCI 能省掉不少启动时间。

第三步，配置网络接口。这里有两种选择：virtio-net 接 TAP 设备，或者 virtio-vsock 只做 socket 通信。对 Agent 沙箱来说，我强烈建议默认走 vsock——guest 和 host 之间一条私密的双向 socket 通道，不需要 IP 配置，不暴露外部网卡，也不容易碰到 MAC 地址冲突。

# 通过 vsock 给沙箱提供控制通道 curl --unix-socket /srv/jailer/fc-sandbox-01/api.socket \ -X PUT "http://localhost/vsock" \ -H "Content-Type: application/json" \ -d '{ "guest_cid": 42, "uds_path": "/srv/jailer/fc-sandbox-01/vsock.sock" }'

启动之后，内核会在几十毫秒内完成引导，rootfs 里的 init 进程起来，沙箱进入就绪状态。整个过程从 API 触发到 guest 内 agent 进程存活，实测通常只需要 300ms 左右。

2.3 任务执行与结果回收

microVM 启动好之后，宿主侧的任务就变成：把 Agent 的代码传入 guest，运行，回收输出。

传输路径用 vsock 最干净。host 侧监听vsock.sock，guest 侧通过/dev/vsock连接 host，两边约定好一个简单的消息协议——比如 JSON 行协议，每行一个{cmd, script, timeout}；或者干脆跑一个轻量 gRPC。代码示例：

# host 侧，通过 vsock socket 下发任务 import socket VSOCK_PATH = "/srv/jailer/fc-sandbox-01/vsock.sock" def dispatch(sock_path, payload): with socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) as s: s.connect(sock_path) s.sendall(payload.encode()) resp = s.recv(65536) return resp.decode()

guest 内的 agent 进程只做一件事：收到任务，在受限的 shell 里执行脚本，把 stdout/stderr 打回去。执行完，沙箱管理服务可以选择把 VM 重置到干净状态，或者直接销毁。重置用 Firecracker 的快照功能，但初次落地不建议上来就搞快照——后面我会专门讲这个坑。

超时控制这条线必须在 host 侧双保险：guest 内设timeout命令，host 侧再加一个 goroutine/线程定时器。到了设定时间直接 kill Firecracker 进程。注意 kill 掉进程就是硬断电，guest 里残留的临时数据跟着一起消失，这正是沙箱该有的脾气。

3. 安全边界分析：Firecracker 到底把防线拉到了哪一层

3.1 信任模型：guest root 能干什么，不能干什么

很多第一次接触 Firecracker 的人会有一个疑问：Agent 在 VM 里拿到了 root 权限，那是不是和宿主 root 没区别了？大错特错。

在 KVM 硬件虚拟化模型下，guest 里的 root 只是 guest 操作系统内部的最高权限。它运行在 CPU 的 guest 模式下，能控制的是 guest 的页表、guest 内核、guest 的所有进程。它看不到 host 物理内存的原始内容，改不了 host 上的其它进程，也碰不到物理设备。它最“出格”的行为，也就是把 guest 内核搞崩、或者向 virtio 设备提交恶意请求。但这些请求最终会经过 virtio 的 ring buffer 送到 host 侧的 Firecracker 进程，由 VMM 来翻译、校验、执行。换句话说，guest root 的控制半径被硬件和 VMM 明确框死了。

对比之下，Docker 容器里的 root 如果不配合用户命名空间和只读挂载，某些情况下能通过nsenter、ptrace、挂载伪文件系统等方式触碰宿主内核。如果遇到内核漏洞，容器 root 可以直接变宿主 root。共享内核永远是容器隔离绕不过的短板。

所以信任模型的结论很简单：guest root 不等于 host root，这是 Firecracker 安全边界的地基。KVM 硬件虚拟化的历史非常长，Intel/AMD 的虚拟化扩展经历了大量实战检验，攻击难度和容器提权完全不在一个量级。

3.2 jailer + seccomp：VMM 自身还能少多少权限

Firecracker 进程本身才是真正有 host 权限的实体——因为 virtio 设备、API、内存映射都是它在处理。所以安全设计的第二层就是极力压缩这个进程的权限。

jailer 做的事情比较多，逐条理一下：

• chroot：把 Firecracker 进程关进一个专属目录。即使 VMM 被攻破，能遍历的文件系统只有目录内那点东西。
• capability drop：启动后立即丢到极少的 capabilities，不允许再往 mount namespace、socket 创建这类高权限操作上靠。
• cgroup 隔离：CPU、内存、PID 数量全部限死。
• seccomp：Firecracker 进程内部还加了一层 BPF 过滤器，只放行它运行必需的那几十个系统调用。漏过一个调用都不行，实测中clone、execve、openat、read/write这类是主流，其余一律默认拒绝。

拿 6.1 内核的 Firecracker 来说，它的 seccomp 白名单控制在 70 个系统调用左右。这个数字可以自己去 Firecracker 的seccompiler配置目录里翻，它把每条规则都写得很清楚。

还有一个细节：Firecracker 的进程模型是单线程 VMM + vCPU 线程。vCPU 线程在运行 guest 指令时是直接占用物理 CPU 的，它们本身不执行什么业务逻辑；真正处理控制面请求、虚拟设备读写的是主线程和 IO 线程。线程之间的隔离边界，让攻击者即使控制了一个 vCPU 线程，也拿不到宿主进程的完整地址空间。

3.3 攻击面到底还剩多少

把虚拟化这层剥开，剩下的攻击面其实很窄：

• KVM 本身。这是虚拟化边界上最大的攻击面，Firecracker 完全依赖 KVM，自己不做任何软件模拟来绕过它。历史上 KVM 确实出过漏洞，但这是所有轻量级微 VM 方案的共同风险。宿主内核保持最新补丁，是防线里必须做的一环。
• virtio 设备模型。Firecracker 只实现了 virtio-net、virtio-block、virtio-vsock、串口。每个设备的实现都是用 Rust 写的，内存安全上有先天优势。即便如此，设备模型的正确性仍是安全审计的重点——尤其注意is_read_only: false这种磁盘配置别乱开。
• API 面。控制 HTTP API 监听在 Unix socket 上，意味着只有同一宿主上拥有该 socket 权限的用户/进程能操作它。把 socket 文件权限设为仅沙箱编排服务可读写，基本能封死这条路径。
• Guest 内的软件漏洞。沙箱里的 Agent 代码、解释器、底层系统库如果有漏洞，攻击者拿到的也只是 guest 权限，还得再走虚拟化边界。最坏情况是被当成一台普通虚拟机进行横向侦察，但出不去 VM，影响有限。

三层防线叠起来的效果是：即使 guest 里跑的是恶意至极的代码，攻击者仍然需要连续突破 guest 内核加固、KVM 虚拟化边界、seccomp + jailer + 资源限制四道关卡，才能摸到宿主内核。这个“纵深防御”的密度，是共享内核方案给不了的。

4. 实操：成本控制、性能调优与问题排查

4.1 资源参数与性能调优

Firecracker 的配置自由度不算高，但几个参数值得用心调。

内存大小。128MB 能跑一个很精简的 Alpine Linux，但上面要跑 Python 解释器和 Agent 框架的话，建议至少 512MB 起步。给大了浪费，给小了 Agent 经常 OOM。我个人的经验是：先给 512MB 跑一个标准 Agent 任务，观察 guest 内内存的峰值，再决定上下浮动。注意宿主的 overcommit 设置——如果/proc/sys/vm/overcommit_memory是 2，那么你物理机有多少内存，就只能开多少个 VM，Firecracker 不会偷内存。

vCPU 数量。默认 1 够用，但 Agent 代码里如果会有并行 fork 或者轻度计算密集，给 2 个会让沙箱的响应快不少。量大的时候注意宿主 CPU 的 oversubscription——和内存不同，CPU 超卖是常态，但超得太狠时会出现“vCPU 线程互相抢”导致的毛刺性能。

内核镜像。强烈建议自己编一个精简内核，而不是直接用发行版全家桶。我一般用 6.1 LTS，裁剪掉几乎所有块设备驱动、声音、显卡、无线，保留 ext4、virtio、vsock、IPv4 网络栈。一个精简内核从 30MB 缩到 6~8MB，启动时间能快近一半。内核 config 的模板可以网上搜索 “firecracker minimal kernel config”，很多项目都把可用的 config 直接开源了。

启动速度的三个优化点：

• 关闭串口控制台日志：console=none能省掉大量的字符输出开销。
• 使用vmlinux而不是bzImage：省掉解压环节，少几十毫秒。
• 吃透 snapshot：预启动一台干净 VM，做完快照，之后每创建一个新沙箱就从快照恢复。这个能把冷启动从 300ms 压到 50ms 以内。注意快照恢复有前提：只能在同内核、同 CPU 型号、同 Firecracker 版本的宿主间迁移，而且需要单独开启 dirty page tracking，否则恢复出来的 VM 可能数据不一致。

4.2 常见问题与排查速查表

这套体系里最容易翻车的点，我把它们按踩坑频率排了个序：

还有一个老生常谈但要再提的情况：不要在 host 上随便关掉 KVM 的 nested virtualization。很多笔记本跑虚拟化靠的是宿主再套一层 KVM，如果 host 又把 KVM 暴露给 guest，Firecracker 在 guest 内是起不来的，会误以为是 Firecracker 的问题。

4.3 安全使用的几条建议

最后是使用层面的安全经验，这些不是 Firecracker 配置能解决的，但能极大减少整体风险：

• 每个沙箱分配独立的 TAP 设备和独立网络命名空间。哪怕 guest 被完全控制，也没法直接从网络摸其它沙箱。
• 不要把任何生产密钥、云厂商 credential 放进 rootfs。Agent 沙箱应该默认是个“零信任”环境，要用什么临时动态注入。
• 磁盘按需求设置is_read_only，正常 Agent 不需要写 rootfs 就全程只读；需要写临时文件的，挂一个独立的可写数据盘而不是改动 rootfs。任务结束直接销毁数据盘，比“清理”干净得多。
• 在编排服务层面对 Agent 行为做白名单管理。Firecracker 防止的是代码“越狱”到宿主机，但 Agent 自己的 prompt 可能被诱导去做危险操作——比如调用内网服务、下载恶意 payload。控制面要用合适的策略（比如 egress 域名白名单、CPU/内存配额）做第一道把关。

最后聊点个人实操中的真实体会

用 Firecracker 搭 Agent 沙箱的过程中，我最深的感受是：这套组合真正解决了 Docker 方案解决不了的那层信任问题。代码执行环境出事故之后，你不用再连夜排查宿主上有没有留下什么 rootkit，大不了销毁 VM，五秒钟之后一个新的干净沙箱又起来了。这种“廉价的重生能力”，是生产环境里最值钱的特性。

但也得说实话，它不是一个零成本的方案。你需要维护精简内核、管理快照、调 cgroup、理解 KVM 的边界，前期的工程投入比“docker run 一下”高不少。好在这些投入是一次性的，一旦把池子、快照、调度这几块理顺，后面运维省心很多。如果你团队里正好有一个能在 Linux 内核和虚拟化层折腾的人，那这个路线的回报会远超预期。