2026 年 9 月 18 日，AWS 推出 AgentCore Runtime V2。两个数字值得做长程智能体的团队盯一下：P75 冷启动从过去的 5 到 30 秒，压到约 2 秒（镜像最大 2GB）；计费口径从按峰值内存，改成按实际使用的内存。对跑在托管运行时里的智能体来说，这两项是实打实的经济杠杆，不是性能榜上的一行注脚。
冷启动与内存计费，是长程智能体的两道账
智能体一旦从一次性问答走向跨天数运行——比如持续监控一个渠道、按节奏推进一个多天任务——运行时的成本结构就变了。旧版 AgentCore 的冷启动区间落在 5 到 30 秒，意味着一个被唤醒的会话要先等上不短的一段时间才能开工；而按峰值内存计费，又意味着哪怕智能体大部分时间在发呆，你也在为它预留的那块峰值付钱。V2 把 P75 冷启动压到约 2 秒，等于把唤醒延迟缩短了两道半到十五倍；把计费改成按实际占用，则直接把闲置时段的成本从账上拿掉。
这两处改动合起来，改变的是一类工作流的可行性。过去为了省冷启动，团队倾向于为每个会话保留一个常驻沙箱，但峰值计费让这种保活贵得肉疼；现在按实际用量计费后，常驻才变得可负担。把这件事放到本周的脉络里看更清楚：9 月 10 日 OpenAI 把 Agents API 做成公开测试，9 月 23 日 GitHub 给 Copilot 加了定时智能体任务，智能体运行时正在从团队自己造的轮子，变成可以租用、按用量结算的产品。AWS 这一步，是把托管运行时继续往下压实。
对做智能体的工程团队，这类运行时优化最实在的意义，是把「要不要让智能体常驻」从一道预算难题，变成一道默认可选的开关。过去为了躲冷启动，团队要么接受每次唤醒都卡几秒到半分钟、把交互体验做糙，要么为保活常驻付费、为峰值内存肉疼；V2 把两端都压下来之后，轻量任务可以随叫随到，重活则可以名正言顺地留一个常驻会话，不必再为「发呆的那段」付峰值价。这背后其实是一个更大的信号：智能体运行时正在从各团队自己拼的轮子，变成可租用、按用量结算的水电煤——谁能把冷启动和内存这两道账压得更薄，谁就更容易成为被默认选中的那一层。对选型团队，这意味着比拼模型档位之前，先得看清运行时这张账单。把冷启动和内存当成验收项，而不是事后才想起的成本，才是这次发布真正该带走的提醒。
仍要算清楚锁定与驻留的账
客观地说，V2 不是把所有账都抹平了。其一，它仍运行在 AWS 之内，选择它意味着把智能体的状态、日志与沙箱继续交给同一家云，跨云或自管的团队要重新权衡；其二，数据驻留与合规仍是受监管行业的硬约束，单看冷启动变快并不能绕过；其三，约 2 秒是 P75 而非上限，对突发、短促、要求确定性延迟的工作负载，冷启动仍可能成为短板。对工程团队，更有价值的不是记住 2 秒这个数字，而是借它理清自己智能体的成本结构：到底是冷启动拖慢了响应，还是峰值内存榨干了预算，先把账算清，再决定要不要迁。
把视线拉回落地，托管运行时早已进入不少企业的生产环境，AgentCore Runtime 早就被一些团队用在了真实的治理与编排场景里。V2 的意义，是把这些早期采用者一直在吃的苦——冷启动慢、内存按峰值付——做成了默认改善。对正在评估托管运行时的团队，这条发布是个提醒：比选模型档位更值得算的，是智能体在运行时这一层到底花了多少冤枉钱。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。