Agentic Resource Discovery：給 agent 的 robots.txt——開放發現規格與 HF 參考實作拆解

瀏覽次數: 1

本文大綱

當你的 agent 需要一個「它還不知道存在」的能力

過去一年，整個產業把心力放在「兩個 agent 之間怎麼講話」（A2A）、「agent 怎麼呼叫工具」（MCP）。這兩件事大致都解了，但中間漏掉一個更前置的問題：一個 agent 要怎麼先「找到」那個它根本還不知道存在的能力，並且確認連上去是安全的？

今天每個平台都有自己的 registry——各家模型商有、各家雲也有——但它們彼此封閉、各說各話。結果是：跨組織的 agent 無法互相發現，能力被鎖在各自的生態孤島裡。2026 年 6 月 17 日，Google 在 Developers Blog 發表 Agentic Resource Discovery（ARD） 規格，想把這層「發現與信任」變成像 DNS、像 robots.txt 一樣開放、去中心化的基礎設施。

這件事為什麼現在才浮上檯面？因為前兩層的標準化大致塵埃落定了。當 agent 還只會連幾個寫死的工具時，「發現」根本不是問題——端點就那幾個，寫進設定檔就好。但一旦你期待 agent 能在執行當下，依任務臨時去找出「世界上某處有沒有人提供我現在需要的這個能力」，缺一層通用的發現與信任協定就成了硬傷。ARD 想補的正是這一塊：它不是又一個框架，而是一層協定。

它到底要解決什麼

先把名詞定清楚：agentic resource（代理資源） 是任何 AI 用戶端可以呼叫來完成任務的外部能力——一個 agent、一台 MCP server、一個 Skill、一支 API、一條 workflow，或一筆 AI Catalog entry。ARD 要回答的是 agent 面對這些資源時的三個問題：

對的能力住在哪裡？（Where）
我到底該用哪一個？（Which）
連上去安全嗎？（How to verify）

關鍵設計選擇是去中心化。ARD 不蓋一個「全世界唯一的大目錄」，而是讓每個組織在自己的網域上發布，再由多個可互通的 registry 去爬、去索引。這跟 web 本身的長相一致：沒有人擁有整個 web，但搜尋引擎都能索引它。

為什麼非得這樣不可？因為「中心化目錄」這條路前面已經有人走過、也撞過牆。各家平台的 plugin store、tool marketplace、MCP registry 都是中心化目錄：你得去某個平台註冊、由那個平台審核、被那個平台的命名空間綁住。結果是同一個能力要在五個地方重複登記，跨平台的 agent 還是看不到彼此。ARD 的賭注是：與其再蓋第六個中心目錄，不如把「宣告」這件事還給網域擁有者——你在自己家門口（well-known 路徑）掛牌，誰想索引就來爬，這套機制 web 已經用 robots.txt、sitemap、.well-known/ 驗證了二十年是可行的。

運作原理：發布 → 發現 → 驗證 → 直連

ARD 建立在兩個基本元件上：Catalog（目錄） 與 Registry（登錄所）。整條鏈路可以拆成四個階段。

① 發布 Catalog。 提供方在自有網域的 well-known 路徑掛一份 JSON：https://{domain}/.well-known/ai-catalog.json（規格也允許 robots.txt 指示、HTML link tag、DNS SVCB 記錄等替代發現方式）。這份 manifest 的骨架是：

{
  "specVersion": "...",
  "host": { "displayName", "identifier", "trustManifest", ... },
  "entries": [ { CatalogEntry }, ... ]
}

每一筆 CatalogEntry 至少要有：identifier（URN，格式 urn:ai:<publisher>:<namespace>:<agent-name>）、displayName、type（用 IANA media type 標示，例如 application/mcp-server+json、application/a2a-agent-card+json），以及 url（遠端參照）或 data（內嵌）二擇一。選填欄位包含 description、tags、capabilities、representativeQueries、version、trustManifest 等。

這裡最聰明的設計是：因為 catalog 掛在你自己的網域下，網域所有權本身就是信任根——不需要再去某個中心機構註冊、發證。

② 發現 / 解析。 Registry 是「agentic web 的搜尋引擎」。它用 web ingestion pipeline 去爬各家的 ai-catalog.json 並建索引（規格明訂所有實作 MUST 支援 web 爬取）。一個 client agent 需要能力時有兩條路：對 registry 發一個自然語言 intent 去 POST /search（回傳帶 0–100 相關度分數的排序結果）；或者完全跳過搜尋，直接抓某個已知夥伴網域的 catalog。Registry 怎麼知道哪個 entry 是另一個 registry？靠 type 為 application/ai-registry+json 的條目——於是 registry 之間能形成聯邦，client 用 federation 參數（auto / referrals / none）決定要不要把上游結果一起併進來。規格另外定義了 POST /explore（分面聚合，選用）與 GET /agents（確定性列舉，選用）兩個端點。

③ 驗證信任。 這是 ARD 跟「又一個 API 目錄」拉開差距的部分。每筆資源可附一個 trustManifest：

{
  "identity": "<密碼學工作負載身分>",
  "identityType": "spiffe | did | https",
  "attestations": [ ... ],
  "provenance": [ ... ],
  "signature": "<detached JWS>"
}

規則是：URN 裡的 <publisher> 段，必須對齊 trustManifest.identity 的密碼學身分根。換句話說，「宣稱我是 example.com 的能力」這件事，要能用 SPIFFE / DID / HTTPS 的密碼學憑證實際證明，而不是嘴上說說。這讓零信任驗證成為可能——agent 連線前可以先確認對方真的是它宣稱的那個發布者。

④ 直連執行。 驗證過後，client 動態載入選定能力，改用該能力的原生協定（A2A、MCP、OpenAPI…）直接互動。請注意這個邊界：ARD 只管「發現與信任」，不介入執行層。它不是要取代 MCP 或 A2A，而是站在它們前面，補上「找到對的端點」這一環。

把四步合起來走一個具體例子比較有感。假設你的 agent 要「把這份合約轉成 PDF 並寄出」：它先帶著這句自然語言意圖打某個 registry 的 /search，registry 回傳幾筆候選——可能來自 acme.com 的文件轉檔 MCP server、來自 mailer.io 的寄信 A2A agent，每筆都附 score 與 trustManifest。agent 挑分數最高的那筆，先驗證 acme.com 宣稱的身分確實對得上它 URN 裡的 publisher 段，確認不是有人冒名掛了一個惡意端點，才用 MCP 協定實際連上去呼叫。整個過程裡，agent 事前完全不需要知道 acme.com 這個服務存在——這正是「discovery」與「寫死整合」的根本差別。

數據與限制：先別當成定案

誠實講清楚現況：

版本是 v0.9（Draft），授權 Apache-2.0，規格與 schema（CDDL / JSON Schema / OpenAPI）放在 ards-project/ard-spec。它還在提案階段，欄位與行為都可能變動。（補一個小觀察：規格範例裡的 specVersion 寫成 "1.0"，整份文件標的卻是 v0.9 draft——這種不一致正是早期規格的常態，別照抄版本號。）
它建立在既有的 ai-catalog 標準之上，背後是 Linux Foundation 旗下的 AI Catalog Working Group。
目前沒有公開的採用數字——多少網域已掛 catalog、多少 registry 在線上運作，官方都還沒給數據。任何「已被廣泛採用」的說法現階段都該打折。
參與方：Google 官方文中以「launch partners」與 Linux Foundation AI Catalog WG 概括，作者為 Junjie Bu（Senior Staff Software Engineer）與 Srinivas Krishnan（Distinguished Software Engineer）。多方報導與儲存庫資訊指出，協作者包含 Microsoft、Hugging Face、GoDaddy 等。Hugging Face 已在其 GitHub 提供一份 ARD 的 Client/Server 參考實作（Python；有來源指其授權為 MIT）——這也是本文標題說「HF 實作併入」的由來：規格不只是紙上談兵，已經有可跑的開源實作可以照著理解資料流。

適用場景與 trade-off

什麼時候值得關注：

你在做跨組織、跨平台的 agent 互通——要讓自家 agent 動態發現合作夥伴的工具，而不是把每個整合寫死。
你是能力提供方（賣 API、賣 agent、賣 MCP server），想被別人的 agent「搜尋得到」，而且想用網域證明「這真的是我發布的」。
你需要可驗證的供應鏈信任——在 agent 自動選工具的世界，「這個端點是不是冒充的」會變成真實的攻擊面。值得提醒：開放發現是一把雙面刃，當 agent 能自動搜尋並連上陌生能力，prompt injection、惡意 catalog、registry 投毒（往索引塞假能力騙 agent 上鉤）這些風險也一起放大了。ARD 的 trustManifest 是針對「身分冒充」設計的解法，但「內容可信」「行為可信」並不在它的守備範圍——這部分仍要靠你自己的沙箱、權限控管與人類審核補上。

什麼時候別急著上：

你的 agent 只連內部、數量固定的工具——直接在 config 寫死端點更簡單，發現層是多餘的開銷。
你需要生產級穩定性——v0.9 draft 不適合壓在關鍵路徑上。
某個雲的託管版就夠用——例如 Google Cloud 在 Gemini Enterprise Agent Platform 推的 Agent Registry，有 HIPAA 合規、namespaced URN、以 trust manifest 做 Agent Identity 驗證等企業功能；但選它就意味著你綁在某家供應商的實作上，而非開放規格本身（官方說原生 ARD 支援「未來數月」才到）。

對工程團隊的意義

把 ARD 想成「agent 時代的 robots.txt + DNS」會比較好定位它：一層讓能力可以被公開宣告、被聯邦式索引、被密碼學驗證的薄協定。給團隊的可操作建議：

如果你發布能力：現在就能實驗性地在 /.well-known/ai-catalog.json 掛一份 catalog，把你的 MCP server / API 用 URN + IANA type 描述好。成本很低，而且這會逼你把「我有哪些對外能力、怎麼證明是我的」想清楚。
如果你消費能力：先別把發現層接進關鍵路徑，但值得拿 Hugging Face 的參考實作跑一個 PoC，把 search → verify → connect 的資料流走一遍，評估它能不能取代你現在手寫的整合膠水。
把信任當第一公民：不論你用不用 ARD，「agent 自動選工具」一旦上線，trustManifest 這套思路（網域錨定 + 簽章 + provenance）就是你遲早要面對的問題。ARD 把它規格化了，值得直接拿來當設計檢查表。

它能不能成為事實標準，取決於有沒有夠多 registry 真的去爬、夠多提供方真的去掛。標準之爭從來不是技術最好的贏，而是網路效應先到的贏——這也是為什麼 Google 選擇把它放進 Linux Foundation、拉多家共同掛名，而不是自己關起門來做：開放治理是降低各方採用心防的必要條件。對工程團隊而言，現階段最務實的態度是「看懂、實驗、別押身家」：理解它的資料模型與信任模型，拿參考實作跑個 PoC 練手感，但先別把 v0.9 的 draft 接進生產關鍵路徑。方向是對的——把「發現」從各家孤島，變成像 web 一樣開放可索引的公共層——但這層基礎設施要長成，還需要時間與生態的共同投票。

來源

Google Developers Blog — Announcing the Agentic Resource Discovery specification（Junjie Bu、Srinivas Krishnan，2026-06-17）：https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/
規格與 schema（CDDL / JSON Schema / OpenAPI）：https://github.com/ards-project/ard-spec ・規格全文：https://agenticresourcediscovery.org/spec
基礎標準：Linux Foundation AI Catalog Working Group（ai-catalog）
Hugging Face：ARD Client/Server 參考實作（Python，見 huggingface GitHub 組織）