AI 审计证据之二：沉默会被读成完整

一个审计员拿到一份证据包，哈希链校验通过。

他会读成什么？

多数人会读成两件事：这些记录没被改过，而且全在这里。

链只证明了第一件。它证明不了第二件：把最后几行删掉，剩下的链仍然自洽。

这篇文章提议一件事：每一份证据包都附一份覆盖声明，用数据说出它读了什么、看不了什么；这份声明要跟包一起被签住。

一、链证明的，与它不证明的

哈希链的性质是：每一行都带着前一行的摘要。改一行，后面的行对不上；删中间一行，链断；换顺序，断。

但它防不住从尾部删。删掉最后几行，留下的是一个更短的、完整自洽的链。

所以「链校验通过」回答的是内部一致性，不是完整性。完整性需要另一个东西：一个在链之外的锚，比如定期把链尾摘要写到别处。

这不是实现细节。它是读者会做的推断：一份没有说明自己边界的记录，会被读成完整。

二、现场：一条我们故意没写进表的缺口

我们维护一份缺口登记表。它的每一条，都是「这份包看不了什么」。

截至这篇，表里有 11 条。

但有一处，是故意不在表里的：有一种猜测认为「副作用行显示不了『谁』」。我们没有把它写进去，因为它是否仍然成立，还没核定。本仓的副作用实体是带 owner 的；那句读数可能只是「实体有、端点不透」。

一条未经核实的缺口，比没有更糟。它会给每一份包挂上一句假的告诫，而读者没有办法分辨哪一句是真的。

所以我们的测试里有一条，专门钉住这个缺席：断言表里找不到它的由来。

这可能是最反直觉的一条：这一条测试不测「有」，测「没有」。

它也说明覆盖声明本身要有覆盖边界：我们只能声明我们核实过的缺口。

三、缺口是数据，不是散文

如果每份报告都手写一段「本报告可能不包含……」，那段话会慢慢和系统漂开。有人改了采集，忘了改告诫；或者反过来。

所以缺口只存在一处。每一条长这样：

• 一个稳定、永不复用的 id；
• 严重度；
• 影响的是这份包，还是整个部署；
• 一个谓词：它读一组闭集的事实，全部成立时这条缺口适用于这份包；
• 一句英文声明（这是上 wire 的文案字段）；
• 一个内部由来（不上 wire）。

闭集是刻意的。一个什么都能读的谓词，没人能对它求值；而条件求不了值的条目，只能永远算「适用」，那又回到了「沉默即完整」。

于是每一份包声明的，是真的适用于它的那些缺口，而不是一份会漂开的手抄清单。

加一条缺口，只改登记表，前提是它读的是现有事实集里的东西。声明会自动多一条，服务代码一字不用动。这是结构上的：改登记表，声明里的「登记表版本」跟着变。服务代码里搜这 11 个缺口 id，命中 0。

四、覆盖声明里有什么

先把「声明」从文案变成对象。我们的证据包里，这一段现在是这些字段：

• registryRevision：这份声明按哪一版缺口登记表算出来的；
• scope：它覆盖的是单条动作、一个期间，还是一个实体，起止时间与主体；
• sources：真的读过的源，每个带状态与行数；
• verdict：complete/partial/unknown；
• gaps：适用于这份包的缺口，每条带 id、严重度、影响范围与一句英文声明。

这是一份「能机读的声明」的最低形状。它回答三个问题：按哪版规则算的、读了什么、结论怎么读。

如果你想把「人工复核」也放进来，要补的不是一句话，而是三个字段：复核状态、确认人、确认时间；再加一个「例外原因」：为什么某一项没覆盖、谁接受了这个例外。这些字段今天不在声明里，它们在授权与确认行上。要放进来，得先决定跨表取数，并保证它们也进签名。否则补进去的只是又一段会漂的文案。

签名/哈希这一格也要说清：声明不单独签，它作为整包规范串的一部分被签住。单独给声明一个哈希，是另一个设计。

五、结论是算出来的

登记表还要给出结论怎么读。我们的规则只有三条：

• 没有适用的缺口 ⇒complete；
• 只要有一条缺口说「连漏了什么都说不出」 ⇒unknown；
• 其余 ⇒partial。

关键在这三条之外还有一层：unknown不是更强的partial。partial的意思是「我知道漏了什么」；unknown的意思是「我连漏了什么都说不出」。

把unknown报成partial，等于声称我们知道漏了什么，而那正是那条缺口说我们不知道的事。

结论不手写，是算出来的。手写的结论会变成另一个会漂的值。

六、声明要跟包一起被签住

覆盖声明如果只是包旁边的一段附注，它可以在事后被改写成更好看的版本，而签名照样通过。那这一段就是装饰。

所以在新一版证据包里，覆盖声明是必填段，并且进入签名覆盖的规范串。离线校验器遇到这一版包，先看这一段在不在；不在就直接判失败。

同一份声明还要说清「问了谁」：只列这份包真的读过的源，不是系统里有哪些源。列一个谁也没查过的源，恰恰是整件事要打破的那种沉默。

签名签住的是这份声明的内容。而内容里有两处不是算出来的，只能写死。两处都不是乐观值。

一是「是否有一个缓存服务多个部署」。代码看不见第二个部署。对本仓支持的形态（一个部署、一套库）取否是正确的；那条缺口留在表里，给不支持的形态用。今天没有这个输入口，我们如实记下，而不是糊过去。

二是「包里有没有外部锚」。外部锚没有端点（我们实测过）。所以包带不了它，声明于是说unknown，而不是假装链就够了。

把这两条写得这么具体，是因为它们说明这份声明想做什么：它不承诺完整，它指出哪里不完整。

七、三种常见的「只有」

• 只有 trace，没有声明：读者会把「这里没有这条 trace」读成「没有这个动作」。trace 的缺席和动作的不存在，是两件事。
• 只有审批通过，没有审批范围：批准了一次调用，不等于批准了这次执行的全部参数与目的地；范围没写，后面的人只能靠猜。
• 只有日志，没有完整性校验：日志能被改；链能证明内部一致，但尾部仍可删。没有外部锚，完整性就还是一句推断。

三者指向同一件事：记录的存在，不等于覆盖的成立。

八、这条设计划不到的边界

覆盖声明能让不完整变可读，不能让审计变完整。

它只能覆盖我们算得出的事实。算不出的，只能进unknown，或者——如果是连是否成立都没核实的猜测——干脆不进表。

事实集是闭集，这既是它的形状，也是它的天花板：一条需要新事实的缺口，不是往表里加一行就能出现的。

所以它不是一份合规证明。它是一份使用说明：告诉你这份包能回答什么，不能回答什么。

九、一个你可以自己做的检验

四问：

1. 你的证据包有没有一句话说出它没读什么？如果只有「校验通过」，读者会自己补上「应该是全的」。
2. 这句话是手写的，还是从一份登记表算出来的？手写的那份会漂。
3. 结论是写上去的，还是算出来的？尤其是unknown会不会被降级成partial。
4. 这份声明在签名范围里吗？不在的话，它可以在事后被改写而不破签。

如果你的系统里有高风险 Agent 会话，最省事的落地不是加一个报告页，而是把证据包生成变成会话结束时的自动动作，并把覆盖声明作为包的必填段。声明由系统算，不由写报告的人填。这是它和一段免责声明之间的区别。

结语

回到开头：沉默会被读成完整。

我们做的是：缺口只此一份（11 条，全部带由来）；谓词读闭集事实；结论由事实算出，unknown不降级；覆盖声明进签名；只列真的读过的源。

下面这套取自开源项目 KeelBase 的实现—— 一个夹在 AI Agent 与企业业务系统之间的运行时，在工具执行前重新检查身份、授权、范围、风险与确认状态，并把每次决策写成可离线核验的记录。覆盖声明落在它治理闭环的「确认 + 审计」接缝上：确认回答「谁同意了这次动作」，声明回答「这份记录能证明到哪一步」。

仓库（境内访问建议用 Gitee 镜像）：

• GitHub：https://github.com/rain6fish/KeelBase
• Gitee：https://gitee.com/rain6fish/KeelBase

照实交代两处。一是外部锚今天没有端点，所以涉及尾部完整性的结论只能是unknown；这不是保守，是事实。二是那条「有意缺席」：我们宁可少声明一条，也不把一条没核实的缺口挂到每一份包上。

一份诚实的审计包，不是说自己没有缺口，是说清自己有哪些缺口。