引言
为了打破不同厂商、不同框架构建的智能体壁垒,实现 AI 生态的互联互通,业界领先者谷歌(Google)和 Anthropic 相继推出了开放标准——Agent-to-Agent(A2A)协议和 Model Context Protocol(MCP)标准。
A2A 和 MCP 是高度互补的关系。它们解决了 AI 系统与外部世界连接的两个不同层面的问题:
-
MCP 解决的是“AI 如何连接到数据和工具”的问题。 它为 AI 代理(或模型本身)提供了一个标准化的接口,使其能够获取外部知识、调用外部 API、与各种软件工具交互,从而获得执行任务所需的上下文(Context)和能力(Capability) 。
-
A2A 解决的是“AI 如何连接到其他 AI”的问题。 它为具备了不同知识或能力的多个 AI 代理提供了一个标准化的通信协议,使它们能够相互协调、分配任务、共享信息,共同完成更复杂的协作(Collaboration)任务。
在一个复杂的 AI 应用场景中,完全可以同时采用 MCP 和 A2A。例如:一个面向用户的个人助理 Agent,可能首先通过 MCP 连接到公司的 CRM 系统查询客户信息(获取上下文),然后通过 A2A 调用另一个专门负责生成报告的 Agent 来整理这些信息并生成分析报告(进行协作),最后再通过 MCP 调用邮件服务将报告发送给用户(执行操作)。
就谷歌所言,已经有 50 多家技术合作伙伴的支持和贡献了,还得是大佬振臂一呼有用。
一、 谷歌 A2A 协议:构筑智能体协作的桥梁
1.1 A2A 协议简介与核心目标
2025 年 4 月 9 日,谷歌正式发布了名为 Agent-to-Agent(A2A) 的开放协议,旨在为不同生态系统中的 AI 智能体提供一套安全、标准化的协作框架。正如谷歌开发者博客的公告所述,A2A 的核心目标是在复杂的企业环境中实现动态的多智能体协作。并且已经开源在了 Github。
在当前企业数字化转型的大背景下,数据孤岛和应用壁垒普遍存在。A2A 协议的提出,正是为了打破这些障碍,让由不同供应商、基于不同技术栈开发的智能体能够顺畅地进行通信、交换必要信息并协调行动。通过这套通用的代理互操作协议,企业可以将多个专精于特定领域的 AI Agent 有机整合,共同处理复杂的业务流程,例如跨部门的设备采购审批、多渠道的客户服务支持、动态调整的供应链计划等,从而显著提升自动化水平和整体生产效率。
谷歌特别强调,A2A 协议并非要取代而是补充 Anthropic 此前提出的 MCP 标准。如果说 MCP 主要解决了智能体如何获取外部工具和上下文信息的问题,那么 A2A 则聚焦于智能体之间的交互与协作。谷歌建议将 MCP 用于工具(Tools),将 A2A 用于代理(Agents),他们是相互补充的。
A2A 协议凝聚了谷歌在部署大规模代理系统方面的丰富经验,致力于解决企业级多代理系统面临的现实挑战,最终目标是实现广泛的通用互操作性,为充分释放协作式 AI 代理的巨大潜力奠定坚实基础。
1.2 A2A 协议的架构与关键技术
核心架构: A2A 协议清晰地定义了客户端代理(Client Agent) 和远程代理(Remote Agent) 之间的通信模式。在这种模式下,客户端代理负责发起任务请求,明确需要完成的目标;而远程代理则接收请求,执行具体的任务,并返回所需的信息或执行相应的操作。
技术实现: 为了确保协议的易用性和兼容性,A2A 构建在成熟的 Web 技术之上:
-
通信基础: 使用标准的 HTTP 协议进行请求响应。
-
实时推送: 利用 Server-Sent Events (SSE) 实现服务器向客户端的实时信息推送,这对于状态更新和长时任务的反馈非常重要。
-
消息格式: 采用 JSON-RPC 格式来定义消息结构,便于与现有的 IT 系统和开发栈集成。
-
通信特性: 支持双向流通信和长连接,以高效处理需要实时反馈和持续交互的长周期任务。
核心组件与数据结构: 为支撑上述通信模式,A2A 定义了一系列标准化的组件和数据结构:
-
代理卡片(Agent Card): 每个智能体通过一个 JSON 格式的“Agent Card”来声明自身的能力和服务。这使得客户端代理能够发现(Capability Discovery)具备特定能力的远程代理,并选择最合适的协作者来执行任务,实现了动态的服务发现。这有点类似于 LLMs.txt 的作用。
-
任务(Task)对象: 智能体间的交互围绕“任务”展开。任务是协议定义的核心对象,包含了任务描述、当前状态、生命周期管理等关键信息。任务可以是即时完成的短任务,也可以是需要较长时间运行的长周期任务。对于后者,双方代理会持续通信以同步进度,提供实时的状态更新和必要的通知。任务最终产出的结果被称为成果(Artifact) 。
-
消息(Message): 智能体之间通过结构化的消息来传递上下文信息、响应、中间结果、最终成果或用户指令等。消息采用 JSON 封装,支持流式传输,使得代理间能够进行多回合的协作式交互,并能够即时地相互提供反馈。
-
消息部件(Part)与用户体验协商: 为了支持丰富的交互内容,每条消息可以包含多个“部件(Part)”,每个部件都带有明确的内容类型标识(如文本、图像、视频、Web 表单等)。这种设计允许客户端代理和远程代理协商决定使用何种内容格式,以及如何在用户界面上呈现结果。例如,如果远程代理能够生成图表或嵌入式网页(iframe),协议允许双方确认接收方是否具备相应的展示能力,从而确保协作的输出能够与用户界面能力相匹配,提供流畅、一致的用户体验。
关键技术特性与安全考量:
-
基于开放标准: A2A 严格遵循现有成熟的互联网标准,降低了企业的学习成本和集成门槛。
-
默认安全(Secure by default): 协议将安全置于核心地位,支持企业级的身份认证与授权机制。其安全策略与 OpenAPI 规范中的认证方案对齐,确保在不同平台和云环境下的代理通信安全可靠。
-
支持多模态: A2A 不仅限于文本交互,还原生支持音频、视频流等多模态内容的传输,前瞻性地考虑了未来多模态 AI 代理的交互需求。
总体而言,A2A 的技术架构旨在提供一个开放、灵活、可扩展且高度安全的框架,为不同来源、不同能力的 AI Agent 互联互通和协同工作提供了统一的技术基础。
1.3 A2A 协议的典型应用场景
A2A 协议主要面向企业内部复杂的、跨系统的工作流程自动化场景,在这些场景中,往往需要多个具有不同专长的 AI 代理协同工作,共同完成用户委派的复杂任务。
谷歌官方提供了一个生动的候选人招聘流程示例来说明 A2A 的应用价值:
-
任务发起: 在一个统一的智能体交互界面(例如 Agentspace)中,招聘经理向其个人助理代理下达指令,要求寻找符合特定岗位要求(如软件工程师)、地区和技能条件的候选人。
-
代理协作(发现与调用): 助理代理(作为客户端代理)通过 A2A 协议,首先发现具备人才搜索能力的人力资源代理(作为远程代理)。随后,它向人力资源代理发送请求,委托其在内部人才库或外部渠道中搜索合适的候选人名单。
-
结果反馈与下一步协作: 人力资源代理完成搜索后,通过 A2A 将候选人建议(成果 Artifact)返回给助理代理。助理代理将结果呈现给招聘经理。
-
多轮协作(任务扩展): 招聘经理审阅后,可能要求助理代理为选定的候选人安排面试。助理代理再次通过 A2A,找到并调用日程安排代理,协调面试官和候选人的时间,并发送会议邀请。
-
进一步协作(流程延伸): 面试结束后,招聘经理可能需要进行背景调查。助理代理可以继续通过 A2A 协议,调用 ** 背景调查代理 **,请求获取候选人的背景核查报告。
在这个例子中,多个 AI 代理(助理、HR、日程、背调)跨越了不同的业务系统(人才管理系统、日历系统、背调服务平台等),通过 A2A 协议实现了无缝协作,极大地简化了原本繁琐的招聘流程,提高了效率。
这是一个基于 A2A 协议的 Demo APP,建议可以仔细查看:
这仅仅是 A2A 潜力应用的一个缩影。在更广泛的企业环境中,A2A 可以应用于:
-
IT 运维与支持: 一个代理负责接收员工的设备申请并下单采购,另一个代理负责在新设备到货后自动进行系统配置和软件安装。
-
客户服务: 多个智能客服助理协同工作,一个负责理解用户意图并分发请求,其他代理分别处理订单查询、技术支持、投诉处理等不同类型的任务,共同为客户提供高效全面的服务。
-
供应链管理: 一系列代理协同完成从接收订单、检查库存、安排生产、跟踪物流到更新库存状态的整个链条,实现供应链的智能化管理和快速响应。
总而言之,A2A 为企业实现跨系统、跨部门业务流程的端到端自动化提供了强大的技术支撑。
1.4 A2A 协议的核心设计理念
根据谷歌的阐述,A2A 协议在设计过程中始终遵循了五大核心原则:
-
拥抱智能体的自主能力(Agentic Capabilities): 协议的设计不仅仅是将 Agent 视为简单的工具调用接口,而是充分尊重和发挥每个智能体自主决策、处理非结构化任务的能力。即使参与协作的 Agent 不共享记忆、工具或上下文,协议也允许它们以自然、灵活的方式进行协作,实现真正的对等、分布式的多智能体系统,而非将某些 Agent 降级为其他 Agent 的附属工具。
-
构建于现有标准之上: A2A 优先选用业界广泛接受和使用的标准协议,如使用 HTTP 进行通信,SSE 进行事件推送,JSON-RPC 进行远程过程调用。这意味着企业可以利用现有的网络基础设施和 API 技术栈来部署和集成 A2A,无需引入全新的、专有的技术体系,从而显著降低了采用门槛和集成复杂度。
-
默认安全(Secure by Default): 企业级应用对安全性有极高要求。A2A 从设计之初就将安全放在首位,支持严格的身份验证和授权机制,并与 OpenAPI 规范中的成熟认证方案(如 OAuth 2.0, API Keys)保持一致。这确保了跨 Agent 通信过程中的数据机密性、完整性和访问控制能够得到有效保障,满足企业的合规要求。
-
支持长时任务(Support for Long Running Tasks): 现实世界的业务流程往往不是瞬时完成的。A2A 被设计得足够灵活,既能处理快速响应的短任务,也能良好地支持需要数小时甚至数天完成的深度任务,甚至允许在任务执行过程中有人工介入协作。对于长时任务,A2A 提供了状态同步、进度反馈和通知机制,确保协作过程的透明度和可管理性,避免因协议限制而导致任务中断。
-
模态无关(Modality Agnostic): 未来的 AI 交互必然是多模态的。A2A 在设计上保持模态中立,不局限于文本,原生支持文本、音频、视频等多种数据形式的交流。例如,一个进行图像分析的 Agent 可以将其处理后的视频片段通过 A2A 发送给另一个负责生成文本摘要的 Agent,双方协同完成多模态信息的处理与呈现。这种灵活性使得 A2A 能够适应未来 AI 技术的发展,更好地支持日益丰富的多模态应用场景。
通过践行这些设计理念,A2A 致力于成为一个开放通用、健壮安全、灵活可扩展的智能体协作基础框架,为企业构建和部署复杂的 AI Agent 生态系统提供标准化的解决方案。
二、MCP 和 A2A 的关系
虽然谷歌的 A2A 协议和 Anthropic 的 MCP 标准都是为了促进 AI 系统间互联互通而设计的开放标准,但它们在核心目标、侧重场景、技术架构等方面存在明显的差异。理解这些差异对于在实际应用中选择和组合使用它们是很重要多。
谷歌也明确指出,A2A 是对 MCP 的补充,两者共同构成了 AI 互操作性版图的重要组成部分,所以以后的 AI 很有可能是 A2A + MCP,Agent 是人的角色,MCP 是工具的角色。
举个官网的例子:
考虑一家修理汽车的汽车维修店。该车间雇用自主工人,他们使用专用工具(例如车辆千斤顶、万用表和套筒扳手)来诊断和修复问题。工人经常必须诊断和修复他们以前从未见过的问题。维修过程可能涉及与客户的广泛对话、研究以及与零件供应商合作。
现在,让我们将商店员工建模为 AI 代理:
-
MCP 是将这些代理与其结构化工具(例如 把平台升高 2 米,扳手向右转 4 毫米 )连接的协议。
-
A2A 是使最终用户或其他代理能够与商店员工合作的协议(“我的车发出嘎嘎作响的声音”)。A2A 支持持续的来回沟通和不断发展的计划以实现结果(“给我发送左轮的照片”、“我注意到液体泄漏。这已经发生了多长时间?A2A 还帮助汽车修理厂员工与其他代理合作,例如他们的零件供应商。
下表从多个维度对 A2A 和 MCP 进行了对比:
总结:互补关系,共促生态
因此,MCP 为 Agent 提供了“燃料”(数据和工具), 而 A2A 则提供了 Agent 之间“对话和合作的规则。两者共同推动了 AI Agent 从孤立的个体走向互联互通、协同工作的生态系统。
三 、 以往的 AI 协作历史探索
A2A 和 MCP 标准的提出并非一蹴而就,而是建立在 AI 研究和工程领域长期以来对模型知识接入和多智能体协作探索的基础之上。回顾这些重要的技术发展脉络,有助于我们更深刻地理解 A2A 和 MCP 的价值与意义。
3.1 插件系统与工具使用:赋予模型行动能力
早期的大型语言模型如同博学的“书生”,知识丰富但缺乏与现实世界交互、执行具体任务的能力。为了弥补这一缺陷,插件(Plugins)系统应运而生。
-
OpenAI 的 ChatGPT 插件: 2023 年,OpenAI 为 ChatGPT 推出的插件功能是这一方向的里程碑。开发者可以将各种网络服务(如航班预订、购物比价、数学计算、知识库查询等)封装成符合 OpenAPI 规范的 API 接口,并提供描述文件给 ChatGPT。模型在理解用户意图后,能够自主判断何时以及如何调用这些插件来获取实时信息或执行操作。
-
核心价值: 插件系统极大地扩展了 LLM 的能力边界,使其能够接入最新的、私有的或特定领域的信息源,并在用户授权下代表用户执行任务,弥补了纯语言模型无法主动查询或行动的不足。同时,OpenAI 也强调了安全可控的重要性,通过权限和沙盒机制确保插件的调用符合预期。
-
早期探索: 插件思想的雏形可见于更早的研究,如 2021 年的 WebGPT(通过浏览器搜索增强回答)以及社区涌现的 Adept 行为 API、LangChain 工具链等。这些探索证明了让模型学会使用外部工具(API、搜索引擎、计算器等)是提升其实用价值的关键途径。
可以说,插件系统是实现模型“工具使用”能力的一次重要标准化尝试,为后续更通用的 MCP 标准奠定了实践基础。后续出的 GPTs 也是 Agent 的雏形。
3.2 向量数据库与 RAG:让模型“开卷考试”
另一条关键的技术脉络是检索增强生成(Retrieval-Augmented Generation, RAG) ,它旨在通过检索外部知识来提升模型回答的质量和准确性。
-
核心思想: RAG 的理念是,在模型生成回答之前,先根据用户的问题从一个大规模的知识库(通常存储在向量数据库中)检索出最相关的几段信息,然后将这些信息作为额外的上下文(Context)一同输入给模型。这样,模型就能像“开卷考试”一样,依据检索到的可靠资料来生成回答。
-
提出与发展: Facebook (Meta) AI 研究院在 2020 年的 NeurIPS 论文 中首次系统性地提出了 RAG 框架,旨在结合模型的参数化记忆(模型内部学到的知识)和非参数化记忆(外部知识库)来处理知识密集型任务。
-
实现流程: 首先,将企业文档、网页、FAQ 等文本资料进行切块(Chunking)和向量化(Embedding) ,存入向量数据库(如 Pinecone, Weaviate, Milvus, FAISS 等)。当用户提问时,将问题也转化为向量,在数据库中执行相似度搜索,找到最相关的文本片段。最后,将这些片段与原始问题拼接成提示(Prompt),送入 LLM 生成最终答案。
-
主要优势:
-
信息时效性: 可以访问实时更新的知识库,弥补 LLM 训练数据截止日期带来的知识滞后问题。
-
减少幻觉: 基于检索到的事实依据生成回答,能显著减少模型凭空捏造(Hallucination)的可能性,并可提供引用来源,提高答案可信度。
-
降低成本: 相比于为模型补充新知识而进行昂贵的微调或重新训练,维护和更新外部知识库的成本通常更低,尤其适合需要频繁更新知识的企业应用。
-
-
生态发展: 随着向量数据库技术的成熟和 LlamaIndex (原 GPT Index) 等开源 RAG 框架的普及,RAG 已成为构建知识问答、企业智能助手等应用的标准技术架构。OpenAI 也开源了“检索型插件”,让开发者能将自己的向量数据库接入 ChatGPT。
RAG 为模型接入非结构化文本知识提供了一条高效路径,而 MCP 标准则可以看作是将 RAG 中“连接到知识库”这一步进行了标准化和通用化,使其能接入更多类型的数据源。
3.3 知识图谱接口:结构化知识的利用
除了基于向量的非结构化文本检索,知识图谱(Knowledge Graph, KG) 作为一种结构化的知识表示形式,也为 AI 模型提供了重要的知识来源。
-
特点与优势: 知识图谱以实体 - 关系 - 实体的三元组形式存储事实,具有结构清晰、便于推理的特点。相比于 RAG 返回的文本片段,知识图谱可以直接提供精确的事实,并通过图查询语言(如 SPARQL)支持复杂的关系查询和多跳推理,这对于回答需要精确关系判断的问题(如“某公司的 CEO 是谁?”或“A 和 B 是否有共同投资方?”)非常有优势。
-
与 LLM 的结合:
-
LLM 驱动 KG 查询: 利用 LLM 的自然语言理解能力,将用户的自然语言问题转换为知识图谱的结构化查询语句。
-
KG 增强 LLM 生成: 将从知识图谱中检索到的相关事实或子图作为上下文提供给 LLM,为其生成提供事实依据和背景知识,有助于减少模型幻觉,提升答案的准确性。
-
-
应用探索: 实践中,有项目尝试开发知识图谱查询插件,让 LLM 能够直接与企业 KG 对话;也有研究探索“图谱增强的 RAG”,即在 RAG 流程中结合知识图谱检索和文本检索,提供更丰富、更结构化的上下文。
-
与向量数据库的关系: 知识图谱和向量数据库并非相互替代,而是互补关系。向量数据库擅长处理语义相似性和模糊匹配,适合检索相关段落;知识图谱则擅长精确事实查找和关系推理。理想的系统可能会结合两者,通过统一的接口(如 MCP 所倡导的)供 LLM 查询。
知识图谱接口的探索,代表了模型接入结构化知识的努力方向,进一步丰富了模型获取外部信息的能力。
3.4 智能体框架与多代理协作:走向协同智能
随着 LLM 能力的提升,研究者和开发者开始探索让多个智能体(Agent)分工协作来解决更复杂的问题,催生了一系列智能体框架和实验性项目。
-
智能体框架(如 LangChain): 开源框架 LangChain 是其中的早期代表。它最初专注于将 LLM 调用外部工具(搜索、计算等)的链式流程封装起来,随后发展出“代理(Agent) ”概念。在这种模式下,LLM 不再是被动地按指令调用工具,而是可以基于当前对话状态和目标,自主决定下一步应该调用哪个工具或采取何种行动(即 ReAct:Reasoning + Acting 模式)。LangChain 提供了记忆管理、工具接口、提示工程等组件,使得开发者能更容易地构建出具备一定自主决策能力的 Agent。
-
自主代理探索(如 AutoGPT, BabyAGI): 受 LangChain 等框架启发,社区出现了像 AutoGPT 这样的实验项目。它尝试让一个 LLM Agent 根据最终目标,自主地生成子任务、调用自身或其他工具、甚至创建新的 Agent 来完成子任务,形成一种递归的任务分解和执行链。虽然 AutoGPT 因其展示的自主规划潜力在 2023 年引起广泛关注,但由于缺乏有效的规划、校验和长期记忆机制,其实际应用效果有限,更多地停留在概念验证阶段。
-
多代理协作研究(如 HuggingGPT): 一些重要的研究项目开始探索更结构化的多代理协作模式。例如,微软亚洲研究院在 2023 年提出的 HuggingGPT (或称 Jarvis) 框架 ( 相关介绍 ),展示了如何让一个中央协调 LLM(如 ChatGPT)扮演“控制中心”的角色,来调用 HuggingFace 平台上托管的各种专用 AI 模型(如图像识别、语音合成、文本摘要等专家模型)来协同解决复杂的多模态任务。HuggingGPT 的工作流程大致是:任务规划 -> 模型选择 -> 任务执行 -> 结果整合。这证明了 LLM 可以作为有效的中介和协调者,将不同能力的 AI 模块(或 Agent)组织起来进行模块化协作。
-
模拟社会与生成式代理: 同年,斯坦福大学等机构进行的“生成式代理(Generative Agents) ”实验也引发了关注。研究者在一个虚拟小镇环境中创建了 25 个由 LLM 驱动的 Agent,观察它们如何自主互动、形成社交关系、传播信息,模拟了人类社会行为的涌现。
这些从工具使用、检索增强,到智能体框架、多代理协作的探索,清晰地勾勒出 AI 系统能力演进的轨迹:从被动的信息处理器,到主动的工具使用者,再到具备一定自主规划和协同能力的智能体。这些前期的探索为 MCP 和 A2A 等标准的诞生铺平了道路,积累了宝贵的经验和教训。MCP 标准化了 Agent “看世界、用工具” 的方式,而 A2A 则规范了 Agent “彼此对话、协同工作” 的规则。
技术演进总结: 历史探索解决了 AI 模型接入外部知识和工具(通过插件、RAG、KG 接口等)以及初步实现 Agent 自主决策和多 Agent 协同(通过 Agent 框架、HuggingGPT 等)的问题。然而,这些方案往往是定制化的、碎片化的。MCP 和 A2A 的出现,正是为了将这些能力进行标准化和通用化,降低集成成本,促进更广泛、更深入的 AI 应用和生态发展。
四 、 总结与展望
谷歌的 A2A 协议和 Anthropic 的 MCP 标准,是当前 AI 领域推动互操作性和生态开放的两大关键举措。
-
MCP 致力于打造 AI 模型连接外部数据源和工具的“通用插座”,让模型能够便捷、安全地获取实时、私有的上下文信息,极大地提升了 AI 应用的实用性和准确性,并已迅速获得包括 OpenAI 在内的行业巨头的广泛支持,正朝着事实标准的方向发展。
-
A2A 则聚焦于解决多智能体之间的协作问题,提供了一套基于开放 Web 标准的通信协议,使得不同来源、不同能力的 Agent 能够安全、高效地协同工作,共同完成复杂的企业级任务,为构建强大的分布式 AI 系统奠定了基础。
这两大标准互为补充,共同构成了未来智能体生态系统的重要基石。MCP 为 Agent 提供了感知世界、获取知识、使用工具的能力;A2A 则赋予了 Agent 之间相互理解、沟通协作的能力。
展望未来,随着这两大标准及其生态的不断成熟和完善,我们可以预见:
-
AI 应用开发的变革: 开发者将能够像搭积木一样,更容易地组合来自不同提供商的 AI 模型、Agent、数据源和工具,快速构建出功能强大、高度定制化的智能应用。
-
企业自动化的深化: 企业将能够部署由多个专业 Agent 组成的“智能劳动力”,实现跨部门、跨系统复杂业务流程的端到端自动化,显著提升运营效率和决策水平。
-
新型智能服务的涌现: 基于 Agent 协同和广泛知识接入,可能会涌现出全新的智能服务模式,例如更加个性化、主动化、具备深度推理和执行能力的 AI 助手。
当然,标准的推广和应用也面临挑战,包括如何确保不同实现之间的兼容性、如何处理复杂协作场景下的安全与治理、如何平衡开放性与商业利益等,这也都是后话了。
但总体而言,A2A 和 MCP 所代表的开放、协作、标准化的方向,无疑将极大推动 AI 技术从模型本身向更广阔的应用场景渗透,加速智能体经济(Agent Economy) 的到来。我们有理由相信,一个更加互联互通、协同高效的 AI 新纪元正在加速到来