MCP协议走向无状态 一个传输层的重大变化

MCP（Model Context Protocol）的规格更新在7月28日发布了一个重要改动：传输层走向无状态。

如果你不在AI Agent开发的一线，可能对这个变化没什么感觉。但如果你正在用MCP协议构建Agent工具链，这个改动会直接影响你的架构设计。

先说说MCP协议是什么。它定义了AI模型和外部工具之间的通信标准——模型通过MCP协议调用工具、获取数据、执行操作。过去一年里，MCP在Agent开发社区里逐渐成为事实标准，Claude Code、各种IDE插件、Agent框架都在用它。

但MCP最初的传输协议有一个设计选择——有状态连接。模型和工具服务器之间建立的是长连接，连接的整个生命周期里，消息是相关联的。

这个设计的优点很明显：不需要每次都重新握手，消息序列号可以简化实现。

但问题在于——长连接在Agent场景下并不总是最佳选择。尤其是当Agent需要在多个工具之间快速切换、或者在不同进程之间传递上下文时。

这次更新的核心变化是：MCP的传输层现在支持无状态模式。每个请求独立携带认证信息和上下文，服务器不需要维护客户端状态。

这次改动包含了传输协议中状态管理的全部重新设计——JSON-RPC消息的请求/响应机制变更，消息确认机制的调整。

从工程角度看，这意味着什么？

第一，水平扩展变得简单了。在有状态连接模式下，需要做会话亲和（Session Affinity）来保证同一个Agent的请求路由到同一个后端实例。这对负载均衡器配置、后端扩容都增加了复杂度。无状态模式下，任何后端实例都可以处理任何请求。如果你跑过Kubernetes上的Agent服务，应该清楚session亲和性带来的调度限制——Pod扩缩容时需要重建连接，滚动更新时会话会断。

第二，故障恢复成本降低了。连接断开不再意味着会话丢失。Agent只需要重新发送请求，服务器端不需要重建状态。这在Agent执行长任务时尤其有用——一个Agent任务可能持续几分钟甚至几十分钟，保持连接的难度和成本都会累积。

第三，消息格式更加标准化。新的传输规范中，请求头携带了更丰富的能力协商信息，包括安全策略、数据格式偏好和流控参数。这意味着客户端和服务端之间不再需要提前约定数据格式，而是运行时协商。

不过问题在这里：无状态模式对每个请求的开销更大。每次请求都需要携带认证信息和上下文元数据，这对于短请求场景影响不大，但对于长上下文推理——比如Agent带着大量历史信息调用工具——会增加网络传输量。

MCP团队的做法是同时保留有状态和无状态两种模式，让开发者根据场景选择。对于延迟敏感、需要高频调用的场景，继续保持有状态连接。对于需要高可用、水平扩展的场景，推荐使用无状态模式。

从协议设计的角度来看，这次改动反映了MCP团队对真实部署场景的理解。MCP最初的协议设计偏理想化——假设Agent和工具之间建立长连接后一直可用。但在生产中，Agent经常需要在不同环境中切换上下文，或者被调度到不同的计算节点上运行。

从实现角度看，如果你已经在用MCP的SDK（官方的TypeScript、Python、Kotlin SDK），升级到新版本后需要做两件事：一是检查连接管理的代码是否需要适配无状态模式；二是配置路由层让服务支持无状态请求。

对开发者来说，最直接的体验变化可能是：工具调用错误恢复变得更优雅了。现在的Agent在出现连接中断后，不需要重新建立完整的会话，只需要重新发送失败的那个请求就行了。

这听起来是个小改动——但站在传输层层面调整状态管理，涉及的实现改动不小。JSON-RPC的message id管理、并发请求控制、超时重试策略，都需要重新设计。

MCP团队的roadmap里，下一步是推动服务端SDK原生支持无状态模式，包括自动的上下文元数据注入和请求重试机制。从工程角度看，这个方向是对的——状态管理应该在框架层面解决，而不是让每个Agent应用自己实现。

关于维基框架

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。

官网：framewiki.com

Gitee：gitee.com/wiki-framework

GitHub：github.com/wiki-framework

示例项目：gitee.com/cdkjframework/framewiki-example

📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）