隨著AI代理與MCP伺服器不斷增加，究竟有哪些資源可用，已經超出人力所能掌握的範圍。專門針對這個找不到的難題而訂定的共通規範，就是Agentic Resource Discovery，簡稱ARD。它以Apache License 2.0的開放規範形式公開，Google、微軟、GitHub、NVIDIA等11家公司的工程師參與了設計與審閱。Amazon Web Services也在制定過程中提供意見，並於8月24日說明了它與自家AWS Agent Registry的搭配方式[1]。
缺的不是工具，而是工具的索引
現在AI用戶端能呼叫的，早已不只是模型記住的知識。工具、Skill、MCP伺服器、API、工作流程、其他代理，ARD文件把這些統稱為代理資源。
問題在於，它們增加的速度已經超過人力跟得上的程度。必須有人去找到資源，判斷是否堪用可信，接進用戶端，再持續維護這條接線。在知名工具只有幾個的年代還轉得動，可是一旦公司內部團隊、供應商與個人都在發布自己的資源，負擔就會急遽加重。更麻煩的是，替某一個用戶端設定好，並不代表另一個用戶端也能使用。
換句話說，卡住的環節不是呼叫，而是呼叫之前的發現。用戶端無法使用它不知道存在的能力，企業也不可能要求每位員工記住所有內部工具與已核准的服務。
ARD只規定了搜尋的入口
ARD劃定的範圍窄得有些出乎意料。用戶端只提出一個問題：這項工作能用什麼資源。回傳的是一組符合條件的結果，說明它做什麼、由誰提供、位於何處、如何抵達。
再往後的實際呼叫不歸ARD管。無論是MCP、API還是代理框架，都交給所選資源本身的機制。把ARD想成坐在呼叫之前的一層，就比較容易理解。
搜尋介面由3個端點定義。
| 端點 | 作用 | 屬性 |
|---|---|---|
| POST /search | 依工作內容尋找資源 | 必要 |
| POST /explore | 篩選並瀏覽集合 | 選用 |
| GET /agents | 取出集合中的項目 | 選用 |
至於資源本身的描述，則使用稱為ARD條目的記述單位。在v0.91規範中，一個條目就是一個JSON-LD節點，讓型態各異的資源能用同一套寫法說明做什麼、誰提供、在哪裡、怎麼抵達[2]。發布方把條目放在自有網域的/.well-known/ard.json下。前身規範使用的/.well-known/ai-catalog.json如今只是可選的舊名，現行版本建議發布方改用ard.json[2]。
收錄範圍如何界定、排序、代管以及商業模式，ARD一概不規定。既可以是把網路上公開內容照單全收的寬鬆集合，也可以是只放已核准資源的嚴選集合。規範方也預期，企業實際上會選擇後者。
實作的一方，與接上的一方
具備這套介面的集合，在ARD規範中稱為Agent Registry，實際落地時多半以「Agent Finder」之名出現。GitHub的Agent Finder、Hugging Face的Discover Tool、思科的AI Catalog、Ora Directory，以及可以自行架設的ANS Finder，都已被列為官方參考實作[3]。
使用的一方則透過Claude、ChatGPT、GitHub Copilot、微軟Copilot、Gemini等用戶端，經由Skill或遠端MCP連接器接上Agent Finder。請它找出適合某項工作的能力，候選就會列出來，要裝哪一個由使用者自己決定。
AWS從企業內部目錄那一側切入
AWS同期主打的是AWS Agent Registry，這是面向組織內部的目錄，由登錄庫與登錄紀錄兩個層級構成。
運作流程分為4個階段。管理者建立登錄庫，設定審核規則以及以IAM或企業身分提供者簽發的JWT為基礎的授權；發布者把自己的MCP伺服器、代理或工具登記成紀錄並送出審核；策展者負責審查、核准或退回，並把不再使用的紀錄標為淘汰；接著使用者，可以是人也可以是代理，搜尋所需的資源。
搜尋採用語意理解與關鍵字比對並用的混合方式，自然語句提問與精確名稱查找都行得通。登錄庫本身以遠端MCP端點提供，支援MCP的用戶端可以直接查詢。搭配跨帳戶共用，一個登錄庫就能涵蓋整個AWS Organization。
被拿來比喻的是DNS
不過只要登錄庫還關在企業內部，跨環境的搜尋就解不開。當多個雲端、地端環境、SaaS與業務應用各自維護格式與命名規則不同的目錄時，想互通幾組，就得做幾個專用連接器。
AWS對ARD的期待正好落在這裡。依該公司的說法，可以把它想成：DNS在網路之間承擔名稱解析，ARD則在登錄庫之間承擔同樣角色的聯邦。只要各環境的目錄都以同一套協定對外開窗，不必逐一達成雙邊約定，跨環境的搜尋就能成立。
不搬遷也能聯邦，發現範圍放寬而控制權留在本地，把目錄發布在自有網域上就能被組織外部找到。AWS列出的這3個目標，前提都是不更動既有的權限管理。
總結
ARD不是產品，而是把發現這一環單獨切出來的開放約定。正因為範圍只限於搜尋入口，它才能疊在既有的MCP與API之上而不起衝突。11家公司的名字並列出現，代表代理數量將持續攀升這件事已成為共識。剩下的問題是，究竟會有多少企業真的照這個格式公開自己的目錄。這類標準的成敗，與其說取決於規範本身是否精巧，不如說取決於最後收錄內容的數量。
出典:https://agenticresourcediscovery.org/spec/
出典:https://agenticresourcediscovery.org/ref_implementations/
