Firecracker 是 AWS 在 2017 年为 Lambda 函数计算自研的 microVM（精简版虚拟机），启动约 125 毫秒、单台可承载上千个隔离实例 — 十年后它被 AI Agent 行业集体捡回来当代码执行沙箱，因为容器（Docker 这类共享宿主内核的方案）隔离力度被认为不够。我们关心这件事，是因为 AI Agent 进入企业时，"代码能不能安全跑"是合规的第一道门。

这是什么

当 Agent 要执行用户提交的代码（比如让 AI 跑一段 Python 算账），需要隔离环境防止越权或恶意行为。Docker 类容器共享宿主内核，攻击面大；microVM 有独立内核和资源配额，隔离强度接近传统 VM，启动速度接近容器。技术上有个新坑：容器镜像（OCI 标准格式）不能直接当 VM 硬盘用，需要把多层文件系统合并、处理"删除标记"、补上内核模块和 init 启动脚本。

行业怎么看

主流是跟进。Anthropic 去年在技术博客里推荐 Agent 用"代码执行 + MCP"模式跑在沙箱里；E2B、 Dayton a 等 Agent 沙箱服务商底层都在用 Firecracker。投资人看到的是：任何一家企业要做"能跑代码的 Agent"，沙箱是绕不过去的工程基建。

反对声音也有。容器派认为 microVM 冷启动多几十毫秒，运维需要懂 KVM（Linux 内核虚拟化模块）和内核裁剪，自托管成本高；高频代码补全类产品用容器 + gVisor（用户态内核沙箱）更划算。OpenAI、Anthropic 内部 Agent 是否全用 Firecracker 也没公开说法 — 不能默认"所有 Agent 都在用"。

对普通人的影响

对 企业 IT：如果公司要上线能执行代码的 AI Agent（财务自动化、数据分析），安全审计会卡隔离级别 — 容器可能过不了合规，microVM 是更稳的默认选项。

对 个人职场：用 Cursor、Devin、通义灵码这类 AI 写代码工具偶尔"卡一下再出结果"，背后可能是 microVM 冷启动成本，不一定是 bug。

对 消费市场：Agent 沙箱按执行时长计费正成为新商业模式，类似当年的 AWS Lambda — 用户看不到虚拟机，但账单上会体现。