Higress 是一个面向 AI 网关和 Kubernetes 入口流量管理的开源网关。看它近期几个版本的演进，能摸清 AI 时代网关正在往哪走——不只是转发请求，还要统一多模型服务入口、参与推理流量调度、让传统 Ingress 平滑迁移。把这些方向看懂，比追具体 PR 更有选型价值。
AI 网关：统一模型入口与安全拦截
AI 网关的核心命题是：让不同模型服务（OpenAI 兼容、Anthropic、Vertex、vLLM 自建等）尽量通过统一入口接入，业务应用少处理协议差异。Higress 在这条线上持续增补。
协议透传：AI Proxy 支持 vLLM 透传 Anthropic Messages 和新版 OpenAI endpoints。能原样透传的请求不再做多余转换，链路更短、排查更轻。这对自建模型团队很关键——不必为了走网关而被迫改协议。
上下文限制前置：新增 ai-context-limit 网关插件，在网关层提前判断请求是否超过模型上下文限制，省去等请求打到模型服务才失败的浪费。长文档问答、RAG、多轮对话、代码分析这类容易塞超长 prompt 的场景最实用。
安全防护：ai-security-guard 增加结构化拒绝响应和 AI 日志，支持 Embedding API 内容检测。安全插件拦截后能把原因说清楚，方便业务侧展示提示、做审计、接告警，而不是黑箱拒绝。
负载均衡与路由：ai-load-balancer 新增基于一致性哈希的 cluster_hash 策略，model-router 支持保留完整原始模型名。还修了一批多厂商协议兼容问题——Claude API 名称识别从宽泛匹配改成更准确的后缀判断，减少换模型就异常 400 的概率；修了 ai-cache 在 SSE 流式响应首个 chunk 只有 role 时的兼容问题。
Gateway API：多网关隔离与版本兼容
Gateway API 正在成为 Kubernetes 入口流量管理的重要标准，比传统 Ingress 拆得更细：GatewayClass 说明谁管网关、Gateway 是网关实例、HTTPRoute 等资源负责路由规则。拆得清楚后多团队、多网关、多协议的边界更容易表达。
Higress 在这块的演进：支持可配置的 GatewayClass 隔离——过去默认监听固定 GatewayClass，单套网关直接；当一个集群同时有公网、内网、测试多套网关时，现在能明确分清谁处理哪些资源，多套 Higress 可在同一集群各自管理对应资源。默认关闭 alpha Gateway API watch，把稳定资源和实验性资源分开——常规能力默认启用，实验性能力按需开启，减少版本差异对控制器启动和同步的影响。还修了 Gateway 状态地址写入，对依赖状态做自动化发布、DNS 更新或平台展示的团队很重要。
推理扩展：让 AI 流量获得更合理的调度
普通 Web 服务做负载均衡，依据是权重、连接数、健康状态。AI 推理流量更复杂：不同请求命中不同模型、不同副本 GPU 负载不同、队列长度不同、缓存命中情况也不同。Gateway API Inference Extension 想解决的就是网关在转发 AI 推理请求时，结合推理后端状态做更合适的调度。
Higress 修复了 InferencePool 路由配置在 HTTPRoute 合并时可能丢失的问题——多个推理路由挂在同一网关和域名下时，要正确保留每条路由对应的推理调度配置，不能在合并过程中退回普通负载均衡。这项能力还在跟随 Gateway API Inference Extension 演进，但它代表了一个重要方向：网关不再只是入口，会逐步参与推理流量调度。对做大模型推理服务的团队，这是选型时要关注的演进点。
Ingress 迁移：少动既有集群资源
Gateway API 是未来方向，但 Ingress 仍是大量线上系统的现实入口。很多团队用 Ingress NGINX 多年，配置、发布、告警、DNS 自动化都围着它跑。迁移到 Higress 时用户最关心的不是新网关能不能写全新配置，而是已有配置能不能少改、现有平台边界能不能不被打乱。
Higress 在迁移细节上持续补强：Helm 支持跳过 IngressClass 创建——很多集群的 IngressClass 是预先创建统一管理的，安装网关时不应擅自覆盖或新建，现在可让 Higress 监听指定对象不动平台已有资源；正确保留 Ingress LoadBalancer hostname——有些云厂商返回域名而非 IP，状态同步丢 hostname 会影响外部系统、DNS 自动化和迁移验证。这些不算亮眼功能，但迁移真正落地时，往往正是这些小地方决定要不要回滚。
安全与稳定性
网关在入口位置，安全默认值不能含糊。这块多是修复和加固，但每项直接关系线上可靠性。
- 认证：jwt-auth 支持 remote JWKS，便于公钥集中管理、密钥轮转更方便；Key Auth 支持同一服务配多个凭证，对迁移和多客户端接入友好。
- OIDC 加固：升级 oauth2-proxy 修复 verifier 回调空指针和 Session 刷新 Cookie 损坏问题，并在 verifier 不可用时 fail closed——认证组件异常时受保护路由应明确失败，而不是悄悄放行。这一点是安全设计的原则底线。
- TLS：回滚了跳过 HTTPS 上游证书校验的行为，恢复更谨慎的默认校验。
- 限流：增强 cluster key rate limit 的 cookie 解析健壮性。
- 运行时：MCP filter 在高内存使用时重建，移除 WASM 不必要的重建触发条件。
Console：配置增多后的操作体验
网关能力多了，Console 配置项也跟着多。Higress Console 的优化集中在减少配置出错、让页面更易用：LLM provider token 列表支持折叠（配多个 token 做负载均衡或容灾时不用摊开一长串）、修复 MCP server 名称含冒号的解析、删除 MCP server 不误删同名 route、修服务权重表 stale state 和潜在空指针。目标很直接——配置出错少了，运维才省心。
CNCF 治理：对选型意味着什么
Higress 已正式完成 CNCF Sandbox 入驻。对正在选型的团队，这些事不像功能那样直接可感，但回答了另一个更要紧的问题：把生产流量交给一个开源网关，它背后的项目是否在被认真、长期、透明地维护。
入驻要逐项落实清单：知识产权与合规（商标 Logo 移交 Linux Foundation、Apache 2.0 许可、第三方依赖许可证扫描）、中立托管（迁入独立 GitHub 组织、加入 CNCF GitHub Enterprise、不再绑单一公司）、治理与安全制度（开放治理文档、DCO、OpenSSF 最佳实践徽章）、社区透明度（维护者名单并入 CNCF 聚合列表、接入 DevStats/CLOmonitor/LFX Insights 看板，活跃度公开可查）。完成 Sandbox 入驻意味着治理、合规与社区运作被纳入 CNCF 公共框架，而不只依赖某一家公司或几个人。后续会朝 Incubation 阶段准备。
谁该关注这些演进
- 用 Higress 做 AI 网关、接入 vLLM/Vertex/Claude 兼容 API、流式响应、AI 安全防护或上下文限制的团队。
- 用 Gateway API 或关注推理扩展在 AI 推理调度落地的团队。
- 评估从 Ingress NGINX 迁移到 Higress、希望复用现有 IngressClass 和平台发布流程的团队。
- 对认证链路、OIDC、TLS 校验、限流、WASM/MCP 运行稳定性敏感的团队。
- 用 Console 管理 LLM provider、MCP server 或路由权重的团队。
升级涉及 Gateway API、Ingress 迁移配置、AI 网关插件或自定义 Helm 参数时，建议先在测试环境渲染并对比安装结果再上生产。网关演进的价值不在版本号，而在它有没有把统一入口、推理调度、平滑迁移、安全默认这几件你迟早要面对的事提前处理好。