Firecracker microVM 实战：构建高安全边界的 Agent 沙箱

给 Agent 跑沙箱，在很长一段时间里是个挺拧巴的事：既要让它有足够的计算资源跑得快，又怕它失控把宿主机拖下水。最近把一套 Agent Sandbox 从容器迁移到 Firecracker microVM 上跑通之后，我对“运行路径”和“安全边界”这两个词的理解才算落地——不同隔离方案，代码走到内核的路径不同，出问题后被波及的范围也不同。这篇文章不打算写成 Firecracker 的官方文档复述，而是把一个真实可用的 Agent 沙箱从选型、启动链路、通信设计，到安全加固和排错手册完整拆开讲一遍，给正在评估“用 microVM 跑不可信 Agent”这条路的同学一份能直接参考的实践记录。

1. 为什么 Agent 沙箱要选 Firecracker：容器看似够但不够的隔离矛盾

1.1 容器隔离的边界在哪里

先说一个可能被很多人忽视的事实：容器不是虚拟化，容器是一个“加了约束的进程”。同一台宿主机上的所有容器共享同一个内核，共享同一套系统调用接口，共享 /proc、/sys 里那堆内核暴露出来的状态。Docker、runC 提供的 namespace、cgroup、seccomp 确实能在用户态层面做很多限制，但“同内核共享”这件事本身就是一个无法绕开的信任假设。

我在迁移之前，Agent 沙箱用的是 runc + seccomp + AppArmor 这套组合。常规第三方工具跑起来没问题，但一旦处理的是不可信代码，心里总是悬着的。因为沙箱内代码一旦触发内核漏洞，哪怕只是一个可被利用的竞态条件，攻击面就直接从“guest 进程”变成了“宿主机整个内核”。更麻烦的是，容器逃逸类问题很多不是靠配置能完全堵死的，内核模块加载、文件系统漏洞、io_uring 这类新特性都可能成为突破口。生产环境里我不能假设内核永远没有 bug，也不能假设每次内核升级都能及时覆盖所有节点。

所以，当隔离需求从“防止误操作”升级成“对抗恶意输入和未知代码”时，容器那套用户态隔离模型就已经到了边界。我需要的是一个真正有硬件隔离边界的执行环境，而不是又一个“共享内核的受限进程”。

1.2 Firecracker 做对了哪三件事

Firecracker 是 AWS 开源出来的 microVM 方案，支撑的是 Lambda 和 Fargate 这类服务。它本质上还是基于 KVM 的虚拟化，但和我们熟悉的 QEMU/KVM 虚拟机完全不是一回事。它做对了三件事，恰好对应 Agent 沙箱的三个核心诉求。

第一，启动路径足够短。传统虚拟机要从 BIOS/UEFI 固件初始化开始，经历自检、引导加载器、内核解压、驱动枚举，一套流程下来动辄几秒甚至十几秒。Firecracker 干脆删掉了固件层，把 Linux 内核镜像直接加载进 guest 内存，按 Linux boot protocol 设置好启动参数之后直接进入内核。配合精简后的 virtio 设备模型，从发起创建到 guest 内核开始执行通常只要一百多毫秒。对 Agent 这种“频繁创建、短生命周期”的工作负载来说，这是容器之外最接近“秒级拉起”的隔离方案。

第二，内存和进程开销控制得极低。每个 microVM 的 VMM 进程额外开销很小，guest 内存可以根据负载压到 128MiB 甚至更低。我实际测试下来，空闲 microVM 的 VMM 部分额外内存占用在 5MiB 量级，这在单机密度上意味着可以并排跑几十个甚至上百个隔离实例。早期我用过 QEMU 方案做类似的事情，一个虚拟机光固件和设备模拟就要吃一两百 MiB 内存，密度完全不在一个数量级。

第三，设备模型裁剪得很干净。Firecracker 只提供 virtio-net、virtio-block、virtio-vsock 和串口这几个必要设备，没有传统虚拟机那套完整 PCI 拓扑、USB 控制器、声卡显卡模拟。设备模型小，攻击面就小；没有的东西自然不存在可利用漏洞。这个“减法设计”对安全边界的价值，比任何事后加固都重要。

1.3 传统虚拟机方案为什么绕不开

有人可能会问，既然要硬件隔离，那直接用 QEMU/KVM 做完整虚拟机不就行了？我也试过，结论是“能用，但很痛苦”。

QEMU 的功能太丰富了，它要兼容几十种设备模拟、多架构、固件生态，庞大的代码面带来的是更大的安全暴露面。更关键的是，QEMU 的启动路径天然为“完整操作系统”设计，BIOS、GRUB、驱动探测这一整套流程对 Agent 沙箱场景完全是多余的。你只是想让一个不可信进程在一个独立的硬件隔离环境里跑完一段任务，结果先得跟着它把整个 PC 兼容机的启动流程走一遍。

Firecracker 的定位则完全不同：它从一开始就假设每个 microVM 只跑一个轻量级负载，只提供最少的虚拟设备，不追求通用计算，只为“安全隔离 + 快速启动”这一件事做到极致。它把虚拟化技术里不必要的复杂度全部丢掉，只保留隔离的本质。这也是我在对比之后最终选择它的核心原因：当一个工具的目标函数足够收敛时，它的安全边界才真正可控。

2. 从 API 调用到内核运行：microVM 的启动链路拆解

2.1 管理链路：API Socket 到 VMM 进程

Firecracker 的每个 microVM 都是一个独立的 VMM 进程。这个进程通过一个 Unix domain socket 对外暴露控制 API，创建、配置、启动、停止 microVM 的所有操作都通过这个 socket 完成。

实际路径是这样：宿主侧控制程序用 HTTP over Unix socket 向/tmp/firecracker.socket发请求，VMM 进程收到请求后创建 KVM 虚拟机文件描述符、分配 guest 内存、配置 vCPU，然后加载内核镜像和 rootfs，最后让 vCPU 进入运行状态。从这个角度看，Firecracker 的“运行路径”是从 API 层开始的，API 层和 VMM 层之间没有额外的 RPC 中继，所有管理操作都直接作用于当前进程。

这里有一个容易被忽略的注意点：API socket 的权限控制直接影响整个沙箱的安全边界。如果 socket 文件权限过宽，任何能访问到该 socket 的本地用户都能管理你的 microVM，这等于把虚拟化层的控制权交了出去。我采用的做法是每个 Agent 实例一个临时目录，socket 权限设为 0600，只允许运行控制组件的同一 UID 访问。

2.2 内核镜像进入 guest 内存的方式

Firecracker 启动时不需要 BIOS，也不需要引导扇区。它直接读取内核镜像文件，支持两种格式：未压缩的 vmlinux ELF，以及可选的 PE 格式内核。加载过程本质上是把内核镜像拷贝到 guest 物理内存的特定位置，然后按 Linux 启动协议填充 boot parameters，设置入口点，最后通过 KVM 的 vCPU 运行指令触发内核执行。

这一步对“运行路径”的影响非常直接：没有固件层意味着 guest 内核的第一条指令在创建 VMM 进程后很快就能执行，启动时间的主要构成从“固件自检 + 引导”变成了“内核解压 + 驱动初始化”。很多初次接触的人会以为内核启动时间是 Firecracker 决定的，其实 Firecracker 只负责把内核送进内存，真正耗时的是 guest 内核自身的初始化流程。所以，想优化启动时间，光换 Firecracker 版本没用，得从 guest 内核上下功夫：裁剪不需要的驱动、关闭不需要的内核特性、使用精简的 init 进程。

我在实际项目里把 vmlinux 做成了静态编译的裁剪内核，只保留 virtio、ext4、vsock 和串口驱动，其余模块全部去掉。这样既缩小了内核镜像体积，也减少了 guest 内核暴露给 Agent 的攻击面。

2.3 内核启动、virtio 枚举和用户态交接

guest 内核开始执行后，会经历常规的 Linux 启动流程：初始化内存管理、调度器、中断系统，然后枚举 virtio-mmio 设备。Firecracker 把虚拟设备挂在 MMIO 总线上，内核通过设备树或直接 platform device 描述识别到 virtio-blk 和 virtio-vsock，然后挂载 rootfs、执行 init。

我常看的一条启动日志时间线大致是这样的：

[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.092517] virtio-mmio 40000000.virtio_mmio: IRQ 32 [ 0.184023] virtio_blk virtio0: [vda] 2097152 512-byte logical blocks [ 0.301447] virtio_vsock virtio1: 2\-(u32)MAX [ 0.387935] EXT4-fs (vda): mounted filesystem with write support [ 0.402881] Run /sbin/init as init process

从这条路径里能看到几个关键节点：virtio 设备在极早期就被内核找到，rootfs 挂载后直接交接给用户态 init，中间没有多余等待。整个到 init 的时间在我们的裁剪内核上大约 300ms 出头，这还算上了内核自身枚举的时间。如果换成完整发行版内核，时长会涨到 700ms 甚至更多，差别很明显。

2.4 启动耗时的主要构成

启动耗时这件事值得单独说，因为很多 Agent 沙箱的业务指标都卡在这里。

拆开来看，Firecracker 的耗时主要有三块：

• VMM 进程启动 + KVM 初始化：大概几十毫秒，和进程 fork、API 请求往返有关。
• guest 内核解压 + 初始化：通常 200~500ms，取决于内核大小、驱动数量和 console 输出。
• 用户态 agent 初始化：从 init 执行到 agent 就绪，取决于语言运行时和业务逻辑，Rust 或 Go 静态二进制可以做到几毫秒，Python 解释器冷启动则要另算。

如果 Agent 生命周期很短，比如每个请求都创建新沙箱，启动时间占比就会很高。我见过两种优化思路：一种是预创建 microVM 池，请求来时从池里取一个已经启动好的实例，用 vsock 下发任务；另一种是结合 Firecracker 的快照恢复能力，把已经初始化完成的 microVM 内存状态保存下来，新实例从快照快速恢复。这两种方案我都试过，预创建池在事件驱动型负载里更直观，快照恢复则更适合“批量创建同构沙箱”的场景。

3. Agent 在沙箱内的执行路径与对外通信链路

3.1 控制面：vsock 通道设计

microVM 跑起来之后，宿主侧和 guest 侧需要一条通信链路。Firecracker 提供的是 virtio-vsock，这是一种专门为虚拟机设计的 socket 协议，类似 TCP，但不需要 IP 地址和网卡。guest 侧有一个 CID（Context ID），宿主侧固定能看到 guest 的 CID，guest 也能反向连接宿主。

我把通信通道分成控制面和数据面。控制面负责下发的任务、中止信号、健康检查；数据面负责具体的输入输出文件和结果回传。两个面共用同一个 vsock 连接还是分开两个端口，取决于业务。我建议分开，因为控制面流量小且需要低延迟，数据面可能有大文件传输，混在一起容易互相阻塞。

宿主侧通信程序骨架大致是这样：

use std::os::unix::io::RawFd; use vsock::{VsockAddr, VsockListener}; fn main() { let listener = VsockListener::bind(VsockAddr::new(3, 5200)).unwrap(); loop { let (stream, _) = listener.accept().unwrap(); // 读取任务描述，执行，回写结果 } }

guest 侧只需要一个静态编译的 agent 二进制，监听固定端口。注意客体内核要开启 CONFIG_VSOCKETS 和 CONFIG_VIRTIO_VSOCKETS，否则/dev/vsock根本不会出现。

3.2 数据面：任务下发、执行与结果回收

任务执行路径本身并不复杂：宿主把任务描述序列化成 JSON 或 protobuf，通过 vsock 发给 guest agent；guest agent 解析后 fork 子进程执行具体任务；执行过程中的 stdout、stderr、退出码通过原连接回传；大文件输出通过 guest 内的临时目录中转，宿主通过只读挂载或额外通道读取。

这里要非常注意文件系统边界。我给 guest 的 rootfs 设计成只读挂载，Agent 可写的目录单独放在一个内存盘或者独立的块设备上。这样即使 Agent 被攻破，它能修改的只有自己的临时目录，无法篡改二进制、内核镜像和系统配置。任务结果回收时，宿主只读取指定输出目录，不信任 guest 回传的路径字符串。

一个常见的错误是把宿主目录直接 bind mount 进 guest。这等于把宿主的文件系统路径暴露给了不可信代码，Agent 一旦越权读取，宿主业务数据就危险了。我做沙箱时严格遵循“guest 能看到的宿主资源越少越好”的原则，文件交换一律通过受控通道完成。

3.3 生命周期：从创建、闲置到销毁

Agent 沙箱的生命周期可以分成四个阶段：创建、就绪、执行、销毁。

• 创建阶段：宿主控制进程通过 API socket 创建 VMM，加载内核与 rootfs。
• 就绪阶段：guest agent 启动完成，监听 vsock 端口，等待任务。
• 执行阶段：宿主下发任务，agent 执行并回传结果。执行期间宿主侧应该持续检测 agent 心跳和资源占用，超过阈值就可以主动中止。
• 销毁阶段：任务完成后直接杀掉 VMM 进程，回收内存和文件描述符，或者把该实例回收进预创建池。

我在实际落地时有一个经验：不要让一个沙箱长期闲置。长期运行的 microVM 会增加暴露时间，也会让“任务边界”变得模糊。理想状态下，沙箱应该是无状态的，任务结束即销毁。如果确实需要池化复用，至少要保证每次任务前重置 guest 内的临时目录和环境变量，不能把上一个任务的数据留给下一个任务。

3.4 Agent 当 PID 1 的细节问题

很多人为了让启动路径更短，直接让 agent 二进制当 PID 1 跑，省掉 init 进程。这个方案可行，但有几个坑。

PID 1 在内核里有特殊语义：它负责收养孤儿进程，处理 SIGCHLD 信号，避免僵尸进程堆积。如果你的 agent 主进程是个简单的循环，fork 出来的子进程结束时父进程没有主动 wait，僵尸进程就会越积越多。客体内核 PID 空间本来就有限，僵尸进程把 PID 耗尽后，整个 sandbox 就废了。

我的做法是在 guest 内放一个极简 init，或者让 agent 主进程在每次子进程退出后主动 waitpid。如果是 Go 或 Rust 写的 agent，一般都会用进程池来管理子任务，waitpid 是顺手的事。如果是 Python 写的 agent，那更要注意 signal handler，不然子进程退出状态根本收不回来。

4. 安全边界的实际位置：信任边界、攻击面与加固清单

4.1 威胁模型与信任层级

聊安全边界，必须先说清楚“信任谁、不信任谁”。在我这套 Agent Sandbox 里，信任层级从上到下是这样的：

• 宿主机内核和 KVM 模块：这是整个隔离体系的地基，假设是可信的。
• Firecracker VMM 进程：通过 Rust 内存安全、seccomp、jailer 约束，假设它尽量可信，但仍然要尽量减少它暴露给 guest 的攻击面。
• guest 内核和 agent：完全不可信，是我们要隔离和限制的对象。

威胁模型的核心问题是：guest 里的恶意代码，有没有可能突破到 VMM 层或宿主内核层。Firecracker 的安全设计就是围绕这个核心问题展开的。

4.2 边界上的四道防线

第一道防线是 CPU 虚拟化硬件。KVM 使用 Intel VT-x / AMD SVM 的硬件辅助虚拟化，guest 运行在 non-root 模式，内存访问通过 EPT 页表翻译。guest 能看到的物理地址空间被完全隔离，直接访问宿主内存地址会被硬件拦截。这是微虚拟机隔离的物理根基，软件层再强也替代不了。

第二道防线是设备模型。Firecracker 的设备模型非常小，virtio-blk、virtio-net、virtio-vsock、串口，每个设备对应的模拟代码都经过专门审计。攻击面小意味着漏洞概率低。我在配置时更是把用不到的设备全部去掉，比如不需要网络功能的沙箱就不加网络接口，不需要块设备热插拔就不开相关功能。

第三道防线是进程级约束。jailer 是 Firecracker 自带的加固工具，它把 VMM 进程放进 chroot、cgroup、seccomp 环境里。seccomp 过滤掉 VMM 进程不需要的系统调用，chroot 限制文件系统可见性，cgroup 限制 CPU 和内存配额。即使是 VMM 进程自身被攻破，它也处于受限环境中，无法直接操作宿主全盘。

第四道防线是 API 层访问控制。API socket 的权限、saas 控制组件的鉴权、日志审计，都是在管理面上防止“内部人员误操作或系统化攻击”的手段。

4.3 不可忽视的限制：硬件侧信道与内核可用性

诚实地说，Firecracker 的隔离能力不是绝对完美的。硬件层面的侧信道问题，比如缓存侧信道、预取侧信道，在没有硬件安全特性的前提下，guest 可以通过时序测量侧面观察宿主上其他负载的行为。这类攻击并不是 Firecracker 能解决的，它属于“同一物理主机上的微架构隔离”问题，实际威胁程度取决于你的场景和主机硬件支持。

另一个限制是 guest 内核自身的漏洞。Firecracker 隔离的是“guest 内的代码”，但 guest 内核仍然是 Linux，一个 guest 内核提权漏洞虽然不会直接导致宿主机失陷，但可能让攻击者获得 guest 内的完整控制权，进而尝试攻击 virtio 设备。所以 guest 内核同样要定期更新，不能因为“反正有虚拟化兜底”就放松 guest 内核的补丁管理。

4.4 边界验证的 canary 设计

安全边界到底有没有效，不能靠感觉，要靠验证。我设计了一套 canary 检查，在每个沙箱环境里跑一次，确认隔离性是真实存在的。

检查项包括：

• guest 内尝试读取宿主文件路径（比如/etc/hostname、宿主家目录），应该全部失败或看到的是 guest 自己的文件系统。
• guest 内执行dmesg或访问/dev/mem，应该被拒绝或看到受限信息。
• 向只读 rootfs 写入文件，应该报只读错误。
• 尝试绑定宿主的特权端口或访问宿主网络，应该被网络隔离规则挡住。
• 通过 vsock 通道以外的方式连接宿主服务，比如 TCP 直连宿主 IP，应该失败。

这套检查我只把它当成回归测试，不当作绝对安全证明。真正的安全需要持续验证、持续加固，不是跑通一次就能一劳永逸。

5. 生产落地配置与排错手册：可以直接抄的 Firecracker 沙箱

5.1 前置验证和 rootfs 制作

开始之前，先确认几个前置条件：

• 宿主内核开启 KVM：ls /dev/kvm存在且有读写权限。
• 拥有 Firecracker 二进制和 jailer 二进制，建议从官方 release 页下载，不要自己编译不熟悉的版本。
• 准备 vmlinux 内核镜像和一个 ext4 rootfs。

rootfs 制作我推荐用容器工具链，流程是：先拉一个精简的 Linux 发行版作为 base，把静态编译的 agent 二进制拷贝进去，再清理掉所有不需要的包和缓存，最后用ext4格式打包。注意 agent 必须静态编译，否则 rootfs 里缺动态链接库会导致 guest 启动后 agent 直接崩溃。

我常用的一条命令大致是这样：

# 假设 rootfs 目录在 ./rootfs，skeleton 系统已经准备好 sudo mkfs.ext4 -d ./rootfs -b 4096 rootfs.ext4 2G

如果 rootfs 制作过程中没有-d选项（取决于 e2fsprogs 版本），可以改用debugfs写文件，或者直接用容器导出再转换。核心目标只有一个：得到一个干净的、只包含 agent 及其运行依赖的只读 rootfs。

5.2 最小化配置与启动命令

Firecracker 的配置是一个 JSON 文件。一个最小化 Agent 沙箱配置如下：

{ "boot-source": { "kernel_image_path": "/opt/firecracker/vmlinux", "boot_args": "console=ttyS0 reboot=k panic=1 pci=off" }, "drives": [ { "drive_id": "rootfs", "path_on_host": "/opt/firecracker/rootfs.ext4", "is_root_device": true, "is_read_only": false } ], "machine-config": { "vcpu_count": 2, "mem_size_mib": 512, "smt": false }, "vsock": { "vsock_id": "vsock0", "guest_cid": 3 } }

这里没有配置网络接口，因为 Agent 沙箱默认不需要外部网络。如果业务需要访问外部 API，再加网络接口，并通过上层网络策略严格限制出口流量。

启动命令直接用 jailer 包裹：

./jailer \ --id agent-1 \ --exec-file ./firecracker \ --uid 1000 \ --gid 1000 \ --seccomp-level=2 \ --chroot-base-dir /opt/fc-jail \ -- \ --api-sock /run/firecracker.socket \ --config-file /firecracker/config.json

注意 jailer 会先做 chroot、设置 cgroup、应用 seccomp，然后才执行 firecracker。配置文件路径必须相对 chroot 后的环境来写，否则会找不到文件。这是新手最容易踩的坑之一。

5.3 宿主侧通信程序骨架

宿主侧控制程序通过 vsock 连接 guest agent。一个简单的实现思路如下：

use vsock::{VsockAddr, VsockStream}; fn dispatch(vm_cid: u32, task: &[u8]) -> Result<Vec<u8>, Error> { let mut stream = VsockStream::connect(VsockAddr::new(vm_cid, 5200))?; stream.write(task)?; stream.flush()?; let mut buf = vec![]; stream.read_to_end(&mut buf)?; Ok(buf) }

这个骨架只处理单个连接，生产环境要加连接池、超时控制、结果校验和任务重试。vsock 是全双工流式传输，如果你需要更复杂的消息边界，建议在应用层做长度前缀帧。

5.4 资源规划参考

资源规划是 Agent 沙箱落地时最容易被低估的部分。我给一份基于实测的参考：

同一台宿主能跑多少个 microVM，取决于内存容量、CPU 核数、IO 吞吐和内核线程数。我们团队的经验是，在 64GiB 内存、16 核的宿主上，跑 128MiB 的小沙箱可以稳定维持 200 个左右，但 CPU 和 IO 会成为瓶颈，不能只看内存。

5.5 常见异常与处理

实际部署中总会遇到各种异常，我列几个出现频率最高的。

排错时先看串口输出。console=ttyS0配合boot_args和日志采集，基本能把启动阶段的问题定位清楚。guest 起来之后再出问题，就得靠 agent 自身的日志通道排查了。

6. 生产环境实测体会：边界维护比搭建隔离更难

6.1 监控与可观测性

沙箱跑起来只是开始，真正的挑战在于长期运行时的可观测性和边界维护。

我一般会监控几个层面的指标。第一层是宿主侧进程级指标：VMM 进程的 CPU、内存、线程数、打开的文件描述符数量。第二层是 guest 侧指标：通过 vsock 周期性上报 guest 的内存使用、agent 进程数、僵尸进程数。第三层是业务指标：任务成功率、执行时长、超时率、沙箱创建/销毁频率。

guest 侧监控最容易出问题。agent 如果不可信，上报的数据就不能直接信任；但如果 agent 本身不采集，宿主侧就两眼一抹黑。我的折中方案是：guest 侧只上报轻量级运行时指标，更细粒度的行为审计放在宿主侧做。宿主侧通过 Firecracker API 拿 VMM 进程的资源占用，再结合 cgroup 统计，形成相对可信的监控数据。

6.2 升级节奏和配置漂移

Firecracker 的 API 在 v1.x 系列里保持得比较稳定，但版本升级仍然需要谨慎。我踩过最典型的坑是：升级 Firecracker 版本后，旧配置里的字段名或默认值发生了变化，导致沙箱启动失败。这类问题在部署时不会立刻暴露，往往要等下一次扩容或重建实例时才出现。

我的做法是：把版本号、校验和、配置模板一起纳入配置管理，每次升级先在 staging 环境跑完整启动链路和 canary 检查，通过后再灰度推进。同时用自动化脚本检查当前运行版本和配置模板的匹配关系，避免长期运行后出现配置漂移。

6.3 操作层面的个人经验

最后分享几条操作层面的体会。

第一，guest 内核越小越好。不只是启动快的问题，更小的内核意味着更少的驱动代码、更少的文件系统支持、更少的网络协议栈暴露。Agent 沙箱不需要声卡、USB、蓝牙，这些全部裁掉，攻击面自然小。

第二，只读 rootfs 不是可选，是必须。可写 rootfs 会让 Agent 有机会篡改自身环境，即使 Agent 本身是良性的，一旦被输入数据诱导，恶意行为就有了持久化空间。只读 rootfs + 独立临时目录是我认为最合理的结构。

第三，vsock 通信也要做超时和鉴权。vsock 端口如果没有鉴权，guest 内代码理论上可以尝试连接宿主侧控制服务。我会在应用层做简单的 token 校验，避免任何 microVM 都能无障碍访问宿主控制面。

第四，不要试图用一个 sandbox 配置解决所有任务。不同 Agent 对资源、网络安全、文件访问的需求差异很大，统一配置要么过度授权，要么功能受限。我宁可维护几套不同的模板，也不愿意把权限放宽到“最坏情况所需”。

这套体系上线到现在，最大的收益其实是“安心”。容器时代，每次跑不可信代码都像在走钢丝，出了事只能事后补救。切到 Firecracker microVM 之后，就算 guest 完全被打穿，广播半径也只有那一个微虚拟机，和我宿主的联系已经被硬件层、设备模型、seccomp 和只读文件系统挡了好几层。隔离这件事没有银弹，Firecracker 也不是万能的，但它让我把“安全边界”从一个形容词变成了一组可以测量、可以验证、可以维护的具体设计。如果你也在纠结 Agent 沙箱的选型，建议先理清楚自己的信任边界到底需要多厚，再按这套路径动手试一次。