MCP 2026：1.1 亿下载量、强制规范重写与生产环境现实检验

TL;DR: MCP 月度 SDK 下载量已达 1.1 亿，公开服务器超过 1 万个，但 7 月 28 日的规范重写是强制迁移而非可选升级。协议的无状态化解决了扩展问题，却破坏了依赖会话的生产环境模式；而影子 MCP——未经审核的 MCP 服务器在企业环境中运行——已成为新型影子 IT，规模是 IT 团队预期的 3-10 倍。

概要

Model Context Protocol 在 2026 年跨越了少数集成协议才能达到的门槛：1.1 亿月度 SDK 下载量、1 万多个已追踪的公开服务器、500 多个 MCP 客户端，覆盖 Claude、ChatGPT、Cursor、VS Code 和 Replit 等平台。在 2026 年 4 月纽约 MCP 开发者峰会上，叙事重心从采用指标转向了基础设施治理。头部数字令人印象深刻，但真正的故事在于接下来会发生什么。

2026-07-28 规范发布候选版于 2026 年 5 月 21 日锁定，计划于 7 月 28 日正式发布，这是 MCP 自 2024 年底发布以来最大的一次修订。它彻底移除了 initialize/initialized 握手和 Mcp-Session-Id 头，使协议在传输层变为无状态。三项核心功能——Roots、Sampling 和 Logging——被正式废弃。扩展成为一等公民：MCP Apps 提供服务器端渲染 UI，Tasks 扩展处理长时间运行的操作，授权机制与 OAuth 和 OpenID Connect 部署对齐。

这不是可选升级。任何运行 2025-11-25 规范的 MCP 服务器，在客户端升级到 2026-07-28 版本的那一天就会中断。废弃到移除的最短窗口为 12 个月，但会话处理方面的破坏性变更对混合版本部署来说是即刻生效的。

与此同时，生产团队发现协议的爆发式采用造成了治理真空。影子 MCP——在 Cursor、Claude Desktop 和 VS Code 中直接配置的、未经 IT 审核的 MCP 服务器——的运行规模是安全团队预期的 3 到 10 倍。MCP 开发者峰会 23 场会议聚焦安全，关于影子 MCP 检测的演讲座无虚席。Qualys、Darktrace 和 AquilaX 均已发布识别和管控企业环境中未审核 MCP 服务器的框架。

2026 年 MCP 核心矛盾在于：协议已成熟到需要企业级治理，但仍足够年轻以至于生产模式往往是在事故之后才被发现。

背景

Anthropic 于 2024 年 11 月推出 Model Context Protocol，作为连接 AI 助手与外部工具和数据源的开放标准。核心理念很直接：用基于 JSON-RPC 2.0 的通用协议替代定制集成代码，使任何兼容 MCP 的 AI 客户端都能与任何 MCP 服务器通信。该协议于 2025 年 12 月捐赠给 Linux 基金会的 Agentic AI Foundation，2026 年全年采用加速。

在第一年，MCP 解决了一个真实的开发者问题。在 MCP 之前，将 LLM 连接到内部系统需要为每个工具和每个模型编写定制集成代码。GitHub 为 GitHub Copilot Chat 提供的 MCP 服务器包在 2026 年 2 月突破了 200 万周安装量。Postgres MCP 服务器——让 AI 助手直接对任何 Postgres 数据库执行 SQL 查询——周安装量超过 80 万。这些不是玩具工具——它们在规模上赋予了 AI 智能体对生产系统的访问权限。

但支撑这一采用的协议是为本地 stdio 连接和单用户桌面应用的世界设计的。2025-11-25 规范要求每个客户端通过 initialize/initialized 握手建立会话，接收 Mcp-Session-Id，然后将所有后续请求路由到同一服务器实例。这对在笔记本电脑上运行单个 MCP 服务器的开发者来说没问题。但对在负载均衡器后部署 6 个 MCP 服务器、每个在单次智能体执行中处理 40 次工具调用的公司来说就行不通了。

到 2026 年初，生产团队已构建了各种变通方案：负载均衡器上的粘性会话、共享会话存储（通常是 Redis）、API 网关上的深度包检测，以及工具调用周围的熔断器包装。这些变通方案让 MCP 在生产环境中得以运行，但增加了协议本应消除的运维复杂性和成本。

MCP 工作组认识到了这一点。2025 年 12 月，他们发布了”The Future of MCP Transports”，规划了使协议无状态化的方案。6 份规范增强提案（SEP）之后，2026-07-28 发布候选版兑现了这一规划。握手消失了。会话 ID 消失了。每个请求在 _meta 字段中携带自己的上下文。服务器可以位于任何轮询负载均衡器之后，无需粘性路由。

问题不再是 MCP 能否扩展——规范重写使之成为可能。问题是团队能否及时迁移、过渡期间什么会中断，以及如何治理一个增长速度超过任何人审计能力的生态系统。

分析

无状态重写：改了什么以及为何重要

2026-07-28 规范的核心变更是移除了协议层的有状态会话管理。这不是微调。这是一种需要彻底决裂的基础性变更——维护者自己也承认这一点。

重写之前，大规模部署远程 MCP 服务器需要三样任何云原生团队都不想维护的东西：

1. 粘性会话——在负载均衡器上，将每个客户端固定到特定服务器实例的整个会话生命周期
2. 共享会话存储（通常是 Redis）——使所有服务器实例能访问相同的会话状态
3. 深度包检测——在 API 网关上提取 Mcp-Session-Id 头并正确路由请求

这种架构与 2010 年困扰有状态 Web 服务器的问题如出一辙，被硬套到了为 AI 工具集成设计的协议上。每次服务器重启都会丢弃活跃会话。自动扩缩容很痛苦，因为新实例需要在接受流量之前同步会话状态。多区域双活部署是一个架构项目，而非配置变更。

重写之后，MCP 服务器部署看起来与任何其他无状态微服务一样。initialize/initialized 握手被内联元数据取代：协议版本、客户端信息和能力信息在每个请求的 _meta 字段中传递。新的 server/discover 方法让客户端在需要时获取服务器能力，而非在连接建立时。Mcp-Session-Id 头被完全移除。

两个新的 HTTP 头——Mcp-Method 和 Mcp-Name——实现了无需会话亲和性的路由和缓存：

• Mcp-Method 声明请求目标的 MCP 方法（如 tools/call、resources/read），在每个请求上必须携带
• Mcp-Name 声明操作适用的资源、工具或提示，用于构建缓存键

列表和资源读取结果现在携带 ttlMs 和 cacheScope 字段，借鉴自 HTTP Cache-Control 语义。客户端确切知道 tools/list 响应的保鲜时长，以及是否可以跨用户共享。这消除了仅为了获知工具列表变更而维持长连接 SSE 流的需求。

W3C Trace Context 传播现在使用固定键（traceparent、tracestate、baggage）进行文档化，因此分布式追踪可以跨 SDK 关联，并在 OpenTelemetry 后端呈现为统一的 span 树。

实际效果立竿见影：以前需要粘性会话、共享会话存储和网关深度包检测的远程 MCP 服务器，现在可以运行在普通的 AWS Application Load Balancer 或 Cloudflare 负载均衡器后面，零自定义路由逻辑。

什么会中断：无状态迁移的生产现实

无状态重写解决了扩展问题。它引入了规范未涉及的新故障模式。

熔断器变得不可或缺。 在有状态世界中，固定到一个服务器实例的客户端会将该实例的故障体验为会话断开。在无状态世界中，服务器故障后客户端的下一个请求会路由到不同实例——但如果故障是系统性的（下游 API 中断、触发速率限制），每个实例都会失败，每个请求都会级联失败。在单次智能体执行中跨 6 个 MCP 服务器运行 40 次工具调用的生产团队已经学会将每次工具调用包裹在熔断器中。dev.to 上的文章”97M MCP Downloads and Still No Production Playbook”详细记录了这一模式：按工具（而非按服务器）设置熔断器是最低可行韧性模式，因为一个不稳定的工具不应拖垮同一服务器上所有工具的访问。

上下文开销转移但未消失。 在 Claude Code 实现工具搜索之前，MCP 工具消耗了 200K token 窗口的 22%。之后，基本为零。Anthropic 的 MCP 联合创建者 David Soria Parra 在开发者峰会上直接回应了这一点：“这些都是非常可解决的问题。而且它们是客户端问题，不是协议问题。“Cloudflare 报告其 Code Mode 将 token 用量从约 9,400（4 个服务器、52 个工具）降至约 600——降幅 94%——方式是让模型针对工具 API 编写代码，而非将每个定义加载到上下文中。

无状态协议，有状态应用。 规范明确指出，移除协议级会话并不意味着应用必须无状态。需要跨调用携带状态的服务器可以从工具中铸造显式句柄（basket_id、browser_id），让模型在后续调用中将其作为普通参数传回。这与 HTTP API 数十年来使用的模式相同。但这要求团队在迁移到无状态模式之前，审计现有 MCP 服务器中的隐式会话依赖——那些在不知不觉中依赖跨调用会话状态的工具。

Chanl 迁移指南推荐三步流程：一个配置变更禁用会话，快速审计隐式依赖跨调用会话状态的工具，以及决定哪些长时间运行的操作适合使用 Tasks 扩展。最后一步是大多数团队将花费最多时间的地方。

Tasks 扩展填补异步缺口。 团队使用会话的原因之一是处理长时间运行的操作——数据库迁移、文件处理、多步骤工作流。2026-07-28 规范引入 Tasks 扩展作为管理异步工作的一等公民方式。任务句柄在智能体和服务器之间流转，替代了会话之前提供的隐式状态。但这是一个扩展，不是核心协议的一部分，团队需要显式采用它。

影子 MCP：新型影子 IT

在 MCP 开发者峰会上，“Shadow MCP: Finding the MCPs Nobody Approved”这场演讲座无虚席。论点直截了当：员工正在 Cursor、Claude Desktop 和 VS Code 中直接配置 MCP 服务器，制造了传统安全工具无法发现的盲区。

问题的规模不容忽视。Digital Applied 的开发者峰会综述报告称，影子 MCP 的运行规模是 IT 团队预期的 3 到 10 倍——这一发现差距意味着大多数组织环境中的 MCP 服务器远比他们知道的多。

AquilaX 的分析指出了原因：到 2026 年初，npm 和 PyPI 注册表托管了数百个已发布的 MCP 服务器包，覆盖 Postgres、GitHub、Slack、Google Drive、AWS 和 Kubernetes。安装一个只需几分钟。无需采购流程。无需安全审查。无需 IT 工单。仅 Postgres MCP 服务器——让 AI 助手直接对任何 Postgres 数据库执行 SQL 查询——就有超过 80 万周安装量。这些是生产级访问权限，却在没有生产级监管的情况下部署。

Qualys 识别了具体的风险类别：

• 凭证暴露：许多 MCP 服务器依赖长期有效的静态密钥（API 密钥），难以轮换、容易过度授权，且会在项目间传播
• 能力发现泄露：工具描述可能将内部系统名称、API 模式和基础设施细节暴露给 AI 模型，进而暴露给模型提供商
• 供应链攻击：MCP 服务器包可能被仿冒或入侵，安装的便捷性意味着恶意包可以在几分钟内运行

在开发者峰会上，一位使用工具 MCPwned 的安全研究员成功对官方 MCP Inspector、Google Cloud Run、Google Database Toolbox、Apollo 的 GraphQL 服务器、Docker 的 MCP 网关和 AWS Labs 的 MCP 服务器执行了任意工具调用。Docker 曾发布博客文章声称其网关受到保护。事实并非如此。该研究员在台上披露了 Google Database Toolbox 的一个零日漏洞——Google 已知该漏洞超过 90 天却未修补。

Darktrace 将治理挑战概括为：“在 2026 年，成功的组织将是那些不仅将 MCP 视为技术集成协议，而是将其视为治理自主 AI 系统的关键安全边界的组织。“

规模化采用：谁做对了

开发者峰会提供了在生产规模上运行 MCP 的组织实例：

Uber——5,000 多名工程师、10,000 多个内部服务、1,500 多个月活跃智能体、每周 60,000 多次智能体执行。他们的方案是一个 MCP 网关和注册中心，通过爬取内部文件并使用 LLM 生成描述，自动将 Uber 的服务端点转换为 MCP 工具。服务所有者保持控制权，但繁重工作已自动化。第三方 MCP 服务器比内部服务器经过更严格的审查——一种刻意的双层信任模型。该网关驱动无代码智能体构建器、面向客户的产品以及 Minions（一个每周产生 1,800 多次干预的后台编码智能体）。

Cloudflare——其 Code Mode 通过让模型针对工具 API 编写代码而非将定义加载到上下文中，实现了 94% 的 token 用量削减。这是一种不需要更改协议或服务器的客户端优化。

Pinterest——在峰会上展示了规模化 MCP 部署，但细节较少公开。模式一致：网关或注册中心层位于智能体和 MCP 服务器之间，强制执行认证、速率限制和审计日志。

这些部署的共同模式是 MCP 网关。arXiv 论文”Bridging Protocol and Production: Design Patterns for Deploying AI Agents with Model Context Protocol”（2026 年 3 月）通过 Context-Aware Broker Protocol（CABP）将此形式化，该协议通过六阶段代理管道扩展 JSON-RPC，实现身份范围请求路由。论文识别了 MCP 仍然缺乏的三个协议级原语：身份传播、自适应工具预算和结构化错误语义。

数据点

指标	数值	来源	日期
MCP SDK 月下载量	1.1 亿	MCP 开发者峰会 2026 主题演讲	2026 年 4 月
已追踪的公开 MCP 服务器	1 万+	Digital Applied	2026 年 4 月
影子 MCP 相对 IT 预期的倍数	3-10 倍	Digital Applied 开发者峰会综述	2026 年 6 月
开发者峰会安全专题会议数	23	Digital Applied 开发者峰会综述	2026 年 6 月
开发者峰会参会人数	约 1,200	Digital Applied 开发者峰会综述	2026 年 4 月
GitHub MCP 服务器周安装量	200 万+	AquilaX	2026 年 2 月
Postgres MCP 服务器周安装量	80 万+	AquilaX	2026 年 2 月
规范 RC 锁定日期	2026 年 5 月 21 日	MCP Blog	2026 年 5 月
规范正式发布日期	2026 年 7 月 28 日	MCP Blog	2026 年 5 月
废弃到移除最短窗口	12 个月	MCP Blog	2026 年 5 月
Cloudflare Code Mode token 削减	约 94%（9,400 降至 600）	Digital Applied	2026 年 4 月
Uber 周智能体执行量	60,000+	AAIF 开发者峰会总结	2026 年 4 月
MCP 工具上下文消耗（工具搜索前）	200K 窗口的 22%	MCP 开发者峰会（David Soria Parra）	2026 年 4 月
达到 1.1 亿月下载量用时	16 个月	MCP 开发者峰会主题演讲	2026 年 4 月

🔺 独家情报：别人遗漏的关键

置信度： 高 | 新颖度评分： 82/100

大多数报道将 7 月 28 日规范框定为让 MCP 更易扩展的升级。这种框定忽略了关键动态：2025-11-25 稳定规范现在是一种负债，而非基线。将无状态迁移视为可选的生产团队，会在第一个客户端升级时发现会话在混合版本部署中悄然中断——而规范不提供向后兼容桥。与此同时，被废弃的三项功能（Roots、Sampling、Logging）并非无人使用的残留功能：Roots 尤其嵌入在 2025 年基于 MCP 构建的公司的工具发现模式中。12 个月的废弃窗口听起来宽裕，但它从标注日期开始计算，而非从团队发现其依赖关系的日期。另外，开发者峰会上 MCPwned 的零日披露——Google 在一个周安装量 80 万+ 的服务器上超过 90 天未修补的漏洞——表明供应链风险并非理论上的。在 MCP 上做对的组织（Uber、Cloudflare）有一个共同特征：它们运行了一个协议不要求、大多数团队尚未构建的网关层。

关键启示： 在 2025 规范上运行 MCP 服务器的工程负责人必须在 7 月 28 日之前审计隐式会话依赖并安排无状态迁移——同时盘点团队已部署的每一个 MCP 服务器，因为大多数组织中已知与实际 MCP 端点之间的安全差距是以倍数衡量的，而非百分比。

展望

短期（3-6 个月）

7 月 28 日最终规范将触发 Tier 1 维护者（TypeScript、Python、Java、Go）的 SDK 更新浪潮。未审计 MCP 服务器会话依赖的团队将在客户端自动升级时遭遇中断。对大多数服务器而言，迁移工作量不大——一个配置变更禁用会话，一次跨调用状态审计——但发现阶段（找到所有隐式依赖）将消耗大部分精力。预计 2026 年 8-9 月混合版本部署交互时会出现生产事故高峰。

影子 MCP 发现工具将作为一个产品品类出现。Qualys TotalAI 和 Darktrace SECURE AI 已包含 MCP 检测能力；预计 CrowdStrike、Palo Alto 和 Wiz 将跟进。市场信号明确：3-10 倍的发现差距是一个企业级销售机会。

中期（6-18 个月）

MCP 网关模式将成为标准。arXiv CABP 论文将 Uber 和 Pinterest 已在生产中实践的做法形式化：一个处理智能体与 MCP 服务器之间身份传播、速率限制和审计日志的代理层。这要么在未来的规范修订中被标准化，要么通过开源实现成为事实标准。

Tasks 扩展将重塑团队处理长时间运行操作的方式。目前，团队将会话用作多步骤工作流的隐式状态机制。显式的基于句柄的模式（任务 ID 作为参数传递）更健壮，但需要重新架构现有工具实现。

MCP Apps 扩展（服务器端渲染 UI）将打开新的攻击面。通过 AI 工具界面交付的服务器端渲染内容是当前安全框架未解决的提示注入和内容欺骗的攻击向量。

长期（18 个月以上）

MCP 正在走 HTTP/1.1 到 HTTP/2 的轨迹：一个适用于小规模采用的有状态协议，被一个实现水平扩展的无状态协议取代，随后通过扩展加回团队需要的功能（多路复用、服务器推送、优先级）。废弃策略确保未来的规范修订不会需要同样的彻底决裂。

更困难的长期问题是治理。MCP 生态系统的增长速度超过了管理它的工具。1 万多个公开服务器和数亿次下载创造了一个任何单一组织都无法审计的供应链面。协议的开放性——其对采用的最大优势——也是其在安全方面的最大弱点。预计将出现分化：由 Agentic AI Foundation 或云提供商运营的经过审核验证的 MCP 服务器注册中心，与当前的开放生态并存，企业采购将越来越多地要求注册中心验证的服务器。

相关报道

• OpenAI Jalapeño：宣告 AI 推理成本战的自研芯片 — 定制推理芯片与 MCP 部署的智能体同样需要应对的成本曲线
• 中国下令人形机器人进工厂：6 个月强制令 — 国家主导的大规模 AI 部署，MCP 治理模式将面临最严峻考验
• 生成式 AI 正在设计从未存在过的蛋白质——而且它们有效 — 依赖 MCP 等工具集成协议将模型连接到湿实验系统的 AI 驱动发现

来源

• The 2026-07-28 MCP Specification Release Candidate — MCP Blog（S 级，官方）
• MCP Dev Summit 2026 Readout: The Protocol Grows Up — Digital Applied（A 级）
• 97M MCP Downloads and Still No Production Playbook — DEV Community（A 级）
• What Every MCP Builder Needs to Know Before July — Gravitee（B 级）
• Shadow MCP: The New Security Risk of Unvetted AI Agent Tools — AquilaX（B 级）
• MCP Servers: The New Shadow IT for AI in 2026 — Qualys（A 级）
• 7 MCP Risks CISOs Should Consider and How to Prepare — Darktrace（A 级）
• MCP Is Now Enterprise Infrastructure: Dev Summit NA 2026 — AAIF（A 级）
• Bridging Protocol and Production: Design Patterns for Deploying AI Agents with MCP — arXiv（A 级）
• How to Migrate Your MCP Server to Stateless Mode — Chanl（B 级）