MCP 2026-07-28规范即将发布：无状态协议、负载均衡与SDK迁移要点

文章摘要

MCP计划于2026年7月28日发布新规范，这是协议推出以来规模最大的修订之一。核心变化是协议层转向无状态，远程MCP Server不再依赖粘性会话和共享Session Store，并新增方法路由、工具列表缓存、扩展机制与更清晰的生命周期策略。本文解释这些变化对生产部署、网关、SDK和兼容性意味着什么。

一、先说明时间点

截至2026年7月18日：

  • 2026-07-28规范仍处于Release Candidate阶段；
  • 最终规范计划于2026年7月28日发布；
  • RC已经锁定，供SDK维护者和企业项目验证；
  • 新版本包含破坏性变化；
  • 现有MCP Server不会在7月28日突然停止工作。

开发者需要区分：

规范发布
≠ 旧协议立即下线
≠ 所有SDK自动升级

二、最大变化：协议层无状态化

旧版远程MCP链路通常需要：

Client
→ Load Balancer
→ 固定MCP Server实例
→ Session Store

由于初始化和协议会话状态，生产部署可能需要：

  • Sticky Session；
  • 共享Session Store；
  • 会话恢复；
  • 网关识别协议消息；
  • 实例间同步。

新规范的目标是：

Client
→ 普通负载均衡
→ 任意MCP Server实例

协议层不再要求维护长期会话。

这使MCP Server更接近普通无状态HTTP服务，可以：

  • 水平扩容；
  • 使用轮询负载均衡；
  • 快速替换实例；
  • 减少共享状态；
  • 简化容器与Serverless部署。

三、无状态不等于业务没有状态

以下状态仍然存在：

  • 用户身份；
  • 租户；
  • 任务进度；
  • 长任务结果；
  • 审批状态；
  • 业务事务；
  • 数据库游标；
  • 文件上传状态。

区别是协议传输状态不再强绑定某个MCP Server实例。

业务状态应进入：

  • 数据库；
  • 缓存；
  • 对象存储；
  • 任务系统；
  • 客户端上下文；
  • 扩展定义的任务资源。

四、负载均衡会变简单

旧部署可能配置：

ip_hash;

无状态后可以使用普通轮询：

upstream mcp_servers {
    server mcp-1:8080;
    server mcp-2:8080;
    server mcp-3:8080;
}

server {
    location /mcp {
        proxy_pass http://mcp_servers;
    }
}

实际迁移时仍要确认：

  • SDK是否支持新规范；
  • Transport是否启用无状态模式；
  • 身份令牌是否可在实例间验证；
  • 工具执行状态是否外置；
  • 长任务是否采用Tasks扩展。

五、Mcp-Method请求头有什么用

新规范引入 Mcp-Method 请求头，网关可以更容易识别请求类型。

潜在用途包括：

tools/list
tools/call
resources/read
prompts/get

网关可以据此：

  • 分流；
  • 限流；
  • 统计；
  • 鉴权；
  • 审计；
  • 设置不同超时；
  • 对高风险工具调用增加策略。

示例：

如果Mcp-Method = tools/list
→ 允许缓存
→ 较低限流

如果Mcp-Method = tools/call
→ 检查用户身份
→ 执行工具级权限
→ 记录完整审计

不要只依赖请求头做安全判断，因为客户端输入可被伪造。最终授权仍需根据已解析的协议消息和服务端权限配置完成。

六、tools/list缓存可以降低发现成本

新规范支持客户端根据 ttlMs 缓存工具列表。

缓存后可以减少：

  • 工具发现请求；
  • 工具Schema传输；
  • 网关压力；
  • 模型前置等待时间。

动态权限场景要谨慎。

某用户权限被撤销后，客户端可能仍缓存旧工具列表。服务端在 tools/call 时必须重新鉴权，不能把“工具列表缓存”当成授权结果。

七、初始化握手变化

新规范的无状态设计移除了协议层长期初始化会话。

这会影响依赖以下逻辑的实现：

  • 初始化时保存客户端能力；
  • 把Session ID绑定到实例内存；
  • 仅在初始化后开放工具；
  • 通过会话存储用户信息；
  • 长连接维持授权上下文。

迁移方向是：

每个请求携带足够身份与协议信息
＋服务端根据请求独立处理

用户身份应来自标准认证机制，而不是内存中的MCP会话。

八、SDK迁移不是统一升级一个版本号

官方已提供Python、TypeScript、Go和C#的Beta SDK支持。

Python

Python v2 Server可以从一个端点响应多个协议版本，便于兼容测试。

TypeScript

v2采用新的包结构，安装新包本身就是显式Opt-in。

Go

可以安装预发布版本，并在Streamable HTTP配置中显式启用Stateless。

C

预览版本的HTTP Transport对新模式有自己的默认行为，需要阅读对应发布说明。

结论是：

不能把一篇Python迁移教程直接套到所有语言。

九、旧客户端和新服务如何兼容

建议建立兼容矩阵：

Client Server 协议 结果
旧版 旧版 2025-11-25 基线
新版 旧版 回退 应测试
旧版 新版 兼容模式 应测试
新版 新版 2026-07-28 目标

测试不能只验证连接成功，还应验证：

  • 工具发现；
  • 工具调用；
  • 错误响应；
  • OAuth；
  • 长任务；
  • 超时；
  • 取消；
  • 多实例负载均衡。

十、企业迁移步骤

第一步：盘点状态依赖

检查是否使用：

  • Sticky Session；
  • Session Store；
  • 实例内用户上下文；
  • 初始化缓存；
  • 长连接状态；
  • 自定义Session ID。

第二步：升级测试环境SDK

不要直接升级生产。

第三步：增加协议版本日志

记录：

client_sdk
server_sdk
protocol_version
transport
mcp_method
trace_id

第四步：部署多实例测试

验证连续请求被分配到不同实例后仍能正常执行。

第五步：测试身份与权限

重点验证：

  • Token是否每次请求携带；
  • 用户身份是否正确传递；
  • 工具级权限；
  • 缓存工具列表后的权限变更；
  • 租户隔离。

第六步：灰度启用新协议

先对内部客户端或小比例流量开放。

十一、哪些项目不用立即迁移

以下项目可以继续观察：

  • 本地stdio MCP Server；
  • 单用户开发工具；
  • 不需要横向扩容；
  • 仍依赖稳定版SDK；
  • 没有生产流量；
  • 当前版本运行稳定。

官方明确说明，7月28日不是旧版强制停止日期。

因此，关键生产系统更应该：

先测试
→ 等稳定SDK
→ 再灰度

而不是为了追新直接切换Beta。

十二、这次变化对MCP意味着什么

无状态化让MCP进一步靠近标准企业基础设施：

普通HTTP负载均衡
标准OAuth/OIDC
网关路由
缓存
水平扩容
明确弃用策略
独立扩展

这会降低MCP Server进入云原生和企业平台的门槛。

总结

MCP 2026-07-28规范最核心的变化可以概括为：

把协议会话从基础传输层拿掉，让MCP Server像普通无状态HTTP服务一样扩容。

当前最正确的行动不是立即全量升级，而是：

  1. 盘点会话依赖；
  2. 选择对应SDK Beta；
  3. 建立协议兼容矩阵；
  4. 在多实例环境验证；
  5. 等稳定版后灰度迁移。