AWS 升级智能体运行时与数据隔离

Agent 跑进生产环境后，难题不只是模型能不能完成任务，还包括它执行代码时如何隔离、等待模型时怎么计费，以及任务结束后数据留在哪里。AWS 这次更新 AgentCore runtime，集中处理的就是这些问题。

官方给出的变化是：会话启动最高快 15 倍，计算资源扩到原来的 4 倍，多轮交互场景的会话内存消耗最多减少 68%。这些数字值得关注，但各自衡量什么、适用于什么负载，比数字本身更影响选型。

Agent 跑得越久，为什么越需要独立运行环境

原文引用 METR 的观察：前沿 Agent 能独立完成的任务时长，大约每 4 个月翻一倍。McKinsey 的数据则显示，正在扩大 AI Agent 应用规模的大型企业占比，从一年前的 27% 升至 40%。

任务变长，执行环境承担的责任也变了。Agent 会运行代码、操作浏览器、读取敏感数据，并代表用户执行动作。一次会话中拿到的凭证、生成的文件和工具返回结果，都可能影响后续操作。

AgentCore runtime 是 Amazon Bedrock AgentCore 的托管计算层。它的隔离单位是会话：每个会话运行在独立、具备硬件隔离的 Firecracker 微虚拟机（MicroVM）里，并拥有自己的身份、策略和审计记录。

对程序员而言，可以把它理解为：给每次 Agent 任务分配一个独立工作间，同时管理这个工作间能访问什么、做过什么。

传统方案容易卡在资源准备上。提前准备环境，空闲时也消耗资源；收到请求后再创建环境，又会增加冷启动延迟。并发从几个会话涨到数千个时，自建沙箱还要处理容量、调度和回收。

不过，基础设施并不包办 Agent 治理。原文引用 Deloitte 数据称，只有 15% 的组织已经规模化运行经过编排的多 Agent 系统，70% 表示尚不能信任并有效治理自己的 Agent。这些数据说明问题普遍存在，不能直接证明购买托管运行时就能解决它们。

启动更快、资源更大，哪些数字可以拿来参考

新版会话的资源上限扩至此前的 4 倍，最高支持 8 vCPUs、32 GB 内存，以及最大 10 GB 的容器镜像。官方宣称，会话启动时间低于 2 秒，不受镜像大小和并发量影响，启动速度最高提升 15 倍。

这些能力对应的是具体负载：大型代码库编译、浏览器驱动流程，以及本地模型推理。对于需要安装构建工具、启动浏览器或执行测试的编码 Agent，更大的会话资源有实际意义。

但「最高快 15 倍」和「低于 2 秒」不是同一种指标。前者是相对旧版的最佳提升，后者是启动时延声明。原文没有披露完整测试方法、并发范围和启动计时边界，也没有说明它是否包含业务初始化与首次工具调用。

运行环境启动快，不等于用户拿到任务结果也同样快。

原文中更有参考价值的是 Mission Cloud 对两个版本的初步比较：同一工作负载下，推理请求冷启动快 35%，健康检查启动快 77%，实测每次调用的运行时成本降低 17%。这组数据区分了请求类型，也明确是在比较运行时版本。

Zuora 则称，在不少用例中，每次调用的内存占用下降约 60%，同时能在延迟保持稳定的情况下处理更多流量。

这些是客户提供的测量结果，但缺少完整配置和可复现步骤。可以把它们作为试用线索，不能直接当成自己项目的预期收益。Coinbase、Rescale 等客户关于弹性扩展和减少运维工作的描述，则主要是使用反馈，没有给出量化对照。

少付等待的钱，还要管住任务读写的数据

Agent 的资源曲线与普通计算任务不同。它可能短时间密集执行代码，接着等待模型、工具或人工决策。如果整个会话一直按资源峰值占用计费，等待越多，浪费越明显。

新版 runtime 会在 Agent 释放内存后的几分钟内回收内存，空闲 Agent 可以缩容到零。对于轮次之间有自然停顿的多轮 Agent，官方称每个会话的内存消耗最多减少 68%。

这里要分清释放与回收：应用先不再需要那部分内存，平台才能回收。原文没有解释不同语言运行时、垃圾回收机制和内存缓存会怎样影响这个过程。

最多减少 68% 的会话内存消耗，不能直接读成总账单降低 68%。

对于持续运行的 Agent，AWS 提供 committed baseline pricing：为每个会话设定内存基线，按基线收取最低费用，按需最多突增到基线的 4 倍。官方称其采用 AWS Lambda MicroVM 费率，但原文没有列出具体价格。它提供的是另一种容量与费用安排，是否划算仍取决于实际负载。

另一项变化是文件系统。Agent 现在可以动态挂载文件系统并保存工作成果，例如通过 FUSE 支持挂载 Amazon S3 bucket。FUSE 可以让应用通过文件系统接口访问这类存储。

AWS 希望把数据访问也纳入会话的身份、策略和审计控制，减少团队自行拼接数据进出规则的工作。对于编码 Agent，这涉及拉取的代码、测试产物，以及后续任务需要读取的文件。

但这里有明确的能力边界：原文把「通过带会话标签的凭证，将每个会话绑定到专属存储文件夹」列为到 re:Invent 时实现的计划。因此，当前支持挂载存储，不能直接等同于已经具备这项会话目录绑定能力。

原文也没有交代空闲缩容后的状态保留、恢复细节，以及挂载文件系统的一致性和异常恢复行为。这些都需要在实际评估时补齐。

我的判断

我赞同这次更新的方向。执行不确定代码的 Agent，需要清晰的会话隔离；等待时间长、资源峰谷明显的任务，也适合更细的资源回收机制。把身份、存储访问和审计一起考虑，比只讨论沙箱启动速度更贴近生产需求。

但原文是一篇产品发布文章。它提供了旧版与新版的部分客户对照，没有给出与自建 Firecracker、容器沙箱或其他托管方案的完整比较。关于更容易上线、更省运维的结论，主要仍是客户经验之谈。

隔离也有职责边界。独立 MicroVM 能帮助限制会话之间的影响，但如果给某个会话的凭证本来就能访问过多数据，隔离环境不会自动纠正权限设计。Agent 是否应该执行某个动作，也仍需要业务规则约束。

对于只调用模型和几个受控 API 的简单服务，这套运行环境未必是最先要解决的问题。对于要跑构建、测试、浏览器和用户代码的 Agent，它更值得评估。国内团队还需要确认目标 AWS Region、数据位置与现有系统的网络路径；原文仅说明已在北美、南美、欧洲和亚太的 AWS Regions 上线，没有列出完整区域清单。

能拿来做什么

• 如果正在做前端或 Node 编码 Agent，可以用一条真实流程评估新版：准备仓库、安装依赖、构建、测试、保存产物，分别记录环境启动时间和任务总耗时，避免只测一个健康检查接口。
• 如果 Agent 经常等待模型或人工确认，可以测量等待阶段的内存占用，以及释放内存后平台的实际回收时间，再比较按需使用与 committed baseline pricing 的费用。
• 如果需要跨轮次保存代码和产物，可以先明确会话目录、访问凭证与清理规则，再验证 S3 挂载的读写行为；不要把计划中的会话目录绑定当成当前保障。
• 如果正在决定是否自建沙箱，可以把隔离、启动、并发调度、存储权限和审计放在同一份评估里。原文没有替代方案对照数据，这部分需要用自己的工作负载补上。