跳到正文
原文
Hugging Face Blog·· 2026-06-17精选AI 评分62

Hugging Face 发布 Agentic Resource Discovery 参考实现 Discover Tool

Agentic Resource Discovery: Let agents search

AI 摘要

Hugging Face 发布 Agentic Resource Discovery（ARD）规范的参考实现 Discover Tool，为 Skills、ML 应用和 MCP Server 提供搜索访问。

正文 · AI 翻译

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

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

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

发现难题

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

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

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

该规范定义了两件事：

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

Hugging Face Hub 上的 ARD

Hugging Face Discover Tool 是我们对 ARD 的参考实现。它提供对数千个 Skills、ML 应用和 MCP Servers 的搜索访问——既包括 Hugging Face 上的，也包括其他 ARD 发现服务中的。

它的工作原理是将 Hub 现有的对 Spaces 的语义搜索与我们 Agent Skills 相结合，并将结果作为 ARD 目录条目提供。Hub 已经托管了一个包含运行 Gradio 应用、MCP 服务器和演示的 Spaces 目录。其语义搜索支持一个 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 元数据。

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

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

使用它

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

# Install the Hugging Face 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 搜索目录。

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 包装在规范的信封中，并让相同的 Space 根据客户端请求的内容以技能或 MCP 服务器的形式呈现。

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

了解更多

来源：Hugging Face Blog · huggingface.co

#智能体与工具调用#开源权重
00