Agent 上生产之后，最先让你半夜爬起来的一般不是模型答错，是两件很土的事：新会话启动要等半分钟，账单按内存峰值算一整天。
9 月 18 日，AWS 发布了新一代 AgentCore Runtime——Amazon Bedrock AgentCore 里的 serverless microVM 计算层。它专门冲着这两个坑来：内存改成按需分配、用完就回收；冷启动从”看镜像大小和运气”改成”稳定 2 秒左右”。AWS 说自发布以来已有数千个团队用它跑生产级 Agent，这次是给”长跑、常驻”那类 Agent 补基础设施。
先说清这两个坑怎么来的
理解旧版的痛点，才能判断新版是不是真解决了。
第一个坑：内存按峰值算钱。 旧版 Runtime 的会话一旦分配了内存，就会一直持有到会话结束，中间没有任何机制把它收回去。对”分配了就一直在用”的场景没问题；但对长跑或突发型 Agent 就很亏——它可能在第 10 分钟处理一段大文件时把内存冲到高点，之后几小时都在等 I/O，账单却会按那个高点一路收下去。AWS 自己的说法是：这类 Agent 等于”整天按峰值付费”。
第二个坑：冷启动不确定。 每次新会话都得先启动才能干活。如果会话正好落在一个已初始化的环境上，启动不到 100 毫秒；但要让环境保持”热”，就意味着一直预留算力。所以大多数会话实际走冷启动：拉镜像、起环境、初始化 Agent，然后才能处理第一个请求。这个耗时随镜像变大而变长，也随并发升高而变差——最糟的情况恰好出现在人最多的时候。于是不少团队自己造机器：预热池、内存调优、再拆掉省账单。
新版的解法一：内存按需给，用完就收
新的 Runtime 换了一套内存模型。
会话不再从”完整配置好的内存占用”起步，而是从一个小内存剖面开始，按需分配、按需换入页面。当 Agent 释放了请求级缓冲区、或者缓存数据在两次请求之间失效，平台会把这块内存收回去，而不是让它挂到会话结束。
AWS 说这套回收策略是基于对数亿次会话分配模式的分析调优出来的。关键词是”行为”而不是”上限”——它认的不是你声明要多少内存，而是你实际用没在用。
计费方式也跟着变了：从”整个容器镜像按会话生命周期占着内存”改成”按 Agent 真正活跃使用的内存”。AWS 用一句话概括这次的账：单价更高了，但 GB-小时数少得多，多数 Agent 的内存占用下降幅度大于单价上升幅度，所以总账单是降的。
这其实是个很典型的云产品进化路径：从”你为峰值容量付费”变成”你为实际消耗付费”。同样的逻辑我们前不久在 Cursor 推出自托管机器 时也见过——企业不想为用不到的能力付溢价，也不想把代码送出去。
新版的解法二：先跑一次，拍个快照
冷启动的改法是换思路：不再想办法”每次启动更快”，而是让绝大多数实例根本不需要完整启动。
具体做法是：Agent 环境只准备一次，然后拍一张快照。之后每个新实例直接从快照恢复，而不是重跑一遍完整启动流程——加载模型构件、拉取静态配置这类一次性初始化工作，在快照里已经做完了。
还有一个容易被忽略的细节：快照会剥离缓存和临时内存，所以它的体积大致不随容器镜像增大而增长。这是”冷启动时间与镜像大小无关”能成立的技术前提。
顺手给个小技巧，官方文档里也写了：交互式 Agent 可以在用户刚开始交互时就打开会话，比如聊天窗口一弹出来就开会话，这样环境会在用户敲第一个问题的过程中预热完，等他按下回车时几乎感觉不到启动成本。这类”把延迟藏进人的思考时间里”的设计，做产品的可以直接抄。
数字：P75 从 30 秒到 2 秒，但要会读
AWS 公布的测试口径值得完整看一遍，因为它比结论本身更有信息量。
测试用的是个”空壳 Agent”：只回显输入，不调用任何模型和工具。这样测出来的时间基本就是平台启动开销。方法是每个 Agent 发 5,000 次冷调用，跨新旧两个版本、五种镜像大小；客户端是一台放在 us-west-2 的 EC2 上用 Python boto3 调用 us-east-1 的 Agent，走公网、没有 VPC peering——所以客户端测到的数字里含跨地域往返时间。
结果：新 Runtime 的 P75 冷启动在 1.9–2.0 秒，从 200MB 到 2GB 的镜像都是这个水平，因为镜像大小对它没有影响。旧版则从约 5.4 秒一路涨到接近 30 秒。
空壳 Agent 自身的代码执行时间 P75 约 34 毫秒——也就是说，测出来的时间几乎全是平台启动时间，不是你的代码慢。
有几个边界要一起记住：2 秒是 P75，不是平均也不是最差；测试没用 VPC peering，真实环境里加了这个会更快，加了别的网络中间层可能更慢；那不到 100 毫秒的”热启动”依然存在，但前提是你愿意付预留算力的钱。新版没有取消热池的价值，只是让不加热池的代价小到可以接受。
怎么开：一行参数，但要留意默认值
开启方式非常简单：创建或更新 runtime 时把 platformVersion 设成 V2。
有个默认值陷阱要记住：创建时不写这个字段，得到的是 V1；更新时不写，则保持该 runtime 当前的版本。 也就是说，你不会”不小心”升级，但也别指望它自动帮你升。存量 runtime 需要显式改一次。
区域方面，新 Runtime 先开放 5 个：us-east-1、us-east-2、us-west-2、eu-west-1、ap-northeast-1。
旧版那些 serverless 特性都保留了：不用预置、能缩到零、硬件级会话隔离、按用量付费，以及等 I/O 时闲置的 CPU 不计费。
如果你还没接触过 AgentCore，它的定位是”Agent 的运行与运维层”，和框架解耦——CrewAI、LangGraph、Strands、自己写的框架都能跑。除了 Runtime，还有 Memory（长短记忆）、Gateway（把 API、Lambda、OpenAPI 转成 MCP 工具）、Identity（给 Agent 发身份和凭证）、Policy（用 Cedar 写细粒度授权规则）、Observability、Browser、Code Interpreter 等模块。而且它还有个 Instances 选项，把 Agent 跑在你账号下的托管 EC2 上，适合持续运行、要 GPU 或者跑好几天的任务。想先看一个真实的 Agent 应用长什么样，可以读 AWS 开源的 Pizza Bot。
优缺点
优点：
- 冷启动变可预测。2 秒且不随镜像变大，这是运维层面最直接的收益——SLA 可以按这个数字写了。
- 计费模型更合理。按活跃内存算，突发型 Agent 省得最明显。
- 迁移成本极低。一行参数，代码和框架都不用动。
- 不需要自己维护预热池。以前团队自建的那套”预热 + 拆机”逻辑可以省掉。
缺点：
- 只覆盖 5 个区域，国内团队要评估跨区延迟。
- 内存单价提高了。如果你的 Agent 确实是持续高负载、内存一直满载，这轮降价跟你基本无关，甚至可能更贵——AWS 自己说的是”对多数 Agent 更便宜”。
- 默认不升级，存量 runtime 要人手动改，容易漏。
- 它对标的是”会话型”负载。超过 microVM 会话时长上限的超长任务，还是得看 Instances 选项。
适合谁，不适合谁
适合： 已经在 Bedrock / AgentCore 上跑生产 Agent 的团队；账单明显被内存峰值拖累的团队；容器镜像偏大（接近 1–2GB）因此冷启动特别慢的团队；事件触发的常驻 Agent，请求稀疏但要求响应稳定。
不太适合： 还只在本地跑脚本、没上生产的个人开发者——这些收益你暂时用不到；对延迟极度敏感、要求稳定 100 毫秒内首响的场景，还是得加热池，新版只是把冷启动的天花板降低了；以及内存长期满载的持续型负载。
替代方案怎么选
如果你不一定留在 AWS，同一层的问题有几条路：
- 通用托管平台：Vercel、Fly.io、Cloudflare Sandboxes 这类，胜在上手快、按请求计费，适合轻量 Agent 和 Web 侧集成。
- 专用沙箱服务：E2B、Daytona、Modal 这类，长于给 Agent 提供隔离的代码执行环境，冷启动也做了不少优化，适合”代码执行”是核心的场景。
- 自建 Kubernetes + 预热池：控制力最强，成本最可控，代价是那套预热和回收逻辑得自己写、自己维护——这正是新版 Runtime 想帮你省掉的部分。
- 同门的 AgentCore Instances：要 GPU、要跑几天、要持续状态，走这个而不是 microVM。
选型逻辑其实只有一句话：如果你的痛点是”起得慢 + 按峰值付费”，这个版本正好对症；如果你的痛点是”不想被云厂商锁定”，那所有托管方案都一样，得先想清楚迁移成本。
老达点评
第一，这轮优化真正值钱的不是 2 秒，是”可预测”。 30 秒和 2 秒的差距，做 demo 时感觉不出来，做 SLA 时是两种产品。运维最怕的从来不是慢，是不确定——同样一个请求，有时 0.1 秒有时 30 秒，你就没法写容量规划，也没法给用户承诺。把方差压掉，比把均值压低更有工程价值。顺带说一句，AWS 这次把测试方法交代得很细（空壳 Agent、跨区公网调用、含往返时间、P75 不是均值），这种把”数字在什么条件下成立”写清楚的做派，值得国内厂商学。
第二，“按峰值付费”变”按实际用量付费”，是 Agent 时代基础设施的必然走向。 因为 Agent 的负载形态和传统 Web 服务完全不同：它天然是突发 + 长尾的组合，思考时吃 CPU、调工具时干等 I/O、写文件时吃内存。用为”稳定 QPS”设计的计费模型去套它，双方都别扭。今年一整条线上都在发生同样的变化——微软的 Project Opal 把长任务塞进云电脑连干几小时，Codex 在测持久模式 让 Agent 干完活自己找活干，万级 Agent 协作解数学难题 直接把并行度拉到万级。这些场景共同指向同一个结论：Agent 的基础设施成本不再由”请求数”决定，而由”它到底动了多少资源”决定。
第三，对普通开发者，这条新闻的实际含义是”你不需要自己搭预热池了”。 过去这件事只有两种结局：要么忍受冷启动，要么花工程力气自建。现在第三种选择出现了。如果你正在为 Agent 的启动延迟和账单做架构决策，值得花半小时把存量 runtime 的 platformVersion 升到 V2 实测一轮——这是那种”改动一行、收益立刻可见”的少数优化之一。更多工具选型的对比思路，可以看 AI 工具评测专题；如果你更关心 Agent 怎么拆任务、怎么编排，AI 智能体与自动化专题 里有成套的实践文章。
常见问题
Q：升级要改代码吗？
不用。创建或更新 runtime 时把 platformVersion 设为 V2 即可，框架和 Agent 逻辑都不用动。
Q：为什么我升级后账单变贵了？
检查两件事：内存单价确实提高了，如果你的 Agent 内存长期满载，成本可能上升；另外确认区域和调用模式，稀疏调用才是这次优化的最大受益者。
Q：升级之后还需要预热池吗？
多数场景不需要了。但如果你的产品要求首响稳定在 100 毫秒以内，热池依然有价值——新版降低的是”不加热池”的代价，不是取消热池的作用。
Q：和 AgentCore Instances 怎么选？
会话型、几小时内完成、弹性要求高——用 microVM（也就是本文说的 Runtime）。持续运行、要 GPU、要跨天保持状态——用 Instances。
