AWS 称 AgentCore Runtime V2 用「快照一次、每次恢复」替代逐会话冷启动，目标是让聊天和语音 Agent 突破 2 秒启动门槛
AWS 在其机器学习博客中称，Amazon Bedrock AgentCore runtime 是一个全托管的无服务器 Agent 运行环境：每个会话运行在独立的 microVM 中，无负载时缩到零，按会话实际消耗的资源计费。当 platformVersion 设为 V2 时，运行时不再为每个会话初始化容器，而是准备环境一次、做快照、每个新会话从快照恢复。对聊天和语音体验来说，哪怕 2 秒的会话启动都太慢（原文：”for chat and voice experiences even 2 seconds is too slow”）。
它解决什么问题
据 AWS 博客，Agent 如今承担代码审查、理赔处理等任务，也有许多 Agent 直接面对交互场景——用户在等待第一条响应。在 V1 架构下，AgentCore runtime 每次新会话都要从 Amazon ECR 拉取容器镜像、启动容器、运行初始化代码，然后才能处理第一个请求。镜像拉取占据了大部分时间，冷启动时长随镜像大小增长。对于需要加载本地模型权重、嵌入向量、数据集、浏览器二进制文件或 CLI 工具链的 Agent，这个问题尤其突出。读取大量小文件（例如编译 TypeScript 项目）也会产生同样的效果。
它怎么做
AWS 博客描述了 V2 的启动机制，分为”构建”和”调用”两个阶段。
据 AWS 博客，构建阶段（每次创建或更新运行时执行一次）： AgentCore runtime 在一个新的 microVM 中启动容器，等待第一次健康检查（GET /ping）在 120 秒内返回成功。随后清除操作系统文件缓存以缩小快照体积，冻结 microVM，将其内存和磁盘存储为快照。这意味着每次创建或更新都需要几分钟来构建快照，这是与 V1 的一个区别。
AWS 介绍，调用阶段（每个新会话）： 当新会话到达时，AgentCore 将快照恢复到一个新的 microVM。进程从冻结点恢复执行，导入的模块、对象和客户端都保持原样。镜像中的文件按需加载——每个块在会话首次读取时从快照存储获取，之后缓存到更靠近主机的位置。
该文总结了三个关键事实：进程内存完整恢复，快照时刻持有的任何数据在恢复后立即可用；文件缓存不会延续，因为冻结前已清除，所以初始化阶段读过的文件在恢复后的会话中并不更快；镜像文件在首次读取时才获取。
AWS 博客还称，V2 回收会话未使用的内存，使账单更贴合 Agent 的实际用量。
和 V1 的区别
据 AWS 博客，V1 每个会话都经历完整的镜像拉取和容器初始化，冷启动随镜像大小增长。V2 将这些工作集中到部署时执行一次，代价是每次创建或更新需要几分钟构建快照。已在运行的会话响应时间约 200 毫秒，而新会话启动约需 2 秒。为了突破这个门槛，博客建议在用户打开应用或聊天窗口时就预热会话——在后台发送预热请求，等用户输入第一条消息时会话已在运行。这种方式会为打开但未发送消息的用户消耗一个会话，但较短的空闲超时可以控制成本。
AWS 博客给出的延迟度量建议是，应使用 P90、P99 等分位数或 TM90（取最快 90% 请求的平均值，丢弃最慢的尾部）来报告延迟，而非简单平均值——平均值会掩盖慢请求。AgentCore runtime 通过 Amazon CloudWatch 发布两个指标：Latency（到首字节的时间）和 OverheadLatency（属于平台的部分，如启动 microVM 和恢复快照）。博客建议以生产环境预期的新会话速率进行测试，而非部署后只测几个会话。
AWS 在博客中称，V1 时代的常规冷启动建议是懒加载导入、保持初始化精简。V2 上要反过来做：初始化只运行一次（构建快照时），而推迟到处理函数中的工作会被每个新会话重复支付。具体模式包括：在初始化阶段创建对象和客户端而非仅做导入；将静态数据（提示词、技能前置说明、配置和小索引）常驻内存；在初始化阶段启动长驻辅助进程（如语言服务器或已完成导入的工作进程），使其作为进程内存的一部分随快照恢复。boto3 客户端在恢复后首次调用时会自动重连，但某些网络客户端会先尝试已失效的套接字，可能增加数百毫秒延迟，因此应在快照前关闭这些连接。
据 AWS 博客，V2 还支持 hooks 机制——在容器中暴露一个 HTTP 端点，AgentCore runtime 在构建过程中发送两次 POST 请求：一次在快照前（加载到内存的内容成为快照的一部分），一次在测试恢复后（用于预热恢复会话首先需要获取的文件），两次调用共享 120 秒。
目前的边界
AWS 博客列出了若干约束：/ping 健康检查必须在 120 秒内返回；会话空闲超时默认 15 分钟（可配置为 60 秒到 8 小时），最大生命周期默认且上限为 8 小时；构建钩子的两次调用共享 120 秒，任何非 2xx 响应、连接失败或超时都会导致创建或更新失败且不会重试；钩子端口需在 8000–12000 范围内且不能与平台已用路由冲突。快照中冻结的值在下次部署前不会改变，因此动态数据（工具目录、功能开关、价格表）必须在处理函数中加载，随机数和凭证等也必须在每个会话中重新生成，否则会成为安全问题。
主题分类：AI Agent/基础设施