从 API 网关到 AI 网关：当基础设施被 Token 撑开
最近我越来越发现，把 LLM 调用接入自家产品的过程，已经不仅仅是调用一个 API 那么简单了。
虽然在形式上，依然是前端客户端发起请求、拼接参数、调用模型厂商的接口，再把结果返回给客户端。从架构图上看，这与过去十几年里我们调用的任何第三方接口并无二致：请求进去，响应出来，中间最多过一层限流和鉴权。
但很快事情就变得复杂起来：财务拿着账单过来问，为什么这个月的费用突然翻了一倍；对于同样的接口和同一个用户，有时几百毫秒就能返回，有时却要等上十几秒，导致产品经理根本无法向用户承诺稳定的体验；安全团队跑来质问，用户输入的内容你们审查过吗，敏感信息是如何拦截的；业务团队又在催促，能不能把一部分流量切到另一家模型上，先对比看看效果。
这些问题起初并不在网关的视野之内。它们冒出来时零散杂乱，被不同的团队各自解决。过了一阵回过头来看，我们才发现它们其实是同一类问题，只是一直缺乏一个统一的治理层。
这种新形态的请求，正在催生一种全新的基础设施：AI 网关。叫什么名字其实并不重要，重要的是它要解决的问题是结构性的：它不是某个产品的特定功能，而是任何团队在将 AI 接入业务时，迟早都要面对的系统性场景。
一、 调用变了形
LLM 调用从协议层面看是 HTTP，但在行为形态上却远非如此。
它的协议头依然是 Content-Type: application/json，参数也还是 JSON。如果从七层网络的视角审视，它与任何普通的 REST 接口别无二致。然而只要深入细节，就会发现这种调用隐藏着几个传统 API 从未有过的核心特征：
- 输入不再是黑盒：对于普通 API，请求体对网关而言是个黑盒，网关不需要、也无法解析其内容。但 LLM 的请求体中直接包含着用户的提问，里面可能潜藏着敏感信息、提示词注入攻击，或者越狱尝试。网关是否需要检查、检查到什么程度，本身就是一个全新的课题。
- 输出不再确定：普通 API 的响应是由代码逻辑生成的，给定相同的输入，就会得到确定的输出。而 LLM 的响应是基于概率分布生成的，同样的输入跑两次，生成的内容可能完全不同，长度可能相差数倍，质量更是参差不齐。
- 成本不再均匀：普通 API 的单次调用成本基本等同于网络流量费，相对稳定。而 LLM 的单次调用成本直接由 Token 数量决定，这与用户提问的字数、历史上下文长度、推理深度以及生成长度密切相关。同一个接口、同一个用户，相邻的两次调用，账单上的金额可能会相差几个数量级。
将这三点结合来看，调用已经不再是一个确定性的数据请求，而变成了一段需要被理解后才能进行调度的推理过程（Thinking）。
云时代的基础设施一直建立在“算力、网络、存储”这个稳定的三角形之上。每一项资源都有其独立的计量单位：vCPU-秒、GB 传出流量、GB-月。每一层基础设施都有成熟的计量与计费方式。而 Token，则是云时代以来第一个同时横跨这三个维度的新计量单位：它代表计算（推理即计算），代表网络（每次调用都是跨域请求），也代表数据（上下文、缓存、Embedding 向量都以 Token 计费）。当一种资源同时跨越这三个维度时，意味着围绕旧三角形建立起来的所有治理工具：容量规划、限流、配额、计费、SLO，在 Token 面前都需要被重新设计。
二、 旧基础设施的假设变了
“API 网关”这一概念我们已经使用了近二十年，它起初并不是独立的产品，只是反向代理加上一些常用功能：路由、限流、鉴权和日志。随着微服务的兴起，服务数量激增，如果在每个微服务中都重复编写这些逻辑，既浪费时间又容易出错。于是，它们被统一抽取到最前端，并被赋予了一个名字：网关。此后，网关的职责不断扩展，开始承载协议转换、灰度发布、熔断降级和可观测性等，但这些都是同一类场景的延伸，本质上仍在管理“请求”与“响应”。
传统网关的工作模型非常干净：请求到达，检查用户身份、权限、配额，决定路由到哪台机器，设定超时并处理错误。整个过程基于预设规则运行，无需对请求内容进行语义理解，也无需关心响应里写了什么。
传统 API 网关的全部价值，都建立在两个前提之上：请求与响应是确定性的、可被规则描述的，且内容对网关本身保持不透明（黑盒）。
正是这一前提，让 API 网关能够成为一种稳定的通用基础设施。它无需理解业务，因此可以代理任何业务；它无需理解内容，因此可以转发任何加密、压缩或二进制的数据流。从 SOAP、REST 到 gRPC，协议在演进，但这个前提从未改变。传统网关关注的是如何承载更多的调用，而非管理不同的调用。
而 LLM 调用的出现，彻底打破了这一长久的平静：
- 内容无法再对网关保持不透明：如果不解包检查请求体，网关就无法进行正确的路由决策。因为面对同一个
/v1/chat/completions接口，到底该将流量分发给哪家厂商、哪个级别的模型，完全取决于用户 Prompt 的语义本身。网关必须理解请求内容才能完成路由。 - 响应也不再具有确定性：LLM 的响应来自概率分布，长度是浮动的，质量是浮动的，成本也是浮动的。传统网关所依赖的统一超时阈值、按次计费模式以及简单的权重切流逻辑，在 LLM 响应面前纷纷失效。
当一种新形态的调用同时打破了“内容黑盒”与“行为确定”这两个基本前提时，它就不再是旧基础设施通过常规修补所能解决的了。我们必须在它之上，构建一层全新的机制。
三、 新基础设施长在旧基础设施之上
在基础设施的历史中，这种在原有层之上构建新机制的演进曾反复上演：虚拟机没有干掉物理机，而是叠加了虚拟化管理层；容器没有干掉虚拟机，而是叠加了容器编排层。每一次演进都不是简单的替代，而是为了解决新粒度资源带来的新挑战。
AI 网关与传统 API 网关之间，也是这种继承与叠加的关系。
传统网关原有的职责一项都没有减少：TLS 终止、身份鉴权、基础限流和日志记录依然留在原地。而 AI 网关则在此之上，延展出了专属大模型的治理能力：基于语义的多模型路由、Token 级别的计费与配额管理、Prompt 注入防御与敏感信息过滤、基于上下文语义命中的缓存，以及将 Token 消耗、模型可用性和调用质量纳入可观测性体系。两层叠加，才能完整地代理和治理一个 LLM 调用。
如今，老牌 API 网关正在积极增加 AI 功能（如 Kong AI Gateway、Higress AI），而专门做 AI 调用治理的新兴初创公司也在迅速崛起（如 Portkey）。尽管出发点不同，但它们指向的痛点完全一致。
拉长时间维度来看，这并非 AI 时代的特有现象。任何一种全新的调用形态走向成熟，都会经历从协议标准化到治理与入口化的演进——正如 HTTP 的普及演进出了 WAF 和 CDN，微服务架构下内部调用的规范化演进出了 Service Mesh。AI 网关在当下的爆发，不过是这一网络演进规律的又一次重演。
四、 网络层开始承载思考
到目前为止，AI 网关听起来似乎仍只是传统网关的延伸，像是多挂了几个插件。但真正拉开两者时代距离的，藏在它日常执行的动作之中。
传统网关的全部关注点都在流量上，其行为几乎完全基于“单次请求与响应”的孤立视角：限流是通过数请求次数，鉴权是检查 Headers，路由是匹配 URL 路径，日志则是记录请求与响应的元数据。在它的视野中，请求体是一个不需要、也无力去探知的灰色地带。
而 AI 网关的核心关注点转移到了 上下文(Context) 上。这带来两层本质的变化：
第一层变化是：网关必须解包并读取请求体。 * 语义缓存：缓存不再通过匹配 URL 实现，而是基于语义相似度。即使两次提问字面不同，只要语义相近，第二次就应当复用第一次的结果。这需要网关通过 Embedding 将请求体向量化并进行相似度检索，如果不打开请求体，这一切都无从谈起。 * Token 配额管理：配额管理不能再靠计算请求次数，而必须计算 Token 数。这需要网关运行 Tokenizer 对整个请求体分词，计算上下文长度并评估成本，这也必须解包请求体。 * 安全审计与防御：安全审计不能只看 IP 或 Auth Token，而必须审查 Prompt 文本，利用规则或轻量级模型来检测是否存在提示词注入、越狱模板，或者窃取系统提示词（System Prompt）的企图。
向量检索、分词、模式匹配，这三项技术的手段各异，但共同的前提是：网关必须解包读取请求体。这是传统网关从不做、而 AI 网关必须做的事情。
第二层变化更为深刻：网关自身必须先运行一次推理，才能决定请求的流向。 这主要体现在“意图路由（Intent Routing）”上。在实际业务中，企业通常会混合使用多种模型：简单的日常闲聊分流给轻量小模型，复杂的逻辑推理交给顶级大模型，代码问题路由给代码专用模型，垂直领域任务打给特定的微调模型。
这种路由决策是无法通过 HTTP 报头或字面关键词来判断的，网关必须先理解这次提问到底属于什么意图。而意图分类本身就是一次模型推理（通常是一次轻量小模型的分类调用）。网关为了做出一次路由决策，必须先对自己发起一次推理请求。
这在传统网络架构中是不可想象的。一台负载均衡器（LB）在转发数据包前需要先思考一下，听起来就像交换机必须读懂 Payload 才能转发报文一样违和。但对于 AI 网关，这已是常态。因此，网络设备不再仅仅是流量的搬运工，它自己也成为了推理链条（Inference Chain）上的关键一环。
原本只负责过路的网络层，被要求理解过路的内容。从仅看包头，到解析协议，再到理解应用层语义，直至自己运行推理，其理解的粒度不断攀升。AI 网关或许不是这条演进曲线的终点，但它是网络层首次跨越内容语义理解门槛的里程碑，它处理的不再是字节流或结构化请求，而是请求中蕴含的思考本身。
五、 它正在成为所有 Token 流量的统一入口
AI 网关的职责将不再局限于单一的 LLM 接口代理，它正演变为企业内所有与 Token 相关的流量必须流经的统一入口。
当前，企业的 AI 流量主要由三部分构成： 1. 直接模型调用：业务代码组装 Prompt，直接调用大模型厂商的 API 换取结果。这是最基础、也是大多数企业目前所处的阶段。 2. MCP（Model Context Protocol）流量：当 Agent 运行起来后，需要调用外部工具、查询数据库或加载外部资源。过去，这需要各业务团队自行编写 RPC 对接逻辑；现在，MCP 将上下文组织方式、工具暴露方式以及资源挂载方式进行了标准化。MCP 流量本质上仍是 Token 流量，上下文输入，上下文输出，只是中间穿插了工具调用。 3. Agent 内部的多步推理流量：Agent 在执行复杂任务时，会在内部进行反复的自我修正、模型调用和工具调用。一次外部的用户请求，在内部可能会裂变为数十次细碎的模型与工具交互。这部分流量过去隐藏在 LangChain、LlamaIndex 等应用框架内部，从基础设施层来看是一个黑盒。
过去，这三股流量各自为政：直接调用走 SDK，MCP 走 stdio 或 HTTP，Agent 内部调用则受控于应用框架的事件循环。它们依赖不同的类库，监控指标也支离破碎。
然而，如果从企业治理的视角出发，这三股流量的本质完全一致：都是通过消耗 Token 来换取推理和思考能力，它们也同样需要审计、限流、计费和合规监控。企业不可能在直接调用上做一套配额，在 MCP 上做另一套限制。这在工程上是不可持续的灾难。因此，这些流量必然会收拢到整个调用链路的必经之路：AI 网关。
这里需要特别指出 MCP 的关键角色：
MCP 不仅仅是连接工具的手段，它深层的意义在于标准化了 AI 调用的契约：规定了如何附加上下文、如何声明工具、如何暴露资源、甚至如何反向触发模型采样。过去，每个应用框架都在各自造轮子；而 MCP 将其收拢为统一协议。
契约一旦标准化，治理便有了抓手，AI 网关之所以能跑通配额、缓存和审计，是因为 MCP 协议将需要治理的要素（调用了哪些工具、引用了哪些资源、上下文大致结构）向基础设施层敞开了。没有协议层的标准化，网关层的统一治理就无从谈起。因此，MCP 不仅仅是一个应用层协议，更是 AI 网关能够发挥治理威力的基石。
MCP 与 AI 网关是典型的上下游咬合关系：MCP 在应用侧将上下文规整化，AI 网关在基础设施侧对规整后的上下文执行治理策略。两者配合，才构成了企业 AI 流量的统一入口。
六、 为什么必须建在企业侧
一个很自然的问题是：这些治理工作，模型即服务（MaaS）厂商自己在云端做不行吗？
从技术上讲，厂商确实可以提供限流、配额和基础的内容审核。但他们永远无法替代企业侧的 AI 网关，这源于三个深层次的结构性因素：
- 多模型路由是厂商的天然盲区：没有哪家模型厂商会在自己的 API 中告诉你：针对这个具体的请求，你应该用我们竞争对手的模型，因为他们更便宜也更好用。然而，企业真实的 LLM 使用策略必然是多模型混用，将基础任务派发给开源模型，核心逻辑交给顶级闭源模型，特定场景路由给垂直领域微调模型。这种跨厂商的动态分流，必须发生在所有厂商之外的独立治理层。
- 合规与预算是企业不可推卸的内部责任：例如，财务团队规定研发部门本月在 LLM 上的预算总额是 5 万元。这种约束无法委托给外部模型厂商执行，因为厂商不了解企业的部门组织架构与预算分配机制。同理，禁止将包含客户身份证号等隐私信息的 Prompt 发送给外部模型这类数据出境合规约束，也必须在请求离开企业内网、进入厂商接口之前被强行拦截并脱敏。
- 避免供应商锁定（Vendor Lock-in）：目前大模型能力仍在以极快的速度演进，企业今年选择厂商 A，明年可能就转向了厂商 B。如果配额、审计、可观测性等治理逻辑直接构建在某家特定厂商的 API 之上，切换供应商就意味着重建整套治理体系，其迁移成本将高到无法承受。因此，治理层必须解耦并独立于所有厂商之外。
从历史的镜子中看，这种博弈反复发生：公有云崛起后，企业为了避免被 AWS 或阿里云绑定，建立了多云管理平台（CMP）；SaaS 普及后，企业构建了集成中台。只要核心能力来源于少数不可替代的外部供应商，企业就必然会在自己这一侧建立一层用于解耦的基础设施。AI 网关，本质上就是大模型多云时代的企业侧管理层。它是由市场和供应商格局决定的，而不仅仅是技术驱动的产物。
这也意味着：只要模型能力依然分散在多家各有长短、不可相互替代的厂商手中，这层基础设施就会长期存在，并不断完善。
七、 基础设施的本质特征是不确定性下沉
AI 网关并非凭空出现，它是上下文工程在实践中被反复提炼、进而将共性部分自然下沉的产物，是接口与协议（如 MCP）标准化后治理层必然跟进的产物，也是在模型供应商分散的格局下，企业为了自保和解耦在自身网络边界建立的防护层。
如果整篇文章只能留下一句核心断言，那应当是：这一代基础设施的本质特征，是不确定性下沉（Non-determinism pushed downward）。
传统基础设施解决的都是确定性的问题，一个请求该打到哪个节点是确定的，数据写入哪个磁盘是确定的，服务健康检查是否通过是确定的。过往所有的限流、路由、缓存和监控，其底层逻辑都默许着一个前提：我们知道正确答案是什么，基础设施的工作只是高效率、高可用地去执行它。
而 AI 网关，则是基础设施层首次将“不确定性”作为一等公民（First-class citizen）引入： * 路由是不确定的：必须先对请求进行意图识别才能决定路由； * 输出是不确定的：必须在响应生成之后才能去评估其质量与合规性； * 成本是不确定的：只有响应返回之后，我们才能确认最终消耗的 Token 账单； * 时延是不确定的：流式传输和推理深度的不同，导致传统的单一超时阈值（SLO）彻底失效； * 正确性更是不确定的：在非确定性系统中，连什么叫答对了这个判定本身，可能都需要再调用一次小模型来评估。
这些不确定性过去隐藏在应用层，散落在业务代码的 try/except 捕获中，或者是产品经理无奈妥协的那句模型有时候就是这样。现在，AI 网关将这些不确定性直接搬到了基础设施层。
放眼更宏大的图景，AI 网关只是软件吞噬世界下半场中，基础设施演进的第一站。在规则化编码时代，我们围绕着确定性请求建立起了一整套成熟的设施：网关、负载均衡、服务发现、配置中心和可观测性体系。在 Token 化的生成式时代，我们需要建立起另一套围绕着“非确定性思考”的全新基础设施。AI 网关只是这套新设施在调用与入口层的初步落地，在其后，围绕大模型评估（Evaluation）、安全对抗、流量回放、实时监测等更深层级的治理基础设施正陆续浮出水面。每一层都会把同样的问题重新抛给我们：这件事由谁管、标准是什么、责任怎么算。
软件吞噬世界的下半场，改变的仅是应用层。它正裹挟着无可阻挡的力量一路下沉，漫过接口层，浸入网络层，一直传导到那些我们曾以为最稳定、最不会被波及的底层物理边界。