谷歌聯(lián)手微軟等發(fā)布ARD規(guī)范：企業(yè)需要的不僅是“找到一個能用的工具”

你以為讓AI Agent自己找工具用，最難的環(huán)節(jié)是“找不到”？谷歌云杰出工程師一句話就揭了老底：找一個能用的工具很簡單，找一個敢放心用的，才是真正卡脖子的事。在工具爆炸、API泛濫的年代，Agent缺的從來不是選項，而是一套能在連接前就確認“你是誰”“你到底能干什么”“我憑什么信你”的機制。7月23日，谷歌聯(lián)合微軟、GitHub、Hugging Face、英偉達等十余家企業(yè)，把這個缺位多年的環(huán)節(jié)補上了一塊拼圖——Agentic Resource Discovery（ARD）資源發(fā)現(xiàn)規(guī)范。

ARD要解決的問題，說穿了就一句話：Agent如何跨組織、跨平臺，像呼吸一樣自然地把可用的工具發(fā)現(xiàn)出來，并同時建立信任。它不被設(shè)計成另一個大一統(tǒng)標準，也不試圖把Model Context Protocol（MCP）這類執(zhí)行協(xié)議踢下牌桌。ARD盯的是MCP覆蓋不到的前置盲區(qū)——在調(diào)用一個工具之前，Agent先得知道它存在，而且知道它能信。這個看似順理成章的需求，在企業(yè)混合云、多供應(yīng)商、多身份域的實際環(huán)境中，此前一直靠各種私有集成和靜態(tài)配置列表硬撐，運維工程師的頭發(fā)就是這么掉光的。

ARD打出的明牌是兩個核心概念：Catalog（資源目錄）和Registry（注冊中心）。組織可以在自己域名下掛出一個機器可讀的ai-catalog.json文件，把自己能提供的工具、API、Skill、Agent Endpoint統(tǒng)統(tǒng)列出來。Registry則像是一個按需聚合這些目錄的發(fā)現(xiàn)中樞，Agent可以用任務(wù)意圖去搜索能力，而不必事先綁定某個特定集成方式或死記硬背一長串端點列表。關(guān)鍵點在于，ARD并不綁架執(zhí)行層——目錄里列出的能力，仍可繼續(xù)用MCP、OpenAPI等現(xiàn)有協(xié)議去實際調(diào)用。它干的活兒，更像是在工具和應(yīng)用之間架起一張實時更新的“黃頁”，并且自帶驗明真身的機制。

安全設(shè)計沒有留到事后補課。ARD的信任模型從域名歸屬入手，Agent在建立連接前必須先完成資源真實性驗證，確保自己發(fā)現(xiàn)的服務(wù)不是李鬼。在Reddit社區(qū)的討論里，不少開發(fā)者認為這種基于域名的歸屬校驗，比疊床架屋的令牌體系更落地，也更符合去中心化Agent互訪的初衷。但潑冷水的聲音同樣尖銳：無論發(fā)現(xiàn)機制做得多么絲滑，最終決定Agent體驗上限的，仍然是工具本身的質(zhì)量，以及各家廠商會不會借著入口優(yōu)勢封死訪問和計費的流量黑洞。

ARD的聯(lián)合制定名單幾乎搬空了半個科技圈：微軟、GitHub、Hugging Face、Cisco、Databricks、GoDaddy、英偉達、Salesforce、ServiceNow、Snowflake。它們不是來站臺的。GitHub已經(jīng)用ARD在Copilot里跑了Agent Finder，Hugging Face的Discover Tool同樣基于ARD實現(xiàn)了運行時能力發(fā)現(xiàn)——兩個早期實現(xiàn)直接把規(guī)范從紙面拖進了代碼倉庫。微軟AI首席工程師Jennifer Marsman的表態(tài)更值得琢磨：ARD的目標絕不是建一個容納一切資源的全球目錄。未來會有一堆資源發(fā)現(xiàn)服務(wù)，各自按索引范圍、服務(wù)受眾和排序策略干活，ARD只負責(zé)讓AI客戶端能認出這些能力，至于身份認證、授權(quán)、治理和組織信任決策，它一件都不越俎代庖。

說白一點，ARD是要把“發(fā)現(xiàn)工具”這個動作從各家私有的黑盒里拎出來，變成一套開放、可驗證、聯(lián)邦化的公共對話規(guī)則。規(guī)范本身已經(jīng)附帶了數(shù)據(jù)Schema、信任驗證指南以及互操作實現(xiàn)參考，企業(yè)現(xiàn)在就能拿到倉庫去試驗發(fā)布能力目錄。生態(tài)能不能真正轉(zhuǎn)起來，取決于兩點：一是開發(fā)者愿不愿意把能力清單公開掛到域名下接受Agent“檢閱”；二是工具提供方會不會在發(fā)現(xiàn)這一層就埋下后續(xù)鎖定的地雷——ARD搭好了橋，但管不了誰會在橋頭收過路費。