Agentic Resource Discovery 智慧代理資源發現：ai-catalog.json、工具目錄與手機代理授權邊界
解釋 ARD 與 ai-catalog.json 如何讓 AI 代理發現工具、技能與代理，並說明驗證、原生協定連線與手機代理授權為何必須分開處理。
- Agentic Resource Discovery 智慧代理資源發現是一套用來發布、搜尋與驗證工具、技能和代理的開放規範，核心是讓能力可以被發現，而不是直接被執行。
- ai-catalog.json 工具目錄可以描述 MCP、A2A、OpenAPI 或巢狀目錄等資源，但目錄命中只代表找到候選能力，還需要後續驗證與連線檢查。
- 發布者驗證能提高來源可信度，卻不等於工具行為安全、Android 權限已授予，或使用者已批准具體手機動作。
- 在 FoneClaw 的手機代理架構中，模型負責理解與規劃，FoneClaw 透過受治理的 Android 工具、權限引導、風險標籤、核准控制與可見結果來執行支援動作。
目錄
ARD 解決的是代理資源如何被找到
Agentic Resource Discovery 智慧代理資源發現，簡稱 ARD，回答的是一個很實際的問題：當 AI 代理需要外部工具、技能或另一個代理時，它要如何知道誰提供了能力、能力在哪裡、該用什麼介面連線，以及能不能先驗證發布者。Google 在 2026 年 6 月 17 日的ARD 規範公告中，將它描述為跨網路發布、發現與驗證工具、技能和代理的開放規範。
沒有共同發現機制時，代理系統往往依賴私有清單、手動設定、單一平台市集，或由開發者在程式中硬寫端點。這些方式可以在封閉產品內運作，卻很難支撐跨組織、跨協定、跨代理的能力探索。ARD 的思路是讓組織在自己的網域下發布目錄，讓登錄服務索引目錄，也讓已知合作方可以直接抓取指定網域的目錄。
ai-catalog.json 工具目錄是這個流程裡最容易被搜尋到的詞。它可以把某個網域提供的代理資源寫成結構化資料，例如資源名稱、描述、能力類型、可用協定、驗證資訊與下一步連線位置。重點在於：目錄讓能力可被找到，並不讓能力自動取得使用者權限。對手機代理來說，這個區分尤其重要，因為找到一個工具和允許它在 Android 手機上採取動作，是兩個不同決策。
目錄與登錄服務如何發布和搜尋能力
理解 ARD 的流程，可以先把「目錄」和「登錄服務」分開。目錄由資源發布者放在自己的網域下，像是企業、工具供應商或代理服務的公開能力說明。登錄服務則負責爬取、索引與查詢這些目錄，讓代理可以用自然語言意圖或結構化條件找到候選資源。根據公開的ARD 規範與儲存庫，相關規範、結構描述、信任架構與參考工作以公開方式演進，並採 Apache-2.0 授權。
一個典型流程有四步。第一，發布者在自己控制的網域下放出 ai-catalog.json 或相容目錄，描述可用工具、技能、代理或巢狀目錄。第二，代理客戶端可以查詢登錄服務，例如「找能處理發票擷取的工具」；也可以在已知合作方網域直接抓取目錄。第三，系統檢查目錄中的發布者中繼資料與可驗證資訊。第四，客戶端依目錄中宣告的原生介面，改用 MCP、A2A、OpenAPI 或其他合約連線。
這裡有一個常見誤解：登錄服務不是執行代理，也不是授權代理。它比較像能力索引與解析層。它可以回傳匹配度、發布者資訊、能力描述、可用協定與驗證資料；真正的連線仍會回到被宣告的原生介面。若目錄指出某個能力是 MCP server，後續就要用 MCP 的方式檢查工具與呼叫；若目錄指出是 OpenAPI 工具，就要驗證 schema、認證方式與端點行為。
| 階段 | 輸入 | 輸出 | 還沒完成的事 |
|---|---|---|---|
| 發布 | 供應商網域與能力描述 | 目錄或巢狀目錄 | 尚未代表使用者授權 |
| 搜尋 | 代理意圖或已知網域 | 候選資源清單 | 尚未證明端點可用 |
| 驗證 | 發布者與目錄中繼資料 | 來源與完整性線索 | 尚未證明行為安全 |
| 連線 | 宣告的原生協定 | 可測試的工具介面 | 尚未批准具體動作 |
發布者驗證能證明什麼、不能證明什麼
可信代理工具目錄的第一個價值，是讓代理在連線前更清楚「這個資源是誰發布的」。ARD 公告提到，正式的發現流程可以包含可加密驗證的發布者中繼資料，讓客戶端在直接透過原生協定連線前先確認來源。這對防止假冒目錄、錯誤端點或供應鏈混淆很有幫助。
但發布者驗證不是萬能安全章。它可以提高「來源是不是它聲稱的那個發布者」的可信度，卻不能直接回答「這個工具是否適合我的任務」、「這次呼叫是否會造成外部效果」、「使用者是否允許這個代理讀取手機資料」或「目標帳號、收件人、金額、位置是否正確」。身份正確，仍可能有設定錯誤、能力過寬、文件過期、端點失效或業務風險。
因此，驗證應該被放在決策鏈中的一段，而不是終點。對企業代理來說，它能支援供應商信任與目錄完整性檢查；對手機代理來說，它還要接上本機政策、工具啟用狀態、Android 權限、使用者確認與活動紀錄。若團隊正在設計技能安裝、更新與權限檢查，可延伸閱讀AI Agent 技能安全：為什麼手機 Agent 不能只靠安裝前掃描，那篇把技能生命週期與手機權限檢查拆得更細。
ARD 如何交給 MCP、A2A、OpenAPI 與 App 合約
ARD 的位置不是取代 MCP、A2A 或 OpenAPI，而是幫代理找到這些原生介面的入口。目錄可以宣告某個資源是 MCP server、A2A agent、OpenAPI tool，或指向另一個巢狀 catalog。被發現之後，代理仍要依照該協定的規則連線、驗證參數、處理錯誤，並決定是否把它納入可執行流程。
這種設計很像「先找到門牌，再用正確鑰匙開門」。ARD 負責找到門牌、辨認發布者與整理能力描述；MCP、A2A、OpenAPI 或 App 自己的可呼叫合約，負責說明實際能呼叫什麼、參數怎麼傳、結果怎麼回來、錯誤如何處理。若某個 Android App 沒有提供穩定可呼叫介面，目錄本身不會把它變成可自動操作的 App。
手機端尤其需要這個分工。App 可能透過 Intent、分享面板、深層連結、系統權限、無障礙互動或自家 SDK 提供不同程度的可呼叫能力。若讀者想理解「被發現」之後，App 還要怎麼變成可被機器呼叫的手機任務，可以接著看App Intents 可被機器呼叫的 App：AI Agent 怎麼真正執行手機任務；本篇只聚焦在 ARD 如何把資源帶到正確連線入口。
在手機上，發現不等於授權
ai-catalog.json 工具目錄對手機代理是否安全，答案取決於後面的授權設計。目錄可以讓代理知道某個工具存在，也可以提供發布者與能力描述；但手機上的權限涉及使用者、裝置、App 狀態與具體行為。Android 的執行階段權限指引建議應在功能需要時才於情境中請求權限，並由應用程式負責處理使用者拒絕權限後的流程。
這表示「可發現」不能直接推出「可執行」。例如目錄發現一個能寄信的工具，代理仍要確認本機是否啟用該工具、使用者是否允許讀取或傳送相關內容、收件人是否正確、郵件是否已預覽、送出是否需要核准，以及失敗後是否能停止或回復。Android 權限本身也不是商業授權：允許位置權限，不代表允許代理替你預訂車票；允許讀取某些資料，不代表允許把資料傳給外部服務。
| 控制點 | 回答的問題 | 手機代理仍需檢查 |
|---|---|---|
| 發布者身份 | 資源是否來自聲稱的發布者 | 是否符合使用者任務與政策 |
| 目錄完整性 | 目錄是否被竄改或過期 | 端點與 schema 是否仍可用 |
| 端點相容性 | 原生協定是否能連線 | 參數、錯誤、速率與認證是否可控 |
| 工具啟用 | 本機是否允許使用這項工具 | 是否需要按工具或風險等級核准 |
| Android 權限 | App 是否可取得所需裝置能力 | 拒絕權限時如何引導與回退 |
| 動作核准 | 這次具體行為是否被使用者接受 | 目標、內容、外部效果是否可見 |
| 撤銷與紀錄 | 事後能否查詢與停止 | 如何停用工具、撤銷權限或移除插件 |
把這些點拆開，並不是要讓流程變慢，而是讓不同風險由正確機制處理。更完整的身分、權限與活動紀錄架構，可參考AI Agent 身分、權限與稽核軌跡：手機 Agent 真正需要的安全棧；ARD 只解決其中的發現與可驗證中繼資料問題。
代理資源連線前與執行前檢查清單
如果團隊準備讓手機代理接觸被發現的外部資源，檢查順序應該從低風險開始，而不是一找到目錄就打開全部能力。以下清單適合用在 pre-connect 與 pre-execution 兩個時點：前者決定是否連線，後者決定是否讓某次手機動作發生。
- 確認發布者：檢查目錄是否來自預期網域，驗證中繼資料是否可用，並記錄版本或擷取時間。
- 檢查目錄新鮮度：觀察目錄是否過期、是否指向失效端點、是否有巢狀目錄或外部跳轉。
- 驗證原生介面：依 MCP、A2A、OpenAPI 或 App 合約測試 schema、認證、錯誤回應與最小可用呼叫。
- 比對本機政策：確認工具是否已啟用、風險等級為何、是否屬於可由手機代理處理的支援範圍。
- 檢查 Android 權限：只在任務需要時請求必要權限，並準備被拒絕時的可理解回復。
- 驗證動作目標：在傳送、分享、修改、刪除、定位或裝置控制前，確認目標、內容、帳號與外部效果。
- 取得適當核准：依風險採用自動、依政策或人工確認；低風險讀取與高影響動作不應使用同一規則。
- 呈現結果與留紀錄：讓使用者看見結果、錯誤與下一步，並保留可追溯的工具與權限狀態。
- 準備撤銷：提供停用工具、收回權限、移除插件、停止任務或改走手動流程的路徑。
實測時，先用低風險讀取或查詢類任務確認發現、驗證與連線是否穩定，再測需要核准的外部效果。這能把「目錄找得到」和「手機動作可靠可控」分開觀察，也能避免在端點、權限或目標仍不明確時直接進入高風險流程。
FoneClaw 如何分開目錄可見性與手機權限
在 FoneClaw 的產品設計中，目錄可見性和手機權限是兩件事。FoneClaw 是 Android 手機代理執行環境；使用者設定的相容模型負責理解、推理與規劃，FoneClaw 則呼叫受治理的支援 Android 工具。依 2026 年 8 月 1 日的公開快照，FoneClaw 擁有 100+ 內建工具，涵蓋螢幕、裝置、通訊、位置、工作流、技能與插件等表面，工具條目帶有風險與核准標籤。
FoneClaw 0.1.0 的版本發布資料顯示，這個版本加入了按工具搜尋、啟用控制、核准覆寫、權限復原與更安全的工具合約，也完成了可信插件延續流程。公開的工具目錄快照則讓使用者與開發者可以看到內建工具分類、風險與核准訊號。這些設計的目的，是讓模型計畫進入手機動作前有清楚的工具範圍。
當模型在 FoneClaw 內規劃任務時，它可以提出下一步，例如讀取可見畫面、開啟 App、準備訊息、執行工作流或呼叫已啟用工具。FoneClaw 會依工具政策、啟用狀態、權限需求、風險標籤與使用者核准來處理支援動作。權限會在需要時被引導，插件安裝也從可見提案開始；這讓使用者知道能力從哪裡來、會做什麼、能在哪裡停下。
這也是為什麼 ARD 的觀念對手機代理很有價值，即使 FoneClaw 在本文中不把自己描述成 ARD 實作。發現層可以改善能力可見性；FoneClaw 的重點則是把已知、已啟用、可治理的工具放進 Android 執行流程。想完整理解 FoneClaw 如何把使用者意圖轉成支援的手機動作，可延伸閱讀手機 AI Agent 控制是什麼？Android 手機自動化代理的能力、邊界與安全檢查。
導入代理資源登錄服務前要測什麼
團隊評估代理資源登錄服務時，不應只看搜尋結果多不多。真正該測的是：它是否能找到正確資源、是否會回傳過期或錯誤目錄、發布者驗證失敗時是否能停下、原生協定連線是否可被測試、本機政策拒絕時是否清楚，以及手機端失敗後是否能恢復到可理解狀態。
| 測試項目 | 可觀察指標 | 採用判斷 |
|---|---|---|
| 意圖搜尋品質 | 錯配、漏配、排序原因 | 能否讓使用者理解為何選中 |
| 目錄新鮮度 | 更新時間、失效端點、巢狀跳轉 | 是否有過期處理與重試策略 |
| 驗證失敗 | 簽章、網域或中繼資料錯誤 | 是否停止連線並呈現原因 |
| 政策拒絕 | 工具停用、風險過高、權限不足 | 是否提供安全替代流程 |
| 手機復原 | 權限被拒、App 狀態變更、動作失敗 | 是否能保留可見結果與撤銷路徑 |
成熟的導入方式，是讓發現與授權各自可觀察。登錄服務要說明為什麼找到某個能力；執行環境要說明為什麼允許或拒絕某次動作。當這兩件事各自清楚，ARD、ai-catalog.json 工具目錄與手機代理工具治理才能形成可靠路徑：先找到可信候選資源，再用本機政策、Android 權限與使用者核准決定能不能真正執行。