AI 代理（AI agent）開始能寫文件、查資料、呼叫程式介面（API）與操作工具後，下一個卡點會變成：它到底該用哪一個工具？公司內部可能有客服查詢、報表、翻譯、資料清理、付款、文件搜尋等十幾種能力，使用者也不一定知道每個工具名稱。
Agentic Resource Discovery（ARD）想補的就是這一層。你可以把它想成「給 AI 代理的資源搜尋層」：代理先描述任務，發現服務回傳合適的技能（Skills）、MCP 伺服器、API、工作流或其他代理，接著再由原本的協定或系統去執行。對產品、營運、資料與平台團隊來說，現在可以先做一個務實判斷：自己的代理專案是否已經多到需要一份受控工具目錄。
本文依據 Hugging Face 2026-06-17 公告、ARD 規格網站、GitHub 規格儲存庫與 Hugging Face hf-discover 文件整理。ARD 目前仍是 draft；如果你只是使用單一聊天工具，不必急著行動。若你正在做企業代理、內部工具平台、MCP 伺服器目錄或 AI 工作流治理，值得把它放進觀察清單。
ARD 解決哪個卡點？
多數代理專案一開始都採取「先安裝工具，再讓代理使用」的方式。工程師把 MCP 伺服器寫進設定檔，或由使用者把某個外掛接進 AI 應用。工具少的時候可以運作；工具一多，問題就會出現：
- 使用者不知道哪個工具能完成任務。
- 代理一次帶入的工具描述太多，任務反而變難判斷。
- 團隊很難分辨哪個工具由誰提供、是否可信、是否仍可用。
- 內部工具、外部服務、MCP 伺服器、技能（Skills）與工作流散在不同平台。
- 新工具上線後，需要重新設定每個代理或每個 AI client。
ARD 的設計思路是把「找資源」放到執行前。發現服務（discovery service）可以索引一批可被代理使用的資源，使用者或代理以自然語言搜尋，例如「幫我轉錄一段音訊」或「找能整理客服退款規則的工具」。搜尋結果會包含資源名稱、描述、類型、來源、網址、信任或合規相關資訊，再由 AI client（AI 客戶端）決定是否採用。
一個白話例子：客服主管不需要知道每個 MCP 伺服器名稱，只要公司有受控目錄，代理就能先搜尋「查詢訂單狀態」「套用退款政策」「產生補償草稿」這類任務。平台團隊再決定哪些結果能被列入核准工具目錄，哪些任務必須交給人審。
和 MCP、A2A、Skills、OKF 差在哪？
ARD 最容易被誤解成新的代理執行平台。比較清楚的方式，是把它放在「發現 → 連接 → 執行 → 審核」這條鏈路的前段。
| 名稱 | 白話理解 | 它處理什麼 | ARD 和它的關係 |
|---|---|---|---|
| ARD | 幫代理找可用資源的搜尋層 | 依任務搜尋工具、技能（Skills）、MCP 伺服器、API、工作流或其他代理 | 先找到候選資源，後續仍交給各自協定執行 |
| AI Catalog | 資源的描述卡 | 用 ai-catalog.json 描述資源名稱、提供者、類型、位置與信任欄位 | ARD 建在 AI Catalog 這類描述資料上 |
| MCP | 讓代理呼叫工具和資料源 | 工具清單、工具呼叫、回傳結果 | ARD 可以搜尋 MCP 伺服器；MCP 負責實際連接與呼叫 |
| A2A | 讓代理和代理協作 | 任務委派、長任務狀態、跨系統代理溝通 | ARD 可以把 A2A 代理當成可搜尋資源 |
| Skills | 給代理讀的任務指令或操作方式 | 特定工具、流程、任務的使用說明 | ARD 可以回傳可安裝或可載入的 Skill |
| OKF | 公司知識要怎麼整理 | 知識包、檔頭欄位、正文與來源 | OKF 偏知識內容；ARD 偏找得到哪個能力或資源 |
如果你還在理解底層協定，可以先讀 MCP Server 開發教學 和 Google A2A protocol 指南。如果問題是公司知識太分散，再看 OKF 知識包指南。ARD 的位置比較像搜尋目錄與治理入口。
Hugging Face 參考實作做了什麼？
Hugging Face 這次公告的重點，是把 ARD 做成可試的參考實作。官方說 Hugging Face Discover Tool 可搜尋 Hugging Face Hub 上的技能（Skills）、機器學習應用與 MCP 伺服器，也能連到其他符合 ARD 的發現服務（discovery services）。
它目前有幾個關鍵做法：
- 使用 Hub 的語意搜尋。 Discover 會把 Hugging Face Spaces、Agent Skills 和標記為 MCP 伺服器的資源轉成 ARD 資源卡（catalog entries）。
- 只回傳可服務的 Spaces。 官方文件寫明，回應會限制在執行狀態（runtime stage）為
RUNNING的 Spaces，避免代理找到暫時不能使用的資源。 - 同一個搜尋可回不同媒體型別。 AI client 可以要求
application/ai-skill、application/mcp-server-card+json或 Hugging Face Space 原始資料。 - 提供 CLI、REST 與 MCP 入口。
hf discover search可以從命令列搜尋；REST 端點與 MCP 端點則讓其他 AI client 接入。
本站在本次整理時用官方搜尋端點做了輕量驗證：以英文查詢「transcribe some audio」搜尋 MCP 伺服器，回應中包含 Whisper Large V3 的 MCP 伺服器，並附上 Space ID、runtimeStage: RUNNING、Hub/app/MCP 相關網址。這不能代表 production 可用性保證，但足以確認參考實作已經能回傳機器可讀的候選資源。
企業現在該怎麼判斷？
ARD 對企業的價值，不在於多一個英文縮寫，而在於把「代理可以使用哪些能力」變成可搜尋、可審核、可控管的清單。你可以依目前的代理成熟度分流：
| 你的情況 | 這週可以做什麼 | 預期產出 | 先不要做的事 |
|---|---|---|---|
| 只有少數代理和固定工具 | 先整理現有工具清單、owner、用途與權限 | 一份人工維護的核准工具清單 | 不要急著把所有工具都包進公開搜尋 |
| 已有多個部門代理 | 選一個高頻任務建立受控目錄，例如客服退款或內部報表查詢 | 任務 → 可用工具 → owner → 審核條件的對照表 | 不要讓代理自由搜尋整個公開網路工具 |
| 正在做 MCP 伺服器目錄 | 測試把 MCP 伺服器描述轉成 AI Catalog 資源卡 | 可被搜尋與版本控管的資源卡 | 不要只看連線成功，忽略權限與資料外洩風險 |
| 是工具或 API 提供者 | 評估未來是否提供 .well-known/ai-catalog.json | 讓發現服務有機會索引你的能力 | 不要把未完成或未授權能力公開給代理使用 |
| 是 AI 平台團隊 | 設計信任欄位、排序規則、存取政策與人工審核規則 | 一套核准工具目錄與拒用規則 | 不要把搜尋結果直接等同採用建議 |
對多數公司來說，最安全的路線是從「內部受控目錄」開始，先避免開放代理到公開網路自由找工具。內部工具目錄可以先收錄已核准的 API、MCP 伺服器、文件查詢、報表工具與人工流程，並要求每個資源都有負責人（owner）、資料範圍、更新時間、權限限制與失敗時的人工接手方式。
7 天試點：先測一個核准工具目錄
如果你的團隊已經有代理專案，可以用 7 天做一個小試點。目標是確認「搜尋可用資源」這件事是否真的降低操作成本，並且沒有放大風險；追最新規格可以排在後面。
- 選一個任務。 例如客服退款判斷、每週營運報表、合約條款摘要或產品限制查詢。
- 列出 5 到 10 個可用資源。 包含 API、MCP 伺服器、文件查詢、內部工作流或人工審核入口。
- 為每個資源補描述卡。 至少寫清楚用途、提供者、資料範圍、使用限制、負責人（owner）、更新時間與可否由代理自動呼叫。
- 設計 20 個搜尋問題。 用真實使用者會講的話，少用工程命名，例如「查這筆訂單能不能退款」比
refund_policy_tool更接近實際查詢。 - 檢查搜尋結果。 看第一名是否正確、是否能排除不該用的工具、是否會把相似但錯誤的資源排在前面。
- 加上人工審核。 高風險動作先只允許代理建議工具與草稿，不直接執行。
- 留下失敗樣本。 把找不到、找錯、描述不清、權限不足的案例收成下一輪工具目錄改版清單。
這個試點可以不用等 ARD 成熟。即使最後沒有正式採用 ARD，你也會得到一份更乾淨的工具目錄，這對 AI Agent 上線生命週期 本來就是必要工作。
導入限制：Draft、信任、權限與排名都要自己設計
ARD 規格 repo 目前標示 v0.9 Draft。這代表它值得追蹤，也代表企業不應把它當成已固定的合規標準。幾個限制要先講清楚：
- 發現不等於安全。 搜尋到一個工具，只代表它符合查詢條件；能不能呼叫、能不能讀資料、能不能自動執行，要由權限與政策決定。
- 排名不等於推薦。 發現服務（discovery service）怎麼排序，會影響代理選到哪個工具。企業需要自己的核准清單、風險等級與拒用規則。
- 描述品質會決定結果。 如果資源卡寫得模糊，代理可能找錯工具。這和 RAG 一樣，資料品質會直接影響輸出品質。
- 公開聯邦發現不一定適合內部流程。 ARD 支援聯邦式發現（federated discovery），但企業流程通常要先採受控、可稽核的子集合。
- 執行責任仍在原系統。 MCP、API、工作流、代理執行環境（agent runtime）、權限與稽核紀錄都要各自補齊。
用一句話收斂：ARD 可以讓代理更容易找到能力，但不能替你判斷哪個能力可信、誰可以使用、出錯後誰負責。這些仍是產品、平台、安全與法務團隊要一起設計的治理問題。
對 Mason 讀者的採用建議
如果你是產品、營運、客服或資料主管，先把 ARD 當成一個提醒：未來代理會面臨「工具太多、名稱太散、權限太雜」的問題。你現在可以要求平台團隊建立可讀的工具清單，不需要立刻研究每個 JSON 欄位。
如果你是工程或 AI 平台負責人，可以先追蹤 ARD、AI Catalog、MCP 目錄與 A2A 目錄的分工，並把內部工具目錄做成可版本控管的資料。等規格穩定後，再評估是否要提供 .well-known/ai-catalog.json 或接入外部發現服務。
如果你正在做公開工具、互動示範（demo）或 MCP 伺服器，ARD 的訊號更直接：未來工具被代理找到的方式，可能會同時依靠文件頁、工具市集、機器可讀的資源卡、信任欄位與搜尋描述。描述寫得清楚，會變成產品被代理採用的一部分。
FAQ
ARD 會取代 MCP 嗎？
不會。MCP 處理代理如何連接與呼叫工具；ARD 處理代理如何先找到可能有用的工具或資源。實務上，ARD 可以搜尋 MCP 伺服器，找到後仍由 MCP 負責工具互動。
一般企業現在需要導入 ARD 嗎？
多數企業可以先觀察，不必立刻導入。若你的代理專案已經跨多部門、工具數量增加，建議先建立核准工具目錄與工具描述卡；正式是否採 ARD，可以等規格與生態更成熟。
ARD 和公司內部搜尋有什麼不同？
公司內部搜尋通常找文件或頁面；ARD 找的是代理可使用的能力，例如 MCP 伺服器、API、Skill、工作流或其他代理。它更重視資源類型、呼叫位置、提供者、信任欄位與後續執行方式。
風險最大的是什麼？
最大風險是把「找得到」誤解成「可以用」。企業需要權限、資料範圍、人工審核、日誌與回滾規則，避免代理找到不該使用的外部工具或高風險內部能力。