要评估影响优先看四件事有没有把应用状态放在协议会话里、有没有依赖长连接做 elicitation 或 sampling、有没有硬匹配 ​​-32002​​、有没有在用 ​​logging/setLevel​​。7 月 28 日MCP 官方发布了2026-07-28规范替代2025-11-25这是它自诞生以来改动最大的一次修订。initialize/initialized握手删了Mcp-Session-Id头也删了协议层不再有会话这个概念。Claude 给的官方数据是 MCP 近期月度 SDK 下载量突破 4 亿Anthropic 的 connectors 目录收录了 950 多个 MCP Server。势头依旧非常猛。背景2025-11-25及更早版本里一次 Streamable HTTP 交互要先握手客户端发initialize服务端回能力集客户端再发notifications/initialized。之后服务端下发一个Mcp-Session-Id每个请求都得带上POST /mcp HTTP/1.1 Mcp-Session-Id: 1868a90c-3a3f-4f5b {jsonrpc:2.0,id:2,method:tools/call, params:{name:search,arguments:{q:otters}}}这个 ID 只在签发它的那台机器上有效。想水平扩容要么在负载均衡上开 sticky session要么全集群共享一份会话存储很多团队是两样都做。代价还不止扩容。连接一断状态就没了客户端得重新握手。中间的网关、限流器想知道这个请求在干什么只能把 JSON-RPC body 解开看。无状态的协议内核SEP-2575 删掉握手SEP-2567 删掉协议级会话和Mcp-Session-Id。现在一次工具调用长这样POST /mcp HTTP/1.1 MCP-Protocol-Version: 2026-07-28 Mcp-Method: tools/call Mcp-Name: search {jsonrpc:2.0,id:1,method:tools/call, params:{name:search,arguments:{q:otters}, _meta:{io.modelcontextprotocol/clientInfo:{name:my-app,version:1.0}}}}协议版本、客户端身份和能力都放进了_meta键名是io.modelcontextprotocol/protocolVersion、/clientInfo、/clientCapabilities。版本对不上返回UnsupportedProtocolVersionError。一次工具调用现在是完全自包含的普通的轮询负载均衡就够用不需要共享存储也不需要会话亲和。有状态与无状态的请求路径对比图上看右边几条线的走向。上半只有一条能走通打到实例 B 就失败因为会话状态只在 A 上下半三条都通右下角灰掉的共享会话存储也就不需要了。另有一处容易漏SEP-2575 同时移除了 SSE 流的可恢复能力Last-Event-ID不再适用。响应流断了在途请求就丢了客户端要用新 ID 重发。server/discover客户端想提前知道服务端支持什么可以调新增的server/discover它返回协议版本、能力集和身份信息。服务端 MUST 实现客户端 MAY 调用跳过它直接发工具调用完全合法。显式的状态句柄协议不管状态了不等于应用不能有状态。官方的做法是由工具签发一个句柄让模型作为普通参数在工具之间传{jsonrpc:2.0,id:2,method:tools/call, params:{name:add_item, arguments:{basket_id:bsk_a1b2c3,sku:shoes}}}这里的basket_id由上一步建购物车的工具返回。官方的判断是这种写法比放在传输层里的会话状态更好用模型能看到这个句柄也就能自己决定后续哪些调用要带上它。多轮请求 MRTR工具执行到一半需要用户确认或者需要客户端的模型生成一段内容以前靠elicitation/create、sampling/createMessage、roots/list这类服务端反向请求解决实现上要求服务端一直保持一条 SSE 流不断开。无状态之后没有常驻连接这套做法不成立了。SEP-2322 的替代方案是 Multi Round-Trip Requests缩写 MRTR。服务端把要问的东西放在返回值里tools/call、prompts/get、resources/read都可以返回resultType为input_required的结果{ resultType: input_required, inputRequests: { confirm: { method: elicitation/create, params: {mode: form, message: Delete 3 files?, requestedSchema: {type: object, properties: {confirm: {type: boolean}}, required: [confirm]}} } }, requestState: eyJzdGVwIjoxLCJmaWxlcyI6WyJhIl19 }客户端收集完回答用同样的键放进inputResponses连同原样的requestState重发一次原始调用。旧的长连接方式与 MRTR 的时序对比左边那根粗竖线是关键整个过程服务端都得保持这条流断一次这次调用就废了。右边拆成两次普通请求中间状态全在报文里第二次由哪台机器处理都行。顺带说下resultType这是 RC 之后才补的字段现在每个 result 都必须带普通结果是complete老版本服务端不带这个字段时按complete处理。配套的 SEP-2260 规定服务端只能在处理某个客户端请求的过程中发起请求用户看到的每次弹窗都能追溯到主动动作。Supabase 就是靠 MRTR 才做上 elicitation 的删数据前可以先问一句。路由头 Mcp-Method 与 Mcp-NameSEP-2243 要求 Streamable HTTP 的 POST 请求必须带两个标准头Mcp-Method标明方法Mcp-Name标明具体的工具、资源或 prompt 名。网关拿到这两个头就能路由、限流、计量不用再解 body。头和 body 对不上直接拒HTTP 400-32020。同一个 SEP 还支持用x-mcp-header把工具参数映射成自定义 HTTP 头。列表结果的缓存tools/list、prompts/list、resources/list、resources/read、resources/templates/list的返回值多带两个字段SEP-2549ttlMs新鲜度提示单位毫秒cacheScopepublic或private决定共享的中间层能不能缓存语义照着 HTTPCache-Control抄的和原有的listChanged通知并存。会话没了以后列表端点不再随连接变化客户端避免每次调用都重拉工具目录靠的就是这两个字段。链路追踪SEP-414 把 W3C Trace Context 的traceparent、tracestate、baggage固定在了_meta里。之前几个 SDK 各写各的键名不统一就串不起来统一之后一条 trace 能从宿主应用一路连到下游服务。扩展框架SEP-2133 把扩展正式化了。每个扩展有一个反向 DNS 风格的 ID通过ClientCapabilities和ServerCapabilities里新增的extensions映射协商代码放在独立仓库按自己的节奏发版。新能力不用再写进核心规范也就不会因此触发一次带破坏性改动的版本升级。核心协议与扩展框架的分层关系图上看中间那条虚线也就是extensions的协商动作。上面一层动一下就是主版本变更下面三个扩展各有各的发版节奏。两端只有都声明了某个扩展它才生效没声明就当它不存在。Tasks 扩展Tasks 在2025-11-25里是核心协议的实验特性生产环境跑下来问题不少这次按 SEP-2663 移到了io.modelcontextprotocol/tasks扩展同时做了一轮重构阻塞式的tasks/result换成tasks/get轮询新增tasks/update客户端可以往运行中的任务里送输入删掉tasks/list服务端可以主动返回 task handle变更通知也从 HTTP GET 端点改到了统一的subscriptions/listen流。MCP Apps 扩展MCP Apps 走的是 SEP-1865今年 1 月就已经是 Final是第一个官方扩展。它让 Server 下发可交互的 HTML 界面宿主在沙箱 iframe 里渲染工具要提前声明 UI 模板宿主才能预取和做安全审查。界面上触发的动作走的是和直接调用工具相同的审计与授权路径。授权的收紧六个 SEP方向是向生产环境里的 OAuth 2.0 和 OIDC 部署形态对齐。其中几条值得单独说授权服务器 SHOULD 在响应里带iss客户端换 token 前 MUST 校验SEP-2468对应 RFC 9207防的是 authorization server mix-up 攻击注册时 MUST 指定application_typeSEP-837。桌面端和 CLI 客户端之前常报redirect_uri错误就是因为授权服务器默认按web类型拒掉了localhost回调客户端凭据绑定到签发它的 issuerSEP-2352持久化时要按 issuer 分开存Dynamic Client Registration 正式废弃方向是 Client ID Metadata Documents兼容期内继续可用错误码的变化以前基本什么都是 HTTP 200 加一个放在 body 里的错误。现在传输层失败返回真实的 HTTP 状态码应用层结果才留在 body 里情况2025-* 版本2026-07-28未知方法HTTP 200 body 内错误HTTP 404协议版本不支持不统一HTTP 400-32022头绑定字段缺失或不匹配不统一HTTP 400-32020缺少必需的客户端能力无-32021还有一处容易踩资源不存在的错误码从 MCP 自定义的-32002改成了 JSON-RPC 标准的-32602SEP-2164客户端里硬匹配过的要检查一遍。logging/setLevel不再可用改用每请求的io.modelcontextprotocol/logLevel字段。废弃的能力MCP 第一次有了正式的特性生命周期策略SEP-2596定义 Active、Deprecated、Removed 三种状态。核心保证是最短窗口从标记 Deprecated 的那个版本发布算起至少保留十二个月才有资格移除出安全事故可以加速但也要留够九十天。这次按这个策略废弃的是 Roots改用工具参数、资源 URI 或服务端配置、Sampling改为直接对接 LLM 提供方 API、Loggingstdio 用 stderr观测用 OpenTelemetry以及旧的 HTTPSSE 传输。四项都还能正常工作至少一年官方的态度是新实现别再依赖。SDK 支持与升级方式升级是 opt-in 的版本按请求选。像 Amazon Bedrock AgentCore Gateway 就支持一个网关同时声明2025-11-25和2026-07-28请求带哪个版本头就走哪套行为两边可以各自按节奏迁移。四个 Tier 1 SDK 在发布当天全部支持2026-07-28Rust SDK 是 betaPythonmcpv2FastMCP更名MCPServer升级后一个端点同时应答两个协议版本TypeScript v2 拆包成modelcontextprotocol/server和/clientESM only要求 Node.js 20C#2.0.0系列v1.x API 继续可用Go 从v1.7.0起支持模块路径不变Go 这边有个必须知道的开关Streamable HTTP transport 只有在Stateless打开时才接受2026-07-28的请求handler : mcp.NewStreamableHTTPHandler(func(r *http.Request) *mcp.Server { return server }, mcp.StreamableHTTPOptions{Stateless: true})不开这个开关客户端会协商降级到2025-11-25。TypeScript 也是类似的显式选择Python 和 C# 相反升级后默认就走新版本。总结这次改的是 MCP 的传输层和生命周期不是往上加特性。会话和握手去掉之后MCP Server 就是一个普通的 HTTPS 端点可以部署到 serverless 和边缘节点。要评估影响优先看四件事有没有把应用状态放在协议会话里、有没有依赖长连接做 elicitation 或 sampling、有没有硬匹配-32002、有没有在用logging/setLevel。7 月 28 日只是规范文本的发布日跑在2025-11-25上的实现不受影响废弃项还有至少十二个月节奏可以按自己的节奏来定。新写的 Server 直接按无状态来就好。