Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >5000字长文带你看懂,Agent世界里的A2A、MCP协议到底是个啥。

5000字长文带你看懂,Agent世界里的A2A、MCP协议到底是个啥。

作者头像
数字生命卡兹克
发布于 2025-04-14 13:59:30
发布于 2025-04-14 13:59:30
1530
举报

昨天晚上,Google发了一个关于Agent的新开放协议。

叫Agent2Agent,简称A2A。

包括昨天阿里云百炼也官宣搞MCP了。

这些本来没打算写的,因为太技术了,也是感觉离普通人还是有很大距离。

但是有好几个朋友都在群里说。。。

那还是来聊聊吧,正好也用我自己的理解,来做个小科普,让大家一片文章看懂,A2A、MCP,到底是个啥。

正好最近特朗普对等关税这事,非常火。

搞得全世界鸡犬不宁,每个国家之间的隔阂,好像又重新出现了。

我就用国与国之间的外交,来去解释这两个协议。不要以为八竿子打不着,其实真的非常的像。

我们现在,假设每个AI智能体(Agent)就是一个小国家,它们各自有自己的语言和规矩。

现在,这些国家的大使馆分布在同一栋大楼里,试图互相沟通、做生意、交换情报。

理想情况是,各国之间关系和睦,大家都有一套明晰的外交规则,只要大家坐在圆桌前,就能顺畅地交流、签署协议、并合作进行国际项目。

但现实却是,每个国家的大使馆互不统属,协议各异,有的只认英制度量衡,有的只收欧元货币,有的说谈判必须用法语,有的则坚持任何通信都要用自家加密算法……

结果,你想跟A国谈一个简单的贸易合作,得先备齐对方要求的一大堆条文、证明、翻译、特殊密钥。如果你还想同时跟B国、C国合作,那就得重复N遍相似的流程。

这种临时的、分散的、多头的各国各自为政,让所有人的沟通成本居高不下,每次对话都要额外缴一份信息关税。

过去,AI世界里的Agent想要合作,都面临一样的窘境。

举个例子,你可能有一个自动帮你帮你回邮件的Agent,还有一个内置在日历应用里的Agent,能帮你安排日程。

但这两个AI很难直接对话,必须得你充当翻译在中间手动复制粘贴信息,或者依赖开发者定制的接口。贼恶心。

结果就是,AI智能体各据山头,互操作性极差,这种碎片化现状让很多用户头疼,因为需要在多个AI应用间来回切换,也限制了AI的潜力发挥,很多本可以多Agent协同完成的复杂任务,被人为隔断在各自的小圈子里。

这种局面下,就有点像二战后世界的状态:每个AI智能体各自为政,缺乏统一规则,互通有壁垒。

当年二战后,也就是1940年代,美国寻求建立一套战后多边机构,其中之一将致力于重建世界贸易,搞了很多轮的谈判。

最后,历经50年,终于1995 年1月1日正式开始运作,依据 1994年马拉喀什协议 ,取代了1948 年建立的关税与贸易总协定。

我们有了人类历史上也是非常伟大的组织:

WTO,世界贸易组织。

而现在AI世界的生态,就有点像二战后的废墟,WTO成立的前夕,你调用我的功能要按我的接口来,我访问你的数据也得敲你定的门路。

没有标准,意味着每增加一种合作关系,都要付出额外“关税”(开发成本和沟通成本)。

AI生态因此变得割裂且低效。

人人设墙,自扫门前雪。

但是还好,在AI圈里也出现了想要制定通用规则的势力,就想大家在贸易混战中渴望一个WTO那样。

AI行业开始探讨能否有一套大家都认可的协议,让智能体之间、智能体与工具之间互相对接更加顺畅。

这时候,Google和Anthropic分别站了出来,各自抛出了一个方案,也就是我们今天的主角:A2A协议和MCP协议。

一. A2A协议

先来看Google发布的 A2A协议

A2A(Agent-to-Agent)协议,顾名思义,就是让AI代理彼此直接对话、协同工作的协议。

这次Google得到了包括Salesforce、SAP、ServiceNow、MongoDB等在内的50多家科技公司的支持参与。

A2A协议的设计初衷很简单:

让不同来源、不同厂商的Agent能够互相理解、协作。就像WTO旨在消减各国间的关税壁垒一样。

一旦采用A2A,不同供应商和框架的Agent就像一个个的小国家,加入了一个自由贸易区,能够用共同语言交流、无缝协作,联手完成单个Agent难以独立完成的复杂工作流程。

至于A2A是如何运作的,我尽量用现实类比来通俗易懂的解释下:

1. Agent = 国家外交官

每个Agent其实就像一个国家大使馆的外交官。他的名牌上写着自己能干啥、隶属于哪家企业,联络方式如何等。A2A要做的,就是制定一个统一的外交礼仪和沟通流程

过去,A国外交官只会说法语,B国外交官只用西里尔字母写文件,C国外交官要求面谈时必须使用古老的云纹金箔信件。。。而A2A的出现,就是让大家在同一个会议室开会时,都能说一套约定好的通用语言,用相同格式提交文件,让商议好的结果可以被各方理解并执行。

2. Agent Card(代理卡) = 外交国书 / 大使名片

在A2A规范中,每个Agent都要公开一份“Agent Card”,相当于其外交官的身份名片。

包含以下内容:Agent名称、版本、能力描述、支持什么“语言或格式”等等。

现实中,外交官的身份名片让对方知道他是谁,代表哪个国家,有哪些职权。同理,在A2A里,Agent Card列举了“我(这个Agent)能执行哪些技能”、“我的认证方式是什么”、“输入输出格式有哪些”等等。

这样,其他外交官想跟你合作就能很快找到你、理解你的能力,省去了大量沟通障碍。

3. Task(任务)= 双边或多边外交项目

A2A中最核心的概念之一是Task。

当一个Agent想委托另一个Agent去完成什么事情,就像对外发布一份“合作项目意向书”。对方同意接单后,双方会记录一个Task ID,追踪项目进度、交换资料、直到该Task完成为止。

现实外交中,某国家就可能向某兔提议:“我们想合作修一条跨境高铁,麻烦你们派工程队来。”

这就对应A2A的Task:由发起方提出需求(TaskSend),远程Agent表示接受(Task状态变更),然后双方在整个项目过程中随时更新任务进度

里面还有个Artifacts(成果物),就相当于这个项目最后落地的“合同文本、建设成果”。在AI里可能是生成的一份报告、一张图片或任意形式的输出。而在A2A语言里,用 Artifact 表示最终生成的成果。

Message(消息),则是项目前期或中期的各种来回沟通。它可能包含对任务细节的补充说明、要对方再确认某些条件等。这与现实外交中的电报、照会、使节往来是一模一样的。

4. Push Notifications(推送通知)= 外交使馆快报

在A2A里,如果一个Task是长期项目,远程Agent需要花很久时间才能完成,比如DeepResearch动辄十几分钟,某些复杂的Agent动辄一小时,它就可以通过推送通知机制向发起方更新进度。

就像在外交中,如果一个跨国基建项目周期很长,甲国会定期给乙国发通报:“进度到哪儿了?有什么问题需要协调?”

这样能大幅提升异步协作的能力。过去很多AI系统比较原始,只能用同步的“请求-响应”模式,就像放一个人在那24小时监控,一旦响应超时就中断。

A2A允许设置回调接口、服务器端事件(SSE)等方式,把漫长的任务分段汇报,让沟通保持流畅。

5. 身份认证与安全= 外交特权与协议

A2A采用企业级的认证策略,要求通信双方先验证对方的身份凭证。例如在现实外交中,不是谁都能随意闯进某国大使馆,必须持有相应的外交护照、获得许可。

这就是为了防范“冒名顶替”或“恶意窃听”。

在A2A里,“认证头信息”“token”“签名”等一系列安全手段,就相当于外交通行证或盖了公章的外事批准文书,确保你跟我谈判时是真的代表“你所在的国家”,而不是一个假冒的第三方。

这大概,就是A2A的机制,其实你看,跟国与国的外交,或者跟企业与企业之间的协同,没有任何本质的区别。

二. MCP协议

再来看MCP协议,全称Model Context Protocol

这就是Claude的母公司Anthropic在2024年11月推出并开源的一套标准。

A2A解决了AI外交官之间的交流流程问题,但是还有一个棘手的现实,再能言善辩的外交官或者企业商务,要是没有任何可靠的信息来源,对国际局势和资源配置就两眼一抹黑,根本就没法干活。

更何况,在现代社会,外交官往往需要调用种种外部工具,比如签证系统、国际结算系统、情报数据库等等,才能完成任务。

同理,一个Agent若想承担真正的复杂职责,也需要能连上各种数据库、文档系统、企业应用,甚至是硬件设备。

这就像给外交官建立完备的情报局,并授权他们使用某些工具处理事物。

过去,Agent要接入外部资源,常常得各自开发专用插件,与不同工具做深度整合,劳心劳力。

但是,我们现在有MCP了。

MCP致力于标准化大型语言模型(LLM)与外部数据源、工具之间的交互方式。Anthropic的官方比喻很形象:MCP就像AI应用程序的USB-C端口

USB-C是如今设备通用的接口,不管充电、传数据都是一个口搞定。

MCP的野心也是这样的,搞一个AI领域的万能接口,让各种模型和外部系统接驳都用同一个协议,而不是每次另写一套集成方案。

以后AI模型要连数据库、连搜索引擎、连第三方应用,不用每家各订各的协议,只要都支持MCP就能对上话。

它大概是客户端-服务器架构的思路:

1. MCP服务器= 整合的情报局

企业或个人可以把自己的数据库、文件系统、日历、甚至第三方服务封装成一个个“MCP Server”,这些Server符合MCP协议,向外暴露统一格式的访问端点,任何Agent只要符合MCP客户端标准,就能发送请求、检索信息或执行操作。

比如高德就把自己的一些API,封装成了MCP,只要你有高德的API Key,你就可以在Agent上调用高德。

2. MCP客户端 = 外交官实际使用的终端设备

就像一个Agent外交官带着专用的终端设备,可以输入各种指令:“帮我查一下财务系统里库存数据”、“帮我向某个API提交请求”,“把某份PDF拿来我看看”。

过去,如果没有MCP,你得针对各种系统写不同的访问代码,整合起来极其麻烦;但是用了MCP后,只要客户端支持协议,就能轻松切换到不同的MCP服务器。

调用不同的信息,随时获取情报、做业务流程。

这大概,就是MCP的机制。

三. A2A和MCP的不同

抽象讲了很多,可能很多人,还是有点云里雾里。

别急,我们通过一个故事化的场景来把A2A和MCP的区别与合作说明白。

比如我们现在,有一个世界版的国际峰会。

各国首脑其实是各家公司的Agent代表,比如谷歌代表是小G,Anthropic派出了小A,OpenAI来了个小O,国内的阿里派出小Q,腾讯派小T等等。大家齐聚一堂,要合作完成一项跨国任务,比如联合写一份全球经济分析报告。

在没有通用协议之前,这会基本开不起来,因为每个代表讲自家语言,互相听不懂。

但现在好了,有了A2A协议这套外交标准,所有代表进入会场前都签了《A2A维也纳外交公约》:发言必须用统一格式,说话先报身份、标明意图,回应要引用之前的发言ID等等。

于是,小G可以正式地用A2A格式发消息给小O,小O收到后依样画葫芦地回复一个A2A消息。这样,不同公司的AI首次实现了无障碍对话。

二对话进行中,各位AI代表难免需要查阅资料或使用工具帮助分析。

这时候Anthropic的小A说:“各位,如果需要外部数据或工具的支持,可以通过MCP系统获取。”

原来,会场边上还架设了一套“MCP同声传译室”。里面坐着各种专家(对应不同的MCP服务器)。

有谷歌Drive资料馆管理员、有Slack聊天记录管家、有GitHub代码管家,甚至还有Postgres数据库管理员…只要通过MCP提请求,他们就能用统一语言回应。

比如,小Q(阿里云代表)想调自家云端数据库算点东西,如果按老办法,他得派人打个飞的回国去拿。

现在他直接在会上发送一个MCP请求(这请求其实也是按MCP定义的JSON格式发给对应的MCP Server):

“我要查询X数据库里的Y数据”。

MCP数据库管家翻译室收到请求,立刻查库拿到结果,用MCP语言回复给小Q。

整个过程对其他Agent来说是透明的,他们也听懂了小Q引用的这份数据,因为MCP翻译过来的格式大家都认识。

继续写报告过程中,小G(谷歌)和小A(Anthropic)发现需要把各自部分内容对接起来分析。

小G擅长数值分析,小A擅长语言总结,那就协作:

小G通过A2A对小A说“我这边算完GDP增速了,数据如下”,小A收到后,在自己这边通过MCP又连了一下Excel表格插件,验证了数据趋势,然后再用A2A回复小G一个总结段落……

一来二去,A2A让Agent彼此沟通任务,MCP让每个智能体方便地调用外部工具补充信息,两套协议配合默契,报告很快完工。

这个故事中,大家可以清楚地看到:

A2A更像外交部专线,解决的是Agent直接对话的问题。

MCP更像同声传译与资源共享系统,解决的是智能体对接外部信息的问题。

两者配合起来,就是为AI版联合国量身打造的沟通协定。有了它们,AI Agents可以各展所长又紧密合作,真正形成一个互联互通的AI生态体系。

写在最后

当A2A和MCP这样的开放协议逐渐统一标准之后,我们有理由畅想一个全新的AI Agent生态。

无数AI Agent像网站一样部署在各处,它们通过A2A协议彼此发现、通信,通过MCP协议调动资源、分享知识。

我们作为用户,就像当年浏览网页一样,可以无感知地使用这些智能体的协同服务。比如,你的个人AI助理Agent接受了你的复杂委托:

“帮我计划一次欧洲旅行,顺便写一篇游记稿件。”

它不会单打独斗,而是迅速通过A2A喊来各路好手:旅行规划Agent、航班预订Agent、翻译Agent、文案Agent……

大家分工合作,各显其能。

正如我们希望国家间少打贸易战、多订规则,AI领域我们也乐见各家少搞闭关锁国,多推行兼容协议。

A2A和MCP的崛起,意味着AI产业已经在朝着协作而非对抗的方向进化。

现实世界,和AI世界,明明是一体,确实两种趋势。

真是讽刺。

最后,希望这篇文章,对你有一些帮助。

以上,既然看到这里了,如果觉得不错,随手点个赞、在看、转发三连吧

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2025-04-10,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 数字生命卡兹克 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
开源后台管理系统 (go-vue-admin)
https://github.com/guyan0319/go-vue-admin
孤烟
2024/02/12
7680
浅学前端:Vue篇(五)
这里选择了 vue-element-admin 这个项目骨架,它采用的技术与我们之前学过的较为契合
传说之下的花儿
2023/11/15
2390
浅学前端:Vue篇(五)
Jeecgboot-Vue3 v1.0.0 版本正式发布,基于代码生成器的企业级低代码平台
Jeecgboot-Vue3 采用 Vue3.0、Vite、 Ant-Design-Vue、TypeScript 等新技术方案,包括二次封装组件、utils、hooks、动态菜单、权限校验、按钮级别权限控制等功能。 是在 Vben-Admin 基础上研发的,适合于JeecgBoot的新版前端VUE3框架。
JEECG
2022/03/21
1.4K0
Rainbond 中Vue、React项目如何调用后端接口
通常我们会在项目的全局配置文件.env.production中直接写入后端ip,例如:
曾庆国
2020/11/19
1.6K0
Golang: gin-vue-admin框架介绍
gin-vue-admin基于gin+vue搭建的后台管理系统框架,集成jwt鉴权,权限管理,动态路由,分页封装,多点登录拦截,资源权限,上传下载,代码生成器,表单生成器,通用工作流等基础功能,五分钟一套CURD前后端代码,目前已支持VUE3,欢迎issue和pr~
OwenZhang
2021/12/08
1.9K0
Golang: gin-vue-admin框架介绍
若依
(adsbygoogle = window.adsbygoogle || []).push({});
P轴
2022/12/02
1.5K0
聊聊 ruoyi-vue ,ruoyi-vue-plus ,ruoyi-vue-pro
笔者在知乎、Github 上搜索快速开发框架时 ,很多的话题都绕不开若依 RuoYi 。
勇哥java实战
2025/05/08
8190
聊聊 ruoyi-vue ,ruoyi-vue-plus ,ruoyi-vue-pro
TienChin 运行 RuoYi-Vue3
在前几篇文章当中,之前使用的是 Vue2,在某一天发现若依提供了 Vue3 的版本,所以这篇文章主要是运行起来,Vue2,迟早要被替代,所以这里采用最先进的 Vue3。
程序员NEO
2023/10/12
2010
TienChin 运行 RuoYi-Vue3
vue 项目中自定义布局与左侧菜单及路由跳转功能的实现(简易版)
在 Vue项目中,实现自定义布局与左侧菜单及路由跳转功能,对于笔者这种不是精通前端开发的同学一向是比较困难的。以前都是在开源项目的基础上扩展自己的功能,比较著名的开源项目 vue-element-admin 就是开源项目的作者通过定义实现的左侧菜单和路由跳转的。不过 vue-element-admin 项目使用的 vue 版本还停留在 vue2,现在市场上新项目普遍都用 vue3 技术了, 但是 vue-element-admin 项目也相应地出了 Vue3 版本,对应的 gitee 仓库地址为:https://gitee.com/youlaiorg/vue3-element-admin.git
用户3587585
2024/05/10
2.1K0
vue 项目中自定义布局与左侧菜单及路由跳转功能的实现(简易版)
一个非常适合前端后管系统的vue3项目
vue3-element-admin 基于 Vue3、Vite、TypeScript 和 Element-Plus 搭建的极简开箱即用企业级后台管理前端模板。 配套 Java 后端 youlai-boot 和 Node 后端 youlai-nest 。 提供开发简版vue3-element-template 和 JS 版本vue3-element-admin-js 供开发者快速开发。
BUG弄潮儿
2025/04/15
1430
一个非常适合前端后管系统的vue3项目
Vue + .NetCore前后端分离,不一样的快速发开框架(提供Vue2/Vue3版本)
整个只读的基础表单的所有前后端代码,全部由代码生成器生成,代码生成器中几乎不需要配置,并支持并后端业务代码扩展,直接生成代码后,配置菜单权限即可
沙漠尽头的狼
2022/04/18
2.7K1
Vue + .NetCore前后端分离,不一样的快速发开框架(提供Vue2/Vue3版本)
Ruoyi框架深度实践与技术解析
Ruoyi(若依)作为基于Spring Boot + Apache Shiro + MyBatis的快速开发平台,支撑了我们多个企业级中后台系统的快速落地,涵盖OA、CRM、ERP等场景。
用户3171739
2025/05/13
1461
猫头虎分享:已解决RuoYi-Vue3 项目代码生成器默认生成代码使用的Vue2模板代码问题与Vue2升级到Vue3解决方案
🔍 在本篇技术博客中,猫头虎博主将深入探讨RuoYi-Vue3项目中的一个常见问题:代码生成器默认使用Vue2模板代码。我们将分析此问题的具体表现、对开发的影响,并提供详细的解决方案。本文涉及Vue2与Vue3的差异、代码修正方法和模板替换指南,旨在帮助开发者快速适应RuoYi-Vue3环境。无论您是前端初学者还是资深开发者,这篇文章都能为您提供宝贵的参考。关键词:RuoYi-Vue3, Vue2, Vue3, 前端开发, 代码生成器, 模板替换, 技术解决方案。
猫头虎
2024/04/09
1K0
猫头虎分享:已解决RuoYi-Vue3 项目代码生成器默认生成代码使用的Vue2模板代码问题与Vue2升级到Vue3解决方案
SpringBoot版的低代码开发平台,关联无 SQL,性能高10倍!
你好,我是 Guide。今天在逛开源社区的时候,发现了一个基于 Spring Boot 技术体系的低代码开发平台 Diboot 挺有意思的,号称“关联无 SQL,性能高 10 倍”。
Guide哥
2023/01/16
1.4K0
基于.NET8 + Vue/UniApp前后端分离的快速开发框架,开箱即用!
今天大姚给大家分享一款基于.NET8 + Vue/UniApp前后端分离的快速开发框架,开箱即用:ZR.Admin.NET。
追逐时光者
2024/10/17
3910
基于.NET8 + Vue/UniApp前后端分离的快速开发框架,开箱即用!
推荐20+好用的开源管理端项目
开源的管理端项目可以帮助我们快速构建应用,在这里推荐20+好用的开源管理端项目给到大家参考。
码之有理
2023/06/08
1.5K0
盘点6个WebAPI+Vue前后端分离的.Net开源项目
今天我们一起梳理下6个,比较受到大家欢迎的.NetCore+Vue前后端分离的开源项目。
郑子铭
2025/05/26
1910
盘点6个WebAPI+Vue前后端分离的.Net开源项目
用这些后台管理模版后,三天完成项目!
你是否遇到过PM今天丢给你一堆后台管理系统的需求文档,并说这个产品下个星期上线没有问题吧!
@超人
2021/09/17
1.3K0
用这些后台管理模版后,三天完成项目!
基于一个SpringBoot + Vue的代码生成项目,支持多种前后端组合
ALTER TABLE gen_table ADD COLUMN front_end varchar(30) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '前端框架' AFTER options;
小熊学Java
2022/09/04
1.1K0
Jeecgboot-Vue3 v1.2.0 版本正式发布,企业级低代码平台
Jeecgboot-Vue3 采用 Vue3.0、Vite、 Ant-Design-Vue、TypeScript 等新技术方案,包括二次封装组件、utils、hooks、动态菜单、权限校验、按钮级别权限控制等功能。JeecgBoot企业级的低代码平台对应的vue3前端版本!
JEECG
2022/06/07
6460
推荐阅读
相关推荐
开源后台管理系统 (go-vue-admin)
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档