MCP 出现 Session Not Found：新协议为什么直接取消了 Session ID

MCP 出现 Session Not Found：新协议为什么直接取消了 Session ID

远程 MCP Server 放到多个 Pod 后，偶发 400 Session Not Found，常见原因并不在工具函数。旧版 Streamable HTTP 先通过 initialize 建立会话，服务端返回 Mcp-Session-Id，后续请求必须带着它回到保存状态的实例。负载均衡若把第二次调用发给另一个 Pod，那个实例没有会话，自然只能报错。

MCP 2026-07-28 正式规范从协议层移除了 initialize/initialized 握手和 Mcp-Session-Id。每个请求携带协议版本、客户端信息与能力，任意实例都能独立处理。TypeScript、Python、Go 与 C# 四个 Tier 1 SDK 已支持该版本，迁移方向已经明确；线上仍要考虑客户端升级节奏和旧版本兼容。

先确认版本，再决定修负载均衡还是升协议

排障时应抓取完整 HTTP 头与首个 JSON-RPC 请求。旧客户端会发送 initialize，后续依赖 Session ID；新版请求使用 MCP-Protocol-Version: 2026-07-28，并通过 Mcp-Method、Mcp-Name 与 _meta 自描述。

暂时不能升级时，旧链路仍需粘性会话或共享会话存储，并监控 Pod 重启后的会话丢失。升级后，普通轮询负载均衡可以把每次请求发送到健康实例，网关也能直接按方法和工具名做路由、限流与审计，无需解析 JSON 正文。

切换不能只看接口返回 200。要覆盖滚动发布、实例故障、并发工具调用、跨版本客户端和授权失败。新版强化了授权服务器校验，但具体工具权限仍由团队设计。

无协议会话，不代表业务不能保存状态

购物篮、浏览器实例或长流程仍然需要跨调用状态。新规范建议服务端生成显式句柄，例如 basket_id，再把它作为普通工具参数交给后续调用。状态从隐藏的传输会话变成业务可见对象后，可以设置所有者、过期时间、幂等键与审计记录，也更容易在多个实例之间恢复。

需要用户中途确认的工具可用 Multi Round-Trip Requests：服务端返回 input_required 和序列化的 requestState，客户端收集答案后重新提交，任意健康实例都能继续。耗时操作则进入 Tasks 扩展，通过 taskId 查询和更新状态，不必为了数据库备份、CRM 同步或退款一直占着连接。

迁移阶段最好保留双路径测试。列出所有依赖 Session ID、HTTP GET 流、资源订阅和服务器主动请求的功能，确认新版替代机制是否已在目标 SDK 落地；规范对弃用能力提供至少十二个月窗口，时间充足不等于可以盲升。用一组固定工具调用分别跑旧客户端、新客户端和混合发布环境，检查结果、授权、缓存和故障恢复。

MCP 负责 Agent 与工具的通信，模型接入与身份审计还需要其他层协作。采用统一模型 API 时，可结合 [DASP 协议参考](/dasp/reference) 记录调用侧身份与链路信息；MCP 迁移则聚焦工具传输和应用状态。两个协议放在各自边界内，排查问题时更容易定位。

来源：[Model Context Protocol：The 2026-07-28 Specification](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/blog/content/posts/2026-07-28-spec-ga/index.md)、[Google Developers Blog：Scaling AI Agent Infrastructure with the MCP Stateless updates](https://developers.googleblog.com/scaling-ai-agent-infrastructure-with-the-mcp-stateless-updates/)。