在 Amazon Bedrock AgentCore Runtime Instances 上构建多智能体音乐制作流水线
从单智能体到多智能体，基础设施需求变了
当企业从单一用途的智能体走向多智能体系统时，底层基础设施的要求也随之改变。一个处理客户查询的独立智能体，可以在无服务器环境中以短生命周期会话运行；但当你需要三个智能体协作完成一个跨越数天的创意工作流、共享上下文并相互接续产出时，上限仅数小时的无服务器会话就不够用了。
AWS 在 Amazon Bedrock AgentCore 中给出了两种算力选项，而这次的实践正是围绕新选项展开。
两种算力模型：MicroVM 与 Runtime Instances
MicroVM 是此前的无服务器选项：冷启动快、会话隔离、按用量计费。Runtime Instances 则是新增选项，提供 AWS 托管的 EC2 基础设施，面向持久、长时间运行的智能体工作流。二者共用同一套运行时 API，但 Instances 额外带来了多天会话、GPU、持久卷，以及在单个实例上共置多个智能体的能力。
两者的关键差异体现在以下维度：
- 会话时长：MicroVM 最长 8 小时；Runtime Instances 最长可达 14 天。
- 每份算力上的智能体数量：MicroVM 是一个运行时对应一个智能体（1:1）；Runtime Instances 允许一个 EC2 实例承载多个智能体（1:N）。
- GPU 访问：MicroVM 不支持；Runtime Instances 在受支持的实例族上可用。
- 会话持久性：MicroVM 为会话级；Runtime Instances 借助 Amazon EBS 实现持久存储。
- 计费方式：MicroVM 按用量计费；Runtime Instances 的 EC2 实例运行在用户自己的账户中，可使用 AWS Savings Plans 和 On-Demand Capacity Reservations（ODCR）。
- 扩缩容：MicroVM 按需伸缩；Runtime Instances 由容量提供程序（capacity provider）管理。
值得注意的是，两种选项都支持自定义框架（如 CrewAI、LangGraph、LlamaIndex、Strands Agents），都可搭配自选的基础模型，并集成了 MCP 与 A2A 协议。差异只在于底层算力模型。
一条三智能体的音乐制作流水线
文章给出的示例是一条音乐制作流水线，用来直观展示上述能力：
- 第一个智能体在实例自带的 GPU 上运行生成式音频模型；
- 另外两个智能体从共享卷上打开它写出的 .wav 文件，继续后续处理；
- 三个智能体共置在同一台 GPU 实例上，共享同一套文件系统，并相互交接工作，最终产出一首完整的曲目。
这个例子之所以成立，正是因为 Runtime Instances 允许智能体共置、共享文件系统、并在长时间会话中保持上下文——这些恰恰是无服务器 MicroVM 模型难以支撑的。
这条流水线还顺带演示了什么
按文章所述，完成这个实践后，读者不仅能得到一首可播放的曲目，还会掌握几项关键操作：
- 创建容量提供程序（capacity providers）；
- 从不同产物类型（artifact types）部署智能体；
- 使用共享会话编排智能体之间的协作；
- 让工作流跨越多天持久运行。
小结
从 MicroVM 到 Runtime Instances，反映的是智能体应用形态的演进：从短任务、单智能体，走向长周期、多智能体协作。对于需要 GPU、共享文件系统和多天会话的创意与工程工作流，Runtime Instances 提供了一条托管于 AWS 的路径，同时保留了使用自有 EC2 容量与计费优惠的灵活性。至于具体的部署细节与代码，原文有完整的分步说明。
