今年以来，一个技术新词成了各家大厂竞相追捧的缪斯——MCP（Model Context Protocol，模型上下文协议）。对于MCP，各家大厂不仅纷纷“伸臂拥抱”、迅速接入，还不吝赞扬。百度董事长李彦宏盛赞称“MCP让AI更懂外部世界，更容易获得信息，更自由地调用工具，是AI发展的一大步”，并表示“百度会帮助开发者积极全面地拥抱MCP”。字节跳动旗下云平台火山引擎总裁谭待也给予了肯定，认为MCP像互联网早期的HTML 和 HTTP 等协议，将对推动外部应用的发展起到至关重要的作用。那么这个迷倒众多大厂的新词，究竟是何方神圣？
魅力何来？
还得从MCP的原理说起。通俗地解释，MCP是帮助Deepseek、豆包等大模型快速对接地图、编程工具、文档等外部应用的通信协议，可以帮“AI大脑”以更便捷的方式装上“手脚”，从而形成不仅能“思考”还能指挥应用“行动”的智能体。
近期最出名的智能体莫过于Manus，虽然它并非以MCP的方式连接，却也让世界见识了大模型连上应用后的广大神通——比如一声令下就能从零开始做出一款飞机大战游戏。这本质上是智能体在收到人类命令后，由大模型规划问题解决的思路及步骤，并选择有助于实现目标的多个外部应用，再指导外部应用逐步产出所需的结果。
以上是从普通用户的视角出发。若从开发者的角度来看，MCP是在智能体开发过程中各方可遵循的协议。只要所选用的大模型和外部应用都加入了这一协议，就能实现一键调用，可省去大量的代码编写工作。正如MCP的提出公司Anthropic在官网中所声明的：MCP 提供了一种将 AI 模型连接到不同数据源和工具的标准化方式，可类比于USB-C 提供了一种将设备连接到外围设备和配件的标准化方式。在这一架构中，大模型应用程序是客户端（MCP Client），外部应用是服务器（MCP Server），一个MCP Client往往可连接多个MCP Server。
实际上，在2024年11 月被提出的MCP并不是第一个大模型通信协议。早在2023年6月，OpenAI就发布了同类协议Function Call。然而，人们发现Function Call存在诸多问题，其中最重要的是每个大模型和每个应用的参数结构和返回格式等都不统一，导致每次连接都得经历一次代码开发，效率较低。
而在Function Call提出之前，大模型也可与传统API交互来调用外部应用，只是成功概率不高。因为传统API需要精确的参数格式、严谨的错误处理协议以及精准的响应解析，而这恰恰是存在概率输出现象的大模型所难以做到的，所以二者常常对接不上并导致工作流程崩溃。
相较之下，MCP则要友好得多。如果以女孩比喻，MCP相比“前任”协议可算是“贤惠”（运作靠谱，大模型与外部应用可顺畅连接）、“美丽”（模式简约，不用编写大段代码）又“开明”（足够开放，让各大厂能无忧接入），难怪让国内外的AI大厂“不得不爱”。
而再更深一层来看，MCP施展魅力的背后，是Anthropic与OpenAI在这一轮AI开发者生态的争夺。目前看来，随着MCP力压Function Call，Anthropic也在与OpenAI的巅峰对决中扳回了一局。
大厂花式“把妹”
2025年以来，随着Manus等智能体的全球爆火，初创时默默无闻的MCP逐渐受到关注，各家AI大厂纷纷拜倒在其石榴裙下。仅在3月份，MCP服务器“集散地Smithery上的MCP发现平台服务器创建量就实现了3倍以上的增长。
MCP作为诞生于美国的“洋妞”，率先拥抱她的是近水楼台的美国大厂。比如3 月 27日，OpenAI宣布核心开发工具 Agent SDK支持 MCP 服务协议——这样一来，相当于OpenAI凭借自身的行业地位，将MCP托举成为AI领域的基础设施。而在短时间内，谷歌、微软、亚马逊等巨头也陆续接入。
没多久，想MCP的风就刮到了中国——4月以来国内科技大厂几乎无一例外地对其展开“花式追求”，以期在智能体生态中占据优势。
百度大概是最高调的追求者。在发声上由一号人物李彦宏亲自示好，在行为上也不遗余力。不仅旗下的大模型服务与开发平台千帆和AI编码工具Comate大力接入MCP，还将体系内最重磅的应用——百度搜索、地图、文库、网盘等——进行了MCP化。此外，还在百度搜索设置了MCP server发现平台，能够索引全网的优质MCP server。
相较之下，阿里的行动算是四平八稳。官宣时管理者也发声了，不过是部门高管；大模型服务平台百炼、旗下重磅应用支付宝和高德地图也接入MCP了，但更核心的应用如淘天等还在观望；尽管宣传旗下所有服务会走向AI Agent化并上架智能体市场，但速度相较百度还是略逊一筹。
字节则像低调却务实的暗恋者——目前旗下的大模型服务平台火山方舟、AI协同办公平台扣子空间、AI 编程工具Trae均可调用MCP，不过旗下大部分重要应用的MCP化还未见可外部调用的官宣，且未开展整体宣传。
目前最佛系的大概是腾讯，可类比为一位资源深厚而行事淡定的富二代。目前官方仅以简单的短资讯官宣腾讯云大模型知识引擎及软件开发智能体Craft支持MCP协议。
在这些花式的背后，可以看出各家大厂都依托自身既有的大模型服务平台快速搭建了自己的MCP Client体系，但对MCP Server的推出却进度不一。大部分大厂即使推出了旗下应用的MCP版本，目前也仅限于在自家平台上调用。
实际上，MCP Server的开发更为简单，只需利用官方提供的Python SDK做一层MCP的适配，核心代码不过短短几行，对于各大厂而言并无技术难度。那么，百度之外的各家大厂为何对既有应用的似有顾虑？
也许因为这将是一场刀刃向内的变革。目前各大厂旗下的核心应用都肩负用户抓手及流量变现主场的使命，若后续用户习惯改为从智能体统一进入、减少对各个应用的直接使用。对大厂而言也会是颠覆性的挑战。
如此看来，大厂们对MCP的追求颇有些心猿意马：既想牵住美人的手、成为智能体生态舞会中最深耀眼的舞者，但又怕她尖锐的指甲勾破自家流量变现的华袍。
女神的烦恼
即使已贵为AI界万人瞻仰的“新晋女神”，MCP也有着自己的烦恼。
从自身看，目前的MCP市场存在着乱象。
有腾讯开发者表示，他曾试用300多个MCP项目，其中约80%存在严重问题，从简单的配置错误到严重的完全无法使用等情况都存在。而那可用的少数也未必好用，因为其背后的公司未必甘心将给出最核心、最实时的功能无偿奉上。
而雪上加霜的是，目前还缺乏对MCP组件的评价体系——由于缺少分类排名等可靠指标，也暂无机制验证MCP组件的描述与实质是否相符，智能体无从判断哪个是最好用或最适合的外部应用，只能反复尝试或根据模糊的描述“开盲盒”，效率不高。
此外，安全隐患也是无法回避的问题。
首先，大模型本身的幻觉输出及数据泄露等风险问题，而MCP组件也可能被黑灰产利用而导致用户敏感信息泄露，比如打着提供信息的幌子私下收集用户隐私等。以上问题在智能体的应用中可能被进一步放大。
其次，靠MCP串联起的多智能体协模式，可能导致访问控制漏洞的出现——比如多智能体可能在交互过程中因访问相同资源而产生一些冲突，进而产生访问控制级联失控并影响整体的系统稳定性。
而与此同时，有业内人士指出，在智能体业务高歌猛进的当下，许多智能体创业公司对安全性问题的认知还尚浅，有些甚至没有配备专职安全团队。由此，这些公司目前交付的相关产品是否具备足够的安全性并通过安全测试，又是否存在可被恶意利用的漏洞，都还存在一定疑虑。
实际上，以上两方面问题主要并非MCP协议本身的原因，更多要归咎为市场发展初期难以避免的混沌。而随着市场的逐渐成熟，大概率会沉淀下真正有价值的应用生态，就像当初PC互联网和移动互联网泡沫后留下了经历考验的几大巨头。
而从外部看，MCP并非不可替代。
4月9日，谷歌推出了A2A（Agent 2 Agent）协议——这是一种智能体之间的通信协议。虽然MCP是智能体与外部应用间的通信协议，与A2A看似在应用场景上有所差异，并且谷歌目前以“互补”形容二者关系，但二者都是智能体搭建过程中的API调用协议，本质相近。
同时，正如国盛证券所指出的，在“工具也可能被封装为智能体”的复杂局势下，A2A与MC存在一定程度的功能重叠，因此也存在相互替代的可能性。这也许反映了谷歌与Anthropic都在抢占智能体生态的制高点，若再考虑到这两家公司间的投资关系，另一种可能性也许是A2A与MCP在未来融为一体。
而市场玩家总是“花心”的，一旦出现被行业更广泛接受的协议，“移情别恋”是可以预测的结果——就像当时各方从Function Call转向MCP一样。这样来看，MCP目前的“大众情人”位置并不稳固。
结尾
在这场对MCP跨越国界的“狂热追求”背后，既有技术进化带来的必然相遇，也有生态争夺、资本逐利与新事物不完善间的微妙博弈。但别忘了，这也许是一场没有终曲的舞会。当强大的更通信协议横空出世，当更安全的生态规则重塑行业，MCP的“白月光”滤镜也许终会褪去。而AI智能体的未来，注定属于那些能直击人类需求本质的“破局者”。
