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和多区域部署。四、无状态不等于不保存业务状态下列业务仍然需要状态审批流程长时间任务文件处理进度批量导入用户授权外部事务。正确架构是无状态协议入口 外部持久化业务状态例如publicrecordTaskState(StringtaskId,StringtenantId,Stringstatus,intprogress,StringresultLocation){}任意MCP Server实例都可以根据taskId从共享存储恢复状态。五、Mcp-Method解决网关看不懂JSON-RPC的问题Streamable HTTP中的请求可能全部进入POST /mcp普通网关只看到同一个URL很难按实际方法做限流、路由和观测。新规范要求标准请求头Mcp-Method: tools/call或Mcp-Method: resources/read网关可以据此按方法路由 按方法限流 按方法配置超时 按方法统计失败率 按方法应用安全策略例如方法超时缓存风险tools/list5秒允许低tools/call60秒禁止按工具resources/read30秒按结果中prompts/list5秒允许低六、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盘点会话依赖把业务状态外置并建立双版本灰度方案。