MCP · 协议 · 工程实践

MCP 7月大版本来了：无状态化、Breaking Changes、MCP Apps——你的Server要改吗？

2026-06-30 · RC已发布 · 正式版2026-07-28生效

⚠️ 如果你在生产环境跑MCP Server，这篇文章你必须看完。 2026年7月28日，Model Context Protocol将发布自诞生以来最大规模的版本更新。breaking changes级别。

---

先说结论

MCP 2026-07-28 版本不是一次普通的版本升级。它动到了协议核心：无状态化。

这意味着：

• 如果你自建了MCP Server——session ID将从协议层面移除，你的server必须改。
• 如果你是重度MCP用户——你依赖的server会不会断，取决于它什么时候迁移。
• 如果你在做Agent基础设施选型——"是否支持无状态MCP"应该成为评估项。

RC已经于2026年5月21日发布，现在正处于10周验证窗口期。7月28日正式版发布后，主流客户端会逐步切换。拖到那时候再动就是被动迁移。

---

MCP现在是什么体量？

指标	数据
公开MCP Server	13,000 ~ 23,000+
官方SDK月下载量（2026.03）	9,700万次
近6个月增长率	300%
生态累计Stars	300,000+
主流支持客户端	Claude Code、Cursor、VS Code、Zed、ChatGPT、Copilot、Windsurf等
企业采用	Anthropic、OpenAI、Google、Microsoft、AWS、Salesforce

MCP已经从Anthropic的一纸规范，成长为Linux Foundation治理下的行业基础设施。这么大的生态，每一次breaking change都要付出巨大迁移成本。但这次不得不改——因为现协议的基础设施局限性已经到了天花板。

---

旧协议有什么问题？

当前的MCP协议（2024-11-25规范）基于session模型：

• 客户端和server建立session，后续请求依赖session内的状态
• 部署远程server时，必须配sticky session（粘性会话）
• 负载均衡器开session亲和性，扩容缩容都得小心翼翼
• 挂一个实例，在途session全断

这对本地开发没问题。但一旦上生产、做远程server——这些基础设施层面的限制就成了真痛点。

同时还有几个次生问题：

tools/list无法缓存： 每个客户端连上来就全量拉一次工具列表，Server多的时候延迟和流量都很可观。
无法水平扩展： session状态粘在实例上，云原生的弹性伸缩几乎不可能。
运维复杂度高： 需要共享session store、deep packet inspection网关——这些运维负担劝退了很多潜在的server开发者。

---

2026-07-28版本的核心变化

变化一：协议无状态化

维度	旧版	新版
Session管理	Mcp-Session-Id头，服务端维护状态	完全移除，每个请求自包含路由信息
initialize握手	连接时一次握手交换capabilities	在_meta中随请求携带，新增server/discover按需获取
负载均衡	必须sticky session	普通round-robin，任意实例处理任意请求
网关路由	需要deep packet inspection解包JSON body	Mcp-Method / Mcp-Name HTTP头直接路由

旧版部署：

upstream mcp_servers {
    ip_hash;  # session亲和，否则请求落错实例就断
    server mcp1:8080;
    server mcp2:8080;
}

新版部署：

upstream mcp_servers {
    round-robin;  # 任意实例处理任意请求
    server mcp1:8080;
    server mcp2:8080;
    server mcp3:8080;  # 随时加，不中断
}

变化二：Mcp-Method/Mcp-Name HTTP头

每个请求必须携带这两个头，负载均衡器可以直接按方法名做路由，不用解包JSON body。

# Streamable HTTP Transport 新增必需头
Mcp-Method: tools/call
Mcp-Name: my-search-server

# 网关可以直接路由，无需解包
if ($http_mcp_method = "tools/call") {
    proxy_pass http://mcp_executor;
}

Server端会校验头和body的一致性，不一致直接拒绝。

变化三：tools/list可缓存

server声明 ttlMs + cacheScope，客户端按策略缓存工具列表。

{
  "result": {
    "_meta": {
      "ttlMs": 300000,
      "cacheScope": "global"
    },
    "tools": [...]
  }
}

---

新能力：MCP Apps

这是本次版本最引人注意的新特性——SEP-1865：MCP Apps。

以前tools只能返回文本或结构化数据。现在tools可以返回交互式HTML界面，客户端在沙箱iframe中渲染。

工作流程：

1. Server声明工具可用的UI模板（host可预取、缓存、安全审查）
2. Host在沙箱iframe中渲染UI
3. UI通过postMessage与Host通过JSON-RPC双向通信
4. 每次UI触发的动作走与直接tool call相同的审计和同意路径

Claude、ChatGPT、VS Code + GitHub Copilot、Goose已经采用MCP Apps。

MCP Apps ≠ Web应用。MCP Apps是在AI对话流中嵌入的交互式UI组件——比如一个数据查询工具返回一个可排序的表格界面，而不是markdown表格文本。

---

新能力：Tasks扩展

Tasks从实验性功能正式升级为一级扩展。

以前处理耗时任务（几秒到几分钟）只能靠持有SSE流。Tasks解决了这个问题：

• server调用 tools/call 返回task handle
• 客户端通过 tasks/get、tasks/update、tasks/cancel 驱动生命周期
• tasks/list 被移除（无session下无法安全做scope限定）

---

Breaking Changes清单

必须改的

变更项	影响
Session ID移除	所有读Mcp-Session-Id的代码必须改为显式参数传递
initialize握手移除	capabilities改为_meta中随请求携带
Streamable HTTP新增必需头	必须添加Mcp-Method / Mcp-Name头
Tools List缓存策略	旧版实时返回的Server可直接声明ttlMs
W3C Trace Context	分布式追踪标准化

已弃用（12个月后移除）

功能	替代
Roots	无替代（取消该能力）
Sampling	客户端级采样
MCP Logging	W3C Trace Context

---

迁移路线图

时间	事件
2026-05-21	RC发布，10周验证窗口开启
2026-07-28	正式版发布
2026.07-08	主流SDK更新，客户端逐步切换
2026.08-12	MCP Registry Alpha启动，安全认证Server计划推进
2027+	旧版本支持逐步下线

给你的行动建议

• 自建MCP Server的团队： 现在就去读RC公告，对照breaking changes清单评估迁移量。
• 重度MCP用户： 关注你依赖的Server是否跟进。正式弃用政策意味着旧版本的兼容窗口有了明确期限。
• Agent基础设施选型： 把"是否支持无状态MCP"加进评估项。能水平扩展的MCP网关和不能的，半年后运维成本不是一个量级。

---

迁移示例：Node.js Server改动前后

旧版 - 依赖session：

import { Server } from "@modelcontextprotocol/sdk/server";

const sessionState = new Map();  // session粘性状态

const server = new Server(
  { name: "my-server", version: "1.0.0" },
  { capabilities: { tools: {} } }
);
// 需要sticky session才能保证状态一致性

新版 - 无状态：

import { Server } from "@modelcontextprotocol/sdk/server";

const server = new Server(
  { name: "my-server", version: "2.0.0" },
  {
    capabilities: { tools: {} },
    cacheTtlMs: 300000,
    cacheScope: "global"
  }
);

// 状态从session移到了工具参数里
server.setToolHandler("query", async (args) => {
  // args.sessionToken - 显式传入，不依赖会话状态
});

---

这次升级意味着什么？

1. 从"Anthropic的协议"变成"行业基础设施"。 无状态化、标准追踪、缓存策略——这些都不性感，但LSP当年也是靠这种不性感的工程细节赢的。一个协议真正成为基础设施的标志，就是基础设施层面的特殊性越少越好。

2. Server开发门槛降低。 无状态意味着你可以用普通HTTP服务的方式开发MCP Server，不需要理解session管理、状态同步这些复杂概念。这会进一步加速Server生态的爆发。

3. 企业级部署成为可能。 无状态+水平扩展+标准化认证+W3C追踪——这些是企业IT采购MCP的必备条件。7月版本第一次让MCP具备了真正的"企业就绪"属性。

4. MCP Apps改变交互范式。 从一个纯文本/数据交换协议，进化为可以承载交互式UI的协议。这对Agent应用的体验设计有深远影响。

最后一句： 10周验证窗口不是留给观望的。如果你的Server在生产线上，现在就应该拉一份RC Spec，跑一遍兼容性测试。7月28日不是deadline——是旧版本倒计时的开始。

---

参考来源： MCP官方博客《The 2026-07-28 MCP Specification Release Candidate》(2026-05-21) · Gravitee《What Every MCP Builder Needs to Know Before July》(2026-06-19) · MCP Migration Studio《Every breaking change in the 2026-07-28 MCP spec》(2026-06-09) · AIEII《MCP要无状态化了》(2026-06-13) · 志趣《MCP协议与生态指南》(2026-06-22) · 36氪《从25000个星标看MCP协议的真机遇与伪泡沫》(2026-06-21)

版权声明： 本文技术细节基于MCP官方RC公告及社区分析综合整理。如有更新请以官方2026-07-28正式版Spec为准。