每次 AI 智能体运行该记录什么
作者 Inès L. 和 Noah Schmidt8 分钟阅读
一个在演示里跑通的 AI 智能体只证明了一件事：它能成功一次。生产环境提出的问题更难：当它出错时，你能不能说清发生了什么、以及为什么？
如果答案是不能，你运营的就不是一个系统，而是一份期待。填上这道缺口的，是一份每次运行都留下的记录，且要能被你团队之外的人在几个月后读懂。
一句话要点
- 你的监控面板不是审计记录。读者不同、时间尺度不同、规则也不同。
- 标准的 AI 追踪默认不保存提示词和回复，需要你主动开启。
- 审计记录绝不能抽样。你将来必须解释的那次运行，往往就在被丢弃的部分里。
- 记录每一次工具调用及其结果、走过的分支、成本，以及谁批准的。
- 对于审批，要记录当事人实际看到了什么，而不只是「点了同意」。
面板不是审计记录
两者看起来相似，实则不是同一种东西。面板由它的作者在几分钟后阅读，事故还在脑子里。审计记录则由一个冷漠甚至敌意的第三方在几个月后阅读，而且他无法向你追问。
| 监控面板 | 审计记录 | |
|---|---|---|
| 谁来读 | 你，几分钟后 | 第三方，几个月后 |
| 抽样 | 正常，常见 10% 到 20% | 绝不 |
| 提示词与回复内容 | 通常关闭 | 开启，直到保留期结束 |
| 写入失败时 | 记一笔然后继续 | 该操作本身就应当失败 |
| 排序依据 | 时间戳 | 由你分配的序号 |
| 之后能否更改 | 能，这是设计如此 | 不能，只追加 |
| 失效后果 | 排查变慢 | 你无法回答那个问题 |
可观测视图里的一次运行：每一步、状态、耗时、成本。确实有用，但它仍是面板，而不是本文后面所说的那种可长期留存的记录。
「我们有追踪」不等于「我们有记录」
这是最让团队措手不及的一点。
业内追踪 AI 调用的标准约定，把提示词、回复、工具参数和工具结果都定为可选项，并且规范本身的立场是：工具默认不应采集它们。所以一套刚装好的追踪只给你模型名、token 计数、延迟和一个结束原因，全都不是能重建一个决定的材料。
打开内容采集也比想象中麻烦：至少在一个流行实现里，还必须启用另一个几乎没有文档的设置。请去核实你的系统究竟存了什么，而不是假设，并且用完整读一条真实记录的方式去核实。
同一问题的另一半，是几乎所有可观测性指南都会给的建议：量大时大幅抽样，并在数据进入后端前清洗内容。这两条对监控是合理的，对审计是致命的。当你必须为之辩护的那个决定落在另外 90% 里时，10% 的抽样毫无价值。
每次运行要记录什么
每次运行一条记录，这是别人最先读到的抬头。
| 该记录什么 | 为什么重要 |
|---|---|
| 在派发时生成的运行标识 | 其余一切都挂在它上面，生成太晚就会丢失 |
| 是谁或什么发起的，以及怎么发起的 | 人、定时、Webhook：这决定了谁负责 |
| 开始时间和结束时间，两个时间戳 | 时长无法与外部时间线对齐 |
| 计费的是哪个模型，实际跑的是哪个 | 两者可能不同，只记一个会让其余都失真 |
| 当时生效的价格 | 价目变动之后，成本仍然说得通 |
| 输入、输出、缓存的 token，以及花费 | 你的账单，也是你的早期预警 |
| 状态，以及为什么停止 | 你将被要求辩护的那个结论 |
| 当时生效的配置与策略版本 | 那一刻是否要求审批 |
| 当时运行的构建版本 | 这次运行是否早于修复 |
| 是否需要审批，及其引用 | 空值必须表示「不需要」，而不是「未知」 |
其中两点必须坚持。两个时间戳而不是一段时长，因为只有时间戳才能和别人的记录对上。以及当时的价格，因为价格和模型名会在你脚下变化，无法复现的成本就是无法辩护的成本。
有一样东西不该存：每次运行都存完整的系统提示词。按每天一万次运行算，一份 6KB 的提示词一年就是约 20GB 的纯重复。每个版本只存一次，然后引用它。
每一步要记录什么
每一次模型轮次、工具调用、判断或审批各一条记录。它们的数量大约是运行记录的二十五倍，并且承载了几乎全部内容。
| 该记录什么 | 为什么重要 |
|---|---|
| 真实顺序，由写入方分配 | 时间戳会打平、会乱序，计数器不会 |
| 是否有步骤并行执行 | 把并行批次读成因果链，比留一个空缺更糟 |
| 属于哪种步骤 | 模型轮次、工具调用、判断、审批 |
| 工具名与调用标识 | 在重试与乱序中把请求与结果对上 |
| 参数与结果 | 真实内容，按你为内容设定的保留期 |
| 两者的指纹 | 内容删除很久之后仍能证明发送过什么 |
| 内容的体量 | 让后来的读者知道发生过截断，以及截掉了多少 |
| 走了哪条分支 | 让这次运行在纸面上可复盘 |
| 某一步为什么没有执行 | 「被跳过」和「从未到达」是两个不同的事实 |
| 错误码，与错误消息分开 | 码可查询；消息常常把出错的输入原样带出来 |
| 是否执行了脱敏 | 否则一条看起来干净的记录什么也证明不了 |
指纹那一行是这张表里低调的主角。为进出内容各留一个哈希，每一步只多花几个字节，却能让你在几个月后删除内容的同时，把证据保留数年。当有人拿出一份文件、声称你的智能体看过它时，指纹就能定案。
一点必要的提醒：对可枚举的内容（比如邮编或出生日期）做哈希，可以靠穷举反推。这类字段必须用单独保管的密钥加盐。
审批记录值得单独一行
如果有人做了审批，就把它当作一条独立记录，而不是运行上的一个标记。
记下谁批准、何时、通过什么渠道、超时前有多长时间，以及最重要的：审批人实际看到了什么。把那段文本在运行暂停的那一刻冻结，并与记录一起保存。否则「有人批准了」什么也说明不了，因为没人知道他当时在批准什么。
同一处还有三个小陷阱。空的审批字段必须表示「当时生效的策略不要求审批」，这就要求策略版本可被追回。像「system」或「api」这样的默认身份，绝不能与任何真实人员重名。如果你的记录里写了审批人角色，就要确保确实有东西校验过这个角色，否则就在记录里明说没有校验。
两个会悄悄毁掉记录的错误
用「尽力而为」的方式写入。 如果审计写入是发出去就不管、失败只记为「非关键」，那么你的记录会在系统承压时变稀疏，也就是恰好在你将被要求解释的那些事故期间。覆盖率于是与系统健康度相关，这是最糟糕的性质。把记录写在它所记录的那件事的同一个事务里。
只存时长而不存时间线。 听上去无关紧要，直到有人要求你把记录和客户邮件的时间戳对齐，而你做不到。
常见问题
我的模型服务商不是已经记录这些了吗？
他们记录的是他们那一侧的调用，按他们的保留期、他们的格式，而且你无法把它当作证据来查询。你能辩护的记录，是你自己保存的那份。
什么都记录不会很贵吗？
骨架部分（标识、时间、状态、计数、指纹、分支）非常小，按每天一万次运行算，一年也就几十 GB。昂贵的是内容，这正是它应当走更短保留期的原因。这种切分正是 该保留多久 的主题。
日志里的个人数据怎么办？
假定其中有个人数据，尤其是错误消息，它们经常把出错的输入原样带出来。标识保持假名化，内容走短保留期，长期保留的部分只留指纹和错误码。
我怎么知道记录是否够用？
取上个月的一次运行，只用已存储的记录把它从头到尾还原一遍。如果你需要重跑任何东西，或者需要问同事，那就还不够。
下一步
拿一次真实运行，尝试只凭记录把它解释清楚。凡是你不得不猜的地方，就是下一个要补的字段。然后决定每一部分需要存活多久：AI 智能体审计记录该保留多久。