MCP会被谷歌的 A2A“吃掉”吗?
MCP (Model Context Protocol)作为连接大模型与外部工具的通信协议,近期因谷歌推出 A2A(Agent-to-Agent)协议引发争议。
MCP 凭借其简洁的设计和 OpenAI 等巨头的支持,迅速成为大模型与外部工具交互的事实标准。其核心价值在于解决了两个关键问题:一是标准化接口:将工具能力封装为统一的函数描述(如 API 格式、参数定义),降低模型调用复杂度;二是上下文管理:通过动态维护工具调用记录,辅助大模型生成连贯的操作链条。
这种“模型中心化”的设计思路,使其在开发者中广受欢迎。然而,随着谷歌推出 A2A协议,MCP 的“护城河”开始遭遇挑战。
MCP 能否抵御谷歌 A2A 的生态攻势?不久前,开源中国举行了一场以 “全网爆火的 MCP 到底是啥?” 为主题的直播,业内专家对这个问题进行了讨论。
谷歌的生态围剿:A2A 的“包裹战术”
谷歌的入局让战局陡然升温。A2A出现之后,MCP自身的定位成为关键:它是想变成A2A体系下的附属品,还是说它也想升到和A2A平级的位置?
A2A 协议直指智能体(Agent)间的高阶协作场景。Bytebase联合创始人兼CEO陈天舟认为,如果MCP想上升到A2A层面,胜算很小,因为必须这要有应用场景支撑。“MCP背后的公司Anthropic主要做模型基础设施层,本身没有应用。但谷歌不一样,A2A 发布时候,就把应用层厂商都集中起来了,生态优势很大。”根据公开信息,A2A 首批合作企业包括Salesforce、SAP、ServiceNow、MongoDB、Intuit、Workday、德勤、埃森哲等全球顶级企业应用平台,覆盖金融、零售、医疗、供应链等多个领域。
陈天舟指出,现在A2A和MCP的关系,有点像当年云原生时代谷歌经历的K8s和Docker的关系。而A2A 的野心,类似 Kubernetes 对 Docker 的替代路径——先兼容 MCP,再通过上层生态完成“包裹式替代”。“不过,谷歌应该吸取了当年对Docker反应太慢的教训,这次对MCP反应很快——它用更接近应用层的抽象协议把MCP包裹起来了。现在这种情况下MCP如果不集中精力巩固地位,反而继续突围的话,下一步可能真的会被谷歌这个协议体系收编。”
智能体通信协议ANP作者常高伟认为,长远来看,如果未来所有工具都实现智能体化,那么A2A可能直接绕开 MCP 的交互场景,逐渐侵占MCP的份额。MCP甚至有可能被彻底干掉。
Gitee 私有云产品总监林靖靖对MCP的未来持悲观态度。他认为,MCP目前的作用是连接大模型和工具,但随着A2A协议的出现和工具智能化、Agent化的发展,MCP可能会被取代。“大模型的交互方式可能会变化,上下文处理可能不再集中在MCP,未来Agent可能直接通过"上下文封装+预处理"与大模型交互,而无需经过MCP的"任务标识触发"机制。
这就导致MCP的战略困境面临两难选择:如果收缩战线专注大模型交互优化,很可能被A2A协议架空;如果冒险拓展Agent间交互场景,这需极高投入且成效存疑。“结果就是可能哪个方向都没吃透,最终被边缘化。”林靖靖如此预测。
Gitee 公有云技术负责人罗雅新则看好 MCP 作为“USB 式标准”长期存在,因其解决了工具调用的标准化问题。他认为,MCP和A2A是解决不同场景的方案:前者是基础连接标准,后者是生态交互协议,二者可以并存发展。“无论Agent如何进化,要减少幻觉就必须与现实世界交互,获取事实数据。通过MCP这种标准化协议实现数据调用,既便利又可复用,各个Agent都能采用统一方式接入。MCP只要持续解决关键问题(比如传输效率这类基础能力提升),就有长期存在的价值,就像USB历经多代升级仍保持核心价值。当然未来可能出现更好的协议替代它,但设备互联的场景需求不会消失。这本质上不是生态构建,而是协议标准的建立。”
现在的问题是,虽然MCP已集成主流工具扩展能力,但存在明显局限。罗雅新解释,当使用超过40-60个context时,系统就开始崩溃,有些客户端甚至直接限制数量。这导致人为筛选 context 时面临困境:面对海量MCP接口,用户根本不知道哪些该喂给模型,而模型自身也缺乏主动发现和筛选能力。不过如果进化到Agent间交互,协议层——比如谷歌发布的A2A协议,应该能解决这个问题。
“Agent间交互,这才是真正的生态问题”。罗雅新认为,每个Agent都有特定业务场景和商业诉求,是否与其他Agent协作需要市场博弈。A2A协议现阶段可能不是爆发时机,更像是提前布局。当单个Agent无法满足用户完整需求时,自然会产生交互需求,生态才会逐步成型。
长远地看,MCP会消亡?
也有人认为,MCP 面临的最大危机,可能不是A2A ,而是AI 不断发展,具备一定程度智能后,已经不需要任何协议。
“长远来看,MCP这类协议终将消失。”陈天舟认为,现阶段之所以需要MCP,本质上是因为当前智能体的认知能力有限。“当AI发展到足够智能的阶段,除了原始数据资源本身,所有中间层的协议规范都会失去存在价值——足够强大的智能体完全可以自主理解数据。我们不再需要像绘制地图、编写说明书那样,通过数据加工来指导智能体获取信息。考虑到AI的发展速度,或许根本不需要三到五年,这类过渡性协议就会退出历史舞台。”
作为数据库从业者,Pigsty 作者冯若航注意到,微软CEO Satya Nadella在不久前的演讲中也提到类似趋势:未来应用范式可能是Agent直接对Database进行CRUD操作。如果智能体真能实现原生数据理解能力,中间协议层确实可能被绕过——最终形态将是Agent与Database的直接对话。
字节跳动技术专家刘康认为,MCP能否繁荣不取决于它自身的表现,而是取决于Agent范式本身能否成功。若三到五年后 Agent 未成主流,MCP 仍会是工具层的最优解。
“当前MCP受关注的根本原因,是整个行业注意力转移到了Agent范式——前几年大家聚焦预训练模型,现在应用层开发者开始转向Agent架构。但关键在于,Agent能否真正形成繁荣生态?这个命题本身仍然存疑。
“我们不得不思考:这个范式未来是否会被新范式取代?现阶段MCP协议的热度完全依赖于大家对Agent范式的预期。至于三五年后的发展,时间跨度其实非常微妙。如果用最乐观的AI发展视角来看,届时可能已经实现AGI(通用人工智能)——如果真到那个阶段,MCP是否存在根本无关紧要,就像今天我们不再关心CPU总线协议的具体实现。“
回到现阶段,高常伟认为,Agent 协议正确的技术路线确实是工具化——MCP完全契合当前发展需求。下一步无论是A2A还是ANP协议,本质上都是为未来布局。目前智能体生态尚不成熟,通信协议都处于早期研究阶段。但正因如此,现在正是制定标准协议的关键窗口期。“至于更远期的未来,当AI发展到高级阶段,人类设计的协议可能反而成为限制——也许智能体自主协商的协议会更高效,就像牛津大学提出的自然语言协商协议。让每个Agent暴露自然语言接口,通过对话协商交互协议。这种动态协议机制正是ANP框架支持的演进方向,是未来的主流。”
MCP的生存之道:技术做减法与生态做加法
在技术上,大家一致认为MCP应该做减法。
“我认为当前协议架构需要简化,特别是客户端采样这类冗余设计。”常高伟解释,虽然理论上存在应用场景,但实际几乎没有客户端使用该功能,建议直接精简。另外服务端访问客户端文件的设计也值得商榷——这种双向访问机制导致服务端与客户端耦合度过高,这是审阅协议时最突出的问题。理想状态应该是服务端与客户端保持松耦合关系。
陈天舟的观点可能更为激进:“。我认为应该全面移除所有与鉴权相关的功能,将其移交交基础设施层,专注核心通信逻辑因为我们本质是数据库系统开发者,应该回归数据库最核心的架构逻辑来看待这个问题。”
具体来说,MCP当前的核心任务应该是明确定义关系型数据库的基础函数集,并基于这些关系函数构建类SQL的标准语法体系。但需要澄清的是,鉴权机制本就不属于SQL层的职责范畴,而是应该由数据库管理系统(DBMS)承担的基础设施功能。现阶段需要聚焦于关系型数据库最核心的组件。
“需要重点构建的是关系函数集与SQL语法体系这两大支柱,除此之外的附加功能都应该被精简。从当前架构评估,建议保留三个核心模块:现有的资源定义工具、查询解析器、执行引擎,同时必须完善路由功能,即可构建出符合数据库本质的最小化核心架构。
而在建生态这个方向上,要做加法,从解决"工具发现难""开发者动力弱""分发渠道散"这三大问题入手。
模型如何自主发现执行任务所需的context?当前已经出现的MCP工具市场(marketplace)或许能提供解决方案。但接下来的问题是,这些资源应该直接开放给模型调用,还是需要人工筛选?罗雅新观点是:最终应该建立Agent可直接调用的注册中心(registry),让智能体能自主发现所需的context资源或MCP服务节点。这才是作为终端用户真正需要的技术实现路径。
刘康认为,从生态发展角度观察,MCP协议落地的关键在于降低接入门槛。作为开发者,最期待的是更完善的开发工具链——当前协议设计明显偏向模型所有者(Model Owner),资源提供方(Tool Developer)的接入收益相对滞后。虽然长期看双方都能获益,但以模型为中心的架构天然会导致资源侧动力不足。
因此,要推动MCP社区繁荣,必须解决工具开发者的核心痛点:提供极简转换工具,比如将现有REST API一键迁移为MCP接口的自动化方案。只有让资源拥有者以最小成本接入协议,才能真正激发生态活力。这本质上是在模型中心和技术普惠之间寻找平衡点,而开发体验的优化正是破局关键。
林靖靖指出,从当前MCP的分发机制来看,最关键的缺失是统一的"应用商店"角色。目前各家MCP工具/客户端都在构建自己的marketplace。“开发者开发完MCP客户端后,不得不面对多平台分发的困境——需要同时在十几个渠道部署维护,这种碎片化状态严重制约生态发展。应该要有一个聚合平台。至于该平台由谁来主导,不论是云服务商、还是模型厂商,亦或是代码托管平台都有机会尝试。现阶段正处于格局未定的窗口期。不过,最终可能通过市场竞争自然筛选出用户信任度最高的平台。”
所有协议都是时代的产物。这场关于 MCP 的争论,或许正是 AI 技术从“工具时代”迈向“智能体时代”的序章。短期来看,MCP 需警惕谷歌的“生态降维打击”,在工具层构筑技术壁垒;长期来看,协议的价值终将取决于能否顺应 Agent 范式的进化——是成为智能世界的“基础设施”,还是沦为过渡期的“临时脚手架”。
微信扫码,观看直播回放:
【数智漫谈】
OSCHINA 视频号直播畅聊栏目【数智漫谈】,每期一个技术话题,三五位专家围坐,各抒己见,畅聊开源。给大家带来最新的行业前沿、最热门的技术话题、最有趣的开源项目、最犀利的思想交锋。如果你手上也有新点子、好项目,想要跟同行交流分享,欢迎联系我们,讲坛随时开放~

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
国产替代 + 大模型推理优化,AI 产业发展需要强大的基础设施
在人工智能迈向「智算融合」的新时代,大模型凭借其强大的认知与推理能力,正逐步重塑千行百业的智能化图景。然而,大模型推理环节的高算力消耗、高延迟与高能耗问题,成为其规模化落地的关键掣肘。破解这一瓶颈,既需构建高效能、低时延的算力基础设施,也依赖从芯片到应用的全产业链协同创新。 与此同时,在全球化技术博弈与数字化转型的双重驱动下,中国AI产业也正在经历一场从硬件底座到软件生态的"全栈重构"。许多厂商纷纷转入以昇腾(Ascend)计算平台为基础的生态之中。昇腾作为国产AI算力的核心引擎,通过软硬件协同优化与异构计算架构创新,为大模型推理提供了高效能、低时延的部署方案。 随着昇腾在企业中的采用率持续攀升,加之基于其底层基础设施的大模型应用生态日趋完善,OSCHINA邀请某国企人工智能技术负责人,公众号“数学建模岛”主理人熊文韬一起聊了聊关于国产算力替代的真实挑战和基于昇腾的大模型推理优化的几个路径,以期为国产AI技术栈的构建提供可复用的经验样本。 国产化替代并非简单的设备更换,还需生态加持 国产化适配是国企数字化转型中的核心命题。熊文韬介绍,早期项目多采用英伟达GPU架构,但随着昇腾等产品的性...
- 下一篇
在Oracle到GreatSQL迁移中排序规则改变引发的乱码问题分析及解决
一、引言 某老系统数据库从 Oracle 迁移至 GreatSQL 过程中,首批迁移(存储过程、表结构、基础数据)顺利完成。然而,第二批数据迁移时出现主键冲突问题:原Oracle数据库中存在主键字段A与a(忽略大小写后视为相同值),但 GreatSQL 默认排序规则 utf8mb4_0900_ai_ci 不区分大小写,导致主键冲突。 为解决此问题,将排序规则调整为 utf8mb4_0900_bin 以区分大小写。但调整后,Java程序读取中文字段时出现乱码(如“好”显示为“好”),直接影响业务功能。本文从环境兼容性、驱动版本、字符编解码机制等角度深入分析问题根源,并提供三种解决方案。 二、环境说明与问题背景 关键组件版本: 组件 版本号 备注 数据库 GreatSQL 8.0.32-26 默认字符集utf8mb4 jdk 1.7.0_80 旧版本,升级成本高 驱动版本 mysql-connector-java 5.1.46 官方已停止维护 字符集 utf8mb4 未变动 排序规则 utf8mb4_0900_ai_ci->utf8mb4_0900_bin 变更后引发乱码 核心矛...
相关文章
文章评论
共有0条评论来说两句吧...