Agent第一次响应慢，不能笼统归因于"大模型"。平台拉起容器、加载依赖和初始化工具，也可能占掉十几秒。AWS新一代AgentCore运行时把初始化后的环境做成小快照，并按需加载、回收内存。开发者真正该学的，是把平台启动、模型推理和工具执行分开测量。
新运行时改变了什么
AWS在9月18日发布Amazon Bedrock AgentCore Runtime V2。官方称，旧运行时会让会话占用过的内存保持在峰值，直到会话结束；新版本从较小常驻内存开始，按访问需要调入页面，并回收已释放或变冷的内存。创建或更新运行时时，平台先启动容器、等待健康检查、完成一次性初始化，再保存可恢复快照。
在官方测试中，一个不调用模型和工具的空echo Agent，被从美国西部EC2客户端经公网调用到美国东部。每个版本、每种镜像大小各进行5000次冷调用。V2在200MB到2GB镜像上的P75冷启动约为2秒；旧版则从约5.4秒增长到接近30秒。来源：AWS技术文章和AgentCore开发者指南。
技术原理：恢复工作状态，而非重做启动
普通容器冷启动像每天进办公室后重新装软件、登录系统、打开项目；快照恢复像从已准备好的桌面继续工作。类比的边界是，快照不能替你恢复所有外部状态：数据库连接可能过期，短期令牌可能失效，随机数、时钟和远程句柄也需要在恢复后重新校验。
V2的关键不是单纯压缩镜像，而是把镜像体积与每次启动需要恢复的工作集解耦。一次性导入、模型工件与静态配置在创建快照前完成；短命缓存和无关内存被剥离。新实例恢复的是继续执行所需的小状态，而不是完整驻留内存。
最小实践：先算改善倍率
下面的纯Python脚本把官方图中的近似P75数值作为输入，只做比例计算，不伪装成真实AWS压测。无需第三方依赖，保存为cold_start_compare.py后运行python cold_start_compare.py：
python
images_mb = [200, 500, 1000, 1500, 2000]
old_p75_s = [5.4, 8.9, 15.6, 22.3, 29.7]
new_p75_s = [2.0, 2.0, 2.1, 2.0, 2.1]
rows = []
for size, old, new in zip(images_mb, old_p75_s, new_p75_s):
saved = old - new
speedup = old / new
rows.append((size, saved, speedup))
for size, saved, speedup in rows:
print(f"{size:4d} MB: save {saved:4.1f}s, {speedup:4.1f}x faster")
avg_saved = sum(row[1] for row in rows) / len(rows)
print(f"average saved: {avg_saved:.1f}s")本次任务已用Python 3实际运行，五档输出的加速倍率约为2.7、4.5、7.4、11.2和14.1倍，平均节省约14.3秒。数值来自官方图表的近似读数，只适合帮助理解趋势；它不等于你的区域、网络、镜像与并发结果。
正式迁移时，在创建或更新runtime时把platformVersion设为V2，再用相同镜像、相同客户端地区、相同冷调用定义做A/B测试。还要记录P50、P75、P95与失败率，不能只取一次最快结果。
更可靠的实验要把冷调用定义写进脚本：每轮创建全新会话，等待多久算冷，是否预先建立网络连接，以及客户端是否复用域名解析和加密连接。先用echo Agent测平台底噪，再逐层加上模型、一个只读工具和真实工作流。若每次加一层都保存时间戳，就能知道2秒优化最终是否被8秒模型调用或慢数据库掩盖。
成本测量同样不能只看单价。应同时记录每会话的内存时间曲线、空闲间隔、任务持续时间和并发峰值。短而稀疏的任务可能从按实际占用回收中获益最大；持续运行并保持大工作集的任务，节省可能小于预期。把至少一周真实轨迹回放到测试环境，比用整齐的固定间隔请求更接近生产。
常见误判与适用边界
第一，把总首响都算作冷启动。官方echo Agent自身P75执行约34毫秒，而生产Agent的模型循环可能占几秒甚至更久；必须打分段时间戳。第二，以为大镜像从此没有代价。镜像构建、上传、漏洞扫描和首次快照创建仍受体积影响。第三，把内存回收理解成应用无需释放对象；代码长期持有引用，平台无法凭空知道缓存可丢弃。
第四，提前打开会话虽可在用户输入时预热，但会增加无效会话与隐私边界，不能对所有页面访问都静默启动。第五，官方基准跨区且来自供应商，不是独立复现；上线前仍需按自己的区域与配额测量。
它适合突发、间歇、长短不一且要求scale-to-zero的Agent。持续满载、内存稳定的服务则应比较即将提供的基线定价与自管容器，不能只看单次冷启动。运行时优化的价值，不是让模型更聪明，而是把与任务无关的等待和闲置成本变得可预测。
迁移检查表：固定镜像摘要；区分冷、暖调用；记录平台、模型、工具三段时间；验证快照恢复后的凭据和连接；监控每会话内存曲线；最后再比较账单。
你的Agent首轮等待里，平台启动、模型调用和工具调用分别占了多少？
关注「蜗牛聊AI」，一起看懂技术变化背后的真正机会。
本文首发于 java4u.cn，转载请注明出处。