用 Firecracker 搭建并压测 Agent 微虚拟机沙箱
作者用约 2,200 行 Go 复刻 Agent Compute Engine 的关键模式：共享写时复制快照、工具调用驱动的检查点、批量 fork，以及无网卡、凭据留在宿主代理的出口控制。裸机恢复 25 ms，但 Mac 嵌套虚拟化下 12 个并发 fork 全部失败。
- 具体怎么做
- 实现基于 firecracker-go-sdk 的编排器、微虚拟机内 Agent、约 230 行出口代理和写 CSV 的基准工具。预热快照由多个 VM 写时复制共享；工具调用生命周期触发检查点；guest 不配置网卡，只能经 vsock 到宿主代理，由宿主持有真实凭据并执行出口策略。
- 做到了什么
- 在裸机上，512 MiB VM 的 64 个空闲 fork 每个约增加 3 MiB 宿主内存；快照恢复到可响应为 25 ms，比冷启动快 26 倍，64 个并发 fork 约 150 ms 全部就绪。Mac mini 嵌套虚拟化中，12 个并发 fork 没有一个就绪，显示这套密度结论不能直接外推到开发机。
- 上手要点
- 威胁模型假设沙箱内代码不可信且可能有 root；不要把真实凭据放进 guest 环境变量。
你可以这样试
使用 Firecracker在【Linux/KVM 主机规格】上搭建一个 Agent 微虚拟机沙箱原型：使用 Firecracker 快照和写时复制，guest 无网卡，只通过 vsock 调用宿主出口代理，真实凭据仅保存在宿主。分别测量【1/16/64】个 fork 的恢复延迟、就绪时间和增量内存，并与冷启动比较。记录失败和环境限制，输出 CSV 与结论，不要把裸机结果外推到嵌套虚拟化。