Higress v2.2.4：MCP、Gateway API 与推理扩展

Higress v2.2.4：MCP、Gateway API 与推理扩展

一句话结论

这篇文章值得入库，不是因为 Higress 发了一个普通版本，而是因为它把三条 AI 基础设施线索放到同一个网关实现里：MCP 2026-07-28 的无状态 HTTP Tools、Kubernetes Gateway API v1.6、Gateway API Inference Extension v1.4。它说明 Agent 工具调用和模型推理流量都会越来越依赖“可验证的网关控制面”，而不是靠单个 Agent 进程自己维护会话、路由和安全边界。

主要变化

MCP 2026-07-28：远程工具调用转向无状态 HTTP Tools

文章称 Higress v2.2.4 已支持 MCP 2026-07-28 无状态 HTTP Tools 基线，覆盖 server/discover、tools/list、tools/call。核心变化是远程工具调用不再依赖先 initialize 再通过协议级 Session ID 续会话，而是每个请求都携带协议版本、客户端身份和能力。

这解决的是 MCP Server 横向扩容时的粘性会话问题。旧模式下，后续请求要么黏在原实例，要么需要共享会话存储；新模式更像每次请求带齐材料，任意后端实例都能处理。Higress 还把工具方法和工具名放进 HTTP Header，使网关可以在解析 JSON Body 前做路由、鉴权、限流和计量。

文章列出的边界控制包括：输入 Schema 校验，modern 到 modern / modern 到 legacy / legacy 到 legacy 三条显式桥接路径，Origin、媒体类型、请求大小、单条 JSON-RPC 消息、Header/Body 一致性校验，以及默认隔离 Cookie、Session、Last-Event-ID、内部路由 Header 和无关凭据。

Gateway API v1.6：入口标准升级并隔离不同 Gateway 工作负载

Higress v2.2.4 将生产模块、API 类型和控制面转换语义升级到 Gateway API v1.6.0，并隔离 v1.4 与 v1.6 的依赖、CRD 和测试模块，避免运行时或测试中静默混用版本。文章还提到可选的 per-Gateway Deployment/Service 模式：每个受管 Gateway 可以拥有标签隔离的工作负载，以及与 Listener 对应的 Service 端口。

验证方面，文章给出 Gateway API v1.6 官方 HTTP 一致性测试结果：37 项通过，0 失败，0 跳过。范围覆盖 Gateway、HTTPRoute 与 ReferenceGrant，不覆盖 TLS、gRPC、TCP、UDP 或实验性 Profile。

推理扩展 v1.4：Endpoint Picker 选中的端点需要被数据面真正执行

Gateway API Inference Extension 解决的是模型推理流量的端点选择问题：哪个实例有前缀缓存，哪个队列更短，LoRA Adapter 在哪里，数据并行场景下应该落到哪个端口或 rank。Endpoint Picker 负责选目标，网关负责按目标转发。

文章称 v2.2.4 补齐了多个关键链路：一个 InferencePool 的多个 targetPorts 都可成为候选端点，数据并行端点可以聚合，Endpoint Picker 选中的精确 PodIP:port 能被数据面执行，最终真实服务请求的端点也可以回传。验证结果是推理扩展 v1.4 官方网关一致性测试 12 项通过，0 失败，0 跳过。

对 Agent 工程的意义

1. 工具调用需要基础设施化：MCP 工具不应只是 Agent SDK 里的函数列表，而应进入网关层治理，具备协议版本、能力发现、鉴权、限流、计量和审计。
2. Session 不是免费的抽象：长期 Agent loop 如果依赖服务端会话，会遇到扩容、重启、恢复和跨实例一致性问题；无状态请求更适合生产级工具调用。
3. 协议升级必须显式桥接：新 MCP 客户端和旧 MCP Server 共存时，升级路径应被声明和验证，不能靠默认行为悄悄切换。
4. 推理流量也需要可验证落点：Endpoint Picker 的选择只有被数据面执行、并能回传 served endpoint，才算闭环。否则调度策略无法可靠学习和修正。
5. 社区治理开始纳入 Agent 辅助贡献：文章提到 Higress 社区要求实质性 AI/Agent 辅助贡献先获得 Maintainer 对 Proposal 与 Design 的批准，再按授权 TASK 实施，并记录验证命令、结果、证据和哈希。这与 Harness-Engineering 的 evidence-gated lifecycle 方向一致。

对 Hermes / llm-wiki 的启发

Hermes 如果未来接入更多 MCP Server，不应只在 skill 里写“这个工具危险/那个工具只读”，而应逐步把工具面收敛成 runtime policy：哪些工具可无审批调用，哪些只能只读，哪些需要 human gate，哪些必须记录 request/response hash。

llm-wiki 也可以把 MCP / Gateway / 推理扩展作为 Agent 基础设施专题继续跟踪：它们是 Agentic-Engineering 的下层地基，决定 Agent 能否在真实生产系统中稳定、安全、可横向扩容地调用工具和模型。

局限

这是一篇版本发布解读，来自 Higress/阿里云云原生语境。文章给出了 PR 和一致性测试结果，但本页尚未逐条复核 PR diff 与官方测试日志。因此当前结论适合作为中置信的技术雷达条目；若未来用于生产选型，应补充官方 release、PR、conformance 报告和社区评审状态的二次验证。

写入记录

• 2026-08-20 19:24 CST：根据阿里云云原生公众号文章新增来源页，提炼 MCP 无状态 HTTP Tools、Gateway API v1.6、推理扩展 v1.4 与 Agent 工程基础设施意义。