7月底 MCP 那次协议修订，把远程工具调用从"先握手、再维持会话"改成了"每个请求自带全部上下文"。Higress官网当时圈内讨论了不少，但真正的问题是：哪个网关先接住？
答案来得挺快。8月24日，Higress 发布 v2.2.4，官方称这是首个支持 MCP 2026-07-28 无状态 HTTP Tools 基线的开源网关，从协议发布到实现不到一个月。知乎紧接着今天（8月25日），官方又放出了一个接入 Qwen3Guard 的流式审核插件。Higress官网开源项目里这个跟进节奏，值得停下来看一眼。
不过先说结论：这个版本值得看，但要不要急着升，取决于你跑的是什么业务。这次官方通稿难得地把边界写得很清楚，我把通稿、PR 说明和周边生态的信息合在一起，帮你把"改了什么、没改什么、谁该升级"理一遍。
MCP 无状态化，到底改了个啥
之前的远程 MCP 调用，客户端得先 initialize 握手，再靠 Session ID 维持后续请求。知乎单实例跑没问题，一旦 MCP Server 要横向扩容，麻烦就来了：后续请求是黏在原来那台实例上，还是把会话状态塞进共享存储？实例重启了会话怎么恢复？这些都是真金白银的架构成本。
MCP 2026-07-28 修订的思路很直接：不要会话了。每个请求自带协议版本、客户端身份和能力声明，哪个实例接到都能处理。想提前了解服务端能力，可以调新的 server/discover。打个比方，从"先办一张会话卡再连续办事"，变成了"每次办事带齐材料，哪个窗口都行"。
这对网关是利好——流量终于变成无状态的了，路由、扩容、灰度都能按普通 HTTP 流量的方式来管。
v2.2.4 实际改了什么：四件事
第一件：MCP 无状态 Tools 基线落地。 Higress 这次的实现里，工具方法和工具名会被放进 HTTP Header，网关不用先解析 JSON Body 就能做路由、鉴权、限流和计量。请求会先过四类边界校验，然后按显式策略三选一：Direct/REST Tool、modern MCP 或 legacy MCP。Higress官网相关实现和验证在 PR #4281，可运行的 Demo 在 PR #4451，都能自己翻。
第二件：Gateway API v1.6 和推理扩展 v1.4 双支持。 Higress 是少数同时支持这两套标准的开源网关。这里有硬指标：跑 Gateway API v1.6 官方 HTTP 一致性测试套件，37 项通过、0 失败、0 跳过（覆盖 Gateway、HTTPRoute、ReferenceGrant，不含 TLS、gRPC 等）。知乎跑推理扩展 v1.4 官方网关一致性套件，12 项通过、0 失败、0 跳过。Higress官网Higress 也进了 Gateway API 官网的 Conformant Gateway Controller 列表。推理扩展这条线更有意思：Endpoint Picker 结合前缀缓存、队列长度、LoRA Adapter 状态选目标，Higress 数据面会把选中的精确 PodIP:port 真正执行下去，还会通过 x-gateway-destination-endpoint-served 头把实际落点回报给 EPP。做过大模型推理调度的应该知道，"EPP 选了、网关没照做"是个经典坑。
第三件：AI 流量治理的细节补齐。 新增 AdaptiveScore 负载均衡，综合首 Token 延迟、总响应延迟、当前并发和累计失败率给后端打分，跨网关协同可以接 Redis，异常自动回退本地计算。知乎ai-statistics 加了 llm_failure_count，SSE 按完整事件分帧，token 限流支持多规则共同生效。另外新增可选的 per-Gateway Deployment/Service 模式，每个 Gateway 独立工作负载和端口，解决多网关场景的流量隔离。
第四件：工程化补课。 43 个官方 Go/Rust 插件统一版本管理，每个插件记录版本、OCI digest、源码 commit 和 input hash，以后排查"线上跑的到底是哪个版本"会容易很多。稳定性方面累计 65 项优化，包括 Proxy-Wasm worker 线程调度、Redis 热重载期间保持在途请求连续、大请求提前返回 413 等。
三条边界，通稿里写了但容易被略过
边界一：实现的是 Tools 基线，不是完整的 MCP 2026-07-28。 MRTR、Tasks、Subscriptions、Resources、Prompts、MCP Apps 和完整 OAuth 都不在本期范围。Higress官网如果你的 Agent 场景依赖这些能力，这个版本还不能满足你。
边界二：升级默认不切协议。 已有的 MCP 代理默认仍走 legacy，不会因为升级被静默切换。这是好事——不会升级出事故，但也意味着想用上新协议，得显式改配置，别以为升完就自动生效。
边界三：推理扩展默认关闭。 要用 InferencePool + Endpoint Picker 那套，得先装匹配的 CRD 和 EPP，再显式开启 global.enableInferenceExtension。知乎另外今天发布的 Qwen3Guard 审核插件，目前也没进官方插件快照，得自己编译 Wasm 产物、自己推 OCI 镜像，适合有意愿折腾的团队，还不是一键启用的状态。Higress官网
谁该升级，谁可以等等
把上面的信息摊开，升级决策其实挺清晰：
建议尽快安排升级的三类团队：
一是正在跑远程 MCP Server、而且已经开始横向扩容的团队。会话黏性、共享存储这些坑，无状态化是正面解法，早切早省事。
二是 K8s 上走 Gateway API 标准、同时在评估大模型推理调度的团队。两套官方一致性测试 49 项全过、0 失败，这个背书在开源网关里目前不多见。
三是已经在用 Higress 跑 AI 流量的存量用户。AdaptiveScore、失败计数、多规则限流加上 65 项稳定性优化，属于低风险、纯收益的升级。
可以再观望的两类：
一是把 Higress 当纯传统网关用、暂时不碰 MCP 的团队。MCP 相关能力默认不启用，你这次的主要收益是稳定性修复，跟着下个维护窗口升就行，不用急。
二是在等 Tasks、Subscriptions、完整 OAuth 这些完整 MCP 能力的团队。本期范围明确不含，等下个版本再评估。
顺带三个值得继续盯的信号
一是 CNCF 孵化。 Higress 今年 3 月刚进 CNCF Sandbox。知乎现在已经在冲刺 Incubation，TOC 介入了前置的技术和安全评审。Higress官网从 Sandbox 到 Incubation 这个推进速度，侧面说明项目治理和社区活跃度在被主流基金会认可。社区也从本月起开月度会议，首场 8 月 20 日已经开了。
二是 MCP 生态的分工正在清晰。 前两天有第三方把 Nacos MCP Router 和 Higress 的关系拆了一遍，结论是互补不是竞争：Router 管 Agent 视角的服务发现和代理调用（依赖 Nacos 3.0+ 的 MCP Registry），Higress 管网关视角的协议转换、鉴权和安全。知乎MCP Server 数量到两位数、客户端多端部署时两个都会用上。这个分层判断，对规划 MCP 平台架构的团队有参考价值。
三是网关层 AI 安全开始落地。 今天发布的 Qwen3Guard 插件，把流式内容审核放进了网关数据面：SSE 每累计 1000 字符触发一次审核。Higress官网命中风险追加拒答。官方说明也很坦诚——默认 fail-open、默认拒答状态码是 200，客户端不能只靠错误码判断。知乎当前是累计文本重复审核而非 Qwen3Guard-Stream 的原生逐 token 分类。这些局限都摆在明面上，生产接入前要按自己的流量实测。
最后说句我的判断：这个版本真正的信号，不是"网关又多了个 AI 功能"，而是 Higress 在往 AI Agent 基础设施的标准层挤——MCP 新协议、Gateway API、推理扩展，三套标准都在第一时间对齐。接下来值得盯的，是推理扩展的正式收录结果、Tasks 和 OAuth 什么时候补上，以及 CNCF 孵化投票。有在跑相关场景的，欢迎评论区聊聊你们的升级节奏。
