MCP 2026 年 7 月的规范从协议层剥离了所有形式的会话状态 (session state)，迫使所有状态都必须存在于模型的上下文窗口 (context window) 中。这一变化使得任何 MCP 服务器都能响应任何请求，为在负载均衡器、无服务器函数 (serverless functions) 和自动扩缩容的 Kubernetes Pod 之后进行纯无状态部署铺平了道路。
为什么这一变化至关重要
自首次发布以来，MCP (Model Communication Protocol) 一直保持着轻量级的会话握手和 Mcp-Session-Id 请求头，用于在多次 HTTP 调用中跟踪对话状态。这种设计让服务器能够记住哪些工具句柄 (tool handles)、采样率或日志偏好属于特定的客户端。它还提供了可恢复的 Server-Sent Events (SSE) 流，因此连接中断后可以从中断处继续。
2026 年 7 月 28 日的规范完全取消了会话握手。现在，每个请求都在 _meta 字段中携带协议版本和客户端能力，而 Mcp-Session-Id 请求头也随之消失。Roots、sampling 和 logging 字段被标记为已弃用 (deprecated)。简而言之，传输协议现在是纯粹的“请求-响应”模式；不再需要维护“会话”。
开发者需要做出哪些改变
状态不再是服务器需要关心的问题，而是存在于模型的上下文窗口中。当模型需要引用外部资源时，必须作为工具结果的一部分从服务器接收一个显式的句柄 (handle)。下一个请求会将该句柄作为参数包含在内，模型将其视为与其他 token 相同的对象。
由于上下文窗口是一个固定大小的 token 缓冲区，每个句柄都会消耗空间，从而与用户提示词 (prompts) 或模型输出产生竞争。
可靠性也发生了转移。由于失去了 SSE 的可恢复性或消息重传机制，流中断会导致请求完全丢失。客户端必须从头开始重新发起调用。对于快速的无状态查询，这是可以接受的；但对于长时间运行的检索或多步骤的智能体 (agent) 任务，这迫使开发者必须构建自己的重试逻辑，或者将任务拆分为更小的块。
Pilot Protocol 填补了这一空白
MCP 的无状态化是刻意为之，但这使得网络层失去了连接层级的身份识别或可靠性保证。位于 MCP 底层的 Pilot Protocol 填补了这一空白。Pilot 只需建立一次身份，并使用加密技术将数据包与发送者绑定。从 MCP 的角度来看，客户端每次只需发送一个新的 HTTP 请求；而 Pilot 则负责保持底层传输的稳定。
这两种协议相辅相成：MCP 保持轻量、单次请求成本低廉，并且易于在任何 HTTP 端点后进行扩展；而 Pilot 则承担了传统基于会话的协议所提供的繁重工作。
大规模应用下的优势
- 负载均衡器友好 —— 无需会话亲和性 (session affinity)；任何后端都可以处理任何请求。
- 无服务器就绪 —— 函数可以按需启动、处理请求并关闭，且不会留下残留状态。
- Kubernetes 自动扩缩容 —— Pod 可以自由地添加或移除；控制平面不再需要跟踪会话映射 (session maps)。
权衡之处
- Token 开销 —— 句柄及任何其他状态现在都会占用模型的上下文窗口，直接与提示词和响应竞争。
- 模型驱动的正确性 —— 模型必须能够正确地回传句柄；幻觉 (hallucination) 或拼写错误都可能破坏工作流。
- 缺乏内置的可恢复性 —— 长时间运行的任务必须实现自己的检查点 (checkpointing) 机制，或者承担完全重启的风险。
- 诊断功能的弃用 —— Roots、sampling 和 logging 字段已消失，因此除非开发者在应用层添加，否则将失去用于细粒度监控的便捷钩子 (hook)。
总结
通过从传输线路上抹除会话状态，MCP 2026-07 将协议转变为一个纯粹的 HTTP 端点，可以部署在任何负载均衡器、函数平台或边缘节点之后。其优势在于显而易见的扩展性；缺点是状态现在存在于模型有限的 token 窗口中，且可靠性取决于客户端和底层的 Pilot 层。随着 AI 智能体 (agents) 的运行时间从秒级延长到小时级，单次请求的低廉定价与 token 预算压力之间的平衡，将决定这种无状态模型是否能成为长期的胜利。