Google 在 6 月 17 日宣布 Agentic Resource Discovery，隔天又用一篇 A2A 週年文章把 agent-to-agent 協作拉回聚光燈下。這兩件事看起來都像開發者規格更新：一個談工具、技能與代理的搜尋和驗證；一個談 agents 如何彼此交接任務。但放在 2026 年企業 AI 的脈絡裡，它們其實指向同一個問題：當 agents 不再只是單機助理，而是會找工具、找資料、找其他 agents 一起做事，整個生態需要自己的搜尋層與信任層。
過去一年，agent 工具鏈的主角多半是「連線」。MCP 讓模型更標準地接工具和資料源，A2A 讓不同 agents 能互相交接任務，企業平台則把這些能力包進內部工作流。可是連線之後，下一個問題很快出現：agent 要怎麼知道該找哪個工具？哪個 agent 才是公司允許使用的？同名或相似能力背後的發布者是誰？如果每一次都靠工程師把清單寫進設定檔，agent 生態就會卡在手動安裝、手動維護、手動治理的階段。
ARD 想補的就是這一層。Google 的描述很清楚：組織可以在自己的網域下發布 catalog，列出可被 agents 使用的能力；registry 則像搜尋引擎一樣索引這些 catalogs，讓 agent 以自然語言意圖找到合適資源，並帶回可驗證的信任 metadata。重點不是讓 agent 直接把所有東西都抓進上下文，而是把「發現」和「執行」分開：先找到能力、驗證發布者，再交給 MCP、A2A、OpenAPI 或其他原生協定實際連線。
這個設計聽起來像 agent 世界的索引層，也有一點像 DNS、搜尋引擎和企業軟體目錄的混合體。Google 舉的例子是營運 agent 處理生產事故時，可能要查 observability 系統、工程文件、部署紀錄、客服票單，甚至請教專門排錯的 agent。今天這些能力常散落在不同團隊、不同 SaaS、不同 registry 裡；如果沒有共同發現方式，agent 要不是找不到，要不就是把太多工具描述塞進上下文，最後讓模型在模糊清單裡猜。
GitHub 和 Hugging Face 的動作讓 ARD 不只是 Google 自說自話。GitHub 在 6 月 17 日推出 Copilot agent finder，明確說它實作 ARD，讓 Copilot 可以從公開或企業自有 registry 找到合適的 MCP servers、skills、canvases、agents 與 tools，但不會自動安裝或偷偷連線，企業仍可透過管理設定限制可發現範圍。Hugging Face 則把 ARD 說成 MCP、Skills、A2A 前面的 discovery layer，並用 Discover Tool 讓 agents 搜尋 Hub 上的 Spaces、skills 與 MCP servers。這兩個例子一個偏企業開發工作流，一個偏開源模型與工具生態，剛好說明 ARD 想跨過單一平台邊界。
Google 隔天談 A2A，也讓這件事更完整。A2A 解的是 agents 之間如何安全交接任務、保留各自內部資料與流程、避免主 agent 的上下文被塞滿；ARD 解的是 agent 在交接或調用之前，怎麼找到並驗證合適對象。前者像通訊協定，後者像發現與信任目錄。兩者疊起來，才比較接近企業真正需要的 agent 網路：不是每個 agent 都知道所有工具，而是需要時能找到、能確認、能交接，並且在政策範圍內行動。
這也是 ARD 最值得關注的產業訊號。企業部署 agents 的瓶頸正在從「能不能做出一個 agent」變成「能不能管理一群 agents」。一家公司可能同時有客服 agent、資料分析 agent、工程排錯 agent、法務檢索 agent、供應商軟體內建 agent，還有員工自己串出的自動化工具。如果這些能力都靠人工清單維護，治理成本會隨著 agents 數量快速膨脹；如果完全放任搜尋，資安風險又會跟著擴大。ARD 把 catalog、registry、publisher identity、verification metadata 和 policy 帶進同一個語彙裡，正是在回答這個治理難題。
不過，搜尋層也會帶來新的攻擊面。agent 找得到更多能力，不代表它應該使用更多能力；registry 排名靠前，也不代表能力一定安全；發布者有網域身份，也不代表每次輸入、輸出和工具呼叫都符合公司政策。真正關鍵的是驗證與治理要不要成為預設路徑，而不是文件裡的選配功能。Google 提到 Agent Registry 會在 Gemini Enterprise Agent Platform 裡支援 globally unique namespaced URNs、egress policies、tool pinning 和 trust manifest；GitHub 也強調企業可以定義哪些資源可被發現。這些細節比「讓 agent 搜尋」本身更重要，因為 discovery without control 只會讓供應鏈風險跑得更快。
從競爭角度看，ARD 也透露出一場標準之爭正在形成。OpenAI、Anthropic、Google、Microsoft、GitHub、Hugging Face、Salesforce、ServiceNow、Snowflake、Nvidia、Cisco 等企業都想站在 agent 工作流的關鍵位置。誰掌握模型，誰掌握工具目錄，誰掌握企業 registry，誰掌握 identity 和 policy，最後都會影響 agent 生態的入口。Google 把 ARD 做成開放規格，並把 A2A 持續推向協作標準，策略上是在避免 agent 世界被單一 app store 或單一模型平台鎖死。
但開放規格本身不保證成功。MCP 已經因為「模型接工具」的需求清楚而快速普及；A2A 和 ARD 面對的問題更偏多方協作與企業治理，採用速度可能比較慢，也更依賴大型平台先把體驗做好。開發者不會只因為規格優雅就重寫流程，企業也不會只因為 federated registry 聽起來合理就開放內部能力。真正的測試會在接下來幾個月：GitHub agent finder、Hugging Face Discover、Google Agent Registry 以及其他平台的實作，能不能讓 agents 在不增加資安負擔的前提下，真的少一點手動接線。
如果說 2024 到 2025 年的 agent 熱潮是在回答「模型能不能替人做事」，那 2026 年的問題正在變成「這些替人做事的軟體如何彼此找到、互相信任、被公司管理」。ARD 的重要性就在這裡。它不是最炫的模型能力，也不是最容易展示的產品功能；它更像代理網路長大後必須補上的基礎設施。當 agents 從單一聊天框走向跨平台協作，搜尋與驗證會變成和推理能力一樣基礎的需求。
參考來源
- https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/
- https://developers.googleblog.com/how-a2a-is-building-a-world-of-collaborative-agents/
- https://github.blog/changelog/2026-06-17-agent-finder-for-github-copilot-now-available/
- https://huggingface.co/blog/agentic-resource-discovery-launch
- https://www.helpnetsecurity.com/2026/06/18/google-agentic-resource-discovery/