代理找不到自己的工具 — 執行期工具發現層

問題是什麼

如今AI代理取得工具的方式是「先安裝、後使用」。開發者把MCP伺服器URL手動寫進設定檔，代理才能用上那個工具。這種方式在規模變大後就垮了，因為代理沒辦法在工作途中動態發現一個陌生工具。常見的變通做法——把所有工具描述塞進LLM上下文視窗——也有明顯的上限。token預算卡住它，工具一旦超過數十個，模型就分不清該選哪個。結果代理的能力被困在開發者事先想像並接好的那批工具裡。使用者說「把這份PDF放進會計系統」，如果那個會計連接器沒有被預先安裝，代理根本不知道它存在。換成人類只需搜尋就能找到，代理卻做不到。工具本身正在爆炸式增長——上千個MCP伺服器、AI技能和ML應用——可偏偏缺少那一層，讓代理在執行期從中找到並選出合適的那一個。台積電與聯發科生態裡的代理平台都在堆工具，卻沒人把這一層做扎實。

為什麼是現在

催生時機的是標準的出現。Hugging Face聯手微軟、Google、GoDaddy等發布了ARD（代理資源發現）草案規範。模型很簡單：你在網域的知名路徑上發布ai-catalog.json，登錄表對其建立索引，代理用自然語言意圖搜尋，接著驗證發布者並透過MCP、A2A或一般API連接。這就是給代理用的DNS加電話簿。規範定義了兩套機制——靜態清單（ai-catalog.json）與動態登錄表API（自然語言POST /search）。標準落地意味著一塊競爭的場地剛剛打開，正如網域名稱系統標準化之後才催生了DNS服務商與註冊商。眼下規範還處於草案階段，而真正要緊的部分——一個好用到能上手的登錄表，具備過硬的索引品質、排序與發布者驗證——還是空的。標準本身並不決定誰搜得更好。對同一個意圖把哪個工具排在第一，那份排序品質才是產品的競爭力，而這個位置還沒有主人。

怎麼構建

打造一個實作ARD規範的工具發現登錄表。核心有三點。第一，爬取與索引——把散落在各網域的ai-catalog.json收攏起來，把每個工具的描述、代表性查詢和標籤做成嵌入建立索引。第二，意圖排序——當代理用自然語言搜尋「我想做X」，依信心度回傳合適的工具。不是關鍵字比對：把發布者身分、合規證明和真實使用訊號加權進去以提高精度。第三，驗證閘門——不要把任何工具都暴露出去，驗證發布者、過濾掉惡意或冒充的工具，讓代理安全連接。收入從兩側收取：向工具發布者收（曝光與優先索引的B2B費用），向代理開發者收（按呼叫計費的搜尋API）。別想著第一天就涵蓋所有工具；挑一個垂直領域——比如金融科技連接器或資料管線工具——把它的索引品質做到遠超他人，在那裡坐穩標準登錄表的位置。像Hugging Face的Discover Tool這樣的參考實作已經存在，所以差異點在於你能多準、多安全地找到那個合適的工具。