摘要

  • 9 月 5 日的 RMRP 个人草案新增 Routing Completeness Attestation（RCA）：路由引擎按时间窗口签名声明处理了多少事件、写下多少审计记录。它仍是 I-D Exists 的工作草案，不是 IETF 标准或部署证明。
  • Merkle 包含证明和外部检查点只能保护已经存在的记录。如果一次推理调用执行后根本没有写入日志，就没有叶子可验证。草案明确承认 RCA 是系统的自我陈述，并“不证明完整性”。
  • 供应商账单可以提供外部的事件或费用分母，暴露没有对应内部记录的支出；但账号、凭据、模型、时段和费用口径必须先对齐，差额才有解释价值。

一份审计报告写着：路由引擎处理了 10 万次 AI 请求，审计库也有 10 万条记录。每条记录都能通过签名校验，Merkle 根已经交给外部存证方。表面上，四个“10 万”严丝合缝。

如果还有第 100001 次调用绕过了记录生成呢？

现有密码学可以证明某条记录属于已经承诺的集合，也可以证明集合在检查点之后没有被悄悄改写。它无法对一个从未生成的叶子报警。剩余的 10 万条记录可以全部真实、顺序完整、签名有效，同时仍然遗漏一次真实执行。

这正是《Reilly Model Routing Protocol》01 版最值得报道的变化。L. J. Reilly 的个人 Internet-Draft 日期为 9 月 5 日，目标状态是 Informational，Datatracker 状态为 I-D Exists。它不是 RFC、IETF 共识、合规认证，也没有证明任何实施或事故。

与00 版相比，01 版原文新增规范化、签名、选择性披露、复杂度评分证明、总预算控制、包含证明、外部锚定、撤销、符合等级与成本对账。真正的新意不是“又有一种 AI 协议”，而是它迫使管理者把四个问题拆开：记录有没有被改、记录是否在集合中、所有事件是否都被记录、另一个系统是否同意这个总数。

签名回答“谁说过”，不回答“是否说全”

RFC 8785让 JSON 有确定的字节表示，RFC 7515让验证者确认这些字节由哪个密钥签署、之后是否变化。哈希链能显示已知序列中的断裂。

RMRP 还借用 Certificate Transparency 的 Merkle 结构。验证者可以用一条较短的路径证明某条 Audit Log Record 确实包含在某个树根中；一致性证明则说明新树是旧树的追加，而不是替换。

所有这些能力都从“记录已经生成”开始。若路由引擎完成调用，却不生成 Audit Log Record 和 Cost Attribution Record，留下的树仍可完美通过检查。给树根多签几次名，不会凭空长出那片缺失的叶子。

因此，完整性首先是分母问题：本应产生记录的事件究竟有多少？如果事件数和记录数都由同一个引擎、同一个管理员、同一条代码路径给出，那么它们相等只能证明内部叙述一致。

外部锚点能保管历史，不能枚举调用

草案坦白指出：控制 Audit Store 的操作者若也签署树根，这个树根并没有限制他自己能改什么。它因此要求把检查点发布到管理控制范围之外，例如时间戳服务、透明日志或档案存证。

尚未确认的目标只能标为 PENDING；多个独立目标会提高事后篡改成本，却不能被称作“不可变”。检查点间隔也是保障的一部分：每天一次和每五分钟一次留下的改写窗口不同。

外部存证方独立保管的是树根。它没有亲眼观察每次 AI 请求。若遗漏发生在构树之前，向十个外部目标发布同一个根，只会更有力地证明“这个不完整集合后来没有变”。外部独立必须说清是对保管权独立，还是对事件计数独立。

RCA 把沉默变成有署名的陈述

RMRP 的 C3 等级要求定期生成 RCA。它记录 UTC 窗口、引擎身份、处理事件总数、审计记录数、按结果和模型等级的计数、覆盖该窗口的树根、上一份 RCA 标识以及签名。事件数与记录数不同时必须解释；previous_rca_id 断开时，缺失窗口会显现。

RCA 使用的 Routing Engine 密钥应与 Policy Authority 密钥分开。这能避免一把密钥同时扮演两个密码学角色，却不能证明背后是两个团队或两个责任主体。草案的威胁模型也承认，协议可以要求不同密钥，不能强迫组织把密钥交给不同的人。

最重要的是，草案自己划定了边界：RCA 是受审系统对自身完整性的声明，它“不证明完整性”。愿意漏记的操作者仍可签下虚假总数。变化在于，原来的空白现在与一个带时间、范围和身份的签名陈述冲突，审计者可以拿它与其他证据对照。

RFC 9334 的远程证明架构提供了恰当位置：证据、评估政策和最终证明结果应当分离。RCA 是待评估证据，不是自动生成的信任结论。

供应商账单提供第二只表

Cost Reconciliation Record 把内部成本记录与模型供应商在同一期间、同一范围报告的费用比较。unattributed_cost_usd 专门表示供应商看到了费用，内部却没有对应记录。草案称，这是其唯一能发现“完全绕过路由引擎的推理”的控制。

这个因果关系成立：供应商站在 API 调用另一端。团队用直连密钥、紧急备用路径或未接入的工具发起请求时，企业路由器可能毫无记录，供应商账户仍可能留下用量。

账单却不是绝对真相。时区结算、延迟入账、重试、缓存 token、四舍五入、承诺用量折扣和共享凭据都会制造正常差额。对账需要绑定供应商账号、凭据、模型、区域、UTC 窗口、成本中心，并尽可能同时比较调用次数与费用。差额是调查触发器，不是欺诈判决。

RMRP 的 C2、C3、C4 把不同保障压缩成短标签：C2 签记录，C3 加 RCA、撤销和总预算，C4 再加 Merkle、外部检查点和供应商对账。没有检查点频率、外部保管者、对账周期、账号范围和容差，等级只是组件清单。

Heng Lu 的现实层要求把草案文本、符合声明、签名 RCA、日志树、供应商账户和实际执行分别看待。它们相互吻合会增强可信度，任何一层都不会因签名而继承另一层的事实权力。运行代码优先则把实际调用、费用与结果置于格式承诺之上。