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 Discovery（ARD） 规范，Apache 2.0 许可，基于 Google 的 AI Catalog 数据模型。O’Reilly 8 月的 Radar 报告把它列为当月最重要的软件开发事项，评论是“这是必要的一步”。
ARD 解决的是一个特别朴素的问题：Agent 怎么知道世界上存在哪些工具、它们是不是真的、以及该找谁要？ MCP 把“调用工具”标准化了，但“发现工具”一直停留在手工配置、静态列表和 llms.txt 这类临时方案上。这篇拆开 ARD 的机制、它和 MCP/A2A 的分工，以及它真正解决不了的那部分。
发现层：Agent 生态里一直缺的一环
把 Agent 使用外部能力的生命周期拉直：
发现（ARD） → 调用（MCP / OpenAPI） → 协作（A2A）MCP 管“连上之后怎么调”，A2A 管“Agent 之间怎么互相派活”，ARD 管的是最前面那一步——在连接之前，怎么找到、怎么验证。以前这一步靠三件事：开发者在配置里写死 MCP server 地址、社区维护的静态工具列表、或者让模型“猜”工具名。猜和写死的共同问题是没有统一格式、没有所有权声明、没有验证，Agent 很容易找到错误甚至恶意的“同名工具”。
ARD 的两个核心概念：Catalog 和 Registry
ARD 把发现拆成发布与搜索两层：
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 Registry | 托管式搜索/发现/托管 agentic resources，规划认证发布者接入 | |
| Agent Finder | GitHub | Copilot 运行时发现并调用 MCP server、skills、tools、agents，支持公共/私有注册中心 |
| Discover Tool | Hugging 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 这类运行时发现在真实项目里的误用率和投毒拦截率——发现标准化了，安全才刚开始。
微信公众号
欢迎关注「字与码」
如果这篇文章对你有用，也欢迎在微信里继续关注后续更新。
X / Twitter
关注 @ax2_zicode
更即时的技术观察、新文章提醒和一些短想法会发在 X 上。