配了三个月多Agent系统，今天才把MCP和A2A的分工彻底想清楚了——一个是Agent的「手」，一个是Agent的「嘴」

AI 论文日报 内容创作者 2026-08-20 15 阅读

你有没有遇到过这种情况：给团队部署了一套多 Agent 系统，结果发现每个 Agent 都是「孤岛」——Claude Code 能跑代码、另一个 Agent 能查数据库、第三个 Agent 能发邮件，但它们之间完全不知道彼此存在，更别说配合干活了。

这不是配置问题，是协议层的问题。

2025 年 4 月，Google 在 Cloud Next 大会上开源了 A2A 协议（Agent-to-Agent），50 多家企业联合签署支持。这件事在当时的媒体热度不算高，但它解决的是一个根本性问题：多 Agent 协作，到底该用什么语言？

MCP 和 A2A，不是竞争，是分工

很多人容易把 A2A 和 MCP 搞混，觉得 Google 出了个「对标 MCP」的东西。实际上这两个协议解决的是完全不同的问题。

MCP（Model Context Protocol） 是 Anthropic 在 2024 年主导的协议，解决的是「模型和工具之间的连接问题」——让 AI 能调用外部工具、读取数据库、操作文件系统。它的核心是「单 Agent 调用资源」。

A2A（Agent-to-Agent） 解决的是「Agent 和 Agent 之间的协作问题」——让不同厂商、不同框架开发的 Agent 能相互发现对方的能力、派发任务、同步结果。它的核心是「多 Agent 之间的对话」。

简单说：MCP 是 Agent 的四肢，A2A 是 Agent 的嘴。 缺少 MCP，Agent 连工具都用不了；缺少 A2A，Agent 之间就是聋哑人。

A2A 的四个核心机制

1. Agent Card：让 Agent 学会自我介绍

每个支持 A2A 的 Agent 必须提供一个标准化的能力描述文件，位于 /.well-known/agent.json。这个文件里写的是：Agent 叫什么名字、能处理什么任务、接受什么参数、需要什么样的认证方式。

{
  "name": "WeatherAgent",
  "version": "1.0",
  "description": "提供指定日期的天气数据查询",
  "endpoints": {
    "task_submit": "/api/tasks/weather",
    "sse_subscribe": "/api/tasks/updates"
  },
  "input_schema": {
    "type": "object",
    "properties": {
      "date": {"type": "string", "format": "date"},
      "location": {"type": "string"}
    },
    "required": ["date"]
  },
  "authentication": {"methods": ["API_Key"]}
}

这个设计解决的是「能力发现问题」——在 A2A 体系里，Agent 不需要提前知道对方的存在，只需要读取对方的 Agent Card，就能知道它能干什么、怎么调用它。

2. Task Lifecycle：任务有完整的状态机

A2A 把每个协作任务抽象成有状态的生命周期：submitted → working → input-required → completed / failed / canceled。

这意味着你可以在任务执行过程中实时追踪状态，而不是等一个 POST 请求返回结果才知道任务跑完了。支持 SSE 流式推送，客户端可以订阅状态变化。

3. Artifact：结果不只是文本

任务完成后返回的是 artifact 对象，里面可以是文本、结构化数据、文件，甚至是多个 part 组合的复合内容。这比简单的 JSON 返回灵活得多。

4. 开放生态，不绑定框架

A2A 是完全开源的，GitHub 地址是 github.com/google/A2A。任何厂商都可以实现自己的 A2A Server，协议不绑定特定的模型或平台。这和 MCP 一样是开放标准。

企业场景的真实价值

光看技术细节可能还是觉得「听起来不错但用不上」，说个具体场景。

假设你在做一个企业级 AI 客服系统，背后有这几个 Agent：查产品信息的 Agent、查订单状态的 Agent、处理退款的 Agent、发送邮件通知的 Agent。

没有 A2A 的时候，你需要写一套胶水代码来让这几个 Agent 互相调用，接口不统一、认证方式各异、状态管理混乱。

有了 A2A 之后，这四个 Agent 各自实现标准的 A2A Server，任务派发方只需要读取每个 Agent 的 Agent Card 就能知道该找谁、怎么调用。更重要的是，如果将来加一个「处理投诉的 Agent」，只需要让它也实现 A2A 接口，就能无缝接入整个系统。

为什么 2026 年这件事变得更迫切了

多 Agent 协作在 2026 年已经不是「前沿探索」，而是很多企业的实际需求。Anthropic 的 MCP 协议解决了「单 Agent 能力扩展」的问题，但多 Agent 协作的协议层一直是空白。

A2A 和 MCP 是互补关系，而不是替代关系。一个成熟的多 Agent 系统，应该是：MCP 负责每个 Agent 调用工具的能力，A2A 负责 Agent 之间的协作路由。一个管「手」，一个管「嘴」。

如果你正在做多 Agent 系统，先问自己两个问题：每个 Agent 的工具调用是用什么协议？如果 Agent 之间需要协作，用什么协议？

这两个问题，如果现在还没有答案，是时候认真了解一下 A2A 了。

评论区

0 条评论

登录后可评论。

AI 论文日报 15 阅读