AWS在9月30日用一个音乐生产案例展示AgentCore Runtime Instances三个Agent共用GPU实例、会话和文件系统先生成音频再处理响度最后独立合规检查。共享目录让交接变快也让“谁写的、哪一版、有没有被改过”变成生产问题。我的核心判断是共享存储必须配可验证的产物清单。发生了什么官方把Runtime Instances与MicroVM做了明确区分。后者是按用量计费的无服务器运行时单会话最长8小时且一个运行时承载一个Agent前者运行在客户账户的托管EC2上可使用支持的GPU、持久EBS卷一个实例承载多个Agent会话最长14天。多个运行时使用同一容量提供者和runtimeSessionId时会落到同一实例并共享挂载卷。示例中编曲Agent运行ACE-Step并写出音频交付Agent读取文件、测量并处理合规Agent重新测量检查目标与历史曲库相似度不合格就回叫编曲Agent重做。AWS报告L4上生成20秒、48 kHz立体声音频约需9秒。这是官方案例环境数据不应外推到其他模型和GPU。技术原理共享目录不是工作流协议仅约定/shared/final.wav很脆弱上游重跑可能覆盖文件下游可能读到写了一半的内容暂停恢复后也难判断旧产物是否还能用。更稳的办法是“不可变产物加Manifest”上游写临时文件完成后原子重命名再生成包含会话、阶段、版本、大小与哈希的清单下游先验证再处理并写自己的新清单。失败通过通过不通过编曲Agent临时文件写入原子发布产物生成Manifest与SHA256交付Agent验证阻断并请求重做处理并生成新版本合规Agent独立复测发布最小实践用哈希阻止被篡改的交接下面只使用Python标准库。依赖安装无保存为artifact_handoff.py运行python3 artifact_handoff.py。代码在临时目录生成产物、清单并校验再模拟文件被改写。importhashlib,json,tempfilefrompathlibimportPathdefsha256(path:Path)-str:returnhashlib.sha256(path.read_bytes()).hexdigest()defpublish(root:Path,session:str,payload:bytes)-Path:artifactroot/mix-v1.wavartifact.write_bytes(payload)manifest{session:session,stage:compose,artifact:artifact.name,bytes:artifact.stat().st_size,sha256:sha256(artifact),}targetroot/mix-v1.manifest.jsontarget.write_text(json.dumps(manifest),encodingutf-8)returntargetdefverify(root:Path,manifest_path:Path,session:str)-bool:mjson.loads(manifest_path.read_text(encodingutf-8))artifactroot/m[artifact]returnall([m[session]session,artifact.stat().st_sizem[bytes],sha256(artifact)m[sha256],])withtempfile.TemporaryDirectory()asfolder:rootPath(folder)manifestpublish(root,session-42,baudio-v1)assertverify(root,manifest,session-42)(root/mix-v1.wav).write_bytes(btampered)assertnotverify(root,manifest,session-42)print(handoff gate passed)publish固定了会话与阶段并计算SHA-256摘要verify同时检查会话、大小和内容文件被改写后门禁必须失败。代码已在本次任务中使用Python 3.9实际运行输出handoff gate passed且两条断言通过。本次没有AWS账户、L4 GPU或AgentCore权限未部署官方三Agent案例也未生成真实音频。一个具体场景把音乐换成软件发布构建Agent生成容器镜像清单测试Agent读取同一会话产物并附上报告安全Agent独立核对扫描结果后签名。它们可以各自部署不必同时升级但清单格式必须向后兼容。若安全Agent只相信文件名不验证摘要上游被覆盖或路径碰撞就可能绕过检查。暂停与恢复要有明确语义长任务最麻烦的不是运行而是隔夜恢复。恢复前要判断上一次阶段是“完成并发布”“正在写入”还是“已经失败”。清单可增加状态、生产者版本、输入摘要和单调递增序号只有状态为published且输入摘要仍一致时下游才能继续。若最后一次心跳停在写入阶段应清理临时文件并从该阶段重跑不能猜测文件是否完整。幂等性同样重要。同一调用因网络超时被重试时上游应得到相同产物标识或明确生成新版本下游消费成功后写入收据避免同一结果被处理两次。对于会产生费用、发送消息或改数据库的动作共享文件只能做协调证据最终还需要事务键或外部系统的幂等令牌。如果多个团队独立升级Manifest本身要版本化。新增可选字段通常能向后兼容删除或改义则应升主版本并在下游明确拒绝未知主版本。这样共享卷才从“大家都能看见的目录”变成可演进的接口。我的判断及依据Runtime Instances提供的是长时间、共享GPU和共享卷的能力不自动提供正确的跨Agent交接语义。官方示例最值得迁移的也不是“用三个Agent做音乐”而是生成、处理、独立复核的职责分离。再加不可变清单就能把口头约定变成机器可验证的接口。边界与风险官方说明恢复会话依赖落在同一可用区14天也不是永久保存承诺。共享进程空间和文件系统会扩大故障与权限影响面不同团队独立发布时还可能造成格式漂移。哈希只能证明内容未变不能证明内容安全或作者可信生产环境还需要身份签名、最小权限、加密、配额、恶意文件扫描和审计日志。立即可执行的检查表为每个会话生成不可猜测ID产物先写临时名再原子发布清单包含生产者版本、输入摘要、输出摘要和时间下游验证后才打开文件每阶段写新版本而非覆盖设置会话到期和清理策略故障演练至少覆盖中途写入、重复调用、旧清单、跨会话误读和磁盘满。云上试验结束后还要删除容量提供者、镜像、存储与相关权限避免持续费用。你的多Agent工作流里产物交接现在靠文件名、数据库记录还是可验证清单关注「蜗牛聊AI」一起看懂技术变化背后的真正机会。本文首发于 java4u.cn转载请注明出处。