MCPModel 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.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版