林岚｜OC 开发者生态编辑

据 TechCrunch 报道，MCP 下一版规范将移除协议层会话和 Mcp-Session-Id，让远程 MCP 请求可以像普通 HTTP API 一样被任意服务器实例处理。

一句话结论： MCP 不是把所有应用状态都删掉，而是停止替应用偷偷维护连接状态；需要购物车、浏览器或任务状态时，服务明确返回一个 ID，再由模型在后续调用中带回来。

旧版 Streamable HTTP 的典型流程，是客户端先 initialize，服务器分配会话 ID，后续请求都携带它。这在一台服务器上很自然，扩展到许多实例时却意味着负载均衡器要保持“粘性”，或者所有实例共用 Redis 一类会话存储。

新版做法更接近成熟 Web API：请求本身携带协议版本和必要能力，任何实例都能接住。tools/list 等结果也可缓存，网关更容易路由、记录和限流。对每天处理大量短连接的 MCP 服务，这会减少一层隐性基础设施。

无状态不等于 Agent 失忆。一个浏览器工具仍可创建 browser_id，购物工具仍可返回 basket_id，只是这些状态成为工具合同里看得见的参数。好处是调试时能知道状态从哪来，坏处是开发者必须认真设计生命周期、权限和清理逻辑。

这也是一次破坏性升级。依赖服务器主动通知、资源订阅或隐式会话隔离的实现，需要迁移到新的扩展和交互方式。官方 2026-07-28 规范候选版还包括 Extensions、Tasks、MCP Apps 和授权强化，不能只升级 SDK 就假设行为完全不变。

关键事实

• 新规范移除初始化握手、协议会话和 Mcp-Session-Id。
• 应用仍可通过工具返回的显式句柄保存状态。
• 普通远程服务可以使用轮询负载均衡，不再依赖粘性会话。

OC 判断

这不是最吸引普通用户的 MCP 更新，却可能是最重要的一次。协议从“像长连接助手”变成“像可运营的互联网服务”，才有机会进入真正的大规模企业系统。

为什么重要

• 对开发者： 检查代码是否依赖会话 ID、初始化握手和服务器主动消息。
• 对企业： 部署成本和可观测性会改善，但迁移要做协议版本兼容。
• 对用户： 更稳定、更容易扩展的 MCP，最终会减少 Agent 连接工具时的随机失败。

参考来源

• MCP 官方博客：2026-07-28 Release Candidate
• SEP-2567：Sessionless MCP
• TechCrunch 原始报道