从 API 网关到 AI 网关：当基础设施被 token 撑开

最近发现把 AI 调用接进自己业务的这个动作，越做越不像是仅仅在调一个 API。

一开始大家都把它当 API 调。前端发请求，后端拿到参数，去调一家模型厂商的接口，再把结果吐回前端。这条线从架构图上看，跟过去十几年我们调任何一个第三方接口都没有区别。一条线进去，一条线出来，中间最多过个限流和鉴权。

但很快就麻烦来了。账单的曲线开始让财务来问；同样的接口、同样的用户，延迟时长时短到没法做产品节奏；安全开始过来问用户输进去的内容你们看过吗、敏感信息是怎么拦截的；业务方又在催，说能不能把一部分流量切到另一家模型上，先看看效果。

这些问题原本一个都不在网关的视野里，它们各自发展出来，先被处理一次，再过一阵才慢慢被人意识到，它们其实是同一类问题，只是没有被集中处理。

本文想讲的就是这一点，LLM 调用这种新形态的请求，正在催生一种新的基础设施。它今天叫 AI 网关，叫什么名字其实不重要，重要的是它要解决的事情是结构性的：不是某个产品的功能，而是任何团队把 AI 接进业务之后早晚都要面对的场景。

一、调用变了形

LLM 调用从协议看是 HTTP，从形态看不是。

它的协议头还是 Content-Type: application/json，参数也还是 JSON。从七层网络的视角往里看，它跟任何一个普通 REST 接口长得一模一样。但只要稍微再往里看一下，就会发现这种调用里藏着几件传统 API 调用从来没有过的东西。

输入不再透明：普通 API 的请求体对网关是黑盒，它不需要看，也看不见。LLM 的请求体里直接写着用户的提问，里面可能含敏感信息，可能含提示注入模板，可能含越狱尝试。要不要看、要看到什么程度，本身就是一个新问题。

输出不再确定：普通 API 的响应是被代码生成的，给定输入就有给定输出。LLM 的响应是被概率生成的，同样的输入两次跑出来的内容可以完全不一样，长度可以差几倍，质量可以差更多。

成本不再均匀：普通 API 一次调用的成本基本由调用次数决定，相对稳定。LLM 一次调用的成本由 token 数量决定，而 token 数跟提问字数、上下文长度、思考深度、生成长度都有关。同一个接口、同一个用户、相邻两次调用，账单上的数字可以完全不在一个量级。

把这几点合起来看，调用从一种确定性请求，变成了一段需要被理解才能被调度的思考。

云时代的基础设施一直建立在一个很稳定的三角形之上：算力、网络、数据。每一项资源有自己的计量单位：vCPU·秒、GB·出向流量、GB·月。每一层基础设施都有合理的计量方式。token 是云时代以来第一个横跨这三个维度的新计量单位。它本身是计算（推理就是计算）、它本身是网络（每次调用都是跨域 RPC）、它本身是数据（上下文、缓存、嵌入都按 token 算）。一项资源横跨三个维度，意味着围绕旧三角形建起来的所有治理工具：容量规划、限流、配额、计费、SLO，在 token 面前都需要被重做一遍。

二、旧基础设施的假设变了

API 网关这个概念被我们用了差不多二十年。它最早不是什么独立产品，就是反向代理加上几个常用功能：路由、限流、鉴权、日志。微服务流行之后服务一多，这几个逻辑在每个服务里重写一遍既浪费时间又容易写错，于是它们被统一抽到前面一层，给了一个名字叫网关。后来网关越长越大，开始管协议转换、灰度发布、熔断降级、可观测，但这些都是同一类场景往外延伸，本质上都在管请求与响应。

它的工作模型其实很干净。请求过来，是不是这个用户、有没有这个权限、配额还够不够、要打到哪台机器、超时多少、出错怎么报，按规则判断一遍，请求就放过去；后端把响应送回来，再原路送出。整个过程是基于规则的，不需要对内容做语义理解，也不需要关心响应里写了什么。

它的全部价值，建立在一个前提上：请求和响应都是确定的、可被规则描述的、内容对网关本身透明。

这个前提让 API 网关能成为一种稳定的基础设施。它不需要懂业务，所以业务怎么变它都能代理；它不需要理解内容，所以加密的、压缩的、二进制的它都能转。从 SOAP 到 REST 到 gRPC，协议在变，但这条前提一直没变。API 网关解决的从来都是调用变多，不是调用变质。

LLM 调用同时打破了这条前提的两端。

它打破了内容对网关透明这一端：不看请求体，就路由不出来，因为同一个 /v1/chat/completions，到底该走哪个模型得看这次提问本身是什么，是闲聊还是复杂推理，是事实查询还是长上下文代码理解，是一般业务还是某个垂直领域。能力差异、价格差异都很大，不理解请求就路由不对。

它也打破了响应是确定的这一端：响应是分布出来的、长度浮动的、质量浮动的、成本浮动的，传统网关那套统一超时、按次计费、按规则切流的逻辑，对它都不再适用。

这不是需求变多，是地基松动。当一种新形态的调用同时撕开了透明和确定这两条假设，它就不再属于旧基础设施能继续延伸覆盖的范围。需要在它之上设计一层新的东西。

三、新基础设施长在旧基础设施之上

这种事在基础设施这条线上反复发生。

物理机时代有运维脚本和监控。虚拟化出来撑不住了，于是有了 vCenter、有了 OpenStack。容器出来之后 vCenter 又撑不住了，于是有了 Kubernetes。每一次都不是替代，物理机还在，虚拟机还在，容器还在。而是在原来这一层之上多了一层，专门处理新颗粒度带来的新问题。

AI 网关跟传统 API 网关之间，就是这种关系。

API 网关该干的事还在继续。一个 LLM 请求过来，仍然要被 TLS 终止、要鉴权、要做基础限流、要计入日志，这和过去没有区别，也没必要换。AI 网关管的是额外的那一部分：基于语义的多模型路由，token 计费与配额，prompt 防注入与敏感信息过滤，按上下文语义命中的缓存，以及把 token 漂移、模型可用性、调用质量纳进可观测体系。两层叠在一起，才能把一个 LLM 调用从我们能调通推到我们敢长期运行。

老牌 API 网关在加 AI 能力，比如 Kong AI Gateway、Higress AI 都是这条路；也有专门做 AI 调用治理的新公司在涌现，比如Portkey。它们出身不同，路径不同，但要解决的事情是相同的。最终谁会稳定下来还不一定，但需要这样一层 AI 网关，已经基本不需要再讨论。

退一步看，这条因果不是 AI 时代独有的。HTTP 给了 Web 一种统一的调用形态之后，才有了 WAF、CDN、Ingress 这套治理层；gRPC 给了微服务一种统一的调用形态之后，才有了 Service Mesh；任何一种新的调用形态走向成熟，都会按"协议层 → 治理层 → 入口层"三段铸型走一遍。这条路径过去发生过几次，每一次的节奏也都差不多：协议先稳定下来，治理层一两年内出现，再过一段时间被收口成统一入口。AI 网关在这个时间点开始快速发展，不是巧合，是这条路径的重演。

四、它的支点不是流量，是上下文

讲到多了一层、处理新维度，AI 网关听起来还是传统网关的延伸，好像只是多挂了几个插件。再往里看会发现，新的支点和传统网关已经不一样了。

传统 API 网关的支点是流量。它做的所有事情几乎都建立在我看到一个请求和一个响应上。限流是数请求次数，鉴权是看请求头，路由是看请求路径，日志是把请求和响应记一遍。它的视野里没有调用之间的关系，每一次调用都是独立的，前一次和这一次之间没有状态。

AI 网关的支点是上下文。它做的事情，很多都不是在管这一次请求，而是在管调用之间的状态。

举几件具体的事。缓存，传统网关只能按 URL 缓存，同一个 URL，相同的查询参数，命中。AI 网关的缓存不是这样做的，它要按上下文相似度命中，两次提问字面不同但语义上相近，第二次仍然要能复用第一次的结果。这要求网关自己得做一次理解，不能只看 URL。配额管理，传统网关数请求次数就够，AI 网关要数 token，而 token 数依赖于请求体里挂了多少上下文、模型分词大概会切成多少片，得对内容有所理解才能算。安全审计也是这样，传统网关只看请求头里的 token 和 IP 黑白名单，AI 网关要看请求体里的提示词，要识别这段提示词里有没有提示注入、有没有越狱模板、有没有把系统消息泄露出去的尝试。这些事每一件都不是在管流量，是在管上下文。

更准确地说，AI 网关其实是把上下文工程的一部分从应用层下沉到基础设施层。我们之前反复讲的上下文工程：记忆、压缩、token 预算、prompt 安全。每个团队第一次做都得自己写一遍，写到第三个团队第四个团队时，那些反复出现的部分就开始往下沉。下沉到哪？下沉到所有调用都要经过的地方，就是 AI 网关。

不是先有 AI 网关再有上下文工程，是上下文工程被反复实践之后，那些反复出现的部分自然下沉到了网关。

五、网络层开始承载思考

接住这个支点之后，再往前看一步会发现一件更不寻常的事：网关为了做出一次路由决策，得先调一次模型，路由本身就是一次推理。

这在传统网络里是不可想象的。一台 LB 要先想一下再决定怎么转发，听起来跟一个交换机要先理解 payload 再转包一样违和。但 AI 网关上这件事是常态。它不是为了好看才这么做，是因为模型之间的能力差异和价格差异都很大，不理解请求就选不对后端，闲聊问题打到顶级模型上是浪费，复杂推理打到便宜模型上是不可用，垂直领域的问题打到通用模型上效果不够。一次合理的路由决策，必须先理解请求里写了什么。

这件事不是孤立发生的，它有更长趋势。

智能网卡这几年把存储和网络的处理卸到了网卡硬件，网络硬件开始做计算。Service Mesh 把熔断、重试、可观测、流量染色都做进了 sidecar，网络层开始承载业务策略。eBPF 让网络栈在内核里直接执行业务逻辑，网络的执行能力第一次被暴露给应用。AI 网关再往前一步，网络层开始承载思考。

这条路走下来，方向是一致的。原本只负责过路的网络层，正在被反复要求理解过路的内容。从只看包头到看协议到看应用语义到看推理结果，理解的颗粒一直在往上走。AI 网关不是这条线的终点，但它是这条线第一次明显跨过内容理解这道门槛的那一站，它处理的不再是字节流也不再是请求结构，而是请求里那段思考本身。

承认了这点之后，组织上结构的麻烦也跟着冒出来。AI 网关到底归网络团队管，还是归平台团队管，还是归 AI 团队管？过去这种问题不太常出现：K8s 归平台团队，CDN 归网络团队，模型服务归 AI 团队，归属基本是清楚的。AI 网关不一样，它身上每一块责任都跨了两个团队的边界：路由治理像网络团队，配额管理像平台团队，prompt 安全又像 AI 团队。这在不同公司会有不同的解，但所有公司都会被问到。

六、它正在成为所有 token 流量的统一入口

AI 网关接下来要承担的不只是管 LLM 调用这一件事，它正在变成企业里所有跟 token 相关的流量都要经过的入口。

今天一家公司的 AI 流量大致分三股。

第一股是直接的模型调用。业务代码拼好 prompt，调一次模型厂商的接口，拿到结果用。这是最早的形态，也是大多数公司今天还停在的形态。

第二股是 MCP 流量。Agent 跑起来之后，要去调外部的工具、查外部的数据、挂外部的资源。这件事过去是各业务自己拼 RPC，现在通过 MCP 把上下文怎么组织、工具怎么暴露、资源怎么挂载这套交互标准化了下来。MCP 流量本质上还是 token 流量，它带着上下文进、带着上下文出，只是中间多绕了一道工具调用。

第三股是 Agent 内部的多步推理流量。一个 Agent 接到一个稍复杂一点的任务，内部会反复调模型、反复用工具、反复修正自己。一次外部请求可能在内部炸成很多次模型调用和工具调用。这股流量过去藏在应用框架内部，从外面根本看不见。

这三股流量过去各走各的，直接调用走 SDK，MCP 走自己的 stdio 或者 HTTP，Agent 内部那一堆调用走应用框架的事件循环。它们出身不同，跑在不同的库里，监控也是各看各的。

但只要从企业治理的视角往后退一步看，这三股流量是同一类东西：都是花一笔 token 钱去调一段思考。都得计费，都得限额，都得审计，都得监控。一家公司不可能在外部模型调用上做一套配额、在 MCP 上做另一套配额、在 Agent 内部又做第三套配额，这件事在工程上不可持续。所以它们一定会在某一层汇起来。汇到哪？汇到所有调用都绕不开的地方，还是 AI 网关。

这里要单独把 MCP 的角色讲清楚，因为它是这件事能成立的关键。

之前已经讲过，MCP 不是接工具，这是表层。MCP 真正在做的，是把 AI 调用应该长什么样标准化下来：怎么挂上下文、怎么列工具、怎么暴露资源、甚至怎么反向触发一次模型采样。这些动作过去每个框架都各自发明一套，现在被收拢到一份协议里。

形态一稳定下来，治理就有抓手了。AI 网关之所以能在调用层做配额、做缓存、做审计，是因为协议把要看的东西暴露出来了，它能看到这次调用挂了哪些工具、引用了哪些资源、上下文里大概是什么结构。没有协议层的标准化，网关层的治理是无从入手的。所以 MCP 不只是应用层协议，它同时是让 AI 网关有可能存在的前提。

MCP 和 AI 网关的关系很清楚了，它们是上下游配合，不是替代。MCP 在应用侧把上下文规整好，AI 网关在基础设施侧把规整好的上下文拿过来做治理。一个负责形态，一个负责治理，两件事咬合在一起，才有所谓的统一入口。

七、为什么必须建在企业侧

讲到这里下一个自然的问题是：这些事情，模型服务（MaaS）厂商自己做不行吗？

理论上可以。今天每家 MaaS 厂商的 API 里其实也有限流、配额、内容审核。但这些做不到 AI 网关该做的程度，原因不在技术，在三件结构性的事情上。

第一，多模型路由单一 MaaS 厂商天然做不了。一家厂商不可能在自己的 API 里告诉你这次请求你应该路由到我家友商，因为友商在这种问题上更便宜或者更好。但企业实际用 LLM 的姿势就是多家混用，便宜的活给开源模型，关键的活给头部模型，特定垂直领域用专门微调过的。这种跨厂商的路由必须发生在所有厂商之外的地方，不可能在任何一家厂商之内。

第二，token 配额、内容审计、合规这些事情，本质上是企业侧的责任，不是模型方的责任。一家公司的财务说研发部门这个月在 LLM 上的预算是多少，这个约束没法委托给模型厂商执行，模型厂商不知道你们公司有几个部门，不知道你们的预算结构，也不知道你们要怎么分摊。同样，我们公司不允许把客户身份证号传给模型这种合规约束，也不可能让模型厂商替你执行。这些约束必须在企业自己控制的那里落下来，落在调用还没出企业网关之前。

第三，模型能力还在快速演化，企业不愿意把治理逻辑和某一家厂商绑死。今年用这家明年可能换那家，今年用这个版本明年可能升那个版本。如果配额、审计、监控都建在某家厂商的 API 上，那换厂商就等于把治理体系也重建一遍，代价高到没人愿意承担。所以治理层一定会被抽出来，建在所有厂商之外。

退一步看，这件事过去发生过。公有云崛起之后，企业建了多云管理平台来对单一云厂商解耦；SaaS 崛起之后，企业建了集成中台来对单一 SaaS 厂商解耦。只要关键能力来自少数不可替代的外部供应商，企业就一定会在自己这一侧建一层对供应商解耦的基础设施。AI 网关在这条规律上的位置，本质上是模型多云的管理层。它不是技术驱动的产物，是供应商格局驱动的产物。

这也意味着，如果哪天模型能力高度收敛到一两家手里，这层会萎缩；只要模型能力分散在多家不可替代的厂商手里，这层就会一直在。它会从形态上变薄变厚，但不会被任何一家 MaaS 收编。

八、基础设施的本质特征是不确定性下沉

写到这里，可以把问题整体收一下。

AI 网关不是凭空冒出来的。它是上下文工程被反复实践之后那些反复出现的部分自然下沉的结果，是协议层稳下来之后治理层必然跟上来的结果，是模型供应商格局分散之后企业必然在自己这一侧建解耦层的结果。前面几节顺着这几条线把它讲了一遍。

但如果只能留下一个判断，那应该是这一句：这一代基础设施的本质特征，是不确定性下沉。

过去的基础设施处理的都是确定性问题。一个请求该走哪条路是确定的，一段数据该存哪里是确定的，一个服务该不该被拉起来是确定的。所有的限流、路由、缓存、监控都建立在我们知道正确答案是什么、只是要把它高效地做出来这一假设上。

AI 网关是基础设施第一次把不确定性作为头等公民引入。路由是不确定的，要先理解请求才知道走哪。输出是不确定的，要在事后才知道质量行不行。成本是不确定的，要等响应回来才知道这次花了多少。时延是不确定的，没法用单一阈值兜住。正确性更是不确定的，连什么算对这个判断本身有时候都需要再调一次模型。这些不确定性过去藏在应用层、藏在业务代码的 try/except 里、藏在产品经理那句它本来就不准的妥协里。AI 网关把它们抬到了基础设施层。

从工程师的视角看，跟当年看 K8s 是一样的。K8s 出来的时候，对工程师而言不是一个赛道、不是一个创业机会、也不是一个值不值得学的问题，它是新基础设施带来的新责任分工，逼着每一个团队回答几个新问题：哪些事情归集群管、哪些事情留在应用里、Pod 死掉之后谁负责拉起来、流量怎么进、配置怎么发、密钥怎么配。这些问题在 K8s 出来之前不是没有，而是答案分散在脚本和文档里，每个团队用自己的方式处理。K8s 出来之后这些问题被集中提出来，每个团队都得给出明确答案。

AI 网关也会提出一组新问题。哪些治理动作下沉到网关、哪些留在应用里。token 预算到底是网关算还是应用算。多模型路由的策略写在哪里、谁来维护。prompt 安全策略由网关统一执行还是各业务各做一份。出了事故责任在网关团队还是 AI 团队。这些问题在每家公司里会以不同的方式被回答，但所有公司都会面临。

放进更大的图景里，AI 网关只是软件下半场基础设施的第一站。规则化时代我们建起了一整套围绕确定性请求的基础设施：网关、负载均衡、服务发现、配置中心、可观测。token 化时代要建的，是另一套围绕不确定性思考的基础设施。AI 网关只是这套新基础设施在调用层的第一次落地，后面还会有围绕评估、监控、回放、检测的更多层冒出来，每一层都会重新提一遍同样的问题：这件事归谁管、用什么标准、怎么算责任。

软件吃掉世界的下半场，不只是应用层在变。它会一直往下传，传到调用层、传到网络层、传到我们以为最不会被这场变化波及的那些位置。