上个月我还在为 MCP 的会话管理头疼，现在官方直接把问题解决了上上篇写 MCP 传输层升级实战的时候，我提到过一个还没完全解决的问题：多个客户端并发访问时的会话隔离策略。那时候 Streamable HTTP 刚出，我在本地测试环境跑得挺顺，一到公网就被各种问题搞到怀疑人生——session 串了、某个请求超时整个链路断了、负载均衡器把不同步的请求分到了不同的 MCP 进程。这些问题不是我的代码写得糙，是 MCP 协议本身设计里就有的坑。MCP 从一开始就假设 Server 和 Client 是一对一的，握手建 session，session 里跑请求。这个设计在本地场景（stdio 管道）完全没问题，一旦你像我一样尝试把 MCP Server 部署到公共网络，让多个 Agent 同时调用，所有问题全暴露了。从当初第一个 MCP Server 学着写到现在，中间经历了不少版本迭代。最开始连文档都看不全，官方概念文档偏学术，手把手教程少之又少。后来 Streamable HTTP 出来的时候我第一反应是「终于有 HTTP 传输了」，兴冲冲部署上线准备替换掉之前的 stdio 模式。结果被 session 隔离和并发冲突折磨了两周，才陆陆续续用一堆 workaround 撑住。那段时间我在那篇传输层文章里写的——「一个还没完全解决的问题」——就是我当时的原话。所以 7 月初，当我在 MCP 官方博客上看到 2026-07-28 Release Candidate 的公告邮件时，第一反应不是兴奋，是松了一口气。那天晚上我花了两个小时从头到尾读了 RC 的 changelog，读完之后只有一个感觉：这次终于从根本上改对了。Stateless 化：去掉 initialize 握手之后，整个世界清净了2026-07-28 RC 最大的改动，就是把 initialize 握手和协议级 session 完全移除。在旧规范里，Client 和 Server 建立连接的第一步就是握手。Client 发 initialize request，带上自己的协议版本和能力列表，Server 回 init
