Agent sandbox 可能的选型以及 unikernel 的机会
内容提要
文章探讨了为何Agent沙箱未采用unikernel技术，对比了Firecracker、Kata、WASM等方案。Firecracker启动快但镜像构建复杂，Kata兼容OCI但缺快照，WASM启动极快但难支持Python。Unikernel理论上理想，但过去不支持多进程，限制其应用。未来技术发展或带来机会。
延伸解读
容器启动速度被低估
文章指出，容器冷启动时间其实可以低至10-50毫秒，远快于Firecracker等轻量级虚拟机（通常125毫秒以上）。许多对比不公平地拿容器进程就绪时间与空虚拟机启动时间比较。因此，容器在启动速度上完全满足Agent沙箱需求，其短板主要在安全性，而非速度。
镜像构建与分发是隐藏瓶颈
文章强调，镜像构建和分发的效率往往比启动时间更影响整体性能。e2b需将Docker镜像转为ext4根文件系统，构建复杂；而Kata直接兼容OCI镜像，构建简单。Modal则通过FUSE实现按需加载，大幅减少镜像拉取时间。这提示选型时需权衡镜像生态与启动性能。
Unikernel的多进程限制与突破
传统Unikernel不支持多进程，导致难以运行依赖多进程模型的Python。Unikraft 0.19版本虽引入多进程支持，但实现方式（vfork共享地址空间）并非真正多进程。UKL通过集成到Linux保留多进程能力，却牺牲了Unikernel的启动速度和攻击面优势。未来若能在多进程与轻量性间取得平衡，Unikernel仍有潜力。
Q&A
为什么Agent沙箱没有采用unikernel技术？
主要是因为传统的unikernel不支持多进程，而Python等主流Agent开发语言重度依赖多进程模型，导致无法很好地支持。此外，unikernel的生态和工具链不成熟，镜像构建和分发也不如Docker方便。
Firecracker、Kata和WASM在Agent沙箱中各自的优缺点是什么？
Firecracker启动快（125ms以上），提供强隔离和快照能力，但镜像构建复杂；Kata兼容OCI镜像，构建简单，但可能无法利用Firecracker的快照功能；WASM启动极快（10ms级），但难以支持Python，因为WASI接口有限且Python依赖系统调用。
e2b是如何利用Firecracker构建Agent沙箱的？
e2b使用Firecracker作为VMM，将Docker镜像转换为ext4根文件系统，通过两次启动Firecracker虚拟机（第一次安装systemd，第二次启动服务）来构建模板，最后创建快照并上传。调度使用自研的基于best-of-k算法的轻量级调度器，而非Kubernetes。
Kata方案（如k7）与e2b相比有什么优势和劣势？
Kata方案的优势是完全兼容OCI镜像，构建简单，且与Kubernetes集成良好；劣势是无法像e2b那样利用Firecracker的快照功能实现快速恢复，可能影响频繁创建销毁场景的性能。
为什么WASM难以支持Python？
WASM假设单一线性内存空间，而Python的内存管理依赖GC，且WASI接口精简，功能远少于Linux原生接口，导致许多Python库无法正常工作。Pyodide等方案冷启动慢，优化也治标不治本。
Unikraft和UKL在支持多进程方面有何不同？
Unikraft在0.19版本通过vfork实现多进程，但子进程与父进程共享地址空间，若不立即execve会互相干扰，并非真正多进程。UKL则通过将应用直接链接到Linux内核，保留Linux的多进程和地址空间隔离，但失去了unikernel的启动快和攻击面小的优势。
Modal是如何优化镜像加载速度的？
Modal采用lazy loading（按需加载）方式，通过FUSE拦截文件系统读取，先生成占位文件系统树，按需从内存、本地SSD、同可用区缓存、区域CDN、对象存储等优先级获取数据，避免传统串行下载和解压整个镜像，大幅减少启动延迟。
