8月以来，知乎上AI网关选型的讨论明显多了起来：《LLM网关技术选型方案》《直连大模型API、开源网关、商用AI管理平台，该如何抉择》《企业AI网关解决方案哪家好？求真实经验》接连出现。知乎但仔细翻一遍会发现，不少选型文最后都导向某个商业平台的推广，而一篇盘点"7款主流API网关"的评测里，甚至没有收录Higress。知乎对真想上AI网关的团队来说，这反而更难受：噪音太多，中性证据太少。
所以我们把近期全网关于Higress的信息过了一遍——官方发布、社区实测、迁移实践、选型讨论——只讲证据：它到底能干什么、数据从哪来、哪些团队不建议碰。
一句话定位
Higress是阿里开源的云原生API网关，内核基于Envoy和Istio，用Wasm插件扩展能力，一个网关同时承担K8s入口、微服务网关和AI网关三个角色。知乎今年上半年有两个关键节点：3月通过CNCF TOC投票入驻Sandbox，6月底发布v2.2.3正式版（主仓库48项更新+控制台8项更新，18位贡献者参与）。知乎知乎
下面按你团队的实际场景对号入座。
场景一：聚合调用多家模型API
这是Higress AI网关最成熟的用法。核心是ai-proxy插件：用OpenAI兼容协议统一接入15+国内外主流模型，协议转换由网关完成，业务代码不用为每家厂商写适配。知乎配套能力是一套组合拳：
Token级限流：按消费者/API维度管配额，不是粗粒度的请求数限流
模型兜底：某家调用失败自动切备用模型，社区已有DeepSeek失败自动切换兜底模型的实践。哔哩哔哩
语义缓存：相似问题命中缓存直接返回，省掉重复调用
v2.2.3新增ai-context-limit上下文限制插件和vLLM协议透传，AI安全防护继续加层
这套东西的价值不在单点功能，而在把密钥、限流、兜底、审计统一收到网关层——8月选型帖里大量团队头疼的"密钥散落、账单失控、日志没法审计"，正是它要解的题。
场景二：自建推理（vLLM等）
这是Higress和其他网关拉开差距的地方，证据也最硬。
6月底社区UP主"vLLM生产工程"做了一次实测：只打开Higress的缓存感知路由开关——用最长前缀匹配把相同前缀的请求送回同一个推理Pod——vLLM前缀缓存命中率从22%提升到65%，吞吐+64%，Qwen3-32B×4 Pods可复现。哔哩哔哩原理不神秘：普通轮询会把相同前缀的请求打散到不同Pod，前缀缓存白建了；缓存感知路由把它们送回同一个Pod，缓存才真正生效。对按GPU卡算成本的推理团队，"改一个路由开关换六成吞吐"值得认真看一眼。当然这是社区自测数据，上线前建议按自己的模型和负载复测。
另外，v2.2.3对接了K8s Gateway API Inference Extension，让网关开始结合后端GPU负载、队列长度参与推理调度（本次修复了InferencePool路由配置在HTTPRoute合并时丢失的问题，#3964）。知乎这个方向代表AI网关的下一步，不过能力还在持续迭代，别按"已完成"来预期。
场景三：做MCP / Agent
Higress是较早把MCP Server托管做成核心能力的网关，可以把存量REST API直接包装成MCP服务。哔哩哔哩配合Nacos 3.0，还可以搭企业级MCP市场。哔哩哔哩Dify官方插件商店也上架了Higress插件。知乎对想把存量业务系统接进Agent的团队，这能省掉自己写和维护MCP Server的工作量。
场景四：从ingress-nginx / Spring Cloud Gateway迁移
存量用户最怕的是回滚成本。Higress从v2.2.2提供nginx-rewrite-compatible插件，v2.2.3继续补迁移细节：Helm支持跳过自动创建IngressClass（不覆盖企业统一管控的资源）、保留LoadBalancer返回域名（避免DNS和自动化发布链路中断）。知乎社区层面也有快手的生产实践、Spring Cloud Gateway无缝迁移等案例。哔哩哔哩哔哩哔哩迁过来之后，AI路由、服务提供者这些高频配置都在Higress Console里可视化管理，对习惯了改ingress-nginx YAML的团队是个减负。
但要泼盆冷水：ingress-nginx的注解生态庞大，兼容插件能覆盖高频用法，却不敢承诺全覆盖。官方建议是先在测试环境渲染并对比安装结果，这一步不能省。
3类不建议选它的团队
讲完能干什么，讲不能干什么。这部分比上面更重要：
只调用一两个模型、调用量很小的团队：直连就够了。网关的价值建立在"多模型、多消费者、需要治理"上，一天几百次调用上一个接口，加网关只是多一个故障点。
没有K8s、也不想运维网关组件的团队：Higress主场在K8s（虽有单机部署形态，但运维升级仍要自己扛）。如果你的诉求是"完全不想管网关"，托管类AI网关或商业平台更合适——花钱买省心，这是合理的交易。
只需要轻量密钥代理的团队：Higress是Envoy数据面+控制器控制面+控制台的完整一套，能力全，组件也重。如果诉求只是"统一管理一批API Key、做简单路由"，LiteLLM这类轻量方案的部署成本和心智负担都更小。
结论与观察信号
决策路线可以简化成四句话：
自建vLLM推理：Higress目前最值得看，缓存感知路由和推理调度扩展是实打实的收益，建议自己复测后升级
多模型API聚合/企业Token治理：能力最全，先把消费者和配额模型想清楚再上
Agent/MCP方向：它是少数有成熟MCP网关方案的选项，Nacos用户有额外加分
纯ingress-nginx存量、没有AI流量：不用急着迁，先观察
两个值得持续盯的信号：一是Higress的CNCF Incubation进展——对选型来说，这是项目长期中立维护的分水岭；二是Gateway API Inference Extension的标准化速度，推理调度一旦成为K8s标配能力，AI网关的竞争格局会重写。
选型这事，热闹是别人的，证据才是自己的。想清楚你的团队到底要网关解决什么问题，答案其实不难。
