后MCP时代:AI互联互通的真正障碍不是技术
Site Owner
发布于 2026-05-06
2024年底Anthropic开源MCP协议,整个AI圈像过年。一年过去,现实是:MCP活得不错,但离真正互联互通还差得远。不是技术问题,是利益问题。
后MCP时代:AI互联互通的真正障碍不是技术
2024年底,Anthropic开源了MCP(Model Context Protocol),整个AI圈像过年。
开发者们奔走相告:终于有一套协议能让AI工具互相打通了。Cursor接上了,Claude接上了,GitHub接上了。媒体标题一个比一个夸张——"AI时代的USB-C"、"大一统协议诞生"。
一年过去了。
现实是:MCP确实活得不错,但离"互联互通"这四个字,还差着十万八千里。
不是技术问题,是利益问题
MCP的技术架构足够简单:定义一套标准接口,让AI工具通过统一协议调用外部资源。这套逻辑在USB时代被验证过,在REST API时代被验证过,在支付协议时代被验证过。
每验证一次,成功一次。
但每一次失败,也都败在同一个地方:谁掌握标准,谁掌握分配权。
USB-C能成,是因为Intel和苹果都不想永远打架,最后坐下来把接口统一了,背后有利益博弈,但博弈的双方体量对等,谁也吃不下谁。
MCP不一样。Anthropic是开源的,但Anthropic同时也是一家要卖Claude API的公司。这意味着什么?
意味着其他大厂——OpenAI、Google、Microsoft——在决定要不要全面支持MCP之前,都要先问自己一个问题:支持MCP,是在给Anthropic铺路吗?
这不是阴谋论,这是正常的商业逻辑。
Google有自己的工具调用协议,OpenAI有Function Calling,Azure有自己的一套标准。每家都有现成的基础设施,都有已经接入的开发者生态。让任何人先放弃自己的标准去支持对手的协议,谁都会先算一笔账:我的开发者跑了怎么办?我的生态被稀释了怎么办?
结果是:大家都表态"我们支持开放标准",但实际行动是"我们希望你用我们的标准"。
互联互通的三个真正障碍
障碍一:数据是护城河,不是待连接的资产
今天,没有一家大厂愿意让自己的AI无摩擦地读取竞对生态的数据。
Google想让AI读Gmail,但不想让AI读Outlook。OpenAI想让AI用GitHub,但不想让AI用GitLab。每家都在建围墙,每家都在用"隐私"和"安全"作为正当化理由。
真正的原因是:数据是喂养AI的饲料。谁拥有更多数据,谁的模型就更强。谁的模型更强,谁就有更多用户。谁有更多用户,谁就更有数据。
这是一个飞轮。大厂们正在用这个飞轮筑高护城河,而互联互通的协议,本质上是要把这个飞轮的刹车交给别人。
障碍二:协议易得,信任难建
MCP协议本身是开源的,任何人都可以查看、实现、修改。但这不意味着任何人都能参与标准的制定。
今天MCP的演进路径,基本是Anthropic主导、社区贡献的形式。这意味着Anthropic对协议的发展方向有事实上的决定权。其他大厂可以"参考"MCP实现自己的协议,但很难真正"参与"到Anthropic主导的生态里——因为参与就意味着承认对手的权威。
科技史上,开放标准最终获胜的案例,大多数发生在没有单一强主导者、或者主导者有意愿分享控制权的情况下。HTTP/1.1的普及,背后是IETF多利益方博弈的机制。TCP/IP的全球化,是因为美国军方主动放弃了独占权。
MCP缺少这样一个机制。Anthropic是贡献者,不是裁判。
障碍三:开发者正在用脚投票,但方向各不相同
有一种乐观观点是:开发者不在乎政治,只在乎哪个工具好用。如果MCP真的最好用,大家自然会迁移到MCP。
这个逻辑在纯技术领域成立,但在AI应用层不太成立。
原因是:AI工具的粘性不在工具本身,而在工具背后连接的服务和数据。你用Cursor,不只是用它的编辑器,还因为它能直接调用你的代码库、你的GitHub、你的团队协作工具。这些连接不是靠协议建立起来的,是靠商务合作、API密钥、数据授权建立起来的。
换句话说,协议标准化解决的是技术层的互通性问题,但解决不了商业层的利益分配问题。
小开发者的大困境
对个体开发者来说,这种局面意味着什么?
意味着你每次接入一个新的AI工具,都要重新谈一次数据授权,重新搭一次集成适配。协议再开放,你的Confluence数据也不会自动流向Claude——你得自己写中间件,自己维护认证,自己承担接口变化的风险。
更现实的情况是,很多开发者选择了"等":等协议稳定,等大厂们打完架,等一个真正能让他们躺平的标准出现。
结果就是:AI工具很热,但AI工作流很碎。每个人都在用AI,但每个人的AI都连着不同的东西,大家都在自己的小生态里转。
未来的三种可能
可能一:区域性互联互通
中美AI生态的分裂,客观上创造了一种"区域标准"的可能性。在中国,阿里云、百度、字节的AI工具正在形成自己的协议生态。这不是全球互联互通,但可能是区域内的互联互通。
对国内开发者来说,这未必是坏事。区域内的标准往往比全球标准更容易达成,因为玩家更少,监管更统一。
可能二:事实标准的自然形成
不一定需要协议战争分出胜负,也可能是一种协议因为用得足够多,自然成为事实标准。就像HTTP最终胜出,不是因为哪个国家下令,而是因为所有网站都在用。
MCP有可能是这个逻辑——用得足够广,广到各家不得不兼容。今天Cursor、Claude、Sourcegraph都在用,这个基础比一年前已经强了很多。
可能三:开放协议层 + 封闭数据层
最现实的未来可能是:协议层逐渐开放,大家在接口标准上慢慢收敛;但数据层继续保持封闭,每家继续建自己的围墙。
这意味着开发者可以更容易地连接工具,但连接之后能读取什么数据,还是每家各凭本事。
对开发者来说,这算是半个好消息。至少工具链的打通不再需要三套代码,但真正的数据打通,仍然需要商务谈判和定制开发。
最后
MCP是个好开头。
它证明了开放协议在AI领域是有需求的,也是有生存空间的。但从"有需求"到"被采纳",中间隔着的不只是技术难度,还有商业博弈。
下一个真正能推动AI互联互通的变量,可能不是哪个协议本身,而是一场意外的格局重组——某个大厂因为某种原因放弃了封闭策略,或者某个体量足够大的开发者群体,用自己的生态倒逼标准统一。
在那之前,我们还得继续在碎片化的生态里凑合着活。
这不是技术问题。
技术问题,反倒最好解决。