前阵子有同事问我能不能让 Agent 帮我改一百个文件的代码直接跑在 CI 机子上不就行了我第一反应是千万别。现在的 Agent 能力边界越来越大它能读环境变量里的密钥能往~/.ssh里塞东西能调用系统里几乎所有命令行工具甚至能自己起一个 HTTP 服务把数据传出去。如果它被一段藏在网页里的提示词注入骗了这个盒子里装的可不是普通程序而是整台机器的控制权。所以在把 Agent 变成生产力之前第一步要想清楚怎么把它关起来。这篇文章我想把“怎么关”这件事完整拆一遍先说为什么必须用虚拟机级的隔离再说 Firecracker 的运行路径长什么样最后把安全边界的每一层墙和每一扇门都标清楚。适合正在搭 Agent 执行环境、做 AI 基础设施、或者对沙箱方案选型犹豫不决的工程师看。1. Agent 必须被装进盒子先弄清楚威胁在哪1.1 Agent 的真实能力比你想的大Agent 和传统服务的最大区别在于它在运行时的行为是不可预期的。你不只是在部署一个确定逻辑的进程而是给一个语言模型接了终端、文件系统和网络然后让它自己决定怎么操作。它能执行 Python 脚本、跑 shell 命令、读写项目目录、安装依赖、调 git push甚至自己起一个本地服务做端口转发。这会带来几类很现实的风险。第一类是提示词注入外部内容——网页、邮件、GitHub issue 里的文字——可能说服 Agent 执行恶意指令。第二类是工具链不可信第三方 MCP 服务器或下载的脚本可能本身就是木马。第三类是敏感数据外泄Agent 读取了密钥或内部文档然后把它们写进一个外部 API。第四类是供应链污染它执行了一个被篡改的安装命令在项目里埋下后门。一个不错的类比是Agent 是一个执行力很强的实习生你把钥匙、银行卡、公章都交给了它但它分不清谁是“老板”谁是“骗子”。我们的工作不是去教模型分辨真假而是给这个实习生一间没有公章、没有银行卡、只有一次性办公用品的房间。1.2 传统隔离方式在哪里失效很多人第一反应是用 Docker 隔离。Docker 做应用打包确实优秀但它的边界模型和 Agent 要应对的风险并不匹配。Docker 容器共享宿主内核逃逸一旦发生攻击的目标就是整个宿主机内核而在 Agent 场景里一台机器上可能同时跑几十个不同租户的任务任何一次内核提权都会让所有历史数据暴露。我拿几个维度快速对比一下维度进程级沙箱容器共享内核传统虚拟机Firecracker 微虚拟机隔离边界命名空间 seccomp同一内核内的隔离硬件虚拟化 独立 Guest 内核硬件虚拟化 独立 Guest 内核是否共享内核共享共享不共享不共享启动延迟毫秒级毫秒级秒级百毫秒级内存开销极小较小GB 级别起步几十到几百 MB设备模型无无大量模拟设备攻击面大极简 virtio 设备逃逸后的影响面内核提权直达宿主内核提权直达宿主攻破 VMM 后仍需二次防御VMM 进程已被降权进程级沙箱的问题是配置太复杂任何一条 seccomp 白名单写宽了边界就等于没有。传统虚拟机隔离强度够了但启动慢、内存浪费、设备模型庞大用在“创建销毁频繁”的 Agent 场景里非常痛苦。Firecracker 正好卡在中间有硬件虚拟化的强度又有接近容器的快速启动和低内存。1.3 为什么 Agent 场景必须单独做一套沙箱Agent 负载和传统微服务还有一个本质差别微服务可以假设自己只做一件事Agent 却会被要求做各种意料之外的事情。它有某种程度的“主观能动性”会尝试解决 prompt 描述的问题过程中可能删文件、装软件、发请求。如果把它放在一台和同事共享的开发机上一次误操作就可能污染所有人的环境。所以 Agent 沙箱需要三个特性强隔离一个 Agent 拿不到另一个 Agent 的状态、文件和凭据。快速启停任务一来能立刻拉起任务一走能彻底销毁。可观测它做了什么必须留下审计日志。这三个需求Firecracker 的微虚拟机模型都能很好满足。不过在选型之前把“为什么要隔离”想清楚后面所有边界设计才不容易跑偏。2. Firecracker 的运行路径请求进去进程出来如果用一句话概括 Firecracker我会说它是专门为“高密度、短生命周期虚拟机”设计的 KVM 微虚拟机管理器。不少云厂商的无服务器产品都靠它支撑。它用 Rust 实现目标不是替代 QEMU而是把设备模型砍到最少让一台物理机可以同时跑成百上千个 microVM。下面沿着一条创建请求把运行路径完整走一遍。2.1 设备模型精简到什么程度Firecracker 向 Guest 暴露的设备极其有限virtio-net网络、virtio-block块设备、virtio-vsock宿主机与 Guest 的本地通信、串口控制台以及一个用于触发 soft reset 的 i8042 控制器。其它什么 BIOS 设备、USB、声卡、显卡、ACPI、PCI 热插拔一概没有。这不是偷懒而是刻意为之设备模型是 VMM 进程里最大的代码面每一个设备都意味着新的解析逻辑和新的漏洞入口。传统虚拟机像租了一套带全套家具的样板房Firecracker 只给你一张床和一张桌子——住得简陋但能进来的“陌生人”也少得多。Guest 启动也不是传统 BIOS 引导而是由 Firecracker 直接把内核镜像载入内存用指定的 boot args 启动。内核参数里常见consolettyS0、noapic、rebootk、panic1、pcioff这些。因为没有 BIOS/ACPI 那套内核必须在极简硬件环境下跑起来这反过来也逼着镜像把不必要的驱动都剔掉。2.2 一次完整的创建到启动路径一条创建请求走下来大致是这样的编排层为实例创建 UNIX domain socket把 JSON 请求通过 HTTP 发给这个 socket。先配置 machine-configvCPU 数、内存大小、CPU 模板。再配置 boot-source内核镜像路径和内核启动参数。配置 drivesrootfs 路径、是否只读、缓存类型。配置 network-interface绑定到已创建好的 tap 设备。可选配置 vsock给本地通信留一条高速通道。最后发送 InstanceStart 动作KVM 开始跑 vCPUGuest 内核启动init 起来后运行环境就绪。一个典型的配置长这样{ boot-source: { kernel_image_path: ./vmlinux.bin, boot_args: consolettyS0 noapic rebootk panic1 pcioff }, drives: [ { drive_id: rootfs, path_on_host: ./rootfs.ext4, is_root_device: true, is_read_only: true, cache_type: Unsafe } ], machine-config: { vcpu_count: 2, mem_size_mib: 1024, track_dirty_pages: true }, network-interfaces: [ { iface_id: eth0, host_dev_name: tap0, guest_mac: 06:00:00:00:00:01 } ] }字段略有版本差异以官方 API 文档为准。这里重点讲讲几个关键选项的含义track_dirty_pages用于快照场景开启后 VMM 会记录脏页方便做增量快照但会带来额外开销is_read_only为 true 意味着 Guest 永远改不了 rootfscache_type: Unsafe表示直通宿主机 page cache性能最好非常适合只读根盘。这条路径从 socket 到 vCPU 再到 Guest 里的 init整个过程可以做到百毫秒级。前提是内核镜像和 rootfs 镜像是预先准备好的不需要在启动时做大量解压和初始化。2.3 Jailer把 VMM 进程本身也关起来前面那条路径说的是“Guest 怎么被启动”但 Firecracker 还有一个容易被忽略的关键组件Jailer。Jailer 要解决的是另一个问题VMM 进程本身被攻破怎么办毕竟 Guest 内核逃逸之后第一步攻打的通常就是宿主机上的 VMM 进程。Jailer 的流程大概是以 root 启动后先做必要的特权初始化打开/dev/kvm创建 VM 句柄然后创建一组新的命名空间把自己 chroot 进一个很小的 jail 目录放弃 root 权限切换成普通 uid/gid通过 cgroup 限定 CPU 和内存最后加载 seccomp-bpf 白名单并重新 exec firecracker 二进制。这样一来VMM 进程从出生起就处于最小权限状态。即使 Guest 逃逸成功攻击者面对的也是一个不能读宿主机文件系统、不能开新特权、系统调用被过滤的普通进程。这是 Firecracker 和很多传统 VMM 最大的差别它不是给了一个强大的进程去处理所有请求而是让这个进程从里到外都“抬不起头”。这里有一个实践上的联动因为 Jailer 把进程放进了新 netnstap 设备的创建也要在这个 netns 里完成否则 Guest 里看不到网卡。常见做法是由编排层的 root 组件提前建好 tap或者借助 Jailer 参数把 netns 准备好。很多第一次用的人在这块绕了半天我会在第五节专门讲。3. 安全边界在哪里可信根、逃逸路径与纵深防御安全边界不是一句“用了虚拟机就安全”能概括的。它需要你明确知道哪些地方是墙哪些地方是门哪些地方如果被突破会造成什么后果。3.1 攻击面清单先列攻击面再谈防御。一个 Agent Sandbox 对外暴露的核心攻击面有这些Guest 内核逃逸通过 KVM 漏洞攻击宿主机内核。VMM 进程漏洞firecracker 设备模型对畸形输入处理出错攻击者从 Guest 侧控制 VMM。设备模型输入面恶意磁盘镜像、畸形网络包、异常 vsock 数据。控制 socket本地 UNIX socket 如果权限设置不当其他本地用户可以随意控制沙箱。MMDS如果启用了 metadata 服务Guest 能查到的东西里有敏感信息就是漏洞。网络出网路径不加控制的话Guest 可能访问内网管理端口、云 metadata 地址或其它 Sandbox。控制 socket 是本地 socket 而不是网络服务这本身就比千篇一律的 HTTP 服务少了很多暴露面。真正需要重点保护的是前三条它们和设备模型、KVM 关系最近也是安全研究者最喜欢盯的部分。3.2 两层防御Guest 逃逸之后还有第二道墙整个安全模型里最底层的信任根是宿主机内核加上 CPU 的虚拟化扩展Intel VT-x 或 AMD-V。KVM 的 ioctl 是 VMM 与硬件交互的唯一天然入口保持宿主机内核及时更新是所有隔离方案的基石。在这之上有两层墙。第一层是 Guest 自己的内核Guest 跑在独立的虚拟地址空间里普通权限进程在 Guest 里提权也只是提到 Guest 内核要跳出虚拟机必须利用 KVM 或硬件虚拟化本身的漏洞。第二层是 VMM 进程即便第一层被突破攻击者还要再破 firecracker 这层而这时的 firecracker 已经被 Jailer 剥夺了绝大多数权限。对比之下容器的模型只有一层墙提权进程一旦拿到内核就同时拿到了宿主机。这个对比是选择微虚拟机而不是容器的最重要理由。当然说出这句话的同时也要清醒没有任何单点工具能解决所有问题纵深防御才是重点。Firecracker 的价值在于把“逃逸之后的余波”限制在一个非常小的权限范围里。3.3 网络边界怎么收口沙箱里的 Agent 需要上网下载依赖、调用 API但你不可能让它访问所有资源。常见的做法是每个 Sandbox 一个 tap 设备桥接进宿主机网桥再通过 NAT 出网在宿主机或网关上用iptables/nftables做默认拒绝和端口/域名白名单。对 Agent 任务来说允许 80/443 出网、禁止访问内网网段和169.254.169.254是一个比较合适的起点。169.254.169.254这个地址要特别小心它是云平台 metadata 服务的约定地址Firecracker 也提供 MMDS 挂在同一个地址上。如果你没有显式给 MMDS 填充数据就保持禁用如果需要给 Agent 下发任务元数据不要把密钥和历史数据塞进去它只是 Guest 可以查询的一本小册子不是保险箱。如果某个任务完全不需要网络我强烈建议直接不配网卡。少一条链路就是少一个暴露面。配置网络之后也一定要做基线检查从一个全新 Sandbox 里执行curl确认它看不到内网、看不到其它 Sandbox 的 IP、访问不了 metadata 地址。3.4 数据与持久化的边界块设备的路径由宿主机路径指定Jailer 通过 chroot 把路径解释范围锁在 jail 目录里。实际操作时把 rootfs 做成只读任务要写的临时数据放内存盘 tmpfs 或第二块可写盘这样 Guest 无论如何修改都影响不到宿主机文件系统。需要持久化的数据通过显式 volume 挂载任务开始前把需要的输入文件放进专用可写盘任务结束后把输出读走整个盘随之销毁。这比让 Agent“直接访问宿主机目录”安全得多也更容易审计——什么东西进来、什么东西出去都在编排层留下记录。4. 拿 Firecracker 跑 Agent编排架构与生产配置理论部分讲完下面落到落地。这个部分偏架构和配置我会按我自己搭过的形态来组织你可以按需裁剪。4.1 整体架构把 Sandbox 和 Agent Runtime 分开我会把“沙箱”本身和“Agent 运行库”分成两层。底层是 Sandbox Manager一个长期运行的编排服务管理镜像池、快照池、tap 设备、API socket 和资源配额。上层是 Agent Runtime当 Agent 需要执行代码或调用外部工具时把“可执行环境描述 输入数据 超时策略”交给 Sandbox Manager由它分配一个 Sandbox执行任务等结果返回后再销毁。这种解耦带来两个好处。其一Agent 本身并不直接拥有宿主机权限它只拥有一个一次性沙箱的描述其二即使某个 Agent 被骗去做危险操作最坏情况也只是销毁这一个 Sandbox不影响其它任务。Sandbox Manager 不需要太复杂一个后台服务加几张表就够一张记录镜像版本一张记录正在运行的 Sandbox 实例一张记录审计日志。任务并行度、单任务超时、镜像黑白名单都可以通过配置项暴露。4.2 镜像与启动策略小镜像加快照恢复镜像构建我推荐用 Dockerfile 来维护环境然后在发布阶段导成 ext4 raw 文件比如docker export之后做格式转换和大小调整。核心思路是 rootfs 尽量小一个 Python 运行时、必要的依赖和工具链比一个完整桌面系统好维护得多启动也快得多。启动路径上最大的技巧是快照。具体做法是先冷启动一个干净的 microVM进入就绪状态后调用快照 API 保存内存和磁盘状态之后每个新任务直接从快照恢复十几毫秒到几十毫秒就能拿到一个已经跑起来的环境不需要每次都从内核开始。资源配额我通常这样设默认一个 Sandbox 给 1 vCPU、256 到 512 MB 内存跑重活的任务单独加配额。用 cgroup 把 CPU 和内存钉死防止单个 Agent 吃光机器。4.3 安全与策略配置细则下面是生产环境我比较看重的一组配置项列出来供你对照检查API socket 权限只允许 Sandbox Manager 用户访问文件权限 0600路径尽量短。seccomp用 Firecracker 默认过滤器尽量减少额外的 syscall 白名单。rootfs必须只读写操作一律走数据盘避免镜像被污染。网络默认 NAT 出网加白名单完全无网络的任务不配网卡。可观测性串口日志集中收集Firecracker metrics 定期拉取任务结束后归档审计日志。快照一致性CPU 模板、内核镜像、rootfs 和设备配置在保存与恢复时必须完全一致。这些配置看起来琐碎但每一条都在压缩攻击面。尤其是 API socket 权限我见过不少部署里干脆用 root 跑 Manager把所有 socket 都暴露给本机所有用户等于把门拆了只留墙。4.4 资源回收与生命周期管理任务结束之后一定要销毁 Sandbox而不是留着复用。复用容器会积累脏状态违背沙箱的隔离初衷。销毁时要依次做删除 API socket、回收 tap、解除网桥成员关系、删除 cgroup 目录、确认 VMM 进程退出。Jailer 默认会让 VMM 进程跟随父进程退出但 Manager 最好显式等待进程退出别依赖隐式机制。提示生产环境不要为了省事复用 Sandbox。脏状态会毁掉整个隔离模型还会让问题变得极难排查。还有一个容易忽略的点超时保护。Agent 任务可能卡死或进入死循环所以要给每个任务设硬超时比如默认 10 分钟到点强制销毁。否则一个卡住的 Sandbox 会一直占着内存和网络资源一次出现几十个就是事故。5. 实测中最容易翻车的几个点启动失败、网络不通、快照不兼容原理和架构说完了最后分享几个我踩过最多坑的地方。这些坑都不深但每个都会浪费大半天时间。5.1 启动失败大多数是内核和 rootfs 不匹配最经典的现象是 API 全部返回成功但 Guest 根本没起来或者瞬间重启。第一步永远是看串口内核参数里带consolettyS0然后从 Firecracker 日志或串口文件里找 panic 信息。常见原因无非三类。第一内核镜像没编进 virtio 驱动——Firecracker 没有传统磁盘控制器必须用 virtio-blk第二rootfs 格式不对或文件系统支持没编译进去第三内核参数里 root 设备指向错误比如vda和vda1搞混。排查时建议先用最小可用内核参数启动确认能进 init 之后再逐步加配置。很多发行版内核是给普通 PC 编译的直接跑在 Firecracker 上会缺 ACPI、PCI 相关的东西最省事的是用社区维护的 Firecracker 内核配置或者从官方示例镜像开始。5.2 网络不通tap 设备、vhost-net 和 NAT 三连坑网络坑我踩得最多。第一个是 tap 设备没建在正确的 netns 里Jailer 会把进程丢进新命名空间你在外面建的 tap 根本对不上号。解决办法是在同一个 netns 里创建 tap或者让 Jailer 处理 netns。第二个是/dev/vhost-net不存在。在容器里跑 Firecracker 时尤其常见没这个设备就不能用 vhost 加速性能会掉一截但至少能跑。第三个是 NAT 没配 MASQUERADE或者 FORWARD 链默认策略是 DROP于是 Guest 能 ping 通宿主机却出不了网。顺带提一句如果任务用不上网络就干脆别配网卡。每次我都建议做一次基线检查从一个全新 Sandbox 里执行几个curl看看默认能不能访问内网、metadata 和别的 Sandbox IP。5.3 快照恢复不兼容配置一致性比你想的严格快照恢复的报错通常是“配置不匹配”但日志往往不够直观。我的排查顺序是先确认保存和恢复时的 CPU 模板是否一致再看track_dirty_pages开关是否一致然后核对设备列表、内核路径和启动参数。Firecracker 对一致性检查非常严格任何一项对不上都会拒绝恢复。另一个坑是同一份快照被多个 Sandbox 恢复Guest 里的 MAC 地址和 IP 地址完全一样网络会冲突。编排层必须为每个恢复实例重新分配网络环境要么在请求里覆盖网络配置要么在 Guest 里动态获取新的 IP。5.4 进程泄漏和文件残留巡检任务必须有Firecracker 进程崩溃或 Manager 被kill -9会留下两种垃圾/run/firecracker/下的 socket 文件以及挂在宿主机网桥上的 tap 设备。时间一长进程表里出现僵尸、socket 文件堆积、网桥成员爆炸各种诡异问题就来了。我的习惯是在 Manager 里加一个巡检任务每几分钟扫描一次凡是运行时间超过任务最大时长的 Sandbox 直接销毁凡是属于已不存在 Sandbox 的 tap 设备全部回收cgroup 目录同步清理。这套东西不复杂但没有它系统跑一周就会开始出幺蛾子。整套方案在团队里跑了几个月我的总体感受是边界不是用来阻碍效率的而是用来保证效率可持续的。Firecracker 解决了“启动快”和“隔离强”这两个看起来矛盾的需求但真正让它可用的是那些外围工程——镜像管理、网络收口、快照策略、超时清理。如果你也在搭类似的东西建议别一上来就追求复杂控制面先把不可变 rootfs 加上快照恢复这条主线打通再把安全策略一层层叠上去。顺带说一句沙箱安全是个动态过程宿主机内核、Firecracker 版本、镜像里的依赖库都会出现新漏洞规划和运维要给它留出持续升级的位置。