MCP 之上少了一層：Google 等 11 家公司用 ARD 讓代理人自己找工具

重點一：2026 年 6 月 17 日，Google 在 Developers Blog 公布 ARD（Agentic Resource Discovery） 開放規格，Google、Microsoft、GitHub、Hugging Face、NVIDIA 等 11 家公司共同推出，採 Apache 2.0 授權。

重點二：ARD 補的不是代理人怎麼「呼叫」工具——那是 MCP 的事——而是怎麼「找到」工具：機構在自家網域 /.well-known/ai-catalog.json 放一份能力清單，registry 像搜尋引擎爬取索引，代理人在執行當下用自然語言查、用網域所有權驗證來源。

重點三：規格仍是草案、採用未定；11 家名單裡沒有 Amazon、Apple、Meta，Google 自家的 John Mueller 也已對「相似檔案難辨識」提出疑慮。

今天的 AI 代理人要用一個工具，流程其實很笨：得有人先把那個工具的 MCP server 網址，手動寫死進一份設定檔。換一個工具、加一個服務，就再改一次設定。另一條路是把幾十個工具的說明全塞進模型的 context，但那受 context 預算限制，工具一多就爆。

6 月 17 日，Google 在 Developers Blog 公布的 Agentic Resource Discovery（ARD） 規格，要處理的正是這件事。它由 11 家公司共同推出——Google、Microsoft、GitHub、Hugging Face、Cisco、Databricks、GoDaddy、NVIDIA、Salesforce、ServiceNow、Snowflake——採 Apache 2.0 授權，建立在 Linux Foundation 的 AI Catalog 資料模型之上。

值得讀下去的理由不是「又一個代理人標準」。而是 ARD 補的位置很精確：過去一年，MCP 讓代理人有標準方式去「呼叫」工具；ARD 處理的是它的上一步——代理人怎麼先找到那個工具。

ARD 想補的位置：MCP、A2A、Skills 都假設「你已經知道要用哪個工具」

Hugging Face 在官方說明裡把這層關係講得很直白：「MCP 讓代理人有標準方式呼叫工具。Skills 讓代理人有方式消化指令。A2A 讓代理人有方式呼叫其他代理人。這三者都假設使用者已經知道要用哪個工具、指令或代理人。」

ARD 把這個「已經知道要用哪個」的假設拿掉。它不取代 MCP，而是疊在上面——讓代理人在執行的當下，自己去搜尋有哪些能力可用，再交給 MCP 去呼叫。

層	解決什麼	預設前提
MCP	代理人呼叫工具的標準方式	你已經知道要用哪個工具
A2A	代理人呼叫其他代理人	你已經知道要找哪個代理人
Skills	代理人消化指令	你已經知道要載入哪份指令
ARD	代理人找到上述這些能力	—（補上「先找到」這一步）

差別具體到一句話就清楚：MCP 讓代理人會「呼叫」工具，但不會「找到」工具——ARD 補的就是這一層。

規格怎麼運作？一份 ai-catalog.json 放在網域的 /.well-known/ 路徑

ARD 定義兩個基本元件，catalog 與 registry。

catalog 是發佈端。機構把一份靜態清單檔 ai-catalog.json，放在自家網域的一個 well-known 路徑上，例如 https://yourdomain.com/.well-known/ai-catalog.json。這份清單裡可以列出機構提供的 MCP server、A2A 代理人、OpenAPI 工具，甚至巢狀指向其他 catalog。Hugging Face 自己的範例就放在 https://huggingface.co/.well-known/ai-catalog.json。

registry 是發現端。它的角色「像針對代理人資源的搜尋引擎」：去爬取各網域的 catalog、索引內容，然後用自然語言回應代理人的查詢，回傳符合的能力與一組驗證 metadata。換句話說，「選哪個工具」這個決定，被從模型內部（塞進 context）搬到模型外部一個可搜尋的 registry，在執行當下完成。

Hugging Face 提供了一個參考實作叫 Discover，開發者可以用 CLI 直接查，例如：

hf discover search "Fine tune a language model"

但官方特別強調這條界線：「它不是一個產品，也不是一個市集。它是一個共享標準，任何公司都可以獨立實作。」

為什麼用「網域所有權」當信任根，而不是另開一個市集？

代理人找到一個工具後，下一個問題是：這個來源可信嗎？ ARD 的答案不是審核制的中心化市集，而是把信任掛在網域所有權上。

因為 catalog 必須放在機構自家網域的 well-known 路徑，「對那個網域的所有權，就成為身分與信任的加密根據」。你能把清單放上 stripe.com 的 well-known 路徑，本身就證明你控制 stripe.com。registry 在回傳能力時，會一併帶上 publisher identity（發佈者身分）、representative queries（代表性查詢）、compliance attestations（合規聲明）、tags 等較豐富的信號，讓代理人據以判斷該不該連上去。

這條設計把 ARD 和 App Store 式的中心化市集分開：沒有單一守門人決定誰能上架，能見度建立在「你擁有的網域」上——這也是它沿用網站世界既有的 /.well-known/ 慣例的原因。

11 家公司各帶了什麼進來，誰沒進來？

ARD 不是 Google 單獨的規格，而是一個跨廠商聯盟，背書名單橫跨雲端、開發工具、資料平台與晶片。

進來的公司	代表的位置
Google、Microsoft	雲端與作業系統級平台
GitHub、Hugging Face	開發者與模型／工具發佈樞紐
NVIDIA	運算與加速層
Salesforce、ServiceNow、Snowflake、Databricks	企業 SaaS 與資料平台
Cisco、GoDaddy	網路基礎建設與網域／代管

GoDaddy 出現在名單上並不違和——當信任根是網域所有權，網域代管商本來就站在這條線的關鍵位置。Hugging Face 則營運參考實作 Discover，把既有的 Spaces 包成可被發現的資源。

對台灣大量在做 MCP server、工具與 API 包裝的開發者與團隊，這份規格牽動的是一個供給線前提：未來若 registry 生態真的成形，「有沒有發佈 ai-catalog.json」會成為自家工具能否被代理人自動找到的條件。今天它還不改變任何工具選擇，但這條線值得放進視野。

至於誰沒在名單上，也是訊號：Amazon（AWS）、Apple、Meta 都不在 11 家之列——NVIDIA 在，但雲端三雄裡缺了 AWS。

還沒有答案的是什麼？

ARD 是一份草案規格，採用率尚未獲得證實——它定義了發佈與發現的格式，但「會不會被廣泛實作」是另一回事。

技術上的疑慮已經有人提出。Google 自家的 John Mueller 先前就論點，LLM 系統難以區分使用相似檔案的網站；批評者也指出，ARD 瞄準的是工具發佈者，而非一般內容網站。registry 由誰營運、會不會在「沒有中心市集」的設計下，反而長出新的事實守門人，規格本身沒有給答案。

把今天這件事收束成一句：代理人的堆疊裡，多了一塊叫「發現」的拼圖——ARD 補的是「找到」，不是「呼叫」，而它把這件事交給了網域所有權。 它是不是會成為那個標準，要看 11 家名單之外、尤其是缺席的那幾家，接下來怎麼接。

---

資料來源：Google Developers Blog（Announcing the Agentic Resource Discovery specification）、Hugging Face Blog（Agentic Resource Discovery: Let agents search）、GitHub ards-project/ard-spec、Search Engine Journal、Let’s Data Science。

林子睿（編輯：廖玄同），《MCP 之上少了一層：Google 等 11 家公司用 ARD 讓代理人自己找工具》，矽基前沿 [Si]gnals，2026-06-19。https://signals.tw/articles/agent-discovery-standard-ard/