Lambda MicroVM：AI Agent 沙箱的云原生转向

AI 编码 agent 有一个很简单的需求：让我运行命令。

这也是很多事件的开始方式。有种奇妙的对称性。

在过去的一年里，很多 agent 沙箱工作感觉就像一个穿着安全帽的本地工程项目。做一个容器。挂载一个工作区。屏蔽一些网络访问。隐藏敏感信息。希望 agent 找不到什么创意十足的方法把 npm install 变成一件行为艺术作品。

这是有用的。现在仍然有用。

但 AWS 宣布 Lambda MicroVMs 指向了这个问题的下一个形态：agent 沙箱正在变成一个云原语，而不是围绕终端的巧妙包装。

有趣的地方不仅在于 Lambda MicroVMs 使用 Firecracker，或者它们启动速度快，或者它们可以保持状态。有趣的地方在于产品边界。

AWS 在说：你可以为每个用户、每个任务或每条 AI 生成的代码路径提供自己的 VM 级执行环境，拥有生命周期控制、网络配置、状态保持和账单的细粒度控制，而无需自己构建虚拟化平台。

这是一个很大的提示，暗示了 agent 基础设施的走向。

容器是第一个答案

容器是显而易见的第一个答案，因为工程师已经理解了它们。算是吧。

它们足够快，足够便宜，足够便携，而且已经接入 CI、Kubernetes、扫描器、镜像仓库和关于 Docker 网络的集体创伤。如果你需要一个 agent 来编辑仓库和运行测试，容器是一个合理的起点。

但"合理的起点"不等于"任意生成代码的最终安全边界"。

Agent 工作负载有一个很特殊的烦人之处。它们需要安装依赖、执行工具、写入文件、运行测试、也许启动浏览器、也许调用内部 API、也许在尝试之间保持状态、也许在人类审查输出时空闲。它们不仅仅是无状态函数调用。它们也不完全是正常的服务。

它们是有雄心的乱糟糟的小工作区。

容器可以承载这些。但一旦你关心租户隔离、提示注入、不可信代码、文件系统状态、网络出口和长时间运行的会话，你就开始围绕容器重建很多 VM 形状的关切。

在那一刻，架构是在无声地坦白。

沙箱需要内存

旧的沙箱模型是一次性的：运行命令、收集结果、扔掉环境。

这对简单的任务有效。对 agent 工作来说很痛苦。

编码 agent 不仅运行一条命令。它会探索、改变文件、运行测试、安装包、失败、备份、重试、等待 CI，然后在审查者说"也更新一下迁移脚本"后恢复。如果环境在每一步后都消失，你要么丧失有用的状态，要么不断重建它。

Lambda MicroVMs 把状态保持作为原语的一部分。AWS 描述的会话可以跨越长达八小时，暂停和恢复会保留内存和磁盘状态。这很重要，因为 agent 工作充满了闲置间隙。

这直接关联到乏味的成本问题。如果每个 agent 工作区都必须保持完全热启动来保持状态，账单就会成为一场会议。如果平台可以暂停环境、保留状态、快速恢复，agent 基础设施就会获得与工作相匹配的生命周期。

不是魔法。只是减少了浪费的等待。

VM 级隔离不是奢侈特性

安全论证也变得更加尖锐。

当 agent 运行生成的代码时，威胁模型不仅仅是"代码有 bug"。威胁模型是"代码可能是从被入侵的提示、被污染的依赖、误导性的议题或自信地输出胡言乱语的模型生成的"。

那段代码需要一道真实的边界。

Firecracker microVM 之所以有趣，是因为它们处于 agent 平台需要的不舒适的中间位置：比普通容器更强的隔离，比传统 VM 更轻更快，而且熟悉得足以让云提供商大规模运维。

这不会让问题消失。除非你喜欢将来的事件审查，否则不要在幻灯片中放"通过 microVM 解决"。

你仍然需要网络策略。你仍然需要秘密隔离。你仍然需要出口控制。你仍然需要审计日志。你仍然需要决定 agent 允许调用什么，以及当它非常有礼貌地请求部署到生产环境时会发生什么。

但 VM 级隔离改变了默认的爆炸范围。如果 agent 写了破坏性的东西，它首先摧毁的应该是它自己的临时环境，而不是开发者笔记本电脑、不是共享 worker、不是某个人因为演示在星期二而忘记挂载的生产凭证缓存。

策略不能活在提示内

AWS 将 Lambda MicroVM 的故事与 Agent Toolkit 指南和 Bedrock AgentCore 策略相结合。这个组合比各个产品名称更重要。

模式是：隔离执行、教 agent 正确的工作流、在 agent 之外执行策略。

最后一部分是团队应该偷取的，即使他们永远不接触 AgentCore。

如果 agent 能重写自己的计划，策略就不能仅仅活在计划内。一个说"不要部署到生产环境"的提示很不错。但它也是链锯上的便利贴。

执行点需要坐在工具边界处。当 agent 请求运行部署工具时，网关应该知道用户、工具、环境、参数和策略。即使模型正在进行一个漂亮的推理时刻，它也应该能够说不。

这就是普通生产系统的工作方式。我们不依赖 API 客户端来记住安全模型。我们在边界处放置授权，因为客户端有 bug、用户很有创意、分布式系统是一个性格测试。

Agent 不应该仅仅因为用段落说话就获得这方面的特殊豁免。

平台形状变得显而易见

agent 运行时平台现在需要一些乏味的对象：

• 隔离：每个 agent 会话在自己的执行边界内
• 状态：磁盘和内存在暂停/恢复周期中持续
• 可观测性：执行日志、资源使用、行为审计
• 策略：谁可以调用什么、在哪里、带什么参数
• 生命周期：明确的启动、暂停、恢复、终止、清理

这些都不是光鲜亮丽的。这就是你知道它们重要的方式。

agent 沙箱的演示版本是"它可以运行测试"。生产版本是"我们知道谁的代码运行了、在哪里运行、它能到达什么、它改变了什么、为什么恢复了、花了多少钱、它怎样死的"。

最后一部分很重要。Agent 沙箱需要好的死亡方式。超时。预算限制。空闲暂停。硬终止。状态导出。日志保留。资源清理。一个因为每个人都害怕删除它而永远存活的沙箱不是工作区。它是一个小基础设施博物馆。

Lambda MicroVMs 之所以重要，不是因为每个人明天都必须将 agent 执行迁移到 AWS。

那样会很整洁。软件惩罚整洁。

它们之所以重要是因为它们命名了这个原语。AI 生成的代码需要一个隔离的、有状态的、可暂停的、可观测的、可治理的、足够便宜用于日常工作的执行边界。

容器仍然会是故事的一部分。Kubernetes 仍然会是故事的一部分。本地沙箱仍然重要。但 agent 时代正在推动代码执行向更强的边界和更清晰的生命周期控制发展。

沙箱不再是一个辅助脚本。

它是产品的一部分。

如果你的 agent 平台对隔离、状态、策略和清理没有真正的答案，它可能还不是一个 agent 平台。

它是一个充满乐观主义的终端。

参考资源

AWS Compute Blog: Announcing Lambda MicroVMs

AWS Compute Blog: Secure code execution for AI agents with AWS Lambda MicroVMs

Firecracker: secure and fast microVMs for serverless computing

为了测试我的项目，我使用 Railway。如果你想要 20 美元的启动资金，请使用这个链接。

如有进一步的行动，你可以考虑屏蔽这个人和/或举报滥用行为