八月底 Ken W Alger 往 AI Memory Stack 系列里插了一篇 Part 4.5。编号本身就是信息：不是新开一章，是补丁，补的是 Part 4 底下二十条评论吵出来的那点共识——一条推理账本记录到底该装什么。文章注明最初发在 kenwalger.com，dev.to 上的版本挂了 agents、ai、architecture、llm 四个标签。
单看只是个社区里的小动作，放到 agent 基础设施这条线上，位置就不一样：这个系列还没走完，讨论已经从"要不要留决策原因"进到"inherited 这种获取方式要不要带 inherited_from 指针、继承证据的可信度按链条哪一环算"。一个概念在几周内从表态走到字段级施工图，通常意味着后面有人真要照着建东西，而不是又停在喊话那一层。
先把镜头拉远。模型层、壳层、场景层这套棋盘我今年反复用，遇到新东西习惯先往格子里放。推理账本放哪层：它不是模型层的能力项，模型不给这个；也不是壳层那种工作流整合，壳层能把工具调用串起来，串起来不等于事后有人讲得清为什么这么串；它站的坑位是"一次决策发生之后，能不能有人站出来为它辩护"，场景层里最不性感的一块。
这里得认个旧错。此前我把 agent 编排能力归进了壳层，判断是它属于工作流整合，不构成新的护城河。后来看下来格子放错了：能不能让 agent 在真实项目里连着跑几小时而不脱轨，靠的是权限设计和信任积累，不是壳层的组织能力。框架放错格子比没有框架更麻烦，因为它会让你误以为自己已经想清楚了。
回到那篇补丁。第一条原则就把整套设计的调子定死了：账本只作见证，不能执法，不能阻断、否决或门控它记录的行动；执法放在策略和工具边界上，账本可以记录某次策略评估的结果，但不能把执行决定本身当成自己的权威。这条看着像谦逊，其实是定位。账本一旦拿到否决权，写账本的人立刻有了动机把记录往对自己有利的方向写，账本就从证据变成了辩词。审计里最贵的东西是"当时到底发生了什么"，而任何带惩罚权的记录机制都会扭曲这件事，这是几十年的老教训，不是这一代 agent 才碰上的新问题。
第二条原则接着往下压：取代关系要作为新事件写进去并指回旧记录，不许改写或覆盖原记录。评论里 Mudassir Khan 补的那句我觉得该刻墙上——压缩可以生成当前状态的投影，但被改写的证据无法还原。这跟 git 的追加式历史是同一个机制，压缩产物只能是派生视图，不能反过来替换原始证据。
第三条是我在这篇里最想拿出来的。evidence 里要有个 obtained 块，记录这个权威版本是怎么拿到的：来源、获取方法、检索时间，以及这次拿的是不是缓存状态。理由是，如果外部权威早就变了而系统没观察到，账本能做到完全自洽却已经过时；所以记录获取方式的价值，是把"检查过、但拿到的是旧数据"和"从未检查过"这两件事分开。它们在事后追责里天差地别，可只看一个版本号，长得一模一样。
Sergei Parfenov 在评论里又把这条往前推了一步：inherited 这种获取方式得带指针指回它从哪儿继承来，而且继承证据的可信度取链条上最弱的一环。这是审计里的信任链逻辑，一旦承认它，账本的可信度就不再是个二值开关，是一条链上最弱的那段说了算；agent 之间互相传证据时会自动带着衰减，而不是各说各话地互相担保。双时间戳那条同理：事实在现实世界里成立的有效时间，和系统记录这条断言的断言时间，是两个轴，分开存是为了不拿后来才获得的知识去评判当时的决策。这手艺数据库圈子用了很多年，搬到 agent 决策上正好卡住那个最常见的甩锅方式。
然后是我最想站队的一条：账本要保留落选方案和反证，被考虑过的备选要有 rejection_reason，不利证据要有 disconfirmed_by，还要记 unknowns 和 scope_limitations。但作者划了一条线，只记录决策过程中明确出现过的备选路径，不重建模型全部的内部思维。这条线划得对，而且比它看起来重要。现在不少所谓"可解释性"的做法，是把模型的推理文本当成审计材料收起来，行业内谁都看得出来那些文本跟真实计算过程的关系有多松。推理账本不是思维记录，是决策记录；思维记录注定残缺且不可验证，决策记录是可以对外举证的。把这两件事混在一起，是这一轮 agent 叙事里最常见的偷懒。
stakes 分级那条顺手把边界也划清了：哪些决策算高利害、需要把可选字段升级成核心字段，由治理侧定，不能由被审计的 agent 自己声明豁免。这句话把账本从"开发者工具里的一个功能"挪到了"组织治理结构的一部分"——前者可以是一个开源库，后者得有采购预算和责任人。设计里还处理了一个技术人容易忽略的点：账本不能声称自己在两次检查之间持续拥有权威，只能声明在某个特定时刻观察过权威；再验证放在查询时做，而不是后台定时轮询，结果作为新事件追加进去。老实得有点狠，等于承认账本永远慢于现实半步，它缩小差距，但消不掉差距。作者也直说了，账本只能见证已观察到的内容，补不回系统从未获得的知识。
Part 5 预告要谈写侧保管，也就是怎么保证记录事后没被篡改，作者把记录设计和完整性保证明确当成两项不同的工作。顺序本身有信息量：先定原则，再管完整性。反过来说，一个团队先去做防篡改，再回头想自己该记什么，多半会做出一套很牢固的、记错了东西的账本。
然后推分野。这堆设计会走到哪，我看到三条路。一条是账本变成企业采购里的硬条款，类似今天的合规审计材料，先被写进大客户的采购清单，再倒逼工具厂商支持；前提是监管或某个大客户先动，而且动得比供应商自己快。一条是被模型厂商吞掉，做成"可审计执行环境"的内置能力，跟沙盒、权限、审计日志捆在一起卖；前提是企业愿意接受供应商自证，而这恰恰是审计这件事上最不该被接受的假设，所以这条路我认为阻力最大。还有一条是停在开发者社区里，变成一份公认的最佳实践，但没人愿意为它单独付钱——这条路最省事，也最可能被默认。
我压第一条，而且是这篇里我压得最重的判断：账本作为独立治理层的需求会先在企业侧出现，不会先在开发者工具侧出现。辩护需求天生是组织性的，个人开发者不需要为自己的决策辩护，是团队、合规、法务、以及出了事要有人签字的地方需要。这决定它第一笔钱从哪来，也决定它先长成什么形状——不是插件市场里的一个扩展，是采购流程里的一行。
方向我此前看对了，但压得不够重：当时觉得"可审计"是个合规尾巴，不是主战场，后来看它更像场景层准入的一部分。
证伪条件摊在这儿：接下来两三个季度里，如果主流模型厂商把可审计执行环境做成默认内置、企业点头接受供应商自证、独立治理层在采购预算里一分钱拿不到，那这个判断就该扔掉，方向判反了。