前陣子有知識星球成員私信，想要我介紹下 Google 發(fā)布的 A2A 是啥？

我在具體研究 A2A 之前，刷到過幾個視頻號的博主介紹 A2A時說 A2A 完全是多此一舉，現(xiàn)有的 MCP（大模型上下文協(xié)議 ）可以直接實現(xiàn) agent 之間的標準化交互功能。

但初步測試下來發(fā)現(xiàn)，A2A并非這么簡單。

這篇試圖說清楚 A2A 的核心定義是啥， 其與 MCP 的主要區(qū)別，以及 A2A 官方 Demo 復(fù)現(xiàn)講解。

以下，enjoy:

1、A2A 到底是啥

這部分內(nèi)容主要從公開信息整理而來，但當涉獵即可，看不下去的 feel free 劃到下一章節(jié)查看表格形式的與 MCP 核心特性對比。

根據(jù) Google 的官方介紹，A2A (Agent-to-Agent) 是其和超過 50 家技術(shù)合作伙伴（如 Langchain, Salesforce, SAP 等）共同推出并支持的開放協(xié)議，核心目標是為 AI Agents 提供一個標準的通信方式，使它們能夠：

1.1互相發(fā)現(xiàn)和識別

通過“Agent Card”（一種 JSON 格式的文件，包含 Agent 的 ID、名稱、能力、版本、安全需求等信息），一個 Agent 可以找到并了解其他 Agent 的能力。 

======= Agent Card ========
   {"name":"Parse and Chat","description":"Parses a file and then chats with a user using the parsed content as context.","url":"http://localhost:10010/","version":"1.0.0","capabilities":{"streaming":true,"pushNotifications":true,"stateTransitionHistory":false},"defaultInputModes":["text","text/plain"],"defaultOutputModes":["text","text/plain"],"skills":[{"id":"parse_and_chat","name":"Parse and Chat","description":"Parses a file and then chats with a user using the parsed content as context.","tags":["parse","chat","file","llama_parse"],"examples":["What does this file talk about?"]}]}
   =========  starting a new task ========

這個被 ======= Agent Card ======== 包裹的 JSON 對象就是官方Demo中LlamaIndex Agent 的 Agent Card示例。里面包含了：

name: "Parse and Chat"
description: Agent 功能描述
url: Agent 的訪問地址
version: 版本號
capabilities: 支持的能力（流式、推送通知等）
defaultInputModes / defaultOutputModes: 支持的默認輸入輸出格式
skills: Agent 擁有的技能列表，每個技能有 ID、名稱、描述、標簽和示例。

1.2安全地交換信息

協(xié)議設(shè)計考慮了安全性，確保 Agent 之間交互的可靠性。

{
      "jsonrpc": "2.0",
      "id": 11, // 請求 ID
      "method": "tasks/send", // A2A 方法
      "params": { // 方法參數(shù)
        "id": "129", // 任務(wù) ID
        "sessionId": "8f01f3d172cd4396a0e535ae8aec6687", // 會話 ID
        "acceptedOutputModes": [
          "text"
        ],
        "message": { // 用戶消息
          "role": "user",
          "parts": [ // 消息內(nèi)容部分
            {
              "type": "text",
              "text": "How much is the exchange rate for 1 USD to INR?"
            }
          ]
        }
      }
    }

Input - 發(fā)送給 Agent 服務(wù)器的請求示例

// 第一個流式更新 (中間狀態(tài))
    data: {"jsonrpc":"2.0","id":12,"result":{"id":"131","status":{"state":"working","message":{"role":"agent","parts":[{"type":"text","text":"Looking up the exchange rates..."}]},"timestamp":"2025-04-02T16:59:34.578939"},"final":false}}


    // 第二個流式更新 (中間狀態(tài))
    data: {"jsonrpc":"2.0","id":12,"result":{"id":"131","status":{"state":"working","message":{"role":"agent","parts":[{"type":"text","text":"Processing the exchange rates.."}]},"timestamp":"2025-04-02T16:59:34.737052"},"final":false}}


    // 第三個流式更新 (推送結(jié)果片段)
    data: {"jsonrpc":"2.0","id":12,"result":{"id":"131","artifact":{"parts":[{"type":"text","text":"Based on the current exchange rate, 1 USD is equivalent to 0.77252 GBP. Therefore, 100 USD would be approximately 77.252 GBP."}],"index":0,"append":false}}} // 注意這里是 artifact


    // 第四個流式更新 (最終狀態(tài))
    data: {"jsonrpc":"2.0","id":12,"result":{"id":"131","status":{"state":"completed","timestamp":"2025-04-02T16:59:35.331844"},"final":true}}

流式通知示例

1.3協(xié)調(diào)行動

跨越不同的工具、服務(wù)和企業(yè)系統(tǒng)進行協(xié)作，完成更復(fù)雜的任務(wù)。 

例如與LangGraph 貨幣兌換 Agent 交互時，這個 Agent 會調(diào)用外部的匯率 API 來獲取實時匯率。

2、A2A 與 MCP 的核心區(qū)別所在

2.1主要特性對比

下面通過一個表格給各位簡要的梳理下二者間的核心特性差別：

簡單來說：

MCP 關(guān)注的是 Agent 如何使用工具 (Agent-to-Tool/Context)。它讓 Agent 更方便地連接和使用各種外部資源（如 API、數(shù)據(jù)庫）。

A2A 關(guān)注的是 Agent 如何互相合作 (Agent-to-Agent)。它讓不同的 Agent 能夠像一個團隊一樣協(xié)同工作。

2.2A2A 相對 MCP 是否畫蛇添足

在給出這個問題答案之前，我們先來梳理下網(wǎng)上所謂的 MCP 實現(xiàn) A2A 核心功能的主要邏輯所在。

MCP 如何實現(xiàn) A2A 核心功能

封裝 Agent B 為 API/Tool：

將 Agent B 的核心功能（例如，特定的 RAG 檢索能力、數(shù)據(jù)分析能力、API 調(diào)用能力等）封裝在一個或多個 API 端點后面。


例如，創(chuàng)建一個 REST API，其中 /queryKnowledgeBase 端點接收查詢并返回 RAG 結(jié)果，/analyzeData 端點接收數(shù)據(jù)并返回分析報告。


這個 API 就成為了 Agent B 對外提供服務(wù)的接口。

為 API/Tool 創(chuàng)建 MCP 描述：

為 Agent B 的 API 創(chuàng)建一個符合 MCP 規(guī)范的描述文件（使用 OpenAPI Specification）。這個描述文件需要清晰地說明：


工具的名稱和描述（告訴 Agent A 這是什么工具，能做什么）。
可用的函數(shù)/端點（如 /queryKnowledgeBase）。
每個函數(shù)所需的輸入?yún)?shù)（名稱、類型、描述、是否必需）。
函數(shù)預(yù)期的輸出格式（結(jié)構(gòu)化的數(shù)據(jù)模式）。
可能的認證或安全要求。

Agent A 通過 MCP 調(diào)用 Agent B：

Agent A（通常是一個基于 LLM 的 Agent）在其上下文中“看到”了 Agent B 這個工具及其描述。


當 Agent A 的 LLM 判斷需要 Agent B 的能力來完成當前任務(wù)時，它會生成一個符合 MCP 規(guī)范的“工具調(diào)用”（Tool Call）請求。


這個請求包含了要調(diào)用的 Agent B 的函數(shù)名（如 /queryKnowledgeBase）以及所需的輸入?yún)?shù)（如用戶的查詢）。


Agent A 的執(zhí)行環(huán)境（或 MCP 處理器）接收到這個工具調(diào)用請求，實際調(diào)用 Agent B 的 API 端點。


Agent B 的 API 執(zhí)行其內(nèi)部邏輯（調(diào)用自己的 RAG 流程、分析數(shù)據(jù)等）。


Agent B 將執(zhí)行結(jié)果按照 MCP 描述中定義的輸出格式返回。


Agent A 的執(zhí)行環(huán)境接收到結(jié)果，并將其格式化為“工具結(jié)果”（Tool Result），反饋給 Agent A 的 LLM。


Agent A 的 LLM 結(jié)合這個工具結(jié)果，繼續(xù)處理任務(wù)或生成最終響應(yīng)。

這種“MCP + Agent as Tool”的方式，實測確實可以實現(xiàn)基本的 Agent 任務(wù)委托和信息交換，尤其適用于相對簡單、明確的請求-響應(yīng)式交互。

注：這部分大家可以參考我之前的文章，使用 Dify 的自定義 Tool 功能模擬 MCP 實現(xiàn) Agent 協(xié)作，這里就不做贅述。

Dify+RAGFLow：基于占位符的圖片問答升級方案（最佳實踐）

However，雖然可以將 Agent 視為 MCP 工具來實現(xiàn)部分 A2A 功能，但這更多是一種“模擬”，實際不能充分發(fā)揮多 Agent 系統(tǒng)協(xié)作的潛力，也缺乏 A2A 提供的標準化協(xié)作框架。

當然，選擇哪種方式取決于各位具體應(yīng)用場景的復(fù)雜度和對 Agent 間交互深度的要求。

3、A2A 官方 Demo 復(fù)現(xiàn)與講解

光說不練假把式，我們來使用 A2A 的 Github 官方實例來給大家做一個具體的復(fù)現(xiàn)講解。

建議感興趣的一定要實際上手操作下，再結(jié)合下方的日志解析應(yīng)該可以對 A2A 有更加完整的理解。

3.1官方示例的選擇

git clone https://github.com/google/A2A.git

先把 A2A 的官方倉庫下載到本地，我們可以發(fā)現(xiàn)官方提供了多個 demo（以 python 為例）供選擇測試，這里先分析下其中主要幾個 demo 的內(nèi)容和差別。 

Google ADK (google_adk)

內(nèi)容: 模擬一個填寫費用報銷單的 Agent。

主要特性:

使用 Google 的 Agent Development Kit (ADK) 構(gòu)建。

展示多輪交互：當用戶提供的信息不完整時，Agent 會要求補充。

核心亮點: 演示如何通過 A2A 返回 Web 表單給客戶端（或用戶）填寫，并在客戶端提交表單后繼續(xù)處理任務(wù)。

LangGraph (langgraph)

內(nèi)容: 一個可以進行貨幣兌換查詢的 Agent。

主要特性:

使用 LangGraph 框架和 ReAct 模式構(gòu)建。

展示多輪交互：例如，詢問需要兌換的目標貨幣。

核心亮點: 演示 Agent 如何使用外部工具（調(diào)用 Frankfurter API 獲取匯率）以及如何通過 A2A 流式傳輸狀態(tài)更新（例如，“正在查詢匯率...”）。

CrewAI (crewai)

內(nèi)容: 一個可以生成圖像的 Agent。

主要特性:

使用 CrewAI 框架構(gòu)建。

展示多輪交互。

核心亮點: 演示如何通過 A2A 發(fā)送圖像數(shù)據(jù)作為任務(wù)結(jié)果。

LlamaIndex File Chat (llama_index_file_chat)

內(nèi)容: 一個可以接收用戶上傳的文件，解析文件內(nèi)容，然后根據(jù)文件內(nèi)容與用戶進行問答的 Agent。

主要特性:

使用 LlamaIndex Workflows 構(gòu)建。

展示多輪交互：在同一會話中基于文件內(nèi)容進行連續(xù)問答。

核心亮點: 演示通過 A2A 處理文件上傳（用戶將文件附加到請求中）、文件解析（使用 LlamaParse），以及流式傳輸狀態(tài)更新和帶引用的結(jié)果（回答中會標注信息來源是文件的哪部分）。

經(jīng)過初步測試，建議各位還是從 LangGraph (langgraph) 示例開始實踐，理解了 LangGraph 示例后，可以再嘗試其他示例，例如 ADK 示例來理解 Web 表單交互，或者 LlamaIndex 示例來理解文件處理。

3.2LangGraph 的配置

1. 導(dǎo)航至demo目錄:
   ```bash
   cd samples/python/agents/langgraph
   ```
2. 創(chuàng)建虛擬環(huán)境并配置Google_API_Key:
   ```bash
   echo "GOOGLE_API_KEY=your_api_key_here" > .env
   ```
3. 運行agent服務(wù)器:
   ```bash
   # Basic run on default port 10000
   uv run .
   # On custom host/port
   uv run . --host 0.0.0.0 --port 8080
   ```
4. 另起一個單獨的終端, 運行A2A客戶端:
   ```bash
   cd samples/python/hosts/cli
   uv run .
   ```

3.3測試目的與示例場景

測試目的

• A2A 協(xié)議集成: 確保 Agent 可以正確地通過 A2A 協(xié)議接收任務(wù)請求 (tasks/send, tasks/sendSubscribe) 并返回符合協(xié)議規(guī)范的響應(yīng)。
• 多輪對話能力: 測試 Agent 在信息不充分時，能否主動向用戶請求額外信息（例如，只問了“1 美元換多少？”，Agent 會反問“換成哪種貨幣？”），并能利用后續(xù)用戶提供的信息完成任務(wù)。
• 流式響應(yīng) (Streaming): 測試 Agent 在處理耗時任務(wù)時，能否通過 A2A 協(xié)議實時發(fā)送中間狀態(tài)更新（例如，“正在查找匯率...”，“正在處理...”），而不是讓客戶端一直等待最終結(jié)果。
• 工具使用 (Tool Usage): 測試基于 ReAct 模式的 LangGraph Agent 能否在需要時正確調(diào)用外部工具（這里是 Frankfurter API）來獲取實時匯率數(shù)據(jù)。
• 會話管理 (Conversational Memory): 測試 Agent 能否在同一會話 (sessionId) 的多次交互中保持上下文記憶。

示例場景

簡單同步請求: 發(fā)送一個包含所有必要信息的請求，期望直接得到最終結(jié)果。

例子: "1 美元兌換多少印度盧比？" (How much is the exchange rate for 1 USD to INR?)

需要補充信息的多輪請求: 發(fā)送一個信息不完整的請求，測試 Agent 是否會要求補充信息，以及在收到補充信息后能否給出結(jié)果。

用戶: "1 美元能換多少？" (How much is the exchange rate for 1 USD?)

Agent: "你想換成哪種貨幣？" (Which currency do you want to convert to? )

用戶: "加元" (CAD)

Agent: (返回 1 美元兌換加元的匯率)

流式請求: 發(fā)送一個訂閱任務(wù)的請求 (tasks/sendSubscribe)，測試服務(wù)器是否會逐步推送狀態(tài)更新和最終結(jié)果。

例子: "100 美元兌換多少英鎊？" (How much is 100 USD in GBP?)，期望收到類似 "正在查找匯率...", "正在處理...", 然后是最終結(jié)果的消息流。

針對一次提問 ("How much is 100 USD in GBP?")，客戶端收到了三個以 stream event => 開頭的獨立消息。這就是流式輸出的核心——服務(wù)器不是一次性返回最終結(jié)果，而是分多次推送信息。 

3.4日志解析

客戶端日志

samples/python/hosts/cli 目錄下的日志，這是最直接展示 A2A 交互的地方。

發(fā)起請求: 當在 CLI 中輸入問題（例如 "What is exchange rate between USD and GBP?"），CLI 工具會構(gòu)建一個符合 A2A tasks/sendSubscribe 或 tasks/send 規(guī)范的 JSON RPC 請求，并通過 HTTP POST 發(fā)送給 Agent 服務(wù)器 (http://localhost:10000)。雖然日志沒有顯示發(fā)出的請求原文，但后續(xù)的響應(yīng)證明了請求的發(fā)送 ( http://localhost:10000)。雖然日志沒有顯示發(fā)出的請求原文，但后續(xù)的響應(yīng)證明了請求的發(fā)送 )。

接收響應(yīng) (流式事件): 日志中的 stream event => {...} 行就是 Agent 服務(wù)器按照 A2A 協(xié)議返回給 CLI 客戶端的實時響應(yīng)。這些 JSON 數(shù)據(jù)結(jié)構(gòu)完全遵循 A2A 規(guī)范：

jsonrpc: "2.0": 表明使用 JSON RPC 協(xié)議。
id: 對應(yīng)請求的 ID。
result.id: A2A 任務(wù)的 ID。
result.status.state: 顯示任務(wù)狀態(tài)，如 working (處理中), input-required (需要輸入), completed (已完成)。這是 A2A 定義的標準狀態(tài)。
result.status.message: 當狀態(tài)是 working 或 input-required 時，這里包含 Agent 發(fā)來的中間消息或提問。
result.artifact: 當任務(wù)完成時，這里包含最終的結(jié)果。
final: false / true: 表明這個事件是否是該次請求的最終響應(yīng)。false 代表后面還有更新，true 代表結(jié)束。

多輪交互體現(xiàn): 當問 "How much is the exchange rate for 1 USD?" 時，收到的事件中 result.status.state 變?yōu)?input-required，并且 result.status.message 包含了 Agent 的提問 "What currency do you want to convert to?..."。隨后再輸入 "CAD"，CLI 再次發(fā)送 A2A 請求，Agent 處理后返回最終結(jié)果。這清晰地展示了 A2A 對多輪對話的支持。

Agent 服務(wù)器日志

samples/python/agents/langgraph 目錄下的日志，這份日志展示了 Agent 服務(wù)器內(nèi)部處理 A2A 請求的過程。

接收請求: INFO: 127.0.0.1:xxxxx - "POST / HTTP/1.1" 200 OK 表明服務(wù)器收到了來自 CLI 客戶端的 HTTP POST 請求 (這是承載 A2A 消息的方式)。

任務(wù)管理: INFO:common.server.task_manager:Upserting task ... 和 Getting task ... 顯示服務(wù)器內(nèi)部對 A2A 任務(wù)狀態(tài)的管理。

調(diào)用外部工具: INFO:httpx:HTTP Request: GET https://api.frankfurter.app/ ( https://api.frankfurter.app/ )... 顯示 Agent 為了回答問題，調(diào)用了外部的匯率 API。這是 Agent 內(nèi)部邏輯的一部分，由 A2A 請求觸發(fā)。

準備響應(yīng): 雖然日志沒有直接顯示服務(wù)器發(fā)送的 JSON 響應(yīng)，但服務(wù)器的處理邏輯（調(diào)用 API、生成文本）最終會

構(gòu)建成您在客戶端日志中看到的 stream event 內(nèi)容，然后發(fā)送回客戶端。

Agent 發(fā)現(xiàn): INFO: 127.0.0.1:xxxxx - "GET /.well-known/agent.json HTTP/1.1" 200 OK 是 CLI 客戶端啟動時，根據(jù) A2A 規(guī)范去獲取 Agent 能力描述文件的記錄。

4、MCP 如何與 A2A 協(xié)同

注：這部分內(nèi)容由 LLM 協(xié)助編寫

一個復(fù)雜的企業(yè) RAG 系統(tǒng)，不僅僅是一個單一的問答機器人，而是一個由多個專業(yè) agents 組成的協(xié)作網(wǎng)絡(luò)： 

MCP 的角色（垂直整合 - Agent 與工具/數(shù)據(jù)）:

核心 RAG Agent: 每個負責(zé)特定領(lǐng)域（如 HR、財務(wù)、產(chǎn)品技術(shù)文檔）的 RAG Agent，內(nèi)部會使用 MCP 來標準化地調(diào)用其核心工具：

連接并查詢**向量數(shù)據(jù)庫**以檢索相關(guān)文檔片段。 訪問**結(jié)構(gòu)化數(shù)據(jù)庫**（如 SQL 數(shù)據(jù)庫）以獲取精確數(shù)據(jù)。 調(diào)用**內(nèi)部 API**（例如，查詢用戶權(quán)限、獲取實時庫存狀態(tài)）。 MCP 在這里確保了每個 RAG Agent 能夠高效、可靠地利用其所需的底層數(shù)據(jù)源和功能 API，就像給 Agent 插上了標準化的“眼睛”和“手臂”去感知和操作數(shù)據(jù)。

**A2A 的角色（水平協(xié)作 - Agent 與 Agent）:

用戶交互與路由 Agent: 用戶首先接觸的是一個前端交互 Agent。該 Agent 理解用戶意圖后，利用 A2A 協(xié)議的發(fā)現(xiàn)機制找到最合適的下游專業(yè) Agent。

任務(wù)委托與編排: 路由 Agent 通過 A2A 向選定的專業(yè) RAG Agent（如 HR Agent 或 技術(shù)文檔 Agent）提交一個標準的 Task。如果任務(wù)復(fù)雜，需要跨領(lǐng)域知識（例如，“查詢新員工入職的技術(shù)設(shè)備配置流程和預(yù)算標準”），路由 Agent（或一個專門的編排 Agent）可以通過 A2A 協(xié)調(diào)技術(shù)文檔 Agent 和財務(wù) Agent，管理各自子任務(wù)的狀態(tài)，最終匯總結(jié)果。A2A 的任務(wù)生命周期管理在此場景下至關(guān)重要。

多輪澄清與協(xié)作: 如果專業(yè) RAG Agent 在處理任務(wù)時發(fā)現(xiàn)信息不足，可以通過 A2A 向路由 Agent（進而傳遞給用戶）發(fā)送需要輸入 (Needs Input) 的狀態(tài)和澄清消息，進行多輪交互，而不是簡單地失敗或返回模糊答案。

主動知識更新與同步: 一個監(jiān)控 Agent 可以監(jiān)測外部信息源（如法規(guī)更新網(wǎng)站、內(nèi)部知識庫變更），發(fā)現(xiàn)重要更新后，通過 A2A 通知相關(guān)的 RAG Agent 進行知識庫更新（如重新索引）或觸發(fā)內(nèi)容摘要任務(wù)。

5、寫在最后

總結(jié)來說，與側(cè)重于標準化 Agent/LLM 與外部工具/數(shù)據(jù)源交互的 MCP 相比，A2A 并非畫蛇添足。雖然通過將 Agent 封裝為 API 并使用 MCP 的“工具調(diào)用”模式，但缺乏 A2A 在任務(wù)生命周期管理、豐富消息傳遞、流式狀態(tài)更新和標準化協(xié)作原語方面的深度和靈活性。

A2A 剛推出不久，在實際生產(chǎn)場景中具體可以發(fā)揮多大的作用還有待各位一起探索，我計劃后續(xù)分享的項目實操案例中，會適當加入 A2A 的相關(guān)方法。Anyway，從實踐中來，到實踐中去。