为什么标准 Docker 无法满足极致沙箱需求？
在面向公众开放的 AI 代码助手平台中，恶意用户可能诱导模型生成内核提权攻击代码或挖掘加密货币。标准 Docker 容器共享宿主机内核，隔离级别无法抵御零日（0-day）内核漏洞。
基于微虚拟机的沙箱架构优势
现代 Agent 基础设施（如 E2B、Modal）普遍采用 Firecracker 微虚拟机：
- 硬件级虚拟化隔离：每个沙箱独占虚拟 CPU 和精简 Linux 内核，即便宿主机内核有漏洞，攻击者也无法逃逸；
- 内存快照预热（Memory Snapshot Pre-warming）：将安装好 Python、Node.js 与常用开发库的虚拟机在内存中制作快照，新请求到达时直接从内存恢复（Fork），启动时间压缩至 50 毫秒以内。
落地清单：从威胁模型到生命周期策略
- 先定威胁等级。内部工具执行自家代码，容器加运行时策略通常够用；执行任意用户提交的代码，才需要微虚拟机级别，安全全景可参考 MCP 安全防御架构：从鉴权拦截、沙箱隔离到高危指令熔断；
- 网络默认拒绝。沙箱出网按域名白名单放行，禁止任意外联，阻断数据外传与挖矿回连；
- 强制生命周期。每个沙箱设 TTL 上限自动回收，用快照池维持热备实例，避免长驻；
- 配额与计量。按实例秒数计费限流，单用户并发封顶，让滥用成本可控；
- 不可变镜像。运行环境只读，写入落在临时层，销毁即清空。
三档隔离方案对比
| 维度 | 进程级隔离 | Docker 容器 | Firecracker 微虚拟机 |
|---|---|---|---|
| 隔离强度 | 低（同内核同权限） | 中（共享内核） | 高（硬件虚拟化） |
| 冷启动量级 | 亚毫秒 | 通常数百毫秒 | 快照恢复约数十毫秒 |
| 单实例内存 | 最小 | 数十 MB 起 | 数十 MB 起 |
| 运维复杂度 | 低 | 中 | 中高（需虚拟化支持） |
| 适用场景 | 可信内部脚本 | 半可信工具服务 | 任意公共代码执行 |
追求更高密度且代码可改造时，也可以评估 基于 WebAssembly 的轻量级边缘 Agent 运行时架构探索 中的 WASM 路线。
验证方法
三条可执行的检查：逃逸探测，在沙箱内尝试访问未授权路径与元数据服务地址，全部应被拒绝；断连测试，销毁宿主上一个沙箱不应影响其余实例的时延与成功率；回收审计，抽查超过 TTL 的实例是否确实消失，防止僵尸实例累积成本。
常见故障速查
| 现象 | 原因 | 处理 |
|---|---|---|
| 沙箱内 pip/npm 安装失败 | 出网白名单过严 | 放行受控镜像源域名而非全开 |
| 冷启动偶发数秒抖动 | 快照池水位不足被冷建 | 按峰值并发预热池容量 |
| 宿主内核升级后无法起沙箱 | 虚拟化依赖与内核不匹配 | 升级前在 staging 宿主全量回归 |
| 用户任务结束但实例仍计费 | 回收依赖前端信号 | 以服务端 TTL 为唯一回收依据 |
小结
选择隔离方案的判断标准只有一条：被执行的代码是否可能携带攻击者完全可控的输入。是，就 upper bound 按微虚拟机设计，再谈成本优化；否，就用更轻的方案换取密度与简单性。上线前至少完成逃逸探测与回收审计两轮验证，缺任何一轮都视为未就绪。