AI agent 系统一旦从聊天走到执行，就会开始疯狂地产生 artifact。浏览器自动化留下截图和 DOM 快照，代码任务留下 patch、log 和构建产物，调研任务留下引用、摘录和候选结论。最开始这看起来甚至像好事，因为这些中间产物让系统更容易恢复、更容易解释，也更容易复盘。
但只要量一起来，artifact 很快就会从“帮助恢复的抓手”变成“谁也不敢碰的数据堆”。你会遇到三种同时出现的压力：热存储成本上涨、读取路径越来越慢、删除和审计边界越来越模糊。更麻烦的是，大多数 artifact 其实不会再被看第二次，可一旦真出了事故，恰恰又是这些东西最能说明问题。
所以 artifact retention 真正要解决的，不是省几块钱存储费，而是把“以后可能有用”这件事结构化，而不是一股脑全留在热路径上。
建议结合 AI agent Artifact 中间产物设计、AI agent Session Store 设计、AI agent Run Ledger 审计模型 和 AI agent Plan Drift 检测与再规划触发 一起看。
先给一个分层表：不是所有 artifact 都值得待在热存储
| Artifact 类型 | 常见示例 | 最常用时段 | 更适合的存储层 |
|---|---|---|---|
| Working Draft | 中间草稿、暂存 patch、候选摘要 | 当前 run 正在执行时 | 热存储 |
| Recovery Snapshot | checkpoint、关键 step 输出 | run 失败或 wake 恢复时 | 温存储 |
| Audit Evidence | 审批快照、外发前版本、关键引用 | 事故复盘、合规核查时 | 温存储或冷存储 |
| Heavy Debug Payload | 全量截图、trace、HTML dump、浏览器录像 | 只在严重故障时查 | 冷存储 |
| Derived Index | 摘要索引、检索片段、embedding 中间层 | 召回或搜索时 | 专用索引层，单独 TTL |
如果你把这些东西都放在同一层里，最后得到的不是“统一”，而是热路径越来越臃肿，任何清理动作都像在拆炸弹。
真正该保热的，只有“正在帮你做判断”的那一层
判断一个 artifact 是否该留在热存储里，有个很朴素的标准：它是不是当前 run 接下来几步还要直接使用。如果答案是否定的，那它大概率不该继续占着最快、最贵、最容易被误读的那一层。
例如：
- 当前正在迭代的 patch 和草稿，需要留热
- 已完成步骤的截图和日志，多半只在恢复或复盘时才会用到，可降温
- 已经通过审批并外发的最终版本，不该和未确认草稿混在一起
很多系统之所以越来越难救，不是因为 artifact 太多，而是因为所有 artifact 都在假装自己“眼下还很重要”。
Metadata 和大对象要分开，不然你永远不敢清理
更稳的做法，是把 artifact metadata 和内容本体拆开。metadata 用来回答：
- 这是什么产物
- 来自哪次 run / step / tool
- 当前状态是什么
- 保留理由是什么
- 过期后该降到哪一层或删除
而内容本体，例如截图、录像、完整 diff、HTML dump，则放到适合的大对象存储里。这样做的价值在于：你可以在不搬动大文件的情况下先改策略，也可以在不丢索引可见性的前提下降温或归档内容。
如果 metadata 和本体混在一起，团队最终通常会进入一种熟悉的停滞：知道该清了，但没人敢动，因为根本说不清删掉的是“几个无用截图”还是“下周事故排查唯一的证据”。
保留策略最好围绕三个问题，而不是统一天数
Artifact retention 最适合围绕这三个问题设计：
- 这个产物还要不要参与恢复？
- 这个产物还需不需要用于解释或审计？
- 这个产物是不是还能被别的 run 直接复用？
这三个问题会导出三种完全不同的命运：
- 还能参与恢复的，优先保温，不要直接删
- 只为审计存在的，保留索引和最小必要副本
- 纯临时调试产物，过了窗口就降冷或清理
很多团队喜欢先定“30 天保留”或“90 天保留”，但真正到实现层就会发现，同样是 30 天，checkpoint 和浏览器录像根本不是一个重量级对象，理应用不同方式存、不同方式删。
一个很典型的事故：调试文件删得太快，恢复窗口却还没关
某团队为了压成本，把失败 run 的大对象截图统一改成 24 小时自动清理。两周后，一批浏览器 runner 因页面反爬改动开始间歇性失败。问题在于：
- 错误通常在 36 小时后才被客户支持团队汇总出来
- session log 还在
- error code 还在
- 真正能说明页面当时发生了什么的截图，已经被删光了
于是大家只能对着一个“selector not found”猜半天，到底是页面改版、登录失效，还是区域网络问题。
最后他们没有回到“全部永久保存”，而是把 retention 改成分级：普通失败截图 48 小时降温，P1/P0 事故样本一旦被 incident system 关联，就自动提升到 audit tier。这个做法的关键不在于多存一点，而在于让保留策略会响应故障等级，而不是死板按创建时间清理。
成熟系统的清理动作不是 cron，而是状态迁移
真正可控的 artifact cleanup 更像状态机，而不是定时器。一个 artifact 可能经历：
workingsealedwarm_retainedaudit_retainedcold_archivedpurged
一旦你用状态迁移来做 retention，很多原本难解释的问题就清楚了。比如，为什么这个截图还在？因为它从普通失败样本升级成了 incident evidence；为什么这个草稿被清了？因为 run 已完成且没有被任何下游引用。
这比“每天凌晨删 7 天前文件”更像生产系统，也更容易回答客户和内部审计的问题。
真正该先做的，不是多建一个存储桶，而是先定义晋升条件
如果你今天就要开始补 artifact retention，最值得先补的不是再建一个 archive bucket，而是定义“什么东西值得晋升到更长保留层”。因为不是所有 artifact 都配得上审计级待遇，真正值得长留的通常只有三类：
- 会直接影响恢复能力的
- 会直接影响责任判断的
- 发生事故时最能解释现场的
一旦这个晋升条件被说清楚，团队才会愿意清理其余那些只是“也许以后有用”的大对象。否则系统只会一边抱怨成本，一边什么也不敢删。
延伸阅读：
