MCP 无状态协议改造后哪些上下文要留下：会话移除与可缓存路由的边界

如果 MCP 远程服务从旧版 Streamable HTTP 迁到 2026-07-28 规范，最容易误判的一点是：协议层不再维护会话，并不代表业务层可以丢掉状态。真正要迁移的是“状态放在哪里、由谁携带、如何验证”，而不是简单删掉一个请求头。

把 Mcp-Session-Id 隐藏的连接状态拆成显式业务句柄、请求元数据和可观察性字段，服务才能在普通轮询负载均衡后仍然可恢复、可缓存、可追踪。

先拆开协议状态和业务状态

旧版请求通常先 initialize，服务器返回 Mcp-Session-Id，后续 tools/call 再带着它回到同一实例。这套机制把连接建立、客户端信息和业务连续性绑在了一起，集群只能依赖粘性会话或共享会话存储。

新规范移除了 initialize/initialized 握手和 Mcp-Session-Id。协议版本、客户端信息、能力等请求上下文改为随请求携带，服务器也可以通过 server/discover 提供能力发现。这里要画一条线：协议层无状态只说明每个请求自洽，不会替应用保存购物篮、浏览器或任务记录。

用显式句柄承接跨调用数据

需要跨调用的数据改成普通工具参数。比如 create_basket 返回 basket_id，之后 add_item 明确传回这个值：

{
  "method": "tools/call",
  "params": {"name": "add_item", "arguments": {
    "basket_id": "bkt_7f2a", "sku": "SKU-204", "quantity": 2
  }}
}

服务端用 basket_id 查业务状态存储，得到记录后再执行本次工具调用。它不关心请求落到哪个服务实例，只要求句柄可校验、可过期、不能被另一个租户猜中。这个设计也更适合审计：用户传了哪个对象、工具改了哪条记录，都能从参数和业务日志中还原。

把路由、缓存和追踪变成请求的一部分

无状态请求要让基础设施看得懂。面向 2026-07-28 的 Streamable HTTP 请求可以带上 `Mcp-Method: tools/call` 和 `Mcp-Name: search`，负载均衡器、网关或限流器据此选择规则，不必先解析 JSON body。服务器还应拒绝头部与 body 中方法、名称不一致的请求。

结果缓存要看 `ttlMs` 与 `cacheScope`。前者表示结果还能新鲜多久，后者说明结果是否可以跨用户共享；tools/list 这类列表不应只靠一条长 SSE 连接通知变化。链路信息放在 `_meta`，按约定传递 `traceparent`、`tracestate` 和 `baggage`，下游才能把主应用、MCP 客户端、服务器和下游调用串成一棵追踪树。

给兼容层留下清晰的版本边界

不要只删掉 Mcp-Session-Id 就上线。请求至少要带清楚的 `MCP-Protocol-Version`，客户端信息和能力按新规范放入 `_meta`；网关需要同时识别旧版和新版，或者在入口明确拒绝不支持的版本。

服务器主动请求也有边界：它只能发生在处理客户端请求期间。需要用户补充输入时，服务器返回 `InputRequiredResult`，客户端收集答案后带着 `inputResponses` 和原来的 `requestState` 重发。这样重试仍可落到任意实例，状态来自载荷而不是一条被网关固定的连接。

迁移验收可以按四项做：任意实例接收同一 basket_id；头部与 body 不一致时返回错误；缓存按 ttlMs 和 cacheScope 失效；补充输入的重试仍能关联原 trace。四项都通过，再考虑移除旧版粘性会话。

常见问题

MCP 无状态后还需要 Redis 吗？

协议本身不再要求共享会话存储，但业务仍可能需要 Redis 或数据库保存 basket_id 对应的数据，选择取决于数据一致性、过期和并发更新要求。

能把 basket_id 放到 HTTP header 里吗？

可以由业务自行设计，但工具参数更容易被模型、权限检查和审计明确看到；不要重新把业务连续性藏回协议会话头。

ttlMs 等于浏览器的缓存时间吗？

它表达 MCP 结果的新鲜度和缓存范围，客户端仍要结合 cacheScope、用户权限和本地缓存策略判断是否能复用。

2025-11-25 客户端能直接连 2026-07-28 服务吗？

不能凭版本字符串推断兼容。两版存在握手、会话、请求元数据和多轮输入差异，应通过明确的协商、适配层或拒绝策略完成迁移。

相关规范会继续通过候选版本、扩展和兼容政策演进。部署前应以 MCP 官方规范和变更记录核对当前实现支持的版本，不要把博客中的迁移示例当成某个 SDK 已经完成升级的证明。