Table of Contents
背景
随着AI代理生态的繁荣，开发者如今面临三个主流协议：MCP（模型上下文协议）让代理可以调用工具，Skills允许代理消费指令，A2A（代理到代理）使代理能够调用其他代理。然而，所有这些协议都假设用户已知所需工具、指令或代理的具体位置。用户仍需负责手动发现、集成和维护这些能力。
当代理需要与数十上百个工具或服务交互时，“先安装后使用”的模式变得难以扩展：开发者不得不将每个MCP服务器URL硬编码进配置文件，或将所有工具描述塞进LLM的上下文窗口依赖模型选择——后者受限于上下文预算，且描述往往过于简略。
2026年6月17日，由微软、谷歌、GoDaddy、Hugging Face等多方贡献的Agentic Resource Discovery (ARD) 规范正式发布，旨在作为发现层填补这一空白。ARD定义了一种开放的规范，允许代理在运行时动态、意图驱动地发现工具、技能和其他代理，而非依赖预置清单。
核心内容分析
发现层：从手动安装到动态搜索
ARD规范明确了两个核心组件：
- 静态清单格式：名为
ai-catalog.json，发布者可在已知URL上托管其能力清单，包含描述、查询示例、合规证明等丰富信号。 - 动态注册API：通过
POST /search接口提供实时、排序的发现服务。客户端以自然语言搜索，服务端返回匹配的能力。
这一设计将选择逻辑从LLM中移出，转向专门的索引和搜索系统。注册表可以记录发布者身份、代表性查询、标签等元数据，使得搜索更加精准。
Hugging Face的参考实现
Hugging Face Hub已经推出了基于ARD的Discover Tool，这是规范的参考实现。目前它提供对数千个Skills、ML应用和MCP服务器的搜索访问——既包括Hugging Face平台上的资源，也跨越其他ARD发现服务。用户可通过统一的搜索界面，用自然语言找到所需的代理能力。
该发现工具结合了Hugging Face Hub的丰富资源（数据集、模型、应用）与ARD的标准化发现机制，初步展现了跨平台动态发现的潜力。任何第三方都可以部署自己的ARD注册表并加入互操作网络。
解决的核心问题
ARD瞄准的是当前代理生态中的“集成鸿沟”：开发者需要预先知道每个工具的地址并手动配置，而代理无法自主探索新能力。通过ARD，一个代理在遇到未知任务时可以向注册表发起搜索，在响应中发现合适的MCP工具、A2A代理等，然后动态调用它们。这使得代理的能力边界不再受限于初始配置，而能随生态成长而扩展。
行业影响/专业点评
ARD规范的提出是代理互操作性领域的一个重要里程碑。如果说MCP定义了“如何调用”，A2A定义了“如何通信”，那么ARD则定义了“如何发现”。三者共同构成代理协作的完整基础设施。
从行业视角看，ARD有望成为AI代理时代的“DNS”——一个统一的名称与发现系统，让工具和服务的注册、索引、搜索标准化。这将对以下场景产生深远影响：
- 企业级代理部署：企业可以建立私有的ARD注册表，将其内部工具、API和专业知识统一索引，供内部代理动态发现。
- 开放的代理市场：第三方开发者或组织可以将自己的工具发布到公共ARD注册表，代理可以按需获取，无需用户手动安装插件。
- 降低集成成本：开发者不再需要为每个新工具编写适配代码，只需确保工具符合ARD清单格式，代理即可自动发现并调用。
当然，ARD目前仍是草案规范，其实际采纳速度取决于主要平台（如OpenAI、Anthropic等）的支持情况。但微软、谷歌和Hugging Face的参与赋予它强大推动力。随着Hugging Face Reference Implementation的落地，我们将很快看到基于ARD的应用案例涌现，推动AI代理从“静态集成”走向“动态探索”的新阶段。
