核心概念

傳統 AI Agent 的工具整合採「先安裝、後使用」（install-first, use-later）模式：開發者將 MCP 伺服器 URL 硬編碼進設定檔，工具清單在開發期就已固定。這帶來兩個根本限制：能力被鎖在靜態、手動配置的目錄；備選方案是把所有工具描述塞進 LLM 的上下文視窗，受制於 context 預算。

Agentic Resource Discovery（ARD） 是由 Microsoft、Google、GoDaddy、Hugging Face 等機構聯合開發的開放規範，將「能力選擇」移出 LLM，讓 Agent 在執行任務時以意圖驅動的方式動態發現所需工具，無需預安裝。

ARD 規範定義兩個核心元件：

靜態清單（ai-catalog.json）：發布者在標準 URL（/.well-known/ai-catalog.json）上託管能力清單，包含發布者身份、代表性查詢、合規認證、標籤等富信號元數據。

動態註冊表 API（POST /search）：接受自然語言查詢，返回即時、排序的發現結果。Hugging Face 實作端點為 https://huggingface-hf-discover.hf.space/search。

ARD 定位為發現層，不取代 MCP、A2A 或 Skills 等執行層協議（見 多 Agent 系統協作架構：MCP 與 A2A 協議）。兩者分離讓發現機制可獨立演化。

關鍵要點

媒體類型驅動的擴展性：ARD 用媒體類型區分不同工件協議，新增能力格式無需修改規範。Hugging Face 目前支援三種：

聯盟制架構：服務間可用純 HTTP REST 聯邦查詢彼此目錄，無需中央控管。--registry-url 旗標可指向任意外部目錄，一次請求可呈現多個服務的能力。

hf discover CLI 整合：ARD 整合進 hf CLI（見 hf CLI：為 AI Agent 優化的 Hub 操作介面）：

hf discover search "Fine tune a language model"          # 搜尋技能
hf discover search "Generate an image" --json --kind mcp # 找 MCP 伺服器
hf discover search "Buy airline tickets" --registry-url <url> # 查詢外部目錄

搜索語義流程：HF Hub 先過濾（RUNNING 狀態、代理標籤），再轉換為 ARD 規範，依請求媒體類型返回排序結果。

驗證層是最大開放問題：社群指出發布者身份驗證（Ed25519 數位簽章、信任鏈、防篡改）與發現本身同等重要，規範仍在演進中。

實務應用

REST API 直接呼叫

# 搜尋技能
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

架構意義

ARD 為 AI Agent 建立了類似 DNS 的基礎設施：Agent 在運行時聲明「我需要能做 X 的工具」，系統動態匹配返回，而非開發期就綁死工具清單。這對AI Agent 詞彙指南：Harness、Scaffold 與 Sub-agent 層次定義描述的多層代理系統尤其關鍵——上層 orchestrator 可依任務動態組裝子代理工具鏈，無需提前知道所有可用能力。

延伸觀點

動態發現的 token 效率有實驗支撐

ARD 聲稱動態發現優於「把所有工具描述塞進上下文」的方法，這一點已有學術量化。MCP-Zero（arxiv:2506.01056）針對 2,797 個工具的大規模集合測試：靜態注入方式消耗 248,100 個 token，主動按需發現僅需 111 個 token，token 消耗減少 98%，同時準確率從靜態方案的 69.2% 提升至 95.19%。ARD 的富信號索引（代表性查詢、合規標籤）可進一步提升語義對齊，因為 Agent 自身生成的能力需求描述比原始使用者查詢更貼近工具文件的語言空間。

工具描述品質是發現成敗的關鍵

MCP 生產部署的設計模式研究（arxiv:2603.13417）與 ARD 在「富信號索引」的設計上高度呼應：Agent 僅依據工具名稱與說明做選擇，而非檢視實作細節，模糊描述直接導致工具選擇失敗。ARD 規範要求發布者提供代表性查詢範例，正是從協議層強制改善工具描述品質——這是 MCP tools/list 無法約束的部分。

驗證層：下一個必須解決的架構缺口

兩篇來源都強調驗證問題。動態能力治理研究（arxiv:2603.14332）提出「能力-身份缺口」：現有系統可驗證 Agent 是誰、被授權做什麼，卻無法偵測能力集合在授權後是否被靜默擴充（silent capability escalation）。其解法是能力綁定憑證——以 X.509 v3 擴充儲存工具配置雜湊，工具集變動即使憑證失效。ARD 社群反饋的 Ed25519 驗證需求指向相同問題，意味著 ARD 的下一個版本將需要解決發布者能力聲明的密碼學綁定，才能在零信任環境中安全部署。

延伸閱讀來源：MCP-Zero、Governing Dynamic Capabilities、MCP Design Patterns

反向連結

以下頁面引用了本頁：