合并规范：draft-li-rttp-iqa-addressing（IETF 独立提交通道审核中）· 其中 rttp:// 已获 IANA 注册（Provisional · CRI 27）
当 Agent 开始跨域互相调用，它需要两样东西：一个语义寻址方案（把「我要对谁、做什么」变成可解析的地址），和一个信任证明方案（把「谁、在什么地位下、凭什么授权」变成可验证的证据）。现在的协议栈里，这两样东西各有残缺；而把它们硬塞进同一个协议，代价比想象的大。本文解释为什么最终形态是一个草案、两个 scheme。
一、现实协议栈的缺口
- DNS + CA：域名寻址靠 DNS，身份绑定靠 CA 签发的证书。验证一次链路，要在线询问两套权威设施；信任锚是 CA 体系本身；
- OAuth / OIDC：授权语义完整，但每次校验都回 IdP（身份提供方）——freshness 与撤销永远在线；
- DID / VC（W3C 路线）：身份可自主生成，但 DID 解析回网（registry / DID method）、VC 的有效性核验同样依赖在线端点；
- MCP：把工具调用标准化了——但身份、授权状态、执行证据不属于它的语义范围。
把这张清单放在一起看：寻址与证明被混在各种协议里，却从未被当作两个独立问题分别给出离线解。Agent 跨域互调时，每一次「找到你、信你」都要在线回访某个第三方。
二、两层需求不同源：单协议硬装两层的代价
语义寻址层需要：确定性（同一权威永远同一地址）、离线性（无注册表解析）、无状态（不依赖发放机构）。它的信任锚是哈希函数本身——地址 = SHA-256(权威字符串)[:16]，落地自证。
信任证明层需要：状态机（地位四态）、租约与撤销、防重放、签发与验证分离。它的信任锚是机构密钥——证明即签名事实。
两个信任锚不同源，这是本质约束。若强行写进一个 scheme：
- 寻址格式被证明层的演进拖住（信封扩展要改版，地址语法也得跟着动——而地址已经写进别人的证据里，几乎不可改）；
- 评审与实现边界模糊：注册方、实施方要在一份混合语法里拆分两套语义；
- 「只用寻址」的轻量场景被迫背上证明层的依赖。
三、两层如何咬合
分开定义，不等于互不相认。咬合点在字节层：寻址层派生的 16 字节分片（SHA-256[0:16]），被原样嵌入证明信封的主体分片字段。于是同一个 16 字节值，在寻址帧里是 ROUTE_SHARD（WHERE），在证明信封里是主体绑定（WHETHER）。验证方落地核对：分片对不上，任何一方作废；对上了，闭环不回网。
四、落地形态：一个草案，两个 scheme
合并规范 draft-li-rttp-iqa-addressing 里，rttp:// 与 iqa:// 各自陈述语法与语义，共享同一套术语与测试向量。演进节奏解耦（寻址格式近乎冻结，信封可随部署迭代）、审阅边界清晰（注册方分开引用）、零依赖部署合法（纯寻址场景可只用 rttp://）。
五、诚实边界
本文不声称双柱方案解决了跨域信任的全部问题：委托链语义当前版本明确不规定；机构密钥的分发属于部署层决策；实时风控不在范围内——它只负责让「事后可证明」成为可能。
仓库：github.com/Aicent-Stack · 规范与证据链：iqa.org · 寻址柱官网：rttp.com
一句话：地址的锚是哈希，证据的锚是密钥——两个锚装不进一个协议，但可以装进同一份草案、咬合在同一组分片里。
