A2A 协议是什么：和 MCP 管的不是一回事
数据截至 2026-07，规范与各项目能力以官方文档当前版本为准。
A2A 和 MCP 不是摆在同一个位置上让你二选一的两个方案，它们连接的对象根本不同：MCP 解决的是”一个 agent 怎么调用外部工具和数据源”，A2A 这个缩写指向的是”一个 agent 怎么跟另一个 agent 说话”。选型时真正该问的不是”选哪个”，而是”我现在到底有没有第二个 agent 需要对话”——对绝大多数项目来说，答案是没有。
一、先拆掉最常见的那个误解
不少人第一次听到 A2A，是在某篇”新协议出现，MCP 要被替代”的推文里。这个框架从一开始就错了。
打个不严谨但够用的比方：MCP 像是给一台电脑配的外设接口标准，让它能插硬盘、插打印机、插读卡器；A2A 指向的问题更接近两台电脑之间怎么通信——它们各自有自己的外设、自己的存储、自己的操作系统，需要商量的是”我把这个活交给你、你做完告诉我结果”这类事。接口标准和机器间通信标准，本来就不在一个层上，谈不上谁替代谁。
所以”A2A 出来了，MCP 是不是白学了”这个担心不成立。反过来说也一样：把 A2A 接进来，并不会让你少写一行工具层的代码。两层各自的问题，各自解决。
如果你对 MCP 这一层还没有概念，建议先看MCP 是什么？为什么说它是 AI 的 USB 接口，再回来看这篇会顺很多。
二、MCP 那一层现在是什么状况
要说清楚 A2A 的位置，得先承认一件事：工具这一层现在已经收敛得相当成熟了，成熟到有具体规范、有官方注册表、有跨厂商共识。
按官方公开资料，MCP 于 2024 年 11 月发布，2025 年 12 月由 Anthropic 捐给 Linux 基金会下的 Agentic AI Foundation，转为厂商中立、社区治理的标准。OpenAI、Google、Microsoft、AWS 这几家主流厂商都已经把它接进了自家的 agent 栈。生态规模方面，按官方与行业公开资料的口径，有超过一万个公开 MCP server 跑在生产里，SDK 月下载量超过 9700 万——这类数字来自公开资料汇总而非精确统计，看个量级就好。
2026 年 7 月 28 日 MCP 发布了新规范，官方称是自协议发布以来最大的一次修订，涉及协议内核的无状态化、Extensions 框架、授权加固等方面，也带来了破坏性变更（旧版本有 12 个月的弃用窗口）。具体条目和迁移细节以官方 blog 与规范文档当前版本为准，这篇不展开，可以看MCP 2026 规范变革那篇。
提这些不是为了堆信息，而是想说明一个判断：工具层已经有事实标准了，agent 之间那一层还没有到同等成熟度。 这个不对称，直接决定了你现在该把工程精力放在哪。
三、为什么 agent 之间需要单独一层
如果两个 agent 都是你自己写的、跑在同一个进程里、共享同一份内存和上下文，那你根本不需要什么协议——直接函数调用就完了。多智能体框架内部的 agent 协作，本质上走的就是这条路。
需要单独一层协议的，是下面这几种情况：
- 两个 agent 分属不同团队甚至不同公司。 你不可能要求对方跟你用同一个框架、同一门语言、同一套内存结构。这时候需要的是一个双方都认的、跨进程跨组织的通信约定。
- 对方是个黑盒，且有自主性。 调用一个工具，你知道它会做什么、多久返回、返回什么结构；把一个任务交给另一个 agent，它可能会自己规划、自己调工具、中途要你补充信息、耗时不可预测。这种交互形态和”调函数”差别很大。
- 需要发现和协商能力。 工具是你提前配好的，你知道它存在；另一个 agent 可能是你运行时才知道的，你得先搞清楚”它能干什么、以什么形式交付、要不要鉴权”，才能决定要不要把活交出去。
看清这三点，你就能自己判断需不需要 A2A：如果你的场景一条都不占，那当前阶段引入 agent 间协议，多半是给自己找事。
四、多数人现在其实不需要它
这一节可能是全文最值得记住的。
一条在实践者里反复被提到、但和”多智能体很酷”的直觉相反的建议是：当单个 agent 只调用一两个工具时，OpenAI Agents SDK 或 Anthropic Claude Agent SDK 往往是 2026 年更快的路径——你可能根本不需要多智能体框架。 连多智能体框架都不需要，自然更谈不上 agent 之间的通信协议。
过度设计在这个领域特别常见：需求其实是”读个数据库、查个 API、把结果整理成周报”，方案却做成了”研究员 agent + 分析师 agent + 写手 agent 三方协作”。多出来的两个 agent 不解决任何原有问题，反而带来了状态同步、错误传播、token 开销和调试困难。
一个务实的推进顺序是这样：先用单 agent 加工具跑通业务，跑不动了再看是不是需要拆成多个 agent（拆之前先确认是”职责真的正交”，不是”看起来更像个团队”），确认要拆之后先在同一个框架内部拆——框架内部的 agent 协作不需要跨进程协议；只有当你确实要和外部的、别人维护的 agent 打交道时，A2A 这一层才真正进入议程。
不清楚单 agent 该怎么组织的，可以看ReAct 智能体原理。
五、框架侧的支持现状
如果你确实走到了要考虑 agent 间通信的这一步，框架选型是绕不开的一环。下面这些信息来自 2026 年的多篇第三方实战对比，不是各项目官方文档的逐条核实结果，具体能力、接口形态和支持程度以各项目官方文档当前版本为准。
先说协议支持：CrewAI 已经加入了 A2A 支持。另外有项目（OpenAgents）声称自己是唯一原生同时支持 MCP 与 A2A 的框架——“声称”两个字请保留，这一条没有经过独立核实，真要选它，务必自己去仓库和文档里确认当前版本的实际情况。
再说框架本身的差异。三个常被拿来比较的框架，架构模型完全不同：
- LangGraph 用的是有向图模型，节点是函数或 LLM 调用，边定义控制流，状态以带类型的字典在其中传递，适合复杂的生产系统。
- CrewAI 是一队有明确角色的 agent（研究员→写手→审稿），可串行可并行，适合快速搭建和线性流水线。
- AutoGen / AG2 基于对话，agent 之间互相交谈，适合多方辩论、达成共识这类场景，对话模式最丰富，在代码生成和调研上表现突出。
按某次第三方实测对比的口径：学习曲线上 CrewAI 最平缓、LangGraph 最陡；控制力、生产成熟度、token 效率、生态规模这几项上 LangGraph 领先，AutoGen 的 token 开销最大。LangGraph 对执行流的控制更精细，支持持久化的长时运行工作流和 human-in-the-loop，含 checkpointing、streaming、human-in-the-loop 原语；带反馈环的循环任务上它胜出——CrewAI 技术上支持循环，但调试比较痛苦。
有两条容易被旧文章带偏的更新必须提醒：
第一，CrewAI 在 2025 年加了 Flows，一种事件驱动的 pipeline 模式，面向更可预测的生产型负载。多数较老的对比文章没有涵盖这一点，别再沿用”CrewAI 只能做原型”的旧结论。
第二，AutoGen 已经进入维护模式：微软把重心转到了更大的 Agent Framework，AutoGen 的主要新功能开发已经停止，仍有 bug 修复和安全补丁。有实践者直言，2026 年不该把它作为任何新项目的起点。这话该怎么理解——它不是”没法用了”，存量项目不必恐慌迁移，社区也在陆续找替代方案；但如果你正在为一个新项目做技术选型，这个信息你必须知道。就事论事，仅此而已。
框架层面的完整对比可以看主流 AI Agent 框架对比。
六、真要走这条路，先做哪几件事
假设你的场景确实撞上了第三节说的那几种情况，下面这些准备工作和具体用哪个协议无关，做了都不亏：
- 先把每个 agent 的能力边界写成文档。 “这个 agent 接受什么输入、产出什么结构、什么情况下会失败、失败怎么表达”，这套东西不写清楚，换任何协议都对不上。很多人以为协议能替自己想清楚职责划分，其实顺序是反的。
- 工具层先用 MCP 收敛。 让每个 agent 自己那一侧的工具调用走统一标准，是后面做跨 agent 协作的地基。地基不平，上面搭什么都晃。
- 把跨进程调用该有的工程约束补齐。 鉴权、超时、重试与幂等、限流、可观测性——agent 之间的调用比传统 RPC 更难预测（耗时长、可能中途要人介入、失败形态多），这些东西只会更重要，不会更不重要。
- 先在内部两个 agent 之间跑通一遍。 哪怕对方也是你自己写的，先按”跨进程、不共享内存、只能通过消息沟通”的假设跑一遍，你会立刻发现一堆平时靠共享上下文糊过去的问题。这一步的成本远低于直接对接外部 agent。
七、诚实说局限
这篇有几处必须讲明白的边界。
第一，本文没有给出 A2A 的规范细节。 版本号、消息字段、鉴权流程、治理归属这类具体条款，请以其官方文档和仓库的当前版本为准。我不打算凭印象复述这些内容——协议这类东西写错一个字段名，读者照着做就是白折腾一晚上。
第二，第五节的框架对比是第三方实测口径，不是官方文档核实。 各框架迭代很快，某次评测里的”token 效率最好""生态最大”是那次评测那个时间点的结论，你真要拍板选型，请自己跑一遍最小验证。
第三，agent 间协议这一层的格局还没定。 工具层有 MCP 这个已经进入基金会治理、多厂商接入的事实标准，agent 之间那一层目前还没有到同等程度的收敛。这不是说 A2A 不行，而是说现在押注任何一个方案，都得留出改的余地——把业务逻辑和协议实现隔开，别让协议细节渗进核心代码，是这个阶段最实在的自保方式。
想把协议这几层的关系一次看全的，可以看Agent 侧的协议生态：MCP、ACP、A2A 各管什么。
小结
A2A 和 MCP 管的不是一回事：前者指向 agent 与 agent 之间的通信，后者管 agent 与工具、数据源的连接，两层不冲突，也不互相替代。工具层已经有事实标准，agent 间那一层还在成型，两边的成熟度不对称，工程投入也该有先后。多数项目当前的真实需求是把单个 agent 加工具做扎实——单 agent 只调一两个工具时，直接用 OpenAI Agents SDK 或 Claude Agent SDK 往往比上多智能体框架更快。真到了要跨组织协作那一步，先补齐能力边界文档、工具层收敛和跨进程工程约束，这些功课比选哪个协议更决定成败。所有具体条款和框架能力，以各项目官方文档当前版本为准。