ETF Agent’s Approach to Versioned Artifacts and Targeted Sharing
An ETF Agent engineering article uses a teaching scenario to explain how an AI agent can treat a generated report as a versioned Artifact rather than simply a filename and URL. The proposed record binds a file to a fixed content digest, owner, generating task, source and retention information. The save process distinguishes not-yet-committed, committed and unknown states, while downloads check the current visitor’s session, object ownership and sharing record. The article contrasts account-specific sharing with Amazon S3 presigned URLs and notes that the public Open ETF Agent v0.15.2 teaching version supports fixed artifacts and local read-only viewing, but not complete multi-account sharing. The account-specific sharing behavior is described in the article, but the implementation details were not independently verified; the described commit behavior is specific to local file storage and does not establish atomicity across arbitrary database and object-storage combinations.
Separating generation, artifact persistence and access control helps prevent uncertain saves from being treated as failures, duplicated outputs from automatic retries, and a share for one version from exposing a later version.
设想这样一个场景：Agent 为你生成了一份基金比较报告，你把它分享给同事。十分钟后，你补充了一个条件，Agent 又生成了一份报告，文件名仍然叫 comparison.html。
同事第二次打开原链接，应该看到哪一份？如果你撤销分享，他还能不能继续下载？假如生成时界面报了超时，文件究竟没有保存，还是已经保存、只是回执没有回来？
这些问题无法靠“把文件放到一个目录，再返回 URL”完整回答。
文件交付需要同时确定三件事：保存的是哪份内容，谁可以取得它，这次操作究竟发生到了哪一步。 本文以 ETF Agent 的文件链路为基础，用上述教学场景解释三者如何协作；它不沿用某一次真实用户研究的内容。
图示主题：版本、归属与定向分享的关系图。概览按职责组织，不是某次任务的真实调用记录。 完整配图见文末原文链接。
一、先确定交付对象：文件名不是版本，链接不是权限
在一次短演示里，report.html 似乎足以代表产物。但只要允许重新生成、后台执行或分享，这个名字就变得含糊：它表示文件用途，不能回答“是哪一次生成的哪一份内容”。