MCP 2026-07-28 候选版发布：协议史上最大一次重构，AI Agent 基础设施迎来无状态时代

MCP 发布了一个重磅候选版——2026-07-28。这是 MCP 自问世以来最大的一次修订，也是其 2026 路线图的核心交付。如果你正在构建或运维 MCP 服务，这次变更值得逐行读完。

一句话总结

MCP 从「有状态、需要会话黏连」的协议，变成了一个纯无状态、可运行在普通 HTTP 基础设施上的协议。同时引入了独立的 Extensions 框架，让 MCP Apps 和 Tasks 可以按自己的节奏演进。

无状态：最大的架构变更

在 2025-11-25 版本中，调用一个 MCP 工具需要先建立会话：

POST /mcp HTTP/1.1
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"initialize",
 "params":{"protocolVersion":"2025-11-25","capabilities":{},
           "clientInfo":{"name":"my-app","version":"1.0"}}}

服务器返回 Mcp-Session-Id，后续所有请求都必须携带该 ID。这意味着：负载均衡器必须开启 sticky session，所有实例共享一个会话存储。

而在 2026-07-28 中，同一个调用变成了单次自包含请求：

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
           "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

任意实例都能处理，不再需要黏连路由和共享存储。

具体改了什么

六项 SEP（规范增强提案）共同实现了这一转变：

• 取消 initialize/initialized 握手（SEP-2575）。协议版本、客户端信息和能力声明现在通过 _meta 在每次请求中传递，新增 server/discover 方法供客户端按需获取服务端能力。
• 移除 Mcp-Session-Id 与会话层（SEP-2567）。请求可落到任意实例，水平扩展的门槛大幅降低。
• 显式句柄替代隐式会话。需要跨调用保持状态？服务端生成一个 basket_id 或 browser_id，让模型将其作为普通参数传递。这比隐藏在传输层元数据中的会话更强大——模型可以跨工具组合句柄、推理它们。
• 服务端到客户端请求重构（SEP-2260 & SEP-2322）。服务器只能在处理客户端请求期间发起反向请求；引入 InputRequiredResult + requestState 机制替代 SSE 长连接。
• 可路由、可缓存、可追踪（SEP-2243、SEP-2549、SEP-414）。新增强制 Mcp-Method 和 Mcp-Name 头，网关可直接按操作路由；tools/list 等结果支持 ttlMs 和 cacheScope；W3C Trace Context 传播正式纳入规范。

Extensions 成为一等公民

此前 Extensions 虽已存在但没有正式流程。SEP-2133 补上了：

• 通过反向 DNS 标识（如 io.modelcontextprotocol.apps）
• 在客户端和服务端能力声明的 extensions map 中协商
• 独立仓库（ext-*）、独立维护者、独立版本
• 标准的 SEP 流程，从实验到正式

本次发布包含两个正式扩展：

MCP Apps：服务端渲染 UI

服务端可以交付交互式 HTML 界面，客户端在沙盒 iframe 中渲染。工具预先声明 UI 模板，客户端可以预取、缓存和安全审查。UI 触发的一切操作都走和直接工具调用相同的审计和授权路径。

Tasks 扩展

Tasks 从实验性核心功能降级为独立扩展，基于无状态模型重新设计了生命周期：服务端通过 tasks/get、tasks/update、tasks/cancel 驱动长任务。之前基于 2025-11-25 实验 Tasks API 的实现需要迁移。

授权加固

六项 SEP 将授权规范向 OAuth 2.0 和 OpenID Connect 对齐：

• 客户端必须验证授权响应中的 iss 参数（RFC 9207），防范 mix-up 攻击
• 动态客户端注册时声明 application_type，避免桌面/CLI 客户端被误识别为 web 类型
• 凭据绑定到颁发授权服务器的 issuer
• 支持从 OpenID Connect 风格授权服务器请求 refresh token
• 澄清 scope 累积行为和 .well-known 发现后缀

正式弃用：Roots、Sampling、Logging

以下三项核心功能被标记为弃用：

功能	替代方案
Roots	工具参数、资源 URI 或服务端配置
Sampling	直接集成 LLM 提供商 API
Logging	stdio 传输用 stderr；结构化可观测性用 OpenTelemetry

需要强调的是，这只是注释级别的弃用，当前版本及未来一年内的规范版本中这些功能仍然可用。移除需要经过独立的 SEP 流程。

JSON Schema 2020-12

工具 inputSchema 和 outputSchema 升级为完整的 JSON Schema 2020-12（SEP-2106）。输入 schema 保持 type: "object" 根约束但支持 oneOf/anyOf/allOf、条件判断和引用。输出 schema 不再受限。

时间线

• 2026 年 5 月 21 日：候选版锁定
• 2026 年 7 月 28 日：正式规范发布

十周窗口期供 SDK 维护者和客户端实现者验证变更。Tier 1 SDK 预计在此窗口内完成适配。

这意味着什么

对于 MCP 的运维者和实现者来说，这次变更的核心信息是：

• 部署复杂度骤降：不再需要 sticky session、共享存储或深度包检测
• 扩展能力大幅增强：Extensions 框架让新能力可以独立交付，不绑死核心规范的发版节奏
• 可观测性开箱即用：W3C Trace Context 原生支持，分布式追踪从客户端贯穿到 MCP 服务端再到下游调用
• 向后兼容有保障：弃用策略规定至少 12 个月的窗口期，生态有足够时间迁移

对于 AI Agent 生态来说，这可能是 2026 年最重要的一项基础设施更新。MCP 已经从一个需要精心运维的「有状态协议」转变为一个可以部署在任何标准 HTTP 基础设施上的「无状态协议」——这为 Agent 的大规模生产化部署扫清了关键障碍。