前言¶

Model Context Protocol（MCP）是 Anthropic 发起、社区共同维护的开放协议，用来让 AI Agent 以统一方式连接外部工具、数据源与交互界面。自 2024 年底发布以来，MCP 迅速成为 Agent 工具链的事实标准——官方 Tier 1 SDK（TypeScript、Python 等）每月下载量已接近五亿次，TypeScript 与 Python SDK 累计下载均突破十亿。

2026 年 7 月 28 日，MCP 官方正式发布 2026-07-28 版规范。这是协议自诞生以来最大的一次修订：协议核心从「双向有状态」全面转向 request/response 无状态模型，移除了 initialize/initialized 握手与 Mcp-Session-Id 会话头，Remote MCP Server 终于可以像普通 HTTP 服务一样挂在负载均衡后面水平扩展。

本文基于 MCP 官方博客 与 Release Candidate 说明，梳理这次改动的核心机制、对部署架构的影响，以及开发者需要关注的迁移要点。

为什么需要无状态¶

在 2025-11-25 版规范中，通过 Streamable HTTP 调用 Remote MCP 工具，需要先建立会话。客户端发送 initialize，服务端返回 Mcp-Session-Id，后续每个请求都必须携带这个 ID，把客户端「钉」在签发会话的那台实例上。

对单机部署来说，这套流程没问题。但一旦把 MCP Server 放到负载均衡后面做水平扩展，麻烦就来了：

1. 必须配置 sticky session（会话亲和），否则后续请求可能落到没有会话状态的实例上；
2. 或者维护 共享 Session Store（Redis 等），增加运维复杂度；
3. 网关在路由、限流、鉴权时往往要 深度解析 JSON-RPC 请求体，性能与实现成本都不低。

这正是社区开发者反馈最多的痛点之一。2026-07-28 版规范用六个 SEP（Specification Enhancement Proposal）协同完成无状态改造，完成了 2025 年 12 月《The Future of MCP Transports》中提出的路线图。

核心变化：每个请求自描述¶

握手与会话头被移除¶

以下两项在 2026-07-28 版中正式退役（参见 SEP-2575、SEP-2567）：

• initialize / initialized 握手交换
• Mcp-Session-Id HTTP 头及协议层会话

协议版本、客户端身份、客户端能力等信息，改为随 每个请求 携带，放在 JSON-RPC 参数的 _meta 字段里。如果客户端想提前了解服务端能力，可以调用新增的 server/discover RPC——但这是可选的，不调用也能直接发起工具调用。

请求对比¶

2025-11-25：先握手，再带 Session ID 调工具

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: 1868a90c-3a3f-4f5b，后续请求必须带上：

POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json

{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"}}}

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"}}}}

关键差异一目了然：没有握手、没有 Session ID，任意请求可以落到负载均衡后面任意一台实例，不再需要 sticky routing 或共享存储。

协议无状态，应用仍可有状态¶

移除协议层会话，并不意味着你的 MCP Server 不能做有状态业务。官方推荐的做法与 HTTP API 一致：由工具显式 mint 一个 handle（如 basket_id、browser_id），让模型在后续调用中作为普通参数传回。

官方认为，这种「模型可见、可推理、可跨工具传递」的显式 handle，往往比藏在传输层 metadata 里的会话状态更灵活——模型可以把 handle 在不同工具步骤之间串联起来。

MRTR：无状态下的服务端交互¶

无状态协议面临一个经典问题：工具执行到一半，服务端需要向用户确认（elicitation）或请求采样（sampling），怎么办？旧版依赖保持打开的 SSE 双向流；新版引入 Multi Round-Trip Requests（MRTR，SEP-2322） 解决。

流程如下：

1. 客户端发起 tools/call；
2. 服务端返回 resultType: "input_required"，附带 inputRequests（需要用户回答的问题）和 requestState（服务端状态的编码）；
3. 客户端收集用户输入后，重新发起原始调用，在参数中附上 inputResponses 与 echo 回来的 requestState；
4. 任意服务端实例都能处理这次重试，因为所需上下文全在 payload 里。

示例响应：

{
  "resultType": "input_required",
  "inputRequests": {
    "confirm": {
      "type": "elicitation",
      "message": "Delete 3 files?",
      "schema": { "type": "boolean" }
    }
  },
  "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}

同时，SEP-2260 规定服务端只能在 正在处理客户端请求期间 发起 server-to-client 请求，用户不会被「无缘无故」弹窗打断——每一次交互都能追溯到用户或 Agent 主动发起的操作。

MRTR 替代了原先需要长连接的 elicitation/create、sampling/createMessage、roots/list 等 server-initiated 请求，使 elicitation 等交互能力在无状态 HTTP 上传输成为可能。Supabase 等已在生产环境运行的 stateless MCP Server 正是因此才能落地「删除数据前确认」这类场景。

基于 Header 的路由与可缓存列表¶

Mcp-Method 与 Mcp-Name¶

Streamable HTTP 传输现在 必须 携带 Mcp-Method 和 Mcp-Name 两个 HTTP 头（SEP-2243）。方法名（如 tools/call）和工具/资源名（如 search）同时出现在 Header 与 JSON body 中；若两者不一致，服务端应拒绝请求。

这意味着负载均衡器、API 网关、WAF、限流器可以直接基于 Header 做路由与策略，无需先解析 JSON-RPC body。例如：

• 对 Mcp-Name: expensive-query 路由到专用后端；
• 对特定工具做 per-tool 限流或鉴权；
• 在基础设施层统一计量 MCP 流量。

ttlMs 与 cacheScope¶

tools/list、prompts/list、resources/list、resources/read 的响应现在携带 ttlMs 和 cacheScope（SEP-2549），语义类似 HTTP 的 Cache-Control。客户端可以据此决定工具目录缓存多久、是否可跨用户共享，减少每次重连都重新拉取 catalog 的开销，同时保持上游 prompt cache 在 reconnect 之间的稳定性。

此外，W3C Trace Context（traceparent、tracestate、baggage）在 _meta 中的键名已在规范中固定（SEP-414），便于跨 SDK、网关与下游服务的分布式追踪关联。

同期重要变更一览¶

2026-07-28 版不止是无状态改造，还包含多项与生产落地密切相关的变更：

SDK 与生态¶

官方 Tier 1 SDK（TypeScript、Python、Go、C#）已同步支持 2026-07-28 版规范，Rust SDK 处于 beta。各 SDK 均提供 breaking changes 的迁移说明。

云厂商与工具链伙伴也在发布日即宣布支持，包括 AWS Bedrock AgentCore、Cloudflare Workers、Google Cloud、Microsoft Foundry、Netlify 等。FastMCP 4.0、Manufact 的 mcp-use 等社区框架也报告了因 client-server 拆分带来的包体积与性能收益。

对于依赖 Mcp-Session-Id 做路由或状态管理的现有实现，迁移成本确实存在，但官方在 SDK beta 阶段已根据早期测试反馈做了简化。

开发者迁移建议¶

如果你正在维护 Remote MCP Server 或集成 MCP Client，可按以下步骤评估迁移：

1. 检查 Session 依赖：搜索代码中对 initialize、Mcp-Session-Id 的引用；若仅用于协议握手，直接移除；若用于业务状态，改为显式 handle 模式。
2. 补充 HTTP Header：Streamable HTTP 请求加上 Mcp-Method、Mcp-Name，并确保与 body 一致。
3. 处理 MRTR 流程：若工具需要用户确认，实现 input_required → 收集输入 → 带 inputResponses 重试的客户端逻辑。
4. 利用缓存 hint：读取 tools/list 等响应中的 ttlMs，避免无谓的 catalog 刷新。
5. 关注弃用项：新实现不要再采用 Roots、Sampling、Logging 及 legacy HTTP+SSE 传输；OAuth 集成逐步从 DCR 转向 CIMD。
6. 阅读 SDK 迁移笔记：TypeScript / Python / Go / C# 各 SDK 仓库均有针对 2026-07-28 的 breaking change 说明。

规范全文与 changelog 可在 MCP 规范仓库 查阅；实现问题可通过 contributor Discord 的 Working Group 频道快速获得解答。

小结¶

MCP 2026-07-28 把 Remote MCP Server 从「需要特殊会话管理的协议」变成了「标准无状态 HTTP 工作负载」。负载均衡、Header 路由、响应缓存、分布式追踪——这些 Web 基础设施数十年来验证过的能力，现在可以直接服务于 Agent 工具链。

对 Agent 开发者而言，这意味着 MCP Server 的部署与运维复杂度显著下降；对平台与云厂商而言，MCP 正从实验性集成走向生产级基础设施。如果你已经在用 Remote MCP 连接 GitHub、Linear、Supabase 等官方托管端点，这次规范升级值得尽快跟进 SDK 版本，把架构从无状态改造中真正获益。