Agent 的搜索引擎：Agentic Resource Discovery 规范，以及它解决不了的信任问题

古董级程序员大厂出来后一直在创业公司现在仍在一线做 AI 相关开发。写过 MCP 安全边界也写过 llms.txt 这类“给 Agent 看的网页说明书”这篇把 Agent 生态里最缺的那一环——资源发现——讲清楚。2026 年 6 月 16 日Google 联合微软、GitHub、Hugging Face、Cisco、Databricks、GoDaddy、NVIDIA、Salesforce、ServiceNow、Snowflake 等企业发布Agentic Resource DiscoveryARD规范Apache 2.0 许可基于 Google 的 AI Catalog 数据模型。O’Reilly 8 月的 Radar 报告把它列为当月最重要的软件开发事项评论是“这是必要的一步”。ARD 解决的是一个特别朴素的问题Agent 怎么知道世界上存在哪些工具、它们是不是真的、以及该找谁要MCP 把“调用工具”标准化了但“发现工具”一直停留在手工配置、静态列表和 llms.txt 这类临时方案上。这篇拆开 ARD 的机制、它和 MCP/A2A 的分工以及它真正解决不了的那部分。发现层Agent 生态里一直缺的一环把 Agent 使用外部能力的生命周期拉直发现ARD → 调用MCP / OpenAPI → 协作A2AMCP 管“连上之后怎么调”A2A 管“Agent 之间怎么互相派活”ARD 管的是最前面那一步——在连接之前怎么找到、怎么验证。以前这一步靠三件事开发者在配置里写死 MCP server 地址、社区维护的静态工具列表、或者让模型“猜”工具名。猜和写死的共同问题是没有统一格式、没有所有权声明、没有验证Agent 很容易找到错误甚至恶意的“同名工具”。ARD 的两个核心概念Catalog 和 RegistryARD 把发现拆成发布与搜索两层Catalog资源目录组织在自己控制的域名下发布一个机器可读的ai-catalog.json描述它能提供什么工具、API、Skill、Agent Endpoint。域名是天然的归属锚点——你信任stripe.com/ai-catalog.json比信任某个第三方聚合站更有依据。Registry注册中心聚合大量 Catalog接受 Agent 按任务意图搜索。Agent 不再依赖写死的集成逻辑或静态端点列表而是带着意图去 Registry 里查查到之后再回源 Catalog 验证。一个关键设计ARD 不是“全球唯一目录”。微软 AI 首席工程师 Jennifer Marsman 在发布时把话说得很清楚未来会有许多发现服务各自按索引范围、服务对象和排序策略提供不同结果ARD 只是让 AI 客户端能发现这些服务不替代身份认证、授权、治理和组织层的信任决策。生态已经落地的东西规范发布当天就带了一批参考实现实现提供方能力Agent RegistryGoogle托管式搜索/发现/托管 agentic resources规划认证发布者接入Agent FinderGitHubCopilot 运行时发现并调用 MCP server、skills、tools、agents支持公共/私有注册中心Discover ToolHugging Face在 Hub 的 Spaces 与 Agent Skills 上做语义搜索输出 ARD 目录条目ARD 支持Snowflake 等作为数据平台接入发现网络GitHub 的 Agent Finder 是最能说明问题的例子Copilot 在执行任务时按需从注册中心发现并调用工具而不是把每个工具都预先写进配置。这正好是 ARD 想推的“运行时发现”模型。信任ARD 的核心承诺也是最大的问号ARD 官方把“域名为锚的归属与验证”设计成核心组成部分Agent 在建立连接前能确认找到的资源确实属于声称的那一方。发布方在自己的域名下放ai-catalog.json验证就有了一个可检查的起点。为什么验证这么重要因为“给 Agent 的搜索引擎”同时也是“给 Agent 的投毒入口”。2026 年已经出现 FakeGit 这类针对 AI Agent 的诱捕案例用与官方项目高度相似的名字和描述引诱 Agent 在运行时去拉取带恶意代码的“工具”从而窃取开发者的 token。工具发现一旦变成自动化的“搜到就用”供应链攻击就从“骗开发者下载”升级成“骗 Agent 自动下载”——开发者还能看一眼Agent 不会。所以 ARD 的验证机制值得关注但也必须知道它的边界ARD 负责确认资源归属这是不是 stripe.com 声明的资源ARD 不负责确认资源质量这个工具写得对不对ARD 不负责授权你的组织能不能用、用了花多少钱。Google 云杰出工程师 Srinivas Krishnan 在发布时说企业需要的不只是“找到一个能用的工具”而是治理、安全和身份认证从一开始就是系统设计的一部分。翻译成工程语言ARD 是发现协议不是安全方案安全边界仍然要由调用方自己画。如果你想接 ARD现在能做什么发布方在自己的域名下放ai-catalog.json按 ARD v0.9 schema 描述工具、API、Skill 和 Agent Endpoint并与现有 MCP server / OpenAPI 文档保持一致。这是成本最低的第一步也让你的能力可以被 Copilot、Agent 这类客户端在运行时发现。消费方Agent 侧把“发现”从写死的配置改成运行时查询先向 Registry 按意图检索再回源 Catalog 域名验证归属验证通过后才交给 MCP 调用层。伪代码级的检查清单1. 按任务意图向 Registry 查询候选资源 2. 回源 ai-catalog.json 所在域名校验资源声明 3. 核对资源 ID / 版本 / 归属方拒绝与意图不符或无法验证的条目 4. 调用前检查权限与计费条款ARD 之外的授权层 5. 记录发现-验证-调用全链路供审计观察点ARD 的价值取决于什么工具质量决定目录价值。Reddit 上的讨论已经点破发现机制再统一目录里都是劣质工具Agent 也只是更快地找到烂东西。Registry 的排序和评价机制会成为下一轮竞争点。计费与访问模式没解决。ARD 让 Agent 知道工具存在但“调一次多少钱、要不要审批”仍然是发现层之外的难题。验证机制能不能兑现看实现。域名验证是承诺落地时认证发布者、证书轮换、联邦互认都是工程活。O’Reilly 把它列为“必要的一步”潜台词是这一步只解决了“找得到”后面“信得过”“用得起”还早。对我们这些写代码的人ARD 的意义是把一个之前靠“猜和写死”的问题变成了可编程的问题发布目录、运行时发现、域名验证、调用前审计——每一环都有明确的工程位置。这也正是它和我们之前聊的 llms.txt 的区别llms.txt 是网页给 Agent 的说明书ARD 是给整个生态的目录系统和验证机制。下一轮值得看的是 Agent Finder 这类运行时发现在真实项目里的误用率和投毒拦截率——发现标准化了安全才刚开始。