如果您今天正在開發 AI 代理，您可能熟悉三種協定：MCP 提供代理呼叫工具的標準方式；Skills 讓代理能夠執行指令；A2A 則允許代理呼叫其他代理。然而，這三者都假設使用者已經知道他們需要哪些工具、指令或代理，使用者仍需負責發現、整合和維護這些功能。
代理資源探索 (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 Discover Tool 是我們對 ARD 的參考實作。它提供對 Hugging Face 和其他 ARD 探索服務上數千種 Skills、機器學習應用程式和 MCP 伺服器的搜尋存取。
它透過結合 Hub 現有的對 Spaces 的語義搜尋，以及我們的 Agent Skills，並將結果作為 ARD 目錄條目提供。Hub 已經託管了運行 Gradio 應用程式、MCP 伺服器和演示的 Spaces 目錄。其語義搜尋支援一個 `agents=true` 旗標，該旗標會返回根據代理導向中繼資料排序的 Spaces，而 Discover 則將該搜尋轉換為 ARD 規範。
該轉接器應用了兩個過濾器。首先，回應僅包含運行階段為 `RUNNING` 的 Spaces。其次，回應的媒體類型由請求驅動。支援三種媒體類型：`application/ai-skill`（預設，一個包裝 Space 的 `agents.md` 的生成 `SKILL.md`）；`application/mcp-server+json`（用於標記為 `mcp-server` 的 Spaces 的 MCP 伺服器目錄條目）；`application/vnd.huggingface.space+json`（原始 Space 中繼資料，供希望自行處理的客戶端使用）。
技能類型涉及額外的轉換。許多 Spaces 附帶一個 `agents.md` 文件，描述代理應如何與其互動。Discover 會讀取該文件，並用技能消費者預期的前置資料（名稱、描述和涵蓋 Space ID、Hub URL、應用程式 URL 和原始 `agents.md` URL 的來源中繼資料）進行包裝。結果是一個任何支援技能的客戶端都可以透過其正常技能流程安裝或載入的技能。
對於標記為 MCP 的 Spaces，轉接器會生成一個目錄條目，指向 Space 透過 HTTP 傳輸的 Gradio MCP 端點。當 Hub 提供運行時網域時，URL 會使用該網域，否則使用標準的 `.hf.space` 網址慣例。
`discover` 已內建於 Hugging Face CLI (hf) 中。要開始使用並讓您或您的代理存取：
```bash
# 安裝 Hugging Face CLI 工具：
uv tool install huggingface_hub
# 搜尋用於訓練模型的資源
hf discover search "Fine tune a language model"
# 尋找用於生成圖像的 MCP 伺服器
hf discover search "Generate an image" --json --kind mcp
# 搜尋其他註冊中心
hf discover search "Purchase aeroplane tickets" --registry-url <catalog-url>
```
您也可以使用 REST API 或 MCP 伺服器直接搜尋目錄。Hugging Face 目錄發布在其眾所周知的 URL：`https://huggingface.co/.well-known/ai-catalog.json`。
要直接呼叫搜尋：`POST https://huggingface-hf-discover.hf.space/search`
```bash
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 伺服器：
```bash
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 Tool 是該設計的一個實際測試。它沒有發明新的工件格式，而是將現有的搜尋後端（Hub）包裝在規範的封裝中，並根據客戶端的需求，讓相同的 Spaces 以技能或 MCP 伺服器的形式呈現。下一步是更緊密地整合規範的聯邦模式（自動、推薦、無），以及 Hub 端對使用者和組織個人資料上靜態 `ai-catalog.json` 清單的支援。
一旦這些功能落地，任何 Space 發布者都將能夠透過標準的眾所周知 URI 機制宣傳其功能。
了解更多：
代理資源探索規範：https://agenticresourcediscovery.org/
Hugging Face Discover Tool：https://github.com/huggingface/hf-discover
Hugging Face CLI：https://github.com/huggingface/huggingface_hub
Hub 上的代理技能：https://huggingface.co/docs/hub/agents-skills
Hugging Face Spaces：https://huggingface.co/spaces