hero

城武導讀

2026 年 6 月 17 日，Google 在開發者部落格上發表了 Agentic Resource Discovery（ARD）規範。表面上的故事很乾淨：agent 生態系需要一個統一的發現層，讓任何 agent 能找到任何工具——就像 DNS 加上搜尋引擎之於人類的 web。Google 把 spec 用 Apache 2.0 授權釋出，找了一票夥伴背書，GitHub 和 Hugging Face 已經有參考實作。

但如果你對「Google 推出開放規範」這個句型還保有一點歷史記憶，你會想起 SPDY、想起 WebP、想起 AMP——每一次都是「開放」，每一次最後都長成了 Google 的基礎設施護城河。ARD 會不會是同一個劇本的第四季？本篇文章要拆的，不是 ARD 的技術規格本身——那份 spec 設計得相當乾淨——而是它選擇的信任模型（DNS-based trust）、它刻意留下的空白（不碰 invocation）、以及它在 MCP/A2A/OpenAPI 這些既有 protocol 之間的位置。這三個設計選擇，才是 ARD 真正的政治。

原文摘要

ARD 解決的問題

ARD 的核心命題很簡單：agent 之間互相找到彼此的基礎設施不存在。今天一個 agent 想要使用某個工具，流程大致是：人類先找到那個工具、人類判斷它可不可靠、人類手動設定連線。這在少數知名工具之間還能運作，但當每個組織、每個團隊、每個產品都開始發布 agentic resource（MCP server、A2A agent、OpenAPI 工具），純手動的發現流程會直接崩潰。

ARD 提出的論斷是：瓶頸已經不在 invocation（怎麼呼叫），而在 discovery（怎麼找到）。一個 agent 無法使用它不知道存在的資源。

兩個核心原語

ARD 的架構建立在兩個概念上：

Catalog（目錄）：組織在自己的 domain 底下發布一個 ai-catalog.json 檔案，描述該組織提供的 agentic 資源——MCP server、A2A agent、OpenAPI 工具、甚至嵌套的子目錄。因為 catalog 掛在組織自己的 domain 下，那個 domain 就成為身份的密碼學信任根（cryptographic root of trust）。

Registry（註冊中心）：註冊中心扮演 agentic web 的搜尋引擎。它們爬取已發布的 catalog、建立索引、回應 agent 的查詢。Agent 可以用自然語言意圖進行搜尋，也可以繞過搜尋直接 fetch 已知的 catalog。

端到端流程（四個階段）

  1. 發布 catalog：提供者在自己 domain 上架 ai-catalog.json
  2. 發現與解析：用戶端查詢 registry（或直接 fetch）來找到資源
  3. 密碼學驗證：catalog 附帶的信任 metadata 讓用戶端／registry 在連線前確認發布者的真實身份
  4. 直接執行階段連線：agent 載入資源並透過其原生 API／protocol 互動

ARD 明確定位自己只處理 discovery——它坐落在 invocation 之前，幫助用戶端決定使用哪個資源。要搜尋什麼、何時搜尋、搜尋結果如何處理，都留給系統設計者決定。

Google Cloud 的整合

Google Cloud 正在將 ARD 嵌入 Gemini Enterprise Agent Platform，提供託管的搜尋、發現與資源代管。企業治理功能包括全域唯一命名空間 URN、agentic egress 政策、資源釘選、以及基於 Agent Identity 的信任驗證。原生 ARD 支援預計在未來幾個月內上線。

生態系現狀

規範使用 Apache 2.0 授權，GitHub 上的 Agent Finder 和 Hugging Face 的 Discover 是兩個參考實作。規範本身正在被考慮納入 Joint Development Foundation 的標準專案。

城武觀點

一、「開放規範」作為市場佔領工具：SPDY、AMP，現在是 ARD

讓我們先不要把 ARD 當成一個技術規格來讀，而是當成一個商業動作來讀。Google 在 2026 年 6 月推出 ARD，背後有一個極其精準的時間點：agent 生態系正處於協議混戰期。MCP（Anthropic 主導）在 tool-use 層攻城掠地，A2A（Google 自己主導）在 agent-to-agent 通訊層建立地盤，OpenAPI 已經在 REST API 世界擁有龐大 installed base。這三個協議各自有各自的領地，但沒有人在做 discovery 這一層。

ARD 切入的正是這個真空地帶。它不跟 MCP 競爭（ARD 明確說自己不管 invocation），不跟 A2A 競爭（A2A 是 execution protocol，ARD 是 discovery），不跟 OpenAPI 競爭（ARD 的 catalog 可以直接指向 OpenAPI endpoint）。它做的事情是：定義什麼叫「找到」一個 agentic resource。而誰定義了「找到」的標準，誰就定義了 agent 網路的入口。

歷史上有足夠多的前例。2009 年 Google 推出 SPDY——開放規範、Apache 授權、找了一群夥伴背書。SPDY 後來成為 HTTP/2 的基礎，而 Chrome 作為當時市佔率最高的瀏覽器，Google 實質上控制了 HTTP 協議的演進方向。2015 年 Google 推出 AMP——開放規範、開源、找了一群媒體夥伴背書。AMP 的結果是：媒體網站為了在 Google Search 上獲得「閃電標記」的流量紅利，自願把自己的 HTML 改成 Google 定義的格式。開放，從來不是權力的反面——開放常常是權力最有效的偽裝。

ARD 的 Apache 2.0 授權、Joint Development Foundation 的標準化路徑、GitHub 和 Hugging Face 的參考實作——這些都不是「開放」的證據，而是「開放」的標準劇本。真正的問題不是 ARD 開不開放（它是開放的），而是：當 Google 同時控制著 Gemini Enterprise Agent Platform（ARD 的最大託管 registry）、Chrome（最大的 browser agent 載體）、以及 Android（最大的 mobile agent 平台），一個「開放」的 discovery 規範會長成誰的形狀？

這不是陰謀論。這是平台經濟學的基本原理：平台擁有者推出開放協定，降低生態系的參與門檻，吸引足夠多的參與者之後，平台擁有者透過控制主要的 entry point（在 ARD 的例子裡是 registry 和搜尋排序）來提取租金。開放協定是高速公路，入口匝道是收費站。

二、DNS 作為信任根：一個把權力外包給 ICANN 的設計

ARD 的信任模型建立在一個簡潔的前提上：組織的 domain name 就是它的身份。你發布 ai-catalog.json 在 example.com 下，cryptographic trust metadata 綁定在這個 domain 上——任何 agent 看到這個 catalog，只要驗證 domain 的 TLS 憑證和 trust metadata，就能確認「這個 catalog 確實是 example.com 發布的」。

這個設計在技術上很乾淨。它避免了 PKI 的複雜性、避免了 decentralized identity 的 adoption 問題、避免了聯邦式信任模型的協調成本。DNS 作為信任根的好處是：它已經在那裡了，每個組織都有一個 domain，TLS 以經被全網部署。

但 DNS 作為信任根的代價，是把整個 agent 信任模型的權力，外包給了 DNS 治理結構。而 DNS 治理結構——ICANN、各國 TLD 註冊管理機構、國家級審查機制——從來就不是為了「AI agent 之間的信任」而設計的。

考慮一個情境：某國政府要求其國家級 TLD 註冊機構吊銷某個組織的 domain。在 ARD 的信任模型下，這個組織的 agentic resource——無論它實際上多安全、多可靠——瞬間從 agentic web 上消失。不是因為它做錯了什麼，而是因為 DNS 層的權力被行使了。更微妙的情境：某個 registry 決定不索引某些 domain 的 catalog。這不是技術上的封鎖，是排序上的封鎖——你的 catalog 仍然存在，但沒有 agent 會找到你。

ARD 的設計文件沒有討論這些治理問題。這不奇怪——protocol spec 通常不討論治理，治理被視為「implementation detail」或「policy layer」。但當你的信任模型把單一故障點（DNS）變成信任根的時候，治理就不是 policy layer——治理是架構本身的一部分。一個 protocol 選擇把信任放在哪裡，本身就是一個政治決定。

附帶一提：Google 在中國沒有搜尋業務，但 Google Domains（雖然後來賣給了 Squarespace）和 Google Cloud 的全球 DNS 基礎設施仍然在運作。當 ARD 的 registry 生態系主要由 Google Cloud 託管時，哪些國家的哪些 domain 能被 agent 發現、哪些不能——這個問題的答案不會寫在 spec 裡，但它會被寫在 Google Cloud 的 compliance 文件裡。

三、發現層與執行層的分離：一個好的架構決策，但權力從新分配

ARD 最值得稱讚的設計選擇是：它刻意不碰 invocation。Catalog 裡描述一個資源是什麼、在哪裡、用什麼 protocol，但 ARD 本身不執行任何呼叫——執行階段由資源原生的 protocol（MCP、A2A、OpenAPI）處理。

這個分離在架構上是正確的。它讓 ARD 不需要處理 protocol 之間的語義差異（MCP 的 tool call 跟 A2A 的 agent task 是完全不同的互動模型），它讓現有的 protocol 不用為了被發現而修改自己的 spec，它讓 ARD 的 spec 可以保持極簡。這種「只做一件事並把它做好」的 Unix 哲學，在 protocol 設計中已經越來越少見。

但這個分離也有一個隱含的政治後果：ARD 把執行權下放給各 protocol，但把發現權集中在自己身上。 換句話說，MCP 決定 agent 怎麼使用工具，A2A 決定 agent 之間怎麼通訊——但 ARD 決定 agent 能發現哪些工具、哪些 agent。

這不是中性分工。在一個 agent 網路中，發現層的力量比執行層更大——因為你只能使用你發現的東西。MCP 可以設計出全世界最安全的 tool-use protocol，但如果一個 MCP server 沒有被任何 ARD registry 索引，它就不存在於 agent 的搜尋範圍內。A2A 可以設計出全世界最有效率的 agent-to-agent 通訊協議，但如果兩個 A2A agent 無法透過 discovery 找到彼此，它們就只能靠人類手動配對。

所以當 Google 說「ARD 只做 discovery，不做 invocation」的時候，它說的不是「ARD 比較不重要」——它說的是「ARD 掌握的是更上游的權力」。歷史上，掌握發現層的玩家最終會掌握整個生態系：Google 不生產網頁，它索引網頁；Amazon 不生產商品，它索引商品。ARD 的定位是 agentic web 的搜尋引擎——而搜尋引擎從來就不是中立的公共設施。

四、ARD、MCP、A2A：分工清楚的背後，是各自不可替代的風險

把 ARD 放進目前的 agent protocol 生態系，分工看起來很清楚：

  • ARD：負責發現（這個資源在哪裡？誰發布的？用什麼 protocol？）
  • MCP：負責工具使用（agent 怎麼呼叫外部工具？）
  • A2A：負責 agent 之間的通訊（agent 怎麼委託任務給另一個 agent？）
  • OpenAPI：負責傳統 REST API 的描述（既有的 HTTP API 如何被 agent 理解？）

這個分工表看起來乾淨到幾乎像一張組織架構圖。但生態系不是組織圖——協議之間沒有彙報關係，沒有 CEO 出來仲裁衝突。每個協議都有自己的主導者、自己的商業利益、自己的戰略時間表。

ARD 的風險是：如果 Google Cloud 的 registry 成為 agent discovery 的事實壟斷者，其他 registry 的生存空間會被擠壓——不是因為技術落後，而是因為 Google 掌握了最多 agent 的 deployment footprint（Gemini 生態系），registry 的網路效應會自然集中。

MCP 的風險是：Anthropic 主導的協議，在 Google 主導的 discovery 層之下，會失去生態系的可見度。一個 MCP server 如果沒有在 ARD catalog 中被良好描述，它在 agentic web 上的能見度就歸零。

A2A 的風險是：A2A 是 Google 自己的協議，但 ARD 也是 Google 主導的。表面上是互補，實際上是一個公司控制了 agent 通訊的兩個相鄰層。當同一個玩家同時定義「如何找到 agent」和「agent 之間如何通訊」的時候，第三方 agent framework 要在這個生態系裡保持獨立性，成本會越來越高。

這不是說 ARD 是壞協議。ARD 的設計文件讀起來是一個深思熟慮的 spec。但協議的生態系動力學跟協議的技術品質是兩回事。一個技術上優秀的協議，被一個有結構性優勢的玩家主導之後，生態系的演化方向就不再由技術品質決定——而是由那個玩家的戰略需求決定。

城武的未解檔案——ARD 把 agent discovery 比喻成 DNS 加搜尋引擎的合體，這個比喻精確得令人不安。DNS 從來不只是技術協定，它是網路的權力樞紐；搜尋引擎從來不只是資訊工具，它是注意力的分配機器。當你把 agent 網路的信任根綁在 DNS 上，把發現權集中給 registry——你建立的不是一個開放市場，是一個有入口匝道的收費高速公路。開放規範是路面，匝道管理權是商業模式。