A2A协议深度解析｜Agent2Agent通信标准，智能体互联网的"HTTP"

当你的 LangGraph Agent 要和另一个 CrewAI Agent 协作，当你的客服 Agent 需要把计费问题交给第三方财务 Agent------ 谁来定义它们之间怎么对话、怎么分发任务、怎么实时同步进度？Google 联合 50+ 厂商在 2025 年 4 月给出的标准化答案：A2A（Agent2Agent）协议。发布仅两个月，该协议便完整捐赠至 Linux 基金会；到 2026 年 4 月发布满一周年时，项目收获 22000+ GitHub Stars，落地覆盖 150 + 企业生产组织。本文系统拆解 A2A 的底层设计哲学、三大核心构件与企业级工程落地实践。

一、为什么需要 A2A：多 Agent 协作的"巴别塔困境"

2024-2025 年，LLM 驱动的 AI Agent 从单兵作战走向集群协作。但一个尴尬的局面摆在了开发者面前：不同框架构建的 Agent 之间，没有统一的"对话协议"。

想象一下这个场景：你用 LangGraph 搭了一个客服编排 Agent，它需要调用一个用 CrewAI 写的财务分析 Agent，还要对接一个第三方 SaaS 提供的 CRM Agent。在 A2A 出现之前，你只能手写定制适配层------把 Agent B 封装成一个 Tool 暴露给 Agent A。但这本质上把 Agent 降级成了无状态的函数调用，完全丢失了自主推理、多轮协商和长期任务管理的能力。

业界将这种困境总结为"巴别塔困境"：

问题	具体表现
无统一发现机制	Agent A 不知道 Agent B 能做什么、怎么调用
协议碎片化	LangChain Agent 无法原生与 AutoGen Agent 通信
安全边界模糊	跨 Agent 调用缺乏统一身份认证和权限模型
状态传递混乱	长任务的中间状态没有标准格式传递
人机协作缺失	Agent 不知道什么时候该停下来等人工确认

💡 核心洞察：这和 2000 年代初 Web Service 的混乱状态如出一辙------直到 HTTP + REST 成为事实标准。A2A 要做的就是 AI Agent 时代的"HTTP"。

二、A2A 在技术栈中的定位：不是取代 MCP，而是互补

很多同学一上来就会问："A2A 和 MCP 是什么关系？选哪个？"

答案是：两个都选，它们解决的是不同层次的问题。

flowchart TD subgraph BizOrchestrator["业务编排层"] direction LR Orchestrator["Orchestrator Agent"] WorkflowEngine["Workflow Engine"] end subgraph A2ALayer["A2A 协议层"] direction LR AgentDiscovery["Agent 发现"] TaskDelegation["任务委派"] StateSync["状态同步"] end subgraph MCPAgentLayer["MCP 工具层 & Agent 运行时"] direction LR subgraph MCPTools["MCP 工具层"] Tools["Tools/Resources"] end subgraph AgentRuntime["Agent 运行时"] LangGraph["LangGraph"] CrewAI["CrewAI"] Custom["自研框架"] end end subgraph LLMLayer["LLM 推理层"] direction LR GPT4o["GPT-4o"] Claude["Claude"] Gemini["Gemini"] end BizOrchestrator --> A2ALayer A2ALayer --> MCPAgentLayer MCPAgentLayer --> LLMLayer

维度	A2A	MCP
连接对象	Agent ↔ Agent	Agent ↔ 工具/资源
交互特征	多轮、有状态、协商式	单次调用、无状态、结构化
典型场景	客服 Agent 委托计费 Agent 处理退款	Agent 调用数据库查订单
设计哲学	Agent 是自主的协作伙伴	工具是被调用的能力原语

一句话总结：MCP 解决 Agent 怎么用工具和数据，A2A 解决 Agent 怎么和其他 Agent 协作。一个 Agent 可以同时用 MCP 调工具、用 A2A 和其他 Agent 组队。

⚠️ 踩坑提醒：别想着跳过 MCP 直接上 A2A------你会得到一群能互相聊天但对内部数据一无所知的 Agent。

三、核心角色模型：三个角色，一个原则

arduino 复制代码

User（终端用户：人类操作者或自动化服务）
 │
 ▼ 发起请求
A2A Client（客户端 Agent：代表用户发起通信）
 │
 ▼ A2A 协议通信（HTTP/JSON-RPC 2.0）
A2A Server（远程 Agent：实现 A2A 协议的 HTTP 端点）

A2A 协议的核心原则之一是不透明性（Opaque） ：客户端无需、也不会了解远程 Agent 的内部实现、记忆状态或工具集合。你只需要知道它能不能干这个活、怎么调用它。

这种设计精妙之处在于------它既保护了 Agent 提供方的知识产权（我的 Agent 内部怎么实现的你不需要知道），又天然契合了标准的 C/S 安全范式。类比一下：你用 REST API 调支付宝支付接口，需要知道支付宝内部怎么记账的吗？不需要。

四、五大基本构件：一张图看懂数据结构

A2A 围绕五个核心数据结构组织所有通信：

4.1 Agent Card ------ Agent 的"数字名片"

每个 A2A 兼容的 Agent 都要在 https://{domain}/.well-known/agent.json 托管一份 JSON 格式的能力声明。客户端通过读取它来决策"该不该找这个 Agent 干活"。

json 复制代码

{
  "name": "财务分析 Agent",
  "description": "专业财务数据分析，支持财报解读、风险评估",
  "url": "https://finance-agent.example.com",
  "version": "1.2.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "stateTransitionHistory": true
  },
  "skills": [
    {
      "id": "financial-report-analysis",
      "name": "财务报表分析",
      "description": "解读年报、季报，提取关键财务指标",
      "tags": ["finance", "analysis"],
      "examples": ["分析某公司2025年Q4财报的盈利能力趋势"],
      "inputModes": ["text", "file"],
      "outputModes": ["text", "data"]
    }
  ],
  "authentication": {
    "schemes": ["Bearer"]
  }
}

⚠️ 踩坑提醒：Agent Card 里声明的技能要精确克制。我看过有些团队把能做的和不能做的全塞进去，结果客户端匹配时会频繁误召。建议按"最小技能声明"原则来写。

4.2 Task ------ 有状态的工作单元

Task 是 A2A 最核心的概念，它代表一项需要跟踪的工作，拥有完整的状态机：

stateDiagram-v2 direction TB SUBMITTED: SUBMITTED（已提交） WORKING: WORKING（执行中） INPUT_REQUIRED: INPUT_REQUIRED（待补充输入） COMPLETED: COMPLETED（完成·终态） FAILED: FAILED（失败·终态） CANCELED: CANCELED（取消·终态） SUBMITTED --> WORKING WORKING --> INPUT_REQUIRED INPUT_REQUIRED --> WORKING WORKING --> COMPLETED WORKING --> FAILED WORKING --> CANCELED

Task 不可变性原则：一旦 Task 进入终态（COMPLETED / FAILED / CANCELED），就不可重启。想修改结果？在同一会话下创建新 Task 并引用原 Task ID。

4.3 Message ------ 通信的基本单位

每次对话都是一条 Message，包含角色（user/agent）、唯一 ID 和 Parts 内容列表。

4.4 Part ------ 内容的原子容器

Part 是 A2A 实现模态无关性的关键：

类型	说明	典型场景
`text`	纯文本	自然语言对话
`file`	二进制文件（Base64/URL）	PDF 财报、图片
`data`	结构化 JSON	数据库查询结果
`url`	外部 URI	大文件引用

json 复制代码

{
  "role": "user",
  "parts": [
    { "type": "text", "text": "请分析这份财报的盈利能力" },
    { "type": "file", "mimeType": "application/pdf",
      "url": "https://.../report.pdf", "name": "Q4_2025.pdf" }
  ]
}

4.5 Artifact ------ Task 的产出物

Artifact 和 Message 的区别是什么？Message 是沟通过程，Artifact 是正式交付物。Agent 完成 Task 后产出的报告、代码、数据，都以 Artifact 形式呈现。

五、三种交互模式：短任务用同步，长任务用流式，超长任务用推送

A2A 设计了三种交互模式来覆盖不同场景：

5.1 同步请求/响应（轮询）

最基础的交互。客户端调 tasks/send，服务端返回结果。对于长时间任务，客户端轮询 tasks/getTask。

适用：简单的即时交互，耗时 < 5s 的任务。

5.2 SSE 流式传输（推荐）

客户端调 tasks/sendSubscribe，服务端通过 Server-Sent Events 实时推送：

sequenceDiagram participant Client participant RemoteAgent as Remote Agent Client->>RemoteAgent: POST /tasks/sendSubscribe Note over Client,RemoteAgent: 建立SSE长连接 loop 实时流式推送 RemoteAgent-->>Client: event: TaskStatusUpdateEvent<br/>data: {"state": "working"} RemoteAgent-->>Client: event: TaskArtifactUpdateEvent<br/>data: {chunk 1 of report} RemoteAgent-->>Client: event: TaskArtifactUpdateEvent<br/>data: {chunk 2 of report} end RemoteAgent-->>Client: event: TaskStatusUpdateEvent<br/>data: {"state": "completed"} Client-xRemoteAgent: 连接关闭

5.3 Push 推送通知

针对分钟甚至小时级别的超长任务，客户端提供 Webhook 地址，服务端在状态变更时主动回调。

⚠️ 踩坑提醒：Push 通知的安全验证很容易被忽略。服务端要防止 SSRF（验证 Webhook URL），客户端要验证推送来源（JWT 签名 + 时间戳 + Nonce 防重放）。

六、Agent 发现：三种方式，按需选择

方式	路径	适用场景
Well-Known URI	`https://domain/.well-known/agent.json`	公开 Agent、域内发现
注册中心	中央 Catalog 服务	企业级集中治理
直接配置	硬编码 / 环境变量	开发测试、私有 Agent

生产环境推荐 Well-Known URI + 注册中心组合------公开 Agent 用标准路径自发现，内部 Agent 走注册中心统一管理。

七、A2A 的关键设计决策（面试/架构评审高频考点）

决策一：Task ID 由 Client 生成，而非 Server

为什么？因为 Client 需要在网络重试时做幂等校验------同一个 ID 发两次，Server 不会重复执行。代价是 Client 要保证 ID 全局唯一（UUID v4 是标配）。

决策二：Artifacts 和 Messages 分离

过程通信（Messages）和任务产出（Artifacts）是两个独立字段。Messages 需要顺序展示给用户看，Artifacts 需要被引用和下载。分离之后，你可以对 Artifact 做增量流式传输（lastChunk: false 表示还有后续分块）。

决策三：用 JSON-RPC 2.0 而非 REST

REST 的 HTTP 方法语义在 Agent 场景下容易混淆（取消一个 Task 用 DELETE 还是 POST？）。JSON-RPC 的 method 参数语义更清晰，id 字段天然支持请求-响应匹配，适合异步场景。

八、工程实战：用 Python SDK 接入 A2A

A2A 官方提供 Python/JavaScript/Java/Go/.NET 五套 SDK。下面是 Python 的快速接入示例。

8.1 暴露你的 Agent 为 A2A Server

python 复制代码

from google.adk.a2a import to_a2a
from your_agent_module import root_agent

# 一行代码将 ADK Agent 转换为 A2A 兼容服务
a2a_app = to_a2a(root_agent, port=8001)
# a2a_app 自动托管 Agent Card 到 /.well-known/agent.json

8.2 消费远程 A2A Agent

python 复制代码

from google.adk.a2a import RemoteA2aAgent

# 通过 Agent Card URL 发现并连接远程 Agent
billing_agent = RemoteA2aAgent(
    name="billing_agent",
    description="账单处理专家",
    agent_card="https://billing.example.com/.well-known/agent.json",
)

# 现在 billing_agent 就像本地 Agent 一样可以直接调用
result = root_agent.invoke_async("查一下订单 #12345 的退款状态", billing_agent)

九、企业级特性：不只是协议，更是治理框架

A2A 从一开始就把企业级需求内建在协议设计中，不是事后补丁：

传输安全：生产环境强制 HTTPS，推荐 TLS 1.2+
认证方案：API Key / OAuth 2.0 / OpenID Connect / mTLS
细粒度授权：按技能粒度控制访问权限
可观测性 ：支持 OpenTelemetry 分布式追踪，每个 Task 都记录 taskId + contextId
扩展机制：通过 Extension 体系支持领域定制，不破坏核心规范

十、A2A 的 2026 生态现状

截至 2026 年 6 月，A2A 已经走过从提案到生产的关键一年：

2025.04.09：Google Cloud Next 上首次发布
2025.06：捐赠给 Linux 基金会，AWS、Microsoft、Cisco、Salesforce、SAP 等成为创始成员
2026.03：v1.0 稳定版发布 + v1.2 引入签名 Agent Card
2026.04：GitHub Stars 突破 22,000，150+ 生产组织
当前：Microsoft Copilot Studio / Azure AI Foundry、AWS Bedrock AgentCore 均已原生集成

Google 同时在 A2A 之上构建了 AP2（Agent Payments Protocol），与 Mastercard、PayPal、American Express 合作，让 Agent 能在授权范围内自主执行交易。

总结

A2A 协议不是"又一个新标准"，它是多 Agent 协作时代的基础设施。它的核心设计哲学可以归结为三句话：

Agent 是自主的协作伙伴，不是被调用的工具------所以它设计了有状态的 Task、多轮协商的 Message、模态无关的 Part
不透明协作优于透明耦合------所以 Agent 之间不需要暴露内部实现，通过 Agent Card 和能力声明就够了
企业就绪的协议才是好协议------所以安全、可观测性、扩展机制从一开始就被内建

如果你是正在搭建多 Agent 系统的开发者，建议先从 MCP 入手让 Agent 具备工具能力，再引入 A2A 打通跨 Agent 协作。先 Audit 目前用定制 API 或者人工中转的跨 Agent 流程，这些就是上 A2A 的第一批候选。

技术选型没有银弹，但有了 HTTP 才有了互联网。A2A 能不能成为"智能体互联网的 HTTP"，时间会给出答案。