审计日志的最小集，我现在的答案是六项：会话 ID、模型版本、prompt 哈希、工具名与参数、耗时与成本、有没有人接手。难的不是这六项，是第七项要不要加——原文。加，合规那边过不去；不加，出事那天你连复盘的门都摸不着。我的解法是按结果切开：成功的存哈希，失败的和人工介入过的存原文，两套保留期分开管。
六项够了，但每一项目前留得都不对
会话 ID 不是 request ID。一次会话里可能有几十次模型调用，你要能顺着它串起来。这周有篇讲 Global Coherence 的论文说的就是这个：每个 agent 局部都对，合起来错。这种错在单条记录里根本看不出来，只有把同一会话的记录排在一起才显形。所以会话 ID 得能 join，别在中间重新生成。
模型版本我建议留到部署点那一级，不然三个月后你复现不出来当时到底跑的是什么。工具名与参数这块，参数的脏程度往往超过 prompt——SQL、文件路径、URL、客户 ID 全在里面。
人工介入我只留一个 boolean 是不够的，得留"在哪一步介入"和"介入前 agent 想干什么"。不然事后你只知道有人踩了刹车，不知道刹车踩在哪。
哈希得加盐，不然等于没哈希
我同意 prompt 存哈希不存原文。理由是原文里全是用户数据，而日志库通常是整个系统里权限最松的地方。HN 上那篇对话式 AI agent 的隐私分析讲的差不多是同一件事：你以为你留的是 prompt，其实是可追踪的指纹。
但哈希有个坑：不可逆不等于不可枚举。模板化的 prompt、短 prompt，拿字典撞几下就出来了。所以得加盐，盐按租户分，别全局一个。这一条没做，前面那套设计就是自欺欺人。
失败路径不留原文，等于放弃复盘
成功路径你已经知道结果是对的，留原文只是给自己找合规麻烦。失败路径不一样，你要回答的问题是"它当时到底看到了什么"。
麻烦在于，最典型的失败不是某一次调用错了，而是整条链子错了。这就要求失败时不止留那一次的原文，还得留同一会话里前几步的。留几步？我没法给你一个数——我的做法是拿最近两周的失败案例回放，看平均要往前追多少步才够，那个值随你的工具粒度变，测一次就知道。
保留期拆成三档，别用一个 TTL 打天下
第一档，成功路径的哈希和元数据，跟你的审计周期走，长留。第二档，失败与人工介入的原文，短留，到期自动脱敏或者删掉。第三档，安全相关的——权限被绕过、越权调用那种，Meta 那个 Muse 忽略用户权限的事就是例子——单独设一档，留得比第二档久。
顺带说一个容易忽略的点：Argo-Bench 那篇提到，现有 benchmark 的答案键经常是错的。审计日志也一样，你留的日志本身可能不准——耗时从哪一刻开始算，成本包不包含重试，这些口径不定清楚，攒一年数据也是白攒。要么定期抽样人工核对，要么把"日志可信度"本身当成一个指标。
这周的外部信号：硬件在来，schema 还得自己写
Nvidia 在推给每个 agent 配一颗监控芯片。方向我认可，但它监控的是行为不是语义——芯片能告诉你这个 agent 调了多少次工具，不能告诉你第几次那次该不该调。schema 定错了，硬件只会让你更快地攒一堆没用的数据。
还有那篇 There are no "rogue" AI agents，论点我基本同意：所谓失控，大多是权限、上下文、评测的锅。这恰好是审计日志存在的理由——不是为了抓一个坏 agent，是为了出事后能指出是哪一层错了。
也许半年后回头看，"失败留原文"这条会被推翻，比如厂商开始提供可信执行环境，或者这周那篇 FHE 强化学习 那条线真能落地。按我现在看，先把盐、保留期、抽样核对这三件事做扎实，比继续往字段列表里加东西有用。