2025年3月，MCP这三个字母在中文互联网上属于顶流。铺天盖地的分析文章、教程、手把手教你5分钟接入MCP。所有大厂排队表态支持，GitHub上MCP Server一个月新增三千个。那场面，恍惚间让人觉得下一个iOS生态就要靠这玩意儿定义了。
2026年的今天，安静了。不是死寂，该支持的还在支持，该接入的还在接入。但那种不追就落后的紧迫感没了。这种热度退潮，究竟意味着MCP踩过了该踩的坑、开始走向真正有用的成熟期，还是那场爆发本来就不是真实需求、全靠FOMO情绪撑着？
本文将从MCP的技术定位、2026年的关键升级、行业采纳现状，以及它面临的质疑与竞争格局四个维度，系统分析MCP成为Agentic AI标准的可能性与现实障碍。
一、MCP解决了什么问题
1.1 集成的N×M困境
在MCP出现之前，AI工具和外部世界之间的连接方式一片混乱。每个厂商、每个工具都有自己的插件系统，互相不兼容。Cursor有Cursor的，Claude有Claude的，OpenAI有OpenAI的。你想在一个AI编程环境里调用内网的代码库，需要单独适配；想让AI读一份PDF，需要另外写接口。
这种碎片化的集成模式，本质上是一个N×M的集成悖论。每一种新模型若要连接每一种外部资源，传统模式下需编写海量的定制化适配器。MCP正是为了解决这个长期困扰开发者和企业的核心架构问题而生的。
2025年12月，Linux Foundation成立Agentic AI Foundation时公布的数据显示，MCP月度SDK下载量已达9700万次，活跃服务器超过10000个，ChatGPT、Claude、Cursor、Gemini、Microsoft Copilot、Visual Studio Code等主流AI平台均已提供一级客户端支持。这一数据说明，在标准化的方向上，MCP已经获得了行业的广泛认可。
1.2 MCP的核心理念
MCP由Anthropic于2024年11月推出，其核心价值主张是通过一套通用的双向连接规范，将复杂的集成方程简化为线性的N+M模式。MCP采用客户端-宿主-服务器的三层物理隔离模型，通过三大核心原语来标准化AI与外部世界的交互：资源类似只读数据源，向LLM暴露文档、数据库记录等静态上下文；工具赋予模型执行实际操作的能力，如发送邮件、执行代码或创建工单；提示词提供可复用的交互模板，引导模型在垂直领域内遵循一致的工作流规范。这种设计被业内形象地称为人工智能领域的USB-C接口，一次实现工具连接，任何兼容MCP的AI客户端都可以即插即用。
MCP与Google的A2A协议形成了清晰的互补分工。MCP解决的是垂直方向的Agent到工具连接问题，A2A解决的是水平方向的Agent到Agent通信问题。一个典型的Agent架构中，Planner Agent通过A2A与Domain Agent通信，Domain Agent内部通过MCP调用数据库和外部API。两者不是竞争关系，而是解决不同层级问题的互补管道。
二、2026年MCP的关键升级：从炒作到成熟
2026年7月28日，MCP迎来了自发布以来最大规模的史诗级更新。如果说2025年的MCP是概念验证阶段，2026年的这次升级才是真正面向生产环境的成熟化改造。
2.1 无状态核心架构
这是本次更新最核心的变化。此前MCP是一个有状态的双向协议，需要管理复杂的会话状态，导致MCP服务器很难在现代云原生架构中丝滑扩展。新规范将核心彻底变成了无状态，移除了Mcp-Session-Id头部和初始化握手，切换到了纯粹的请求响应模式。
ZopDev的云架构师Muskan Bandta在评论这次升级时指出：当MCP服务器是开发人员笔记本电脑上的本地进程时，基于会话的模型是有意义的。但在生产环境中，它变成了一种运营负担。当基础设施团队询问MCP服务是否可以像其他云应用程序一样扩展时，答案过去是不完全能。随着向无状态架构的转移，答案现在变成了肯定的。
这一变化带来了两个关键的红利。一是可以拥抱Serverless与边缘计算，把MCP服务器部署在AWS Lambda、Vercel、Cloudflare Workers等无服务器架构上，不再需要为会话状态租用昂贵的常驻服务器。二是实现了无限的水平扩展，每个请求都是自描述的，可以直接挂在轮询负载均衡器后面，扩展能力直接拉满。
IT咨询公司Kanerika的AI开发经理Amit Jena进一步指出，这种向无状态设计的过渡超越了简化基础设施的范畴，从根本上改变了AI应用程序管理和跨工具共享上下文的方式。新设计不再将应用状态隐藏在协议会话中，而是将其显式暴露出来，让AI模型能够在工具之间访问、推理和传递这些信息，使开发人员能够更好地控制如何跨工具保存和共享上下文。
2.2 MCP Apps与Tasks正式化
新版本还引入了版本化的扩展框架，MCP Apps和Tasks作为官方扩展正式纳入规范。
MCP Apps允许服务器在AI对话界面中，通过安全的沙盒iframe渲染出交互式UI。查公司营收数据时，AI不仅给出分析，还能在对话框里渲染出一个完全可交互的动态报表。这标志着UI组件可以直接嵌入MCP生态，与工具逻辑一同打包分发。
Tasks则将长时运行的异步操作纳入了官方标准。过去分析100GB日志这样的耗时任务缺乏标准化的处理方式，Tasks提供了官方的异步任务管理框架。
新规范还强化了对生产环境OAuth 2.0与OIDC部署的适配，MCP服务器无需采用变通方案，即可连接Entra或Okta等企业身份系统。2026年7月，企业级统一访问管理的EMA扩展成为稳定版。
2.3 弃用策略与兼容性保障
新规范引入了正式的弃用策略：从某项功能被标记为弃用到实际移除，至少保证12个月的过渡期，仅针对关键安全更新设有例外。被弃用的功能包括采样、旧的HTTP+SSE传输和动态客户端注册等。
Amit Jena指出，采样的弃用可能会产生最大的影响，因为它改变了谁负责与基础模型互动。采样允许MCP服务器通过客户端调用LLM，弃用它意味着重新建立信任边界，服务器将直接调用模型提供商。这会改变网络架构、身份验证模型和计费流程。一年的过渡期足以让团队开始审计对采样的依赖关系。
Python、TypeScript、Go和C#的MCP SDK均已同步更新，同时支持旧协议和新协议版本，新客户端可以继续与旧服务器通信，降低立即中断的风险。
三、行业采纳：标准化已成为进行时
3.1 从Anthropic到Linux Foundation
2025年12月，Linux Foundation成立了Agentic AI Foundation，将MCP、OpenAI的AGENTS.md、Block的goose三大项目纳入同一治理框架下。铂金会员包括AWS、Anthropic、Block、Bloomberg、Cloudflare、Google、Microsoft和OpenAI。
将MCP捐赠给Linux Foundation的决策，核心意义在于消除单厂商锁定风险。Anthropic不能再单方面修改MCP，Google不能单方面修改A2A，企业CIO敢把预算投进去，因为协议不归任何竞争对手独有。MCP的维护者结构保持不变，技术决策仍由社区维护者通过SEP流程做出，Linux Foundation提供中立的基础设施但不干涉技术方向。
月度SDK下载量从2025年底的9700万次增长到2026年7月的超过4亿次。超过950个MCP服务器在Claude的connectors目录中列出。这是已建立的行业事实，不是预测。
3.2 与A2A的分层协同
在2026年6月，Linux Foundation Agentic AI Foundation发布了MCP加A2A融合草案。两个协议都置于Linux Foundation治理之下，形成了清晰的分层架构：A2A层负责Agent之间的横向协调，包括Agent Card发现与签名验证、Task生命周期管理、跨组织委托与协商；MCP层负责Agent到工具的纵向连接，包括Tool、Resource、Prompt调用，无状态工具执行和上下文注入。
Google的比喻最准确：A2A是horizontal bus，MCP是vertical bus。一个典型的生产架构中，Orchestrator Agent通过A2A将任务委派给Specialist Agent，后者内部通过MCP调用数据库、API、文件系统等工具。
3.3 Agent Plugins 1.0：行业自发的标准
2026年8月6日，Amazon、Microsoft、OpenAI、Vercel、Cursor联合采用Agent Plugins 1.0.0，一个用于打包Agent Skills和MCP服务器的开放、厂商中立标准。Google同日作为核心维护者加入。这一标准已经集成到VS Code、GitHub Copilot、Cursor、ChatGPT和Kiro中。
值得注意的是，Anthropic缺席了这一联盟。尽管它制定了底层的Agent Skills规范和.claude-plugin格式，Claude Code不在首发客户端之列，Anthropic也没有代表出现在技术指导委员会中。这表明Anthropic可能在押注更丰富的平台特定能力，而非联盟的便携但最小化的方案。
Agent Plugins 1.0故意排除了安装机制、分发协议、来源验证、权限模型、沙箱要求和市场，确保每个平台运营商建立自己的分发渠道。这意味着技术标准是开放的，但商业模型并非如此。平台运营商谁控制客户端谁就成为守门人。对于开发者来说，构建高价值的Agent Skills时，他们不仅在为技术标准构建，还在选择哪个守门人控制他们进入企业买家和变现的路径。
四、质疑的声音为何存在
尽管采纳数据惊人，关于MCP的质疑声从未消失。2026年中，Perplexity CTO Denis Yarats公开宣布正在放弃MCP，回归API和CLI。YC CEO Garry Tan发帖直言MCP糟透了。
这些质疑的根源不是MCP没有价值，而是它试图解决的问题和实际带来的工程复杂度之间存在错位。
4.1 上下文臃肿
MCP最根本的性能问题是工具定义全量加载到上下文窗口。连接3个MCP Server，仅工具定义就可能占用约14.3万Token。在200K Token的模型上，72%的上下文被工具定义吃掉。有开发者指出，GitHub的MCP服务器为了教会AI如何使用GitHub，消耗约5万Token的上下文；而一个写着使用gh命令操作的Markdown文件只需要200个Token即可达到同样效果。250倍的差距在Token成本依然昂贵的今天直接决定了AI产品是盈利还是亏损。
Python社区知名开发者Simon Willison也指出，某主流AI IDE的MCP Server捆绑了43个工具描述，AI接入之后光工具定义就往上下文里塞了55000个Token，干活之前先把Token预算花掉一半。
4.2 架构复杂度与安全风险
MCP的架构涉及多个独立进程和网络边界，每一步都可能出错。有开发者调侃说：配置MCP的时间比写代码的时间还长。
安全方面，CoSAI于2026年1月发布了MCP安全白皮书，指出MCP引入的架构级安全风险无法通过补丁或配置修改来解决。Netskope的研究进一步确认了MCP存在三类固有漏洞：间接提示注入、工具投毒和Rug Pull攻击。安全研究人员已发现近7000个暴露在公网的MCP服务器，其中约半数没有任何授权控制。
不过，这些安全风险并非不可克服。正如2026年4月MCP Dev Summit上的讨论所示，安全批评的问题在于将当前状态的空缺视为MCP的终点。身份验证是过去一年MCP规范中被最积极讨论和修订的部分。远程代码执行风险在Agent相关的工作流中是真实存在的。但2026年的路线图直接处理了身份验证问题，AAIF工作组正在吸纳身份领域的专家贡献，Agent网关已经在多个供应商的生产实现中展示了协议之上的策略执行层。
4.3 MCP与Skills的路线之争
更深一层看，这场MCP争议反映了AI工程化的两种路线之争。一派是协议派，追求大一统的标准化理想：AI Agent要调用成千上万的工具，必须有一套严谨、标准化的沟通协议。另一派是Skills派，主张描述比定义更高效：一个简简单单的Markdown文件，告诉AI这是API端点，这是参数，就够了。
这场争论本质上取决于AI的执行环境。在受限环境中，例如ChatGPT网页版或标准Claude，不具备访问本地文件系统和执行命令的能力，MCP几乎是模型与外部世界互动的唯一可行路径。而在开发者的本地环境中，Skills方案通过CLI驱动的工具组合展现出更大的灵活性。
五、结论：标准之路已经铺平，但定义尚未写完
回到最初的问题，MCP会成为Agentic AI的标准吗？答案是肯定的，但需要加上一个定语：MCP已经成为连接AI与工具这一层的标准。
月度SDK下载量突破4亿的生态规模，Linux Foundation的治理背书，OpenAI、Google、Microsoft、AWS等巨头的集体采纳，这些都已经是既定事实，不是预测。MCP的2026-07-28规范解决了企业级扩展性、身份验证和Serverless部署等核心生产问题。
MCP没有成为也不准备成为Agentic AI的全部标准。AAIF的2026年8月路线图明确了五个优先事项：Agentic messaging primitives、HTTP-native transport unification、Agent identity、Improved primitives、Improved SDK developer experience。MCP的联合创建者David Soria Parra在MCP Dev Summit上明确指出：MCP有明确的定义范围，连接AI应用到数据源。可观测性属于OpenTelemetry，身份管理属于专用项目，治理属于协议之上的控制平面层。MCP不应试图拥有这些问题。
对于开发者而言，与其纠结MCP会不会成为标准，不如先搞清楚自己的Agent运行在什么环境里、需要连接哪些外部系统，然后判断今天是否值得为MCP投入时间。答案大概率是肯定的，因为标准化的方向已经足够明确，而MCP在这场标准化浪潮中已经拿到了关键的入场券。正如OpenAI的Nick Cooper在MCP Dev Summit上所言：MCP本身不是重点，人们能用它实现什么才是重点。协议是管道，真正的价值在于基于它构建的内容和连接。