Hugging Face 发布 Agentic Resource Discovery 规范与 Discover Tool

如果你今天用 agent 构建应用，大概会知道三种协议。MCP 为 agent 提供了调用工具的标准方式。Skills 为 agent 提供了消费指令的方式。A2A 为 agent 提供了调用其他 agent 的方式。这三者都假定用户已经知道自己需要哪个工具、哪条指令或哪个 agent。用户仍然要负责发现、集成和维护这些能力。

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

在本文中，我们将探讨该规范、HF Mirror 如何实现它，以及你如何开始在 ARD 上进行构建。

发现问题

当前 agent 能力的模式是先安装、后使用。开发者将 MCP 服务器 URL 硬编码到配置文件中。用户通过插件将服务连接到自己的 AI 应用并复用。这对 agent 每天使用的那几个工具来说行得通，但无法扩展到成千上万的临时场景。

退而求其次的做法是把所有可用的工具描述都塞进 LLM 的上下文窗口，让模型去挑。这受限于上下文预算。这里也有基于搜索的策略，但描述往往过于单薄，难以很好地区分。

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

该规范定义了两件事：

一种名为 ai-catalog.json 的静态清单格式，让发布者可以将自己的能力托管在一个众所周知的 URL 上。
一个位于 POST /search 的动态注册表 API，提供实时的、按排名排序的发现能力。

HF Mirror Hub 上的 ARD

HF Mirror Discover Tool 是我们对 ARD 的参考实现。它提供了对数千个 Skills、ML 应用和 MCP 服务器的搜索访问——涵盖 HF Mirror 以及其他 ARD 发现服务。

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

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

application/ai-skill：默认值。一个生成的 SKILL.md，包裹该 Space 的 agents.md。
application/mcp-server+json：为标记为 mcp-server 的 Spaces 提供的 MCP 服务器目录条目。
application/vnd.huggingface.space+json：原始 Space 元数据，供希望自行处理的客户端使用。

这种 skill 类型涉及额外的转换。许多 Space 会附带一个 agents.md 文件，描述 agent 应如何与它们交互。Discover 会读取该文件，并用 skill 使用方期望的 frontmatter 将其包装起来：name、description，以及涵盖 Space ID、Hub URL、app URL 和原始 agents.md URL 的源元数据。其结果是任何支持 skill 的客户端都能通过其常规 skill 流程安装或加载的 skill。

对于带有 MCP 标签的 Space，适配器会生成一条目录条目，通过 HTTP 传输指向该 Space 的 Gradio MCP 端点。当 Hub 提供运行时域名时，URL 使用该 Space 的运行时域名，否则使用标准的 .hf.space slug 约定。

使用它

discover 已内置于 HF Mirror CLI（hf）。要开始使用并为你或你的 agent 授予访问权限：

# Install the HF Mirror CLI tool:
uv tool install huggingface_hub

# Search for resources to train a model
hf discover search "Fine tune a language model"

# Find MCP Servers to generate an image
hf discover search "Generate an image" --json --kind mcp

# Search other registries
hf discover search "Purchase aeroplane tickets" --registry-url <catalog-url>

REST API 和 MCP 工具

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

HF Mirror 目录发布在其 well-known URL 上：

https://hf-mirror.com/.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 Client 连接到 MCP 端点，使用 https://huggingface-hf-discover.hf.space/mcp 来搜索目录。

这对规范意味着什么

ARD 将发现与执行分离。静态 manifest 格式由媒体类型驱动，因此任何 artifact 协议都可以搭载同一个信封，而无需在规范层面做修改。注册表 API 是普通的 HTTP REST，因此任何客户端都可以与其联合。Discover 是该规范在整个生态系统中的若干参考实现之一，并且由于联合机制内置于协议中，通过一个服务进行的搜索可以发现由另一个服务托管的能力。

Discover Tool 是对该设计的一次实际测试。它没有发明新的 artifact 格式。它将现有的搜索后端 Hub 包装进规范的信封中，并让相同的 Space 根据客户端请求的内容以 skill 或 MCP 服务器的形式呈现。

下一步是与规范的联合模式（auto、referrals、none）进行更紧密的集成，并在 Hub 侧支持用户和组织配置文件上的静态 ai-catalog.json manifest。一旦实现，任何 Space 发布者都将能够通过标准的 well-known URI 机制宣传其能力。

了解更多

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