Agent 资源发现功能上线：智能体自主搜索能力

Agentic Resource Discovery（ARD，Agent 式资源发现）规范，是位于这些资源之前的发现层。它是一份开放的规范草案，由 Microsoft、Google、GoDaddy、Hugging Face 等公司的贡献者共同制定，并得到了整个行业的广泛参与。它定义了如何跨联邦注册表对 Agent 和工具进行编目、索引与搜索，让 Agent 能在运行时发现所需能力，而不必预先安装。它不是产品，也不是市场，而是一套任何公司都能独立实现、任何 Agent 或工具都能参与的共享标准。

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

发现问题

目前，Agent 获取能力的模式是：先安装，后使用。开发者将 MCP server URL 硬编码进配置文件；用户则通过插件把某项服务连接到 AI 应用中，之后反复使用。对于 Agent 每天使用的少数几个工具，这种方式行得通；但面对成千上万个临时按需使用的服务界面，它无法规模化。

一种退而求其次的做法，是把所有可用工具的描述全部塞进 LLM 的 context window，再让模型自行选择。但这种方法受限于 context budget。虽然也有基于搜索的策略，但工具描述往往过于单薄，很难准确区分彼此。

ARD 将选择过程移到了 LLM 之外。注册表使用更丰富的信号为各种能力建立索引，例如发布者身份、代表性查询、合规证明和标签，并对外提供 REST endpoint。客户端使用自然语言搜索，模型则调用搜索返回的资源。这意味着，系统从需要手动安装的静态目录，转向基于意图的搜索：Agent 可以动态找到正确的能力，并接入一个不断扩大的 MCP 工具、A2A Agent 及其他服务生态，而不必事先逐一配置。

该规范定义了两项内容：

• 一种名为 ai-catalog.json 的静态 manifest 格式，发布者可以通过 well-known URL 托管自己的能力目录。
• 一个位于 POST /search 的动态注册表 API，用于提供实时、经过排序的发现结果。

Hugging Face Hub 上的 ARD

Hugging Face Discover Tool 是我们对 ARD 的参考实现。通过它，可以搜索 Hugging Face 以及其他 ARD 发现服务中的数千项 Skills、ML 应用和 MCP Servers。

它将 Hub 现有的 Spaces 语义搜索与我们的 Agent Skills 结合起来，并把搜索结果作为 ARD 目录条目提供。Hub 已经托管了大量运行 Gradio 应用、MCP servers 和 demo 的 Spaces。其语义搜索支持 agents=true flag，可以根据面向 Agent 的 metadata 对 Spaces 进行排序；Discover 则负责将该搜索结果转换为符合 ARD 规范的格式。

该 adapter 会应用两项过滤规则。首先，响应只包含 runtime stage 为 RUNNING 的 Spaces。其次，响应的 media type 由请求决定。目前支持三种 media type：

• application/ai-skill：默认类型。根据 Space 的 agents.md 生成封装后的 SKILL.md。
• application/mcp-server+json：适用于带有 mcp-server 标签的 Spaces，返回 MCP server 目录条目。
• application/vnd.huggingface.space+json：返回原始 Space metadata，供希望自行处理的客户端使用。

Skill 类型还涉及额外的转换。许多 Spaces 都包含一个 agents.md 文件，用于描述 Agent 应如何与它们交互。Discover 会读取该文件，并为其添加 Skill 消费方所期望的 frontmatter，其中包括名称、描述以及涵盖 Space ID、Hub URL、应用 URL 和原始 agents.md URL 的来源 metadata。最终得到的 Skill，可以由任何支持 Skill 的客户端通过其常规 Skill 流程安装或加载。

对于带有 MCP 标签的 Spaces，adapter 会生成一个目录条目，通过 HTTP transport 指向该 Space 的 Gradio MCP endpoint。如果 Hub 提供了 Space 的 runtime domain，URL 就使用该 domain；否则使用标准的 .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 Tool

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

Hugging Face 目录发布在其 well-known 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 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
  }'

或者，也可以让任意 MCP Client 连接到 MCP endpoint https://huggingface-hf-discover.hf.space/mcp，通过它搜索目录。

这对规范意味着什么

ARD 将发现与执行分离。静态 manifest 格式由 media type 驱动，因此任何 artifact protocol 都可以使用同一套封装，而不需要修改规范本身。注册表 API 使用普通的 HTTP REST，因此任何客户端都可以与其进行联邦式连接。Discover 是整个生态中多个规范参考实现之一。由于 federation 已内置于协议中，通过一个服务发起的搜索，也可以发现由另一个服务托管的能力。

Discover Tool 是对这一设计的实际验证。它没有创造新的 artifact 格式，而是把现有的搜索后端——Hub——封装进规范定义的格式中，并让同一个 Space 可以根据客户端的请求，以 Skill 或 MCP server 的形式呈现。

接下来的工作包括：与规范中的 federation 模式（auto、referrals、none）进行更紧密的集成，以及在 Hub 端支持用户和组织 profile 上的静态 ai-catalog.json manifest。等这些功能落地后，任何 Space 发布者都可以通过标准的 well-known URI 机制公开自己的能力。

Agentic Resource Discovery 规范：https://agenticresourcediscovery.org/

Hugging Face Discover Tool：https://github.com/huggingface/hf-discover

Hugging Face CLI：https://github.com/huggingface/huggingface_hub

Hub 上的 Agent Skills：https://huggingface.co/docs/hub/agents-skills

Hugging Face Spaces：https://huggingface.co/spaces

博客中的更多文章

Python 中的 Tiny Agents：一个由 MCP 驱动、仅约 70 行代码的 Agent

借助 AI、开放工具和 human in the loop，每周发布 huggingface_hub

Google 刚刚发布了 Agentic Resource Discovery——一项开放标准，由 Google 与 Linux Foundation 联合推出，规定 AI Agent 如何在整个 Web 上发现能力并与之连接。可以把它理解为 Agent 世界里的 DNS 加电话簿。

它的模型很简单：你在自己 domain 的 well-known 路径下发布一个 ai-catalog.json → 注册表对它进行抓取 → Agent 按意图搜索 → Agent 验证发布者 → 然后通过 MCP、A2A 或普通 API 建立连接。发布 → 抓取 → 搜索 → 验证 → 连接。

大多数报道都会聚焦于“发现”。但我想特别指出第 4 步，因为它才是真正重要的一步：验证。Agent 即将根据它发现的内容采取行动——调用工具、提取数据或者作出决策。如果它无法确认资源由谁发布，也无法判断资源是否遭到篡改，那么“我发现了一项能力”毫无价值。没有验证的发现，只不过是在把“信任陌生人”这件事工业化。

这正是我们一直在构建的另一半。因此，当该规范于本周发布时，我们也在同一周推出了自己的目录。Dynamic Feed 现在已经成为一个可验证的 ARD 发布者：身份锚定于 domain，每个 datapoint 都使用 Ed25519 签名，并且可以通过我们的 public key 进行验证。

Agentic Web 将同时具备可发现性与可验证性。很高兴看到这项标准把后半部分也视为一等公民。

如果你发布了 API、MCP server 或 Agent，现在就可以托管一个 ai-catalog.json。它只是一个文件。规范是开放的：github.com/ards-project/ard-spec

· 注册或登录后发表评论