Amazon Bedrock AgentCore Runtime V2 让冷启动变得可预测，但成本仍需验证

Amazon 推出了 Amazon Bedrock AgentCore Runtime V2，并提出了一项引人注目的主张：无论容器镜像大小介于 200 MB 至 2 GB，冷启动时间都可维持在约两秒。

这一结果挑战了无服务器计算中一个常见的取舍。团队可以将 agent 缩容至零以节省成本，但下一位用户往往需要等待其运行环境启动。保持实例预热能够减少这种延迟，却也意味着要持续保留可能闲置的容量。

Runtime V2 试图同时解决这一权衡的两端。AWS 表示，它通过恢复已准备好的快照，而非重建每一个环境；同时，在会话仍然存活时回收未使用的内存，而不是按照会话此前的内存峰值计费。

这一发布之所以重要，是因为生产环境中的 agent 与传统请求处理程序的行为不同。它们可能等待模型响应、调用工具、处理文件，并在长时间的一系列请求中保留工作状态。围绕短暂 Web 事务设计的运行时，在这些暂停占据会话主要时间时可能浪费资源。

AWS 将 V2 定位为对这种基础设施错配的回应，而不只是又一个 agent 框架。核心竞争在于：基于快照、对使用情况敏感的执行方式，能否胜过为获得可预测性能而始终保持预热或保留峰值分配的环境。

Microsoft 和 Google 已分别针对容器启动延迟提供了自己的方案。Microsoft 使用预热会话池，而 Google 建议使用最小实例数和启动 CPU 加速。Amazon 的新论点是，团队无需永久保持预热容量，也能获得一致的启动表现。

这些数据颇具吸引力，但它们来自 AWS 自己的基准测试。买方仍需要基于工作负载的证据，覆盖实际初始化代码、突发流量、内存压力、区域容量以及总体应用延迟。

Amazon Bedrock AgentCore Runtime V2 实际改变了什么

Runtime V2 改变了 agent 环境执行初始化的时机，以及已分配内存可被计费的持续时间。

Amazon Bedrock AgentCore Runtime 是 AgentCore 内的托管计算层。它在隔离的 microVM 中托管 agent 或工具；microVM 是一种轻量级虚拟机，拥有独立的 CPU、内存和文件系统资源。

AWS 于 2026 年 9 月 18 日发布 V2。开发者可在创建或更新运行时时将 platformVersion 设置为 V2 来选择它。根据当前的运行时架构，V1 仍是默认版本。

首项重大变化涉及初始化。当开发者创建或更新 V2 运行时时，AgentCore 会启动容器并等待其健康检查通过。随后，平台会捕获该运行中环境的预备快照。

未来实例将恢复该快照，而非重复整个启动流程。因此，加载库、获取静态配置或准备模型工件等一次性工作，可以在第一个真实请求到达之前完成。

快照机制本身并非新事物。AWS Lambda SnapStart 同样通过恢复已初始化的执行环境来减少启动延迟。AgentCore 将这一方法应用于存续时间更长、采用自定义容器并支持有状态交互的隔离 agent 会话。

第二项变化涉及内存计量。V1 会一直保留已分配内存直至会话结束，即使 agent 已释放缓冲区或不再访问缓存数据。因而，使用量可能会跟随该会话期间达到的最高内存分配值。

V2 以更小的常驻内存占用启动，并在工作负载实际访问时按需载入内存。AWS 表示，应用程序释放内存或数据变冷后，平台会回收这些内存。

当前的使用规则指出，V2 中的闲置内存会在 120 秒后自动回收。内存计费的最低值为 128 MB，系统开销也会计入测得的使用量。

CPU 此前已遵循面向消耗的模式。当 agent 等待模型、工具、数据库或外部 API 时，若没有后台进程保持活跃，CPU 费用可降至零。V2 将这种弹性更有意义地延伸至内存。

这些变化在单个会话经历截然不同的阶段时最为重要。文档 agent 可能会在解析大文件时分配内存，释放这些缓冲区后，再花数分钟等待模型调用。

在高水位线模型下，解析阶段可能会影响会话余下时间的内存使用。在 V2 下，AWS 表示，临时分配消失后，后续使用量可以下降。

AgentCore 会话仍需要谨慎的生命周期管理。一个 microVM 最长可运行八小时，默认的不活跃超时可更早停止其计算资源。应用程序也必须将持久信息保存在临时会话内存之外。

因此，此次发布并未将 agent 容器变成无限制的持久基础设施。它改变了托管环境的效率和启动行为，同时保留了 AgentCore 的会话边界。

这一区别构成了真正的张力。AWS 承诺提供与预备容量相关的响应能力，同时保留缩容至零执行模式的经济性。

为什么 Agent 工作负载打破了旧有的内存模型

旧模型变得低效，是因为 agent 会话会在计算突发、内存增长和外部等待之间交替，且会话持续时间较长。

传统 Web 请求通常拥有短暂且易于理解的生命周期。它到达后运行应用代码、访问数据库、返回响应，并释放执行环境。

agent 的行为则更像一名临时工作者。它接收目标、调用模型、调用多个工具、下载材料、创建中间文件、等待审批，并在之后恢复执行。

这些阶段对运行时提出了不同要求。工具调用可能让 CPU 几乎处于闲置状态。文档处理可能产生短暂的内存峰值。交互式对话无法容忍启动延迟，而无人值守的任务则更看重成本而非即时响应。

V1 已提供会话隔离、缩容至零能力以及按消耗计费的 CPU 收费。然而，它的内存处理方式会在其有效阶段结束后仍保留分配。

以审查大型代码仓库的编程 agent 为例。它可能加载索引、检查构建输出、保留多项工具响应，然后在等待模型前释放其中的大部分数据。

在原始运行时中，内存峰值仍会影响后续使用量。更长的会话会放大这一后果，因为早期的一次分配可能始终附着于会话的内存占用。

AWS 表示，在调优 V2 时研究了数十亿个会话的分配模式。这一说法表明其拥有广泛的内部遥测数据，但该公司尚未公布相关分析背后的分布、方法论或具有代表性的工作负载构成。

回收冷内存可让计量方式更贴近 agent 不断变化的工作负载。但这也带来了新的运维问题：当 agent 意外再次需要被换出的数据时，这些数据能多快恢复？

AWS 将内存描述为按需加载、在释放后回收，并在变冷后回收。公开发布信息没有给出各类工作负载模式下详细的缺页延迟或阈值。

这一缺失对于拥有大型可复用缓存的 agent 至关重要。回收缓存可以降低测得的内存使用量，但日后重建缓存可能消耗 CPU、增加延迟或重复网络传输。

开发者需要区分真正可丢弃的分配与能够改善后续轮次的数据。较低的内存曲线并不必然代表一个完整工作流更快或更便宜。

这一架构也更加凸显应用程序行为的重要性。能够释放临时缓冲区的软件，才为平台提供回收内存的机会。无限期保留引用的进程，不能期待运行时自行判断这些数据已无必要。

长时间的 agent 会话让这种纪律更具价值。AWS 文档称，每个 microVM 会话都获得隔离的计算、内存和文件系统资源。停止的会话之后可以获得新的计算资源，但除非应用使用持久会话存储或其他持久服务，否则临时状态将会消失。

这种设计保护了用户之间的隔离，但也阻止开发者将进程内内存视为永久知识库。对话记录、学习到的偏好和可复用事实，都需要保存在 microVM 之外的持久存储中。

这一区别对于知识密集型 agent 尤其重要。团队还需要一份可搜索的运营记录，涵盖提示词、源文档、测试结果和运行时变更。维护良好的工程知识库能够将这些上下文保存在单次执行会话之外。

Runtime V2 并未消除这些架构责任。它让临时计算层更具弹性，从而提高了将短暂工作数据与持久组织知识分离的价值。

快照恢复重写了冷启动的权衡

核心改进来自恢复经过精简、已完成初始化的快照；随着容器镜像增大，其大小仍相对稳定。

冷启动是新创建的环境准备好处理应用工作之前的阶段。它可能包括拉取镜像、配置计算资源、启动进程、加载依赖项以及运行初始化代码。

当流量在服务已缩容至零后到达时，冷启动尤为明显。当现有环境无法处理每个新会话的突发流量时，也会出现冷启动。

大型 agent 容器会让问题更加严重。它们可能包含语言运行时、浏览器依赖、agent 框架、文档解析器、机器学习库和内部工具。

Runtime V2 改变了这一流程。AgentCore 会在运行时版本准备就绪时初始化环境，捕获其状态，并为未来实例恢复该状态。

AWS 表示，平台还会移除恢复后的实例不需要的缓存和临时内存。这种精简旨在防止快照大小随着大型容器的完整常驻内存占用而增长。

该公司的发布基准测试在 V1 和 V2 上，针对每个 agent 发起了 5,000 次冷调用。测试覆盖了默认账户配额下的五种镜像大小。

对于从 200 MB 到 2 GB 的镜像，V2 的 P75 冷启动延迟约为两秒。P75 表示，75% 的测得启动在报告时间或更短时间内完成。

在同一项 AWS 测试中，V1 的表现不同。其 P75 结果从最小镜像的大约 5.4 秒，上升到最大镜像的接近 30 秒。

这些数字使其机制比单纯的百分比提升更值得关注。AWS 声称，在测试范围内，镜像大小不再是恢复延迟的重要驱动因素。

该基准测试还使用了一个 echo 应用，其代码在 P75 时约需 34 毫秒运行完成。该设置隔离了基础设施启动时间，但并不模拟复杂 agent 的完整执行路径。

真实的 agent 往往会在每次模型调用上花费数秒。它们还可能在环境准备就绪后联系远程工具、检索上下文、验证用户身份，或建立网络连接。

两秒的平台启动时间，并不意味着两秒就能得到答案。它意味着，在 agent 代码收到首个请求之前，基础设施带来的延迟更小且更可预测。

这种可预测性的重要性可能高于平均值。当启动延迟维持在较窄范围内时，产品团队可以更有把握地设计加载状态、超时机制和首个 token 的预期。

AWS 建议在用户打开界面时就启动会话，而不是等到对方提交第一个提示词。欢迎语和输入时间随后可以掩盖大部分剩余的启动等待时间。

这种策略很实用，但也会改变需求结构。打开界面可能会创建从未收到消息的会话，因此团队应衡量被放弃的会话和不必要的环境创建。

快照也带来了部署方面的考量。在快照之前捕获的初始化状态，不应包含已过期的凭证、不安全的随机性或用户专属状态。

静态配置可能很适合纳入快照。时效性密钥和每会话身份应通过对恢复安全的机制获取。健康检查也必须反映环境确实已准备就绪，而不只是某个网络端口正在监听。

因此，快照模型将部分工作从请求时转移到了部署时。团队获得了更快的实例创建速度，但必须审查哪些内容成为被捕获状态的一部分。

AWS 正在挑战预热池模式

Amazon 的竞争主张并不只是更快的容器；而是在不要求每个团队为永久预热容量买单的情况下，提供稳定的启动速度。

云服务提供商已经提供多种降低冷启动延迟的方法。大多数方案以闲置资源、运维调优或应用限制，换取更快的响应。

Microsoft 的 Azure Container Apps 提供了动态会话。它们使用预热环境池，可在数毫秒内分配隔离会话。

这种模式适合代码解释器和需要一次性沙箱的工作负载。它的速度来自于在请求到来前就已准备好可用环境。

Google Cloud Run 采用更广泛的容器方案。开发者可以配置最小实例数以保持容器预热，启动 CPU 增强功能则可加速初始化。

保留最小实例可降低冷启动风险，但闲置实例会增加成本。启动 CPU 增强可改善初始化路径，但并不能免除加载和启动应用的需求。

Amazon 的 V2 设计处于不同的位置。它只准备一次运行时快照，剥离不必要的状态，并在会话到来时恢复隔离实例。

这种比较并非绝对。预热池可以提供低于 AWS 报告的约两秒 P75 结果的分配延迟。在需求可预测时，它们还可提供更明确的容量下限。

当流量具有间歇性时，快照能保留更强的按需缩容至零经济性。当一个团队拥有许多长期闲置、但在被调用时必须稳定响应的 agent 时，其价值会更高。

这场竞争反映了一个长期存在的 serverless 问题：客户应为保持容量就绪付费，还是平台应让即时创建足够可预测，从而使预热容量成为可选项？

Agent 工作负载让这个问题更加尖锐。一家公司可能运行数百个专用 agent，但任何时刻只有一小部分在处理任务。保持每个环境预热会浪费容量。

突发流量则带来相反的担忧。如果大量会话同时启动，平台必须快速恢复快照，同时不能引入并发性能惩罚。

AWS 表示，无论并发量如何，V2 都能保持一致的冷启动延迟。不过，已发布的基准测试说明强调了镜像大小和默认配额，并未披露每个并发级别或区域条件。

评估 AgentCore 的团队应比较完整的服务级目标，而非单一启动数据。实用指标包括尾延迟、到首个模型 token 的时间、恢复后的缓存行为、启动失败率，以及流量突然激增时的性能。

他们还应比较总资源消耗。预热池具有可见的闲置容量，而基于快照的服务可能将成本隐藏在恢复、内存分页、网络或部署变更后的重复初始化中。

可移植性仍是另一项因素。AgentCore 接受容器化应用，并支持包括 LangGraph、CrewAI 和 Strands Agents 在内的框架。不过，其运行时控制、会话 API、身份层和计费模型均为 AWS 专有。

Microsoft 和 Google 同样鼓励与各自的身份、监控、存储和 AI 服务集成。因此，竞争决策并不止于冷启动。

已经在某一家云上完成标准化的企业，可能会比基准测试优势更看重运维一致性。构建延迟敏感型 agent 平台的团队则可能直接测试每种运行时。

AWS 仍获得了一项重要的销售论点。V2 使其能够声称，缩容至零不再意味着启动延迟会随容器镜像增大而上升。

如果独立工作负载复现这一结果，云服务买家将期待竞争平台解释：对于类似应用，为何预热池或最小实例仍然必要。

基准测试很强，但范围有限

AWS 展示了可信的基础设施改进，但尚未证明其能为所有生产 agent 提供更低的总成本或可预测的应用延迟。

第一项限制在于来源独立性。AWS 设计了运行时、选择了测试配置、执行了基准测试，并发布了结果。

随附的测试代码让客户可以在自己的账户中复现实验。这很有用，但可复现性仍取决于区域、配额、容器设计、流量形态以及每次运行的时机。

第二项限制是百分位数的选择。P75 比平均值提供了更好的视角，但延迟敏感型服务通常围绕 P95 或 P99 结果进行规划。

稳定的两秒 P75 可以与较慢的尾部事件并存。该公告并未提供评估严格面向用户目标所需的完整分布数据。

第三项限制是工作负载的简单性。echo 测试有助于隔离平台启动，但生产容器会执行更多初始化并建立更多外部连接。

快照捕获可以固化一部分初始化过程。但它无法保证每个数据库连接、凭证交换、网络路由或外部依赖在恢复后都能立即使用。

第四个问题是成本解读。AWS 表示，V2 的资源费率高于 V1，但大多数 agent 的内存消耗应会显著降低，从而降低总账单。

这是公司的预测，而非普遍结果。一个内存稳定、很少释放分配的 agent，可能只能获得有限节省，却需支付更高的 V2 费率。

具有临时内存峰值的 agent 则更有理由采用它。当大型缓冲区早早消失、后续会话的大部分时间都维持在较小内存占用时，节省应会改善。

团队应以相同的请求轨迹测试两个版本。他们应按秒记录内存使用量、CPU 消耗、会话时长、恢复延迟、模型成本、存储成本和网络传输。

计费遥测数据同样需要谨慎对待。AWS 表示，由于聚合和对账，监控数据可能存在延迟，并且可能与权威计费记录不同。

第五项担忧是缓存抖动。如果 V2 回收了 agent 很快又需要的数据，工作负载可能要额外花时间重建这些数据。

AWS 的 120 秒空闲回收规则提供了一个可见阈值，但并未完全解释每种内存类别的行为。开发者应测试跨越该阈值的轮次间隔。

第六项担忧涉及快照正确性。应用通常会在启动期间初始化随机数生成器、凭证、网络客户端、临时文件和后台线程。

恢复后的进程不得在隔离会话之间复用不安全状态。团队应验证其库在恢复后的行为，并确保每会话身份在快照边界之后才会传入。

AgentCore 提供隔离的 microVM，但应用仍负责用户到会话的映射。客户端后端必须阻止某个用户提供或复用另一个用户的会话标识符。

运维故障仍有可能发生。配额、区域容量、不健康的容器、有问题的健康检查以及下游服务限制，都可能主导用户体验。

这些问题都不会否定 V2 的基准测试。它们界定了有前景的平台结果与生产决策之间的差距。

正确的结论是有条件的。V2 对流量突发、镜像较大、初始化昂贵、内存峰值暂时存在，以及长期等待模型或工具响应的 agent 尤其有吸引力。

内存使用稳定、需求长期活跃、使用专用处理器或有严格亚秒级要求的 agent，则需要更广泛的比较。AWS 自身也在为其中部分工作负载准备更大的计算选项和基线承诺。

决定 V2 是否胜出的三个信号

接下来的考验在于：客户的测量结果是否能在 AWS 受控基准测试之外，确认稳定的启动延迟、更低的总账单和安全的快照行为。

第一个信号是独立延迟结果的分布形态。开发者应发布多个区域和流量模式下的 P50、P75、P95 和 P99 冷启动数据。

镜像大小应继续成为这些测试的一部分，但并发性同样重要。一项有用的评估应在运行时已缩容至零后，突然启动一波波隔离会话。

如果尾延迟会随着镜像大小和并发量增长仍保持稳定，AWS 的核心主张就会大幅增强。大型容器将不再迫使团队维持备用环境运行。

如果 P95 和 P99 结果波动很大，两秒 P75 的标题数据将缺乏更多运维价值。拥有交互式 agent 的团队仍需要预热容量或积极地预创建会话。

第二个信号是完整会话的实测成本。V2 更高的资源费率意味着，经济结果取决于运行时实际回收了多少内存。

团队应回放具有已知阶段的工作负载。一个有代表性的测试可能包括：解析大型文档、释放其缓冲区、执行数次模型调用、等待超过 120 秒，然后恢复执行。

如果计量内存在解析阶段后下降并保持较低水平，V2 就支持 AWS 的成本论点。如果消耗量仍接近先前峰值，预期节省就会减弱。

比较不应仅包括 Runtime 费用。模型推理、可观测性、存储、网络传输、容器存储、浏览器会话和工具服务都可能主导最终账单。

这种更广泛的视角可避免将小幅运行时节省呈现为显著的应用层面降幅。它还会揭示更快启动是否鼓励团队创建不必要的会话。

第三个信号是 AWS 是否交付其列为即将推出的能力。路线图包括承诺基线折扣、更大的计算和存储资源、x86 microVM 支持、更强的生命周期控制，以及会话范围的身份认证。

每一项都触及当前的边界。更大的环境可扩大符合条件的工作负载范围。x86 支持则能降低那些难以迁移至其他架构的依赖项的迁移阻力。

挂起和恢复控制将帮助智能体跨越单一计算生命周期持续运行。范围明确的身份机制则可厘清：在无人主动监督时，无人值守智能体能够访问哪些资源。

如果 AWS 能以清晰的文档和稳定的行为交付这些能力，Runtime V2 将成为一个更广泛的平台，而不只是针对冷启动优化的产品。

延期将暴露当前版本的局限。一些持久化、专用或无人值守的工作负载，仍需要其他 AgentCore 计算选项或外部基础设施。

开发者可以从受控的 V1 至 V2 测试开始。应保持智能体代码、模型调用、流量追踪、区域和可观测性设置不变。

决策应基于五项输出：启动时间分位数、会话失败率、内存使用随时间的变化、完整工作流延迟，以及最终云账单。

交互式产品还应测试 AWS 的早期会话策略。在用户打开聊天窗口时启动环境可以掩盖启动时间，但被放弃的会话必须在分析中保持可见。

生产环境中的智能体越来越多地将时间花在等待、保留状态和协调工具上，而非持续执行 CPU 工作。这使得传统容器的经济模型并不适合许多工作负载。

Amazon Bedrock AgentCore Runtime V2 提供了一个技术上连贯的答案。它一次准备工作，恢复更小的快照，并会随着会话需求下降而释放内存。

剩下的问题是实证性的：Amazon Bedrock AgentCore Runtime V2 是否能在您的容器、流量突发、依赖项和安全控制条件下保留这些优势？

在两个平台版本上运行相同的工作负载，保留完整的延迟分布，并在账单核对后检查费用。应由这些证据决定是否迁移，而不是发布公告的标题。