AWS为Bedrock AgentCore增加Runtime Instances：单实例可跑多智能体、带GPU和持久卷
AWS博客展示用三个智能体在同一个GPU实例上完成音乐制作流水线：Compose在本地NVIDIA L4上渲染音频，Delivery读取同一文件做母带处理，Compliance独立复测并查重；会话最长可续 14 天。
AI解读：AWS给Bedrock AgentCore加了一个新的计算选项Runtime Instances，定位很清楚：MicroVM那种无服务器模式一次最多跑 8 小时、一个运行时只能装一个智能体、也没有GPU；Runtime Instances把上限拉到 14 天，一个EC2实例可以同时跑多个智能体，并且能挂GPU和持久卷。
这解决的是一个很实际的问题。多个智能体协作做创意类工作，往往要跨天共享上下文、反复读写同一批文件，几小时就断掉的无服务器会话撑不住。Runtime Instances让两个共享同一capacity provider的运行时用同一个runtimeSessionId调用，AgentCore就会把它们放到同一台实例、挂载同一批卷，文件系统直接共享。
对团队分工的影响比性能更大。每个智能体各自打包、各自上线：示例里音频AI团队用容器镜像推新的作曲镜像，工程团队和发布团队完全不用动。泡了一晚上的卷、会话历史都留在磁盘上，第二天接着跑。
普通读者不需要现在动手。真正相关的是已经在AWS上做多智能体、又需要GPU或长会话的团队：他们现在少了一层自己管EC2和调度的胶水代码，但代价是agent代码要遵守几个容易配错的约定，比如入口函数第二个参数必须叫context，否则拿不到session ID。
AWS在机器学习博客发布了一篇实操文章，介绍Amazon Bedrock AgentCore新增的Runtime Instances计算选项，并用一个三智能体音乐制作流水线演示它的能力。文章由Evandro Franco署名。
作者给出的对比是：MicroVM是无服务器选项，冷启动快、会话隔离、按用量计费；Runtime Instances是新的选项，底层是AWS托管的EC2基础设施，面向持久、长时间运行的智能体工作流。两者使用相同的运行时API，但Instances增加了多天会话、GPU、持久卷，以及把多个智能体放在同一实例上的能力。
文章列出的差异表：MicroVM会话最长 8 小时，一个运行时只承载一个智能体（1:1），不支持GPU，会话级持久化，按用量计费，按需扩展；Runtime Instances会话最长 14 天，一个实例可承载多个智能体（1:N），在受支持的实例族上可用GPU，通过Amazon EBS持久存储，EC2实例运行在用户账户内、可使用Savings Plans和On-Demand Capacity Reservations，扩展由capacity provider管理。两者都支持容器镜像和Amazon S3源代码两种构件类型，都支持自定义框架（CrewAI、LangGraph、LlamaIndex、Strands Agents）、可选基础模型、MCP和A2A集成。
文章强调一个智能体是会话内运行的工作负载。两个智能体运行时共享同一个capacity provider时，用同一个runtimeSessionId调用，AgentCore会把它们放到同一台EC2实例上，共享文件系统、协作完成同一任务。
三智能体的音乐制作流水线
示例流水线由三个专门智能体组成。Composition agent（音频AI团队）用Claude Sonnet 4.6把制作人的请求变成音乐brief，再用生成式音乐模型ACE-Step（一个开源音乐生成基础模型）在实例自带的GPU上渲染音频，打包为Amazon ECR中的容器镜像。
Delivery agent（音频工程团队）从共享文件系统读取渲染好的音轨并做测量，然后让Claude Sonnet 4.6基于这些测量值（而不是音频本身）给出一条交付链（EQ、压缩、限幅）。真实的信号处理会应用到这条链上，结果再被测量一次，以确认达到交付目标。它也打包为ECR容器镜像。
Compliance agent（发布工程团队）独立重新测量完成交付的音频，对照delivery agent声称的交付目标做检查，并对音频与工作室自有曲库做和声相似度筛查。如果筛查提出异议，该智能体会回调composition agent生成替代版本并重新筛查。它以Amazon S3上的zip文件形式交付。
- 流程：制作人启动一条音轨 → composition agent写brief并在GPU上渲染真实音频 → delivery agent打开文件、测量、应用基于测量推导出的处理链、再测量验证 → compliance agent独立复测、检查交付目标、对曲库查重，命中则回调composition agent重新生成。
- 产出是一个可播放的 .wav和三份解释每一步决策的报告。
让共置、GPU和跨天续跑成立的机制
文章列出四点关键能力。第一，通过共享session ID共置：每个智能体有自己的运行时，但在同一capacity provider上用同一个runtimeSessionId调用后，AgentCore会把它们放到同一实例并挂载相同卷，共享文件系统、能互相读取输出。
第二，可用的GPU：composition agent直接在实例的NVIDIA L4上运行ACE-Step，渲染 20 秒 48 kHz立体声约需 9 秒。模型和依赖放在持久卷上，一个会话内构建一次后被该会话的每次调用复用，隔夜停止后依然可用。
第三，独立部署：每个团队按自己的节奏发布构件，音频AI团队推新镜像无需与另两个团队协调。第四，多天持久化：制作人周一作曲、隔夜停止会话、周二继续交付；实例自动空闲，下次调用时恢复。
- 构件类型可混用：来自ECR的容器和来自S3的代码包共存于同一个capacity provider。
- 示例中compliance agent用codeConfiguration，artifact指向S3中的zip，运行时为PYTHON_3_12，入口为compliance_agent.py。
部署步骤与配置细节
文章的前置条件包括：有权限创建基础设施的AWS账户凭据、已配置的AWS CLI、至少一个子网和安全组的VPC、在Amazon Bedrock控制台启用Anthropic Claude Sonnet 4.6的模型访问、本地安装Finch或其他OCI兼容容器工具、Python 3.10+，以及boto3 ≥ 1.36.0 或botocore ≥ 1.43.72——旧版本缺少create_capacity_provider，deploy.py会失败。完整示例在AgentCore samples的GitHub仓库。
文章提醒两个容易配错、且报错让人困惑的细节。其一，入口函数参数必须命名为context：SDK依据参数名分发（检查params[1] == "context"），这是读取session ID的唯一方式，而智能体需要它来找到彼此的文件并互相调用。其二，Agent要建在handler之内，而不是模块作用域：模块级Agent会被并发请求共享，Strands会以Agent is already processing a request拒绝重入。历史通过FileSessionManager存在卷上，这就是几天后恢复的会话仍记得先前决策的原因。
创建capacity provider需要两个IAM角色，区别很重要：operator role由AgentCore代入，用来代为开通EC2（启动、打标签、终止实例及其网络接口），附加托管策略BedrockAgentCoreRuntimeInstancesOperatorRolePolicy；execution role由智能体进程在运行时代入，用来调用Bedrock和S3，CreateAgentRuntime需要它，缺失会失败。两者都信任bedrock-agentcore.amazonaws.com。
示例中capacity provider名为music_production_capacity（名称必须用下划线，不允许连字符），指定g6.xlarge实例类型、VPC子网和安全组，挂载两个EBS卷tracks（20 GiB gp3加密）和models（60 GiB gp3加密、吞吐 500），rootVolume留 30 GiB空闲，lifecycleConfiguration设置idleInstanceTimeout 600、maxLifetime 86400。
- 文章警告：如果在多个可用区遇到InsufficientInstanceCapacity导致无法分配GPU实例，可以换成其他GPU实例类型，比如g5.xlarge，并相应更新allowedInstanceTypes。
- Step 3为每个智能体创建独立运行时，都指向同一capacity provider并声明挂载的卷；Step 4用同一个runtimeSessionId依次调用，第一次调用因要开通实例而最慢，之后每次都会路由到已在运行的实例上。
- Step 5演示任一团队如何发布自己智能体的新版本而不影响其他团队。
实测运行数据与限制
文章给出在us-east-2一台g6.xlarge上的实测输出：准备模型栈（GPU实例 + torch +权重）239 秒，host为ip-172-31-11-83.us-east-2.compute.internal，栈 125 秒后ready=True；渲染自有曲库 66 秒；作曲（在GPU上渲染音频）25 秒，NVIDIA L4渲染耗时 8.98 秒（峰值VRAM 7.63 GiB），音频 20.062 秒、48000 Hz、双声道、-7.5 LUFS、峰值 0.42 dBTP。
交付环节 41 秒：读入composition.wav（由另一个智能体写入），前后测量从 -7.5 LUFS、0.42 dBTP变为 -14.0 LUFS、-3.2 dBTP，目标为响度达标、真峰值守住。合规筛查 28 秒，结论为REVIEW REQUIRED，筛查了 2 个参考，最接近的catalogue_00.wav距离为 0.0665（review）。
文章指出所有 5 个步骤都由一台实例服务，符合预期。调用StopRuntimeSession后实例自动空闲，空闲期间不产生计算费用；再次调用会话时AgentCore会恢复它，前提是落在同一个可用区。Amazon EBS卷锁定可用区：如果原可用区容量不足，卷无法重新挂载。