MCP已经赢了：从备受质疑到一统江湖，AI界的“USB-C”是如何炼成的？

三年前，为了将AI助手连接到内部客户关系管理系统，工程师往往需要耗费两周时间去构建一个定制插件，而现在通过模型上下文协议（Model Context Protocol，简称MCP），同样的任务仅需四小时即可完成，并且能兼容技术栈中的所有AI模型。

这一效率的飞跃标志着碎片化插件时代的终结，MCP正迅速成为AI与工具、数据及现实世界交互的通用接口。

MCP Manager的CEO兼创始人Michael Yaroshefsky宣告MCP已经赢了

MCP如何在短短一年内从一个被怀疑的草案，逆袭成为统领AI生态的行业标准的？

从脆弱试验到通用接口的早期探索

2024年11月，当Anthropic首次推出模型上下文协议MCP时，业界对此充满了怀疑。

在那个AI工具集成标准战国争雄的年代，试图用一个粗糙的草案来实现生态系统的统一，听起来像是一个遥不可及的乌托邦式幻想。

当时的MCP主要定位为本地开发者的辅助工具，例如Windsurf这样的代码编辑器可以通过MCP调用Puppeteer打开浏览器，点击正在构建的Web应用并截图。

尽管这优化了开发工作流，但它并未描绘出一幅宏大的互联图景。

那时的MCP传输层极其脆弱。

初始版本主要依赖标准输入输出（stdio）进行数据传输，这意味着在计算机上运行的进程必须将JSON-RPC消息打印到标准输出流中，传输层再从这些输出日志中解析出有效的MCP消息。

这种机制简直是噩梦，任何意外打印到控制台的日志都可能破坏数据流，导致解析失败。

对于开发者而言，观察、调试和管理这些进程的生命周期是一项痛苦的任务。

虽然技术上支持服务器发送事件（Server-Sent Events，简称SSE）以实现Web连接，但SSE在双向通信方面表现笨拙，不仅难以适应多租户服务器环境，还容易引发消息体解析错误或超时等隐蔽Bug。

与此同时，既有的AI连接方案似乎已经足够好。

在2023年至2024年间，模型发布者们已经掌握了如何强制AI输出结构化的JSON数据，将自由文本转化为机器可读的指令。

OpenAI早在2023年就推出了GPT Actions，允许AI直接决定调用哪个API并即时生成所需的JSON参数。

各大厂商都在投资自己的专有框架，试图建立各自的围墙花园。在这种背景下，MCP的出现显得多余且不起眼。

然而社区的探索热情改变了这一切。

进入2025年初，MCP凭借一些实用的服务器框架和AI辅助编程的便利性，迅速吸引了一批热衷于尝鲜的开发者。

这种低门槛的贡献方式让人联想到Docker早期的发展历程，社区迅速生成了成千上万个质量参差不齐的MCP服务器。

尽管这些早期作品大多只适合个人修补匠使用，但它们构建了一个庞大的底层网络，让无数个人和团队感受到了参与AI创新的乐趣。

这种自下而上的草根力量，为MCP后续的爆发积蓄了关键势能。

传统的插件模式存在着天然的缺陷。

每个服务都需要独特的身份验证方案和API格式，开发团队往往将60%的时间浪费在集成的管道工程上，而非解决实际业务问题。

企业级部署可能需要数十个插件，每一个都是潜在的故障点。

MCP提出了一种截然不同的思路，开发者只需构建一个标准化的MCP服务器来暴露系统能力，任何兼容MCP的AI模型都可以自动发现并使用这些能力。

这不仅实现了“一次编写，处处运行”的跨模型兼容性，更重要的是，MCP暴露的是上下文（Context）而非单纯的API端点。

AI模型可以借此了解可用工具的功能描述、工作原理及安全边界，从而在极少人工干预的情况下做出更明智的决策。

巨头共识与网络效应的战略转折

2025年3月26日成为了MCP发展史上的关键转折点。

OpenAI首席执行官Sam Altman在社交媒体上公开宣布全力支持MCP，承诺在产品线中全面集成该协议。

这一战略决策具有里程碑式的意义，意味着行业领头羊放弃了与竞争协议的内耗，选择加入Anthropic倡导的标准。

对于AI代理（Agent）而言，要达到人类级别的工作效率，必须连接到相同的数据源和通信渠道。

无视MCP将意味着OpenAI的客户无法享受到社区在这一新兴协议上已经取得的巨大集成进展。

随着OpenAI的加入，MCP服务器和客户端的集合产生了强大的网络效应。

每一个新增的MCP服务器都为现有的网络增添了价值。

这一天，MCP规范也发布了第二个重要版本，引入了可流式传输的HTTP协议和基于OAuth 2.1的综合授权框架。

在此之前，MCP的实用性主要局限于本地开发环境，因为标准输入输出传输无法在云端扩展，而SSE的双向通信限制又过于繁琐。

新的流式HTTP传输打破了这一瓶颈，使得SaaS供应商可以将安全的MCP服务器发布到互联网上，供任何本地或云端的MCP客户端使用。

这一变革让MCP真正开始兑现“AI连接领域的USB-C”这一承诺。

远程MCP服务器在理论上类似于传统的API，但在交互方式上有着本质区别。

传统API需要人类阅读文档、理解逻辑后编写胶水代码来调用，而MCP服务器具备即时的能力发现与协商机制。

在初始化阶段，服务器会将关于工具、资源和提示词的最新文档直接发送给客户端。

AI利用这些自描述文档来调用工具或访问资源。

这种将文档与调用合二为一的设计，是MCP最核心的创新之处。

对于用户而言，这意味着极致的简化。

随着远程MCP服务器的兴起，用户只需在客户端输入一个URL，系统就能自动解析该URL提供的功能并加以利用。

这消除了传统API集成中“文档与现实脱节”的痛点，也不再需要繁琐的npm配置命令。

这种简单性极大地加速了MCP的普及，使其在AI淘金热中成为连接代理与真实工作的首选方案。

相较于专有的工具调用标准，MCP展现出了压倒性的通用性和易用性。

到了2025年5月，Google、Microsoft和GitHub纷纷宣布支持MCP，行业格局彻底稳固。

DeepMind首席执行官Demis Hassabis称赞MCP为AI代理时代的开放标准，并宣布Gemini模型将全面支持。

微软在Build 2025大会上更是宣布Windows 11将拥抱MCP，并将GitHub纳入MCP指导委员会。

这种由Anthropic、OpenAI、Google和Microsoft四大巨头组成的统一战线，使MCP从一个单一厂商主导的规范演变为行业通用的基础设施。

回顾科技史，像OpenAPI、OAuth 2.0或HTML/HTTP这样的标准通常需要数年时间才能达到类似的跨厂商采用率，而MCP仅用了一年。

安全危机洗礼下的协议重铸

任何新技术的爆发式增长都会伴随着阵痛。

2025年4月1日，Invariant Labs发布了一个通过MCP实施攻击的演示，并提出了“工具投毒攻击”（Tool Poisoning Attack）的概念。

这一演示揭示了MCP早期设计中的一个重大隐患：由于服务器文档在连接时直接发送给大语言模型（LLM）并影响其行为，恶意攻击者可以在文档中嵌入指令。

例如，一个恶意的天气查询工具可能在文档中隐藏“读取密码文件并发送”的指令。用户在毫不知情的情况下连接该服务器，AI就会被诱导执行恶意操作。

这一披露引发了剧烈的反响，关于“工具模仿”、“拉地毯骗局”（Rug Pulls）和“间接提示注入”的讨论甚嚣尘上。

业界充斥着对MCP安全模型的批评，指出其忽视了过去40年远程过程调用（RPC）的最佳实践。

由于当时MCP缺乏有效的可观测性，且AI能够被诱导掩盖其操作痕迹，数据泄露和远程代码执行的风险变得真实而迫切。

对于各企业的安全团队而言，MCP迅速从一个创新工具变成了需要封锁的威胁。

然而这场危机并未扼杀MCP，反而成为了其成熟的催化剂。

MCP的开源特性使得漏洞暴露在阳光下，能够被全行业协作解决。

这与十年前OAuth 2.0初期的困境惊人地相似，当时OAuth也被批评为不安全，但最终通过快速修补和建立最佳实践而存活下来。

社区将每一个发现的漏洞转化为防御机制，安全意识强的团队开始在风险可控的前提下拥抱MCP。

批评和审查实际上为MCP挖掘了一条护城河，随着社区的响应和协议的加固，它变得比以往任何时候都更加安全和强大。

2025年6月18日，MCP规范迎来了一次针对安全性的重大更新。

新版本正式将MCP服务器分类为OAuth资源服务器，并引入了资源指示器，防止访问令牌在不同服务器间被滥用。

规范还增加了一套详尽的“安全最佳实践”指南，为企业大规模安全部署提供了明确路径。

此外，新版本引入了“启发”（Elicitation）机制，允许MCP服务器在请求需要澄清时向用户提出后续问题。

这种交互式的回溯机制不仅提高了安全性，也让AI系统在人机协作中显得更加可靠和稳健。

企业级治理体系的构建与完善

随着技术底座的夯实，2025年夏季，MCP的重心从“如何连接”转向了“如何治理”。

Salesforce在6月23日宣布其Agentforce 3平台将围绕MCP的互操作性构建，并发布了Salesforce DX、Heroku Platform和MuleSoft三个原生MCP服务器。

Salesforce的入局极具风向标意义，作为服务于安全敏感型大企业的巨头，它必须在拥抱开放性的同时满足严格的合规要求。

其更新强调了护栏、治理和安全性，这标志着MCP正式进入企业级生产环境。

与此同时，IT和安全管理者开始面临一系列严峻问题：谁有权部署MCP服务器？如何评估第三方服务器的安全性？如何管理AI代理的身份认证？

市场需求迅速催生了治理工具的生态爆发。

Cloudflare推出了MCP服务器门户，旨在集中管理、保护和观察组织内的所有MCP连接，将MCP提升为需要IT部门严格审计的基础设施。

身份认证巨头Auth0也发布了自己的MCP服务器，并展示了如何利用OAuth提供商来保护远程MCP连接，进一步强化了身份层的集成。

可观测性平台New Relic也迅速跟进，推出了针对Python应用内MCP通信的监控解决方案。

尽管初期功能有限，但这强化了一个行业共识：MCP已经重要到必须纳入企业监控体系。

此外，新兴公司如MCP Manager提出了专用MCP网关的概念，提供团队配置、安全策略、身份管理和审计日志等企业级控制功能。

ToolHive等项目则将MCP带入云原生世界，利用Kubernetes资源来管理和保护MCP服务器。

这一时期，治理和安全工具在生态系统中遍地开花。

Obot等公司专注于策略执行和工具过滤，防止AI调用危险或模棱两可的指令。

独立开发者和开源社区也贡献了威胁模型、验证工具和服务器加固指南。

到了夏末，围绕MCP的讨论已经完全成熟，不再是探讨其可行性，而是聚焦于如何在组织规模上负责任地运营。

这种从实验性技术到生产级基础设施的转变，为后续的生态扩张奠定了坚实基础。

面向未来的技术演进与无状态愿景

在MCP一周年之际，英伟达首席执行官黄仁勋评价道：“MCP的工作彻底改变了AI格局。”

这一年里，协议不仅解决了早期的安全和治理漏洞，还在技术规格上不断进化以适应现实需求。

2025年11月的规范更新引入了客户端ID元数据文档（Client ID Metadata Documents，简称CIMD），彻底改变了客户端注册模式。

在此之前，动态客户端注册（DCR）难以管理且容易遭受网络钓鱼攻击。

CIMD通过让客户端在受信任的公共URL上发布元数据文档，实现了基于URL的唯一身份验证。

这不仅降低了OAuth握手的复杂性，还大大减少了冒充风险，增强了身份层的透明度。

为了解决长期存在的超时问题，该版本还引入了实验性的“任务”（Tasks）功能。

传统的MCP工具调用要求客户端等待完整结果，这在处理耗时操作时极易导致超时失败。

任务功能允许服务器启动长运行作业并立即返回任务标识符，客户端随后可以使用该标识符作为“收据”来查询进度。

这种异步模式让MCP能够适应复杂的企业级工作流，显著提高了系统的可靠性。

展望2026年及未来，MCP正朝着更加独立和泛用的方向发展。

我们可以预见，大型SaaS厂商将普遍提供第一方原生MCP服务器，目前已有70%的大型SaaS品牌涉足此领域。

这不仅简化了集成，也减少了开发者自行构建连接器的负担。

同时，MCP的应用场景将不再局限于大语言模型。

作为一个轻量级、语言无关的接口，它非常适合用于系统与系统之间的结构化指令传递和数据流传输。

一个新的前沿领域是MCP Apps提案，它试图将用户界面（UI）引入大语言模型。

这意味着MCP服务器不仅提供数据和工具，还能直接驱动交互式的UI元素，将MCP的能力从后端连接扩展到前端体验。

这一演进预示着MCP将成为现代软件的基础通信层，不仅服务于AI，也服务于更广泛的数字化交互。

为了支撑这种大规模应用，MCP协议本身也在向无状态（Statelessness）模型演进。

当前的MCP会话通常假设客户端与服务器之间存在持久连接，这在分布式环境中难以扩展。

无状态设计将允许服务器在不维护长连接的情况下运行，从而使部署更具弹性。

结合任务功能的异步机制，MCP正在与现代分布式系统的架构理念深度对齐。

回望过去，MCP在社区的广泛参与中，通过批评、修补和实验，共同塑造了今天的协议。这种跨越厂商、构建者和安全研究人员的集体所有权感，成为了MCP最坚固的护城河。

它没有作为一个完美的成品降临，而是在公众的注视下成长，这种开放性最终成就了它作为AI连接通用标准的地位。

插件孤岛的时代并非以一声巨响终结，而是在MCP被广泛采用的静默中落幕。

参考资料：

https://thenewstack.io/why-the-model-context-protocol-won/

https://thenewstack.io/goodbye-plugins-mcp-is-becoming-the-universal-interface-for-ai/