生活分享

AWS 介绍 Bedrock AgentCore Runtime Instances：AI 智能体可运行 14 天、使用 GPU、多智能体同机协作

AWS 于 2026-09-30 发文，以多智能体音乐制作流程演示 Amazon Bedrock AgentCore 的新计算选项 Runtime Instances，强调最长 14 天会话、GPU 访问、持久存储与多智能体同机协作。文中说法均来自 AWS。

阅读时间约 6 分钟

AWS 介绍 Bedrock AgentCore Runtime Instances：AI 智能体可运行 14 天、使用 GPU、多智能体同机协作
图片：Mokaair (Original editorial artwork)

发生了什么

AWS 于 2026-09-30 在其 Artificial Intelligence 博客发表文章，说明如何在 Amazon Bedrock AgentCore Runtime Instances 上构建多智能体音乐制作流程。AI 智能体指能够分步骤完成任务的 AI 程序。根据 AWS 的说法，AgentCore 目前提供两种托管 AI 智能体的计算选项。一种是无服务器的 MicroVMs，用户不必自己管理服务器，按用量计费。另一种是被称为“新选项”的 Runtime Instances，由 AWS 管理的 EC2（AWS 的云服务器）基础设施提供支撑，定位于持久、长时间运行的智能体工作流。

AWS 在文中指出，当组织从单一用途智能体走向多智能体系统，基础设施需求也随之改变。如果多个智能体要在跨越数天的工作中共享上下文，上限只有几个小时的无服务器会话并不够用。AWS 的文章没有说明 Runtime Instances 的正式推出日期。

AWS 介绍 Bedrock AgentCore Runtime Instances：AI 智能体可运行 14 天、使用 GPU、多智能体同机协作
Mokaair 编辑核查流程 · 图片：Mokaair (Original editorial artwork)
阅读完整文字说明

消息会先收集来源、独立核查，再交由 Jev 判断。

MicroVM 与 Runtime Instances 有何不同

AWS 表示，两种选项都支持 CrewAI、LangGraph、LlamaIndex、Strands Agents 等智能体开发框架，可自选基础模型，并集成 MCP 与 A2A 等协议，差异主要在于底层计算模型。下表整理自 AWS 文章中的比较。其中“制品”指部署时上传的程序包，ODCR 指按需容量预留。

AgentCore 两种计算选项比较（资料来源：AWS 博客）
项目MicroVM（无服务器）Runtime Instances
计算完全由 AWS 管理AWS 管理的 EC2 实例
会话时长最长 8 小时最长 14 天
每个计算单元的智能体数一个 microVM 承载一个智能体（1:1）一台 EC2 可承载多个智能体（1:N）
制品类型容器镜像与 Amazon S3 来源容器镜像与 Amazon S3 来源
GPU不支持支持（限支持的实例系列）
持久性以会话为范围Amazon EBS 持久存储
计费按用量计费EC2 在用户账户中运行，可使用 Savings Plans 与 ODCR
扩展按需扩展由容量提供方管理

据 AWS 说明，关键机制在于“共享会话”。容量提供方（capacity provider）是一项配置，用来告诉 AgentCore 要准备哪些计算资源。当两个智能体 runtime 使用同一个容量提供方，并以相同的 runtimeSessionId 调用时，它们会被安排到同一台 EC2 实例上。它们共享文件系统，能直接读取彼此的产出。

AWS 的演示：三个智能体合作完成一首曲子

  • 作曲智能体：据 AWS 表示，它使用 Claude Sonnet 4.6 将制作人的需求转为音乐简报，再用开源音乐生成基础模型 ACE-Step 在实例的 GPU 上生成音频。
  • 交付智能体：读取共享文件系统上的音轨并进行测量，请 Claude Sonnet 4.6 根据测量结果规划均衡、压缩与限幅。处理完成后再次测量，确认是否达标。
  • 合规智能体：独立重新测量成品并检查交付目标，同时与工作室自有曲库比对和声相似度。若发现相似，会回调作曲智能体生成替代版本。

AWS 公布了在 us-east-2 区域 g6.xlarge 实例上的示例结果：准备模型堆栈用时 239 秒，作曲 25 秒（其中在 NVIDIA L4 上渲染 8.98 秒，峰值显存 7.63 GiB），交付 41 秒，合规筛查 28 秒。五个步骤均由同一台实例完成。LUFS 是衡量响度的单位，dBTP 是衡量真峰值电平的单位。交付处理前，音频为 -7.5 LUFS、峰值 0.42 dBTP；处理后为 -14.0 LUFS、峰值 -3.2 dBTP。合规筛查结果为“REVIEW REQUIRED”（需人工审查）。这些数字是 AWS 单次演示的结果，并非独立测试。

对普通读者与企业的实际影响

对普通用户而言，这一变化不会直接改变日常使用的 App，但它反映出 AI 智能体正从“一问一答”走向“多个智能体分工、跨天完成长任务”。AWS 表示，这种架构并非音乐专属，可应用于 3D 渲染、模拟、模型推理与媒体处理等需要 GPU 的工作。

对企业团队，AWS 强调了几项好处：各团队可以各自更新自己的智能体，而不影响其他智能体；容器与代码包可以共存于同一基础设施；工作暂停时可以停止会话，之后再恢复。不过，这些优点目前都来自 AWS 自身的说法与演示。

仍待观察之处

  • 目前信息仅来自 AWS 官方博客，性能与成本表现尚无独立第三方验证。
  • AWS 文章未提供 Runtime Instances 的正式推出日期，也没有列出各区域的完整可用情况。
  • 演示中的曲库比对仅用于工作室自有曲库，实际应用于版权审查的效果仍有待观察。

常见问题

Runtime Instances 是什么？

据 AWS 表示，这是 Amazon Bedrock AgentCore 用于托管 AI 智能体的新计算选项，以 AWS 管理的 EC2 为基础，适合持久、长时间运行的智能体工作流。它与无服务器的 MicroVM 使用相同的 runtime API。

和原来的 MicroVM 最大区别是什么？

根据 AWS 的比较，MicroVM 会话最长 8 小时，一个 microVM 承载一个智能体，且不支持 GPU。Runtime Instances 会话最长 14 天，一台实例可承载多个智能体，并在支持的实例系列上提供 GPU 与 EBS 持久存储。

多个智能体如何在同一台机器上协作？

AWS 说明，当多个智能体 runtime 共享同一容量提供方，并以相同的 runtimeSessionId 调用时，它们会被放在同一台 EC2 上并共享文件系统，因此能读取彼此生成的文件。

停下来之后还会收费吗？

AWS 表示，调用 StopRuntimeSession 后，实例会自动闲置，闲置期间不产生计算费用。若要避免持续产生费用，AWS 建议先删除会话，以释放实例、网络接口与 EBS 卷。

这只能用来做音乐吗？

不是。AWS 表示音乐只是方便的演示题材，同样的三智能体架构可用于 3D 渲染、模拟、模型推理与媒体处理等 GPU 工作负载。

这些性能数字可信吗？

文中数字（例如约 9 秒生成 20 秒音频）来自 AWS 的单次演示，属于 AWS 自身的说法，尚未经独立验证。实际表现可能因配置与环境而异。

查看同分类最新消息

同主题延伸阅读

最新旅游情报攻略

资料来源

生活分享