很多人把"API 网关"当成一个新名词，其实它就是把企业里"分散在各业务系统里的 HTTP 接口"，统一收口到一个中间层来治理。这个中间层的名字就是 API Gateway。
一句话本质
API 网关 = “HTTP 请求进出企业内部的统一关卡”，负责路由、限流、鉴权、聚合、监控五件事。
治理的对象只有两类：请求（Request）和凭据（Key）。把这两件事管住，就抓住了 API 网关的核心。
五件事，五种用法
| 路由 | 把请求发到正确的后端 | 用户问 “/v1/chat” 时转发到 OpenAI，问 “/v1/embed” 时转发到向量模型 |
| 限流 | 控制请求的"闸门" | 单租户每秒最多 50 次，超出直接拒绝 |
| 鉴权 | 判断"你是谁、你能调谁" | 没带 Token 直接 401，Token 没权限调用某个模型直接 403 |
| 聚合 | 一次调用合并多个请求 | 一个页面要查用户、订单、推荐三个接口，网关合并后只对外暴露一个 |
| 监控 | 记录每一次调用 | 谁、何时、用了哪个接口、用了多久、有没有出错，全留底 |
只要一个产品同时具备这五件事，它就可以叫"API 网关"。
三类典型用户
前端开发者：前端只需要知道一个入口地址（“网关地址”），不关心后端有多少服务。开发联调成本减半。
后端服务方：每个新服务只要在网关注册一下，"注册-上线"全在控制台完成，不用改客户端代码。
运维 / 财务：所有调用走网关，每次调用都有记录、有成本、有来源。月底对账时按账号拆分账单，一行代码不用写。
与"传统网关"的区别
传统 Nginx / HAProxy 的治理对象是 TCP/HTTP 字节流，按 URL 转发即可。
API 网关的治理对象升级成了业务请求——能识别用户身份、调用配额、消费金额、业务语义。
这是从"管道工"到"运营官"的跨越。
进入 AI 时代后，多了一件事：计量
大模型请求与一般 API 请求有一个根本区别——按 Token 计费。
一次调用：
- 收到用户的 prompt（1000 Token）
- 调用 GPT-4 生成回答（800 Token 输出）
- 调用 Embedding 模型把回答向量化
- 三件事涉及三个供应商、三种计费规则
普通 API 网关只会计数（“调了几次”），AI 网关必须计量（“调了多少 Token × 哪个模型 × 哪种费率 = 多少钱”）。
一个完整示例：调用一次问答发生了什么
整个流程里，网关做了 7 件事。任何一件出错（认证失败、配额超限、路由异常），整个调用立刻被拦截而不是送到后端。
给小白的三个核心要点
- API 网关就是请求进出企业内部的"总闸门"：所有调用都从这过，所有凭据都在这验。
- 五大职责固定：路由、限流、鉴权、聚合、监控，少一项就不能叫"网关"。
- 进入 AI 时代，多了"计量"这一项：因为大模型按 Token 花钱，没计量就管不住成本。
把这三件事记住，你对 API 网关的认知就超过了 90% 的非技术决策者。如果还要再深入一层，看 MAI Gateway 如何把"计量"做到 Token 级精度、再把权限做到项目级细粒度，这就是企业级 AI 网关和普通 API 网关的差距所在。
