A2A 介绍：概念篇

在之前的文章中介绍过 MCP：《MCP 和 Function Calling：概念》和《MCP 和 Function Calling：示例》。

谷歌 2025 年 4 月 9 日发布了 A2A 协议，下面是最近学习的总结。

先理解几个概念

首先理解几个概念：智能体（AI Agent）、工具、大模型。下面用一个实际的场景来解释。

我们让 AI 规划一个十一旅游的行程，AI 进行思考、判断、最终做出决策，需要先去了解十一的天气怎么样，需要去了解我之前都去过哪些地方，哪些地方没去过等等，最终给出一个计划。

再举一个例子：让一个“开发智能体”开发一个 Obsidian 插件：实现同步内容到笔记软件中，AI 接收到开发要求和笔记软件的 API 文档，然后调用查看网页的工具进行 API 文档的学习，最后结合大模型的知识输出插件代码。

总之，一个智能体可以感知、思考和行动。

上面提到的开发插件的例子，一个智能体就搞定了，这是因为插件非常简单。那如果开发复杂的企业级应用系统呢？单个智能体就搞不定了。

一个复杂的需求来了，需要不同的角色分工合作，交给 AI 也是如此，下面简单列举几个角色：

这些角色都可以是一个个独立的智能体，在整个开发的过程中，负责人和开发、测试需要沟通；开发的前后端之间需要沟通，开发和测试之间也需要沟通。

如果这些角色都是来自不同国家的人，互相之间语言不通，沟通成本就非常高了。

A2A 的出现就是为了解决这个沟通问题，让每个角色都具备一种通用语言。

A2A 协议是一套开放标准，它为不同供应商、不同框架开发的智能体之间提供了一种通用沟通语言。

在整个过程中，A2A 协议干了下面几件事情：

智能体（Agent）需要像人类一样分工协作以解决复杂任务。每个 Agent 具备独特能力，必须通过信息交换与知识共享实现协同。

然而，不同开发者创建的 Agent 若采用不同的沟通标准，如同人类使用不同语言交流，将导致理解错位与协作混乱，严重阻碍任务执行效率。这种标准化缺失成为多智能体系统的核心瓶颈。

当大量不同 Agent（来自企业、开源项目等）涌入生态时，私有化通信协议使交互成本激增。例如，调度 Agent 可能无法理解执行 Agent 的状态反馈，这种“鸡同鸭讲”的局面迫使系统需要一种通用“语言”来承载需求、能力、决策等核心信息的无损传递。

A2A 协议应运而生，其通过定义统一的消息格式、交互流程与语义规范，构建了智能体间的“通用语”。无论 Agent 底层架构差异如何，均可通过 A2A 声明能力、发送请求、同步状态。

1、标准化协议：两者都是为了解决信息孤岛，提供统一的、标淮的通信机制，使得不同服务或 Agent 可以顺畅沟通。

2、通用与可扩展：都可以扩展到多种应用场景，无论是工具调用、资源整合（MCP），还是智能代理之间的协作沟通 (A2A)。

3、交互机制：核心交互模式都基于类似 Client-Server 或 Peer-to-Peer 的请求-响应机制。

1、核心目标

MCP：连接模型与工具，专注于让大模型（LLM）调用和使用外部工具/资源（API、数据库等），提供结构化、确定性的接口。

A2A：实现 Agent 间协作，专注于定义多个智能体（Agent）如何沟通、协调以完成任务。

2、交互粒度

MCP：精细，处理具体动作细节（如工具调用、参数传递、结果解析等）。

A2A：抽象，关注任务层面协作（如任务请求、状态通告、结果反馈）。

3、协议内容

MCP：制定了一套标准接口元素 (如 Tools, Resources, Memory, Transports)，覆盖了工具调用生命周期。

A2A：定义通信标准，主要规范消息格式、会话机制，不涉及具体工具细节。

如果把智能体比作一个人，那么 MCP 就是“手”，负责操作各种工具和获取资源，而 A2A 则是“嘴”，负责与其他智能体交流。这两个协议并非竞争关系，而是优势互补

A2A 的技术细节还有不少，比如 A2A 的设计原则是什么？A2A 的角色有哪些？A2A 又是怎么通信的？

我认为还是需要通过代码的方式，走通整个逻辑才能更好的理解这些概念。就放到后面的文章中吧。