后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互联互通的变量，可能不是哪个协议本身，而是一场意外的格局重组——某个大厂因为某种原因放弃了封闭策略，或者某个体量足够大的开发者群体，用自己的生态倒逼标准统一。

在那之前，我们还得继续在碎片化的生态里凑合着活。

这不是技术问题。

技术问题，反倒最好解决。