Agent Communication Protocols —— MCP & A2A - Clear Eyes, Full Heart
LOADING
3247 words
16 minutes
Agent Communication Protocols —— MCP & A2A

Agent Communication Protocols —— MCP & A2A

引言:Agent的“母语”问题

在前几篇文章中,我们拆解了Agent的核心架构、范式演进、工具调用和记忆系统。一个具备了这些能力的Agent,已经是一个功能完整的个体——它能思考、能调用工具、能记住信息。

但问题来了:当两个Agent需要一起工作时,它们说什么语言?

早期的做法是“点对点私有集成”——Agent A给Agent B发一个HTTP请求,约定好JSON格式,各自硬编码对方的地址和接口。这套方案在只有两三个Agent时勉强可行,但当Agent数量增长到几十个、几百个时,问题迅速爆发:集成复杂度爆炸、协作逻辑与业务逻辑耦合、新Agent上线无法被自动发现。

行业需要的是一套标准化的Agent通信语言。2024-2025年,两个关键协议先后问世,分别从两个维度解决了这个问题:

  • MCP(Model Context Protocol) :由Anthropic发起,解决“Agent如何调用工具”的问题
  • A2A(Agent2Agent Protocol) :由Google发起,解决“Agent如何与其他Agent协作”的问题

两者不是竞争关系,而是互补关系。一个完整的Agent系统需要同时使用两者。本文将系统讲解MCP与A2A的定位差异、技术架构与协同方式。


一、MCP——Agent的“USB接口”

1.1 核心定位:连接Agent与工具

MCP(Model Context Protocol,模型上下文协议) 是一个开放协议,用于实现LLM应用与外部数据源和工具之间的无缝集成。

MCP要解决的问题可以概括为 “M×N问题” :M个AI应用需要分别连接到N个不同的工具——数据库、API、文件系统、内部系统等。没有标准化协议时,每接入一个新工具就需要写一套新的集成代码。

MCP的方案是:建立一个通用适配层,工具开发者实现MCP服务端,应用开发者实现MCP客户端,双方通过统一协议通信。MCP将一个 “M×N”问题转化为“M+N”问题——显著降低了系统集成的复杂度。

1.2 技术架构:客户端-服务器

MCP采用客户端-服务器(Client-Server)架构

  • MCP Host:LLM应用程序(如Claude Desktop),负责发起连接
  • MCP Client:Host内部负责连接某个MCP Server的组件
  • MCP Server:对外暴露能力的轻量级服务

MCP是无状态协议——每个请求都是自包含的,携带自己的协议版本、客户端身份和能力声明。

1.3 三种核心能力:Tools、Resources、Prompts

MCP Server通过三种方式对外暴露能力:

Tools(工具) :可执行的函数,模型可以主动发现和调用。例如:查询数据库、调用API、执行计算。Tools是模型驱动的——LLM决定何时调用哪个工具。

Resources(资源) :只读的数据源,为模型提供上下文。例如:文件内容、数据库Schema、日志。Resources是应用驱动的——客户端决定在对话中附加哪些资源。

Prompts(提示模板) :预定义的模板化消息和工作流。例如:斜杠命令、菜单选项。Prompts是用户控制的——用户通过交互选择触发。

此外,MCP还支持Sampling(采样) ——服务器可以通过客户端请求LLM生成补全,实现嵌套的Agent行为。

1.4 设计哲学:标准化工具生态

MCP的终极目标是创建一个工具生态——工具提供者可以轻松地将服务暴露给各种AI模型和Agent框架,而Agent开发者可以用标准化方式消费这些工具。

截至2025年底,Anthropic已将MCP捐赠给Linux基金会旗下的Agentic AI Foundation(AAIF),共同发起方包括Block、OpenAI,支持方包括Google、Microsoft、AWS等。MCP正在成为Agent连接工具的事实标准


二、A2A——Agent的“互联网”

2.1 核心定位:连接Agent与Agent

A2A(Agent2Agent Protocol,代理对代理协议) 是一个开放协议,定义了独立AI代理之间如何发现、通信和协作。

A2A由Google于2025年4月推出,已由Linux基金会托管为开源项目。推出时获得了超过50家技术合作伙伴的支持,包括Atlassian、Box、Cohere、Intuit、Langchain、MongoDB、PayPal、Salesforce、SAP、ServiceNow等。

A2A要解决的问题是:不同供应商、不同框架构建的AI Agent之间如何互操作。一个Agent可能由Google的框架构建,另一个由LangChain构建,第三个是自研的——它们需要一种标准化的方式来进行通信和协作。

2.2 设计原则:五个关键词

A2A的设计遵循五个核心原则:

  1. 拥抱Agent能力:A2A专注于让Agent以自然、非结构化的方式协作,不把Agent限制为“工具”
  2. 构建在现有标准之上:基于HTTP、SSE、JSON-RPC等成熟标准,易于集成
  3. 默认异步优先:支持长时间运行的任务,通过流式响应提供增量更新
  4. 安全传输:支持HTTPS、身份验证和授权
  5. 多语言SDK:提供Python、JavaScript、Java和C#的SDK,加速采用

2.3 AgentCard:能力发现机制

A2A的核心创新之一是 AgentCard(代理卡片) 。每个A2A兼容的Agent都发布一张AgentCard,描述自己的:

  • 能力与技能:这个Agent能做什么
  • 通信端点:如何与它通信
  • 安全要求:需要什么样的认证和授权

其他Agent通过发现AgentCard来了解彼此的能力。这类似于微服务架构中的服务发现机制——新Agent上线后,其他Agent可以自动感知其提供的服务。

2.4 任务生命周期管理

A2A通过有状态的任务(Task)模型支持复杂的、长时间运行的协作流程。

每个任务有唯一的ID,经历定义的生命周期:submittedworkinginput-requiredcompleted / failed

一个典型的A2A协作场景是:

旅行规划Agent通过A2A与航班预订Agent、酒店预订Agent、活动预订Agent分别通信,管理一个多阶段的预订流程——每个Agent在自己的专业领域内协作,共同完成用户的旅行规划。

2.5 A2A与MCP的本质区别

A2A官方文档对此有清晰的阐述:

Tools & Resources(MCP的交互对象)

  • 具有明确定义的、结构化的输入输出
  • 执行特定的、通常无状态的函数
  • 行为通常是可预测和事务性的
  • 交互通常是单次请求-响应

Agents(A2A的交互对象)

  • 更自主的系统,能够推理、规划、使用多个工具
  • 在长时间交互中维护状态
  • 行为可能是涌现的、不如简单工具可预测
  • 交互涉及持续的任务、上下文共享和协商

MCP连接的是Agent与工具,A2A连接的是Agent与Agent——两者交互对象的本质决定了它们需要不同的协议设计。


三、MCP与A2A的全面对比

3.1 六维差异分析

维度MCPA2A
发起方Anthropic(2024)Google(2025.4)
核心目标Agent ↔ 工具/数据源标准化连接Agent ↔ Agent标准化协作
技术架构客户端-服务器(总线式)服务注册-发现-调用(注册中心式)
通信模式同步请求-响应为主异步、流式、长任务为主
状态管理无状态(每次调用独立)有状态(支持任务上下文持久化)
发现机制Tools List(工具注册表)AgentCard(能力声明JSON)
响应延迟毫秒级(简单调用)分钟级(复杂任务)
扩展方式注册新工具新增Agent节点
类比USB接口 / 总线公共互联网 / HTTP

3.2 垂直扩展 vs 水平扩展

从系统扩展的角度看两者的差异最为清晰:

MCP实现的是“垂直扩展” ——通过连接到专业工具和数据源,增强单个Agent的功能范围。一个Agent原本只能做文本生成,通过MCP连接了数据库、API、计算引擎后,它变成了一个全能的“超级Agent”。

A2A实现的是“水平扩展” ——通过让多个专业Agent协同工作,处理超出单个Agent能力范围的复杂问题。没有哪个Agent是全能的,但一群专业Agent协作起来可以解决任何问题。


四、协同——MCP+A2A的叠加使用

4.1 不是二选一,而是两者都要

MCP与A2A不是取代关系,而是互补与协作关系

一个完整的Agent系统需要同时使用两者:

用MCP给Agent装备工具,用A2A让Agent们组网协作。

A2A官方文档明确建议:“一个Agent应用可能使用A2A与其他Agent通信,而每个Agent内部使用MCP与自己的特定工具和资源交互。”

4.2 叠加使用的三层架构

在实践中,MCP+A2A的叠加使用通常形成三层架构:

第一层:单Agent装备(MCP) ——每个Agent通过MCP连接自己需要的工具和数据源。研究员Agent连接搜索工具和数据库,分析师Agent连接计算引擎和可视化工具。

第二层:多Agent组网(A2A) ——Agent之间通过A2A发现彼此、委托任务、交换信息。研究员Agent将分析任务委托给分析师Agent。

第三层:统一编排(可选) ——通过LangGraph等框架对多Agent协作进行动态流程编排。

4.3 实际案例:研究员-分析师协作

一个典型的叠加使用场景:

  1. 研究员Agent通过MCP调用搜索工具、网页抓取工具,收集原始资料
  2. 研究员Agent通过A2A将分析任务委托给分析师Agent
  3. 分析师Agent通过MCP调用自己的计算引擎和可视化工具
  4. 分析师Agent通过A2A将分析结果返回给研究员Agent
  5. 研究员Agent整合结果,生成最终报告

在这个流程中,每个Agent内部用MCP获取能力,Agent之间用A2A进行协作

4.4 官方集成方向

A2A官方建议将 A2A Agent建模为MCP的Resource——即一个Agent的AgentCard可以作为MCP资源被发现和访问。这种设计使得Agent既可以通过MCP被“调用”(作为资源),又可以通过A2A被“协作”(作为对等体)。

Anthropic和Google Cloud已经联合举办了关于“使用MCP和A2A在Vertex AI上部署多Agent系统”的研讨会,两大协议生态正在走向深度融合。


五、2026年协议层选型要点

5.1 选型核心逻辑

在2026年的Agent开发生态中,协议选型的核心逻辑可以用一句话概括:

MCP解决“怎么做”(How),A2A解决“找谁做”(Who)。

选择MCP:当你的Agent需要连接外部工具、数据源或API时。MCP将工具接入从“每个工具写一套适配器”简化为“统一协议接入”。

选择A2A:当你的系统需要多个Agent协同完成复杂任务时。A2A让Agent之间可以动态发现彼此、委托任务、共享上下文。

5.2 渐进式策略:MCP打基础,A2A建网络

对于大多数团队,建议采用渐进式策略

第一阶段:MCP打基础 ——先用MCP让单个Agent连接必要的工具和数据源,建立Agent的基础能力。

第二阶段:A2A建网络 ——当单个Agent能力足够、但任务复杂度超出单个Agent处理范围时,引入A2A实现多Agent协作。

5.3 2026年协议生态现状

截至2026年中:

  • MCP:已捐赠给Linux Foundation的AAIF,获得主流AI厂商广泛支持。规范成熟,有Python、TypeScript等多种SDK。MCP Server数量快速增长,覆盖数据库、API、文件系统等各类工具。

  • A2A:已发布v1.0版本,由Linux Foundation托管。提供Python、JavaScript、Java、C#的SDK。获得超过50家合作伙伴支持。

两者共同构成了AI Agent从实验室走向生产环境的基础设施层


六、总结:两条腿走路

MCP和A2A的关系,可以用一个类比来理解:

MCP是Agent的“手” ——它让Agent能够抓取工具、操作数据、影响世界。没有MCP,Agent只能“想”不能“做”。

A2A是Agent的“嘴” ——它让Agent能够与其他Agent对话、协商、委托任务。没有A2A,每个Agent都是孤岛。

一个完整的Agent系统需要两条腿走路——用MCP装备单个Agent的能力,用A2A构建多Agent的协作网络。正如A2A官方文档所说:“Agent应用需要同时使用A2A和MCP”。

在2026年这个“协议时代”,理解MCP与A2A的分工与协同,已经成为每一个Agent开发者必须具备的基础认知。

Agent Communication Protocols —— MCP & A2A
/posts/ai_agent/agent_communication_protocols/
Author
Zhang Haoyi
Published at
2026-03-14
License
CC BY-NC-SA 4.0
分享:

Some information may be outdated

Directory
Albums
Diary
Posts
Projects
Skills
Timeline
Categories
Tags
Table of Contents