AgentCore runtime V2 快照机制：冷启动优化建议需要反转

传统冷启动建议是延迟导入、缩小初始化，让第一个请求尽快触发实际工作。亚马逊云科技在 2026 年 11 月 13 日发布的工程博客指出，在 AgentCore runtime V2 上这条建议需要反过来：初始化只执行一次并被冻结进快照，推迟到处理器的静态工作则每个新会话都要重新支付。

V2 的机制是：创建或更新运行时，平台启动容器、等待健康检查通过（120 秒内），然后清除操作系统文件缓存、冻结微虚拟机、将内存和磁盘存为快照。此后每个新会话不再拉取镜像和运行初始化代码，而是将快照恢复到新微虚拟机中，进程从冻结点继续执行，导入的库、创建的对象和客户端都已在内存中。

这带来三条直接影响。第一，内存完整恢复：初始化阶段持有的任何数据，包括 RAM 文件系统上的内容，以内存速度从第一次访问起可用。第二，文件读取不延续：快照前文件缓存被清除，初始化时读过的文件在恢复会话中仍需从镜像获取。第三，镜像文件按需加载：第一次读取某个数据块时从快照存储拉取，之后缓存到更靠近宿主的位置。

因此，正确的重构方向是把静态工作移入初始化。创建对象而非仅导入模块，因为对象创建会加载其依赖并保持在活跃内存中。在初始化中创建 boto3 客户端，端点解析和凭据解析随快照恢复，套接字在首次调用时自动重连。将提示词、配置、小型索引等静态数据读入内存对象持有，而非每次请求时从镜像读取。对于无法在进程内持有的文件——如独立运行的 CLI 工具链或浏览器二进制——可以复制至 /dev/shm 等 RAM 磁盘，或使用构建钩子在快照构建期间预热。

但这里有一个必须测量的权衡：初始化中保留在内存中的数据使快照变大，恢复时间随之增加，而且每个会话都要为这部分内存付费。文章明确建议端到端测量变更前后的会话启动时间，确认延迟确实降低而非仅从处理器转移到了恢复阶段。

同时，某些值必须留在处理器中。随机数、时间戳、凭据刷新、动态工具目录和特性开关——这些在初始化中创建会被冻结进快照，导致每个会话携带相同的随机状态或过期的时间基准。文章将这一点与 AWS Lambda SnapStart 的已知陷阱类比，并给出带过期时间的模块级缓存模式作为动态数据的折中方案。

对于交互场景，即使 2 秒的会话启动也偏慢。文章建议在用户打开聊天窗口或应用时即发起预热请求，利用用户输入第一条消息之前的时间窗口让会话就绪。已运行的会话响应约 200 毫秒，而新会话启动约 2 秒——预热将后者隐藏在用户操作延迟中。

需要指出的是，上述性能数字和机制描述均来自亚马逊云科技对自身平台的说明，属于厂商自报数据，尚无独立第三方复现。