跳转至

文章背景与核心概要

现代 AI 智能体高度依赖各种协议,例如用于调用工具的 MCP、用于加载指令的 Skills 以及用于智能体间通信的 A2A。然而,这些协议传统上都假设用户或开发者必须提前手动发现、安装并配置所需的各种能力。这种“先安装后使用”的模式在面对成千上万个临时、按需出现的资源时显得难以扩展。

为了解决这一痛点,由微软、谷歌、GoDaddy 和 Hugging Face 等公司的贡献者共同开发的智能体资源发现(Agentic Resource Discovery, ARD)协议应运而生。ARD 为智能体网络引入了一个去中心化的、基于意图的发现层,标准化了智能体如何在运行时跨联邦注册表动态搜索、编目和验证各种工具与能力,从而实现智能体生态的更高效协作。


Agentic Resource Discovery: Let Agents Search for Tools, Skills, and Other Agents

Published: June 17, 2026
Authors: ben burtenshaw (burtenshaw), shaun smith (evalstate)


📝 Summary

Modern AI agents rely on protocols like MCP (for tools), Skills (for instructions), and A2A (for agent-to-agent communication). However, these protocols traditionally assume that users or developers have already manually discovered, installed, and configured the required capabilities ahead of time.

Agentic Resource Discovery (ARD) introduces a decentralized, intent-based discovery layer to the agentic web. Developed by contributors across Microsoft, Google, GoDaddy, and Hugging Face, ARD standardizes how agents dynamically search, catalog, and verify tools and capabilities at runtime across federated registries.


发现问题

如果你现在正在进行智能体(Agent)开发,你大概率会接触到以下三种协议: 1. MCP:为智能体提供调用工具的标准方式。 2. Skills:为智能体提供消费指令的方式。 3. A2A:为智能体提供调用其他智能体的方式。

The Discovery Problem

If you build with agents today, you probably know three protocols: 1. MCP: Gives agents a standard way to call tools. 2. Skills: Gives agents a way of consuming instructions. 3. A2A: Gives agents a way to call other agents.

但这三种协议都假设用户已经清楚自己需要哪个工具、哪条指令或哪个智能体。发现、集成和维护这些能力的工作依然落在了用户肩上。

当前智能体能力的现状是先安装,后使用。开发者会将一个 MCP 服务器的 URL 硬编码到配置文件中,或者用户通过插件将某个服务连接到他们的 AI 应用中。虽然这种做法对于少数日常工具很管用,但面对成千上万个临时的、按需出现的应用场景时,它就无法扩展了。

All three assume the user already knows which tool, instruction, or agent they need. The user remains responsible for discovering, integrating, and maintaining those capabilities.

The current model for agent capabilities is install-first, use-later. A developer hardcodes an MCP server URL into a config file, or a user connects a service to their AI app via a plugin. While this works for a handful of everyday tools, it fails to scale to thousands of ad-hoc surfaces.

常见的替代方案——将所有可用工具的描述全部塞进大语言模型(LLM)的上下文窗口中——会受到上下文额度的限制,并且往往因为描述过于简略而无法进行有效的消歧。

智能体资源发现(Agentic Resource Discovery, ARD)将选择过程移到了 LLM 外部。注册表不再使用静态目录,而是通过丰富的信号(发布者身份、代表性查询、合规认证以及标签)对能力进行索引,并对外暴露一个 REST 端点。客户端通过自然语言进行搜索,智能体则直接调用搜索返回的内容。

该规范定义了两个主要组件: * 一个名为 ai-catalog.json 的静态清单格式,允许发布者在众所周知的 URL 上托管他们的能力。 * 一个位于 POST /search 的动态注册表 API,提供实时的、经过排序的发现服务。

The common fallback—dumping every available tool description into the LLM's context window—is limited by context budgets and often suffers from descriptions that are too thin for effective disambiguation.

Agentic Resource Discovery (ARD) shifts selection outside the LLM. Instead of static catalogs, a registry indexes capabilities with rich signals (publisher identity, representative queries, compliance attestations, and tags) and exposes a REST endpoint. Clients search in natural language, and agents invoke whatever the search returns.

The specification defines two main components: * A static manifest format called ai-catalog.json that lets publishers host their capabilities at a well-known URL. * A dynamic registry API at POST /search that provides live, ranked discovery.


Hugging Face Hub 上的 ARD

Hugging Face 的 Discover Tool 充当了 ARD 的参考实现,它提供对 Hugging Face 及其他 ARD 发现服务中成千上万个 Skills、ML 应用和 MCP 服务器的搜索访问权限。

它将 Hub 原有的 Spaces 语义搜索与 Agent Skills 相结合,将搜索结果作为 ARD 目录条目进行提供。Hub 的语义搜索支持一个 agents=true 标志,该标志会返回按面向智能体的元数据进行排序的 Spaces,随后 Discover 会将其转换为 ARD 规范格式。

ARD on the Hugging Face Hub

The Hugging Face Discover Tool serves as a reference implementation of ARD, providing search access to thousands of Skills, ML applications, and MCP Servers across Hugging Face and other ARD discovery services.

It combines the Hub's existing semantic search over Spaces with Agent Skills, serving results as ARD catalog entries. The Hub's semantic search supports an agents=true flag that returns Spaces ranked by agent-oriented metadata, which Discover then translates into the ARD specification.

应用的过滤器与媒体类型

该适配器应用了两个核心过滤器: 1. 仅返回运行时状态为 RUNNING 的 Spaces。 2. 根据请求提供由其驱动的响应媒体类型(Media Types),支持三种格式: * application/ai-skill(默认):一个生成的 SKILL.md 文件,其中包装了 Space 的 agents.md。 * application/mcp-server+json:针对标记为 mcp-server 的 Spaces 的 MCP 服务器目录条目。 * application/vnd.huggingface.space+json:用于自定义客户端处理的原始 Space 元数据。

Skill 类型会经历一次特殊的转换。Discover 会读取 Space 的 agents.md 文件,并为其包装上技能消费者所期望的标准 frontmatter:name(名称)、description(描述)以及源元数据(Space ID、Hub URL、应用 URL 以及原始 agents.md URL)。

对于带有 MCP 标签的 Spaces,适配器会生成一个直接指向该 Space 通过 HTTP 传输的 Gradio MCP 端点的目录条目。

Applied Filters and Media Types

The adapter applies two core filters: 1. Only returns Spaces whose runtime stage is RUNNING. 2. Serves response media types driven by the request, supporting three formats: * application/ai-skill (Default): A generated SKILL.md wrapping the Space's agents.md. * application/mcp-server+json: An MCP server catalog entry for Spaces tagged mcp-server. * application/vnd.huggingface.space+json: Raw Space metadata for custom client handling.

The skill type undergoes a special transformation. Discover reads a Space's agents.md file and wraps it with standard frontmatter expected by skill consumers: name, description, and source metadata (Space ID, Hub URL, app URL, and original agents.md URL).

For MCP-tagged Spaces, the adapter generates a catalog entry pointing directly to the Space's Gradio MCP endpoint over HTTP transport.


使用 ARD

discover 工具直接内置在 Hugging Face CLI (hf) 中。

Using ARD

The discover tool is built directly into the 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

REST API and MCP Tool

You can also query the catalog directly via its REST API or an MCP Server.

  • Hugging Face Catalog URL: https://huggingface.co/.well-known/ai-catalog.json
  • Search Endpoint: POST https://huggingface-hf-discover.hf.space/search

示例:搜索 AI 技能

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
  }'

Example: Searching for an AI Skill

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 端点进行搜索。

Example: Searching for MCP Servers

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
  }'

Alternatively, you can connect any MCP Client to search via the MCP endpoint at https://huggingface-hf-discover.hf.space/mcp.


这对规范意味着什么

ARD 干净利落地将“发现”与“执行”解耦。由于静态清单格式依赖于媒体类型(media types),任何工件协议都可以在同一封装(envelope)下运行,而无需修改规范本身。

由于联邦机制(federation)直接内置于协议中,通过一个服务发起的搜索查询,就可以呈现完全由不同提供商托管的能力。

生态系统的下一步发展包括: * 与联邦模式(autoreferralsnone)进行更紧密的集成。 * Hub 端支持在用户和组织主页上使用静态的 ai-catalog.json 清单,允许任何 Space 发布者通过标准的知名 URI(well-known URIs)来宣称其能力。

What This Means for the Specification

ARD cleanly separates discovery from execution. Because the static manifest format relies on media types, any artifact protocol can operate on the same envelope without requiring changes to the specification.

With federation built directly into the protocol, a search query through one service can surface capabilities hosted by entirely different providers.

Next steps for the ecosystem include: * Tighter integration with federation modes (auto, referrals, none). * Hub-side support for static ai-catalog.json manifests on user and organization profiles, allowing any Space publisher to advertise capabilities via standard well-known URIs.


了解更多

Learn More