MCP 无状态化：规范最终清除了最后一个企业阻塞器

用简单的语言来说。 让AI助手调用外部工具的规范——模型上下文协议（MCP）刚刚发布了一个修订版，该版本取消了客户端和服务器之间需要状态连接的要求。这是企业基础设施团队一直在等待的变化。

为什么状态连接是个问题

原始的MCP传输假设了一个持久的客户端-服务器会话。如果你的助手需要调用工具，助手和工具会在交互过程中共享一个实时通道。在笔记本电脑上运行没问题；但在大规模部署时会变得尴尬。

尴尬之处在于，一旦你在它前面放置一个负载均衡器，问题就暴露出来了。状态会话意味着每个后续调用都必须落在相同的后端实例上。这破坏了企业基础设施中最便宜的部署模式——将请求喷射到无状态池中，根据负载自动扩展，容忍节点丢失。最终，你不得不构建会话亲和性的临时解决方案、粘性路由，或者更糟，成为单点故障（SPOF）的连接管理器。

新规范实际改变了什么

根据报道，修订后的传输允许服务器广告无状态模式。在实践中：

# 之前（改写）
POST /mcp/session → session_id
POST /mcp/call { session_id, tool, args } # 必须命中同一节点
POST /mcp/close { session_id }

# 之后 - 无状态模式
POST /mcp/call { tool, args, ctx } # 任何节点，无会话

ctx 是客户端推送的、服务器需要了解之前轮次的任何内容的部分。这与REST API二十年前达成的共识相同——以稍大的请求为代价换取无状态。

幕后：你现在拥有的权衡

无状态并非免费。两件事移动到客户端：

• 上下文管理。 客户端现在是工具需要的任何每对话状态的真实来源。更大的有效负载，以及一个新的错误类别：忘记传播。
• 幂等性。 一旦任何节点都可以服务任何调用，重试在更多地方变得可行。工具作者需要使其调用幂等，或者处理双重执行。

对于大多数企业部署，这个权衡是值得的。对于低延迟的助手，其中往返字节很重要，这是一个真实的成本。

这意味着什么

MCP生态系统的讨论一直围绕着“从原型质量”到“我们实际上可以将其放在SRE团队背后”的管道成熟。无状态传输是朝着这个方向的具体步骤。它也告诉你规范作者认为增长在哪里：在企业内部，在代理背后，而不是在个人开发者的机器上。

所以呢

对于一个构建者：如果你发布了一个MCP集成并遇到了会话亲和性问题，修复方案现在是规范认可的，而不是特制的。对于一个决策者：MCP现在变得采购友好。预计供应商会像他们过去宣传REST原生一样宣传“MCP原生”。