技术资讯

MCP 协议将发布史上最大更新：不再有会话，不再有握手

hanghai tian

• 阅读时间 11 分钟
分享

MCP 协议史上最大更新：无状态化深度分析

文档版本: V1.0
编写日期: 2026-07-22
信息来源: OSCHINA 报道、MCP 官方规范、SEP 索引
关键词: MCP, Model Context Protocol, 无状态, SEP, JSON-RPC, OAuth 2.1, 扩展

目录

  1. 概述
  2. 更新背景
  3. 六大核心变化详解
  4. 3.1 移除 Mcp-Session-Id —— 协议层无状态化
  5. 3.2 删除初始化握手
  6. 3.3 显式 Handle 模式管理跨调用状态
  7. 3.4 服务器到客户端请求约束
  8. 3.5 新增强制请求头
  9. 3.6 OAuth 2.1 认证安全实践
  10. 扩展成为一等公民
  11. 4.1 MCP Apps (SEP-1865)
  12. 4.2 Tasks 扩展 (SEP-2663)
  13. Schema 能力提升
  14. 安全审计与新攻击面
  15. 特性淘汰策略
  16. 三个硬断裂变更
  17. 影响分析与迁移建议
  18. 总结与个人看法

1. 概述

2026 年 7 月 21 日，Anthropic 开源社区正式公布了 MCP（Model Context Protocol）有史以来最重大的一次更新。RC 从 5 月 21 日锁定，经过 10 周的 SDK 验证和社区反馈，最终版规范定于 2026 年 7 月 28 日 正式发布。

一句话总结：MCP 变无状态了。

MCP 规范封面

图：MCP 规范封面

这次更新由 六个 SEP（Specification Enhancement Proposal，规范增强提案） 协同完成，核心目标一致——消除协议层的状态。六项 SEP 覆盖了从传输层到认证层的全面重构，将 MCP 从一个有会话（session）的协议彻底转变为无状态、水平可扩展、与 HTTP 对齐的协议。

2. 更新背景

MCP 自发布以来，一直基于 JSON-RPC 2.0。JSON-RPC 本身是无状态的——每个请求独立、不依赖上下文。但 MCP 在传输层引入了 Mcp-Session-Id 头和 initialize/initialized 握手流程，使得协议背上了"有状态"的包袱。

这对企业级部署带来了两大问题：

  • 水平扩展困难：同一客户端的请求必须路由到同一个服务器实例（sticky session），或依赖共享 session store，增加了基础设施复杂度
  • 部署成本高：负载均衡器需要感知 session，运维复杂度翻倍

MCP 维护团队此次的回应是——回到 JSON-RPC 的根，砍掉所有协议层状态。

3. 六大核心变化详解

3.1 移除 Mcp-Session-Id —— 协议层无状态化

这是本次更新最核心的变更。Mcp-Session-Id 头被彻底移除。

MCP 架构对比

图：MCP 旧版架构与新版无状态架构的对比示意图

MCP 架构对比(图片版)

图：MCP 更新前后的架构变化（图片版）

旧模式：
- 客户端发起连接时分配 Mcp-Session-Id
- 后续请求必须携带此 ID，所有请求路由到同一服务器实例
- 负载均衡器需要 sticky session 或共享 session store

新模式：
- 无 Mcp-Session-Id 头
- 请求可以落到任何服务器实例
- 与 HTTP 的设计哲学完全对齐

影响：传输层中如有 sessionIdGenerator 配置，必须删除。协议版本和客户端信息改从 _meta 字段读取。

3.2 删除初始化握手

initialize / initialized 握手流程被删掉。这意味着：

  • 协议版本、客户端信息、能力声明不再在"连接时"一次性协商
  • 改为通过每个请求的 _meta 字段传递
  • 服务器不能在连接时做一次权限校验就了事——每次请求都得自己能站住

MCP 新旧对比图

图：MCP 更新前后的变化对比

影响：能力校验逻辑从握手阶段移到每个工具调用的入口，对服务器实现提出了更高的安全性要求。

3.3 显式 Handle 模式管理跨调用状态

跨调用的状态怎么办？MCP 维护者的回答——显式化。

服务器返回一个不透明的 handle（如 basket_id），模型在后续调用中主动传回来。团队的原话：

"显式 handle 模式只是把状态从协议层藏起来变成了模型可见。"

换句话说：不要把状态藏在协议层，让模型自己管理。

这对调试和审计也更友好：所有的状态传递都在参数中可见，不再有隐式 session 状态。

3.4 服务器到客户端请求约束

以前服务器可以随时推送（如请求用户输入），持续维持 SSE 连接。现在：

  • 服务器只能在处理客户端请求期间发起反向请求
  • 结果通过 InputRequiredResult 带一个 requestState token 返回
  • 客户端重新发起原调用时带上 inputResponses
  • 任何实例都能接住这个重试，不需要去找原来的服务器

这一变更彻底消除了对长连接 SSE 的依赖，使得服务器实例可以自由扩缩容。

3.5 新增强制请求头

两个新增的强制请求头：

请求头 说明
Mcp-Method 标识调用的方法名称
Mcp-Name 标识调用的具体工具/资源名称

有了它们，网关和负载均衡器不需要解析请求 body 就能做路由决策——这对企业部署是实打实的利好。

3.6 OAuth 2.1 认证安全实践

六个 SEP 将 OAuth 2.1 安全实践写进了规范正文：

  • 客户端必须验证 iss 参数防止 mix-up 攻击
  • 支持 Dynamic Client Registration
  • 凭证绑定到颁发服务器
  • 刷新 token 流程文档化
  • scope 累积规则明确
  • 旧式的密码授权和隐式授权被彻底剔除

4. 扩展成为一等公民

扩展在此次更新中升级为一等公民：

  • 使用反向 DNS 标识（如 ext-*.mcp.io）
  • 通过 extensions 能力映射协商
  • 独立的 Extensions Track 管理生命周期
  • 社区创新可独立于核心规范演进和版本化

4.1 MCP Apps (SEP-1865)

服务器可以在沙箱化 iframe 中提供 HTML UI，工具预先声明 UI 模板以支持预加载和缓存。关键特性：

  • UI 与宿主之间的通信走的是同一套 JSON-RPC 协议
  • 审计和授权路径与直接工具调用完全一致
  • 本质上将 MCP 从纯 API 协议扩展到了交互式 UI 领域

4.2 Tasks 扩展 (SEP-2663)

Tasks 从实验性核心功能毕业到扩展。改为轮询模式：

方法 说明
tasks/get 获取任务状态
tasks/update 更新任务
tasks/cancel 取消任务
  • 任务创建变为服务端决策（客户端声明支持，服务端决定是否走异步）
  • tasks/list 被直接移除——因为缺乏 session 后无法安全限定范围

5. Schema 能力提升

inputSchema 和 outputSchema 现在完整支持 JSON Schema 2020-12：

特性 支持情况
oneOf / anyOf / allOf [OK]
条件 (if/then/else) [OK]
$ref / $defs [OK]
  • 输入 schema 的根节点仍约束为 type: "object"
  • 输出 schema 不受限制
  • 规范明确要求：不要自动解引用外部 $ref URI（防 SSRF）
  • 应限制 schema 深度和校验时间

6. 安全审计与新攻击面

Akamai 的安全研究团队在这个 RC 上做了一轮安全审计，结论诚实而清晰：

消除的风险：
- 协议层 session 劫持
- 未经请求的服务端推送
- 弱认证方式

新攻击面（5 个）：

攻击面 说明 严重程度
跨 agent 工作流劫持 tracking ID 可预测或 state 未经校验时，攻击者可劫持其他用户工作流 高
_meta 对象注入 服务器盲目信任元数据做路由/授权决策时，无签名自定义字段可成提权通道 高
头部与 body 反序列化冲突 Mcp-Method 头和 JSON-RPC body 不一致时可能绕过安全控制 中
MCP Apps 存储型 XSS 沙箱 iframe 的 UI 仍面临钓鱼和数据窃取风险 中
一击脱离 DoS 攻击者发起昂贵长时间任务后立即断开，服务器自己扛所有计算成本 低-中

关键洞察：以前协议层帮你挡掉的脏活，现在搬到了应用层。安全性不再由协议保证，而是由实现质量决定。

7. 特性淘汰策略

协议引入了全生命周期的特性淘汰策略：

Active -> Deprecated -> Removed
  • 每个阶段至少 12 个月
  • SEP 要上到 Final 级别，必须有对应的合规测试用例落地

进入倒计时的三个原语：

原语 剩余时间 替代方案
Roots 12 个月 工具参数或资源 URI 替代
Sampling 12 个月 直接调 LLM API
Logging 12 个月 stderr 或 OpenTelemetry

8. 三个硬断裂变更

以下三个变更今天立即生效：

8.1 Mcp-Session-Id 头消失

  • 传输层中 sessionIdGenerator 配置必须删除
  • 协议版本和客户端信息改从 _meta 读取

8.2 初始化握手消失

  • initialize / initialized 握手删除
  • 能力校验逻辑从握手阶段移到每个工具调用的入口

8.3 错误码变更

  • 资源未找到的错误码从 MCP 自定义的 -32002 改为 JSON-RPC 标准的 -32602（Invalid Params）
  • 所有硬编码该值的地方都要替换

9. 影响分析与迁移建议

影响程度分级

场景 影响程度 说明
简单工具服务（无 session 依赖） 低 几乎不受影响
中等复杂度服务（依赖 session 存储） 中 需要重写状态管理逻辑
复杂企业级服务（深度耦合 MCP session） 高 需要架构级重构

迁移时间线

2026-05-21 RC 锁定
2026-07-28 最终版规范定稿
   |
   v
2027-07-28 (12 个月)
Roots / Sampling / Logging 正式移除

迁移建议

  1. 立即检查：扫描代码中所有 Mcp-Session-Id、sessionIdGenerator、-32002 硬编码
  2. 握手阶段：将 initialize 中的能力协商逻辑迁移到每个工具调用的入口
  3. 状态管理：将隐式 session 状态改为显式 handle 模式（如 basket_id、task_id）
  4. 认证升级：确保 OAuth 2.1 流程合规，移除旧式密码授权和隐式授权
  5. Schema 升级：利用 JSON Schema 2020-12 的新特性增强输入校验
  6. 扩展迁移：将 rooted 功能改为工具参数传递，Sampling 改为直接调 API，Logging 改为 OpenTelemetry

10. 总结与个人看法

MCP 这次更新的方向是对的。session 的引入本身是工程上的捷径——让一个天生无状态的 JSON-RPC 协议背上有状态包袱，部署复杂度直接翻倍。切掉之后，水平扩展回到纯 HTTP 的玩法，对企业级部署来说是及格线而不是加分项。

显式 handle 模式是个聪明的选择。让模型自己管理状态，不是增加了复杂度，而是让复杂度发生在它本来就该发生的地方——推理层。对调试和审计也更友好，所有的状态传递都在参数里可见。

短期阵痛主要在迁移——任何深度依赖 MCP session 机制的服务需要重写状态管理逻辑。但那些本来就不依赖 session 的简单工具服务，基本不受影响。

12 个月的弃用窗口给足了时间。问题是，有多少人会等到第 11 个月才开始动手。

对于使用 MCP 的 Agent 框架开发者来说，这次更新意味着三件事：

  1. 部署更简单了 — 不用再为 sticky session 操心，Kubernetes 上的水平扩展变得无痛
  2. 安全责任下移 — 以前协议层帮你挡掉的攻击面，现在需要自己在应用层防御
  3. 扩展生态启动 — 从 MCP Apps 到 Tasks，社区的创新能力将被释放

参考资料

  1. OSCHINA - MCP 协议将发布史上最大更新
  2. MCP 官方规范 (v2025-11-25)
  3. MCP SEP 索引
  4. MCP 架构概览
  5. MCP GitHub 仓库
  6. What actually breaks in your MCP server on 2026-07-28 — dev.to
  7. New MCP specification kills old risks but opens fresh attack surfaces, Akamai finds — SiliconANGLE
苏ICP备19018690号-1