设想一个场景：你打电话给客服，先要等语音提示输入账号密码（握手），然后系统分配一个专属客服代表给你（session），所有对话都绑定在这个客服身上。如果中途断线，一切重来。这就是 MCP 当前的协议模型。

2026 年 7 月 28 日发布的 MCP 规格 RC 完全推翻了这套模型。新协议去掉握手、去掉 session、每个请求独立处理，就像从「打电话」变成了「发微信」。截止 2026 年 5 月，MCP 协议月安装量已超过 9700 万次，社区贡献超过 10,000 个 MCP 服务器，拥有 7 种官方语言 SDK。

• MCP 2026-07-28 RC 移除 initialize 握手和 Session ID，任何请求可落到任何 server 实例
• Streamable HTTP 新增强制 headers（Mcp-Method、Mcp-Name），server/discover 替代能力协商
• Tasks 扩展和 MCP Apps 扩展同时引入：异步工作流 + 交互式 UI
• 协议已捐赠给 Linux Foundation 下的 Agentic AI Foundation，弃用政策正式确定

去状态化到底是什么？从「打电话」到「发微信」

截至 2026 年 5 月，MCP 协议月安装量超过 9700 万次。在如此规模下，session 亲和性带来的运维成本已经成为增长瓶颈。MCP 当前的协议模型基于 session 和状态连接。必须先拨号建立连接（initialize 握手），系统分配一个 session，所有通信绑定在这个 session 上。新协议把模型彻底改为无状态设计——任何请求可以落到任何 server 实例。这就像从「打电话」切换到了「发微信」，你不依赖之前的对话状态，服务器可以自由选择谁来处理。

这次重构涉及哪些核心变更？

重构涉及四份 SEP（Spec Enhancement Proposal）：

• SEP-2575：移除 initialize/initialized 握手流程
• SEP-2567：移除 Mcp-Session-Id header 和协议层 session
• SEP-2596：Streamable HTTP 引入强制 headers（Mcp-Method、Mcp-Name）
• SEP-2598：新增 server/discover 方法替代传统能力协商

SEP-2575 移除了什么？为什么不需要握手了？

SEP-2575 移除 MCP 协议中的初始化握手阶段。旧版本客户端必须先发送 initialize 请求，服务器回复 initialized 响应，双方交换协议版本和能力信息后才能通信。移除后，客户端无需任何前置握手，直接发送功能请求。版本协商通过 server/discover 方法处理，但不再是通信前置条件。这意味着通信的启动延迟从「2 轮 RTT + 处理时间」降到了 0（MCP 规格 SEP-2575, 2026）。

SEP-2567 移除 Session ID 解决了什么部署问题？

SEP-2567 彻底移除了 Mcp-Session-Id header 和协议层 session 概念。旧模型中每个 MCP 连接都有唯一 session ID，服务器通过它维护客户端状态。任何偏离 session 亲和性的部署都会导致状态丢失。移除 session 之后，每个请求完全独立，负载均衡器可自由分发请求到任意实例。这对于 Kubernetes 部署、serverless 函数、边缘计算节点是现代基础设施的巨大简化（MCP 规格 SEP-2567, 2026）。

Streamable HTTP 新强制 headers 有什么用？

SEP-2596 引入了两个强制 header：Mcp-Method（标识客户端期望调用的 MCP 方法）和 Mcp-Name（标识客户端身份名称）。反向代理和 API 网关可以在 HTTP 层面直接做智能路由：把 tools/call 转发到高计算节点，把 resources/list 转发到缓存服务，无需解析请求体（MCP 规格 SEP-2596, 2026）。

Tasks 扩展如何改变 tools/call 的工作方式？

Tasks 扩展解决的核心问题：Agent 调用工具，工具执行需要很长时间（几分钟甚至几小时），客户端怎么办？旧模型下客户端必须在同一 session 内保持连接等待。新模型：服务器收到 tools/call 后立即返回 task handle，客户端通过 tasks/get 获取进度，通过 tasks/cancel 中止任务。任务生命周期完全由应用层管理，不依赖传输层 session 存活状态。

MCP Apps 扩展如何让工具返回交互式 UI？

MCP Apps 允许工具在响应中包含 ui:// 资源协议，这些资源可在聊天客户端界面中渲染成交互式 UI 组件。Agent 调用数据分析工具查询销售数据，不仅可以返回 JSON 数据，还能返回一个 ui://dashboard/sales-q 2 资源，渲染成带筛选器、时间轴的完整交互式仪表盘。Amplitude、Asana、Box、Canva、Figma、Slack 等 9 家公司在发布日集成（MCP Apps 扩展规格，2026）。

迁移时间线和优先级

• 2026 年 5 月-7 月（阅读期）：阅读 SEP 内容，评估 session 依赖的改造工作量
• 2026 年 7 月-10 月（适配期）：官方 SDK 同步更新，新项目直接用无状态模型，现有服务器升级
• 2026 年 10 月-2027 年 1 月（迁移期）：旧握手机制标记弃用但可用，生产环境完成迁移
• 2027 年 1 月之后：旧握手和 session ID 正式移除

优先迁移场景：高并发 MCP 服务器（需要水平扩展）、企业级部署（需要 OAuth/OIDC 集成）、使用异步工作流的 Agent 应用（需要 Tasks 扩展）。本地 Claude Desktop 工具迁移时间相对宽裕。

协议捐赠给 Linux Foundation 的影响

2026 年，MCP 协议正式捐赠给 Linux Foundation 旗下的 Agentic AI Foundation。MCP 不再是 Anthropic 控制的私有标准，而是由基金会管理的开放标准。规格变更需要经过基金会技术委员会评审，贡献者需要签署基金会 CLA。从社区反馈来看，协议捐赠直接推动了 3 家大型云服务商开始规划 MCP 原生服务。

FAQ

我的 MCP 服务器是不是必须重写？

不一定。官方 SDK 会在 RC 发布时同步更新。基于官方 SDK 开发的服务器只需升级 SDK 版本并修复 session 相关代码。超过 70% 的社区 MCP 服务器依赖官方 SDK（MCP 官方 GitHub 仓库，2026 年 5 月）。

没有 session，我的服务器怎么跟踪用户状态？

应用层状态不应放在传输层 session 中。建议使用 OAuth token 携带用户身份，或将状态持久化到存储层并在每次请求中透传上下文标识。这是微服务架构的最佳实践。

Tasks 和 Streamable HTTP 应该怎么选？

Streamable HTTP 适合返回速度快且需要流式输出的场景（如 LLM token 流）。Tasks 适合时间长且需要跨连接追踪进度的场景（如视频渲染、代码编译）。两者可以共存。

MCP Apps 安全吗？会不会有 XSS 风险？

ui:// 资源通过沙箱 iframe 渲染，遵循同源策略并启用严格的 sandbox 属性（禁止执行脚本、禁止表单提交、禁止导航）。安全边界始终严格维持。

我应该在什么时候放弃旧握手方式？

建议在 2026 年 10 月前完成迁移。届时新版 SDK 会默认使用新传输模型。面向公众的 MCP 服务器应尽快迁移以避免客户端兼容性问题。企业内网环境时间相对充裕。

作者：智盒（aiKit.vip）｜ 资讯 · 资源 · 工具 · 导航