搜索相关性不足以支撑自动调用
搜索引擎擅长在海量网页中找相关内容。但智能体互联网中的资源发现,不能只停留在“相关”。一个智能体查到某个工具后,可能会把它接入任务执行链路;一个企业系统查到某个服务后,可能会让它处理敏感数据;一个用户代理查到某个 Skill 后,可能会自动下载描述并生成调用计划。此时,发现结果必须同时满足相关性和可信性。
OAN Discovery 的设计目标不是做通用搜索引擎,而是做可信资源发现节点。它索引的是 Root 验证后的 ResourcePackage,而不是任意网页或开发者随手填写的目录记录。Discovery 同步资源时,要验证 DID 文档哈希、元数据哈希、包哈希、Root Proof、Root bulletin 事件和资源生命周期状态。只有通过这些检查的资源,才进入本地索引。
Discovery 返回的是有来源的候选资源
这意味着 OAN Discovery 返回的候选结果具有明确来源。用户看到的不是“某处抓取来的链接”,而是由 Registrar 接入、Root 验证、CDN 分发、Discovery 校验后形成的资源候选。Discovery 自己可以做本地排序、评价、历史统计和企业偏好过滤,但这些都是局部信号,不能覆盖 Root 的信任事实。
OAN Discovery 的查询对象也不是普通关键词。ResourceDiscoveryQuery 可以包含自然语言 query,也可以包含 resourceType、capabilityTags、protocol、version、versionMode 和 limit 等结构化条件。versionMode 默认偏向最新版本,这符合 Skill、MCP Server 和 API 持续升级的实际情况。对机器调用方来说,结构化查询比单纯字符串更容易复现,也更容易解释为什么某个候选被返回。
查询响应也应该可验证
Discovery 返回的候选也应是机器可验证的。ResourceDiscoveryCandidate 不只包含名称和链接,还会携带 resourceDid、resourceType、score、version、lifecycleState、capabilityTags、authorizedDomains、services、protocolBindings、packageInfo 和 rootProof 等信息。ResourceDiscoveryResponse 还包含 discovery 节点 DID、候选列表、生成时间和 proof。这样,调用方可以先验证响应来源,再检查候选资源的 Root Proof 和包级证据。
| 查询输入 | 发现节点做的事 | 返回结果更像什么 |
|---|---|---|
自然语言 query |
语义匹配、排序 | 可信候选列表 |
resourceType |
限定资源形态 | 更窄的候选集 |
capabilityTags |
按能力筛选 | 更贴近任务需求 |
protocol / version |
按协议和版本过滤 | 更适合自动调用 |
versionMode=latest |
优先最新 active 版本 | 更适合持续迭代资源 |
OAN Discovery 还引入授权域过滤。authorizedDomains 不是普通标签,而是治理边界。一个 Discovery 节点只能在其授权域范围内提供资源发现能力。资源即使能力标签匹配,如果不属于该节点授权域,也不应被当作有效候选返回。这个机制让发现服务不只是技术索引,也体现了开放治理网络对节点职责范围的约束。
能力标签服务于匹配
能力标签则承担不同职责。capabilityTags 帮助 Discovery 理解资源能做什么,支持粗粒度或语义化检索。例如数据分析、代码生成、知识检索、工作流自动化、MCP 工具等标签,可以帮助用户和智能体缩小候选范围。标签越规范,发现效果越好;但标签不能扩大授权域,也不能替代 Root 验证。
从用户体验看,可信发现应该降低理解成本。用户可以输入自然语言 Query,也可以选择资源类型、协议类型和能力标签。Discovery 可以返回候选资源,并解释匹配原因。结合语义推荐库,发现页面可以根据 Query 推荐可能的能力标签、资源类型和协议,从而减少用户对底层分类体系的学习负担。语义推荐只是辅助生成查询条件,不能替代包验证、授权域过滤或 Discovery 响应签名。
可信集合上的语义检索
从工程实现看,Discovery 是一个独立基础设施节点。它有自己的数据库、索引、同步状态、签名响应和查询接口。它不是 Root 的只读页面,也不是 CDN 的文件列表。Root 可以通过批量通知把 sequence 范围、授权域、CDN manifest URL、updates URL 和证明材料发送给 Discovery;Discovery 再按本地策略同步、验证和入库。
OAN 后续可以在 Discovery 层继续增强语义检索能力。例如 GRAIL 方向强调面向智能体资源的语义发现,让自然语言 Query 与结构化资源描述、能力标签、协议入口之间形成更好的匹配。这里的重点不是把 Discovery 做成普通搜索引擎,而是在可信集合上提升召回和排序,让相关性增强始终受到信任边界约束。也就是说,语义检索解决“怎样更准确地找到候选”,Root Proof、授权域和资源包验证解决“哪些候选有资格被返回”。
普通搜索解决“有没有”;可信发现解决“能不能作为可信候选”。这就是 OAN Discovery 与普通搜索引擎的核心区别。智能体互联网越自动化,越不能把相关性误认为可信性。OAN 试图把这个差异做成基础设施能力,而不是让每个调用方在最后一刻凭经验判断。
Discovery 结果应该包含什么
| 内容 | 为什么需要 | 谁来验证 |
|---|---|---|
| 资源 DID | 标识资源主体 | 调用方和 SDK |
| Root Proof | 证明资源已被验证 | 调用方和第三方工具 |
| 生命周期状态 | 判断是否可用 | Discovery 和调用方 |
| 协议入口 | 支持实际连接 | 调用方和 SDK |
普通搜索解决“有没有”;可信发现解决“能不能作为可信候选”。这就是 OAN Discovery 与普通搜索引擎的核心区别。智能体互联网越自动化,越不能把相关性误认为可信性。OAN 试图把这个差异做成基础设施能力,而不是让每个调用方在最后一刻凭经验判断。
可信发现的含义
关键点是,Discovery 不只是“找得到”,而是“找得到还能验证来源”。这意味着返回结果要能对应到 DID、Root Proof 和版本状态,不能只靠相关性排序。
| 发现输入 | Discovery 做的事 | 输出更像什么 |
|---|---|---|
| 自然语言 query | 语义匹配和排序 | 候选列表 |
resourceType |
限定资源类型 | 更窄的候选集 |
capabilityTags |
按能力筛选 | 更贴近任务需求 |
versionMode |
优先最新 active 版本 | 更适合自动调用 |
可验证比可搜索更重要
普通搜索引擎解决的是“有很多结果怎么办”,Discovery 解决的是“哪个结果能被放心调用”。这两件事看起来相似,实质上差别很大。