Agent 的中间结果要不要落盘？要，但别一视同仁。我的分法很土：工具的入参出参全量存，模型的思考过程只存摘要，失败的链路单独留长一点。反面那句也成立——全量存推理过程，绝大部分永远不会被读，成本会在几个月后开始咬人。这两句话不矛盾，矛盾的是把它们当成同一个决定。
出事那天，你才发现手里什么都没有
HN 上挂了一天第一的是 rubyhack.ai，说 OpenAI 的 agent 在 RubyGems 上做了一次没披露的攻击。九百多分的讨论里，一半在骂厂商，一半在问同一个问题：它从哪一步开始走偏的？
这个问题只存最终输出答不上来。你看到的是"某个包被推上去了"，看不到第一次工具调用、看不到它什么时候拿到凭据、看不到中间有没有人点过确认。事后取证要的是调用序列，不是结果。
同一周 Perplexity 用 Astra 做端到端系统，OpenAI 那篇的措辞是 checks in much less frequently than with earlier models。人介入越少，事后追溯越是你唯一的抓手。这不是可观测性的加分项，是能不能上生产的前提。
存了，不等于有人读
HN 上那个 i-have-ADHD 挺有意思，它干的事很朴素：不让 coding agent 把答案埋在几十屏输出里。这反过来证明一件事——过程数据就算全落了盘，默认状态也是没人翻。
danluu 那篇讲 agent 怎么用测试和验证手段结论挺克制：agent 会跑测试，但用得好不好另说。测试输出是中间结果里性价比最高的一类，结构化、可回放、能直接变成回归用例。可惜多数团队把它和 stdout 一起冲掉了。
该全存的全存，该摘要的摘要
工具入参出参存全文。它结构化、体积可控、能重放，还能拿来做 eval。这部分别省。
模型的思考过程存摘要。reasoning token 体积大、噪声高，而且换个模型版本语义就对不上了。我只留三样：起止时间、token 数、一句关键决策摘要。摘要可以让模型自己写，也可以规则抽，别指望它精确。
失败的链路单独一份。成功跑完的 trace 是冗余，失败的 trace 是样本，也是现成的 eval 集。
存储成本会咬人，但它不该是第一个问题
OpenAI 那篇讲存储扩容的文章说 Habitat 要扛 10 亿用户、每秒 2200 万请求。那是用户数据的量级，agent trace 比这个小得多。但性质一样：只增不减、写入便宜、读取率低，还经常带 PII。典型的存得起、养不起。
我的估计是 trace 的实际读取率非常低。但这是估计，别信我。给 trace 表加一列 accessed_at，跑一个季度看分布——比任何人拍脑袋都准。
保留期倒着推
不要从存储单价推保留期，从"你想复盘多久以前的问题"倒推。
先回答三个问题：客户投诉多久内冒出来，事故复盘通常往前看多远，合规审计要求留多久。这三个答案决定保留期，跟对象存储便宜多少没关系。
失败案例单独设更长。还有一点容易漏——把"存下来"和"查得到"分开算。存一年但检索要跑半天，等于没存。索引和采样策略得一起设计，不然半年后你自己都不想打开那张表。
按我现在看，多数团队的问题不是存太多，是存得太随意：该留的没留，不该留的堆了一堆，出事时谁也找不到那一步。也许六个月后回头看，我对摘要那部分的判断会被打脸——如果那时候模型的 reasoning 能便宜到随便存的话。