AWS发布Bedrock AgentCore runtime V2：快照复用初始化环境以加快会话启动
AWS机器学习博客作者Evandro Franco介绍，AgentCore runtime将platformVersion设为V2后，会在创建或更新运行时构建一次快照，新会话直接恢复该快照，不再为每个会话重新初始化容器；博客同时给出四种把工作移出首个请求的做法及相应限制。
AI解读：AWS官方博客称，AgentCore runtime的V2模式在创建或更新运行时启动容器、等待首次健康检查（GET /ping，须在 120 秒内到达），随后清空操作系统文件缓存、冻结microVM并保存内存与磁盘快照；新会话恢复该快照继续运行。
据博客，V2下会话启动时间更快且更稳定，平台还会回收会话未使用的内存；代价是每次创建或更新运行时需多花几分钟构建快照。
博客建议先用CloudWatch指标区分平台开销（OverheadLatency）与代码耗时（Latency），再决定优化方向；作者称V2上初始化时间不计入请求延迟，也不出现在这些指标中。
博客列出四类做法：切换到V2并在app.run() 前完成初始化、为大文件/CLI/浏览器加构建钩子、在用户打开应用或聊天窗口时后台预启动会话，以及对应的测量方式。
博客提醒快照会把init时创建的对象复制到每个会话：随机数、密钥、当前时间等动态值必须在handler中生成，网关工具目录、功能开关、价格表等需在handler加载并设缓存过期；会话默认空闲超时 15 分钟、最长生命周期 8 小时。
以上均为AWS博客作者的技术说明与建议，未给出普适性的效果对比数据或客户案例。
AWS机器学习博客发布文章，介绍Amazon Bedrock AgentCore runtime的一个新变化：当platformVersion设为“V2”时，平台不再为每个会话初始化容器，而是在创建或更新运行时把初始化好的环境保存为快照，供每个新会话恢复。文章作者为Evandro Franco。
博客称，V2下会话启动更快、更一致，平台还会回收会话未使用的内存，账单与实际用量对应；对多数agent而言，切换到V2即可，但部分agent需要重构代码才能获得全部收益。
V2如何启动一个会话
按博客描述，AgentCore runtime为每个会话分配独立的microVM。V1每次都要从Amazon ECR拉取容器镜像、启动容器并执行初始化代码，镜像拉取占主导，因此冷启动随镜像体积增长。
V2把这项工作只做一次：创建或更新运行时，平台在全新microVM中启动容器，等待首次健康检查（GET /ping）在 120 秒内返回，然后清空操作系统文件缓存以缩小快照，冻结microVM并把内存和磁盘保存为快照。新会话到来时，快照被恢复到新的microVM，进程从冻结处继续，导入的模块、对象和客户端仍在原处。
- 作者称，每次创建或更新运行时因构建快照需多花几分钟。
- 文中“初始化”指 /ping报告健康前的全部工作；使用AgentCore Python SDK时即app.run() 之前的一切。
- 文件按需从镜像加载：会话首次读取某个块时才从快照存储拉取。
- 内存完整恢复；文件缓存不保留，因此init期间读过的文件不会让恢复后的会话变快。
先测量，再优化
博客认为agent应用的延迟不是单一数字：一部分花在平台准备会话上，另一部分花在代码里的模型调用、工具调用和流式返回上，两种问题要用不同方式解决。AgentCore runtime在CloudWatch的AWS/Bedrock-AgentCore命名空间发布两个指标：Latency为首字节时间，OverheadLatency为平台开销（如启动microVM、恢复快照）。
- 新会话上OverheadLatency高，说明时间花在会话启动，可考虑提前启动会话。
- 同一会话中首个请求明显慢于第二个，说明本应在init做的工作落在了handler里。
- 作者建议报告P90、P99或TM90等分位数/截尾均值，普通平均值会掩盖慢请求。
- 应按生产环境的新会话速率测试，而不是部署后只测少量会话。
构建钩子解决init覆盖不到的文件
对CLI或浏览器二进制这类在init期间读取后即消失的东西，博客给出构建钩子：在容器中暴露一个HTTP端点，AgentCore runtime在构建运行时期间向它发两次POST。第一次在快照前、agent报告健康之后，此时载入内存的内容会进入快照；第二次在单独的microVM上测试恢复快照之后，此时读取的文件决定恢复会话首先拉取什么，但不会被快照。
请求头X-Amzn-Bedrock-AgentCore-Runtime-Warmup-Type区分两次调用（memory与disk），两次调用共享 120 秒。博客称，只有返回 2xx才算完成，其他响应、连接失败或超时都会导致创建或更新失败且不重试。钩子仅适用于V2运行时，通过hooksConfiguration配置；UpdateAgentRuntime会整体替换钩子配置。
- 钩子的端口可选，默认使用agent的服务端口，若指定须在 8000 到 12000 之间且未被平台保留。
- 路径不能与该端口上平台已用的路由（如POST /invocations、GET /ping）重复。
快照中不能留下的值
博客指出，init期间创建的一切都会冻结进快照并复制到每个会话，对多数对象这正是目的，但随机值、密钥、当前时间、计时器等若在init生成，会让各会话完全相同，随机值还构成安全问题。会话最长可运行 8 小时，缓存需设置过期。
作者还提醒限制条件：会话在空闲超时（idleRuntimeSessionTimeout，默认 15 分钟，可设 60 秒至 8 小时）、达到最长生命周期（默认及上限 8 小时）或被手动停止时结束。若要实现亚秒级响应，需在用户发出首个请求前就启动会话，博客列举了预启动等做法但文章在示例处截断。
- 随机数、nonce、密钥应在handler中用secrets、os.urandom() 或uuid.uuid4() 生成。
- 网关工具目录、功能开关、价格表在handler加载，并在模块级缓存，例如 300 秒后刷新。
- 自己获取的凭据和令牌需按过期时间刷新。
- 已运行的会话响应约 200 毫秒，而作者举例新会话启动约 2 秒，聊天和语音场景因此需要提前启动。