在開發 AI Agent（人工智慧代理人）時，我們通常會給它一些 Tool（工具），例如讓它能呼叫 API 查詢天氣或操作資料庫。目前的開發模式大多是硬編碼（Hardcoded），也就是工程師在寫程式時就定義好 Agent 可以用哪些 API。但當企業規模擴大，工具數量從 10 個變成 10,000 個，且分布在不同部門或第三方服務時，我們就面臨一個巨大的問題：Agent 怎麼知道現在有哪些工具可用？又該如何安全地找到它們？
為了統一這個過程，Google 與微軟、NVIDIA、Hugging Face 等產業夥伴共同推出了 Agentic Resource Discovery (ARD) 規範。簡單來說，ARD 就像是為 AI Agent 設計的黃頁或搜尋引擎，讓 Agent 能在執行任務前，先「發現」並「驗證」它需要的資源。
釐清 ARD 與 MCP 的關係
很多開發者可能聽過 Model Context Protocol (MCP)，這是一個定義 Agent 如何呼叫工具的協議。但這裡有一個關鍵的技術脈絡：MCP 解決的是呼叫階段（Invocation），也就是「我知道工具在那裡，我該怎麼用它」；而 ARD 解決的是發現階段（Discovery），也就是「我不知道在哪裡有能幫我完成任務的工具，請告訴我」。
ARD 並不是要取代 MCP 或 OpenAPI，而是作為一個互補的發現層。Agent 先透過 ARD 找到合適的工具，再透過 MCP 或 OpenAPI 進行實際的溝通與執行。
ARD 的核心運作機制
ARD 規範引入了兩個核心概念：目錄 (Catalogs) 與 註冊表 (Registries)。
首先是目錄。每個組織會在自己的網域中發布一個機器可讀的 ai-catalog.json 檔案。這個檔案就像是一份清單，詳細描述了該組織提供的能力，包括 API 介面、特定技能或 Agent 端點。
其次是註冊表。註冊表負責聚合這些分散在各處的目錄。當 Agent 需要執行某項任務時，它不需要依賴靜態的清單，而是向註冊表發出請求，根據任務意圖（Task Intent）來搜尋相關資源。
安全性與信任鏈
在企業環境中，不能讓 AI Agent 隨便呼叫一個來路不明的 API，這會造成嚴重的資安風險。因此，ARD 將信任與驗證機制內建在規範中，而非事後補強。
它採用基於網域的所有權驗證（Domain-based ownership verification），確保 Agent 在建立連線前，能確認該資源確實是由聲稱的組織所擁有且經過授權。不過需要注意的是，ARD 僅負責發現與驗證身分，至於後續的身份認證（Authentication）、權限控管（Authorization）以及治理政策，仍需由既有的企業安全機制處理。
為什麼這個規範對工程實務很重要
對於開發者而言，標準化的意義在於降低整合成本。如果每個公司都用自己的格式寫工具文件，開發者必須為每個第三方服務撰寫不同的解析邏輯。有了 ARD，只要大家都遵循同一套基線協議，Agent 就能以統一的方式探索能力。
目前這套規範已經有初步的實作案例，例如 GitHub Copilot 的 Agent Finder 以及 Hugging Face 的 Discover Tool，它們都利用 ARD 讓 Agent 能在運行時動態地發現可用能力。
總結來說，ARD 的出現標誌著 AI Agent 從單機的工具調用，走向跨組織、可擴展的生態系統。它讓 Agent 從一個被動接收指令的程式，變成一個能主動在數位環境中尋找資源來解決問題的智能體。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。