为什么MCP赢了
亲爱的AI工程师们，
我很抱歉最近你们的动态中充满了MCP。
模型上下文协议（MCP）于2024年11月推出，受到了相当不错的欢迎，但最初的兴奋热潮（从Copilot到Cognition再到Cursor等都添加了支持）在2025年AI工程师峰会之前就已经消退了1。然而，在2月26日至27日的AI工程师峰会上，我和Barry Zhang的一次偶然对话促使我们邀请了Mahesh Murag（他编写了MCP服务器）。我原本只是想换换口味，不同于Anthropic在2023年和2024年的提示工作坊，但结果却出乎意料：
通常工作坊对现场参与者来说很棒，但在线观众很难保持两个小时的注意力。然而，工作坊的实时推文开始走红，因为社区首次获得了高度期待的官方注册信息，并且对协议规范的每个部分进行了全面深入的讲解，比如这样：
我们随后加快了编辑过程以发布工作坊视频，短短一周内，视频获得了接近30万次观看，于是出现了这种情况：
我在Latent Space的一个“目标”是尝试稍微领先于共识提供一些编辑意见。在11月我们说GPT包装器实际上是好的，现在a16z也对此感到兴奋。在12月我们告诉$200/月Pro用户他们错了，$2k/月的“ChatGPT Max”即将推出，现在我们已经确认$2-20k/月的代理计划正在进行中。但我必须承认，MCP的受欢迎程度让我始料未及，因为我见过许多试图模仿XKCD 927的想法来来去去，而MCP最初被宣传为一种用于Claude Desktop本地、隐私友好的集成方式，我愿意打赌，只有少数%的AI工程师甚至下载过Claude Desktop（相比之下，像ChatGPT Desktop和甚至Raycast AI这样的工具就更普及了）。
即使我们举办了这个工作坊，我还是觉得低估了MCP。
借用Ben Thompson的话，任何网络的#1功能就是已经在那里的人。因此，任何新协议的力量都来源于其采用率（即生态系统），可以说，MCP目前已经获得了足够的关键质量和势头，已经成为2023-2025“代理开放标准”战争的默认赢家。按照目前的速度，MCP将在7月超过OpenAPI：
广泛接受的标准，如Kubernetes、React和HTTP，通过将爆炸性的MxN问题转化为可处理的M+N生态系统解决方案来容纳数据发射器和消费者的巨大多样性3，因此如果它们能获得关键质量，这些标准是非常有价值的。事实上，即使是OpenAI也有之前的AI标准3，甚至Gemini、Anthropic和Ollama都在广告中宣传与OpenAI SDK的兼容性。
我不是自大到认为AIE峰会的工作坊引发了这种加速；我们只是在已经看到火势蔓延的情况下添了一把柴。但是作为一个开发者工具创业公司的学生，其中许多公司尝试并失败了创建开放标准的势头4，我觉得我不应该错过这个机会来更深入地研究它，以便为未来的标准创建提供一本手册。此外，我每天都会被问到关于MCP的看法，所以是时候把它写下来了。
1、为什么MCP赢了（简短版）
即“获胜”状态作为事实上的标准，而不是完全等价但替代的方法，如OpenAPI和LangChain/LangGraph。按大致降序排列。
- MCP是旧想法的“AI原生”版本
- MCP是一个有强大支持者的“开放标准”
- Anthropic拥有最好的开发者AI品牌
- MCP基于LSP，一个现有的成功协议
- MCP用完整的第一方客户端、服务器、工具和SDK进行了自我测试
- MCP从最小的基础开始，但有频繁的路线图更新
- 非因素：我们认为令人惊讶的没有对MCP的成功做出贡献的事情：如Zed、SourceGraph Cody和Replit等合作伙伴的排兵布阵，以及发布时有很好的文档
我现在会用一些截图详细说明。
2、MCP是旧想法的“AI原生”版本
很多“老派开发者”类型的人，包括我自己，最初会对MCP的成功感到困惑，因为在技术层面，MCP主要能够实现现有标准如OpenAPI/OData/GraphQL/SOAP等所支持的相同能力。因此隐含的假设是旧的、更成熟的标准应该获胜。
然而，仅仅因为技术上相似就否定一个想法是忽视了人类工程师所处的社会学背景。换句话说，说“旧的东西能做到一样多，你应该选择旧的东西”陷入了每一个开发者都会遇到的Lavers定律时尚谬误，同样的态度导致你否认AI工程师的崛起，因为你假设它与现有职位足够相似。借用Eugene Wei的《地位即服务》，每一代开发人员都会主动寻找新的领域来留下自己的印记，基本上是因为你在你的时代已经留下了印记。
协议的价值具有反射性——记住，它们只有在获得采用时才有价值——这意味着这些想法在ex ante几乎没有价值。MCP的价值在于它能够获得采用……因为AI影响者认为如此，所以它确实变得有价值。
同样有价值的是，这是一个对旧思想的修订，这意味着它实际上满足了我们已知的需求，而不是制造出未经验证的虚假需求。
然而，简单地说MCP与OpenAPI完全等同，并且其成功只是冷嘲热讽的周期驱动，这种说法也过于轻率。这就是为什么我选择将这个成功因素描述为“AI原生”——在这种情况下，MCP诞生于Claude Sonnet在SWE-Bench结果排名第一的经验教训，并在《构建有效代理》中阐述，主要是这张幻灯片：
一个“AI原生”的标准，将已经在每个代理中独立重复出现的模式具体化，总是比一个没有这些偏见设计的通用标准更易于使用和构建工具。
因此，MCP胜过OpenAPI。
第二，回到这张幻灯片，关注工具（模型控制）、资源（应用程序控制）和提示（用户控制）之间的差异。
MCP的“AI原生”性诞生于LLM框架的第一波浪潮之后，这意味着它有足够的空间避免从LLM互操作性开始（现在是已经解决的问题，并且可能由客户端和网关拥有），而只关注动态上下文访问的令人头疼的未解决问题（非常直白地说，MCP的动机是“模型的表现仅取决于提供给它们的上下文”）。
因此，MCP胜过LangChain等。
3、MCP是一个有大公司支持的“开放标准”
对于理想主义者来说，这可能是最令人沮丧的一点：一个来自大公司的标准比其他任何人的标准都更容易成功。即使那些有数万GitHub星标和数百万顶级VC资金支持的标准。这不公平；如果你们创业公司的财务未来激励我完全锁定到你们的标准上，我是不会采用它的。如果标准的发起方看起来太大而不关心真正锁定你到这个标准上，那么我会采用它。
因此，MCP胜过Composio等。
任何“开放标准”都应该有一个规范，而MCP有一个非常好的规范。仅此规范就击败了许多竞争者，因为他们没有提供这样的详细规范。
因此，MCP胜过许多开源框架，甚至可以说胜过OpenAI的功能调用，其文档在全面性上略显不足。
4、Anthropic拥有最好的开发者AI品牌
也许除了有一个大公司支持之外，更重要的是哪个大公司支持。如果你要建立一个开发者标准，最好能得到开发者的喜爱。 Sonnet在这方面已经连续九个月处于领先地位。
一个稍微微妙一点的点，可能被新来的人忽略——Anthropic一直明确强调支持比OpenAI更多的工具——我们没有关于大型工具数量的基准/消融测试，所以我们不知道不同模型实验室之间的能力差异，但直观上，MCP使单次调用中的平均工具数量远超通常在没有MCP构建的工具中所能达到的数量（仅仅是因为易于包含，而非任何内在的技术限制）。因此，能够更好地处理更高工具数量的模型表现会更好。
因此，MCP胜过比如由Cisco等公司提出的等效开发者标准。
5、MCP基于LSP，一个现有的成功协议
“‘开放标准’与大公司支持”这一陈述的另一部分要求标准没有致命缺陷。与其从头开始发明一个全新的标准，冒着重蹈过去所有错误的风险，Anthropic团队聪明地采用了微软非常成功的语言服务器协议。
再次从研讨会中可以看出，对MCP与LSP的比较有着敏锐的认识：
理解这一点的最佳方式是查看任何尝试获得广泛采用的其他开源AI原生竞争对手，然后思考一下你是否能像添加MCP一样轻松地将其添加到Cursor/Windsurf中。基本的见解是客户端和服务器之间的可替代性：这些竞争对手通常是以一种方式设计的——作为另一个代码库中的开源包——而不是发出可以被任何人消费的消息。另一个明智的选择是坚持使用JSON RPC进行消息传递——再次继承自LSP。
因此，MCP胜过其他更“未经验证”的标准格式。
6、MCP以完整工具链进行了狗食测试
MCP发布时：
- 客户端: Claude桌面
- 服务器: 19个参考实现，包括有趣的记忆、文件系统（魔法！）和顺序思维
- 工具: MCP检查器，Claude桌面开发工具
- SDK: Python 和 TS SDKs，还有llms-full.txt文档
此后，最近发布的Claude代码也悄悄引入了第二个官方MCP客户端，这次是以CLI形式：
这一切都源于Anthropic开发人员的实际使用案例。
因此，MCP胜过其他像Meta的llama-stack这样较少进行狗食测试的大公司尝试。
原文链接：Why MCP Won
汇智网翻译整理，转载请标明出处