Agentic Resource Discovery：让AI智能体自主发现工具和技能

如果你今天在用智能体构建应用，多半听说过三种协议：MCP 让智能体能统一调用工具，Skills 让智能体能消费指令，A2A 让智能体之间能互相调用。但它们都有一个共同假设：用户已经知道自己需要哪个工具、指令或智能体。发现、集成和维护这些能力的责任仍然在用户一方。

Agentic Resource Discovery（ARD）规范就是填补这个缺口的一层——它站在这些协议前面，负责的是“发现”。这是一份由微软、Google、GoDaddy、Hugging Face 等多家公司共同参与起草的开放规范，业内广泛参与。它定义了智能体和工具如何被编目、索引，并通过联合注册中心进行搜索。这样一来，智能体可以在运行时找到所需能力，而无需预先安装。它不是产品，也不是市场；它是任何公司都可以独立实现的共享标准，任何智能体或工具都可以参与其中。

本文我们将解析这份规范、Hugging Face 如何实现它，以及你如何开始在 ARD 上构建。

发现问题的本质

目前智能体能力的模式是“先安装，后使用”。开发者把 MCP 服务器地址硬编码到配置文件里；用户通过插件把服务连到 AI 应用然后重复使用。这种方法对每天用到的少数几个工具还行，但无法扩展至数以千计的临时场景。

退而求其次是：把所有可用工具的描述一股脑塞进 LLM 的上下文窗口，让模型自己选。这受限于上下文预算。也有一些基于搜索的策略，但描述往往太简陋，难以区分。

ARD 把选择过程移到了 LLM 之外。注册中心用更丰富的信号（如发布者身份、代表性查询、合规声明、标签）对能力建立索引。它暴露一个 REST 端点。客户端用自然语言搜索，模型直接调用搜索结果。从手动安装、静态目录的范式，转向基于意图的搜索，让智能体能动态找到合适的能力，无需逐一预先配置即可接入不断增长的 MCP 工具、A2A 智能体和其他服务生态。

规范定义了两部分内容：

• 一种静态清单格式 ai-catalog.json，供发布者在已知 URL 上托管其能力；
• 一个动态注册中心 API，POST /search 端点提供实时的、排序后的发现能力。

Hugging Face Hub 上的 ARD 实现

Hugging Face 的 Discover Tool 是 ARD 的参考实现。它通过搜索接口访问数以千计的 Skills、ML 应用和 MCP 服务器——这些资源既来自 Hugging Face，也来自其他 ARD 发现服务。

它的工作原理是：将 Hub 已有的语义搜索能力（针对 Spaces）与 Agent Skills 结合，把结果用 ARD 目录条目形式返回。Hugging Face Hub 上已经有一个 Spaces 目录，运行着 Gradio 应用、MCP 服务器和各种 Demo。Hub 的语义搜索支持 agents=true 参数，返回按智能体相关元数据排序的 Spaces。Discover 把这种搜索转换成 ARD 规范格式。

适配器应用了两个过滤器。首先，响应只包含运行阶段为 RUNNING 的 Spaces。其次，响应的媒体类型由请求驱动。支持三种媒体类型：

• application/ai-skill：默认类型。为 Space 的 agents.md 文件生成一个 SKILL.md 包装。
• application/mcp-server+json：针对标记为 mcp-server 的 Space 生成 MCP 服务器目录条目。
• application/vnd.huggingface.space+json：原始 Space 元数据，供需要自行处理的客户端使用。

Skill 类型还涉及额外转换。很多 Space 自带的 agents.md 文件描述了智能体应如何与之交互。Discover 读取该文件，并用技能消费者期望的前置信息（name、description，以及包含 Space ID、Hub URL、应用 URL 和原始 agents.md URL 的源元数据）包装它。结果是一个任何技能感知客户端都能通过其正常技能流安装或加载的技能。

对于标记为 MCP 的 Space，适配器生成一个目录条目，指向该 Space 基于 Gradio MCP 端点（通过 HTTP 传输）的地址。URL 使用 Space 的运行域（当 Hub 提供时），否则使用标准 .hf.space 后缀约定。

如何使用

discover 已集成到 Hugging Face CLI（hf）中。开始使用，为你的智能体提供搜索能力：

# 安装 Hugging Face CLI 工具：
uv tool install huggingface_hub

# 搜索训练模型所需的资源
hf discover search "Fine tune a language model"

# 查找用于生成图片的 MCP 服务器
hf discover search "Generate an image" --json --kind mcp

# 搜索其他注册中心
hf discover search "Purchase aeroplane tickets" --registry-url <catalog-url>

REST API 与 MCP 工具

你也可以直接通过 REST API 或 MCP 服务器搜索目录。

Hugging Face 的目录位于其已知 URL：

https://huggingface.co/.well-known/ai-catalog.json

直接调用搜索：

POST https://huggingface-hf-discover.hf.space/search

curl -s https://huggingface-hf-discover.hf.space/search \
  -H "Content-Type: application/json" \
  -d '{
    "query": {
      "text": "fine tune a sentence transformer",
      "filter": {
        "type": ["application/ai-skill"]
      }
    },
    "pageSize": 5
  }'

搜索 MCP 服务器：

curl -s https://huggingface-hf-discover.hf.space/search \
  -H "Content-Type: application/json" \
  -d '{
    "query": {
      "text": "transcribe some audio",
      "filter": {
        "type": ["application/mcp-server-card+json"]
      }
    },
    "pageSize": 5
  }'

或者，通过 MCP 端点 https://huggingface-hf-discover.hf.space/mcp 连接任何 MCP 客户端来搜索目录。

这对规范意味着什么

ARD 将发现与执行分离。静态清单格式由媒体类型驱动，因此任何工件协议都可以使用同一信封，无需规范层面的修改。注册中心 API 是纯 HTTP REST，任何客户端都可以对其进行联邦查询。Discover 是整个生态中多个规范参考实现之一；由于联邦是协议内置的能力，通过一个服务进行的搜索可以透出由另一个服务托管的能力。

Discover Tool 是该设计的一个工作测试。它没有发明新的工件格式。它只是将现有的搜索后端（Hub）包装在规范的“信封”里，让同一个 Space 根据客户端的请求既可以表现为 skill，也可以表现为 MCP 服务器。

下一步，会更紧密地集成规范的联邦模式（auto、referrals、none），并在 Hub 端支持用户和个人资料页上的静态 ai-catalog.json 清单。一旦落地，任何 Space 发布者都将能通过标准的已知 URI 机制来宣传自己的能力。

了解更多

• Agentic Resource Discovery 规范：https://agenticresourcediscovery.org/
• Hugging Face Discover Tool：https://github.com/huggingface/hf-discover
• Hugging Face CLI：https://github.com/huggingface/huggingface_hub
• Hub 上的 Agent Skills：https://huggingface.co/docs/hub/agents-skills
• Hugging Face Spaces：https://huggingface.co/spaces

---

原文链接：Hugging Face
本文由前途科技编辑整理