MCP RC版全面解读：无状态架构+Extensions框架+9项规范变更

Tue, 28 Jul 2026 10:00:00 +0800

MCP 的 7 月 RC，是协议诞生以来最大的一次重构。

一句话结论：MCP 从「能调用工具的协议」变成了「可大规模运行的基础设施」。 核心变化三个：无状态设计让协议具备水平扩展能力，Extensions 框架让新功能不再往核心协议里塞，三个历史包袱（Roots/Sampling/Logging）正式废弃。3000+ 现有 MCP Server（据 MCP.Directory 统计）都需要迁移。

无状态核心：握手和会话消失了

这是最根本的架构变化。SEP-2575 移除了 initialize/initialized 握手流程，SEP-2567 移除了 Mcp-Session-Id 头。两个 SEP 合在一起，把 MCP 从有状态协议变成了完全无状态的请求-响应模型。

旧方式需要两步才能开始通信：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 旧方式：先握手拿 Session-Id
POST /mcp
Content-Type: application/json

{"method": "initialize", "params": {"protocolVersion": "2026-03-26", "clientInfo": {"name": "my-client"}}}

# 响应拿到 Session-Id
{"sessionId": "abc-123", "serverInfo": {"name": "my-server"}}

# 后续每个请求必须携带
POST /mcp
Mcp-Session-Id: abc-123

{"method": "tools/list"}

新方式每个请求自包含，协议版本和客户端信息都在 _meta 中：

1
2
3
4
5
6
7


# 新方式：直接请求，无需握手
POST /mcp
Content-Type: application/json
Mcp-Method: tools
Mcp-Name: list

{"method": "tools/list", "_meta": {"protocolVersion": "2026-07-28", "clientInfo": {"name": "my-client"}}}

Session 消失了，那需要状态怎么办？答案是显式 handle。把状态管理从协议层移到应用层：

1
2
3
4
5
6
7


# 旧方式：依赖 Session-Id 存状态
session = sessions[request.headers["Mcp-Session-Id"]]
session["basket"].add_item(item)

# 新方式：通过参数显式传递 handle
basket_id = request.params["basket_id"] # 任何实例都能处理
baskets[basket_id].add_item(item)

这意味着什么？任何 MCP 请求可以落到任意 Server 实例，不再需要 sticky session。负载均衡、自动扩缩、多区域部署，全部成为可能。Uber 已经在生产环境通过 MCP Gateway 每周运行数万次 Agent 执行，验证了这条路线。

路由/缓存/追踪：三大运维优化

无状态是基础，但光有无状态还不够。三个新 SEP 解决了生产环境的实际问题。

路由头（SEP-2243）：每个请求必须携带 Mcp-Method 和 Mcp-Name 头。LB、网关、限流器无需解析 JSON body 即可路由。头和 body 不一致时服务端必须拒绝请求——这是个安全设计，防止 header spoofing。

1
2
3
4
5
6
7


# 网关直接从 header 路由，不碰 body
POST /mcp
Mcp-Method: tools
Mcp-Name: call
Content-Type: application/json

{"method": "tools/call", "params": {"name": "search", "arguments": {"query": "MCP"}}}

缓存元数据（SEP-2549）：tools/list 和 resource read 结果带 ttlMs + cacheScope，类似 HTTP 的 Cache-Control。不再需要长连接 SSE 来监听 tools/list_changed 通知，按 TTL 主动拉取即可。

1
2
3
4
5
6
7
8


# 响应带缓存元数据
{
 "tools": [...],
 "_meta": {
 "ttlMs": 300000,
 "cacheScope": "instance"
 }
}

分布式追踪（SEP-414）：_meta 中标准化 traceparent/tracestate/baggage 键名，与 W3C Trace Context 和 OpenTelemetry 兼容。跨 SDK、跨网关的端到端追踪成为标配。

三个 SEP 加在一起，MCP 的生产运维能力从「勉强能用」升级到了「大规模可运维」。再加上 SEP-2322 引入的多轮请求机制——用 InputRequiredResult 替代 SSE 流，客户端收集回答后带 inputResponses + requestState 重新发起请求，状态同样在 payload 中，任何实例都能处理——整个无状态架构的最后一块拼图补齐了。

Extensions 框架：MCP 从协议变成平台

SEP-2133 引入的 Extensions 框架是这次 RC 的另一个核心变化。之前所有新功能只能往核心协议里塞，协议越来越臃肿，版本迭代越来越慢。Extensions 把这个耦合拆开了。

设计很直接：核心协议只管通信，扩展能力按需加载。每个 Extension 用反向 DNS ID 标识（如 io.modelcontextprotocol/apps），独立版本、独立仓库（ext-* 系列），有委托维护者。新增 Extensions Track 在 SEP 流程中走规范审批。

能力协商发生在 initialize 阶段——Client 和 Server 通过 capabilities 字段声明各自支持的 extensions，取交集生效。认证模块可以独立发布 v2，不影响 Tasks 的版本节奏。

两个官方扩展：MCP Apps 和 Tasks

Extensions 框架定下来，立刻就有两个重量级扩展落地。它们代表了两个不同的扩展方向：一个扩展「表达能力」，一个扩展「时间维度」。

MCP Apps（SEP-1865）：让工具调用返回交互式 UI。Server 在 tools/list 中声明关联的 app 资源，工具调用后返回 app:// URI，Host 在沙箱 iframe 中渲染 Server 提供的 HTML，通过 postMessage 实现双向通信。Claude 和 ChatGPT 已原生支持。

举个实际场景：你有一个数据库查询工具，旧方式只能返回 JSON 文本，你需要自己解析、自己拼表格。有了 MCP Apps，同一个工具可以直接返回一个可排序、可筛选的交互式表格界面——你在对话窗口里直接操作，不用切到别的应用。Server 开发者只需按规范打包前端资源，Client 端负责渲染和沙箱隔离，安全边界很清晰。官方仓库在 github.com/modelcontextprotocol/ext-apps。

Tasks（SEP-2663）：从 2025 年 11 月的实验功能正式毕业为独立扩展。tools/call 不再同步阻塞等结果，而是返回异步 task handle。Client 通过 tasks/get 轮询状态，支持 tasks/update 推送进度、tasks/cancel 取消。注意：tasks/list 被移除了——在无会话设计下无法安全作用域。

创建模式是 server-directed：客户端声明支持 Tasks 扩展，服务端决定哪些调用作为 task 处理。这对长时间运行的操作（模型训练、大规模数据处理、编译任务）很有价值——Agent 可以同时发起多个长任务，轮流检查进度，而不是排队阻塞等待。从串行等待变成并行管理，用户体验完全不同。

两者共同指向一个方向：MCP 从只能传文本数据的管道，变成了能渲染 UI、能管理异步任务的平台。

授权加固：2 个 SEP 补齐安全短板

MCP 的授权一直被诟病「不够严谨」。这次 RC 用 2 个 SEP 补齐：

SEP	内容	解决什么问题
SEP-2468	iss 参数验证（RFC 9207）	防 mix-up 攻击
SEP-2207	OIDC refresh token 指南	明确 offline_access scope 下的 refresh token 行为

这两个 SEP 把 MCP 的安全模型从「能用」变成了「可审计」。

废弃清单：Roots、Sampling、Logging 正式退役

SEP-2577 定义了三个功能的废弃路线。注解级废弃（不是立即删除），12 个月移除窗口。

废弃功能	替代方案	理由
Roots	Tool 参数传路径、Resource URI、服务端配置	无状态架构下不需要客户端告知文件系统根目录
Sampling	直接集成 LLM provider API	Server 端直接调用模型 API 更高效、更可控
Logging	stderr（stdio 模式）/ OpenTelemetry（结构化日志）	行业标准方案，不需要协议层自建

如果你的 Server 还在用这三个功能，现在就该动手迁移了。12 个月听着长，但 Tier 1 SDK 需要在 10 周窗口内发布支持，生态倒逼的速度会比你想象得快。

迁移行动指南

阶段	时间	做什么
现在	7月	读 draft spec，审计 auth 代码，检查是否依赖 Roots/Sampling/Logging
6 周内	8月	用 RC SDK 重建 Server，验证路由头和缓存元数据
10 周内	9月	部署无状态变体，测试自动扩缩，声明新协议版本
12 个月后	2027年7月	废弃功能正式移除，确保迁移完成

最优先的改动：移除 initialize 握手和 Mcp-Session-Id 依赖，改用 _meta 传递协议信息。这是所有其他变更的前提。如果你的 Server 框架（如 FastMCP）还没有发布 RC 兼容版本，关注框架的更新动态，等框架适配后再动手会省很多力气。

其次是检查授权代码——2 个 SEP 涉及 OAuth/OIDC 流程的细节改动，如果授权实现不规范，安全审计这关过不去。

最后别忘了 JSON Schema 升级到 2020-12（SEP-2106），支持 oneOf/anyOf/allOf/$ref/$defs。错误码也有调整：-32002 改为 -32602（SEP-2164），和 JSON-RPC 规范对齐。

结语

这次 RC 的意义不只是「改了 9 个东西」。MCP 从一个原型友好的实验协议，转型为可大规模运行的基础设施。无状态核心让它能水平扩展，Extensions 框架让它能持续演进，授权加固让它能过安全审计。Apple Safari 技术预览版 247 已支持 MCP，Linux Foundation 已接手协议托管——这些信号说明 MCP 的生态位已经从「Anthropic 的项目」变成了「行业基础设施」。

对于正在使用或计划使用 MCP 的开发者，协议刚定型、生态还在早期，现在介入的门槛和成本都比较低。

作者：varkm

RC on Kalend's Blog