在AI系统越来越复杂的今天，一个关键问题浮现：当AI做出决策时，我们不仅需要知道它做了什么，更需要知道它为什么这么做。这正是"推理账本"（Reasoning Ledger）要解决的核心问题。
作为《构建AI记忆栈》系列的第4.5部分，这篇文章源自第4部分引发的深入讨论。当时提出的核心观点是：智能体系统需要一个专门的层来保存决策的原因，而不仅仅是决策的结果。随后的评论交流演变成了一场关于单个账本记录应该包含什么内容的设计对话。
为什么字段列表不是最重要的
最省事的做法是直接给出一个数据模式（schema），列出字段让读者复制使用。但作者刻意避免这种方式，因为字段列表恰恰是最不持久的产物。不同系统的实现方式各异，字段名称会随实践漂移，如果只是照搬记录结构而不理解其背后的推理逻辑，最终只会变成无人维护的"货崇拜"式结构。
真正有价值的是那些决定什么该进记录、什么不该进记录的设计张力。把握住这些张力，字段可以自行推导；反之，任何数据模式都无法挽救。
因此，这篇文章的原则先行，记录在后。文末附有完整的记录示例和字段参考，并标注了哪些是核心字段、哪些是真正可选的。
起点：基础记录的样子
以下是第4部分提出的基础记录，作为合理起点，但讨论很快表明它在很多方面还不完整：
- 决策：批准部署
- 时间戳：2026-03-14T09:22:00Z
- 证据：ADR-014（架构评审，版本3）、安全策略（安全团队，版本7）
- 工具：GitHub、CI流水线
- 审批：发布经理
- 结果：已批准
下面每一条原则，本质上都是这个记录尚未表达的内容。
原则一：账本见证，而非强制执行
第一个张力是架构层面的，也是作者最坚持的一点。推理账本绝不能阻止、否决或门控它所记录的行动。它的职责是保存发生了什么、周围有什么证据。一旦账本能够阻止行动，它就不再是独立的见证者，而变成了它所描述机制的一部分，其自身的记录也就不再能被当作中立事实来审查。
讨论中有人指出，只做叙述的账本可能悄悄变成虚构，信任来自于能够门控而非仅仅描述。作者认同这一诊断，但将边界划得更早一步：强制执行是真实且必要的，但它属于策略和工具边界，而不是见证者内部。账本保存的是边界被评估过以及它返回了什么结果，边界本身决定行动是否继续。
对记录的实际影响是：账本条目可以包含一个"策略已评估"的结果，显示检查已运行及其结论，但绝不包含强制执行决定本身作为其权威。它报告，但不裁决。
这是核心原则，不是字段问题，而是整个设计的基础。
热门跟贴