Higress 快速入门与扫盲：从 API 网关到 AI Gateway

如果你第一次看到 Higress，可以先记住一句话：Higress 是一个云原生 API 网关，同时把 AI Gateway 当成核心能力来建设。

它不负责“让 Agent 思考”，也不负责“把 PDF 切片做 RAG”，而是负责站在应用与后端服务 / 大模型之间，统一处理路由、鉴权、限流、负载均衡、Fallback、可观测等问题。

1. Higress 到底是什么？

Higress 是阿里开源的云原生 API 网关，内核基于 Istio + Envoy，并支持通过 Wasm 插件扩展网关能力。

传统网关解决的是：

• 请求应该转发到哪个服务？

• 谁可以访问这个 API？

• 每个用户每秒最多请求多少次？

• 某个服务挂了以后该怎么办？

• 如何做负载均衡、灰度、日志与监控？

Higress 在这些传统能力之上，又把大模型场景做成了一等公民，因此现在你会经常看到它被称为 AI Native API Gateway。

所以可以粗略理解为：

Higress = 云原生 API Gateway + AI Gateway 能力

但注意，这只是帮助理解产品定位，并不是说它真的由两个独立产品简单拼接而成。

2. 为什么 AI 时代又需要一个“AI 网关”？

普通 API 网关当然也能把 HTTP 请求转发给 OpenAI、DeepSeek、Qwen。

问题在于，大模型调用逐渐出现了一批传统 Web API 不太关心的问题：

• 一个企业可能同时接入多个模型供应商；

• 不同模型的 API 协议并不完全一致；

• 模型调用成本通常需要按 Token 统计；

• SSE 流式响应非常常见；

• 某个模型不可用时，希望自动切换其他模型；

• 不同部门、用户、Agent 需要不同的模型额度；

• 需要统一统计模型调用量、Token、延迟和错误率。

于是网关除了“转发 HTTP 请求”，还开始承担 模型治理。

例如业务代码始终调用一个统一入口：

POST https://ai.example.com/v1/chat/completions

真正的后端可以由 Higress 决定：

DeepSeek
Qwen
OpenAI
Claude
本地模型

业务侧不需要把“模型选择、Fallback、Token 限流、鉴权”全部重复实现一遍。

3. Higress 不是什么？

这是新手最容易混淆的地方。

因此：

Higress ≠ Agent 框架
Higress ≠ RAG 框架
Higress ≠ 大模型

它更像整个 AI 系统入口前面的“交通枢纽”。

4. Higress 和 Nginx、Spring Cloud Gateway 有什么区别？

Nginx

Nginx 更像一个非常成熟、通用的反向代理和 Web Server。

它当然可以承担网关职责，但 Higress 的产品目标更偏向云原生服务治理、Kubernetes、Wasm 扩展以及 AI 流量治理。

Spring Cloud Gateway

Spring Cloud Gateway 对 Java / Spring Cloud 团队非常友好，过滤器、鉴权和业务逻辑都可以直接用 Java 开发。

但它本质是 Java 网关。Higress 的数据面建立在 Envoy 体系上，更强调高性能代理、云原生控制面以及多语言 Wasm 插件。

APISIX / Kong

它们和 Higress 的产品形态最接近，都属于成熟 API Gateway 赛道。

Higress 当前一个非常明显的差异化方向，就是把 LLM、多模型代理、Token 治理、AI 可观测、MCP 等能力放到了核心位置。

所以不是“Higress 一定比其他网关强”，而是：

如果你的系统正在大量接入大模型，Higress 的能力模型会更加贴合 AI 基础设施这一层。

5. Higress 的基本架构

从概念上理解 Higress，不需要一开始就钻进 Istio 源码。

先记住两个部分：

• 控制面：管理配置、路由、策略，并把配置下发给数据面；

• 数据面：真正接收和转发业务流量。

Higress Gateway 的数据面基于 Envoy。

配置变化通过控制面下发，而不是像传统 Nginx 配置那样严重依赖 reload。对于 SSE、长连接和 AI 流式响应，这种架构尤其合适。

另外 Higress 支持 Wasm 插件，可以使用 Go、Rust、JavaScript 等语言扩展功能。

你可以把插件理解成：

请求
 ↓
鉴权插件
 ↓
限流插件
 ↓
AI Proxy 插件
 ↓
日志 / 观测插件
 ↓
后端服务

6. 五分钟快速体验 Higress AI Gateway

如果你的目标就是体验 AI Gateway，官方提供了一键部署脚本。

6.1 准备环境

需要：

• Docker

• 可以访问公网

• 至少一个模型供应商的 API Key

6.2 一键部署

官方快速开始提供：

curl -sS https://higress.cn/ai-gateway/install.sh | bash

安装过程会引导你配置模型供应商的 API Key，也可以先跳过，之后进入控制台再配置。

部署完成后访问：

http://localhost:8001

第一次进入需要初始化管理员账号。

6.3 配置模型供应商

在控制台中进入 AI 服务提供者管理，添加你的模型供应商和 API Key。

例如：

DeepSeek
Qwen
OpenAI
Azure OpenAI
豆包
...

随后创建 AI 路由，决定某个路径应该代理到哪个模型供应商。

6.4 发起请求

官方示例使用 OpenAI 风格的 Chat Completions 接口：

curl 'http://localhost:8080/v1/chat/completions' \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "qwen-max",
    "messages": [
      {
        "role": "user",
        "content": "你好，请介绍一下你自己"
      }
    ]
  }'

此时你的应用请求的是 Higress：

应用 → Higress → 模型供应商

而不是应用直接绑定某一家模型供应商。

7. 如果只是想体验 Higress 本体

Higress 也支持脱离 Kubernetes 的 Standalone 模式。

官方快速开始给出了 All-in-One Docker 方式：

mkdir higress
cd higress

docker run -d --rm \
  --name higress-ai \
  -v ${PWD}:/data \
  -p 8001:8001 \
  -p 8080:8080 \
  -p 8443:8443 \
  higress-registry.cn-hangzhou.cr.aliyuncs.com/higress/all-in-one:latest

三个端口非常好记：

开发环境使用 latest 很方便，但生产环境建议固定具体版本，避免镜像更新导致不可预期变化。

8. Higress 在 AI 系统里最有价值的几个能力

8.1 统一模型入口

原来：

业务 A → OpenAI
业务 B → DeepSeek
业务 C → Qwen

后来：

业务 A ─┐
业务 B ─┼→ Higress → 多个模型供应商
业务 C ─┘

这样模型供应商的密钥、路由和策略不必散落到每个业务系统里。

8.2 Fallback

假设主模型不可用：

DeepSeek
   ↓ 失败
Qwen

网关可以承担降级策略，而不是每一个 Agent 都自己重新写一套错误切换代码。

8.3 Token 级流控

传统限流经常是：

100 Request / Second

但 AI 请求差异可能非常大：

请求 A：100 Token
请求 B：10000 Token

所以仅按请求数限流，并不能准确反映模型资源消耗。

AI Gateway 可以进一步围绕 Token 做额度和流量治理。

8.4 AI 可观测

除了普通 QPS、延迟、错误率，还需要关注：

输入 Token
输出 Token
不同模型调用量
不同供应商延迟
模型错误率

这对于成本控制和模型选型都很重要。

8.5 流式响应

LLM 经常使用 SSE：

模型生成一点
    ↓
立即返回一点
    ↓
客户端逐字显示

Higress 官方强调对流式请求 / 响应 Body 的处理能力，这类能力对于 AI 长连接场景非常关键。

9. 一个实际的企业 Agent 架构

例如一个 Java 企业系统：

Web / App
    ↓
业务 API
    ↓
Spring AI / AgentScope
    ↓
Higress AI Gateway
    ↓
┌────────┬────────┬────────┐
DeepSeek   Qwen    OpenAI   Claude

与此同时 RAG 可能是：

Agent
  ↓
RAG Service
  ↓
Embedding Model
  ↓
Vector Database

因此 Higress 和 AgentScope、Spring AI、RAGFlow 并不是竞争关系。

它们解决的是不同层级的问题。

10. 什么情况下值得使用 Higress？

比较适合

如果出现下面几种情况，就值得重点考虑：

• 已经有统一 API Gateway 需求；

• Kubernetes / 云原生环境；

• 大量微服务需要统一入口；

• 同时接入多个 LLM；

• 希望集中管理模型 API Key；

• 希望统一做模型 Fallback；

• 需要 Token 限流与 AI 成本治理；

• 需要统一 AI 调用监控；

• 希望统一托管或治理 MCP 服务入口。

没必要急着上

如果只是：

一个 Spring Boot
+
一个 DeepSeek API Key

并且调用规模很小，那么直接使用 SDK / Spring AI 调模型可能更加简单。

不要因为“Higress 支持 AI”就强行增加一层基础设施。

网关真正产生价值的前提，是系统已经出现 统一治理 的需求。

11. Higress 应该放在你的知识体系哪里？

学习 AI 应用开发时，可以把技术栈分层：

┌──────────────────────────┐
│        AI Application    │
│ Agent / Workflow / RAG   │
├──────────────────────────┤
│     AI Development SDK   │
│ Spring AI / LangChain    │
├──────────────────────────┤
│        AI Gateway        │
│         Higress          │
├──────────────────────────┤
│      Model Providers     │
│ GPT / Qwen / DeepSeek    │
└──────────────────────────┘

Higress 位于 AI 基础设施 / 流量治理层。

理解这一点以后，就不会再把 Higress 和 Agent 框架、RAG 系统混在一起。

总结

Higress 最开始是一个云原生 API 网关，但到了 AI 时代，它的定位已经越来越明显：

在传统 API Gateway 的基础上，进一步成为企业统一的大模型与 AI 流量入口。

如果只是快速记忆，可以记住：

AgentScope / LangGraph
负责 Agent 怎么执行

RAGFlow
负责知识怎么处理和检索

Spring AI
负责 Java 程序怎么调用 AI

Higress
负责这些 AI 请求怎么统一进入、治理和转发

对于个人 Demo，Higress 未必是必需品。

但当一个系统开始出现多个模型、多个 Agent、多个部门、统一鉴权、统一限流、统一监控和统一成本治理时，AI Gateway 就会从“可选组件”逐渐变成基础设施。

参考资料

• Higress 官方：https://higress.cn/

• Higress 是什么：https://higress.cn/docs/latest/overview/what-is-higress

• Higress 快速开始：https://higress.cn/docs/latest/user/quickstart/

• Higress AI Gateway 快速开始：https://higress.cn/docs/ai/quick-start/

• AI Proxy 插件：https://higress.cn/en/docs/latest/plugins/ai/api-provider/ai-proxy/

• GitHub：https://github.com/higress-group/higress

本文依据 2026-08-14 可访问的 Higress 官方文档整理。具体功能与部署参数以后续官方版本为准。