智能体资源发现：让智能体搜索工具、技能和其他智能体-未完纪

如果你现在正在使用智能体进行开发，大概已经知道三种协议：MCP为智能体提供调用工具的标准方式；Skills让智能体能够读取和使用指令；A2A让智能体可以调用其他智能体。这三者都假定用户已经知道自己需要哪种工具、指令或智能体。发现、集成和维护这些能力的责任，仍由用户承担。

智能体资源发现（Agentic Resource Discovery，ARD）规范，就是位于它们之前的发现层。这是一份开放规范草案，由Microsoft、Google、GoDaddy、Hugging Face等机构的贡献者共同开发，并有行业内广泛参与。它规定如何在联合注册目录之间编目、索引和搜索智能体及工具，让智能体在运行时发现能力，而不必预先安装。ARD不是产品，也不是市场；它是一项任何公司都可以独立实现、任何智能体或工具都可以参与的共同标准。

本文将介绍这份规范、Hugging Face对它的实现，以及如何开始基于ARD构建应用。

发现问题

当前的智能体能力使用方式，是先安装、后使用：开发者把MCP服务器URL硬编码进配置文件，或者用户通过插件将服务连接到AI应用中，随后反复使用。对于智能体每天使用的少数工具，这种方式是可行的，但无法扩展到成千上万个临时需要的接口。

另一种做法，是把所有可用工具的描述都塞进LLM的上下文窗口，让模型自行选择。这受限于上下文预算。也有人采用基于搜索的策略，但工具描述往往过于简略，难以准确区分。

ARD把选择过程移到LLM之外。注册目录利用发布者身份、代表性查询、合规证明、标签等更丰富的信号，为能力建立索引，并提供REST端点。客户端用自然语言搜索，模型再调用搜索返回的能力。这意味着，从人工安装的静态目录转向基于意图的搜索：智能体可以动态发现合适的能力，访问不断增长的MCP工具、A2A智能体及其他服务生态，而不必逐一预先配置。

规范定义了两件事：

名为 ai-catalog.json 的静态清单格式，让发布者能够在约定的固定URL上托管自己的能力。
位于 POST /search 的动态注册目录API，提供实时、经过排序的发现结果。

Hugging Face Hub上的ARD

Hugging Face的Discover工具是我们的ARD参考实现。它可以搜索数千个Skills、机器学习应用和MCP服务器，搜索范围包括Hugging Face及其他ARD发现服务。

它将Hub现有的Spaces语义搜索与我们的Agent Skills结合起来，以ARD目录条目的形式提供结果。Hub已经托管了一批运行Gradio应用、MCP服务器和演示程序的Spaces。它的语义搜索支持 agents=true 参数，根据面向智能体的元数据对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类型还需要额外转换。许多Spaces提供一个 agents.md 文件，说明智能体应如何与它交互。Discover读取该文件，加入skill使用方所期待的frontmatter：name、description，以及包含Space ID、Hub URL、应用URL和原始 agents.md URL的来源元数据。最终得到的skill，可以由任何支持skill的客户端通过其正常skill流程安装或加载。

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

使用方法

discover 已经内置于Hugging Face CLI（hf）。要开始使用，并让你或你的智能体能够访问：

# 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服务器直接搜索目录。

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工具是对这一设计的一次实际验证。它没有发明新的产物格式，而是用规范的封装包裹已有的Hub搜索后端，使同一个Space可以根据客户端的请求，以skill或MCP服务器的形式出现。

下一步是更紧密地集成规范中的联合发现模式（auto、referrals、none），并在Hub侧支持用户和组织个人资料中的静态 ai-catalog.json 清单。完成后，任何Space发布者都可以通过标准的约定URI机制公布自己的能力。