Agent2Agent协议

官方地址

• A2A 不是一个 Agent 框架。
• 它也不是 MCP 的替代品。
• 它本质上是一个“让 Agent 与 Agent 之间可以标准化通信”的开放协议。

如果只用一句话来概括：

MCP 解决的是 Agent 怎么调用工具，A2A 解决的是 Agent 怎么和另一个 Agent 协作。

一、A2A 到底是什么？

A2A，全称 Agent2Agent Protocol。

你可以把它理解成：

一个让不同 Agent 系统之间可以互相发现、互相调用、互相协作的通信协议。

注意，它强调的是 协议，不是框架。

也就是说，A2A 并不关心你的 Agent 是用什么写的：

• 你可以用 Python
• 也可以用 Java、Go、Node.js
• 你可以基于 LangGraph
• 也可以基于 AutoGen、CrewAI
• 甚至你是公司内部自己写的一套 Agent 系统，也没关系

只要你遵守 A2A 的协议格式，对外暴露标准能力，别的 Agent 就能用统一方式和你通信。

这件事的重要性在于：

今天很多团队都在做 Agent，但几乎每个 Agent 系统都是“孤岛”。

• 接口不统一
• 返回格式不统一
• 能力声明不统一
• 长任务处理方式不统一
• 流式输出方式也不统一

结果就是：
你做了很多 Agent，但它们彼此并不好协作。

A2A 想解决的，就是这个问题。

二、A2A 不是 MCP，它们解决的问题不一样

这是最容易混淆的地方。

很多人第一次看到 A2A，都喜欢把它和 MCP 放在一起比较。
但实际上，这两个东西压根不是一个层次。

MCP 是干什么的？

MCP 更偏向：

Agent 如何调用工具、资源、外部系统

比如：

• 调数据库
• 读文件
• 调浏览器
• 执行 Python
• 调内部 API
• 访问知识库

这些事情，本质上都是 Agent -> Tool / Resource。

A2A 是干什么的？

A2A 更偏向：

Agent 如何把任务交给另一个 Agent

比如：

• 主调度 Agent 发现 HR Agent 更适合处理请假问题
• 财务 Agent 发现报销分析需要交给数据分析 Agent
• 企业助理 Agent 把 IT 故障转给 IT Support Agent
• 一个 SaaS Agent 调另一个第三方专业 Agent

这些事情，本质上是 Agent -> Agent。

最简单的一句话区分

你可以这么记：

• MCP：我怎么使用工具
• A2A：我怎么使用另一个 Agent

所以它们其实是互补关系，不是替代关系。

非常典型的一种未来架构就是：

• Agent 内部通过 MCP 使用工具
• Agent 外部通过 A2A 和其他 Agent 协作

这个组合其实非常自然。

三、为什么 A2A 会重要？

因为未来真正有价值的，不会只是“单个 Agent 很聪明”，而是：

多个专业 Agent 可以组成协同网络。

举个例子。

假设你做了一个企业办公助手，它本身能处理很多事情：

• 查年假余额
• 查报销进度
• 提 IT 工单
• 搜知识库
• 总结会议纪要

再假设你公司里还有别的 Agent：

• HR Agent
• 财务 Agent
• IT Support Agent
• 数据分析 Agent
• 会议纪要 Agent

如果没有 A2A，你往往只能：

• 把所有能力硬塞进一个超级大 Agent
• 或者手写很多内部 RPC / HTTP 接口
• 每个系统都自己定义一套调用格式

时间一长，系统会越来越乱。

而有了 A2A 之后，理论上就能变成：

• 主 Agent 先发现有哪些 Agent 可用
• 再读取它们的能力说明
• 决定把任务交给谁
• 统一接收结果、状态、流式更新

这样，整个 Agent 生态才有“互联互通”的可能。

四、A2A 的核心思想：把 Agent 当成独立服务

这是理解 A2A 的关键。

A2A 并不是把另一个 Agent 当成一个“函数”或者一个“工具调用”。

它更像是把对方当成一个：

独立运行、内部实现可不透明、但能通过标准协议协作的智能体服务

这点非常重要。

因为现实里很多 Agent 系统并不是你自己写的：

• 可能是其他团队维护的
• 可能是别的语言实现的
• 可能是第三方平台提供的
• 甚至可能是一个黑盒 SaaS Agent

A2A 不要求你知道对方内部怎么工作。
你只需要知道：

• 它是谁
• 它会什么
• 它怎么接收任务
• 它怎么返回结果

这就够了。

这也是为什么我认为 A2A 更像是 “Agent 时代的服务协作协议”。

五、A2A 里的几个核心概念

如果你刚开始接触 A2A，最需要搞明白的有 4 个概念。

1）Agent Card

AgentCard 可以理解成这个 Agent 的“名片”。

它是对外暴露的一份描述信息，通常会包含：

• Agent 名称
• 描述
• 服务地址
• 版本
• 支持的输入输出模式
• 支持的能力
• 支持的技能列表
• 是否支持流式
• 是否有认证要求

也就是说，别的 Agent 或客户端，在调用你之前，往往会先拿到你的 AgentCard，看看你到底能干什么。

所以你可以把 AgentCard 理解成：

整个 Agent 的对外说明书

2）AgentSkill

AgentSkill 是很多人一开始最容易误解的地方。

很多人会问：

“如果我内部有十几个 skill，是不是都得一个个定义？”

答案是：

不用。

因为 A2A 里的 AgentSkill，不是你内部每个函数、每个工具、每个子流程的逐一映射。

它更像是：

你对外公开的能力目录

比如一个办公助手内部可能有十几个具体能力：

• 查年假
• 提请假
• 查报销
• 提报销
• 创建 IT 工单
• 查询 IT 工单
• 查知识库
• 总结会议纪要
• 开在职证明
• 查组织架构

但对外完全可以只定义 4 个 AgentSkill：

• hr_services
• expense_services
• it_support
• knowledge_assistant

这才是更合理的建模方式。

换句话说：

内部 skill 是实现细节，A2A 的 AgentSkill 是对外能力标签。

3）Message

如果一次请求可以很快完成，那通常用 Message。

比如：

• “我还有几天年假？”
• “VPN 连不上，帮我提个工单”
• “帮我总结下这段文字”

这种场景下，A2A 交互很像一次普通消息请求：
发出去，处理完，回一个结果。

4）Task

如果一件事不会马上完成，而是一个可跟踪的长任务，那就更适合用 Task。

比如：

• 生成一份 30 天报销分析报告
• 整理大量会议纪要
• 创建审批流并等待后续结果
• 发起 IT 任务并异步跟踪状态

这时服务端可以先返回一个 Task，再通过状态查询、流式事件或者通知机制，持续把进展告诉调用方。

所以你也可以把它理解为：

• Message：一次性回复
• Task：可持续跟踪的工作单

六、A2A 的数据交互到底长什么样？

A2A 的数据交互，本质上就是：

结构化 JSON

举个最简单的例子。

假设另一个 Agent 想请求你的办公助手：

“VPN 连不上，帮我创建一个 IT 工单”

请求体大概会像这样：

{
  "jsonrpc": "2.0",
  "id": "req-001",
  "method": "message/send",
  "params": {
    "message": {
      "messageId": "msg-001",
      "role": "user",
      "parts": [
        {
          "kind": "text",
          "text": "VPN 连不上，帮我创建一个 IT 工单"
        }
      ]
    }
  }
}

如果你的 Agent 很快处理完成，返回可能就是：

{
  "jsonrpc": "2.0",
  "id": "req-001",
  "result": {
    "message": {
      "messageId": "msg-002",
      "role": "agent",
      "parts": [
        {
          "kind": "text",
          "text": "已为你创建 IT 工单：IT-2026-0008。"
        }
      ]
    }
  }
}

你会发现，它本质上还是 JSON。

七、如果我已经有一个在线运行的 Agent，怎么接入 A2A？

这是非常现实的问题。

很多人会担心：

“难道我要把整个 Agent 重写一遍吗？”

其实完全没必要。

最快的方式通常不是重写，而是：

在你原有 Agent 前面，加一层很薄的 A2A Adapter

也就是：

• 原来的办公 Agent 继续照常运行
• 新增一个 A2A 适配层
• 对外说 A2A 协议
• 对内继续调你原来的 Agent API

架构上就会变成这样：

A2A Client / 其他 Agent
    -> A2A Adapter
        -> 你现有的办公 Agent
            -> 内部工具 / MCP / 数据库 / 工作流

这层适配器通常只要做几件事：

1. 定义一个 AgentCard
2. 定义几个高层 AgentSkill
3. 写一个 AgentExecutor
4. 在 execute() 里把请求转发到你原有 Agent

这就是最现实、改造成本最低的方案。