发现之后还有信任缺口
在普通互联网里，“搜索到一个链接”并不等于“可以信任这个链接”。在智能体互联网里，这个问题会被放大。因为智能体不是只阅读页面，它可能会自动调用工具、提交参数、触发交易、访问企业系统，甚至把某个外部服务纳入自己的任务链路。此时，发现一个资源只是第一步，更关键的是判断它能否被放心调用。
OAN 把这个问题称为从发现到可信调用之间的信任缺口。传统搜索引擎主要解决相关性问题：哪些结果更可能匹配用户输入。智能体资源发现还必须解决可信性问题：结果是否来自被验证的资源包，资源的 DID 文档是否匹配，包哈希是否一致，Root Proof 是否有效，Discovery 节点是否有权在对应授权域内返回该资源。
注册提交不是普通表单
在 OAN 中，一个资源进入网络通常要经过 Registrar、Root、CDN 和 Discovery 的协作。资源提供者先通过 Registrar 准备注册数据，包括资源 DID、资源类型、描述、能力标签、授权域、服务入口、协议绑定、包版本和哈希等。面向协议层，这些数据会被组织为 ResourceRegistrationSubmission：其中既有 resourceDid、resourceType、didDocument、metadata 等可读信息，也有 didDocumentHash、metadataHash、packageHash、hashAlgorithm 等完整性字段，还可以携带注册凭证和主体控制证明。
Registrar 不只是表单入口。它可以做草稿校验、授权域候选、能力标签建议和主体控制证明收集。更重要的是，Registrar 自身也需要被治理授权。OAN 的注册请求并不是普通 HTTP 表单，而是可以放入 SignedRequestEnvelope 的协议请求：请求中包含协议版本、用途、方法、路径、受众、时间戳、nonce、body hash 和 proof。这样 Root 在接收上游提交时，可以验证“是谁代表哪个注册节点提交了什么内容”，而不是只相信网络来源。
Root 验证和 Discovery 校验
Root 验证通过后，会形成可被后续节点验证的资源包和 Root Proof。Root 检查 DID 文档完整性、资源类型一致性、主体控制证明、包哈希、元数据哈希和上游签名等条件。CDN 负责把资源包分发出去，但 CDN 不是信任权威。Discovery 同步资源包时，需要验证 DID 文档哈希、元数据哈希、包哈希、Root Proof、Root bulletin 事件和授权域条件。只有通过这些验证的资源，才应进入可查询索引。
| 阶段 | 主要输入 | 核心检查 | 输出 |
|---|---|---|---|
| Registrar 接入 | 资源 DID、描述、标签、授权域、入口 | 草稿完整性、控制证明 | 注册提交 |
| Root 验证 | 注册提交、上游签名、包材料 | DID / 元数据 / 包哈希一致性 | ResourcePackage + Root Proof |
| CDN 分发 | 已验证资源包 | 分发一致性 | 可拉取工件 |
| Discovery 同步 | 资源包、Root bulletin、授权域 | 包级证据、授权域、生命周期 | 可查询候选资源 |
这套流程看起来比“提交一个 URL 到目录网站”复杂，但复杂性正对应了智能体调用的风险。如果一个 Discovery 结果只包含名称和链接，调用者仍然不知道资源是否被篡改、是否过期、是否来自真实发布者、是否被治理规则撤销。OAN 的做法是把这些信任信息沉淀为协议对象和可验证证据，使客户端、SDK 或用户智能体可以在调用前做机器可读的核验。
相关性不能覆盖可信性
这里还要区分两个概念：相关性和可信性。Discovery 可以根据查询语义、能力标签、资源类型、协议类型等进行匹配和排序，但本地排序不能覆盖 Root 信任事实。一个资源可以非常相关，但如果它没有通过 Root 验证，或者不属于 Discovery 节点当前授权域，就不应该被当作可信候选返回。反过来，一个资源通过了 Root 验证，也不代表它一定是“最好”的服务，它只是进入了可信发现的基础集合。
从接口上看，这种链路并不要求用户理解全部内部细节。注册侧可以通过 POST /resources/register 或分步骤提交接口进入 Registrar；发现侧可以通过 POST /discovery/resources/query 查询资源；Root 侧可以通过 /root/resources/verify-and-publish 完成验证发布。SDK 会进一步封装这些接口，让开发者关注资源描述、版本、入口和验证结果，而不是手写每个签名字段。
面向自动调用的可信候选
这种分层对用户很重要。普通用户希望找到能用的资源；开发者希望自己的 Skill、MCP Server 或 API 能被更多智能体发现；企业希望外部智能体接入资源时，有明确的身份和授权边界。OAN 将这些诉求统一到一个链路里：资源先获得可验证身份，再通过治理认可的基础设施发布和发现，最后由调用方在协议层做核验。
所以，OAN Discovery 不是普通搜索的包装。它更像智能体互联网的“可信候选生成器”。它返回的不只是“看起来相关”的结果，而是经过 Root 验证、包级校验、授权域过滤和 Discovery 签名响应保护的资源候选。对于未来自动化程度更高的智能体协作，这种信任层会变得越来越基础。
可信发现与普通搜索的区别
| 维度 | 普通搜索 | OAN Discovery |
|---|---|---|
| 结果依据 | 文本相关性 | 相关性加 Root 证明 |
| 资源状态 | 很难确认是否仍可用 | 可以结合生命周期状态 |
| 调用风险 | 需要调用方自行判断 | 先过滤明显不可信资源 |
| 结果解释 | 多依赖摘要 | DID、证明和元数据可追溯 |
这并不是说 OAN Discovery 要替代搜索引擎，而是说面向智能体自动调用的发现系统，不能只停留在“搜得到”。
从发现结果走向可调用对象
这里真正重要的是：发现不是把一堆结果排出来，而是把“能够被调用的、来源清楚的、版本明确的资源”送到调用方眼前。这样，Discovery 才能从搜索结果页变成自动化工作流的入口。
| 发现结果要素 | 作用 | 对自动调用的帮助 |
|---|---|---|
| DID | 识别资源主体 | 知道结果是谁 |
| 入口信息 | 给出调用路径 | 知道怎么连 |
| 授权域 | 限定治理边界 | 知道能不能用 |
| 版本与状态 | 标明当前版本 | 知道是否可直接调用 |
为什么还要保留人工判断
可信发现并不等于强制调用。对于复杂任务，用户仍然要看描述、能力标签和版本状态；但与普通搜索不同的是，OAN 把这些判断建立在可验证事实之上，而不是只靠文本相似度。
