长勺智库长勺智库

MCP 新一代协议：无状态核心与 SDK 迁移

Cloudflare AI Bl14 天前

背景

过去一年半，Model Context Protocol（MCP）逐渐成为智能体与外部服务交互的通用协议之一。早期 MCP 的一个主要争议在于：客户端与服务器之间需要保持有状态连接。

这种设计源于 MCP 最初面向本地应用的 STDIO transport。当 MCP Server 走向远程部署后，原本适合本地环境的有状态连接被搬到 Web 基础设施上，开发者需要处理 sticky session、长时间打开的 stream、消息重放等问题，整体复杂度高于传统 Web 服务。

MCP 2026-07-28 规范改变了这一点：核心协议被重写为无状态模式，并同步更新了 TypeScript、Python、Go、C# SDK。

MCP 核心变为无状态

旧版 MCP transport 通常从 initialize 与 initialized 交换开始，用于建立 session。服务器可以分配 Mcp-Session-Id header，后续请求都需要找到与该 session 对应的状态。

在实际部署中，这意味着：

  • 自动扩缩容基础设施需要维持活跃 session；
  • 发布部署时需要 drain 或迁移 session；
  • 活跃实例丢失可能导致客户端重连或 session 中断；
  • Serverless 平台也需要额外协调协议 session。

新版协议移除了核心请求路径中的强制握手、Mcp-Session-Id header 以及协议 session。每个请求都携带所需的协议版本、客户端身份和客户端能力。

如果客户端希望在发起后续请求前检查服务器能力，可以调用 server/discover，但这不是必需流程。

这一变化使 MCP Server 可以像普通请求处理服务一样部署：请求到达服务器，调用 tool、prompt 或 resource，然后返回结果。协议层不再要求保存 session 状态。

对于 Cloudflare Workers 这类请求作用域基础设施而言，这意味着 MCP Server 不再必须依赖 Durable Objects 或类似有状态组件来“讲 MCP”。当应用自身确实需要状态时，Durable Objects 仍然适用，但 MCP 协议本身不再强制要求它。

Elicitation 不再依赖开放 stream

MCP Server 有时需要在完成请求前向用户或客户端获取更多信息。例如：

  • 部署工具需要用户批准后才能发布到生产环境；
  • 设计工具需要用户选择颜色；
  • 账单工具需要确认后才能退款。

MCP 将这类交互称为 elicitation。

旧版中，elicitation/create 等服务器发起请求依赖开放 stream。这会带来 stream 负载均衡、成本与请求超时等部署复杂度。

新版协议使用 Multi Round-Trip Requests（MRTR）重构该流程：

  1. 服务器返回 input_required 结果，说明还需要什么信息；
  2. 客户端收集答案；
  3. 客户端带着补充输入重试操作；
  4. 原操作继续完成。

整个过程不要求双方在多次请求之间保持 transport session。

这是对旧版 elicitation 的破坏性变更，但实现和运维上更简单，也更适合构建需要多轮用户参与的智能体应用。

HTTP 基础设施可以直接理解 MCP

MCP 请求本质上是通过 HTTP 发送的 JSON-RPC 消息。旧版中，请求方法等关键信息主要位于 JSON body 内，网关、限流器或 WAF 如果想判断请求是 tools/list、工具调用还是资源读取，就需要解析 body。

新版规范要求 Streamable HTTP 请求带上：

  • Mcp-Method
  • Mcp-Name

这样，网关、限流器、WAF 可以直接基于 header 决策，而不需要解析任意 JSON body。

运营侧可以基于这些 HTTP header 实现：

  • 不同 MCP method 的差异化规则；
  • 工具级别的指标采集；
  • 更接近传统 Web 服务的观测与控制方式。

新版规范还为以下结果增加了 ttlMs 与 cacheScope 提示：

  • tools/list
  • prompts/list
  • resources/list
  • resources/read

工具目录也要求确定性排序，使客户端可以复用目录结果，并在重连时保持上游 prompt cache 更稳定。

鉴权机制继续演进

MCP 2026-07-28 也收紧了授权模型。

当服务器与客户端已经存在关系时，新规范优先推荐预注册客户端。对于动态注册，规范引入 Client ID Metadata Documents（CIMD），并将 Dynamic Client Registration（DCR）作为 fallback。

DCR 已在本次发布中被标记为 deprecated，不建议新实现继续采用，并计划在 2027 年夏季之后移除。

新版还采用 RFC 9207 issuer identification：

  • 授权服务器声明 authorization_response_iss_parameter_supported: true；
  • 成功授权响应中包含 iss；
  • 客户端将其与授权流程开始前发现的 issuer 进行比对。

这样可以避免来自不同 issuer 的授权响应被混淆。

此外，还有一些面向生产部署的细节变化：

  • MCP 客户端在 authorization 和 token 请求中，会把规范化后的 server URI 作为 RFC 8707 resource；
  • token 必须面向该 audience 签发；
  • 服务器也只应接受面向该 audience 的 token。

新增正式功能生命周期

MCP 2026-07-28 不只包含协议层变化，也引入了正式的功能生命周期。

功能会被划分为：

  • Active
  • Deprecated
  • Removed

被标记为 deprecated 的功能，在移除前必须至少保留 12 个月。

本次发布中，以下能力被标记为 deprecated：

  • Roots
  • Sampling
  • Logging
  • Dynamic Client Registration
  • 旧版 HTTP+SSE transport

这给已有实现提供了明确迁移窗口，也让核心协议更容易稳定下来。

与此同时，新想法可以通过 extensions framework 更快迭代，而不必立即进入核心协议。MCP Apps、Enterprise-Managed Authorization 已作为 extension 存在；Tasks 也被迁移到 extension 路径，用于支持可靠的长时间运行任务。

SDK 与迁移方向

随着新规范发布，TypeScript、Python、Go、C# SDK 均已更新。

在 Cloudflare 生态中，原先用于构建远程 MCP Server 的 McpAgent 不再是协议层必需组件。新的迁移方向是使用 createMcpHandler，让 MCP Server 可以在无状态请求处理模型中运行。

这并不意味着所有应用都不再需要状态。如果业务本身需要持久化、事务存储或实时协调，仍然需要相应的有状态基础设施。但从协议角度看，MCP Server 不再必须为了维护 MCP session 而引入有状态运行时。

对开发者的意义

MCP 2026-07-28 的核心变化可以概括为：协议层从“保持连接与 session”转向“每个请求自包含”。

它带来的直接影响包括：

  • 部署更接近传统 HTTP 服务；
  • 更适合 Serverless 与请求级扩缩容平台；
  • elicitation 不再依赖长连接；
  • 网关、限流、WAF、指标采集更容易理解 MCP 请求；
  • 鉴权模型更明确；
  • 被废弃功能有至少 12 个月迁移期。

对于已经部署旧版 MCP Server 的团队，重点需要关注无状态协议、MRTR elicitation、HTTP header、授权调整以及 SDK v2 迁移路径。

评论

请登录后发表观点

暂无数据