MCP 放弃有状态回归 HTTP 范式：架构工程才是 AI 时代稀缺能力

早在 2024 年 11 月 MCP 开源 后，Higress 就判断这会是比 Function Calling 更广泛的 Agent 接入外部系统的协议，能显著 加速模型的货币化 。随后，Higress 迅速跟进了几个关键动作：

• 2025 年 3 月，Higress 开源 Remote MCP Server 托管方案，并准备上线 MCP 市场 。
• 2025 年 4 月，Higress 支持将 存量 OpenAPI 批量转化为 MCP Server ，加速企业存量资产的增值。
• 同月，MCP 引入了全新的 Streamable HTTP 传输层，我们对比分析了 Streamable HTTP vs. HTTP+SSE 。

然而 MCP 爆火之后也遇到了一系列挑战。尤其当主流 Agent 客户端开始用 CLI 连接外部系统时，“MCP 沦为弃子”的说法甚嚣尘上。开发者们最痛的槽点集中在上下文拥挤和费钱上。

在 AI 时代，写个 Demo 的门槛确实在降低。但一旦涉及规模化落地，架构设计与工程质量就成了 AI Coding 难以直接替代的稀缺资源。

01. 这次升级，解决了什么问题？

最新版的核心改动，是把 MCP 从一个有状态、依赖长连接的协议，改回了 [无状态请求/响应模型](https://yunpan.plus/f/34-1)。HTTP 协议的无状态特性是 Web 架构里最基础、也最成熟的做法。

过去 MCP 依赖 initialize/initialized 握手和 Mcp-Session-Id 会话来维持上下文。这就导致同一会话的多次请求必须精准落到同一个服务端实例，否则上下文就会丢失。

以高德地图的 MCP Server 为例。用户问“从公司到最近的充电桩怎么走”，Agent 在一轮对话里往往要串联调用 Server 暴露的多个 tool：先地理编码把地址转坐标，再 POI 搜索找附近充电桩，最后路径规划算路线。这三个 tool 共享同一个会话上下文，有状态模式下就必须由同一个实例来承载。

当调用量不断上涨、后端部署了多个实例时，常规的 [负载均衡](https://yunpan.plus/f/14-1) 策略就行不通了。你必须保证同一会话始终回到最初那个实例，也就是会话亲和性。要么让负载均衡记住绑定关系，要么在实例之间共享会话状态，这些都会给 [横向扩容](https://yunpan.plus/f/14-1) 带来额外架构成本。

新版本索性把这套握手和会话标识直接退役了（SEP-2575、SEP-2567），改为每个请求自描述。协议版本、客户端身份和能力全都随请求携带，任何请求都可以打到普通轮询负载均衡后面的任意实例，彻底告别了对共享存储的依赖。

原先那些需要服务端主动发起、依赖长连接的操作（elicitation、sampling、roots），被替换成了多轮请求 MRTR：服务端返回 input_required，客户端带上答案重试。Streamable HTTP 请求也开始强制携带 Mcp-Method 和 Mcp-Name 两个 header（SEP-2243），网关、限流器可以直接按 header 路由和计量，连请求体都不用解析了。

02. 新版本是否解决了最痛的槽点？

无状态化解决的是部署和扩展问题，极大降低了运维复杂度。但坦白讲，社区对 MCP 最集中的吐槽——上下文拥挤和费钱，并没有被正面回应。

上下文拥挤的根源在于，工具定义是前置加载的。Agent 还没开工，就得先把所有可用工具的说明书塞进上下文提示里。工具一多，定义本身就会挤占相当一部分窗口，留给任务本身的空间被严重压缩。

新版本里和这个问题最相关的改动，是 tools/list、prompts/list、resources/list 等接口开始携带 ttlMs 和 cacheScope（SEP-2549），让客户端可以缓存工具目录，重连后保持上游 prompt 缓存稳定。但这里必须区分清楚：缓存优化的是“别老去后台重新拉取清单”，它并没有降低单轮对话里工具定义占用的 token。该占的上下文一个也没少，只是减少了重复获取的次数。所以，对于上下文拥挤这个核心槽点，缓存充其量是个外围改善，谈不上对症下药。

费钱则是上下文拥挤的直接恶果。token 占用没降，调用成本自然下不来。开发者真正想要的其实很朴素：工具能按需加载，只在要用的时候，再把相关工具的定义喂进上下文。

更要命的是，新版本本身还附赠了一笔迁移成本。无状态化是一次破坏性变更，那些重度依赖会话标识的实现得大改代码。随之一同弃用的还有 Dynamic Client Registration、Legacy HTTP+SSE 传输等等，整套退场清单并不短。

03. 稀缺的是架构工程，而非一个简单想法

回过头看，这次升级并没有什么石破天惊的新机制。无状态、请求自描述、按 header 路由，全都是 Web 架构玩了多少年的老套路。MCP 之所以绕个大圈最后又回到原点，是因为爆火之后真正的考验变了：不再是“能不能定义 Agent 连接外部系统的新标准”，而是“能不能在规模化流量下，保障调用方和维护方的体验”。

前者靠一个好点子就能解决，后者却需要对可扩展性、部署形态和治理成本的全局考量。这背后需要的是扎实的架构设计和丰富的工程实践，而这恰恰是 AI 时代最容易被低估、也最稀缺的东西。

对了，Higress 正在开发对 MCP 最新版的支持，已于本周发布 PR：
https://github.com/higress-group/higress/pull/4059

如果你对 MCP 协议演进或云原生网关架构有更多见解，也欢迎来云栈社区和我们一起聊聊。