你的AI代理还不会自己找工具？ARD协议正在给代理装上「发现」能力

起因：代理工具的「最后一公里」难题 如果你今天构建一个AI代理，大概率会接触到三个协议：MCP（让代理调用工具）、Skills（为代理提供指令模板）和A2A（让代理呼叫其他代理）。它们各自解决了一部分互通问题，却默契地绕过了同一个难题——谁来告诉代理，该去哪里找这些工具？

当前的做法是「先安装，后使用」。开发者把MCP服务器地址硬编码进配置，用户把某个AI服务通过插件连入自己的应用。这在小规模、日常高频工具的场景下勉强可行，但一旦要扩展到成百上千个临时、长尾的能力，立刻捉襟见肘。你不可能把所有工具描述都丢进大模型的上下文窗口里——不仅消耗token，还会让模型选择困难。

这正是Agentic Resource Discovery（ARD）规范想要解决的。它不是另一个封闭的产品或市场，而是一个开放的、可由任何公司独立实现的联合发现标准，由微软、Google、GoDaddy、Hugging Face等多家机构的贡献者共同制定。

拆解：ARD如何成为代理的「黄页」 ARD本质上是一层位于现有协议之上的「发现层」。它定义了两件事：一是静态清单格式ai-catalog.json，让能力提供方（如一个MCP工具、一个A2A代理）在固定的URL上公布自己的元数据；二是动态注册表API POST /search，客户端用自然语言搜索，返回经排序的能力描述。

你可以把它类比为互联网的DNS：过去你需要记住IP地址，现在你输入域名，DNS帮你解析。ARD就像代理世界的DNS，代理不再需要硬编码“MCP服务器地址”，而是用“我需要一个能翻译文本的工具”这样的意图去搜索，发现层返回最匹配的工具及其调用方式。

这种将选择移出大语言模型的做法还有额外好处：注册表可以在模型中立的索引里加入更丰富的信号——发布者身份、合规声明、代表性质询、标签等——从而比单纯依赖工具描述文本做出更精准的匹配。

趋势洞察：从「静态集成」到「动态生态」 ARD的出现揭示了一个更大的范式转移：代理能力正在从“手工安装”模式走向“自动发现”模式。就像手机应用从预装功能发展到应用商店按需下载，代理工具也正在从配置文件里的固定条目，变成可以实时搜索和调用的动态资源。

这意味着未来的代理将不再是孤立的执行器，而是能够探索和利用外部能力的智能体。它们会在任务进行中根据需求，临时去寻找一个还没集成过的工具——只要那个工具发布了符合ARD规范的发现清单。

这也预示着代理生态的分工细化：工具开发者专注于提供能力，注册表服务商专注于索引和质量审核，而代理本身可以变得更轻量、更灵活。

实用价值：你现在可以做什么

• 如果你是工具或代理的开发者，现在就可以为自己的MCP服务器或A2A代理添加ai-catalog.json，并注册到Hugging Face Hub等支持ARD的发现服务中。让其他代理能搜到你。
• 如果你在构建代理应用，可以考虑引入ARD客户端逻辑，让代理在运行时动态寻找新能力，而不是仅依靠预先配置的工具集。这能让你的代理更「通用」。
• 对于产品设计，ARD启发了新的交互模式：用户不需要手动连接每一个服务，只需告诉代理需求，由代理自行发现和调用。

反常识/意外 很多人以为有了MCP和A2A，代理互操作的问题就解决了。但工具发现才是真正的瓶颈——如同有了电话机还需要电话簿。ARD没有发明新的调用机制，而是在现有协议之上补齐了关键的发现环节。更微妙的是，它放弃了让大模型从一堆工具描述里“猜”正确答案的路径，转而用传统搜索工程的方式解决问题。这或许说明，在代理架构中，并非一切都需要塞进模型。

原文地址: Agentic Resource Discovery: Let agents search for tools, skills, and other agents