AWS 推出了 Lambda MicroVMs，这不是又一个普通的函数运行时，而是一个面向“每个用户会话、每个 AI Agent 都需要独立沙箱”的 serverless 计算原语。它把执行单元放进独立的 Firecracker 虚拟机里，强调硬件级隔离、基于快照的快速启动，以及最长 8 小时的状态保留。
这件事之所以值得关注，是因为 AI Agent 正在把后端执行环境推向一个更棘手的问题：代码不是只跑一次就结束，它可能会读写临时文件、安装依赖、调用工具、保留上下文，还可能执行来自用户或模型生成的不可信代码。
它解决的不是“怎么跑函数”，而是“怎么安全地跑会话”
传统 serverless 的心智模型通常是：请求进来，函数启动，处理完退出。Lambda MicroVMs 更像是把一次用户会话或一个 Agent 的工作区装进独立 MicroVM：
- 每个用户会话或 AI Agent 拥有自己的 Firecracker VM。
- 隔离边界下沉到虚拟化层，而不是只依赖进程、容器或语言运行时。
- 通过快照快速启动，避免每次都从零初始化。
- 会话状态可保留最长 8 小时，适合多轮工具调用或交互式任务。
对于 Agent 平台，这个抽象很自然。一个 Agent 可能需要执行 Python、修改文件、运行测试、缓存中间结果。如果多个用户或多个 Agent 共用同一执行环境，安全边界、资源清理和状态串扰都会变得很难解释。
Firecracker 隔离为什么适合 Agent 场景
Firecracker 原本就是为轻量虚拟化和 serverless 场景设计的。相比普通容器，MicroVM 的边界更硬；相比传统 VM，它又更轻、更容易快速启动。
放到 Agent 执行环境里，可以把风险拆得更清楚：
- 不可信代码：用户上传脚本、模型生成脚本、动态安装的依赖，都可以放进独立 VM。
- 状态污染：一个会话里的临时文件、环境变量、缓存，不应该泄漏到另一个会话。
- 多租户边界：平台方不必把所有安全压力都压在语言沙箱或容器运行时上。
- 长任务体验：最长 8 小时状态保留让“多轮执行 + 中间状态”更接近真实开发环境。
但它不是免费的魔法。Reddit 社区分析提到，最低配置成本约为 3.03 美元/天，大约是 Fargate Spot 的 9 倍。这个数字提示我们：Lambda MicroVMs 更适合高隔离、高价值、会话型执行，而不是所有后台任务的默认选择。
可以这样实践：先把 Agent 执行环境设计成“可替换沙箱”
如果你还没有直接使用 Lambda MicroVMs 的公开 API，可以先把系统边界设计出来：业务服务不直接执行代码，而是把任务提交给一个“沙箱执行器”。以后这个执行器可以接 Lambda MicroVMs，也可以先接本地容器、ECS、Fargate 或内部 runner。
下面是一个最小可改造的 Python 示例。它不调用 AWS 的真实 Lambda MicroVMs API，而是演示推荐的接口形状：每个 session_id 对应一个隔离执行上下文，业务层只关心提交代码和取回结果。
# sandbox_client.py
# 假设：/sandbox/run 是你自己的沙箱网关，未来可接入 Lambda MicroVMs。
# 运行前修改 SANDBOX_API 为你的内部服务地址。
import os
import requests
SANDBOX_API = os.getenv("SANDBOX_API", "http://localhost:8080")
def run_agent_code(session_id: str, code: str) -> dict:
response = requests.post(
f"{SANDBOX_API}/sandbox/run",
json={
"session_id": session_id,
"runtime": "python3.12",
"timeout_seconds": 30,
"code": code,
},
timeout=35,
)
response.raise_for_status()
return response.json()
if __name__ == "__main__":
result = run_agent_code(
session_id="user-42-agent-a",
code="""
import platform
print('hello from isolated session')
print(platform.python_version())
""",
)
print(result)
配套的网关请求可以保持非常朴素：
curl -X POST "http://localhost:8080/sandbox/run" \
-H "Content-Type: application/json" \
-d '{
"session_id": "user-42-agent-a",
"runtime": "python3.12",
"timeout_seconds": 30,
"code": "print(1 + 1)"
}'
真正接入 MicroVM 后，网关内部可以做这些事情：
- 按
session_id查找或恢复对应 MicroVM 快照。 - 为每个会话设置 CPU、内存、网络和文件系统限制。
- 执行代码后保存会话状态，直到超过保留窗口。
- 把 stdout、stderr、退出码和产物路径返回给业务服务。
什么时候值得用，什么时候别急着上
Lambda MicroVMs 的价值不在“更便宜地跑任务”，而在“更明确地隔离会话”。如果你的任务是批量转码、普通队列消费、短小无状态 API，Fargate Spot、Lambda 函数或常规容器可能更划算。
更适合考虑 MicroVM 的场景包括：
- AI Agent 需要执行用户代码或模型生成代码。
- 每个用户会话需要保留文件、依赖、缓存或 REPL 状态。
- 多租户隔离是产品卖点或合规要求。
- 你愿意为更强隔离和更简单的安全边界支付更高成本。
落地前建议列一个检查清单：单会话最长会活多久、状态是否必须保留、能否禁止外网访问、依赖安装是否可控、失败后如何销毁环境、成本是否按会话峰值测算。MicroVM 给了 Agent 平台一个更干净的执行边界，但架构上仍然要把配额、审计、网络策略和成本控制补齐。