MCP一周年：协议很美，但我的工具箱里还是乱成一锅粥

去年MCP开源的时候，我熬夜看了发布会。

Anthropic的人把Demo跑了一遍：Claude接GitHub，Cursor接数据库，Agent调用日历——一套协议，全打通了。我坐在屏幕前差点鼓掌，感觉自己像在2024年的WWDC现场。

一年过去了。

我的工具箱里，GitHub是GitHub的接口，Slack是Slack的接口，Notion是Notion的接口。协议很美，现实很骨。

---

协议战争这事，技术从来不是主角

MCP的技术设计是合理的。

它本质上是一套标准化接口——定义好AI怎么调用工具，工具怎么返回数据，开发者就不用每次都重新造轮子。这套逻辑在USB时代被验证过，在REST API时代被验证过，每一次都成功。

每一次，也都败在同一个地方。

谁掌握标准，谁掌握分配权。

USB-C能成，是因为Intel和苹果都不想永远打架，最后坐下来把接口统一了。背后是博弈，但博弈的双方体量对等。

MCP不一样。Anthropic开源了协议，但Anthropic同时也是一家要卖Claude API的公司。这意味着什么？

意味着OpenAI、Google、Microsoft在决定要不要全面支持MCP之前，都要先问自己一个问题：支持MCP，是在给Anthropic铺路吗？

这不是阴谋论。这是每家公司每个季度董事会都要过的灵魂拷问。

结果大家都看到了：Cursor接了，Claude接了，GitHub接了。但OpenAI的Agent用着自己的Function Calling，Google的Agent Studio接的是自己的协议。各家表态"我们支持开放标准"，但实际行动是"我们希望你用我们的标准"。

这个场景，我做过。我上一个项目要给四个AI平台接工具链，每家都说是"开放生态"，每家的接入文档都写着"轻松集成"。实际上我写了四套适配层，每套逻辑差不多，但接口名字不一样，认证方式不一样，超时处理不一样。

这不是工程问题。这是我每年要给四家公司交的保护费。

---

数据才是真正的墙

比协议更难解决的，是数据。

MCP协议本身是开源的，任何人都可以查看、实现、修改。但你用MCP能读到什么数据，跟协议没关系，跟商务谈判有关系。

Google想让AI读Gmail，但不想让AI读Outlook。OpenAI想让AI用GitHub，但不想让AI用GitLab。每家都在建围墙，理由是"隐私"和"安全"。

真正的原因是：数据是喂养AI的饲料。谁有更多数据，谁的模型就更强。谁的模型更强，谁就有更多用户。谁有更多用户，谁就更有数据。

这是一个飞轮。大厂们正在用这个飞轮筑高护城河。互联互通的协议，本质上是要把这个飞轮的刹车交给竞争对手。

这就是为什么真正有意义的问题不是"协议够不够开放"，而是"谁愿意把自己的数据飞轮分享出来"。答案目前是：没人愿意。

---

小开发者的三种活法

在这个碎片化的生态里，小开发者其实只有三种选择。

第一种：全押一个大厂。

选定一个平台，深度绑定，用它的全套工具链。省心，但风险也大——平台政策一变，你的整个工作流可能就得重建。2023年不少套在OpenAI API上的开发者，2024年被迫紧急迁移的事情又不是没发生过。

第二种：自己写中间层。

四套适配逻辑，我全写。维护成本高，但至少不被单一平台绑架。这是大多数正经做产品的团队选择的路径。代价是工程资源被消耗在"接接口"这种没有复利的事情上，而不是真正做产品。

第三种：躺。

等。等协议稳定，等大厂打完架，等一个真正能让我躺平的标准出现。这是大多数独立开发者实际在做的事——嘴上说在关注MCP生态，实际上还是用老办法先凑合着。

第三种选择听起来很消极，但它是理性的。因为你投入重兵去适配一个还在变化的标准，很可能在你刚刚接完的时候，协议就升级了，或者某个大厂突然宣布了自己的替代方案。