對於開發 AI Agent 的工程師來說，目前最頭痛的問題之一就是如何讓 Agent 找到它需要的工具。目前的實作方式大多是靜態的：開發者必須在設定檔中硬編碼 MCP 伺服器的 URL，或是讓使用者手動安裝插件。這種安裝後才使用（Install-first, use-later）的模式，在面對成千上萬個潛在工具時完全無法擴展。
為了打破這個僵局，由 Google、Microsoft、Hugging Face 等公司共同發起的 Agentic Resource Discovery (ARD) 標準正式登場。簡單來說，ARD 就是為 AI Agent 打造的 DNS 或電話簿，讓 Agent 能在執行過程中，根據當下的需求動態地搜尋並連接到所需的資源。
在理解 ARD 之前，我們需要先釐清三個既有的基礎協議。首先是 MCP (Model Context Protocol)，它定義了 Agent 調用工具的標準方式；其次是 Skills，它讓 Agent 能理解並執行特定指令；最後是 A2A (Agent-to-Agent)，它讓 Agent 之間能互相調用。這三者都解決了如何連接的問題，但它們都假設 Agent 已經知道目標在哪裡。而 ARD 解決的是發現（Discovery）的問題，它位於這三個協議的前端，負責告訴 Agent 該去哪裡找這些工具。
ARD 的運作邏輯分為兩個核心部分。第一是靜態清單 ai-catalog.json，發佈者將其放置在網域的已知路徑（well-known URL），就像網站的 robots.txt 一樣，讓索引系統可以抓取。第二是動態註冊 API，提供一個 REST 接口（例如 /search），讓 Agent 能用自然語言描述意圖，並從中獲取經過排序的資源清單。
這種設計將資源選擇的過程從 LLM 的上下文視窗（Context Window）中移出。過去我們為了讓 LLM 選工具，常將所有工具描述塞進 Prompt，這會迅速耗盡 Token 並降低準確度。ARD 則將搜尋交給外部註冊表，利用發佈者身份、代表性查詢、合規證明等豐富訊號進行篩選，LLM 只需要處理搜尋結果，大大提升了效率。
以 Hugging Face 的實作（Discover Tool）為例，它將 Hub 上的 Spaces 轉化為 ARD 資源。當 Agent 搜尋時，Discover Tool 會根據請求的媒體類型（Media Type）動態轉換輸出。如果請求的是 ai-skill，它會將 Space 內的 agents.md 文件包裝成標準的 Skill 格式；如果請求的是 MCP 伺服器，則會提供對應的 HTTP 端點。這意味著同一個資源可以根據客戶端的需求，靈活地呈現為不同的形式。
然而，動態發現帶來了嚴重的安全風險。如果 Agent 隨便在網路上找到一個工具就直接執行，等於是在工業化地信任陌生人。因此，ARD 標準中至關重要的一環是驗證（Verify）。一個完整的流程應該是：發佈 $\rightarrow$ 抓取 $\rightarrow$ 搜尋 $\rightarrow$ 驗證 $\rightarrow$ 連接。
驗證機制確保 Agent 在調用工具前，能確認發佈者的身份以及資源是否被篡改。例如透過 Ed25519 數位簽名與公鑰驗證，確保資源來自可信的域名。沒有驗證的發現機制，在生產環境中是不可接受的。
對工程師而言，ARD 的意義在於它將發現與執行解耦。無論底層是 MCP 還是 A2A，只要遵循 ARD 的封裝格式，就能被全球的 Agent 發現。如果你目前有維護 API 或 MCP 伺服器，現在就可以透過部署一個 ai-catalog.json 文件，讓你的服務正式進入這個可被搜尋的 Agentic Web 生態系。
來源：huggingface.co
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。