7 月 28 日，模型上下文协议（Model Context Protocol，MCP）项目发布了 2026-07-28 修订版，直接删掉了 initialize 握手和协议级会话。这是 MCP 发布以来改动最大的一版。
AISIX AI 网关在三周内完成了支持，开源网关、AISIX Cloud、文档已经全部就绪。
为什么这次改版重要
之前部署过 MCP 服务的同学应该有体会：这东西不好扩容。
老协议是有状态的。客户端上来先握手，服务器发一个 Mcp-Session-Id，之后所有请求都得路由回记得这个会话的实例。想加副本？要么负载均衡器上配粘性会话，要么自己搭一套共享会话存储。一个工具服务，平白多出一份有状态应用的运维成本。
新版协议把这套东西整个砍了：不握手、不发会话，每个请求自带协议信息，服务器能力用新增的 server/discover 方法按需查询。说白了，MCP 流量重新变回了普通的无状态 HTTP——负载均衡、弹性伸缩、Serverless，这些现成的基础设施都能直接用上。
代价是破坏性变更。客户端和服务器不可能约好同一天升级，接下来相当长一段时间，会是新旧两代并存的局面。
这个过渡期的活儿，正好是网关的。
AISIX 的做法：两代协议，一个端点全接
现在 AISIX 的 MCP 端点对每个客户端自动协商协议版本：
| 协议修订版 | 支持情况 |
|---|---|
2026-07-28 | 支持，通过 server/discover 免握手启动 |
2025-11-25、2025-06-18、2025-03-26 | 支持，走 initialize 握手 |
2024-11-05 | 不支持（HTTP+SSE 老传输，另一个世代） |
老客户端照旧握手，新客户端直接无状态调用，两边都不用改一行配置。
顺带提一句：AISIX 从第一天起就没在任何协议版本上发过会话，MCP 请求在网关副本之间从来不需要会话亲和。所以横向扩容这个红利，你的老客户端不用等谁升级，现在就在享受。
上游服务器：老的照连，新的用一个字段搞定
客户端讲什么协议，跟网关连上游用什么协议，是两码事。网关在入口把客户端的协议处理完，转身对每个注册的上游服务器单独开会话。
上游会话的版本，一个字段说了算：
1mcp_servers:
2 - name: modern-tools
3 url: https://mcp.example.com/mcp
4 protocol_version: "2026-07-28"
5 auth_type: none默认不用配——网关走 initialize 握手，2025 年那几个版本自动协商，升级到新版但保留了兼容的服务器也照连不误。只有碰上彻底不理 initialize 的新版服务器，才需要把 protocol_version 钉成 2026-07-28。用 AISIX Cloud 的话，就是 MCP 服务器表单上选一下。
两头解耦的结果：老客户端能调只支持新版的服务器，新客户端也能调还没升级的老服务器。谁先升、谁后升，互不耽误。
多说一句我们为什么不做自动探测。让网关先试新版、不行再退回老版，听起来很贴心，但它有个副作用：配置错了，系统不报错，而是换一种方式继续运行。等你从审计日志里发现行为不对，往往已经过去几个星期了。AISIX 的选择是配什么用什么，不支持就当场报错——错误暴露得越早，代价越小。
升级 SDK 时踩出来的五个坑
支持新协议，底层的 MCP SDK 得升一个大版本。合并之前我们把新版的默认行为挨个过了一遍，有五个是那种“单体应用无所谓、塞进网关就出事”的，全部关掉或改掉了。
第一个是自动多轮重试。新协议允许服务器回一句“我还需要补充输入”，SDK 收到后会自动重试，单次调用上限 10 轮。放到网关场景里：调用方发了一次 tools/call，上游最多执行 10 次、产生 10 笔费用，而配额和预算系统看到的始终只有那一次调用。已关闭——非最终响应直接以错误形式返回给调用方。
第二个是会话过期重放。有状态上游把会话过期了，SDK 默认悄悄重建会话、把在途请求再发一遍。如果那个请求是“创建工单”、“发送消息”呢？就会执行两次。已关闭。
第三个是客户端响应缓存，默认开着，出错时还拿过期缓存兜底。网关是多租户共享的，缓存里的上游响应可能被另一个租户读到。整体禁用。
剩下两个是新增的大小限制：一个 4 MiB 请求体上限，生效位置在网关自身可配置限额之下，配置更大的值也不会生效；另一个是升级前不存在的 16 MiB 上游流式事件上限。前者改成跟着网关配置走，后者直接移除，行为跟升级前一模一样。
这五处各配了一个回归测试，断言方式很直接：数上游实际收到的请求数。它们合起来保证一件事——一次入站调用，上游恰好执行一次。预算、限流和审计的准确性都建立在这个前提上。
调用方凭证不会跟着请求走
调用方的 Authorization 请求头、协议版本、会话标识，网关一概不带给上游。上游会话独立建立，用的是注册服务器时配的凭证；调用方的 API Key（API 密钥）只干一件事——向 AISIX 证明自己是谁。这本来就是 AISIX 的凭证模型，这次无状态改造顺带把整条边界用测试固定了下来。
怎么验证的
两层。CI 里对真实网关链路跑官方 MCP 一致性套件中适用于工具调用的场景，跑不过不许合并；另有一组对照测试，拿旧版、新版两种客户端打同一个端点，把各自看到的响应逐字节固定——后续升级若改变了线上行为，这些测试会先失败。
怎么上手
MCP 支持随开源网关发布（GitHub，Apache 2.0）。已经在用 AISIX 的不用迁移：客户端各协商各的版本，哪天碰到只支持新版的上游，加个 protocol_version 字段就行。
如果碰到网关处理不了的客户端或服务器，欢迎在 GitHub 提交 Issue。