A2a Mcp-生态 Agent

A2A 协议深度解析：为什么说它是 AI Agent 时代的 HTTP

A2A 协议解决了 AI Agent 之间互不相通的难题。本文从核心概念到与 MCP 的互补关系，用技术类比帮你快速理解这个 Agent 互联网的基础协议。

引子：Agent 世界的「巴别塔」

现在的 AI Agent 生态，像极了没有统一语言的巴别塔——LangGraph 说一种方言，CrewAI 说另一种，AutoGen 又是第三种。框架越来越多，Agent 之间却互不相通。

每对 Agent 想要协作，就得写定制胶水代码。5 个 Agent 需要 10 对集成，10 个 Agent 需要 45 对——N² 的复杂度，根本不靠谱。

Google 在 2025 年 4 月 Cloud Next 大会上发布了 A2A（Agent-to-Agent）协议，干的就是这件事：给 Agent 世界定一个统一通信标准。

先说结论：A2A 不是又一个炫技协议，它是 Agent 互联网的基础设施层。就像 HTTP 之于 Web——你不需要每天手写 HTTP 请求，但它无处不在。A2A + MCP 将成为所有多 Agent 系统的标准配置，一个管 Agent 间通信，一个管 Agent 与工具连接。

第一章：为什么需要 A2A？

N² 的集成噩梦只是表象，更深层的问题是：每个框架都在用自己的方式定义「Agent 是什么」「怎么找到另一个 Agent」「任务怎么流转」。

类比互联网早期：每个网络有自己的协议栈，跨网通信需要专门的网关。直到 TCP/IP 一统天下，才有了真正的互联网。A2A 想做的事一模一样——给 Agent 定义一套通用的「TCP/IP」。

A2A 的核心主张很简洁：

  • Agent 之间不需要暴露内部实现（不共享 memory、不共享 tools）
  • 只需要暴露能力描述和标准接口
  • 任何框架构建的 Agent 都能发现彼此、协商交互方式、协作完成任务

这套思路被 Linux Foundation 采纳，现在以 Apache 2.0 开源在 a2aproject/A2A，GitHub 上已超过 24,000 Stars。

第二章：三个核心概念

A2A 只围绕三个原语构建，极简但够用。

Agent Card——Agent 的 DNS + 名片

每个 A2A Agent 在 /.well-known/agent.json 路径下暴露一个 JSON 文件，描述自己的能力、端点、认证方式。

这东西本质就是 Agent 的 DNS 记录 + 数字名片合体：别人不需要知道你内部怎么实现，看你的 Agent Card 就知道你能干什么、怎么连你。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

{
  "name": "ticket-agent",
  "description": "企业 IT 工单管理智能体",
  "url": "https://ticket.example.com/a2a",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "skills": [
    {
      "name": "create_ticket",
      "description": "创建 IT 工单"
    },
    {
      "name": "query_tickets",
      "description": "查询工单状态"
    }
  ],
  "authentication": {
    "schemes": ["bearer"]
  }
}

v1.0 规范引入了签名 Agent Card——用密码学签名验证域名所有权。别人拿到你的 Agent Card 时，可以验证它确实是你签发的，不是被中间人篡改过的。

Task——协作的基本单位

A2A 用 Task 来组织一次协作交互。Task 有明确的生命周期：

1
2
3

submitted → working → input-required → completed
                                       → failed
                                       → canceled

重点是三种执行模式：

模式适用场景特点
同步简单查询、秒级响应一问一答，立即返回
异步数据分析、长耗时任务提交后轮询或推送通知，支持运行数小时
流式实时生成、代码编写SSE 推送中间结果，边算边看

异步模式是生产环境的关键——一个数据清洗 Agent 处理百万行数据，可能跑 30 分钟，A2A 通过 push notification 机制让调用方不用傻等。

Transport——JSON-RPC 2.0 + SSE

传输层选了 JSON-RPC 2.0 over HTTPS，流式场景用 SSE（Server-Sent Events）。

为什么不选 gRPC 或 WebSocket？因为 JSON-RPC 2.0 够简单、够通用、HTTP 原生兼容。A2A 追求的是最大范围采纳，不是追求极致性能——这和 HTTP 当年的设计哲学一致。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# 伪代码：一个 A2A 调用的基本流程
import requests

# 1. 获取对方的 Agent Card
card = requests.get("https://ticket.example.com/.well-known/agent.json").json()

# 2. 发送 Task 请求
response = requests.post(card["url"], json={
    "jsonrpc": "2.0",
    "method": "tasks/send",
    "params": {
        "task": {
            "id": "task-001",
            "message": {
                "role": "user",
                "parts": [{"text": "帮我查一下 REQ12312 的状态"}]
            }
        }
    },
    "id": 1
})

整个交互就三步：发现（拿 Agent Card）→ 发起（创建 Task）→ 跟进（获取结果或接收推送）。

第三章：A2A vs MCP——不是替代，是两条腿

一句话定义：

  • MCP 是 Agent 的 USB——连接工具（数据库、API、文件系统）
  • A2A 是 Agent 的 HTTP——连接其他 Agent
维度MCPA2A
定位Agent ↔ 工具连接Agent ↔ Agent 协作
通信对象工具/资源/提示词其他智能体
核心抽象Tool / Resource / PromptAgent Card / Task
状态管理无状态（调用即返回）有状态（Task 生命周期）
安全模型本地进程信任网络级认证 + 签名
治理Anthropic → 社区开放Linux Foundation

三个常见误区必须澄清：

  1. 「A2A 会取代 MCP」→ 错。它们互补。一个 Agent 通过 MCP 调用数据库查询工具，同时通过 A2A 和另一个 Agent 协作完成跨部门流程。
  2. 「MCP 只能调工具」→ 不完全对。MCP 也能做简单通信，但它不管理 Task 生命周期，不适合长时间协作。
  3. 「A2A 更先进」→ 只是定位不同。MCP 解决「Agent 如何使用工具」，A2A 解决「Agent 之间如何协作」，都是基础设施层。

一个典型的企业级架构是这样的：

1
2
3
4
5
6
7
8
9

┌─────────────┐    A2A     ┌─────────────┐
│  HR Agent   │◄──────────►│  IT Agent   │
│  (LangGraph)│            │  (Google ADK)│
└──────┬──────┘            └──────┬──────┘
       │ MCP                      │ MCP
       ▼                          ▼
┌─────────────┐            ┌─────────────┐
│  HR 数据库   │            │  工单系统    │
└─────────────┘            └─────────────┘

HR Agent 通过 MCP 访问 HR 数据库，通过 A2A 和 IT Agent 协作完成「新员工入职」这个跨部门任务。

第四章：生态版图

A2A 的采纳速度超出预期。截止 2026 年 4 月：

  • 24,000+ GitHub Stars（a2aproject/A2A），Apache 2.0 开源
  • 6 种官方 SDK：Python、JavaScript、Go、Java、.NET、Rust
  • 框架原生支持：Google ADK、LangGraph、CrewAI、LlamaIndex、Semantic Kernel、AutoGen、BeeAI
  • 企业采纳：Salesforce Agentforce、SAP Joule、ServiceNow Now Assist 等已集成

DeepLearning.AI 也上线了官方 A2A 短课程，由 Google Cloud 和 IBM Research 联合出品。

IBM 的 BeeAI 框架深度参与了 A2A 生态共建，社区层面的协议融合一直在推进——从竞争走向统一是 Agent 生态的必然方向。

第五章：未来方向

A2A 规范仍在快速演进，几个值得关注的方向：

签名 Agent Card（已落地）： 密码学签名验证域名归属，解决企业级信任问题。这是生产部署的前置条件。

Agent Directory（规划中）： 从「我知道你在哪」进化到「我能发现你」。类似 DNS 服务发现机制，让 Agent 能在一个注册中心里搜索和发现其他 Agent 的能力。

动态能力协商： 支持 Agent 在任务执行过程中动态添加新的交互方式（比如从文本切换到音视频）。

Rust SDK 加入： 第六种官方 SDK，覆盖系统级高性能场景。

第六章：对我们意味着什么？

个人开发者： 现在可以构建跨框架的多 Agent 系统了。用 LangGraph 做编排 Agent，用 Google ADK 做执行 Agent，通过 A2A 通信，不再被单一框架锁定。入门门槛就是 pip install a2a-sdk。

企业： A2A 让不同部门、不同技术栈的 Agent 可以互操作。IT 部门用 Java 构建的运维 Agent 和业务部门用 Python 构建的分析 Agent，通过 A2A 标准协议就能协作。IT 采购不用再纠结选哪个框架。

落地方案： 如果你已经在用 MCP（连接工具），那你已经走了一半。下一步是在需要多 Agent 协作的场景引入 A2A。从两个 Agent 的简单协作开始，验证流程跑通后再扩展。

结尾

Agent 世界的「巴别塔」正在被拆解。A2A 不是技术炫技，是基础设施——就像 HTTP 一样，你可能不会每天直接写 A2A 调用，但它会成为多 Agent 系统的默认通信层。

A2A + MCP 的组合，就是 Agent 时代的 HTTP + USB：一个管 Agent 间通信，一个管工具连接。两者互补，缺一不可。

你已经在用 MCP 了吗？准备试试 A2A 做多 Agent 协作吗？评论区聊聊你的场景。