MCP最重的一次“拆墙”终于从候选版变成正式标准。北京时间7月29日00:47，MCP 2026-07-28被标记为稳定版：协议级会话、初始化握手和会话ID被移除，每个请求开始自己携带版本与客户端能力。对开发者而言，这不是接口增量更新，而是把远程MCP服务器从需要粘性会话和共享状态的特殊服务，改造成更接近普通HTTP基础设施的可路由、可缓存请求。

三点看懂：无状态不是少存一份会话

从握手到单次请求，基础设施终于能看懂MCP

旧版MCP通常先由客户端发送initialize，再由服务器返回能力，随后依赖会话ID维持连接上下文。新版把这些信息下沉到每个请求的_meta中，并要求服务器实现server/discover。客户端可以先发现服务器支持的版本和能力，也可以把它当作兼容性探针；如果双方没有共同的新版本，再由SDK协商回旧流程。

HTTP层也更容易被网关理解。Mcp-Method、Mcp-Name等标准头把方法和名称从JSON-RPC正文映射到HTTP头，负载均衡器、策略网关和可观测系统不必深度解析消息体即可路由与审计。tools/list、resources/list等结果还必须给出ttlMs和cacheScope，客户端可在时效窗口内复用结果，减少重复轮询。

代价同样明确：新版取消SSE断流续传和消息重投，响应流一旦中断，正在执行的请求会丢失，客户端必须用新的请求ID重新发起。无状态简化了服务器横向扩展，却把幂等设计、重试边界和任务状态句柄的重要性推到了前台。

服务器不再主动调用客户端，复杂任务改为多轮往返

此前，服务器可在处理工具调用时反向发起采样、根目录查询或信息征询。2026-07-28用多轮往返请求取代这条路径：服务器返回resultType为input_required的中间结果，把所需信息放入inputRequests；客户端完成询问后，再携带inputResponses和原请求状态重试。所有普通结果也必须显式标记resultType为complete。

这一变化让请求生命周期更清晰，网络中间件也更容易追踪，但现有依赖服务器主动回调的工具必须改造。统一的subscriptions/listen则用一条长时间POST响应流承接工具、提示词和资源变化，替代旧版GET端点及分散的订阅方法。日志级别也改为按请求声明，避免一个客户端的设置影响其他调用。

规范同时将Roots、Sampling和Logging列为弃用功能，新实现不应继续依赖；官方生命周期规则给出至少12个月的弃用窗口，因此“弃用”并不等于今天立即失效。Tasks也从核心协议移到正式扩展，说明MCP正在用更小的核心与可选扩展控制未来兼容成本。

稳定SDK不等于零成本升级，先检查协商与缺口

Python SDK 2.0可在同一服务器上兼容2026版与更早协议，并自动协商版本；与此同时，1.x已进入维护模式，只继续接收关键错误与安全修复。Go SDK也保留旧协议兼容，但Streamable HTTP只有在显式启用Stateless时才接受新版请求。其预发布版本已被GitHub MCP Server用于超过50万用户，说明架构并非只停留在规范文档。

开发团队仍要留意实现差异。Python 2.0本轮没有包含Tasks扩展，客户端的DPoP证明绑定与部分工作负载身份授权也尚未实现；项目若直接解除版本上限，FastMCP命名、客户端调用方式、缓存设置和认证配置都可能触发迁移工作。更稳妥的顺序是先锁定依赖、开启双版本协商，再逐项验证断流重试、权限、缓存与长任务。

ATYUN编辑判断：MCP这次更新最重要的不是新增了多少方法，而是把协议从“围绕连接组织能力”改成“围绕请求组织能力”。这会降低大规模远程服务器的基础设施门槛，也让网关治理和可观测性更接近成熟Web服务。不过，状态没有消失，只是从隐式会话转移到显式句柄、任务系统和业务存储。真正决定迁移质量的，将是开发者能否把重试、幂等、版本协商与授权边界一起重新设计。