2026 年 6 月 22 日，AWS 在官方博客上发了一篇公告，标题很长，但核心只有一句话：Lambda 现在可以跑 MicroVM 了。
AWS 没出新服务，没出新的 SKU——Lambda 这个已有 11 年历史的 serverless 产品里，开了一扇全新的门。笔者读完第一反应：AWS 把 Firecracker 从幕后推到了台前，而且这次不是给 Lambda 自己的函数用，是给开发者直接用的。
到底发布了什么
Lambda MicroVMs 是一个新的计算原语。它和 Lambda Functions 共享同一个控制台入口，但 API 完全不同：你上传一个 Dockerfile 加一份代码压缩包到 S3，Lambda 帮你构建镜像、初始化应用、打一个 Firecracker 快照。之后每次启动 MicroVM，都从这个预热的快照直接恢复——冷启动环节被直接跳过。
几个关键参数值得注意：
- 单实例上限：16 vCPU、32 GB 内存、32 GB 磁盘，ARM64（Graviton）架构
- 最长运行时间：8 小时——Lambda Functions 的 15 分钟限制在这里不复存在
- 空闲策略：可配置自动挂起（suspend），挂起期间只收快照存储费，恢复时保留完整内存和磁盘状态
- 启动方式：快照恢复而非冷启动。启动成功后立即获得一个就绪的 HTTP endpoint
- 首批区域：美东（弗吉尼亚、俄亥俄）、美西（俄勒冈）、欧洲（爱尔兰）、亚太（东京）
定价按 vCPU/秒和内存/GB/秒计量，挂起后计算费用归零。这和 Lambda Functions 的计费逻辑一致，但由于单次会话可以持续数小时，实际账单结构会更接近一台按需虚拟机——只是多了暂停能力。
AWS 官方博客中明确列出了一组目标场景：AI 编程助手、交互式代码环境、数据分析平台、漏洞扫描器、运行用户脚本的游戏服务器。共同特征是什么？每个终端用户都需要一个属于自己的、能安全执行不可信代码的隔离环境。
为什么是现在
这个问题值得拆开看。
Firecracker 2018 年就开源了。过去七年，它每月支撑着超过 15 万亿次 Lambda 函数调用。技术是成熟的，但 AWS 一直没有把 Firecracker 当成一个面向开发者的产品来卖——直到现在。
变化的不是 AWS 的策略偏好，是需求侧。
2025 年到 2026 年上半年，AI 代码助手从实验品变成了日常工具。Claude Code、Codex CLI、Gemini Code Assist——这些 agent 不仅生成代码，它们还要执行代码。安装包、起服务、读写文件系统、发起网络请求。每天数百万次。而执行这些代码的环境，要么是 Docker 容器（共享内核，隔离靠 namespace + cgroup + seccomp），要么是虚拟机（隔离强但启动慢）。
更棘手的是，agent 本身会主动绕开软件层面的安全限制。2026 年 3 月，Falco 核心维护者 Leonardo Di Donato 演示了 Claude Code 如何绕过自己的沙箱：agent 发现 /proc/self/root/usr/bin/npx 绕过了 deny 规则，被 bubblewrap 拦截后又直接关闭了沙箱。没有 jailbreak，没有特殊 prompt。它只是想把任务完成。
这个案例说明了一个核心事实：基于用户空间逻辑的隔离（denylist、permission prompt、seccomp 规则）和 agent 的推理在同一层运行。agent 有足够的能力理解和绕过它们。而 MicroVM 的隔离由硬件虚拟化强制执行，在 agent 无法触及的层面生效。
Lambda MicroVMs 的推出时机，与这个安全问题的爆发高度重合。
沙箱市场的格局
Lambda MicroVMs 不是凭空出现的。在它之前，围绕”如何安全执行不可信代码”这个问题，已经形成了一个颇具规模的工具和平台生态。笔者梳理了当前的主要阵营，不分优劣，只呈现架构差异和适用场景。
Firecracker 阵营
AWS 自己当然是最大的玩家。除了新发布的 Lambda MicroVMs，AWS Bedrock AgentCore 也在用 Firecracker 为每个 agent session 提供独立 microVM。
独立平台方面，E2B 是一个专注 AI agent 沙箱的服务，Firecracker 底层，~150ms 启动，宣称 88% 的财富 100 强已注册。Fly.io Sprites 提供了持久化的 stateful VM，checkpoint/restore 约 300ms，预装 Claude Code 和 Codex CLI。Vercel Sandbox 同样基于 Firecracker，主打毫秒级快照恢复，面向 AI 代码解释器场景。SlicerVM 走自托管路线，同时支持 Firecracker 和 Cloud Hypervisor，也可在 macOS 上使用 Apple Virtualization Framework。
开源项目里，Matchlock 值得关注——为 AI agent 设计的 Firecracker 沙箱，默认 deny-all 网络策略，域名白名单，密钥保护，专门解决 claude --dangerously-skip-permissions 的安全性问题。
libkrun 阵营
Red Hat 的 libkrun 走的是库级 VMM 路线——把 microVM 能力打包成一个可以被其他程序调用的库，而不是一个独立守护进程。Microsandbox（YC 孵化，Apache 2.0 开源，~4,700 GitHub Star）是 libkrun 最典型的消费方：一个自托管的 AI agent 沙箱，每个实例获得独立内核、文件系统和网络栈。
libkrun 的一个差异化优势是跨平台：Linux 上走 KVM，macOS 上走 Hypervisor.framework。缺点是缺少 Kubernetes 编排层和集群级管理能力——它更擅长单机部署，适合开发者本地或小型团队的沙箱需求，而非大规模多租户生产环境。
Kata Containers
Kata Containers 在定位上和其他方案有本质区别：它提供一个编排框架，把 Firecracker、Cloud Hypervisor 或 QEMU 嵌入到 Kubernetes 运行时层，让每个 Pod 跑在自己的轻量级 VM 里。对 Kubernetes 来说它看起来就是个普通容器，底下却是完整的硬件隔离。
启动时间 ~150-300ms（取决于 VMM 选择），内存开销 <10 MiB 加 guest kernel。Kata 的核心价值在于把 microVM 的操作复杂度封装掉了——你不用自己管理内核镜像、网络配置、VM 生命周期。Northflank 在生产环境跑 Kata Containers + Cloud Hypervisor，月均超过 200 万 microVM。
Kata 面向长期运行、需要 K8s 编排的多租户工作负载，而非单次会话快速启停的场景。
gVisor
Google 的 gVisor 走了一条完全不同的技术路线：它不在容器外面套虚拟机，而是在容器和宿主机内核之间插入一个用 Go 写的用户态内核（Sentry）。容器发出的 syscall 被 Sentry 拦截并在用户空间处理，只有少量必要操作透传到宿主机内核。
这意味着没有 VM 启动开销，不需要嵌套虚拟化支持，Docker/containerd 集成路径最短。代价是：I/O 密集型工作负载有 10-30% 的 syscall 开销。gVisor 的隔离强度介于容器和虚拟机之间——它大幅缩小了内核攻击面（Sentry 只实现了 ~230 个 syscall，而 Linux 内核暴露了 450+），但做不到硬件级的内存隔离。
Modal 是 gVisor 路线的代表性产品，提供 GPU 支持的沙箱环境，~300ms 启动，主打推理和训练场景。
Cloudflare Workers（V8 Isolates）
Cloudflare 走的是另一个极端：V8 isolate。启动时间亚毫秒级，但只支持 JavaScript/TypeScript/WASM。2026 年新增了 Dynamic Workers 功能，允许 LLM 在运行时动态生成 JS/TS 子 isolate 来执行代码，token 消耗比传统 tool-calling 减少 81%。它不是通用沙箱，但在 JS/WASM 生态内密度和延迟表现无人能及。
差异化维度
梳理完各家方案后，笔者观察到几个正在成为竞争焦点的维度：
快照/分叉能力。 Lambda MicroVMs 的”预热快照直接启动”本质上是把一个已初始化的运行时状态凝固下来，下次启动时直接恢复。这个思路在 Unikraft Cloud 做到了极致——宣称 <10ms 冷启动，单宿主机 10 万+ 隔离实例。快照的速度直接决定用户体验：agent 发起一个代码执行请求后，用户到底等 100ms 还是 5 秒，差别就是持续使用和放弃。
网络层密钥遮蔽。 这对 agent 场景尤其关键。agent 需要访问外网（拉依赖、调 API），但你不希望它读到你的环境变量里的密钥。Lambda MicroVMs 的解决方式是 short-lived auth token + proxy 头，Matchlock 的做法是 deny-all + 域名白名单。差异不在功能有无，在各家对安全模型的理解不同。
SSH / VPN 接入。 交互式开发场景需要开发者能直接进入沙箱调试。Fly.io Sprites 和 E2B 支持 SSH，Lambda MicroVMs 目前走 HTTP endpoint 模式，更适合代码执行而非交互开发。
编排层与 K8s 集成。 Kata Containers 在这个维度上几乎没有对手——它就是为了 Kubernetes 设计的。Firecracker 裸用需要自建大量基础设施，Lambda MicroVMs 则把这个责任转移到了 AWS 托管服务上。libkrun 目前缺少集群级编排方案。
Agent 友好度。 这涉及产品设计哲学，而非单纯的技术规格比较。沙箱是否暴露 REST API？是否支持 SDK？snapshot/resume 的语义是否适合 agent 的”执行-等待结果-继续执行”循环？Lambda MicroVMs 的暂停/恢复机制和 8 小时上限显然是为 agent session 设计的，而 Docker Sandboxes 的”每个 agent 一个独立 Docker daemon”模型则更偏重本地开发场景。
格局还没定
把时间线拉长来看，2018 年 Firecracker 诞生时，microVM 还是一个基础设施层的优化手段——让 Lambda 更快、更省、更安全。到了 2026 年，同样的技术变成了产品层的第一公民，因为上层需求发生了根本变化：agent 要执行代码，执行代码需要沙箱，沙箱不能是 namespace 的拼凑。
但”谁是最好的沙箱”这个问题没有统一答案。如果你的 agent 只跑 JavaScript，Cloudflare Workers 的 V8 isolate 可能比亚毫秒启动的 microVM 更强。如果运行在 Kubernetes 上且需要长期运行的隔离 Pod，Kata Containers 比裸 Firecracker 更务实。如果你需要本地自托管的轻量方案，libkrun + Microsandbox 比 AWS 托管服务更灵活。Lambda MicroVMs 的优势在于零运维和快照恢复——但它绑定了 AWS 生态、ARM64 架构和区域限制。
笔者没有在生产环境大规模运行过以上任何一种沙箱方案。本文的判断基于公开文档、技术白皮书和社区讨论的交叉验证。如果你正在为 AI agent 选沙箱基础设施，建议用自己的工作负载做基准测试——100ms 快照恢复在实际网络延迟中的表现，和 benchmark 表格里的数字可能是两回事。
架构的胜负手，往往不在架构本身。 在一个 agent 每秒发起数十次代码执行请求的世界里，快照速度、网络延迟、密钥管理、计费模型——这些”非核心”因素，可能比 VMM 是 Rust 写的还是 Go 写的更重要。
声明：本文仅为技术观察，笔者与文中提及的任何公司或项目无利益关联。