长任务多Agent共享文件系统的Manifest交接模式
内容提要
AWS 展示 AgentCore 多 Agent 共享 GPU 与文件系统案例，指出共享目录易导致覆盖、半写和版本混乱。文章主张采用不可变产物加 Manifest：原子发布，记录会话、阶段、大小与 SHA-256，下游先验证再处理，并处理恢复、幂等与版本兼容。
延伸解读
共享目录的交接风险与Manifest解法
文章指出，多Agent共享文件系统时，仅靠约定文件名（如/shared/final.wav）容易导致覆盖、半写和版本混乱。AWS案例中，编曲、交付、合规三个Agent共用文件系统，虽提升效率，但“谁写的、哪一版、是否被改过”成为生产问题。作者主张采用不可变产物加Manifest：上游写临时文件后原子重命名，并生成包含会话、阶段、大小和SHA-256的清单；下游先验证再处理。这能将口头约定变为机器可验证的接口。
暂停恢复与幂等性的关键语义
长任务常需隔夜恢复，文章强调恢复前必须判断上一阶段是“完成并发布”“正在写入”还是“已经失败”。Manifest可增加状态、生产者版本、输入摘要和单调递增序号；只有状态为published且输入摘要一致时，下游才能继续。若心跳停在写入阶段，应清理临时文件并重跑，不能猜测完整性。幂等性方面，重试应得到相同产物标识或明确新版本，下游消费后写收据，避免重复处理。涉及费用或外部动作时，共享文件仅作协调证据，最终需事务键或幂等令牌。
Manifest版本化与安全边界
多团队独立升级时，Manifest本身需版本化：新增可选字段通常向后兼容，删除或改义应升主版本，下游明确拒绝未知主版本。这样共享卷才能从“大家都能看见的目录”变为可演进的接口。但哈希只能证明内容未变，不能证明内容安全或作者可信。生产环境还需身份签名、最小权限、加密、配额、恶意文件扫描和审计日志。官方说明恢复会话依赖同一可用区，14天并非永久保存承诺，共享进程空间和文件系统会扩大故障与权限影响面。
Q&A
多Agent共享文件系统时，为什么直接约定文件名（如/shared/final.wav）不可靠？
因为上游重跑可能覆盖文件，下游可能读到写了一半的内容，暂停恢复后也难判断旧产物是否还能用。
Manifest交接模式的核心做法是什么？
采用不可变产物加Manifest：上游写临时文件，完成后原子重命名，再生成包含会话、阶段、版本、大小与哈希的清单；下游先验证再处理，并写自己的新清单。
在Manifest模式中，如何用哈希阻止被篡改的交接？
发布时计算产物的SHA-256摘要并写入清单；下游验证时检查会话、大小和内容哈希是否一致，文件被改写后验证必须失败。
长任务暂停恢复时，Manifest需要增加哪些字段来明确语义？
可增加状态、生产者版本、输入摘要和单调递增序号；只有状态为published且输入摘要仍一致时，下游才能继续。若最后一次心跳停在写入阶段，应清理临时文件并从该阶段重跑。
多Agent工作流中，幂等性为什么重要？如何实现？
同一调用因网络超时被重试时，上游应得到相同产物标识，或明确生成新版本；下游消费成功后写入收据，避免同一结果被处理两次。对于会产生费用、发送消息或改数据库的动作，共享文件只能做协调证据，最终还需要事务键或外部系统的幂等令牌。
Manifest本身如何版本化以支持多团队独立升级？
新增可选字段通常能向后兼容，删除或改义则应升主版本，并在下游明确拒绝未知主版本。这样共享卷才从“大家都能看见的目录”变成可演进的接口。
使用共享文件系统进行多Agent交接有哪些边界与风险？
官方说明恢复会话依赖落在同一可用区，14天也不是永久保存承诺。共享进程空间和文件系统会扩大故障与权限影响面；不同团队独立发布时还可能造成格式漂移。哈希只能证明内容未变，不能证明内容安全或作者可信，生产环境还需要身份签名、最小权限、加密、配额、恶意文件扫描和审计日志。
立即可执行的检查表包括哪些内容？
为每个会话生成不可猜测ID；产物先写临时名再原子发布；清单包含生产者版本、输入摘要、输出摘要和时间；下游验证后才打开文件；每阶段写新版本而非覆盖；设置会话到期和清理策略；故障演练至少覆盖中途写入、重复调用、旧清单、跨会话误读和磁盘满。云上试验结束后，还要删除容量提供者、镜像、存储与相关权限，避免持续费用。
