ETF Agent的版本化产物与定向分享方案
一篇ETF Agent工程文章以教学场景说明，AI Agent如何把生成的报告作为带版本的Artifact管理，而不是仅返回文件名和URL。设计中的记录将文件绑定到固定内容摘要、所有者、生成任务、来源及保留信息。保存流程区分尚未提交、已提交和结果未知三种状态；下载时则核验当前访问者的会话、对象归属和分享记录。文章对比了指定账户分享与Amazon S3预签名URL，并指出Open ETF Agent v0.15.2公开教学版支持固定产物和本机只读阅读，但不具备完整的多账户分享能力。指定账户分享的行为来自文章中的方案描述，相关实现细节尚未独立验证；所述提交行为适用于本地文件存储，不能据此推断任意数据库与对象存储组合的原子性。
将报告生成、产物持久化和访问控制分开处理，有助于避免把结果未知的保存误判为失败、因自动重试产生重复输出，以及让一次版本分享意外暴露后续版本。
设想这样一个场景：Agent 为你生成了一份基金比较报告，你把它分享给同事。十分钟后，你补充了一个条件，Agent 又生成了一份报告，文件名仍然叫 comparison.html。
同事第二次打开原链接，应该看到哪一份？如果你撤销分享，他还能不能继续下载？假如生成时界面报了超时，文件究竟没有保存，还是已经保存、只是回执没有回来？
这些问题无法靠“把文件放到一个目录，再返回 URL”完整回答。
文件交付需要同时确定三件事：保存的是哪份内容，谁可以取得它，这次操作究竟发生到了哪一步。 本文以 ETF Agent 的文件链路为基础，用上述教学场景解释三者如何协作；它不沿用某一次真实用户研究的内容。
图示主题：版本、归属与定向分享的关系图。概览按职责组织，不是某次任务的真实调用记录。 完整配图见文末原文链接。
一、先确定交付对象：文件名不是版本，链接不是权限
在一次短演示里，report.html 似乎足以代表产物。但只要允许重新生成、后台执行或分享，这个名字就变得含糊：它表示文件用途，不能回答“是哪一次生成的哪一份内容”。