MCP 2026-07-28规范进入最终发布窗口：无状态核心、缓存与路由升级全解析

文章摘要

MCP 2026-07-28规范在今天进入计划中的最终发布窗口。本轮修订是MCP推出以来规模最大的一次：协议核心转向无状态，Streamable HTTP请求新增Mcp-Method与Mcp-Name路由头，工具、资源和Prompt列表加入ttlMs与cacheScope缓存语义，长任务与服务端UI进入扩展体系，授权流程也更贴近OAuth和OIDC。需要注意的是，在官方GA公告和各语言稳定SDK全部落地前，生产团队仍应把它视为“最终发布窗口”，而不是假设所有生态组件已经同步完成升级。

一、今天应该如何理解“2026-07-28”

2026-07-28既是协议版本标识，也是官方此前公布的最终规范计划日期。

目前可以确认的是：

发布候选规范已经公开
Python、TypeScript、Go、C#测试版SDK已经提供
最终版本进入计划发布窗口
各语言稳定SDK仍需分别确认

协议发布和SDK采用不是同一件事。即使规范正式发布，Java、Python、TypeScript、Go等SDK也可能按不同节奏提供稳定版本。

生产文档更准确的表述应该是：

MCP 2026-07-28规范进入最终发布窗口，迁移前应确认官方GA公告、目标语言稳定SDK和客户端兼容矩阵。

二、最大的变化：协议核心走向无状态

旧版远程MCP服务常见链路：

客户端初始化
→ 服务端创建会话
→ 返回Mcp-Session-Id
→ 后续请求携带会话ID
→ 负载均衡必须找到原实例

部署层往往需要：

• Sticky Session；
• 共享会话存储；
• 会话过期清理；
• 网关识别MCP会话；
• 实例故障后的会话恢复。

新规范方向是移除协议层会话和Mcp-Session-Id，让核心请求更接近普通无状态HTTP：

任意请求
→ 任意可用实例
→ 独立处理
→ 返回结果

这不代表业务不再有状态，而是协议不再强迫所有MCP服务通过连接级会话维持状态。

业务状态应放在：

数据库
Redis
任务服务
工作流引擎
明确的业务对象

三、为什么无状态对企业部署重要

1. 普通负载均衡即可扩容

MCP Client
→ API Gateway
→ Round-Robin Load Balancer
→ MCP Server集群

不再要求所有请求回到原实例。

2. 实例故障影响更小

一个实例退出后，下一次请求可以进入其他实例。

3. 滚动升级更容易

服务实例可以逐步替换，不需要先迁移大量连接级会话。

4. Serverless更可行

无状态核心更适合容器弹性扩缩、Functions和多区域部署。

四、无状态不等于不保存业务状态

下列业务仍然需要状态：

• 审批流程；
• 长时间任务；
• 文件处理进度；
• 批量导入；
• 用户授权；
• 外部事务。

正确架构是：

无状态协议入口
＋外部持久化业务状态

例如：

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

任意MCP Server实例都可以根据taskId从共享存储恢复状态。

五、Mcp-Method解决网关看不懂JSON-RPC的问题

Streamable HTTP中的请求可能全部进入：

POST /mcp

普通网关只看到同一个URL，很难按实际方法做限流、路由和观测。

新规范要求标准请求头：

Mcp-Method: tools/call

或：

Mcp-Method: resources/read

网关可以据此：

按方法路由
按方法限流
按方法配置超时
按方法统计失败率
按方法应用安全策略

例如：

六、Mcp-Name支持更细粒度路由

请求还可以携带：

Mcp-Name: refund-order

它可以帮助网关识别具体工具、资源或任务名称。

应用场景：

• 高风险工具进入审批网关；
• 大文件工具使用更长超时；
• 特定工具进入专用计算集群；
• 按工具统计成本和失败率。

但必须注意：

请求头只是路由提示，不能替代服务端对JSON-RPC正文、身份和权限的完整校验。

七、工具和资源列表新增缓存语义

客户端过去可能频繁调用：

tools/list
resources/list
prompts/list

新规范通过CacheableResult加入：

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

ttlMs表示客户端可以在多长时间内把结果视为新鲜；cacheScope决定是否允许共享缓存。

多租户项目尤其要谨慎：

租户A工具列表
≠ 租户B工具列表

如果错误标记为public，共享缓存可能泄露工具存在性或权限结构。

缓存键至少应考虑：

server
protocol_version
authorization_subject
tenant
scope
locale

八、listChanged与TTL如何配合

推荐逻辑：

收到listChanged
→ 立即失效缓存

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

TTL不是权限撤销的即时保障。高风险工具权限变化时，服务端仍应在每次tools/call中重新鉴权。

九、Tasks扩展适合长任务

适合：

• 大型报告生成；
• 代码仓库扫描；
• 批量数据处理；
• 视频处理；
• 多轮审批。

典型状态：

working
input_required
completed
cancelled
failed

典型链路：

创建任务
→ 返回taskId
→ 轮询或接收通知
→ 补充输入
→ 完成或取消

Tasks属于扩展能力，并不意味着所有MCP实现必须支持。

十、MCP Apps带来服务端UI能力

MCP Apps允许服务端提供可交互UI，适合：

• 表单；
• 图表；
• 数据表；
• 审批面板；
• 文件预览。

同时会引入新的安全边界：

第三方UI脚本
嵌入式内容
跨域通信
身份传递
点击劫持
数据泄露

企业客户端应使用沙箱、CSP、来源校验、消息Schema校验和权限隔离。

十一、授权更贴近OAuth/OIDC

新体系强调：

• 最小权限；
• 增量Scope授权；
• 权限不足时Step-up；
• 企业托管授权。

例如：

当前只有read:orders
→ 调用refund-order
→ 返回insufficient_scope
→ 请求refund:orders
→ 用户或管理员批准
→ 重新调用

不要在首次授权时请求全部高权限Scope。

十二、现有MCP服务会立即失效吗

不会。

协议支持版本协商，旧客户端和旧服务端仍可继续运行。

推荐迁移节奏：

确认GA与稳定SDK
→ 建立兼容测试环境
→ 服务端双版本支持
→ 灰度客户端
→ 逐步下线旧版

十三、迁移前资产盘点

至少记录：

当前协议版本
SDK语言与版本
传输方式
是否依赖Mcp-Session-Id
状态存储位置
工具列表是否动态
是否需要长任务
OAuth模式
网关规则
客户端版本分布

重点识别：

• 隐式依赖会话ID；
• 进程内长任务；
• 网关会删除未知请求头；
• 工具列表按用户变化；
• 老客户端不识别新字段。

十四、推荐迁移步骤

1. 确认最终规范与稳定SDK
2. 服务端支持新旧版本协商
3. 将业务状态外置
4. 先观测Mcp-Method和Mcp-Name
5. 从短TTL开始测试列表缓存
6. 选择低风险长任务接入Tasks
7. 内部客户端先灰度
8. 再扩展到生产租户

十五、建议监控指标

mcp_protocol_version_count
mcp_method_request_count
tools_list_cache_hit_rate
tools_list_stale_error_count
unsupported_version_count
task_failed_count
oauth_step_up_count
legacy_session_request_count

总结

MCP 2026-07-28不是简单增加几个字段，而是把远程MCP进一步推向：

标准HTTP基础设施
＋可缓存发现
＋可路由请求
＋扩展式长任务
＋企业授权
＋可交互UI

今天最稳妥的行动不是立即全量升级，而是确认GA状态和稳定SDK，盘点会话依赖，把业务状态外置，并建立双版本灰度方案。

延伸阅读

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

https://www.zyentor.com/

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