用"权威"这个词去形容数据库里的一行，其实挺奇怪的。那一行什么都不知道。我们真正想说的是：有人愿意直接拿它来做事，不用再自己推一遍——而这份"愿意"总得有个来源。
来源是这条记录进来的路上发生了什么。有四样东西必须活着穿过写入，而在大多数系统里，至少有一样悄悄地没活下来。
一、归因链通常断在"谁"这一环
问一个典型系统"这条记录哪来的"，你会得到 created_by: api_key_7、created_at: 2026-08-14T09:12:00Z。这标识的是一个凭据，不是一个成因。
你真正需要的链条有三环，而通常只有第一环被记下来：
- 凭据——哪个 key 写的。这个每个系统都有。
- 行动者——哪个 Agent、代表谁、在哪一次运行里。大多数系统把这一环塌缩进凭据里，于是共用一个 key 的所有 Agent 就再也分不开了。
- 场合——它产出这条记录的时候，被要求做的是什么。半年后，"CRM 里写着这单 40 万"是没法用的；"Agent 在总结这个客户时，从三季度续约那条线索里抽出了 40 万"才是你能顺着去查的。
第三环是把一条记录从"被记过"变成"可审计"的那一环，也是几乎没人存的那一环——因为写的时候它显得多余：你当时在场，你记得。归因是写给那个当时不在场的你的。
二、diff 必须是"可判断"的，不只是"可显示"
每个系统都能给你看改了什么。能让人在实际拥有的时间里做出判断的，少得多。
这笔账很不留情。改了 1 条记录：审核的人读 diff、想一下、决定——大概三十秒。一次提案改了 40 条、每条三个字段：同一个人真正投入的注意力还是那三十秒左右，因为后面排队的事一件都没少。
接下来会发生什么是可预测的，而且这不是纪律问题。审核不会停，审核会变浅。通过率照旧，只是不再有任何含义。而闭眼盖章比没有门更糟，因为它伪造了"有人看过"的证据。
所以"可判断"是一条有牙齿的设计要求：
- 按决策分组，不按行分组——38 条以同样方式改动的记录是一个决策，外加两个值得单独读的例外；
- 把例外顶上来——离群的值、被改了两次的字段、跟自己来源自相矛盾的记录；
- 让"否决"和"通过"一样便宜——如果否决意味着要写理由、还要重跑 Agent，那审核的人会为了躲开这份摩擦而通过那些边缘改动。
一道审核门值多少，完全取决于背后有多少注意力。按你真正拿得到的注意力来设计，不要按流程假设的那份。
三、来源必须活过"合并"这一步
大多数实现是在这里丢掉它的。审核过程中上下文很丰富——你能看到提案、diff、Agent 的推理。然后它合并了，落进表里的只有那个值。上下文搬去了审计日志，在另一张表里，靠时间戳和记录 id 关联。
技术上什么都没丢。实际上丢了，因为半年后没有人会去做那个 join。他们看的是那条记录，而记录上写着 400,000，完全不记得自己曾经是别的样子。
判断标准很简单：只看这条记录本身，能不能说出它从哪来、谁批的？ 如果需要先知道有一张审计日志表存在、还得会查它，那来源就是你"有的一个功能"，不是这条记录"具备的一个性质"。
四、被否掉的改动是证据——留着
本能是把没通过的东西扔掉。这个本能是错的。
一份被否掉的提案，是关于"你决定不让什么变成真"的唯一记录。它告诉你哪个 Agent 产出的是"看着合理其实错的"东西、哪条提示词在漂移、哪个上游来源不可靠。删了它，每一次否决就变成一件只在某人脑子里发生过一次的私事。
还有第二个理由，不那么明显但更重要：留着否决记录，是一个记录系统对自己诚实的方式。 一个只记得自己被采纳过的历史的存储，是在给你讲一个"我一直都对"的故事。那些被否掉的版本，才是证明判断真的发生过的部分。
为什么权限和审计日志顶不上
这两样经常被拿来当答案。都不是。
权限决定的是谁可以写。那是一道画在能力周围的边界，而且是在没人知道要写什么之前就画好的。一个对客户表有写权限的 Agent，可以往客户表里写任何东西，包括格式完全正确、事实完全错误的东西——而这恰恰就是问题本身，因为那正是 Agent 会产出的东西。
审计日志记录的是发生过一次写入。按定义它是事后写的。审计日志是你周四发现周二哪里出了问题的方式。它确实有用，但它不是控制手段，因为它从头到尾没给任何人一个说"不"的机会。
两者留下的是同一个空缺：在 Agent 写入和记录成真之间，有一个人本可以拦下来的时刻。那个时刻不是权限，也不是日志。它是一个状态——"已提出，但还不是真的"——数据模型必须能表达它。如果你的 schema 里没有办法存放一个"存在但还不成立"的改动，那么再多流程也换不来一个记录系统。
落到实践上长什么样
不是每次写入都配得上这一套。全都套上去，正是团队最后养出一个没人读的审批队列的原因。
按后果划线，别按习惯划线：
- 不设门——草稿、临时演算、检索缓存，以及任何 Agent 下一轮就会覆盖掉的东西。
- 设门——会被下游系统读走的、会被人引用的、以及任何旁边挂着客户名字或监管名字的东西。
然后把设门的量控制在一个人真的顾得过来的范围内。如果队列涨得比消化得快，答案不是找个更快的审核人，而是门后面的东西少一点、分组好一点、或者 Agent 的任务范围收窄一点。
Busabase 是怎么实现的
接进 Busabase 工作区的 Agent 不写入，而是开一个变更请求：一份装着全部意图改动的提案，待在正式数据之外。人读 diff，合并或者不合并。合并的记录把归因带在身上——哪个 Agent、哪个请求、哪个审核人——挂在记录本身上，历史永久保留，包括被否掉的那些版本。
某一次写入到底会不会停下来等人，由凭据的权限级别决定，不由 Agent 的自觉决定。这是刻意的：一条你能指着看的强制边界，胜过一个你得在每次调用里都记得维持的习惯。
关于"为什么这些东西才让一个存储具备权威性"的完整论证，在面向 AI Agent 的记录系统。比起读，你更想直接看这套机制的话，接入你的 Agent，让它提一个你可以否掉的东西。