从聊天机器人到长期运行的自主代理，AI智能体的形态正在发生根本性变化。AWS今天更新了它的生产智能体运行时，以应对这个变化。

问题出在哪

任何用过云函数（如AWS Lambda、Google Cloud Functions）的人都会熟悉「冷启动」问题：当一个容器镜像长时间不使用后，下次调用需要重新启动，会产生明显延迟。

对于早期的AI代理（快速问答，秒级交互），这不是大问题。但当代理开始处理长时间运行的任务时——比如运行数小时的代码代理、持续监控的安全代理、跨多个系统协调的工作流代理——冷启动延迟的影响就变得不可接受。

旧版AgentCore runtime的具体表现：

  • 200MB镜像：冷启动约5.4秒
  • 随镜像大小增大，冷启动时间线性增长，最高接近30秒

30秒的冷启动，对于一个实时交互的业务流程来说，几乎是致命的。

新运行时改了什么

2026年9月18日发布的新AgentCore runtime，从两个维度根本性改变了这个问题：

1. 快照恢复机制

新运行时使用容器快照（snapshot）来实现一致的冷启动时间。核心思路是：预先在内存中保留一个容器的初始化快照，当需要启动新实例时，直接从快照恢复，而不是从头启动。

结果：无论镜像大小（200MB还是2GB），P75冷启动时间稳定在约2秒。

这对运行大型代码库的代理尤其重要——一个配备了完整语言服务器、依赖库和上下文缓存的代码代理，镜像大小往往超过1GB。

2. 弹性内存计费

旧系统的内存模型是「峰值预留」：容器在整个会话期间持有峰值内存，即使大多数时间处于等待I/O的空闲状态，内存费用仍在计。

新运行时改为按实际使用量计费：当一个会话结束，内存立即释放；计费只跟踪真实的资源消耗，而非预分配容量。

对于多数智能体来说，这意味着成本明显下降——尤其是那些大量时间在等待工具调用返回（如数据库查询、API请求）的代理。

为什么这个时间点重要

AWS的这次更新，恰好赶上了智能体形态的一个关键转变时刻。

过去两年，代理主要被设计成：用户提问→代理思考→给出答案。这个模式下，每次交互是独立的，冷启动延迟分散在每次请求里，尚可接受。

但2026年的代理越来越多地变成「环境智能体」（ambient agents）：始终在线，由事件触发，在无监督状态下运行，只在需要人类决策时才浮出水面。

这类代理会长时间运行、频繁与外部系统交互、并在工作完成后进入「休眠」等待下一个触发事件。对它们来说，一致的低延迟启动和精确的资源计费，是决定生产可用性的关键指标。

谁在用AgentCore

AWS透露，自AgentCore runtime上线以来，已有数千个团队在生产环境中使用它。

这个数字并不令人意外。Bedrock作为AWS的企业AI平台，天然继承了大量已有AWS客户——这些客户原本就在AWS上运行核心业务，迁移AI代理到同一基础设施的摩擦成本极低。

对于这些团队来说，新运行时的升级是无感知的基础设施改善：原有代码无需修改，性能和成本自动改善。

更大的图景

从更宏观的视角看，AWS这次更新体现的是一个持续的战略：把智能体基础设施的复杂性从开发者面前隐藏掉。

开发者不应该关心容器调度、内存管理、冷启动优化——这些都是云厂商应该解决的问题。开发者应该只关注智能体的行为逻辑。

随着代理从实验室走向生产，基础设施的成熟度往往是决定大规模采用的最后一块拼图。2秒的一致冷启动，可能是一个平凡但至关重要的里程碑。

来源：AWS Machine Learning Blog，2026年9月18日