揭秘Google A2A協(xié)議：原理、應(yīng)用與未來 精華
一、A2A 協(xié)議的核心原理
A2A 協(xié)議的設(shè)計基于五個核心原則，這些原則確保了協(xié)議的靈活性、安全性和廣泛適用性。以下是對這些原則的詳細(xì)解析，并結(jié)合技術(shù)機制進(jìn)行說明。
1. 擁抱智能體特性（Embrace Agentic Capabilities）
A2A 協(xié)議專為具有自主性和復(fù)雜推理能力的 AI 智能體設(shè)計。不同于傳統(tǒng)的工具調(diào)用（如 API 或數(shù)據(jù)庫查詢），A2A 允許智能體以自然、結(jié)構(gòu)化的方式進(jìn)行協(xié)作，而無需共享內(nèi)存、工具或上下文。這種設(shè)計支持智能體在分布式環(huán)境中獨立運行，同時保持高效的協(xié)作能力。
技術(shù)實現(xiàn)：
? 智能體之間的通信通過任務(wù)（Task）作為核心工作單元。任務(wù)可以是短期的（如生成報告）或長期的（如供應(yīng)鏈優(yōu)化）。
? 智能體通過消息（Message）交換信息，消息支持多模態(tài)內(nèi)容（如文本、圖像、視頻），適應(yīng)復(fù)雜場景。
? 智能體不需要了解彼此的內(nèi)部實現(xiàn)，只需遵循 A2A 協(xié)議的接口規(guī)范即可。
2. 基于現(xiàn)有標(biāo)準(zhǔn)（Build on Existing Standards）
A2A 協(xié)議利用成熟的 Web 技術(shù)，確保與現(xiàn)有 IT 架構(gòu)的兼容性和易用性。
核心技術(shù)包括：
? HTTP/HTTPS：作為主要傳輸協(xié)議，生產(chǎn)環(huán)境中必須使用 HTTPS 和現(xiàn)代 TLS 加密。
? JSON-RPC 2.0：用于結(jié)構(gòu)化數(shù)據(jù)交換，確保請求和響應(yīng)的標(biāo)準(zhǔn)化。 - 服務(wù)器發(fā)送事件（SSE）：支持實時、單向的流式更新，適用于任務(wù)進(jìn)度通知。
優(yōu)勢：
? 開發(fā)者無需學(xué)習(xí)新的協(xié)議棧，現(xiàn)有工具和庫即可支持 A2A。
? 企業(yè)可以輕松將 A2A 集成到現(xiàn)有的微服務(wù)架構(gòu)中。
3. 默認(rèn)安全（Secure by Default）
安全性是 A2A 協(xié)議的核心考量。協(xié)議內(nèi)置了企業(yè)級認(rèn)證和授權(quán)機制，包括：
? OAuth 和 OpenAPI 認(rèn)證：確保只有授權(quán)的智能體可以通信。
? 數(shù)字證書：A2A 服務(wù)器通過知名證書頒發(fā)機構(gòu)簽發(fā)的證書證明身份。
? 請求追蹤：支持日志和事件隊列，便于監(jiān)控和審計。
技術(shù)實現(xiàn)：
? 智能體卡表（Agent Card）中包含認(rèn)證要求，客戶端智能體在發(fā)起任務(wù)前必須完成身份驗證。
? 數(shù)據(jù)傳輸使用 HTTPS 加密，防止中間人攻擊。
4. 支持長時間運行任務(wù)（Support for Long-Running Tasks）
A2A 協(xié)議不僅支持簡單的請求-響應(yīng)交互，還能處理需要數(shù)小時或數(shù)天的復(fù)雜任務(wù)。例如，供應(yīng)鏈優(yōu)化可能涉及多個智能體的協(xié)作，任務(wù)狀態(tài)需要持續(xù)跟蹤。
任務(wù)具有唯一 ID 和狀態(tài)（如 submitted、working、completed、failed）。通過tasks/sendSubscribe 方法，客戶端可以建立流式連接，接收任務(wù)的實時更新。任務(wù)狀態(tài)通過 SSE 推送，確?？蛻舳藷o需輪詢。
5. 模態(tài)無關(guān)（Modality Agnostic）
A2A 支持多模態(tài)通信，智能體可以交換文本、圖像、音頻、視頻或交互式內(nèi)容（如 Web 表單）。這種設(shè)計適應(yīng)了企業(yè)中多樣化的數(shù)據(jù)需求。
消息中的“結(jié)構(gòu)體（Part）”定義了內(nèi)容類型，允許智能體協(xié)商適合的格式。例如，一個智能體可以返回圖表數(shù)據(jù)（JSON）或渲染后的圖像，具體取決于客戶端的偏好。
二、A2A 協(xié)議的核心組件
A2A 協(xié)議的實現(xiàn)依賴于幾個核心組件，這些組件共同構(gòu)成了智能體間通信的框架。以下是對每個組件的詳細(xì)說明。
1. 智能體卡表（Agent Card）
智能體卡表是 A2A 協(xié)議的入口點，用于描述智能體的身份和能力。它是一個 JSON 格式的元數(shù)據(jù)文件，通常托管在智能體的某個確定的路徑下。
結(jié)構(gòu)：
? 身份信息：包括智能體的名稱、版本和托管地址（DNS 或 URL）。
? 能力描述：列出支持的功能（如流式傳輸、推送通知）和技能（Skills）。
? 認(rèn)證要求：指定 OAuth、API 密鑰或 OIDC 等認(rèn)證方式。
? 端點：提供 API 端點的 URL（如 tasks/send）。
示例（簡化版）：
{
"name": "XX云服務(wù)",
"version": "1.0.0",
"endpoint": "https://mycloud.com/a2a",
"capabilities": {
"streaming": true,
"pushNotifications": true
},
"skills": ["AI秘書", "訂購助手"],
"authentication": {
"type": "OAuth",
"url": "https://mycloud.com/"
}
}作用：
? 能力發(fā)現(xiàn)：客戶端智能體通過讀取智能體卡表了解遠(yuǎn)程智能體的功能，決定是否發(fā)起協(xié)作。
? 動態(tài)注冊：對于服務(wù)端來說，智能體可以在運行時更新其能力，無需重啟會話。
2. 任務(wù)（Task）
任務(wù)是 A2A 協(xié)議的核心工作單元，表示客戶端智能體請求遠(yuǎn)程智能體執(zhí)行的操作。任務(wù)具有明確的生命周期和狀態(tài)管理。
生命周期：
? 提交（submitted）：任務(wù)被客戶端發(fā)送到遠(yuǎn)程智能體。
? 工作中（working）：遠(yuǎn)程智能體正在處理任務(wù)。
? 需要輸入（input-required）：任務(wù)需要額外信息暫停。
? 完成（completed）：任務(wù)成功結(jié)束，返回工件（Artifact）。
? 失?。╢ailed）：任務(wù)因錯誤終止。
? 取消（canceled）：任務(wù)被客戶端取消。
API 方法：
? tasks/send：同步請求，適合快速任務(wù)，客戶端等待響應(yīng)。
? tasks/sendSubscribe：建立流式連接，適合長時間任務(wù)，客戶端接收 SSE 更新。
示例請求：
{
"method": "tasks/send",
"params": {
"task": {
"id": "task-123",
"description": "請開通XX服務(wù)",
"input": {
"data": ["XX服務(wù)規(guī)格：..."]
}
}
},
"jsonrpc": "2.0",
"id": 1
}圖示：
3. 消息（Message）
消息是智能體間通信的基本單位，表示一次交互的“回合”。消息支持多模態(tài)內(nèi)容，并通過“Part”定義具體格式。
結(jié)構(gòu)：
? 角色：user（客戶端智能體）或 agent（遠(yuǎn)程智能體）。
? 內(nèi)容：包含多個部分（Part），每個部分指定內(nèi)容類型（如 text/plain、image/png）。
? 元數(shù)據(jù)：包括消息 ID、時間戳等。
示例：
{
"role": "agent",
"parts": [
{
"contentType": "text/plain",
"content": "Chart generated successfully"
},
{
"contentType": "image/png",
"content": "base64_encoded_image"
}
],
"id": "msg-456",
"timestamp": "2025-04-24T22:00:00Z"
}作用：
? 支持復(fù)雜的交互，如同時傳輸文本說明和可視化結(jié)果。
? 允許格式協(xié)商，例如客戶端請求 JSON 數(shù)據(jù)而非圖像。
4. 產(chǎn)出層：Artifact 管理
Artifact 是指任務(wù)的輸出，通常是文件或結(jié)構(gòu)化數(shù)據(jù)（如報告、圖像）。工件與消息類似，但專注于任務(wù)的最終結(jié)果。
示例：
{
"id": "artifact-789",
"contentType": "application/pdf",
"content": "XX服務(wù)已經(jīng)訂購成功",
"taskId": "task-123"
}作用：
? 提供標(biāo)準(zhǔn)化的輸出格式，便于客戶端處理。
? 支持大文件傳輸，通過分片或流式傳輸。
5. A2A 服務(wù)器與客戶端
? A2A 服務(wù)器：實現(xiàn) A2A 協(xié)議的 HTTP 端點，接收任務(wù)請求并執(zhí)行操作。它托管智能體卡表并處理任務(wù)生命周期。
? A2A 客戶端：發(fā)起任務(wù)的智能體或應(yīng)用，通過 HTTP 請求與服務(wù)器交互。
交互流程：
- 客戶端通過智能體卡表發(fā)現(xiàn)服務(wù)器。
- 客戶端發(fā)送任務(wù)請求（tasks/send 或tasks/sendSubscribe）。
- 服務(wù)器處理任務(wù)并返回消息或工件。
三、技術(shù)細(xì)節(jié)
1. JSON Schema
A2A 協(xié)議的核心規(guī)范通過 JSON Schema 定義（a2a.json），詳細(xì)描述了智能體卡表、任務(wù)、消息等對象的字段、類型和約束。開發(fā)者可以通過 JSON Schema 工具驗證實現(xiàn)是否符合標(biāo)準(zhǔn)。
關(guān)鍵字段：
? AgentCard.capabilities：支持的功能，如streaming、pushNotifications。 - Task.state：任務(wù)狀態(tài)枚舉（submitted、working 等）。
? Message.parts：支持的內(nèi)容類型（如 text/plain、application/json）。
2. 通信模式
A2A 支持兩種通信模式：
? 同步模式：通過 tasks/send 實現(xiàn)，適合快速任務(wù)。
? 異步模式：通過 tasks/sendSubscribe 和 SSE 實現(xiàn)，適合長時間任務(wù)。
SSE 示例：
GET /tasks/sendSubscribe?taskId=task-123 HTTP/1.1
Host: mycloud.com
Accept: text/event-stream響應(yīng)：
event: task-update
data: {"taskId": "task-123", "state": "working"}
event: task-update
data: {"taskId": "task-123", "state": "completed", "artifact": "artifact-789"}3. 錯誤處理
A2A 定義了標(biāo)準(zhǔn)化的錯誤響應(yīng)，基于 JSON-RPC 2.0。例如：
{
"jsonrpc": "2.0",
"error": {
"code": 32600,
"message": "認(rèn)證失敗"
},
"id": 1
}四、行業(yè)案例
以運營商智能客服系統(tǒng)為例，演示 A2A 在通信行業(yè)的典型應(yīng)用流程。
1. 背景
假設(shè)運營商在全國多個省部署了智能客服的智能體。用戶在線咨詢時，往往需要跨省調(diào)用多方能力，例如：
? 查詢套餐余量（系統(tǒng) A）
? 推薦個性化增值業(yè)務(wù)（系統(tǒng) B）
? 處理投訴工單（系統(tǒng) C）
2. A2A 集成流程
? 能力注冊
各個?。ū热绨不帐。┑闹悄芸头到y(tǒng)分別發(fā)布自己的 Agent到中心節(jié)點：
anhui.xxx.com/.well-known/agent.json
jiangsu.xxx.com/.well-known/agent.json
center.xxx.com/.well-known/agent.json
? 發(fā)現(xiàn)與認(rèn)證
主客服 Agent（客戶當(dāng)前所在地）在接到用戶請求后，通過 HTTP GET 向中心節(jié)點拉取各 Agent Card，篩選出客戶號碼所在地的智能體地址。同時，使用 OAuth2 向目標(biāo) Agent 申請 Access Token。
? 任務(wù)分發(fā)
所在地的Agent 向目標(biāo) Agent 以 tasks/sendSubscribe 的方式發(fā)起 Task：
POST /tasks/sendSubscribe HTTP/1.1
Host: mycloud.com
Authorization: Bearer <token>
Content-Type: application/json
{
"task": {
"id": "task-123",
"inputs": { "phoneNumber": "1234567890" },
"metadata": { "operation": "推薦一個長期在外地（安徽）的流量套餐" }
}
}同時訂閱 SSE，獲取實時進(jìn)度與結(jié)果。
? 結(jié)果聚合與回傳
當(dāng) Agent 完成任務(wù)后，按照預(yù)定義的業(yè)務(wù)邏輯生成最終用戶應(yīng)答，并通過原始通道反饋給用戶。
3. 應(yīng)用效果
? 全程自主化：用戶只需一個集成A2A的客戶端比如手機，可以使用文字、語音等說出自己的需求，就能直接獲取結(jié)果，無需考慮切換客服號碼或者切換當(dāng)?shù)靥柎a才能獲取答案。
? 開發(fā)成本降低：無需為每對系統(tǒng)單獨編寫對接代碼，只需遵循 A2A 規(guī)范。
? 可維護(hù)性增強：新增或替換智能體只需更新 Agent Card 與認(rèn)證配置，無需改動主業(yè)務(wù)邏輯。
五、現(xiàn)有智能體如何集成A2A
當(dāng)前A2A支持CrewAI、LangChain、Genkit、Google Agent Development Kit等創(chuàng)建的智能體，下面以LangChain為例，說明如何集成A2A。
1. 定義LangChain實現(xiàn)的智能體
class LangChainAgent:
# ...2. 定義智能體技能
skill = AgentSkill(
id="mycloud",
name="XX云",
descriptinotallow="能夠協(xié)助處理云服務(wù)相關(guān)問題",
tags=["AI秘書", "訂購助手"],
examples=["請問XX服務(wù)有哪些規(guī)格"],
)3. 定義智能體卡表
agent_card = AgentCard(
name="XX云智能體",
descriptinotallow="XX云智能體",
url=f"http://agentcard.mycloud.com/",
versinotallow="1.0.0",
skills=[skill],
)4. 啟動A2A服務(wù)
server = A2AServer(
agent_card=agent_card,
task_manager=AgentTaskManager(agent=LangChainAgent(), notification_sender_auth=notification_sender_auth),
host="mycloud.com"
)
server.app.add_route(
"/.well-known/jwks.json", notification_sender_auth.handle_jwks_endpoint, methods=["GET"]
)六、A2A 的優(yōu)勢與局限性
優(yōu)勢
1.互操作性：打破不同框架的孤島，降低集成成本。
2.企業(yè)級特性：內(nèi)置安全性和長時間任務(wù)支持，適合復(fù)雜場景。
3.社區(qū)驅(qū)動：開源協(xié)議，得到廣泛支持，生態(tài)持續(xù)擴展。
局限性
1.文檔等完善度：當(dāng)前文檔缺乏詳細(xì)的跨供應(yīng)商示例和多模態(tài)處理指南。
2.智能體發(fā)現(xiàn)：盡管目前的智能體通過卡表發(fā)現(xiàn)，但是卡表如何部署、如何確保安全和公信力成為一個亟待解決的問題，Google官方也說明這是一個開放性的問題，可以在社區(qū)討論：如果是中心化部署要考慮大流量和高延時的問題，如果是類似DNS這種分層次的部署，那是否要定義一種新的大家都遵守的卡表發(fā)現(xiàn)協(xié)議？
3.sdk支持較少: 目前僅僅支持python 、js開發(fā)的智能體,并且支持的開源智能體框架也比較少。
七、MCP、Manus 和 A2A 的關(guān)系與互補性
MCP、Manus 和 A2A 代表了 AI 生態(tài)系統(tǒng)中不同層面的創(chuàng)新，都在發(fā)布時就爆火，它們在功能和定位上互補但各有側(cè)重：
MCP（數(shù)據(jù)平面）：專注于模型與工具/數(shù)據(jù)的交互，提供標(biāo)準(zhǔn)化的上下文輸入和輸出接口。
Manus（框架層）：提供多智能體協(xié)作的框架，強調(diào)自主性和任務(wù)編排，但缺乏標(biāo)準(zhǔn)化通信協(xié)議。
A2A（控制平面）：專注于智能體間的通信與協(xié)作，定義了智能體如何發(fā)現(xiàn)、協(xié)商和協(xié)調(diào)任務(wù)。
互補性：
? MCP 為智能體提供訪問外部資源的能力，A2A 則讓智能體能夠相互通信。例如，在一個汽車維修場景中，MCP 允許智能體調(diào)用工具（如“將平臺提升 2 米”），而 A2A 協(xié)調(diào)智能體與客戶的交互（如“發(fā)送左輪照片”）。
? Manus 可以在 MCP 和 A2A 的基礎(chǔ)上運行，利用 MCP 訪問工具，借助 A2A 與其他智能體協(xié)作。
未來一種可能的協(xié)作如圖所示：
總結(jié)
A2A 協(xié)議通過智能體卡表、任務(wù)、消息等核心組件，為 AI 智能體間的通信提供了標(biāo)準(zhǔn)化框架。其基于 HTTP、JSON-RPC 和 SSE 的設(shè)計確保了易用性和兼容性，而企業(yè)級安全性和多模態(tài)支持使其適用于復(fù)雜場景。通過以上詳細(xì)的原理分析和圖示，我們可以看到A2A如何通過能力發(fā)現(xiàn)、任務(wù)管理和實時更新實現(xiàn)高效協(xié)作。盡管仍有一些改進(jìn)空間，A2A 的開源性質(zhì)和廣泛支持為其成為 AI智能體通信的“HTTP”奠定了基礎(chǔ)。
參考文獻(xiàn)
Manus, 2025-03-25
Google A2A, 2025-04-19
??https://google.github.io/A2A/#/??
Teneo.ai, MCP and A2A Protocols Explained, 2025-04-10
??https://www.teneo.ai/blog/mcp-and-a2a-protocols-explained-the-future-of-agentic-ai-is-here??
Koyeb, A2A and MCP: Start of the AI Agent Protocol Wars, 2025-04-11
??https://www.koyeb.com/blog/a2a-and-mcp-start-of-the-ai-agent-protocol-wars??
Blott Studio, MCP vs A2A: Which Protocol Is Better For AI Agents, 2025-04-09
??https://www.blott.studio/blog/post/mcp-vs-a2a-which-protocol-is-better-for-ai-agents??
Saptak Sen, Agent2Agent vs MCP, 2025
??https://saptak.in/writing/2025/04/10/agent2agent-vs-mcp??
Anthropic, Introducing the Model Context Protocol, 2024-11-25
??https://www.anthropic.com/news/model-context-protocol??
Hugging Face, MCP is All You Need, 2025-03-18
??https://huggingface.co/blog/LLMhacker/mcp-is-all-you-need??
VC Cafe, The future of AI tooling is Interoperable, 2025-04-10
??https://www.vccafe.com/2025/04/10/the-future-of-ai-tooling-is-interoperable-mcp-and-agent2agent/??
本文轉(zhuǎn)載自??AI遇見云??，作者：王亞平
