摘要

  • draft-vandemeent-ains-discovery-02 的重要变化不是增加命名功能，而是从规范路径中移除 trust_score 与 min_trust：联邦复制类型化证据和路由态势，判断留给消费方自己的政策。
  • 签名、连续序号与 Merkle 包含证明能够说明谁在何时记录了什么、历史是否被静默改写；它们不能独自证明名称归属、能力真实性、当前适用性、准入或授权。

AINS 想让智能体像服务一样被发现：查询一个逻辑名称，得到端点、能力、身份引用、来源和证据。真正值得关注的却是 9 月 24 日发布的 -02 版本删掉了什么。它不再把某个登记库算出的数字包装成可以跨域流通的“信任”。

这仍是一份个人提交、信息类的 Internet-Draft，没有工作组采纳、IETF 共识或 RFC 地位。现有资料也没有证明生产部署、互操作结果或规模表现。现在能评价的是边界是否清楚，而不是系统是否成功。

新版把旧的“信任模型”拆为三层。证据是可验证对象或引用；路由态势描述可达性、覆盖、提供者角色和新鲜度；本地评估则是某个消费方用一版明确政策，对一次具体交互作出的结论。准入与实际执行还要再往后走。

这三层若被压成一个分数，事实就会变质。外部账号发布随机数，只能证明当时控制该账号；不能自动证明长期身份。某条路可达，只能说明探测看见了路径；不能说明对方同意使用。一个对象签名有效，只能说明相应密钥签过这些字节；不能说明能力陈述已经在现实中兑现。

AINS 为联邦设计了带签名、只追加的变更日志。来源登记库为每个创建、更新、删除墓碑或转移事件编号并签名。同行拉取日志，验证来源签名，拒绝不连续或倒退的序列，并保留原始来源。可选的 Merkle 证明可让第三方核对某条记录是否进入承诺历史。

这是重要的保管证据，但不是事实裁判。RFC 9162 的透明日志给出成熟类比：包含证明与一致性证明能帮助发现分叉和回写，却不会让被收入日志的每项主张天然正确。RFC 9421 对 HTTP 消息签名也要求验证方另行判断密钥、算法、覆盖字段、新鲜度和重放风险是否适用于当前场景。

名称冲突规则把这个界限暴露得最清楚。两个来源登记库若声称同一名称，副本保留 registered_at 最早的记录，记安全事件，并禁止静默覆盖。这能让不同副本收敛，却不能裁决正当归属。抢注者同样可能最早。跨登记库预留仍被列为未来工作。

因此，界面不该只显示“胜者”。它应保留两项声明、各自证据，以及当前投影为何选择最早时间戳。若把机械的先后次序涂成绿色认证徽章，收敛规则就被洗成了制度地位。

所谓“多渠道验证”也需要收窄理解。方案要求申请者把新随机数发布到至少一个外部渠道。一个渠道并不等于多个渠道；控制社交账号、代码库或 DNS 记录，也不等于长期主体、组织授权或后续行为许可。更多独立渠道只能成为本地政策的输入。

所以，相同证据产生不同结论并非缺陷。银行、社交平台和实验室承担的后果不同，可以设定不同门槛。责任在于公开政策版本、证据集合、适用范围、新鲜度与拒绝理由，而不是假装存在全球唯一的“可信度 82 分”。

提案自己的比较表也不能免于查证。其信息性附录称 A2A 没有加密验证，但当前官方 A2A 规范已经允许用 JWS 签署 Agent Card，规定规范化方法，并建议客户端在信任卡片前验证至少一个签名。AINS 可以提出不同的证据联邦，但不能靠冻结邻近协议的旧状态来证明必要性。

被删除的权力仍可能从别处回来。core、verified、sandbox 与 reserved 等层级很容易在产品里变成身份等级；来源登记库和同一套作者提出的配套协议也可能形成事实上的门槛。忠实实现应允许消费方忽略层级、独立验证证据、替换评估器，同时仍能解析和复制记录。

隐私代价更加难以逆转。公开记录可能暴露端点、能力、路由态势和历史引用；复制之后，来源无法控制所有副本。墓碑能证明删除事件发生过，却擦不掉已经导出的旧数据。发布前就必须决定哪些字段只放引用、缓存多久、如何发现副本、谁能获得选择性披露。

Lu Heng 的薄协调原则为此给出清晰边界：共同层可以容纳稳定语义、确定性校验、来源签名、可携带格式与可见冲突；适用性、风险承受、商业许可和采纳仍留在本地。登记库保存记录，不因登记动作本身获得治理未来行为的权力。

运营上应保留六份彼此独立的凭据：原始发现响应与来源签名、日志位置与新鲜度、逐项验证结果、路由观察及其盲区、本地政策与结论、后续准入和执行结果。少掉其中任何一层，故障都会被错误归结为一个含混的“信任问题”。

来源