一、A2A 協議的核心原理

A2A 協議的設計基于五個核心原則，這些原則確保了協議的靈活性、安全性和廣泛適用性。以下是對這些原則的詳細解析，并結合技術機制進行說明。

1. 擁抱智能體特性（Embrace Agentic Capabilities）

A2A 協議專為具有自主性和復雜推理能力的 AI 智能體設計。不同于傳統的工具調用（如 API 或數據庫查詢），A2A 允許智能體以自然、結構化的方式進行協作，而無需共享內存、工具或上下文。這種設計支持智能體在分布式環境中獨立運行，同時保持高效的協作能力。

技術實現：

? 智能體之間的通信通過任務（Task）作為核心工作單元。任務可以是短期的（如生成報告）或長期的（如供應鏈優化）。

? 智能體通過消息（Message）交換信息，消息支持多模態內容（如文本、圖像、視頻），適應復雜場景。 

? 智能體不需要了解彼此的內部實現，只需遵循 A2A 協議的接口規范即可。

2. 基于現有標準（Build on Existing Standards）

A2A 協議利用成熟的 Web 技術，確保與現有 IT 架構的兼容性和易用性。

核心技術包括：

? HTTP/HTTPS：作為主要傳輸協議，生產環境中必須使用 HTTPS 和現代 TLS 加密。

? JSON-RPC 2.0：用于結構化數據交換，確保請求和響應的標準化。 - 服務器發送事件（SSE）：支持實時、單向的流式更新，適用于任務進度通知。

優勢：

? 開發者無需學習新的協議棧，現有工具和庫即可支持 A2A。 

? 企業可以輕松將 A2A 集成到現有的微服務架構中。

3. 默認安全（Secure by Default）

安全性是 A2A 協議的核心考量。協議內置了企業級認證和授權機制，包括： 

? OAuth 和 OpenAPI 認證：確保只有授權的智能體可以通信。

? 數字證書：A2A 服務器通過知名證書頒發機構簽發的證書證明身份。

? 請求追蹤：支持日志和事件隊列，便于監控和審計。

技術實現：

? 智能體卡表（Agent Card）中包含認證要求，客戶端智能體在發起任務前必須完成身份驗證。

? 數據傳輸使用 HTTPS 加密，防止中間人攻擊。

4. 支持長時間運行任務（Support for Long-Running Tasks）

A2A 協議不僅支持簡單的請求-響應交互，還能處理需要數小時或數天的復雜任務。例如，供應鏈優化可能涉及多個智能體的協作，任務狀態需要持續跟蹤。

任務具有唯一 ID 和狀態（如 submitted、working、completed、failed）。通過tasks/sendSubscribe 方法，客戶端可以建立流式連接，接收任務的實時更新。任務狀態通過 SSE 推送，確保客戶端無需輪詢。

5. 模態無關（Modality Agnostic）

A2A 支持多模態通信，智能體可以交換文本、圖像、音頻、視頻或交互式內容（如 Web 表單）。這種設計適應了企業中多樣化的數據需求。

消息中的“結構體（Part）”定義了內容類型，允許智能體協商適合的格式。例如，一個智能體可以返回圖表數據（JSON）或渲染后的圖像，具體取決于客戶端的偏好。

二、A2A 協議的核心組件

A2A 協議的實現依賴于幾個核心組件，這些組件共同構成了智能體間通信的框架。以下是對每個組件的詳細說明。

1. 智能體卡表（Agent Card）

智能體卡表是 A2A 協議的入口點，用于描述智能體的身份和能力。它是一個 JSON 格式的元數據文件，通常托管在智能體的某個確定的路徑下。

結構：

? 身份信息：包括智能體的名稱、版本和托管地址（DNS 或 URL）。

? 能力描述：列出支持的功能（如流式傳輸、推送通知）和技能（Skills）。 

? 認證要求：指定 OAuth、API 密鑰或 OIDC 等認證方式。 

? 端點：提供 API 端點的 URL（如 tasks/send）。

示例（簡化版）：

{
  "name": "XX云服務",
  "version": "1.0.0",
  "endpoint": "https://mycloud.com/a2a",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "skills": ["AI秘書", "訂購助手"],
  "authentication": {
    "type": "OAuth",
    "url": "https://mycloud.com/"
  }
}

作用：

? 能力發現：客戶端智能體通過讀取智能體卡表了解遠程智能體的功能，決定是否發起協作。

? 動態注冊：對于服務端來說，智能體可以在運行時更新其能力，無需重啟會話。

2. 任務（Task）

任務是 A2A 協議的核心工作單元，表示客戶端智能體請求遠程智能體執行的操作。任務具有明確的生命周期和狀態管理。

生命周期：

? 提交（submitted）：任務被客戶端發送到遠程智能體。 

? 工作中（working）：遠程智能體正在處理任務。 

? 需要輸入（input-required）：任務需要額外信息暫停。

? 完成（completed）：任務成功結束，返回工件（Artifact）。

? 失敗（failed）：任務因錯誤終止。

? 取消（canceled）：任務被客戶端取消。

API 方法：

? tasks/send：同步請求，適合快速任務，客戶端等待響應。

? tasks/sendSubscribe：建立流式連接，適合長時間任務，客戶端接收 SSE 更新。

示例請求：

{
  "method": "tasks/send",
  "params": {
    "task": {
      "id": "task-123",
      "description": "請開通XX服務",
      "input": {
        "data": ["XX服務規格：..."]
      }
    }
  },
  "jsonrpc": "2.0",
  "id": 1
}

圖示：

3. 消息（Message）

消息是智能體間通信的基本單位，表示一次交互的“回合”。消息支持多模態內容，并通過“Part”定義具體格式。

結構：

? 角色：user（客戶端智能體）或 agent（遠程智能體）。 

? 內容：包含多個部分（Part），每個部分指定內容類型（如 text/plain、image/png）。

? 元數據：包括消息 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"
}

作用：

? 支持復雜的交互，如同時傳輸文本說明和可視化結果。

? 允許格式協商，例如客戶端請求 JSON 數據而非圖像。

4. 產出層：Artifact 管理

Artifact 是指任務的輸出，通常是文件或結構化數據（如報告、圖像）。工件與消息類似，但專注于任務的最終結果。

示例：

{
  "id": "artifact-789",
  "contentType": "application/pdf",
  "content": "XX服務已經訂購成功",
  "taskId": "task-123"
}

作用：

? 提供標準化的輸出格式，便于客戶端處理。

? 支持大文件傳輸，通過分片或流式傳輸。

5. A2A 服務器與客戶端

? A2A 服務器：實現 A2A 協議的 HTTP 端點，接收任務請求并執行操作。它托管智能體卡表并處理任務生命周期。

? A2A 客戶端：發起任務的智能體或應用，通過 HTTP 請求與服務器交互。

交互流程：

• 客戶端通過智能體卡表發現服務器。
• 客戶端發送任務請求（tasks/send 或tasks/sendSubscribe）。
• 服務器處理任務并返回消息或工件。

三、技術細節

1. JSON Schema

A2A 協議的核心規范通過 JSON Schema 定義（a2a.json），詳細描述了智能體卡表、任務、消息等對象的字段、類型和約束。開發者可以通過 JSON Schema 工具驗證實現是否符合標準。

關鍵字段：

? AgentCard.capabilities：支持的功能，如streaming、pushNotifications。 - Task.state：任務狀態枚舉（submitted、working 等）。

? Message.parts：支持的內容類型（如 text/plain、application/json）。

2. 通信模式

A2A 支持兩種通信模式： 

? 同步模式：通過 tasks/send 實現，適合快速任務。 

? 異步模式：通過 tasks/sendSubscribe 和 SSE 實現，適合長時間任務。

SSE 示例：

GET /tasks/sendSubscribe?taskId=task-123 HTTP/1.1
Host: mycloud.com
Accept: text/event-stream

響應：

event: task-update
data: {"taskId": "task-123", "state": "working"}


event: task-update
data: {"taskId": "task-123", "state": "completed", "artifact": "artifact-789"}

3. 錯誤處理

A2A 定義了標準化的錯誤響應，基于 JSON-RPC 2.0。例如：

{
  "jsonrpc": "2.0",
  "error": {
    "code": 32600,
    "message": "認證失敗"
  },
  "id": 1
}

四、行業案例

以運營商智能客服系統為例，演示 A2A 在通信行業的典型應用流程。

1. 背景

假設運營商在全國多個省部署了智能客服的智能體。用戶在線咨詢時，往往需要跨省調用多方能力，例如：

? 查詢套餐余量（系統 A）

? 推薦個性化增值業務（系統 B）

? 處理投訴工單（系統 C）

2. A2A 集成流程

? 能力注冊

各個?。ū热绨不帐。┑闹悄芸头到y分別發布自己的 Agent到中心節點：

anhui.xxx.com/.well-known/agent.json

jiangsu.xxx.com/.well-known/agent.json

center.xxx.com/.well-known/agent.json

? 發現與認證

主客服 Agent（客戶當前所在地）在接到用戶請求后，通過 HTTP GET 向中心節點拉取各 Agent Card，篩選出客戶號碼所在地的智能體地址。同時，使用 OAuth2 向目標 Agent 申請 Access Token。

? 任務分發

所在地的Agent 向目標 Agent 以 tasks/sendSubscribe 的方式發起 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，獲取實時進度與結果。

? 結果聚合與回傳

當 Agent 完成任務后，按照預定義的業務邏輯生成最終用戶應答，并通過原始通道反饋給用戶。

3. 應用效果

? 全程自主化：用戶只需一個集成A2A的客戶端比如手機，可以使用文字、語音等說出自己的需求，就能直接獲取結果，無需考慮切換客服號碼或者切換當地號碼才能獲取答案。

? 開發成本降低：無需為每對系統單獨編寫對接代碼，只需遵循 A2A 規范。

? 可維護性增強：新增或替換智能體只需更新 Agent Card 與認證配置，無需改動主業務邏輯。

五、現有智能體如何集成A2A

當前A2A支持CrewAI、LangChain、Genkit、Google Agent Development Kit等創建的智能體，下面以LangChain為例，說明如何集成A2A。

1. 定義LangChain實現的智能體

class LangChainAgent:
  # ...

2. 定義智能體技能

skill = AgentSkill(
            id="mycloud",
            name="XX云",
            descriptinotallow="能夠協助處理云服務相關問題",
            tags=["AI秘書", "訂購助手"],
            examples=["請問XX服務有哪些規格"],
        )

3. 定義智能體卡表

agent_card = AgentCard(
            name="XX云智能體",
            descriptinotallow="XX云智能體",
            url=f"http://agentcard.mycloud.com/",
            versinotallow="1.0.0",
            skills=[skill],
        )

4. 啟動A2A服務

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 的優勢與局限性

優勢

1.互操作性：打破不同框架的孤島，降低集成成本。

2.企業級特性：內置安全性和長時間任務支持，適合復雜場景。

3.社區驅動：開源協議，得到廣泛支持，生態持續擴展。

局限性

1.文檔等完善度：當前文檔缺乏詳細的跨供應商示例和多模態處理指南。

2.智能體發現：盡管目前的智能體通過卡表發現，但是卡表如何部署、如何確保安全和公信力成為一個亟待解決的問題，Google官方也說明這是一個開放性的問題，可以在社區討論：如果是中心化部署要考慮大流量和高延時的問題，如果是類似DNS這種分層次的部署，那是否要定義一種新的大家都遵守的卡表發現協議？

3.sdk支持較少: 目前僅僅支持python 、js開發的智能體,并且支持的開源智能體框架也比較少。

七、MCP、Manus 和 A2A 的關系與互補性

MCP、Manus 和 A2A 代表了 AI 生態系統中不同層面的創新，都在發布時就爆火，它們在功能和定位上互補但各有側重： 

MCP（數據平面）：專注于模型與工具/數據的交互，提供標準化的上下文輸入和輸出接口。

Manus（框架層）：提供多智能體協作的框架，強調自主性和任務編排，但缺乏標準化通信協議。

A2A（控制平面）：專注于智能體間的通信與協作，定義了智能體如何發現、協商和協調任務。

互補性：

? MCP 為智能體提供訪問外部資源的能力，A2A 則讓智能體能夠相互通信。例如，在一個汽車維修場景中，MCP 允許智能體調用工具（如“將平臺提升 2 米”），而 A2A 協調智能體與客戶的交互（如“發送左輪照片”）。

? Manus 可以在 MCP 和 A2A 的基礎上運行，利用 MCP 訪問工具，借助 A2A 與其他智能體協作。

未來一種可能的協作如圖所示：

總結

A2A 協議通過智能體卡表、任務、消息等核心組件，為 AI 智能體間的通信提供了標準化框架。其基于 HTTP、JSON-RPC 和 SSE 的設計確保了易用性和兼容性，而企業級安全性和多模態支持使其適用于復雜場景。通過以上詳細的原理分析和圖示，我們可以看到A2A如何通過能力發現、任務管理和實時更新實現高效協作。盡管仍有一些改進空間，A2A 的開源性質和廣泛支持為其成為 AI智能體通信的“HTTP”奠定了基礎。

參考文獻

Manus, 2025-03-25

??https://manus.monica.cn/??

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/??

本文轉載自??AI遇見云??，作者：王亞平