亚马逊AWS官方博客
Lambda MicroVMs vs Bedrock AgentCore：AI Agent 开发者该怎么选？
摘要：2026 年 6 月，AWS 同时拥有了两个能”安全运行 AI 生成代码”的 Serverless 产品——Lambda MicroVMs 和 Bedrock AgentCore Runtime。它们底层都基于 Firecracker microVM，却处在完全不同的抽象层。本文从定位、架构、计费、适用场景等维度做深度对比，帮助 AI Agent 开发者和架构师做出正确选择。
目录
一、引言
如果你在 2026 年构建 AI Agent，”如何安全执行 Agent 生成的代码”是一个绑不开的问题。Agent 会写 Python 脚本、调用 Shell 命令、修改文件系统——你不可能让它跑在你的业务进程里。
AWS 给出了两个答案：
- Lambda MicroVMs（2026 年 6 月 22 日发布）：一个全新的 Serverless 计算原语，让你用 Dockerfile 打包任意代码，运行在独立的 Firecracker VM 里，最长持续 8 小时。
- Bedrock AgentCore Runtime（2025 年 8 月预览，2026 年 6 月 GA）：一个为 AI Agent 量身定制的托管运行时，内置 LLM 编排、Tool 调用、Memory、身份认证、代码解释器和浏览器沙箱。
两者底层都跑在 Firecracker microVM 上，都提供 VM 级隔离，都支持 8 小时运行时长——表面看它们很相似，但实际上它们解决的问题完全不同。
二、定位差异：计算原语 vs Agent 框架
 |
理解这两个服务的最简单方式：
Lambda MicroVMs 是”砖头”——它给你一台干净的、隔离的、有状态的小型虚拟机，你往里面放什么完全由你决定。它不知道什么是 LLM，不知道什么是 Tool Calling，不关心你跑的是 AI Agent 还是 CI Runner。
AgentCore Runtime 是”精装房”——它假设你要跑一个 AI Agent，于是把 Agent 需要的一切都预装好了：LLM 调用编排、工具网关、长期记忆、OAuth 身份链、可观测性追踪、甚至浏览器沙箱。你只需要写 Agent 逻辑本身。
这个定位差异决定了后续所有的技术决策。 选择哪个服务，取决于你需要的是”一台机器”还是”一个平台”。
三、核心对比表
| 维度 | Lambda MicroVMs | Bedrock AgentCore Runtime |
| 本质定位 | 通用 Serverless 计算原语 | AI Agent 专属托管运行时 |
| 你提供什么 | Dockerfile + 任意应用代码 | Agent 框架代码（Strands/LangGraph/CrewAI） |
| 你得到什么 | 一台隔离的、有状态的 VM + 唯一 URL | Agent 运行环境 + Memory + Tools + Identity + 可观测性 |
| 编程模型 | 任意 HTTP 服务器（Flask/Express/Go…） | AgentCore SDK + 框架适配器 |
| 隔离机制 | 每 MicroVM 独立 Firecracker VM | 每 Session 独立 Firecracker microVM |
| 最长运行时间 | 8 小时（可挂起恢复） | 同步 15 分钟 / 异步 8 小时 |
| 计费特点 | 按 baseline 配置按秒计费；挂起时免费 | 按实际 CPU 消耗按秒计费；I/O 等待免费 |
| 事件驱动集成 | 可通过 Lambda Function 触发启动 | 需 Lambda 中间层做事件桥接 |
| 内置 LLM 编排 | 无 | 内置 |
| 内置 Memory/Tool Gateway | 无 | AgentCore Memory + Gateway |
| Session 管理 | 开发者自行管理生命周期 | 平台自动管理（空闲 15 分钟终止，可配置 60-28800 秒） |
| 协议支持 | 任意（你的 HTTP 服务） | HTTP + MCP + A2A + AG-UI + WebSocket |
| 适合场景 | 代码沙箱、CI Runner、多租户开发环境 | 端到端 AI Agent 生产部署 |
四、深入分析关键差异
4.1 隔离模型与状态生命周期
两者都使用 Firecracker microVM 实现隔离，但状态管理哲学截然不同。
Lambda MicroVMs 把状态生命周期完全交给开发者。你通过 API 显式地启动、挂起、恢复和终止 MicroVM。挂起时，内存和磁盘状态被快照保存；恢复时，所有进程、文件、已安装的包都还在。这意味着你可以构建”用户离开 → VM 挂起 → 用户回来 → VM 秒级恢复”的交互体验，且挂起期间不产生计算费用。
AgentCore Runtime 的状态与 Session 绑定。每个 Session 是一个独立 microVM，默认空闲 15 分钟后自动终止（可通过 idleRuntimeSessionTimeout 配置为 60-28800 秒），终止时内存被彻底清除（sanitized）。这是一个安全优先的设计——AI Agent 处理的可能是敏感数据，Session 结束后不应留下任何痕迹。如果需要跨 Session 持久化上下文，应使用 AgentCore Memory 服务。
关键区别：MicroVM 的状态是”可恢复的长寿进程”，AgentCore 的状态是”用完即焚的安全会话”。选择哪个取决于你对”状态”的需求——是长期保持完整环境，还是安全地处理后销毁。
4.2 编程模型与开发体验
Lambda MicroVMs 的编程模型极其简单：写一个 Dockerfile，暴露一个 HTTP 端口，打包上传。你的应用可以是 Python Flask、Node.js Express、Go HTTP server——任何能监听端口的东西。Lambda 给你一个唯一 URL 和 JWE token 认证机制。这种极简意味着极大的灵活性，但也意味着 Agent 相关的能力全部需要你自己构建。
AgentCore Runtime 提供了完整的 Agent 开发 SDK。通过几行代码，你的 LangGraph 或 Strands Agent 就能获得：自动化的 LLM 调用重试与流式输出、工具调用的 MCP 协议支持、跨 Session 的长期记忆、用户身份的 OAuth 流转、以及开箱即用的 Trace 追踪。代价是你需要遵循 AgentCore 的编程约定和 SDK 接口。
关键区别：MicroVM 是”给你一台机器，剩下的自己搞定”；AgentCore 是”告诉我你的 Agent 逻辑，其他我来处理”。前者适合有自定义基础设施需求的团队，后者适合想快速投产 Agent 的团队。
4.3 计费模型差异（I/O 等待 vs Baseline）
这是两者最具实际影响力的差异。
Lambda MicroVMs 按你配置的 baseline 资源（vCPU + 内存）按秒计费。当 MicroVM 处于运行状态时，无论 CPU 是在满负荷计算还是在等待网络 I/O，你都在付费。好消息是当 MicroVM 被挂起时，计算费用完全停止。
AgentCore Runtime 实现了一种”活跃资源消耗”计费模型（Active Resource Consumption）。当你的 Agent 在等待 LLM API 返回（这在典型 Agent 工作流中占 80%+ 的时间）时，CPU 被认为处于 I/O 等待状态，不产生 CPU 费用。你只为实际消耗 CPU 周期的时间付费。
这对 AI Agent 工作负载的成本影响是巨大的——一个典型的 Agent Session 可能运行 5 分钟，但实际 CPU 活跃时间只有 30 秒（其余时间都在等 LLM 响应）。在 AgentCore 上，你只为这 30 秒的 CPU 付费。对于 I/O 密集型的 Agent 工作负载，AgentCore 的计费模型可节省 70-85% 的计算成本。
4.4 事件驱动与集成模式
Lambda MicroVMs 天然融入 AWS Lambda 生态。你可以用 Lambda Function 作为事件驱动入口（响应 API Gateway、SQS、EventBridge 等事件），然后由 Function 启动或唤醒一个 MicroVM 执行长时间任务。两者共享同一个 AWS Lambda 控制台和 API 体系。
AgentCore Runtime 本身不直接集成 AWS 事件源。如果你需要”收到一封邮件就触发 Agent 处理”，你需要在前面放一个 Lambda Function 或 EventBridge Rule 来接收事件，再调用 AgentCore 的 InvokeAgentRuntime API。这不是缺陷——AgentCore 专注于 Agent 执行本身，事件路由是外层关注点。
4.5 并发与扩展
Lambda MicroVMs 每个 MicroVM 是独立的执行单元，有自己的 URL。扩展方式是启动更多 MicroVM 实例。目前支持 ARM64 架构，单个 MicroVM 最大 16 vCPU / 32 GB 内存 / 32 GB 磁盘，且支持突发扩展到 baseline 的 4 倍资源。
AgentCore Runtime 的并发单位是 Session。默认配额为每账户每 Region 1000 个并发 Session（us-east-1 和 us-west-2），其他 Region 为 500 个。每个 Session 独占一个 microVM，支持最大 100MB 的请求 payload。扩展能力受配额限制，但对于大多数 Agent 应用场景已经足够。
五、选择决策指南
5.1 什么时候选 Lambda MicroVMs？
一句话判断：如果你需要的是”一台隔离的机器来跑代码”，而不是”一个 Agent 运行平台”——选 MicroVMs。
- 你需要一个通用代码沙箱——让 AI Agent 或用户安全地执行任意代码（Python 脚本、npm install、编译 C++），但 Agent 编排逻辑在别处运行。
- 你在构建多租户开发平台——每个租户需要一个完整的、隔离的、可长时间运行的开发环境（如在线 IDE、Jupyter Notebook）。
- 你需要长时间挂起恢复——用户可能离开几小时后回来，期望环境完全保持原样（MicroVM 挂起恢复）。
- 你的工作负载不是 AI Agent——CI/CD Runner、游戏服务器、安全扫描器等也非常适合。
5.2 什么时候选 AgentCore Runtime？
一句话判断：如果你在构建一个”能思考、能行动、能记忆”的 AI Agent 系统——选 AgentCore。
- 你在构建生产级 AI Agent——需要 LLM 编排、工具调用、长期记忆、用户身份等完整的 Agent 基础设施。
- 你想最大化成本效率——Agent 工作流中 80% 的时间在等 LLM 响应，I/O 等待不计费能节省 60%-80% 的计算成本。
- 你需要多协议互操作——Agent 之间通过 A2A 协议通信，工具通过 MCP 协议暴露，前端通过 WebSocket 实时交互。
- 你需要企业级安全——内置 OAuth 流转、Session 结束内存清除、Agent 级身份管理。
5.3 什么时候两者组合？
最佳实践往往是组合使用——AgentCore 做 Agent 大脑，MicroVM 做代码执行手脚。
- AgentCore 运行 Agent 大脑（推理、规划、工具调度），当 Agent 需要”执行一段它自己写的代码”时，调用 Lambda MicroVM 作为安全沙箱。
- Lambda Function 处理事件触发（SQS 消息到达、定时调度），启动 AgentCore Session 执行 Agent 任务。
- Agent 需要的”重计算”（如模型推理、数据处理）跑在 MicroVM 里，而 Agent 的协调逻辑和状态管理留在 AgentCore。
六、组合架构模式：Function + AgentCore + MicroVM 协作
 |
一个完整的生产级 AI Agent 架构可以将三者有机组合：
6.1 第一层：Lambda Function（事件入口）
Lambda Function 负责接收和路由事件。当 API Gateway 收到用户请求、SQS 队列中出现新任务、或 EventBridge 触发定时调度时，Function 在毫秒内响应，完成认证校验和请求预处理后，调用 AgentCore 的 InvokeAgentRuntime API 启动或恢复一个 Agent Session。Function 是轻量级的”门卫”——处理时间通常在 100ms 以内。
6.2 第二层：AgentCore Runtime（Agent 大脑）
AgentCore Session 承载 Agent 的核心推理循环。Agent 接收到用户意图后，调用 LLM 进行规划，通过 MCP 协议使用工具（查数据库、调 API），利用 AgentCore Memory 获取历史上下文。整个过程中，大量时间花在等待 LLM 响应——这些等待时间不产生 CPU 费用。Agent 的每一步决策都通过内置 Trace 记录，供后续调试和审计。
6.3 第三层：Lambda MicroVM（安全执行沙箱）
当 Agent 决定”我需要执行一段代码来验证这个方案”时，它通过 AgentCore 的 Tool 调用机制启动一个 Lambda MicroVM。MicroVM 里预装了 Agent 需要的运行时环境（Python + 常用库），Agent 通过 MicroVM 的唯一 URL 提交代码、获取执行结果。代码在完全隔离的 VM 里运行，即使是恶意代码也无法影响 Agent 进程本身。任务完成后，MicroVM 可以被挂起保留状态，等待下次使用。
6.4 三层协作的价值
Function 提供了事件驱动的弹性入口；AgentCore 提供了 Agent 专属的高层抽象和成本优化；MicroVM 提供了安全的代码执行隔离。每一层做自己最擅长的事情——这就是云原生 AI Agent 架构的最佳实践。
七、计费对比：用具体场景算账
以下计算基于 us-east-1 ARM64 定价，实际费用请以 AWS 官网最新信息为准。
| 服务 | vCPU 单价 | 内存单价 |
|---|---|---|
| Lambda MicroVMs | $0.0000277/vCPU-秒（≈$0.0997/vCPU-时） | $0.0000037/GB-秒 （≈$0.0132/GB-时） |
| AgentCore Runtime | $0.0000249/vCPU-秒（≈$0.0895/vCPU-时） | $0.0000026/GB-秒（≈$0.00945/GB-时） |
7.1 场景：一个代码助手 Agent，每天处理 1000 个用户请求
7.1.1 假设条件
- 每个请求平均 Session 时长：5 分钟（300 秒）
- 每个 Session 中 CPU 实际活跃时间：45 秒（剩余时间等待 LLM 响应）
- 配置：2 vCPU / 4 GB 内存
- Agent 在每个 Session 中调用一次代码沙箱，沙箱运行 30 秒
7.1.2 方案 A：全部使用 Lambda MicroVM 运行 Agent + 代码执行
MicroVM 按 baseline 配置全程计费，运行时间 = 300 秒/Session（2 vCPU + 4 GB 内存的秒单价 = $0.0000701/秒）：
- vCPU 费用：1000 × 300s × 2 vCPU × $0.0000277 = $16.62/天
- 内存费用：1000 × 300s × 4 GB × $0.0000037 = $4.40/天
- 日总计：$21.02/天 ≈ $631/月
- 无论 Agent 在等 LLM 还是在执行代码，都在计费
- 优势：挂起后完全免费，适合间歇性使用
7.1.3 方案 B：AgentCore Runtime 运行 Agent + Lambda MicroVM 作为代码沙箱
AgentCore 的 CPU 计费仅计活跃时间 = 45 秒/Session：
- vCPU 费用：1000 × 45s × 2 vCPU × $0.0000249 = $2.24/天
- 内存费用：1000 × 45s × 4 GB × $0.0000026 = $0.47/天
- AgentCore 小计：$2.71/天（I/O 等待的 255 秒完全免费）
MicroVM 代码沙箱计费 = 30 秒/Session（仅代码执行阶段）：
- vCPU 费用：1000 × 30s × 2 vCPU × $0.0000277 = $1.66/天
- 内存费用：1000 × 30s × 4 GB × $0.0000037 = $0.44/天
- MicroVM 小计：$2.10/天
方案 B 日总计：$4.81/天 ≈ $144/月
成本对比结论：
| 方案 | 日费用 | 月费用 |
|---|---|---|
| A：纯 MicroVM | $21.02 | ~$631 |
| B：AgentCore + MicroVM | $4.81 | ~$144 |
| 节省 | $16.21 | 77% |
成本差异的根源：在方案 A 中，Agent 等待 LLM 返回的 255 秒（300-45）也在产生计算费用；在方案 B 中，这 255 秒完全免费。对于 I/O 密集型的 Agent 工作负载，AgentCore 的计费模型可节省 77% 的计算成本。
7.2 什么时候 MicroVM 反而更划算？
当工作负载是 CPU 密集型（如持续编译、模型推理、数据处理）而非 I/O 等待密集型时，AgentCore 的 I/O 等待免费优势消失。此时 MicroVM 的优势在于：
- 更大的资源上限（16 vCPU / 32 GB）
- 挂起恢复机制对间歇性工作负载更友好
- 突发 4 倍资源能力应对峰值
八、总结
Lambda MicroVMs 和 Bedrock AgentCore Runtime 不是竞争关系，而是互补关系。它们共享 Firecracker 的底层基因，却服务于不同的抽象需求：
| Lambda MicroVMs | AgentCore Runtime | |
| 一句话总结 | 给你一台安全的、有状态的虚拟机 | 给你一个完整的 Agent 运行平台 |
| 核心价值 | 隔离 + 状态 + 生命周期控制 | Agent 基础设施全托管 + I/O 等待不计费 |
| 你的工作 | 构建所有 Agent 逻辑 | 只写 Agent 差异化逻辑 |
最终建议
- 如果你在构建 AI Agent 并想快速投产 → 从 AgentCore Runtime 开始
- 如果你需要通用代码沙箱或非 Agent 工作负载 → 用 Lambda MicroVMs
- 如果你要构建生产级 Agent 系统 → 用 Lambda Function（事件入口）+ AgentCore（Agent 大脑）+ MicroVM（代码沙箱） 的三层架构
行动号召：2026 年，Agent 开发者的选择不再是”用哪一个”，而是”在架构的哪一层用哪一个”。理解每个服务的本质定位，才能把它放在正确的位置。
- Lambda MicroVMs 产品页面 — 开始你的第一个安全沙箱
- Bedrock AgentCore 文档 — 构建你的第一个生产 Agent
- Lambda Functions 入门 — 事件驱动计算的最佳起点
本文基于 2026 年 6 月 AWS 官方文档和公开发布信息撰写。服务定价和配额可能随时间变化，请以 AWS 官网最新信息为准。
────────────────────────────────────────
➡️ 下一步行动：
相关产品：
- AWS Lambda — 无需服务器即可运行代码
- Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台
- Amazon Bedrock AgentCore — 加快代理投入生产的速度
- Amazon EventBridge — 大规模构建事件驱动应用程序
- Amazon SQS — 托管式消息队列
相关文章：
- Lambda MicroVMs vs Lambda Functions：全方位深度对比
- AWS 正式发布 Lambda MicroVMs：面向 AI 时代的无服务器安全代码执行环境
- 基于 Amazon Bedrock AgentCore Runtime 部署 Apache Doris MCP Server为 Quick Suite 等 AI 客户端提供原生数据分析能力
- AI Agent 的迁移与现代化 — 使用 Amazon Bedrock AgentCore 将 OpenClaw 从单机改造为多租户 Serverless 架构 第四篇
- 5 分钟拉起、90 秒自愈、成本 1/8——基于 Firecracker microVM 与 Bedrock AgentCore 的生产级多租户 AI Agent 平台 OpenClaw Pool
- 快时尚电商行业智能体设计思路与应用实践（七）Amazon Bedrock AgentCore Runtime 深度解析和场景分析
- 基于Amazon Quick与Amazon Bedrock AgentCore打造对话式 FinOps助手
本篇作者
AWS 架构师中心：云端创新的引领者探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用
|
 |
