容器毫秒级启动、单机承载上千实例，代价是逃逸即宿主失陷；全功能虚拟机隔离最硬，代价是秒级启动与低密度。Agent Runtime 的全部设计空间，就是在这两极之间找平衡。
Agent Runtime 需要先决定边界放在哪一层——进程、内核还是硬件——再决定这一层如何包装为 agent 可用的会话。E2B、Vercel Sandbox、AWS Bedrock AgentCore 与 AgentENV 表面上是不同产品，底层却是同一张隔离谱系上的不同选点。
1. 三层模型
把 Agent Runtime 按三层拆解：
| 层 | 解决的问题 | 2026 年主流选型 |
|---|---|---|
| 隔离底座 | 不可信代码的执行边界与隔离强度 | Firecracker microVM |
| 会话抽象 | agent 与环境的交互方式（命令、文件、状态） | envd、快照/恢复/fork、SDK |
| 控制面 | 大规模沙箱的管理（创建、调度、网络、配额） | API + Gateway / Scheduler |
- 其中实例密度指单台宿主机可并发承载的隔离实例数量，受单实例资源开销与资源复用率约束，直接决定规模化的单位成本。
底座技术趋于标准化，真正的差异集中在存储工程、会话抽象与控制面。
2. 隔离底座：谱系与选型
graph LR
A["进程沙箱 bwrap / Seatbelt"] --> B["容器 runc / Docker"]
B --> C["gVisor 用户态内核"]
B --> D["Kata 轻量 VM"]
B --> E["Firecracker microVM"]
E --> F["全 VM QEMU"]
该图表示隔离强度递增的谱系，非时间线或包含关系：越靠右隔离越强，启动延迟、资源开销与密度代价越高。
| 方案 | 内核 | 特权要求 | 启动 | 单实例开销 | 密度 | 典型损耗 | 兼容性 |
|---|---|---|---|---|---|---|---|
| 进程沙箱 | 共享 | 无 | 毫秒 | ~0 | 极高 | ~0 | 全 |
| 容器 | 共享 | 无（普通） | 秒 | 小 | 高 | 低 | 全 |
| gVisor | 软件隔离 | 无（KVM 可选） | 秒 | 小 | 高 | 中（IO 重） | Linux 大部分 |
| Kata | 独立 guest | KVM 可选 | 百毫秒~秒 | 数十 MB | 中 | 中 | Linux（容器接口） |
| Firecracker | 独立 guest | 需 KVM | <125 ms | <5 MiB | 高 | 低~中 | 仅 Linux |
| 全 VM | 独立 guest | 需 KVM | 秒~十秒 | 高 | 低 | 中 | 全（含 Windows） |
Info：
- 进程沙箱（bwrap / Seatbelt）：以操作系统自带的强制访问控制约束单个进程，不改变内核共享的事实。开销趋近于零，适用于本地开发工具的防御性约束，不足以支撑多租户威胁模型。
- 容器（runc / Docker）：以 namespace 隔离视图、cgroup 限制资源、capabilities 与 seccomp 裁剪权限。生态完备，但内核攻击面完全共享，容器逃逸即宿主失陷。
- gVisor：以 OCI 运行时 runsc 保持容器形态，将系统调用截获至 Go 实现的用户态内核 Sentry 模拟执行；systrap 平台无需特权与 KVM。其隔离目标是宿主内核的攻击面而非硬件，代价是系统调用与文件 IO 的性能损耗。
- Kata Containers：保持 OCI 容器接口，每个容器运行于拥有独立 guest 内核的轻量虚拟机。隔离强度为虚拟机级，代价是每 guest 数十 MB 的内核内存开销与较低的实例密度。
- Firecracker：脱离容器形态，每个实例为精简虚拟机，移除 BIOS、PCI 枚举与图形设备，仅保留 virtio-net/block/vsock 与串口，同时获得虚拟机级隔离与容器级密度。
- 全虚拟机（QEMU / KVM）：完整设备模型，支持 Windows 等任意操作系统，兼容性上限最高，但资源开销与启动延迟亦为最高。
容器共享宿主内核，虚拟机运行独立的 guest 内核。microVM 也属于虚拟机一侧，其平衡不在隔离强度，而在以极简设备模型换取接近容器的启动速度与实例密度。
agent 沙箱需同时满足三项要求：
- 启动延迟：agent 高频创建与销毁沙箱，冷启动延迟需控制在亚秒级。
- 实例密度：RL 训练与并行 agent 工作流要求单机承载数百至数千实例。
- 隔离强度：执行对象为不可信代码，逃逸的代价不可接受。
逐项淘汰过程如下：gVisor 的隔离思路成立，但系统调用与 IO 损耗使其难以承载真实软件负载；Kata 提供虚拟机级隔离，但每 guest 独立内核内存导致密度受限；容器兼具速度与密度，但共享内核使一次逃逸即导致宿主失陷。
Firecracker 处于上述约束的平衡点：硬件虚拟化提供独立内核，单实例内存开销低于 5 MiB，无 BIOS 的引导路径缩短启动时间。其内存快照能力允许预先构建标准状态虚拟机并保存内存镜像，新沙箱通过快照恢复而非冷启动完成初始化——AWS Lambda 即以此加速函数冷启动，agent 沙箱借此达到数十毫秒级就绪。E2B、Vercel Sandbox 与 AWS Bedrock AgentCore 均基于此方案。
3. overlayfs & overlaybd
隔离方案解决执行边界，但无磁盘的虚拟机无法承载工作负载。Agent Runtime 的存储难题集中于共享而非持久化：单个 Ubuntu 镜像约 2 GB，单机需承载数百个沙箱；生产环境镜像目录规模可达数百万，本地磁盘无法全量存放；任务重复执行要求环境初始化开销最小化。
容器生态已在文件级解决镜像共享：镜像由只读层堆叠构成，各容器仅携带薄层可写层，基础层全局共享一份。该机制依赖内核 overlayfs（Docker overlay2 存储驱动）——overlayfs 运行于宿主内核，容器进程只是共享其合并视图的使用者；分层粒度为文件，工作于 VFS 层。（该方案隐含前提：容器共享宿主内核，因此可访问宿主 VFS，overlayfs 得以叠加目录视图）
而虚拟机拥有的是独立内核，仅能访问块设备，分层因此需下沉至块级——即 overlaybd 一类块级镜像格式的定位：
| overlayfs | overlay2 | overlaybd | |
|---|---|---|---|
| 分层粒度 | 文件 | 文件 | 块（4 KiB） |
| 工作层次 | VFS 层 | VFS 层 | 块设备层 |
| 使用场景 | 内核通用 | Docker 镜像 | Firecracker 等 VM 场景 |
| 与 ublk 的关系 | 无关 | 无关 | 经 ublk 暴露为块设备 |
容器可进行文件级分层，因其共享宿主 VFS；虚拟机仅访问块设备，分层因此下沉至块级。
块级分层带来两项额外收益：
- 按需拉取：客户机按需从镜像仓库读取数据块，本地磁盘仅作有界缓存并按需淘汰，无需全量预置镜像。
- 增量快照：将可写上层封存为新的只读层即为一次快照，无需复制完整磁盘。
ublk 解决用户态分层镜像与内核块设备之间的对接：Linux ublk 框架允许用户态程序充当块设备读写后端，overlaybd 经 io_uring 在宿主上暴露为 /dev/ublkbN；Firecracker 将其作为 virtio-blk 后端，客户机内对应 /dev/vda，由客户机自行格式化文件系统。
overlayfs 位于宿主内核，在容器场景中为容器进程提供镜像分层的合并文件系统视图；overlaybd 位于宿主用户态、服务于虚拟机，客户机对 overlaybd 无感知。两者均为宿主侧实现，区别仅在 VFS 层与块设备层。
AgentENV 进一步将内存快照复用同一机制：内存按层存储，经 ublk 暴露为只读块设备，多个从同一快照恢复的沙箱共享同一设备，宿主 page cache 仅保留单份数据。该设计构成其生产环境 9.6x 内存超卖的基础。
4. 会话抽象与控制面
底座趋同后，产品差异集中于上层。
会话抽象。客户机内需运行守护进程，将命令执行、文件操作与 PTY 封装为 API——E2B 开源的 envd 即承担此角色，AgentENV 亦直接复用。agent 通过 commands.run()、files.write() 等 SDK 接口与沙箱交互，而非直接操作裸虚拟机。
围绕会话抽象，快照、恢复与 fork 构成状态管理能力：
1 | 创建沙箱 = 从模板快照恢复，毫秒至数十毫秒完成 |
控制面。单机无法支撑规模需求，多机控制面由 Gateway 与 Scheduler 构成：Gateway 为 HTTP 入口并按沙箱 ID 路由；Scheduler 负责节点选择、沙箱到节点的绑定与心跳对账。网络出口策略、凭据注入、配额与审计均实现于此层。对 Agent Runtime 而言，该层构成安全投入的主体：隔离底座仅决定逃逸代价，网络出口与文件系统策略决定数据外泄的可能性。
隔离底座决定”跑不了多坏”，控制面决定”业务能否成立”。
案例：E2B 与 AgentENV。两者共享同一骨架，调校方向不同。
E2B 为通用 sandbox-as-a-service：每个沙箱对应一个 Firecracker microVM，提供 E2B 兼容 API 与官方 SDK。其价值在于验证了 microVM 包装为 agent 会话 API 的可行性——底座本身不再是差异化来源，会话抽象才是。
AgentENV 为 RL 训练场景优化的变体，服务 Kimi K3 的 agentic RL 训练：
| 维度 | E2B（通用产品） | AgentENV（RL 训练） |
|---|---|---|
| 镜像规模 | 按需拉取 | 镜像目录 150 万，本地仅作有界缓存 |
| 内存快照 | 支持 | 多沙箱共享同一快照（page cache 复用） |
| 闲置成本 | 支持 pause | 9.6x 内存超卖，空闲即归还资源 |
| 沙箱寿命 | 分钟~小时 | 默认 15 秒（短命任务、用完即弃） |
| 并行 | fork | fork + 大规模调度 + P2P 节点间镜像传输 |
两者共享 Firecracker 底座、envd 守护进程与 E2B 兼容 API；AgentENV 未照搬 E2B 的编排实现，存储层（overlaybd、ublk 与内存快照链路）为自研。