发生了什么
亚马逊云科技 9 月 18 日宣布，Amazon Bedrock AgentCore 内部的无服务器微虚拟机计算层 AgentCore Runtime 推出第二代版本并正式可用。新版本解决的是智能体服务化的两个成本变量：启动延迟与内存计费方式。在冷启动方面，新 Runtime 会先把智能体运行环境准备一次并制作快照，此后每个新实例都从该快照恢复，而不是重复执行完整的启动序列，因此启动时间不再随镜像体积增长。
- 冷启动：官方测试显示，200MB 至 2GB 的容器镜像 P75 冷启动为 1.9 至 2.0 秒，上一代 V1 在同一区间为 5.4 至 30 秒。
- 内存管理：每个会话从小内存配置起步，按负载需求按需分配，闲置 120 秒后未使用的内存被回收，而不是保留到会话结束。
- 计费口径：从「按峰值分配」改为「按实际用量」，但单位消耗费率上调，CPU 从每 vCPU 小时 0.0895 美元升至 0.1276 美元，内存从每 GB 小时 0.00945 美元升至 0.0169 美元。
- 可用区域：美东（弗吉尼亚北部、俄亥俄）、美西（俄勒冈）、欧洲（爱尔兰）、亚太（东京）五个区域，启用方式是在创建或更新运行时把 platformVersion 设为 V2。
计费变化不等于降价
新 Runtime 被不少转述读作一次降价，这个结论需要限定条件。弹性内存管理改变的是计量基准而非费率：AWS 未公布节省比例，也未给出示例账单，实际节省完全取决于负载形态。如果智能体在整个会话期间内存占用平稳，不会触发闲置回收，节省为零；只有在会话出现内存峰值后闲置 120 秒以上的场景里，回收才会生效。而短会话、高并发的典型对话式智能体，单轮交互往往只有几秒，基本无法触及 120 秒的回收窗口，在这种情况下费率上调反而可能推高账单。
企业技术团队应当注意什么
这项变更的另一个特征是它不会自动生效。新版本描述的是「一个可选项已经可用」，而不是全区队升级：所有既有 AgentCore 运行时会继续跑在 V1 上，除非运维人员主动修改 platformVersion，AWS 也未弃用 V1、未给出任何迁移期限。这意味着公告发布与实际采用之间存在数月量级的落差，团队应按工作负载形态分别决策，而不是整批切换。
- 适合切换 V2 的场景：会话中会出现内存峰值且随后长时间空闲、镜像体积较大、对启动延迟一致性有硬性要求。
- 不宜为省成本切换的场景：单轮交互仅数秒的短会话智能体，无法触发内存回收窗口。
- P75 是分位数口径，意味着约四分之一的调用慢于 1.9 至 2.0 秒，官方未给出尾延迟数据；且 V1 的 5.4 至 30 秒是跨镜像体积的区间，小镜像的实际改善幅度远小于区间跨度给人的印象。
- AWS 同时预告了后续能力：基线定价选项（预留内存下限、超出部分按需突发）、更大的 vCPU 与内存、x86 微虚拟机支持、会话挂起与恢复，以及为无人值守智能体提供按会话隔离的范围化身份。
把冷启动与内存计费作为主战场，说明智能体平台竞争的重心已从能力展示转向单位经济性：这两个变量直接决定团队把智能体当作常驻服务还是按请求调用的一次性函数来运行。AWS 明显在优化后者，并把迁移成本转移给客户，这也解释了为什么公告声势与实际采用速度会明显脱节。