中文博客 · 2026-10-10 · 双柱系列 · 总览

制度可信与数学可信之间,差一个 128 字节

2025 到 2026 年,AI 的话题从"回答问题"滑向"执行任务"。Agent 替用户订机票、审发票、调 API;再往前一步,是 Agent 委托 Agent——跨组织、跨域、互相不知底细。每往前一步,"信任"的形态就变一次:Chat 时代怕模型胡说,Agent 时代怕它越权,A2A 时代则要回答一个新问题——一个陌生 Agent 替我做完事之后,能拿出什么证据?

这个问题,产业界喊得很响,但没人给出机制。

一、口号震天响的"可信"

国内这一年,智能体标准密集出台:运行框架、运行沙盒、开发平台、多智能体协同……中国信通院 2026 年 8 月发布的《云上人工智能可靠性建设指南》里有一句写得非常好的话——"一个具备端到端可靠性的 AI 系统,能够向业务方、监管机构与终端用户证明其可预测、可解释、可审计、可追责,从而建立组织内外的信任共识"(原文公开可查)。

写得对。但翻遍全文,"证明"二字没有落点:没有任何密码学机制,没有可独立复核的凭证设计。审计日志有——但它存在运营方自己的系统里。日志可以被事后修改,验证方别无选择,只能信任运营方。这是制度可信,不是数学可信。

海外同理。Uber 刚发布的 MCP 网关工程博客介绍了托管 800 多个 MCP 服务器、5000 多个工具的治理平台,授权、限流、脱敏写得很细——审计日志的可验证性只字未提。Docker 的 MCP 网关、Cloudflare 的 Agents SDK、阿里的 Higress,特征清单里都有"审计日志",但全都停在"记在自己家"。

二、空白的形状

把各家平台的信任能力摊开,缺口是同一个:

验证方——外部审计、下游服务、合规框架,甚至被代理的用户本人——需要的东西只有一种:事件发生时同步产生的密码学凭证,事后任何人可离线复核,不需要回访任何在线服务。

三、一个最小可行形态

我们开源了一套这样的最小实现(Apache-2.0):

打包形态:四个 MCP 工具(derive_route_shard / parse_envelope / verify_envelope / published_vector),iqa-mcp 已发布 1.0.1(PyPI / npm / crates.io 三注册表),任何 MCP 兼容的 agent 栈可直接调用;参考实现 iqa-org 提供 Python / TypeScript / Rust 三语言包。规范文档 draft-li-rttp-iqa-addressing 正在 IETF 独立提交通道审核中;同一份"互补证据层"提案,已投递到七个国际生态(Docker、Cloudflare、Uber、阿里 Higress 等)的官方讨论区。

自证不止于此:我们自己的网站与全部发布物也用同一套机制逐件密封——目前 32 份凭证挂在 iqa.org/attestations/,每一条都可以离线复核。第一个用户,是我们自己。

四、诚实的边界

这套设计刻意不做三件事:不替代任何网关的实时治理(它只做事后证明);不规定委托链语义(当前版本明确不含,正在征求社区意见);不声称解决实时风控——检测是检测的事,证据是证据的事。

值得讨论的问题比答案多:四个工具的拆分是否合理?跨语言向量一致性如何维护?地位四态的语义谁来仲裁?128 位分片的碰撞裕量怎么分析?——欢迎在评论区拍砖。

双柱状态:rttp:// 与 iqa:// 均已获 IANA 注册(Provisional · CRI 27 / CRI 28)。合并规范 draft-li-rttp-iqa-addressing 正在 IETF 独立提交通道审核;三语言参考实现与字节级测试向量全部开源。

仓库:github.com/Aicent-Stack · 规范与证据链:iqa.org · 寻址柱官网:rttp.com

一句话总结:产业把"可信"喊了两年,"可验证"三个字还空着——这可能是智能体基础设施里最后一块没人挖的地。