# 策展 · X (Twitter) 🔥🔥🔥

> 作者：Google Cloud Tech (@GoogleCloudTech) · 平台：X (Twitter) · 日期：2026-04-24

> 原始來源：https://x.com/googlecloudtech/status/2047567704807346675

## 中文摘要

# A2A 與 MCP 如何協作：構建多 Agent 系統的五種整合模式

沒有任何組織會從零開始構建它所需的所有 Agent。真正的價值在於發現由不同團隊、使用不同程式語言、跨越不同組織所構建的 Agent。這正是 A2A 與 MCP 所實現的目標：A2A 用於 Agent 與 Agent 之間的通訊，MCP 則用於 Agent 與工具之間的通訊。

作者：@addyosmani 與 @Saboo_Shubham_

在 Cloud Next 26 大會上，我們發布了使這種整合在企業規模下變得切實可行的基礎設施。以下是使用這兩種協定構建多 Agent 系統的五種整合模式。

## 模式 1：Agent 卡片搜尋 (Agent Card Discovery)

在你的 Agent 委派任務給另一個 Agent 之前，它必須先知道該 Agent 的存在、它能做什麼，以及如何與它通訊。

A2A 透過「Agent 卡片」(Agent Cards) 解決了這個問題。每個相容 A2A 的 Agent 都會在一個公開的 URL 發布一份 JSON 文件，描述其功能、驗證要求與速率限制。你可以將其視為一種 OpenAPI 規格，但它是專為 Agent 與 Agent 之間的互動而設計，而非客戶端與伺服器之間的通訊。

在 Agent Development Kit (ADK) 中，將你的 Agent 暴露為 A2A 伺服器只需簡單的設定。它會自動根據你的 Agent 定義生成 Agent 卡片。透過 `RemoteA2aAgent` 元件，呼叫遠端 Agent 也同樣簡單，該元件會處理驗證、資料序列化、錯誤處理與結果串流。從協調者的角度來看，由其他團隊使用不同程式語言構建的遠端 Agent，用起來就像本地 Agent 一樣。

Agent Registry (Agent 註冊中心) 進一步強化了這一點。當你在中央註冊中心註冊 Agent 時，組織內的其他 Agent 無需知道特定 URL 即可發現它們。註冊中心成為了你 Agent 生態系統的服務網格 (Service Mesh)：一個用來尋找可用功能、維護者以及存取方式的單一入口。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777066099030-iaHGppz3KaAAEalCmjpg.jpg)

## 模式 2：委派專業化 (Delegated Specialization)

最常見的整合模式是委派：當你的 Agent 遇到超出其專業領域的任務時，會將其交給專家處理。

這種模式建立在「協調者-調度者」(Coordinator-Dispatcher) 架構之上，但將其擴展到了團隊與框架的邊界之外。專家 Agent 不需要使用 ADK 構建，不需要使用相同的程式語言編寫，也不需要由同一個團隊維護。它只需要支援 A2A 協定即可。

考慮一個跨越五個團隊與四種程式語言的客戶入職工作流程。協調者（你的團隊，使用 Python）將身分驗證委派給安全團隊的 Go Agent，將信用評估委派給風險團隊的 Java Agent，將帳戶配置委派給平台團隊的 Go Agent，將合規文件處理委派給法務團隊的 Python Agent，並將歡迎訊息發送委派給行銷團隊的 TypeScript Agent。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777066099153-iaHGpqR5hbQAAjIMAjpg.jpg)

每個專家 Agent 都由不同的團隊擁有、獨立維護，並按照各自的時程部署。協調者不需要知道也不關心內部的實作細節。它只需要知道它們的 Agent 卡片功能與 A2A 協定。

當安全團隊更新其驗證 Agent 以支援新的文件類型時，協調者無需進行任何變更。當風險團隊改進其信用模型時，協調者會自動獲得更好的評估結果。每個團隊都能獨立迭代，整個系統也會隨之提升。這與微服務成功的原則相同：獨立部署、獨立擴展、獨立演進。A2A 提供了讓這一切在 Agent 之間運作的服務合約。

## 模式 3：工具橋接 (Tool Bridge - Model Context Protocol)

如果說 A2A 是連接 Agent 與 Agent，那麼 MCP 就是連接 Agent 與工具及資料。工具橋接模式使用 MCP，讓你的 Agent 能夠安全地存取資料來源、API 與企業系統，而無需為每個系統構建自訂連接器。

沒有 MCP 時，每個資料連接都需要各自的自訂整合程式碼。你的 Agent 需要一個 Python 連接器來連接某個 REST API，另一個連接器連接資料庫，再另一個連接舊有系統。三個資料來源意味著要構建、測試與維護三個連接器。MCP 透過提供一個任何工具都能實作的單一協定消除了這種複雜性。

ADK 整合生態系統提供了超過 60 種開箱即用的工具與整合，例如 GitHub、Notion、Hugging Face、AgentOps 與 Stripe。這些工具讓你的 Agent 能透過簡單的設定立即連接，無需進行冗長的自訂開發。

特別是在資料庫連接方面，MCP Toolbox for Databases 透過單一 MCP 介面將超過 30 種不同的資料來源連接到你的 Agent。而 Apigee API Hub 更進一步：如果你在 Apigee 中有現成的 REST API 文件，你可以自動將它們轉換為 Agent 可存取的工具。你的 Agent 透過管理現有 API 流量的同一個治理層來存取資料。速率限制、驗證、日誌記錄與存取控制都由你現有的基礎設施來處理。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777066098907-diaHGpqclbboAA1cHjpg.jpg)

ADK 原生支援 MCP。當你將一個 MCP 工具加入 Agent 時，Agent 會發現該工具的功能、以結構化參數呼叫它，並接收結構化的回應。從 Agent 的角度來看，透過 Stripe 的 MCP 工具與透過 BigQuery 的 MCP 工具看起來是一樣的。協定就是介面，後端則是可替換的。

## 模式 4：跨組織聯合 (Cross-Organization Federation)

最具野心的模式涉及來自不同組織的 Agent 在共享任務上進行協作。這正是 A2A 開放協定設計變得至關重要的地方，因為你無法假設其他組織使用相同的框架、程式語言或雲端供應商。

Gemini Enterprise 中的 Agent Gallery 使這一切變得切實可行。超過 100 個來自 Adobe、ServiceNow、Workday、Salesforce 等合作夥伴的驗證 Agent 可直接在平台內使用。每個合作夥伴 Agent 都經過 Google Cloud 的安全性與互通性驗證。

關鍵在於每個組織都維持自己的治理權。你的 Agent Gateway 政策控制了你的 Agent 可以與合作夥伴 Agent 共享哪些資料、根據合作夥伴的回應可以採取哪些行動，以及可以請求哪些資訊。合作夥伴 Agent 在其自身的安全模型下運作，並經過 Google Cloud 的整合要求驗證。

考慮一個多 Agent 支付工作流程，你的 Agent 需要與外部商家 Agent 及金融服務 Agent 協調。每一方在透過 A2A 協作處理共享交易的同時，都維持各自的治理。你的 Agent 不需要了解商家系統內部的運作方式。它透過 A2A 協定進行通訊，雙方各自獨立執行其安全邊界。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777066099044-iaHGpqmRvbMAAzzv0jpg.jpg)

同樣的原則適用於任何跨組織整合。你的 Agent 不需要了解 Salesforce 的資料模型或 ServiceNow 的內部架構。它將任務委派給 Agent Gallery 中的合作夥伴 Agent，該 Agent 由合作夥伴團隊維護、經 Google Cloud 驗證，並受你的 Agent Gateway 政策管轄。當合作夥伴更新其平台時，他們的 Agent 也會隨之更新。你的系統無需進行任何變更即可獲益。

## 模式 5：環境事件網格 (Ambient Event Mesh)

最後一種模式將 A2A 與事件驅動架構結合，建立一個環境 Agent 網格，這些 Agent 在背景持續對事件做出反應，而無需等待使用者請求。

Gemini Enterprise Agent Platform 中的批次與事件驅動 Agent 可直接連接 BigQuery 資料表與 Pub/Sub 串流。當你將其與 A2A 結合時，你建立了一個監聽事件、處理事件並視需要委派給專家 Agent 的 Agent 網路——所有這些都在背景持續運作。

網格中的每個 Agent 都獨立運作。當事件到達時，接收的 Agent 會處理它，並決定是在本地處理、透過 A2A 委派給專家，還是透過 Mission Control 升級給人類處理。該網格具有自我組織能力——加入一個新的專家 Agent（例如詐欺偵測專家）只需要在 Agent Registry 中註冊它，並更新相關環境 Agent 中的路由邏輯即可。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777066099036-iaHGpqvSbbMAACtZsjpg.jpg)

對於具有高事件量的組織來說，這種模式特別強大。一個每天處理數百萬次上傳的內容平台、一家處理數百萬筆交易的金融機構、一個處理數百萬次客戶互動的電子商務平台——都可以使用環境 Agent 網格來處理需要智慧處理的長尾事件。

治理在這裡至關重要。網格中的每個 Agent 都透過 Agent Identity 擁有自己的身分。每個工具存取都由 Agent Gateway 管理。每次互動都透過 Agent Observability 進行追蹤。這個網格不是一個黑盒子，而是一個完全可觀察、受治理的專業 Agent 網路。

## 選擇正確的模式

在構建多 Agent 系統時，請根據 Agent 之間的關係選擇你的整合模式：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777066099033-iaHGpq6c7bMAAEVFXjpg.jpg)

立即開始

互通性技術堆疊現已可用：

- A2A 協定：ADK 已支援 Python、TypeScript、Go 與 Java

- MCP：ADK 原生支援，GCP 資料庫提供託管支援

- Agent Gallery：Gemini Enterprise 中提供 100 多個已驗證的合作夥伴 Agent

- 原生生態系統整合：企業系統的隨插即用連接器

A2A + MCP Codelab 逐步介紹如何構建跨語言協作的多 Agent 系統：codelabs.developers.google.com/instavibe-adk-multi-agents

包含多 Agent 模式的 ADK 範例：github.com/google/adk-samples

那些構建孤立 Agent 的公司將在十二個月內面臨重構。而那些構建可互通 Agent 生態系統的公司，其優勢將會與日俱增。

開始構建：adk.dev | https://cloud.google.com/products/gemini-enterprise-agent-platform

構建可互通的 Agent：Google for Startups AI Agents Challenge

孤立的 Agent 是死胡同。加入我們為期 6 週的全球挑戰賽，讓新創公司在 Gemini Enterprise Agent Platform 上構建、優化或重構 AI Agent。你將獲得 500 美元的雲端額度、完整的平台存取權，以及角逐 90,000 美元獎金池的機會。

立即報名開始構建！

## 標籤

MCP, Agent, 產業趨勢, Anthropic, Google