Hugging Face · 官方博客

呵

Agentic Resource Discovery：让智能体自主搜索

Agentic Resource Discovery: Let agents search

二〇二六年六月十七日 · 英文原文
摘要

Hugging Face 联合 Microsoft、Google、GoDaddy 等公司发布 Agentic Resource Discovery（ARD）开放规范草案，作为 MCP、Skills 和 A2A 协议之上的发现层。ARD 定义 `ai-catalog.json` 静态清单格式和 `POST /search` 动态注册中心 API，使 agent 能在运行时通过自然语言搜索联邦注册中心中的工具、技能和其他 agent，无需预先安装。Hugging Face 推出参考实现 Discover Tool，将 Hub 上数千个 Skills、ML 应用和 MCP 服务器转换为 ARD 目录条目，支持 REST API、MCP Tool 及 CLI 搜索。

Agentic Resource Discovery：让 agent 搜索工具、技能和其他 agent

如果你现在使用 agent 进行开发，可能已经知道三种协议。MCP 为 agent 提供了调用工具的标准方式。Skills 为 agent 提供了消费指令的方式。A2A 为 agent 提供了调用其他 agent 的方式。这三种协议都假设用户已经知道自己需要哪个工具、指令或 agent。用户仍然需要负责发现、集成和维护这些能力。

Agentic Resource Discovery（ARD）规范是位于它们之上的发现层。这是一份由来自 Microsoft、Google、GoDaddy、Hugging Face 等公司的贡献者共同开发的开放规范草案，得到了行业的广泛参与。它定义了 agent 和工具如何在联邦注册中心（federated registries）中被编目、索引和搜索，使得 agent 可以在运行时发现能力，而无需预先安装。它不是一个产品或一个市场。它是一个共享标准，任何公司都可以独立实现，任何 agent 或工具都可以参与其中。

在这篇文章中，我们将探讨该规范、Hugging Face 如何实现它，以及你如何开始在 ARD 上进行构建。

发现的问题

当前 agent 能力的模型是“先安装，后使用”。开发者将 MCP 服务器 URL 硬编码到配置文件中。用户通过插件将服务连接到他们的 AI 应用并重复使用。这对于 agent 每天使用的少数几个工具是可行的，但无法扩展到成千上万个临时接口。

退而求其次的做法是将所有可用的工具描述都塞进 LLM 的上下文窗口，让模型自行选择。这受到上下文预算的限制。虽然也有基于搜索的策略，但描述往往过于单薄，无法很好地进行消歧。

ARD 将选择过程移到了 LLM 之外。注册中心使用更丰富的信号（如发布者身份、代表性查询、合规证明和标签）对能力进行索引。它暴露了一个 REST 端点。客户端使用自然语言进行搜索，模型调用搜索返回的任何结果。这种转变是从手动安装的静态目录转向基于意图的搜索，让 agent 能够动态地找到合适的能力，并触及一个不断增长的 MCP 工具、A2A agent 和其他服务的生态系统，而无需预先配置每一个。

该规范定义了两件事：

Hugging Face Hub 上的 ARD

Hugging Face Discover Tool 是我们对 ARD 的参考实现。它提供了对数千个 Skills、ML 应用和 MCP 服务器的搜索访问——这些资源位于 Hugging Face 上，也跨越其他 ARD 发现服务。

它的工作原理是将 Hub 现有的基于 Spaces 的语义搜索与我们的 Agent Skills 相结合，并将结果作为 ARD 目录条目提供。Hub 已经托管了一个包含运行 Gradio 应用、MCP 服务器和演示的 Spaces 目录。其语义搜索支持一个 agents=true 标志，该标志返回按面向 agent 的元数据排序的 Spaces，而 Discover 将该搜索转换为 ARD 规范。

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

技能类型涉及额外的转换。许多 Spaces 附带一个 agents.md 文件，描述 agent 应如何与之交互。Discover 读取该文件，并用技能消费者期望的前置元数据（name、description 以及包含 Space ID、Hub URL、应用 URL 和原始 agents.md URL 的源元数据）将其包装起来。结果是任何支持技能的客户端都可以通过其正常的技能流程安装或加载的技能。

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

使用方式

discover 已内置于 Hugging Face CLI（hf）中。要开始使用并为你或你的 agent 提供访问权限：

# 安装 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 Tool

你也可以直接使用 REST API 或 MCP Server 搜索目录。

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 客户端，通过 MCP 端点 https://huggingface-hf-discover.hf.space/mcp 搜索目录。

这对规范意味着什么

ARD 将发现与执行分离开来。静态清单格式由媒体类型驱动，因此任何工件协议都可以使用相同的信封，而无需更改规范级别。注册中心 API 是普通的 HTTP REST，因此任何客户端都可以对其进行联邦查询。Discover 是整个生态系统中该规范的几个参考实现之一，并且由于联邦机制内置于协议中，通过一个服务进行的搜索可以展示由另一个服务托管的能力。

Discover Tool 是对该设计的一个有效测试。它没有发明新的工件格式。它将现有的搜索后端（Hub）包装在规范的信封中，并允许相同的 Spaces 根据客户端的请求以技能或 MCP 服务器的形式呈现。

接下来的步骤是与规范的联邦模式（auto、referrals、none）进行更紧密的集成，以及在 Hub 端支持用户和组织配置文件上的静态 ai-catalog.json 清单。一旦实现，任何 Space 发布者都将能够通过标准的已知 URI 机制来宣传他们的能力。

了解更多

译自 Hugging Face · 官方博客 · 录于 二〇二六年六月十七日