MCP 2.0 无状态化修订（2026-07-28 规范）

早期 MCP 沿用了「建立连接—握手协商—维持会话」的思路：客户端与服务器先交换 initialize 与 initialized 通知，协商出协议版本与能力，后续请求默认这段上下文仍然成立。这在单机 STDIO 场景里很自然，但一旦服务器要横向扩容、请求可能被负载均衡分发到不同实例，会话状态就成了必须额外同步的负担。

据 modelcontextprotocol.io 上 2026-07-28 版规范 Basic 页的原文，MCP 是无状态协议：处理请求所需的全部信息都包含在请求自身，服务器独立处理每个请求，不得从同一连接或流上的既往请求推断状态。该页进一步明确，服务器须准备好处理关联到多个任务、线程或对话的请求，不应要求客户端为相关操作复用同一连接或进程；客户端也不应把单个任务、线程或对话当作 STDIO 进程的生命周期边界。换句话说，开放连接不等于会话——客户端甚至可以在同一传输上交错互不相关的请求，服务器不得把连接或进程身份当作会话连续性的替身。

会话被拿掉之后，原本靠握手协商的信息必须随请求走。据同一官方规范页，客户端请求在 _meta 中带三类每请求协议字段：io.modelcontextprotocol/protocolVersion 为必填字符串，取值示例如 2026-07-28；io.modelcontextprotocol/clientCapabilities 为必填，声明本次请求相关的客户端能力；io.modelcontextprotocol/clientInfo 可选，给出客户端名称与版本。响应侧，服务器宜在结果的 _meta 中带 io.modelcontextprotocol/serverInfo 以标识自身。此外 _meta 还承载 progressToken、logLevel、subscriptionId，以及 traceparent、tracestate、baggage 等 OpenTelemetry 链路上下文传播键；官方扩展使用 io.modelcontextprotocol 前缀定义额外键，第三方扩展使用自己的厂商前缀。

错误契约也随之收紧。据该页，缺少任何必填字段的请求属畸形，服务器必须以 JSON-RPC 错误码 -32602（Invalid params）拒绝，HTTP 上返回 400 Bad Request；若处理请求需要客户端未声明的能力，服务器不得假定其存在，须返回 -32021 MissingRequiredClientCapabilityError，并在 data.requiredCapabilities 中列出缺失项，HTTP 上同样为 400。跨请求状态的处理方式也被明确规定：长任务、应用级句柄等需要跨越多次请求的状态，必须由客户端在每次请求中显式传入标识符来引用，而不是靠服务器记住上一次。订阅类长连接请求（如 subscriptions/listen）仍是请求/响应，只是响应是一条开放的通知流，其状态归属于该请求本身而非底层连接。

会话层移除后，原本由服务端反向发起的交互也要换形状。据 Ted Neward 的规范整理与 Agentic Commerce Atlas 的综述（第三方整理口径，编号与细节以各 SEP 原文为准），SEP-2322 引入多轮往返请求（MRTR）：服务器不再主动回调 sampling/createMessage、elicitation/create 或 roots/list，而是返回一个 resultType 为 input_required 的结果，其 inputRequests 字段说明还需哪些信息；客户端在重试原请求时带上 inputResponses 补齐。所有结果都带 resultType 字段，普通结果取 complete，多轮中间态取 input_required；对不含该字段的旧协议服务器，客户端须按 complete 处理以兼容。SEP-2575 则对应移除 initialize 握手、新增 server/discover 供客户端在正式请求前探测服务器支持的协议版本、能力与身份，并移除 ping、logging/setLevel 等接口；SEP-2567 用服务器签发的句柄作为跨调用状态载体。

另一条主线是把实验能力搬出核心。据上述综述，SEP-2663 把 Tasks 从核心协议移入名为 io.modelcontextprotocol/tasks 的官方扩展，改用 tasks/get 轮询与 tasks/update 承载客户端到服务端的输入，去掉阻塞式 tasks/result 与 tasks/list，并允许服务器在无需逐请求选择加入的情况下返回任务句柄。扩展身份以反向 DNS 命名、通过 capabilities 中的 extensions 映射协商、独立于核心规范发版。据 Agentic Commerce Atlas 记述，2026-10-29 起 SEP-3392 扩展生命周期（状态 Final）为每项扩展标注 Experimental、Beta、Stable 或并入核心；官方扩展索引列有 MCP Apps、Tasks、Enterprise Managed Authorization、Skills over MCP、OAuth Client Credentials、Server Cards 六项，其中 MCP Apps 允许服务器交付在沙箱 iframe 中渲染的交互式 HTML 界面，让表单、仪表盘一类真实界面取代纯文本返回，但整理文章同时提示，界面来自服务器也意味着仿冒审批按钮、仿冒登录界面成为新的钓鱼面。该综述强调，判断稳定性应看扩展阶段而不是「官方」二字——Stable 扩展只随核心规范修订变化，Experimental 与 Beta 仍可能发生破坏性变更。

据 deniz.in 与 Agentic Commerce Atlas 的综述，1.x 分支此后仅接收安全修复，被弃用特性不得晚于 2027 年 7 月移除，弃用策略给出 Active、Deprecated、Removed 三态并原则上保留至少十二个月迁移窗口（加急移除例外保留至少九十天）；Roots、Sampling、Logging 与旧 HTTP+SSE 传输进入弃用路径但暂时仍可用。授权侧也同步收紧，更贴近 OAuth 2.0 与 OpenID Connect 的实际部署，包含 RFC 9207 签发者校验，动态客户端注册被正式弃用并让位于 Client ID Metadata Documents。整理文章还提到，2026 年 10 月的一项统计发现服务器与客户端仍在同时讲五个不同的规范修订，因此生态碎片化本身就是迁移的现实动因。以上均为第三方整理口径，具体条款以官方规范、弃用政策与各 SEP 原文为准。

对工程团队，最实质的变化有两点。其一，无状态服务器可以直接放在普通负载均衡后面按请求分发，扩容模型简化了；其二，鉴权与授权被推到每一次请求，原本依赖「握手时已认证」的网关、审计与限流逻辑都要重做，沙箱化 UI 扩展还引入了界面层的仿冒风险。这与本站既有条目形成分工：MCP 词条介绍协议基础与工具/资源/提示三类能力，Streamable HTTP 词条讲传输层，MCP Events 词条讲事件订阅规范，MCP 安全机制词条讲授权与工具安全；本词条只聚焦 2026-07-28 修订带来的无状态化、扩展机制与迁移时钟这一版本事件。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。

无状态核心把 MCP 从「一个连接上的对话协议」推向「可水平扩展的普通 Web 协议」，这会降低自建服务器与网关的运维门槛，也让每请求鉴权、链路追踪、缓存（列表结果带 ttlMs 与 cacheScope 一类新鲜度提示）成为标准件。可以预期的另一条线是扩展生态的分层：Stable 扩展沉淀为事实标准，Beta 扩展继续快速迭代，Tasks 一类能力若并入核心将改变长任务编排的写法。风险同样明确——五个修订并存的碎片化不会一夜消失，界面层钓鱼与每请求授权的工程复杂度会成为迁移期的主要摩擦点。本站将持续跟踪官方规范修订与 SEP 演进。