MCP 2026-07-28 最终规范精读 — 无状态核心如何重写会话语义

日期: 2026-07-28 阶段: Phase 2 - AI-native 参考架构 标签: #mcp #stateless #protocol-spec

核心问题

今天正好是 MCP 2026-07-28 最终规范发布日（RC 已于 2026-05-21 锁定，blog.modelcontextprotocol.io，2026）。这是「自 2024-11 发布以来最大的一次修订」（官方原话），口语圈称「MCP 2.0」。本项目 P2 规划要自建一个 MCP server（把 AML 工具——typology 检索、SAR 草稿、规则检查——暴露给外部 agent host），所以必须搞清楚：从 2025-11-25 版到 2026-07-28 版，到底改了什么，会不会让我刚要动手写的 server 接口直接作废？

今天精读三件事：(A) 四大变更——stateless core / Tasks extension / Extensions 框架 / MCP Apps——每个「为什么这么改」；(B) 与 2025-11-25 版的逐项 diff（哪些是 breaking）；(C) 对自建 MCP server 的具体接口影响，以及一个反直觉的代价——无状态让 server 能横向扩展，但它改变了「会话」这个概念本身。

关键内容

A. 四大变更：stateless core 是地基，其余三个是地基上的房子

① Stateless Core（无状态核心）——最大变更。2025-11-25 版调一次工具要先走 initialize/initialized 握手，服务器回一个 Mcp-Session-Id header，之后每个请求都带它。新版彻底删掉握手和这个 session header（MCP blog，2026-07-28）。取而代之：

• 每个请求自带元数据：MCP-Protocol-Version: 2026-07-28 + Mcp-Method（如 tools/call）两个必需 header。
• 客户端信息搬进请求体的 _meta："_meta":{"io.modelcontextprotocol/clientInfo":{"name":"...","version":"..."}}。
• 新增 server/discover 方法，客户端想提前知道能力可主动查（UI hydration 场景）。
• tools/list 响应带 ttlMs 和 cacheScope（仿 HTTP Cache-Control）——客户端能缓存工具列表多久、能不能跨用户共享，都写明了。

为什么这么改：握手 + session header 意味着远程 server 必须有粘性会话（sticky session）+ 共享 session 存储 + 网关深包检测才能水平扩展。无状态后，server 能跑在普通轮询负载均衡器后面，网关只看 Mcp-Method header 就能路由/限流，不用拆包体（MCP blog，2026）。这是把 MCP 从「有状态长连接协议」拉回「普通 HTTP 请求-响应」的世界。

② Tasks Extension（任务扩展）——从核心降级为扩展。2025-11-25 版 Tasks 是实验性核心特性；生产用下来发现要重设计，于是新版把它移出规范、做成扩展（MCP blog，2026）。新模型：tools/call 可以不立即返结果，而是回一个 task handle，客户端用 tasks/get / tasks/update / tasks/cancel 驱动。

关键细节：tasks/list 被删了——「没有会话就无法安全地圈定 task 列表的范围」（MCP blog，2026）。这是 stateless 的直接连锁后果：无会话 = 无「本会话的任务」概念 = 无法安全列举。任务创建是 server-directed：客户端声明支持扩展，由 server 决定某次调用是否当 task 跑。

③ Extensions 框架。用反向 DNS ID 标识（如 io.modelcontextprotocol/...），通过客户端/服务器能力里的 extensions map 协商，独立于规范版本演进，住在 ext-* 仓库里。意义：把「实验性能力」从主规范剥离，主规范保持精简稳定，能力快速迭代。

④ MCP Apps。server 可以发交互式 HTML 界面，host 在沙箱 iframe 里渲染（MCP blog，2026）。工具提前声明 UI 模板，host 可预取/缓存/安全审查；渲染后的 UI 通过同一套 JSON-RPC 与 host 通信——每个 UI 发起的动作都走和直接工具调用一样的审计/同意路径。这条对合规至关重要：UI 按钮点出来的操作不能绕过 consent。

B. 与 2025-11-25 版逐项 diff（标 breaking 的要重写）

来源：MCP blog 2026-07-28 RC 原文 + TokenMix「9 spec changes」迁移图（2026）。

反直觉洞察①（stateless 让 server 可横向扩展，代价是「会话」语义被抽空）：直觉以为「去掉 session header 只是少了个 header」，实际上它删掉了「会话」这个抽象本身。连锁后果一串：tasks/list 没了（无会话无法圈范围）、多轮交互要靠 requestState 在请求间显式回传状态（任意 server 实例都能接力重试）、「本会话上下文」这种隐式状态在协议层不复存在。任何依赖「server 记得我上一句」的设计都要改成「状态显式编码进每个请求」。 这和 HTTP 从有状态 CGI 走向无状态 REST 是同一个故事——可扩展性的代价永远是把隐式状态外置。

反直觉洞察②（Sampling 被弃用，意味着「让 host 帮 server 调 LLM」这条路废了）：2025-11-25 版的 Sampling 允许 MCP server 反过来请 host 帮它调一次 LLM。新版把它 deprecated，官方指引是「server 自己直连 LLM provider API」（MCP blog，2026）。如果自建 server 里写了「让 host 采样」的逻辑，得改成 server 端自带 LLM 客户端——这反过来意味着 server 也要自己管 API key 和成本，正好落到 Day 43 的 gateway 上。

C. 对自建 MCP server 的接口影响：握手状态机的消失

设想本项目要暴露的 AML MCP server（工具：aml.search_typology / aml.draft_sar / aml.check_rules）。两版的握手状态机对比：

=== 2025-11-25（有状态）===
client                          server
  │── initialize ──────────────►│  建会话、分配 Mcp-Session-Id
  │◄── capabilities + SessionId ─│  存进共享 session store
  │── initialized ─────────────►│
  │── tools/call (Mcp-Session-Id)►  必须粘到同一实例（sticky）
  │◄── result ──────────────────│
        ▲ 扩容难：要 sticky LB + 共享 store

=== 2026-07-28（无状态）===
client                          server(任意实例)
  │── server/discover ─────────►│  (可选)主动查能力
  │◄── caps + tools(ttlMs) ─────│  client 按 ttlMs 缓存
  │── tools/call ──────────────►│  header: MCP-Protocol-Version
  │   (_meta.clientInfo)         │          + Mcp-Method: tools/call
  │◄── result | task handle ────│  无 session，任意实例可处理
        ▲ 扩容易：普通轮询 LB，网关只读 header 路由

自建 server 的接口清单影响（计划）：

设计要点/决策表

对本项目的落地

• 新建 src/mcp/amlServer.ts（规划）：直接按 2026-07-28 无状态模型实现，不写 initialize/initialized 握手。三个工具 aml.search_typology（接 src/aml/typology.ts）、aml.draft_sar（接 src/aml/sarDraft.ts）、aml.check_rules（接 src/aml/evalChecks.ts）以无状态 handler 暴露，每个请求自带 _meta.clientInfo。
• tools/list 加缓存元数据：AML 工具签名稳定，设 ttlMs: 3600000（1h）、cacheScope 允许跨用户共享——这是无状态新增能力，能显著减少 host 重复拉工具列表。
• draft_sar 走 Tasks 扩展：SAR 草稿生成涉及多步检索+起草，耗时；声明 Tasks 扩展，长任务回 task handle，host 用 tasks/get 轮询，避免长连接。注意 tasks/list 已删，server 不要假设能列举任务。
• 鉴权与 Day 43 gateway 协同：server 自带 LLM 客户端（因 Sampling 弃用）时，把 LLM 调用指向 Day 43 的 LiteLLM gateway，复用其 budget/fallback；对外 OIDC 鉴权按 RFC 9207 校验 iss。
• 诚实标注：MCP server 为 P2 规划，尚未实现；落地当周须按顶层时效硬规则确认 2026-07-28 是否已正式发布、Tier 1 SDK（TS/Py）是否已支持无状态模型（官方称 10 周窗口），以及 Mcp-Method/_meta 字段名是否随最终版微调。

参考资料

1. Model Context Protocol Blog — The 2026-07-28 MCP Specification Release Candidate（一手原文）：删 initialize/Mcp-Session-Id；新增 MCP-Protocol-Version+Mcp-Method header、_meta.clientInfo、server/discover、tools/list 的 ttlMs/cacheScope；Tasks 降为扩展、tasks/list 删除、tasks/get|update|cancel；MCP Apps 沙箱 iframe+JSON-RPC consent；OAuth/OIDC（RFC 9207 iss、SEP-2468）；弃用政策 12 个月；Roots/Sampling/Logging 弃用；错误码 -32002→-32602；RC 锁定 2026-05-21、终版 2026-07-28、Tier1 SDK 10 周 (2026-07-28)
2. TokenMix Blog — MCP Protocol Updates 2026: 9 Spec Changes, RC Migration Map：逐项变更与迁移图 (2026)
3. mcp.directory / byteiota — MCP 2026-07-28 Stateless RC Explained：stateless 横向扩展动机、普通 LB 后运行、网关 header 路由 (2026)
4. Model Context Protocol Blog — One Year of MCP: November 2025 Spec Release + 2026 MCP Roadmap：2025-11-25 基线、Tasks 当时为实验性核心 (2025-11 / 2026)
5. 本仓库 src/aml/typology.ts、src/aml/sarDraft.ts、src/aml/evalChecks.ts、src/agent/config/providers.ts（自建 server 工具源 + gateway 对接点）(2026-06)

SOTA 检查 (2026-06-11)

• 2026-07-28 是 MCP 当前的「下一个稳定版」：RC 已于 2026-05-21 锁定，终版定档 2026-07-28（笔记日期即发布日）。2025-11-25 仍是当下生产稳定版，新版处于发布前夜——这是本笔记须用计划语气、落地前重新核验的根本原因。
• stateless core 是不可逆的方向：官方 2025-12 transport future 与 2026 roadmap 一以贯之，无状态是为了让 MCP 跑在普通云原生基础设施上；不存在「回退到有状态」的迹象。自建 server 直接对新版是正确押注。
• 过时认知警示：「MCP server 必须握手建会话」「Tasks 是核心特性」「用 Sampling 让 host 代调 LLM」三条均在 2026-07-28 过时——分别被 stateless、Tasks 扩展、Sampling 弃用取代。任何照 2025-11-25 教程写的 server 都需迁移。
• A2A 平行参照：A2A（agent 间协议，归 Linux Foundation，v1.0→v1.2，2026-04 满一年 150+ 组织生产使用）与 MCP 互补——MCP 管 agent↔工具/数据，A2A 管 agent↔agent；本项目 MCP server 暴露工具，若未来要让外部 agent 协作再引 A2A，留待后续 day。
• 待跟踪：终版发布后核对 Mcp-Method/_meta/ttlMs 字段名是否与 RC 一致、TS/Py Tier1 SDK 无状态支持落地时间、Tasks 扩展的 ext-* 仓库稳定版本。