MCP 2026-07-28规范正式发布：无状态核心、扩展框架与生产迁移全解析

文章摘要

MCP官方已于2026年7月28日正式发布新一版规范，并同步推出可用于构建客户端和服务端的SDK。这是MCP自发布以来规模最大的一次协议修订：协议核心移除会话状态和初始化握手，更适合普通HTTP负载均衡；Mcp-Method与Mcp-Name让网关可以直接路由和限流；列表与资源读取增加明确缓存语义；MCP Apps和Tasks进入正式扩展体系；Roots、Sampling和Logging被标记为弃用。本文梳理正式版与旧版的关键差异、破坏性变化，以及企业生产环境的分阶段迁移方案。

一、这次已经不是发布候选版

此前公开的是：

MCP 2026-07-28 Release Candidate

现在官方已经明确宣布：

MCP 2026-07-28 Specification

正式发布，并提供配套SDK供开发者开始构建客户端和服务端。

这意味着团队可以从“关注规范变化”进入：

确认目标SDK
→ 建立兼容测试
→ 改造服务端
→ 灰度迁移客户端

但正式发布并不等于所有现有项目都应在同一天强制升级。新规范包含破坏性变化，旧客户端和旧服务端仍需要通过版本协商继续运行。

二、最大的变化：MCP核心真正无状态化

旧版远程MCP典型流程：

客户端发送initialize
→ 服务端建立协议会话
→ 返回Mcp-Session-Id
→ 后续请求携带会话ID
→ 负载均衡必须找到正确实例

这会让部署层承担：

  • Sticky Session；
  • 共享会话存储；
  • 会话过期；
  • 实例故障恢复；
  • 滚动升级时的会话迁移；
  • 网关对MCP会话头的特殊处理。

新规范移除协议级会话以及Mcp-Session-Id，同时取消以往的初始化握手依赖，使核心请求可以由任意服务实例处理：

MCP Client
→ API Gateway
→ 普通Round-Robin负载均衡
→ 任意健康MCP Server

其核心价值不是“少传一个请求头”，而是：

MCP服务终于可以更自然地使用普通HTTP基础设施进行水平扩展。

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

协议无状态只意味着：

协议层不再替业务维护连接级会话

以下能力仍需要业务状态：

  • 审批流程；
  • 长时间任务；
  • 文件生成；
  • 数据导入；
  • 分页；
  • 外部事务；
  • 用户授权；
  • 人机协作；
  • Agent执行进度。

错误做法：

private final Map tasks =
        new ConcurrentHashMap();

在多实例环境中，请求进入另一台服务器后就无法读取状态。

推荐：

无状态MCP入口
＋Redis、数据库或工作流引擎
＋显式taskId或业务对象ID

例如：

public record TaskState(
        String taskId,
        String tenantId,
        String userId,
        String status,
        int progress,
        String resultLocation,
        Instant updatedAt
) {
}

四、Mcp-Method与Mcp-Name让流量可路由

Streamable HTTP通常统一使用：

POST /mcp

网关只看URL时，无法知道请求实际是：

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

新规范要求在HTTP请求中提供：

Mcp-Method: tools/call

对需要具体对象名称的请求，还可以提供：

Mcp-Name: create-order

这样网关无需解析JSON-RPC正文，就能进行：

  • 路由；
  • 限流；
  • 超时控制；
  • 权限策略；
  • 成本统计；
  • 日志聚合；
  • 熔断；
  • 风险分级。

示例网关策略

MCP方法 建议超时 是否缓存 风险
tools/list 5秒 可以 低
resources/list 5秒 可以 低
resources/read 20秒 条件允许 中
tools/call 60秒 不允许 取决于工具
tasks/get 10秒 短缓存 低
tasks/cancel 15秒 不允许 高

服务端还必须验证：

请求头
与
JSON-RPC正文

是否一致，不能把请求头当成可信事实。

五、列表和资源读取拥有明确缓存语义

新规范为列表与资源读取结果增加：

{
  "ttlMs": 300000,
  "cacheScope": "private"
}

ttlMs

表示结果可被认为新鲜的时间。

300000毫秒
= 5分钟

cacheScope

用于说明缓存是否可以跨用户共享。

public
private

企业服务通常需要谨慎使用public。

如果不同租户拥有不同工具集合，应该返回：

private

否则共享缓存可能让租户A看到租户B才有的工具名称、资源或Prompt。

六、缓存键必须包含哪些维度

推荐缓存键：

server_id
protocol_version
authorization_subject
tenant_id
user_id
scope
locale
request_method

不要只使用：

tools/list

作为全局缓存键。

工具列表发生变化时：

收到listChanged
→ 立即失效

未收到通知
→ ttlMs到期后重新获取

TTL与变更通知应该组合使用。

七、MCP Apps成为正式扩展

MCP Apps允许服务端提供交互式HTML界面，由Host在沙箱iframe中渲染。

适合：

  • 仪表盘；
  • 表格；
  • 图表；
  • 审批面板；
  • 配置表单；
  • 文件预览；
  • 多步骤任务界面。

它让MCP从：

模型调用工具

扩展为：

模型、用户和服务端UI共同完成工作流

企业客户端必须补齐：

  • iframe沙箱；
  • Content Security Policy；
  • 来源校验；
  • 消息Schema校验；
  • 权限隔离；
  • 用户确认；
  • UI动作审计；
  • 敏感数据最小化。

服务端UI发起的动作，也应经过与普通工具调用一致的授权和审计流程。

八、Tasks从实验核心能力迁移为扩展

旧版实验Tasks API需要迁移到新的扩展生命周期。

新模式允许工具调用返回任务句柄：

tools/call
→ 返回task handle
→ tasks/get查询
→ tasks/update补充输入
→ tasks/cancel取消

适合：

  • 大型报告生成；
  • 批量文件处理；
  • 代码仓库扫描；
  • 视频处理；
  • 长时间分析；
  • 人工审批；
  • 外部系统异步任务。

重要变化：

tasks/list被移除

因为无会话环境下难以安全定义“列出哪些任务”。

业务系统应建立自己的任务查询权限，不能依赖一个全局任务列表。

九、授权机制进一步贴近OAuth与OIDC

正式版强化：

  • 授权响应中的iss校验；
  • OpenID Connect应用类型；
  • 发行方绑定；
  • 资源迁移后的重新注册；
  • Refresh Token获取；
  • Step-up授权；
  • Scope累积；
  • .well-known发现规则。

高风险工具推荐采用：

基础登录
→ 低权限Scope
→ 模型提出高风险动作
→ 服务端返回权限不足
→ 用户进行Step-up授权
→ 明确确认
→ 执行

不要在首次登录时请求全部敏感权限。

十、Roots、Sampling和Logging进入弃用状态

新规范将以下核心能力标记为Deprecated：

功能 建议替代方案
Roots 工具参数、资源URI或服务端配置
Sampling 直接集成模型Provider API
Logging stdio使用stderr，结构化观测使用OpenTelemetry

“弃用”不等于本版本立即删除。

新生命周期规则要求：

Deprecated
→ 至少12个月
→ 才可能Removed

现有实现仍然可以继续运行，但新项目不应再围绕这些能力设计长期架构。

十一、JSON Schema能力升级

工具输入和输出Schema升级到JSON Schema 2020-12。

输入Schema可以使用：

  • oneOf；
  • anyOf；
  • allOf；
  • 条件Schema；
  • $ref；
  • $defs。

输出Schema不再强制必须是对象，structuredContent也可以是任意JSON值。

但实现端必须防止：

  • 外部$ref自动下载；
  • Schema深度攻击；
  • 验证时间过长；
  • 递归Schema消耗大量资源；
  • 超大错误信息进入模型上下文。

建议设置：

max_schema_depth
max_schema_size
validation_timeout
max_validation_errors

十二、一个容易漏掉的破坏性变化

缺失资源的错误码从MCP自定义：

-32002

改为JSON-RPC标准：

-32602 Invalid Params

如果客户端存在：

if (error.code() == -32002) {
    handleMissingResource();
}

升级后逻辑会失效。

应改成：

按协议版本解析
＋按错误语义处理

而不是永久绑定某一个数字。

十三、生产迁移前需要盘点什么

当前协议版本
客户端SDK与版本
服务端SDK与版本
是否依赖initialize
是否依赖Mcp-Session-Id
是否使用Sticky Session
业务状态是否存进程内
是否使用实验Tasks API
是否使用Roots、Sampling、Logging
工具列表是否按租户变化
网关是否保留Mcp-Method与Mcp-Name
客户端是否缓存tools/list
OAuth实现是否校验iss
错误码是否写死

十四、推荐迁移顺序

第一阶段：双版本兼容

服务端同时支持：

2025-11-25
2026-07-28

第二阶段：状态外置

把会话内业务状态迁移到：

  • Redis；
  • PostgreSQL；
  • 工作流引擎；
  • 任务服务。

第三阶段：网关观测

先记录：

Mcp-Method
Mcp-Name
protocol_version

确认数据正确后再用于路由和限流。

第四阶段：缓存

从：

tools/list
prompts/list
resources/list

等低风险接口开始，并严格区分缓存Scope。

第五阶段：任务迁移

将旧实验Tasks迁移到正式扩展。

第六阶段：客户端灰度

内部客户端
→ 测试租户
→ 低风险工具
→ 生产核心工具

十五、建议新增的监控指标

mcp_protocol_version_count
mcp_method_request_count
mcp_name_request_count
mcp_header_body_mismatch_count
tools_list_cache_hit_rate
tools_list_stale_count
unsupported_protocol_count
legacy_session_header_count
task_created_count
task_failed_count
oauth_step_up_count
deprecated_feature_call_count

十六、今天最重要的判断

MCP 2026-07-28正式版把协议从“带会话的工具连接”推向：

无状态HTTP核心
＋可缓存发现
＋网关可路由
＋正式扩展体系
＋企业OAuth
＋长期兼容治理

它降低了大规模服务端部署难度，但不会自动解决：

  • 业务状态；
  • 工具权限；
  • 高风险审批；
  • 多租户隔离；
  • UI安全；
  • 任务审计。

总结

生产团队今天最适合做的事情是：

确认SDK版本
→ 建立兼容矩阵
→ 盘点协议会话依赖
→ 外置业务状态
→ 增加路由头与缓存测试
→ 迁移Tasks
→ 灰度升级

正式规范已经发布，但生产升级仍应以双版本、可回滚和真实兼容测试为前提。

延伸阅读

想持续跟踪大模型、Spring AI、RAG、Agent、MCP 与开发者生态的最新变化，欢迎访问 智元界：

https://www.zyentor.com/

智元界将持续分享 AI 热点解读、技术实战、工具推荐与企业落地案例。