企业官网建设流程全解析

1. 先搞清楚：Agent 为什么需要一间“密室”

1.1 Agent 的真实威胁模型不是“代码有 bug”，而是“输入不可信”

任何一个把 LLM Agent 推到生产环境的团队，迟早会撞上同一堵墙：Agent 替用户执行的那一串代码，到底该跑在什么级别的隔离环境里？

我最早接这个需求时，团队里有个经典争论——有人觉得 Docker 就够了，有人坚持要上虚拟机。最后让我下决心的，不是“代码写得有多烂”，而是“Agent 的输入根本不可控”。一个联网的 Agent 会去读网页、收邮件、解压用户上传的包。网页里一行不起眼的<script>，PDF 里一段隐藏的注释，都可能被模型当成“指令”或“上下文”处理，最后变成一条curl | bash。换句话说，Agent 代码执行的沙箱，面对的对手不是“随机 bug”，而是活跃的、有目的的攻击者。

威胁模型里有三件核心资产：宿主机上的其他租户、Agent 自己的 API Key 和对话数据、以及宿主机的网络环境。攻击者只要拿到沙箱里的一个 shell，第一件事就是扫描内网、读环境变量、把/etc里的密钥往外传。所以沙箱的底线不是“代码别崩”，而是“哪怕里面的代码彻底失控，也只能炸掉自己那一小间屋子”。

这个判断直接把方案推向了虚拟化方向。不是容器不好，而是“共享内核”这件事本身，在不可信代码面前就是一个绕不开的减分项。后面我会详细对比，但先记住结论：我做 Agent Sandbox 的选型，第一性原则是让每个 Agent 会话拥有一个独立的、可随时销毁的微型虚拟机。Firecracker 正是为这个场景设计的。

1.2 为什么 Docker 在这里不够用

先把话说公道：如果 Agent 只执行“自己生成的、无副作用的纯计算代码”，比如算个数学题、处理个 JSON，Docker 加--network none完全够用。我的团队现在也还有一批轻量任务跑在容器里。但一旦场景升级到“Agent 需要装系统依赖、访问外部网络、执行用户上传的二进制文件”，容器隔离的短板就非常明显。

短板一是共享内核。容器本质上是同一台宿主 Linux 上的 namespace + cgroup，逃逸漏洞意味着直接拿到宿主内核权限。我不是说 Docker 不安全，而是它的安全模型建立在“内核漏洞库足够干净”这个假设上，而 Agent 执行的是主动对抗代码，这个假设的置信度不够高。

短板二是守护进程的暴露面。dockerd以 root 跑在宿主机上，历史上有过多个提权入口。你给用户提供的是“代码执行能力”，结果把 Docker API 或 daemon 的 attack surface 也一起暴露给了攻击链，这买卖不划算。

短板三是资源隔离不够硬。容器里的 CPU 限额、内存限额都是软隔离，遇上恶意代码故意做fork炸弹，宿主一个 OOM 全玩完。而 Firecracker 这类微型虚拟机的 CPU 和内存有硬件级别的隔离边界，Guest 再怎么疯，能碰到的物理内存只有 KVM 分配给它的那一段。

我当时做过一个对比实验：同样的“死循环 + 无限分配内存”负载，容器模式下宿主机负载会明显波动，而 Firecracker 模式下宿主机几乎无感。这个差异在跑多个并发 Agent 会话时会被放大到不可忽视。

2. Firecracker 运行路径：它凭什么能做到“小而稳”

2.1 从启动到就绪：一条被刻意缩短的虚拟化链路

Firecracker 是 AWS 开源的 VMM，用 Rust 写的，直接调用 KVM 接口，不依赖 QEMU 那套庞大的设备模拟层。它的设计目标很明确：为 Serverless 和函数计算提供毫秒级启动、极低内存开销的微型虚拟机。

启动链路是这样的：firecracker进程起来后，打开/dev/kvm，通过 KVM API 创建 VM 和 vCPU，把内核镜像直接加载进 guest 物理内存，然后启动 vCPU 线程让 guest 内核跑起来。整个过程没有 BIOS、没有 UEFI、没有 PCI 枚举，连设备用的都是简洁的 MMIO 方式。官方口径是 125ms 以内出内核，我的实测数据是：裸启动到内核日志出现大约 200ms，带上完整 init 脚本和 agent 进程就绪，一般在 400-600ms 之间。这个速度对我来说足够好，因为真正要压的是“热池复用”之后的调度时延，而那个可以做到百毫秒级。

启动方式有两种：API socket 方式和配置文件方式。API 方式适合调试，因为你可以在启动前逐个调用接口设置内核、磁盘、机器配置，最后调InstanceStart。配置文件方式适合生产，一条命令带着 JSON 配置直接拉起。我在生产里只用配置文件方式，原因后面讲 Jailer 的时候会提到。

配置里最核心的几项：boot-source指定内核镜像路径和启动参数，drives指定根文件系统镜像，machine-config指定 vCPU 数和内存大小，vsock配主客通信通道。一个最小配置长这样：

{ "boot-source": { "kernel_image_path": "vmlinux", "boot_args": "console=ttyS0 reboot=k panic=1 pci=off 8250.nr_uarts=0" }, "drives": [ { "drive_id": "rootfs", "path_on_host": "rootfs.ext4", "is_root_device": true, "is_read_only": true } ], "machine-config": { "vcpu_count": 2, "mem_size_mib": 1024, "smt": false }, "vsock": { "guest_cid": 3, "uds_path": "/tmp/firecracker-vsock.sock" } }

注意pci=off这个参数。Firecracker 的设备走 MMIO，不需要 PCI 枚举，关掉能省启动时间和减少 guest 内核的探测逻辑。8250.nr_uarts=0在某些内核版本上能避免串口探测异常。

2.2 设备模型：少即安全

Firecracker 的“少”是刻在骨子里的。它支持的设备类型只有 virtio-net、virtio-block、virtio-vsock，外加一个串口控制台。没有 USB、没有 VGA、没有声卡、没有 PCI 直通。这意味着 guest 内代码和硬件交互的攻击面，小到可以用一页纸列完。

我看过一个很形象的类比：QEMU 像一间堆满杂物的库房，能藏东西的角落很多；Firecracker 像一间只有一张桌子和一扇门的空房间，每个角落都能一眼看穿。

少设备还有个实际好处：guest 内核不需要加载大量驱动，启动更快，内存占用更低。官方给的数据是单个 microVM 的 VMM 内存开销小于 5 MiB。注意这是“VMM 自己”的开销，guest 内核和进程的内存另算。我实际跑一个 Ubuntu 精简根文件系统 + Python 执行器，单 VM 总内存大约 120MB 左右，这已经比跑一个完整 Docker 容器加守护进程的边际成本低了。

2.3 vsock：主客通信的“安全隧道”

沙箱内外要通信，最忌讳的就是给虚拟机开一个完整的网络栈。Agent 执行代码完全可以通过一个比 TCP 更干净的信道完成：virtio-vsock。

vsock 的寻址模型是{cid, port}。guest 侧在虚拟机内用AF_VSOCK监听一个端口，宿主机侧通过 Firecracker 暴露的 Unix socket 路径来连接。默认约定 cid=2 代表宿主机，guest 的 cid 是启动时自己指定的，比如 3。

我用 vsock 做主控制通道的原因很直接：AF_VSOCK是内核原生的虚拟化通信机制，不经过网卡、不经过 IP 栈，guest 里就算有人拿到了 shell，也看不到任何 IP 地址和网卡信息，数据只在 VMM 和 guest 之间走内存拷贝。等于把“通信”这件事也变成了受控边界的一部分。

关于宿主侧连 guest 的实现，我用的是 rust-vmm 的vm-vsockcrate，写了一个几十行的小工具做端口转发，后面实操章节会给出关键代码。生产环境里我建议所有控制面流量都走 vsock，互联网流量如果有需要，再单独开网络设备，并且严格做出口管控。

3. Agent 沙箱运行路径：一次任务的完整旅程

3.1 整体拓扑：组件与信任边界

整个系统分四层，每一层之间的信任关系必须画清楚：

• 调度层：接收用户请求和 Agent 的“我要执行代码”指令，负责分配沙箱、发任务、收结果、销毁沙箱。这一层信任沙箱返回的数据格式，但不信任沙箱的“动机”——所有响应都要做超时和内容校验。
• 管理面：负责创建、销毁 Firecracker 进程，操作 jailer、cgroup、vsock 代理。这一层是宿主机上的特权进程，但只暴露内部 API 给调度层，权限尽量收敛。
• VMM 层：Firecracker 进程本身。被 jailer 限制在独立 chroot 和 cgroup 里，以非 root 用户运行，并且有 seccomp 过滤。它唯一能访问的外部资源就是指定的内核镜像、根文件系统镜像、vsock socket 和 tap 设备。
• Guest 层：微型虚拟机内部。跑一个精简 init 和常驻执行器，执行器负责接收任务、派生子进程跑代码、回收输出。所有 Agent 代码都跑在这一层，且执行器本身用非 root 用户启动子进程。

这个拓扑的核心思想是：每一层都假设“下一层可能已经被攻破”，但通过边界控制让攻破任何单独一层都无法直接威胁宿主机和管理面。

3.2 一次代码执行任务的完整时序

我把它拆成九个步骤，每一步都强调“谁在等谁”：

1. 请求进入：调度层收到 Agent 的execute(code, language, timeout)调用。
2. 获取沙箱：从热池里取一台空闲 VM。热池没有货，就现场创建一台。创建流程是：通过管理面启动jailer，jailer 拉起 Firecracker，guest 内核启动后执行 init 脚本，脚本最后跑起执行器。
3. 连接握手：guest 里的执行器进程启动后，主动通过 vsock 向宿主机侧的管理代理发起连接。这里我选择让 guest “往外拨号”而不是宿主机 “往里敲门”，好处是宿主机永远不需要知道 VM 是否已就绪——连接建立本身就是就绪信号。
4. 下发任务：宿主机管理代理把任务序列化成 JSON，按 4 字节长度前缀 + payload 的格式写进 vsock 连接。执行器读到后，把代码写入内存中的临时目录，用指定的解释器或方式拉起子进程。
5. 执行与观察：执行器等待子进程结束，同时把 stdout/stderr 增量推回宿主机。宿主机侧如果发现超过任务 timeout 还没有结束信号，先让执行器对子进程发 SIGKILL，再等一小段宽限期。
6. 结果回收：子进程结束，执行器收集退出码和输出，加上墙钟耗时一起封装成响应，原路返回。
7. 会话清理：宿主机确认收到完整响应后，把这个 VM 标记为“待重置”。如果任务执行期间出现过可疑行为（比如执行器无响应、输出里出现异常特征），直接走销毁流程，不回收复用。
8. 资源归还：销毁 VM 时，关 tap、删 vsock 临时文件、清 cgroup 条目，确保宿主机上没有残留网络设备和僵尸进程。
9. 响应上抛：调度层把结果返回给 Agent。Agent 拿到 stdout 后，继续自己的推理循环。

整个链路里，宿主机只信任两样东西：执行器进程是否还活着、以及协议帧格式是否正确。至于代码干了什么，宿主机不做判断，也不需要在做判断——它只要保证代码的破坏力出不了 VM。

3.3 协议与交互：用最笨的格式做最稳的事

我在协议设计上特意选了“笨”路径：JSON + 长度前缀。没有 Protobuf，没有 gRPC，原因很简单——执行器是沙箱里唯一可信的进程，它不需要花里胡哨的序列化框架，也不该为了引入某个 SDK 去扩大 guest 的依赖面。

请求帧长这样：

{ "id": "req_01HVX...", "action": "exec", "payload": { "lang": "python", "code": "print('hello from agent')", "args": [], "timeout_ms": 15000, "env": {} } }

响应帧：

{ "id": "req_01HVX...", "stdout": "aGVsbG8gZnJvbSBhZ2VudAo=", "stderr": "", "exit_code": 0, "duration_ms": 23, "oom": false }

输出我用 base64，防止二进制数据和转义问题。执行器在 guest 内把任务交给子进程时，会做三件关键事：

• 用preexec_fn切换成低权限用户；
• 用rlimit限制子进程的地址空间、CPU 时间和文件大小；
• 给子进程单独建一个进程组，方便超时后对整个组做 SIGKILL。

这三件事看起来基础，但少一件，线上都会出事故。比如不限地址空间，Python 里一个int(1e100)的二分递归就能吃光 VM 内存；不做进程组隔离，超时杀掉主进程后，它 fork 出来的孙子进程还留在 VM 里继续浪费 CPU。

4. 安全边界：把每一层都当成“可能被攻破”来设计

4.1 第一道墙：KVM 硬件隔离

最底层也是最重要的一道边界，是虚拟化本身。Firecracker 每个 microVM 都是独立的 KVM guest，CPU 指令靠 VMX/SVM 做硬件隔离，内存靠 EPT/NPT 做二级地址转换。Guest 内的代码无论拿到多高的权限，物理上只能访问 KVM 分配给它的那一段内存。

我见过有人问：“Firecracker 和 Docker 不都是隔离吗，为什么前者更安全？” 关键差别在于：Docker 的隔离是“软件约定的”，内核里一个漏洞可能让容器拿到宿主 root；虚拟机的隔离是“CPU 硬件保证的”，guest 要逃逸，得先过掉 VMX 这一层，还要找到一个 VMM 的漏洞，然后再找一个内核漏洞。攻击链的长度完全不在一个量级。

当然，这不是说虚拟机不会逃逸。所以我在设计里假设“理论逃逸存在”，然后继续往上堆墙。每多一层，攻击者从“拿到 guest root”到“拿到宿主机 root”之间的可用路径，就又被截断一段。

4.2 第二道墙：Jailer 和 seccomp

Firecracker 有个配套工具叫 jailer，专门负责把 VMM 进程自己“关进笼子”。它做的事包括：给每个 VM 建独立的 chroot 目录、把进程放进独立 cgroup、把 UID/GID 降到非 root、再配合 Firecracker 自身的 seccomp 过滤。

我把它理解成“给 VMM 这件防弹衣外面再套一层防爆服”。就算攻击者通过某个虚拟化漏洞攻破了 Firecracker 进程，他也面对一个 chroot 目录、一个低权限用户、一堆被 seccomp 白名单拦住的系统调用。想从这个状态摸到宿主机 root，路还长得很。

启动命令长这样：

jailer \ --id "agent-$(uuidgen)" \ --exec-file /opt/firecracker/firecracker \ --uid 1000 --gid 1000 \ --node 0 \ --cgroup-version 2 \ -- --config-file /srv/jailer/agent-xxx/root.json

这里有个我第一次踩坑的细节：--后面的参数是传给 Firecracker 的，而--config-file里的所有路径都是chroot 之后的相对路径。jailer 默认把可执行文件链接到/srv/jailer/<name>/<id>/root/firecracker，但内核镜像和根文件系统镜像不会自动帮你放进去。你得自己把这些文件放进 jail 的 root 目录，然后在配置里写相对路径，比如kernel_image_path: "vmlinux"。这个坑不填，第一次跑 Jailer 模式必然会报 “file not found”。

关于 seccomp，Firecracker 默认启用 seccomp-level 2。除非你明确知道自己在干什么，否则不要关掉它。我自己调试内核模块时才偶尔用 level 1，线上一直保持默认。

4.3 第三道墙：不可变根文件系统与资源配额

guest 里也不是裸奔。我把根文件系统挂成只读，is_read_only设为 true。这样 guest 内任何进程（包括被攻破的代码）都没法持久化地改系统文件。需要写入的临时数据全部放/tmp和 workspace 的 tmpfs 里，重启即清零。

实际跑 Agent 任务时，“要装 pip 包”是个高频需求。只读根文件系统显然不兼容。我的做法是：

1. 把常用依赖预先装进镜像；
2. 非常规依赖装在 tmpfs 的虚拟环境中；
3. 装完这一次执行就丢弃，不保留到下次任务。

这样既保证隔离，又不会让“装包”变成攻击者写文件的入口。另外，guest 里我做了几个加固动作：/proc 用hidepid=2挂载，让非 root 用户看不到其他进程的 cmdline；执行器进程本身用nobody用户而不是 root；子进程再单独降权一次。这些在容器方案里要折腾半天的事，在微型虚拟机里因为起步干净，做起来反而顺手。

资源配额方面，除了 Firecracker 配置里的 vCPU 和内存上限，我还套了一层 cgroup v2。通过 jailer 建的 cgroup 里直接写入限制：

echo "800000 1000000" > /sys/fs/cgroup/agent-cg/cpu.max echo "1073741824" > /sys/fs/cgroup/agent-cg/memory.max

意思是最多 0.8 个核的 CPU 配额，1GB 内存上限。这样就算 VM 内部 OOM，cgroup 会先兜底，不会把宿主机的内存打穿。

4.4 第四道墙：网络出口管控与时间预算

我的默认策略是“沙箱没有网”。Agent 绝大多数代码执行任务，比如数据处理、生成图片、跑个算法，根本不需要互联网。真正需要联网的场景，比如 Agent 要自己调外部 API，我会让请求走宿主上的一个正向代理，代理层做域名白名单、TLS 终止和日志审计。这样出口流量有了唯一网关，规则清晰，也能留下审计记录。

如果某个任务确实需要原始网络能力，我才会创建 tap 设备并给 VM 配一个隔离网段。但即便这个时候，默认防火墙规则仍然是“出站全丢”，只在代理明确放行时才转发。

时间预算同样重要。我给每个任务一个 timeout，给整个会话一个累计预算。不要小看这个——Agent 执行代码常常是链式调用，一次会话可能触发几十次执行，如果每次都按单次 30 秒算，一个会话能烧掉宿主机大量 CPU。我线上用的是“单次 15 秒 + 会话总时长 180 秒”的组合，超了直接杀掉 VM 重新分配，不犹豫。

5. 实操：从零搭一个最小可用的 Agent 沙箱

5.1 宿主机准备：先确认虚拟化能力

动手前先确认三件事：CPU 支持虚拟化、/dev/kvm可用、内核开了所需的模块。

grep -E -c '(vmx|svm)' /proc/cpuinfo ls -l /dev/kvm grep -E -c 'kvm' /proc/misc

如果/dev/kvm不存在，检查 BIOS 里有没有开 VT-x/AMD-V。如果是在容器里跑 Firecracker（比如 CI 场景），一定要把宿主机的/dev/kvm设备透传进去，并给容器加--device /dev/kvm、--group-add适当的组。没有 KVM，Firecracker 直接 panic，这是最常见的入门事故之一。

然后下载 Firecracker 二进制和一个配套的干净内核。Firecracker 的 release 页面会提供编译好的firecracker可执行文件；内核可以用官方 quickstart 用的vmlinux，也可以自己编。我建议先用官方配套内核跑通链路，再考虑自己编译。

5.2 制作最小根文件系统

我要能跑 Python，还要尽量小。用debootstrap做一个 Ubuntu 精简根文件系统是最省心的路径：

sudo debootstrap --variant=minbase --arch=amd64 jammy ./rootfs \ http://archive.ubuntu.com/ubuntu/ sudo chroot rootfs /bin/bash -c "\ apt-get update && \ apt-get install -y python3 iproute2 procps && \ apt-get clean "

然后把根文件系统打成 ext4 镜像。这一步有个关键操作：必须先dd出固定大小的文件，再mkfs.ext4，再挂载拷贝。不能直接把目录路径写进 Firecracker 配置。

dd if=/dev/zero of=rootfs.ext4 bs=1M count=2048 mkfs.ext4 rootfs.ext4 mkdir -p /mnt/rootfs sudo mount rootfs.ext4 /mnt/rootfs sudo cp -a rootfs/. /mnt/rootfs/ # 写入 init 脚本和 executor sudo cp guest-init.sh /mnt/rootfs/etc/init.sh sudo cp executor.py /mnt/rootfs/app/executor.py sudo umount /mnt/rootfs

guest-init.sh是虚拟机启动后 PID 1 直接执行的脚本，它要做的事情很少：挂载 proc/sysfs/tmpfs，配好 lo 接口，然后 exec 执行器：

#!/bin/sh mount -t proc proc /proc mount -t sysfs sysfs /sys mount -t tmpfs tmpfs /tmp mount -o remount,hidepid=2 /proc ip link set lo up # 可选：如果开了 tap 网络 # ip addr add 10.0.0.2/30 dev eth0 # ip link set eth0 up # ip route add default via 10.0.0.1 exec /usr/bin/python3 /app/executor.py

5.3 用 Jailer 拉起带配置的 Firecracker

把文件放进 jail 目录，然后启动：

JAIL_ROOT=/srv/jailer/agent-demo/root mkdir -p $JAIL_ROOT cp /opt/firecracker/vmlinux $JAIL_ROOT/ cp /opt/firecracker/rootfs.ext4 $JAIL_ROOT/ cp /opt/firecracker/demo-config.json $JAIL_ROOT/config.json jailer \ --id agent-demo \ --exec-file /opt/firecracker/firecracker \ --uid 1000 --gid 1000 \ --node 0 \ --cgroup-version 2 \ -- --config-file config.json

这里的config.json注意用相对路径。我给一个可直接用的版本：

{ "boot-source": { "kernel_image_path": "vmlinux", "boot_args": "console=ttyS0 reboot=k panic=1 pci=off" }, "drives": [ { "drive_id": "rootfs", "path_on_host": "rootfs.ext4", "is_root_device": true, "is_read_only": true } ], "machine-config": { "vcpu_count": 2, "mem_size_mib": 1024, "smt": false, "track_dirty_pages": true }, "vsock": { "guest_cid": 3, "uds_path": "/tmp/firecracker-agent-demo.sock" } }

第一次跑 Jailer 模式时，若报找不到文件，九成是路径问题——配置里的路径全部是 jail root 内的相对路径。另外建议track_dirty_pages: true，线上一旦要排查内存问题或者将来做快照，这个开关能省很多事。

5.4 沙箱内执行器与宿主机通道的具体实现

guest 里执行器的核心逻辑是监听 vsock 端口，然后循环处理请求：

# executor.py —— 运行在 guest 内 import socket import json import os import signal import subprocess import resource PORT = 5200 srv = socket.socket(socket.AF_VSOCK, socket.SOCK_STREAM) srv.bind((socket.VMADDR_CID_ANY, PORT)) srv.listen(16) def run_one(req): payload = req["payload"] timeout_ms = payload.get("timeout_ms", 15000) pre_exec = os.preexec_fn rlimits = [ (resource.RLIMIT_AS, (512 * 1024 * 1024, 512 * 1024 * 1024)), (resource.RLIMIT_CPU, (10, 10)), ] proc = subprocess.Popen( [payload["lang"]], stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE, preexec_fn=lambda: (os.setuid(65534), os.setsid()), # 注意：这里应该用临时文件或内存文件传递 code， # 简化演示直接放 env 或 stdin 都可，生产用 workspace 文件 env={"PYTHONUNBUFFERED": "1"}, ) try: out, err = proc.communicate( input=payload["code"].encode(), timeout=timeout_ms / 1000.0, ) return {"stdout": out.decode(errors="replace"), "stderr": err.decode(errors="replace"), "exit_code": proc.returncode, "duration_ms": ...} except subprocess.TimeoutExpired: os.killpg(os.getpgid(proc.pid), signal.SIGKILL) out, err = proc.communicate() return {"timeout": True, "stdout": out.decode(errors="replace"), "stderr": err.decode(errors="replace"), "exit_code": -9, "duration_ms": ...} while True: conn, _ = srv.accept() # 读 4 字节长度前缀 + JSON # 处理请求并写回响应

宿主机侧连接 vsock 的辅助工具，我用 Rust 的vm-vsockcrate 写，核心就几行：

// host/vsock_conn.rs —— 运行在宿主机，连接 guest cid=3 的 5200 端口 use vm_vsock::{VsockAddr, VsockStream}; fn main() -> std::io::Result<()> { let mut stream = VsockStream::new()?; stream.set_vm_addr(VsockAddr { cid: 3, port: 5200 })?; stream.connect("/tmp/firecracker-agent-demo.sock")?; // 写请求、读响应 Ok(()) }

注意vm-vsock不同版本的 API 有差异，以你 lock 住的 crate 版本文档为准。生产环境里我的做法是把这段逻辑封装成一个常驻的agent-proxy服务，负责统一管所有 VM 的 vsock 连接，调度层通过 unix socket 或 HTTP 调它。

6. 常见问题与排查实录

6.1 启动即崩：先查内核和 KVM，别急着调配置

我遇到过的新手问题里，占比最高的就是“Firecracker 起来了但立刻 panic”。排查顺序就三步：看/dev/kvm在不在、看 CPU 虚拟化开关有没有开、看内核镜像和配置里的启动参数是否匹配。把boot_args里的console=ttyS0加上，串口日志就能通过--log-path输出到宿主机文件，否则你只能看到一个没有输出的黑盒。

另一个我踩过的坑是内核镜像选型。Firecracker 官方测试内核用vmlinux原始镜像，而不是bzImage。这两个格式不同，搞错了 KVM 加载直接失败。下载时认准文件名，别顺手把 distro 的/boot/vmlinuz-*丢进去。

6.2 vsock 建连失败：从模块查到端口

guest 里socket(AF_VSOCK)报不支持，先确认 guest 内核编译了CONFIG_VIRTIO_VSOCKETS。很多精简内核默认没开这个模块，Firecracker quickstart 内核是开着的，自编内核时特别容易漏。

还有一个低级的坑：vsock 的guest_cid在同一个宿主机上必须全局唯一，多个 VM 共用同一个 cid 会导致连接串线。我给每个会话分配一个递增或随机的 cid，启动前校验一遍。

如果宿主侧连不上 UDS，先确认 Firecracker 是否真的把uds_path监听起来了。用lsof -U看一眼，再确认你的连接代码用的路径和配置完全一致。路径差一个斜杠，排查半小时。

关于快照要补充一句：Firecracker 的 snapshot/restore 对 vsock 连接有明确限制——已建立的连接不会跨快照保留。所以如果打算用 snapshot 做热池，控制面协议必须设计成“可断线重连”，guest 执行器要能在重连后恢复任务上下文。这也是我采用“guest 主动重连”模式的另一个原因。

6.3 回收不干净：tap 和僵尸进程

MicroVM 销毁看着简单，实际上最容易留垃圾。如果开了 tap 网络，VM 异常退出后宿主上的 tap 设备不会自动删除；不清理，下一次创建同名校验就会失败。我写了个cleanup.sh，在销毁流程的 exit handler 里强制调用：

ip link del dev tap-agent-xxx 2>/dev/null || true rm -f /tmp/firecracker-agent-xxx.sock rm -rf /srv/jailer/agent-xxx

另外注意，Firecracker 进程被 SIGKILL 后，guest 内核可能来不及回收，宿主机上有时会残留firecracker僵尸进程。我在管理面用了waitpid循环，并且加了--no-api之类的最小化参数，减少意外路径。线上跑了大半年，这套清理逻辑一个都没漏过。

6.4 资源耗尽 vs 超时：务必备一个“核选项”

最后一条实战经验：所有优雅回收都不可靠，但“杀 VM”永远可靠。执行器超时没响应、guest 内核 hang、vsock 连接断了——遇到这些情况，别浪费时间尝试优雅关闭，直接调用管理面接口销毁整个 VM，然后重新分配一台。热池的意义正在于“销毁成本足够低”，让核选项成为默认选项。

做法是给每个 VM 加一个会话级的 last-seen 心跳。执行器每 2 秒上报一次，调度层连续 10 次没收到心跳，就判定 VM 失联，自动走销毁流程。这套机制上线后，我们线上“失控持续时间”的中位数从分钟级降到了 3 秒以内。代价只是热池里多放了几台备用 VM，非常划算。

我在实际搭建这套 Agent Sandbox 时最深的体会是：隔离方案的选择不是性能之争，而是“你愿意把哪一层假设当成底线”。Docker 的假设是内核足够安全，Firecracker 的假设是攻击者可能已经足够强。做 Agent 代码执行这种主动面对不可信输入的活，我选择把底线放在硬件虚拟化上，然后用 Jailer、seccomp、只读根文件系统、无网络默认值这些“笨但有效”的手段一层层把它加固起来。

最后再分享一个细节：所有任务下发前，先让执行器确认自己的工作目录在 tmpfs 里，再清空一遍。这样每个任务都是从干净状态开始的，上一个任务留下的文件、缓存、环境变量污染，全都不会带到下一个任务。别小看这一行清理，我见过太多“上一次执行残留导致这一次结果诡异”的线上事故，都是这条规矩能直接消灭的。