人工智慧的世界正迅速發展，AI 代理變得越來越複雜和強大。隨著這些代理變得越來越普及，它們之間無縫的溝通和協作的需求變得至關重要。Agent2Agent (A2A) 協議應運而生，這是 Google 的創新解決方案，旨在促進 AI 代理之間的互通性和團隊合作。
A2A 的核心是一個框架，使 AI 代理能夠有效地溝通和協作，無論它們的底層架構或背後的供應商如何。它作為一個通用翻譯器，彌合了不同 AI 系統之間的差距，促進了無縫的互動。可以將其視為一種通用語言，使 AI 代理能夠和諧地協同工作，為複雜的問題解決和自動化開啟新的可能性。
A2A 的起源：應對 AI 整合的挑戰
要充分理解 A2A 的重要性，必須了解導致其創建的背景。像 GPT-3.5 這樣強大的語言模型的興起，標誌著 AI 應用的一個轉折點，開發人員尋求將其功能擴展到簡單的聊天介面之外的方法。
一種早期的解決方案是函數調用，它允許大型語言模型 (LLM) 以一對一的方式連接到外部 API。然而，這種方法很快導致了一個分散的生態系統，不同的 AI 供應商和實施者採用了不同的整合方法，導致互通性有限。
Anthropic 的模型上下文協議 (MCP) 作為一種潛在的解決方案出現，旨在解決 ‘NxM 問題’，即代理/AI 系統 (N) 的數量乘以工具/資料來源 (M) 的數量。MCP 旨在標準化上下文並簡化整合，但 Google 認識到需要一種協議，使代理能夠直接相互溝通。
這就是 A2A 的用武之地。與 MCP 一樣，A2A 統一了 AI 代理的互動方式，但它不是專注於將代理連接到工具和資料，而是專注於將代理連接到其他代理。這是朝著構建真正協作的 AI 系統邁出的關鍵一步。
揭示 A2A 的本質：AI 代理的通用語言
A2A 是一個開放協議，使 AI 代理能夠相互溝通，無論它們的來源或設計如何。它充當翻譯器，理解和解釋各種語言和框架，例如 LangChain、AutoGen 和 LlamaIndex。
A2A 於 2025 年 4 月推出，是與 50 多家技術合作夥伴合作開發的，其中包括 Atlassian、Salesforce、SAP 和 MongoDB 等行業巨頭。這種協作方法確保 A2A 不僅僅是 Google 的一項倡議，而是更廣泛的行業標準化努力。
A2A 的核心是將每個 AI 代理視為具有標準介面的網路服務。這類似於 Web 瀏覽器和伺服器使用 HTTP 進行通訊的方式，但不是針對網站，而是針對 AI 代理。正如 MCP 解決了 NxM 問題一樣，A2A 簡化了連接不同代理的過程，而無需為每個配對編寫自定義程式碼。
解讀 A2A 的核心功能：實現無縫協作
A2A 建立在四個關鍵功能之上，使代理協作成為現實。要理解這些功能，重要的是要定義一些關鍵術語：
- 客戶端代理/A2A 客戶端： 使用 A2A 服務的應用程式或代理。這是發起任務並與其他代理通訊的 ‘主’ 代理。
- 遠端代理/A2A 伺服器： 使用 A2A 協議公開 HTTP 端點的代理。這些是處理任務完成的補充代理。
有了這些定義，讓我們探索 A2A 的四個核心功能：
- 能力發現： 此功能回答了 ‘你能做什麼？’ 這個問題。它允許代理通過 ‘代理卡片’ 宣傳其能力，這些代理卡片是 JSON 檔案，提供了代理的技能和服務的機器可讀取的配置檔案。這有助於客戶端代理識別特定任務的最佳遠端代理。
- 任務管理： 此功能解決了 ‘每個人都在一起工作嗎，你的狀態是什麼？’ 這個問題。它確保客戶端和遠端代理之間的通訊集中於任務完成，具有特定的任務物件和生命週期。對於長時間運行的任務，代理可以通訊以保持同步。
- 協作： 此功能側重於 ‘上下文、回覆、任務輸出（工件）或使用者指示是什麼？’ 這個問題。它使代理能夠來回發送訊息，從而創建對話流程。
- 使用者體驗協商： 此功能解決了 ‘我應該如何向使用者顯示內容？’ 這個問題。每條訊息都包含具有特定內容類型的 ‘部分’，允許代理協商正確的格式並了解 UI 功能，如 iframe、影片和 Web 表單。代理根據接收代理（客戶端）可以處理的內容調整其呈現資訊的方式。
解密 A2A 的內部運作：用於 AI 通訊的客戶端-伺服器模型
A2A 基於客戶端-伺服器模型運行，其中代理使用結構化的 JSON 訊息通過標準 Web 協議（如 HTTP）進行通訊。這種方法確保與現有基礎設施的相容性，同時標準化代理通訊。
要了解 A2A 如何實現其目標，讓我們分解協議的核心組件並探索 ‘不透明’ 代理的概念。
A2A 的核心組件：用於 AI 協作的構建模組
- 代理卡片： 此 JSON 檔案通常託管在一個眾所周知的 URL（例如
/.well-known/agent.json）上，描述了代理的功能、技能、端點 URL 和身份驗證要求。它充當代理的機器可讀取的 ‘簡歷’，幫助其他代理確定是否與其互動。 - A2A 伺服器： 使用 A2A 協議公開 HTTP 端點的代理。這是 A2A 中的 ‘遠端代理’，它接收來自客戶端代理的請求並處理任務。伺服器通過代理卡片宣傳其功能。
- A2A 客戶端： 使用 A2A 服務的應用程式或 AI 系統。客戶端構建任務並根據其功能和技能將其分發到相應的伺服器。這是 A2A 中的 ‘客戶端代理’，它與專用伺服器協調工作流程。
- 任務： A2A 中的中心工作單元。每個任務都有一個唯一的 ID，並通過定義的狀態（例如
submitted、working、completed）進行。任務充當請求和執行的工作的容器。 - 訊息： 客戶端和代理之間的通訊交換。訊息在任務的上下文中交換，並包含傳遞內容的部分。
- 部分： 訊息或工件中的基本內容單元。部分可以是：
TextPart：用於純文本或格式化內容FilePart：用於二進位資料（帶有內聯位元組或 URI 參考）DataPart：用於結構化的 JSON 資料（如表單）
- 工件： 代理在任務期間生成的輸出。工件也包含部分，並表示從伺服器返回到客戶端的最終可交付成果。
不透明代理的概念：保護智慧財產權並確保安全性
‘不透明’ 一詞在 A2A 的上下文中表示代理可以在不洩露其內部邏輯的情況下協作執行任務。這意味著：
- 代理只需要公開它可以執行的任務，而不是它如何執行它們。
- 專有演算法或資料可以保持私密。
- 只要代理支援相同的功能，就可以將代理換成替代實現。
- 組織可以整合協力廠商代理，而無需擔心安全性問題。
A2A 的方法簡化了複雜的多代理系統的開發，同時保持高安全性標準並保護商業機密。
典型的 A2A 互動流程：逐步指南
當代理通過 A2A 通訊時，它們遵循結構化的順序：
- 發現階段： 想像一下，使用者詢問其主要 AI 代理 ‘你能幫我計劃下個月去東京的出差嗎？’ AI 認識到需要找到專門的代理來處理航班、酒店和當地活動。客戶端代理識別可以協助執行每個任務的遠端代理，並檢索其代理卡片以評估其適用性。
- 任務啟動： 團隊組建完成後，就可以分配工作了。客戶端代理可能會對旅行預訂代理說 ‘查找 5 月 15 日至 20 日從出發到東京的航班’。客戶端向伺服器的端點發送請求（通常是 POST 到
/taskssend），從而創建一個具有唯一 ID 的新任務。這包括詳細說明客戶端希望伺服器執行的操作的初始訊息。 - 處理： 預訂專家代理（伺服器/遠端代理）開始搜索符合標準的可用航班。它可能會：
- 立即完成任務並返回工件：’這是可用的航班’。
- 請求更多資訊（將狀態設置為
input-required）：’你喜歡特定的航空公司嗎？’ - 開始處理長時間運行的任務（將狀態設置為
working）：’我正在比較價格以找到最划算的交易’。
- 多輪對話： 如果需要更多資訊，客戶端和伺服器會交換額外的訊息。伺服器可能會提出澄清問題（’可以轉機嗎？’），客戶端會回應（’不，僅限直飛航班’），所有這些都在同一任務 ID 的上下文中進行。
- 狀態更新： 對於需要時間才能完成的任務，A2A 支援多種通知機制：
- 輪詢：客戶端定期檢查任務狀態。
- 伺服器發送事件 (SSE)：如果客戶端已訂閱，伺服器會傳輸即時更新。
- 推送通知：如果提供，伺服器可以將更新 POST 到回調 URL。
- 任務完成： 完成後，伺服器將任務標記為
completed並返回包含結果的工件。或者，如果遇到問題，它可能會將任務標記為failed，或者如果任務已終止，則將其標記為canceled。
在整個過程中，主代理可能會同時與其他專業代理合作：酒店專家、當地交通大師、活動策劃高手。主代理將通過將所有這些結果合併到一個綜合旅行計劃中來創建行程，然後將其呈現給使用者。
本質上，A2A 使多個代理能夠為實現共同目標做出貢獻和協作，客戶端代理組裝的結果超過其各個部分的總和。
A2A 與 MCP：用於 AI 整合的協同合作夥伴關係
雖然 A2A 和 MCP 看起來可能在爭奪相同的空間，但它們旨在協同工作。它們解決了 AI 整合的不同但互補的方面：
- MCP 將 LLM（或代理）連接到工具和資料來源（垂直整合）。
- A2A 將代理連接到其他代理（橫向整合）。
Google 特意將 A2A 定位為與 MCP 互補。這種設計理念在其啟動具有內置 MCP 支援以及 A2A 的 Vertex AI 代理構建器中顯而易見。
為了說明這一點，請考慮這個類比：如果 MCP 使代理可以使用工具，那麼 A2A 就是他們工作時的對話。MCP 為單個代理提供功能，而 A2A 幫助他們協調這些功能作為一個團隊。
在一個全面的設置中，代理可能會使用 MCP 從資料庫中檢索資訊，然後使用 A2A 將該資訊傳遞給另一個代理進行分析。這兩種協議可以協同工作，為複雜任務創建更完整的解決方案，同時簡化自 LLM 成為主流以來一直存在的開發挑戰。
A2A 安全標準：確保企業級保護
A2A 的開發以企業安全為首要考慮因素。除了獨家使用不透明代理外，每個代理卡片都指定了所需的身份驗證方法（API 密鑰、OAuth 等），並且所有通訊都設計為通過 HTTPS 進行。這使組織能夠建立策略，管理哪些代理可以相互通訊以及它們可以共享哪些資料。
與 MCP 授權規範類似，A2A 利用現有的 Web 安全標準，而不是創建新的模式，從而確保與當前身份系統的即時相容性。由於所有互動都通過定義明確的端點進行，因此可觀察性變得簡單，使組織能夠整合其首選的監控工具並獲得統一的審計追蹤。
A2A 生態系統和採用：不斷增長的支援社群
A2A 協議已在 50 多家技術合作夥伴的鼎力支援下啟動，其中許多合作夥伴目前支援或打算使用自己的代理支援 A2A。Google 已將 A2A 整合到其 Vertex AI 平台和 ADK 中，為已在 Google Cloud 生態系統中的開發人員提供了一個簡化的入口點。
考慮實施 A2A 的組織應考慮以下事項：
- 降低整合成本： 開發人員可以普遍實施 A2A，而不是為每個代理配對構建自定義程式碼，從而降低整合成本。
- 相對較新的版本： A2A 仍處於廣泛發佈的早期階段，這意味著它尚未經過大規模發現潛在缺點所需的廣泛的真實世界測試。
- 面向未來： 作為一個開放協議，A2A 允許新舊代理整合到其生態系統中，而無需額外的工作。
- 代理限制： 雖然 A2A 代表了真正自主 AI 的重大進步，但它仍然以任務為導向，並且不能完全獨立運行。
- 供應商不可知： A2A 不會將組織鎖定到任何特定模型、框架或供應商，從而允許他們在整個 AI 領域中進行混合和匹配。
Agent2Agent 協議的未來：無縫 AI 協作的願景
展望未來，A2A 有望進一步改進，如協議的路線圖中所述。計劃的增強功能包括：
- 正式的授權方案和代理卡片中直接包含的可選憑證。
- 正在進行的任務中的動態 UX 協商（例如，在對話中添加音訊/視訊）。
- 改進的流媒體效能和推送通知機制。
也許最令人興奮的長期可能性是，A2A 將成為代理開發的 HTTP 之於 Web 通訊：創新爆炸的催化劑。隨著採用率的提高，我們可能會看到專為特定行業預先打包的 ‘團隊’ 代理，最終看到客戶端可以利用的無縫全球 AI 代理網路。
對於探索 AI 實施的開發人員和組織來說，現在是學習和使用 A2A 進行構建的理想時機。A2A 和 MCP 共同代表了一種更標準化、更安全和更適合企業使用的 AI 方法的開始。