多个 AI 智能体“同住”一台 EC2：AgentCore 推出持久计算

事件核心：发生了什么

亚马逊云科技在 Bedrock AgentCore 的官方博客中宣布推出运行时实例（Runtime Instances），这是继原有 microVM 无服务器选项之后，AgentCore 新增的第二种计算模式。该功能在客户账户内的托管 Amazon EC2 上运行智能体，保留现有的 AgentCore API、身份控制和可观测性模型。首席开发者布道师 Sebastien Stormacq 在公告中解释，运行时实例允许智能体会话最长运行 14 天，支持共享文件系统、GPU 加速实例类型，并可通过简单的 @app.entrypoint 装饰器导入 CrewAI、LangGraph、LlamaIndex 和 Strands 等外部框架。多个智能体可以部署在同一个 EC2 主机上，通过共享会话目录协作，无需在任务交接时反复调用 API。该功能已面向开发团队开放，相关文档同步上线。

为什么重要

这一发布解决了 AI 智能体从“演示原型”走向“生产任务”时的关键瓶颈：会话时长和状态持久化。此前 AgentCore 的 microVM 模式虽然启动快、按秒计费，但 8 小时上限和会话隔离机制，让需要长时间运行或跨智能体协同的工作负载难以落地。运行时实例将计算模型扩展到客户自有的 EC2 账户内，使团队可以利用现有的 Savings Plans 和预留实例折扣，同时避免直接管理自动扩缩组、启动模板和 AMI 流水线。值得注意的是，亚马逊云科技并未将两种模式对立，而是明确推荐混合拓扑：由 microVM 上的编排智能体将长任务分派给 EC2 上的工作智能体。这种做法在基础设施层面承认了不同智能体有不同生命周期，而不是用单一计算模型硬套所有场景。微软在 Azure Foundry 托管智能体中也有类似的思路，通过预置 VM 沙箱和持久化主目录来还原会话状态，说明主要云厂商正在把智能体运行时的“长期存活”问题当作竞争焦点。

对用户/开发者/创作者的影响

对企业开发团队而言，最直接的变化是部署长流程任务时不再需要自建集群。此前需要持续运行超过 8 小时的智能体，团队往往要手动维护独立的 EC2 集群，自行处理补丁、扩缩容和网络配置。现在 AgentCore 的容量提供程序原语承担了这些工作，开发者只需要定义实例系列、操作系统和会话存活时间，并把智能体运行时绑定到提供程序上。支持 GPU 实例类型意味着视觉模型推理、大规模批处理或加速计算类的智能体也可以纳入同样的管理框架。对于使用 CrewAI 或 LangGraph 的团队，打包模型不需要更改，只需用 ZIP 或容器镜像部署，降低了迁移成本。成本方面需要留意：运行时实例按所选 EC2 类型的标准费率计费并附加管理费，而 microVM 按 vCPU 小时和 GB 小时计费且无管理费。第三方成本分析显示，不考虑 Savings Plan 折扣时，运行时实例的盈亏平衡点约为 24% 的持续 CPU 利用率——CPU 利用率低于这一水平的工作负载，用 microVM 可能更省钱。

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。

值得关注的后续

目前公开信息显示，运行时实例的会话上限为 14 天，之后是否支持更长的持久化会话，取决于客户反馈和实际使用情况。值得观察的方向有三个：其一，14 天上限是否会在后续迭代中放宽或变为可配置，以覆盖更长的定时任务或持续运行的服务型智能体；其二，管理费的具体定价策略如何随使用规模调整，是否会推出针对多智能体共置的打包计费；其三，微软 Azure Foundry 托管智能体的持续演进是否会进一步压低会话恢复成本，促使亚马逊云科技对 microVM 和运行时实例的混合调度做更细粒度的优化。开发者在选型时，建议先统计现有工作负载的 CPU 利用率和平均会话时长，再决定把任务放在哪一层计算上。

来源：InfoQ CN