代理資源探索規格（ARD）發布：讓 AI 代理跨框架、跨組織相互找到彼此

Google Developers Blog · 2026-06-17

Google 於 2026 年 6 月 17 日在 Google Developers Blog 宣布 Agentic Resource Discovery（ARD） 規格的公開草案，並同日在 agenticresourcediscovery.org 正式上線。ARD 是一套開放協定，定義了 AI 代理如何在網際網路規模上「找到」其他工具、技能與代理，並在連線前驗證對端身分。目前版本為 v0.9 Draft，規格原始碼存放於 github.com/ards-project/ard-spec，授權為 Apache 2.0。

問題背景：代理生態系的「黃頁」缺口

當前的 AI 代理系統大多依賴靜態配置或人工整合來知道「哪裡有哪些工具」。一旦跨越組織邊界，就沒有標準化機制可以回答三個核心問題：所需能力存在於何處、應選擇哪一個、以及如何驗證連接的對象確實安全。ARD 的設計目標就是為這三個問題提供一致的格式與流程，填補現有碎片化 Registry 之間的互通空缺。

這份規格由跨廠商工作組共同制定，參與組織包括 Microsoft、Google、Hugging Face、GoDaddy、Cisco、Databricks、GitHub、NVIDIA、Salesforce、ServiceNow 與 Snowflake。跨越直接競爭對手的廣泛參與，反映出業界對統一探索層的迫切需求，而非只是某家廠商的私有方案。

兩個核心原語：Catalog 與 Registry

ARD 的架構建立在兩個基本概念上。首先是 Catalog（目錄）：組織在自己網域的知名路徑（well-known path）發布一份 ai-catalog.json 檔案，描述其對外提供的 AI 能力，包括 MCP 伺服器、代理、OpenAPI 工具乃至巢狀目錄。域名所有權本身即作為身分驗證的基礎——只有域名擁有者才能在該路徑發布文件，這與 HTTP /.well-known/ 慣例一脈相承。

其次是 Registry（登錄索引），角色類似於代理網路的搜尋引擎：爬取各組織的 Catalog、建立索引，並響應代理的探索請求。ARD 明確指出不會有單一集中式 Registry，而是多個獨立服務並存，各自有不同的信任模型與社群。這種聯邦式設計避免了單點故障與單一控制者問題。

// ai-catalog.json 示意結構（規格 v0.9 draft）
{
  "schemaVersion": "0.9",
  "publisher": "example.com",
  "resources": [
    {
      "type": "mcp-server",
      "name": "inventory-search",
      "endpoint": "https://api.example.com/mcp",
      "description": "Search product inventory in real time"
    },
    {
      "type": "agent-card",
      "name": "order-fulfillment-agent",
      "endpoint": "https://agents.example.com/order"
    }
  ]
}

目前規格的 Schema 以 CDDL、JSON Schema 與 OpenAPI 三種格式提供，存放於 spec/schemas/ 目錄，並附有符合性測試工具（conformance/）。adr/ 資料夾記錄架構決策，維持規格演進的可追溯性。

四階段運作流程

ARD 整個生命週期分為四個階段，且刻意只涵蓋執行前（pre-invocation）的部分——ARD 不是執行環境，找到資源之後，實際呼叫仍透過 MCP、A2A、Skills 或 REST API 等原生協定進行。

發布（Publish）：組織在域名上托管 ai-catalog.json。
探索（Discover）：代理向 Registry 送出自然語言或結構化意圖查詢，例如「找一個可以搜尋醫療記錄的工具」。
驗證（Verify）：透過域名錨定（domain-anchored）方式確認發布者身分與資源完整性。
連接（Connect）：代理使用資源本身的原生協定直接連線，ARD 不介入此層。

Google Cloud 已宣布透過 Gemini Enterprise Agent Platform 的 Agent Registry 服務落地實作 ARD，提供企業治理、政策執行與合規支援，包含 HIPAA 合規。這是 ARD 目前最具體的商業化落地路徑。

與現有協定的定位關係

ARD 刻意不重新發明執行協定，而是作為它們的「前一層」——ARD 讓代理知道要呼叫誰，MCP 與 A2A 負責實際呼叫。這種關注點分離降低了現有系統的遷移成本：無需修改工具本身，只需在域名上發布一份 Catalog 檔案。

規格目前處於 v0.9 Draft 階段，工作組歡迎社群回饋。規範性變更（涉及 spec/ 或 Schema 的修改）需先開 Issue 討論；非規範性貢獻（範例、工具、文件）可直接送出 Pull Request。

原始來源：Google Developers Blog — Announcing the Agentic Resource Discovery specification；agenticresourcediscovery.org；github.com/ards-project/ard-spec

A2A 協定一週年：24k Stars、多語言 SDK GA，代理間協作進入標準化軌道

Google Developers Blog · 2026-06-18

Google 於 2026 年 6 月 18 日發布 Agent-to-Agent（A2A）協定一週年回顧。github.com/google/A2A 目前累積 24,400 顆星、2,500 個 Fork，協定本體已於 2026 年 5 月 28 日發布 v1.0.1，並移交 Linux Foundation 以 Apache 2.0 授權開放維護。這一週年節點標誌著 A2A 從 Google 主導的提案，正式演進為中立社群治理的開放標準。

為什麼傳統 REST API 不夠用

整合多個 AI 代理的傳統做法是把每個代理包裝成無狀態的 REST API 端點，由主代理依序呼叫。這個架構有三個已知痛點：靜態契約無法傳達動態意圖、所有上下文必須集中在主代理有限的 context window 中（容易引發幻覺），以及跨組織邊界的敏感資料無法安全委派。A2A 正是針對這三個問題而設計的代理間通訊層。

A2A 的核心訊息傳遞格式為 JSON-RPC 2.0 over HTTP(S)。代理透過「Agent Card」宣告自己的能力、支援的互動模式與認證需求。Agent Card 是 A2A 生態系中的機器可讀名片，讓呼叫方在執行任何請求前就能知道對端支援哪些操作、如何驗證身分。

協定的四項架構設計原則

安全邊界（Secure Boundary）允許代理透過「黑箱交接」使用組織內部敏感資料，而不必對公開 LLM 或第三方揭露內部推論過程或專有工具。被委派的代理僅回傳結果，不暴露其執行細節。

零上下文污染（Zero Context Pollution）讓專業代理自行管理其依賴，不佔用主代理有限的 context window，降低長鏈推論中的幻覺風險。動態自主性（Dynamic Autonomy）則賦予接收端代理理解意圖、精煉計畫、主動詢問澄清問題的能力，行為更接近協作夥伴而非被動的 API 端點。最後，工作負載分散（Workload Distribution）讓不同團隊或廠商可以開發領域專家元件，由主代理透過標準協定組合使用，簡化整體應用設計。

協定在傳輸層支援三種互動模式：

同步請求/回應（synchronous request/response）
即時串流（Server-Sent Events, SSE）
非同步推送通知（async push notifications）

資料格式支援文字、檔案與結構化 JSON 的混合傳輸，並內建企業級身份驗證與可觀測性設計。

SDK 生態系的成熟度

A2A 在一年間建立起多語言 SDK 生態系。Python 與 Go SDK 已達 1.0 GA；Java SDK 處於 Beta；.NET 為 Preview；JavaScript/TypeScript 目前為 v0.3 穩定版，1.0 版正在開發中；Rust SDK 也在開發中，反映嵌入式與系統層整合的需求。

語言	狀態
Python	1.0 GA
Go	1.0 GA
Java	Beta
.NET	Preview
JavaScript / TypeScript	v0.3 穩定，1.0 開發中
Rust	開發中

協定至今已累計 11 個版本、576 個 main branch commit、44 個 open PR 與 242 個 open issue。移交 Linux Foundation 管理意味著治理已從 Google 主導轉為中立的開放社群模式，符合企業採購對中立治理的合規要求。

真實案例：FoldRun 的蛋白質結構預測

週年部落格文章以生命科學案例 FoldRun 具體說明 A2A 的實際效益。FoldRun 需要管理拍位元組（petabyte）規模的蛋白質結構預測工作流程，原先依賴脆弱的 API 串接在 AlphaFold 2、OpenFold 3 與 Boltz-2 之間切換。採用 A2A 之後，開發者只需將 FoldRun 代理登錄於相容環境，以自然語言委派任務，代理會依預測置信度自動選擇最合適的模型。BicycleTx 的 Richard Hughes 表示，代理式介面讓測試與工作流程整合「容易得多」。

A2A 目前已應用於代理式電商與自主支付、企業資料與即時串流、跨平台 IT 與 DevOps，以及需要安全邊界的電信與受監管產業場景。這些場景的共同特徵是：任務邊界清晰、資料敏感性高、需要動態協調——正是靜態 REST API 最力不從心之處，也是 A2A 設計時的核心使用目標。

原始來源：Google Developers Blog — How A2A is Building a World of Collaborative Agents；github.com/google/A2A

End of article