开头从读信到看这封信怎么被拆上一篇结尾我说AI 网关的核心是拆开信封读信的内容。后台又有人问了“那这封信从进来到出去网关到底对它做了什么”这是个好问题也是理解 AI 网关的钥匙。因为我发现一个有意思的现象很多人能说出网关有哪些能力限流、路由、缓存、计费但真要回答一个请求进来后这些能力是按什么顺序、在哪一步被触发的就说不清了。这一篇我就带你把一个 AI 请求的完整生命周期走一遍。我会用流水线这个比喻来组织——你可以把网关想象成一条加工流水线请求就是一件在流水线上流动的半成品每一站有一个工人插件对它做一个固定的动作。走完这一遍你再看网关的配置、日志、排障心里就有谱了。提前说明这一篇是概念理解级别我不会贴源码只讲发生了什么、按什么顺序、为什么。源码级的细节我会放在后面几篇单独展开。一、先建立一张全景图一个 AI 请求在网关里的旅程概括起来就是六个站① 接入请求进来② 协议识别这是哪家的格式?③ 加工提示词被改写④ 限流与计费token 够不够?⑤ 转发送去真正的模型⑥ 观测记录与统计响应原路返回这六站分别回答了六个问题站名称它回答的问题①接入请求进来了先放谁手上②协议识别这请求走的是哪家模型的格式③加工要不要在送出去前改写提示词④限流与计费这个请求的 token 用量超没超预算⑤转发到底送给哪个模型实例⑥观测这一路发生了什么花了多少钱下面一站一站走。二、先说一个贯穿全程的概念插件接力在讲六站之前必须先讲清一个概念——插件接力。因为它决定了网关里的能力是怎么被组织起来的。网关本身不写死先限流、再转发这种流程而是把每个能力做成一个独立的插件然后给每个插件标一个优先级数字。请求进来后网关会把这个请求依次交给按优先级从高到低排好队的插件们每个插件只做自己那一件事做完交给下一个。打个比方这就像一条流水线上的工人每个人只负责一道工序。工人之间不互相指挥靠的是传送带的固定顺序——而这个顺序就是插件优先级。请求 → [优先级最高的插件] → [次高] → ... → [最低] → 上游模型为什么用插件接力而不是写死流程因为这样灵活。你今天想让某个能力早点执行比如先鉴权再计费只需要调一下优先级数字想加个新能力就新写一个插件插到队列里不用改整体流程。但灵活是有代价的这个代价我放到最后的踩坑部分说。三、六站逐一拆解第①站接入——先搞清楚谁能进来、从哪进来请求到达网关的第一件事不是处理业务而是接入层的活儿鉴权、判断请求该走哪条路由。这里的路由回答的是这个请求的 URL 对应到哪个服务配置。传统网关在这一站就已经开始干活了AI 网关在这一站和传统网关没有本质区别——都是看信封。这一站通常很快因为它只碰 URL、Header、API Key 这些元数据还没到拆信读内容的时候。第②站协议识别——先搞明白这封信是用哪国语言写的这一站是 AI 网关真正开始拆信的地方。请求体进来了网关要做的第一件事是判断这个请求走的是哪家模型的格式是 OpenAI 风格Anthropic 风格还是 Bedrock 风格为什么必须先做这件事因为后面所有的加工第③站和转发第⑤站都取决于你面前的是什么格式。读不懂格式后面的工人都没法下手。这里有个有意思的细节协议识别是按顺序试探的。网关会拿着一组特征请求体的字段结构、URL 路径、Header 里的特定标记从最专一的协议一路试探到最通用的兜底协议。识别对了就打个标签全都没认出来就走一个passthrough透传的兜底分支把请求原样放过去不加工。第③站加工——请求送出去前被改写过识别出协议、能读懂请求体之后就来到了 AI 网关最独特的一站加工提示词。这一站做的事传统网关完全做不了。它回答的是“在把这个请求交给模型之前我需不需要改写它的 messages”典型的有几种套模板团队的提示词不是写死在业务代码里的而是存在网关侧。业务只发一个模板 ID 和几个参数网关在运行时把参数填进模板拼成完整的提示词。这样提示词可以统一管理、统一升级。加装饰比如统一在系统提示词里追加你是公司的客服助手这类背景设定不用每个业务都写一遍。填历史多轮对话时网关从缓存里把之前几轮的对话捞出来自动拼到请求里让模型记得上文。压上下文如果历史对话太长、逼近模型的上下文窗口网关会先做一轮压缩比如让一个小模型先摘要再拼进去。你会发现这一站是所有 AI 网关能力的灵魂所在——因为网关第一次真正读懂并改写了信的内容。第④站限流与计费——决定这请求配不配被放行加工完之后请求还没出发先过一道成本闸门。这一站要回答这个请求的 token 用量有没有超过预算上一篇文章讲过AI 网关的限流是按 token 算的。所以这一站要先估算出这个请求大概消耗多少 tokenprompt token 是估算的completion token 要等响应回来才知道再和它所属团队/应用的预算配额比对。没超放行超了要么拒绝要么降级。这里有个关键这一站是有状态的——它需要查配额、更新计数而不是简单地数一数请求。这也是它比传统网关限流复杂的地方。第⑤站转发——真正把请求送出去过了闸门终于轮到把请求发给真正的模型了。但发给哪个模型不是拍脑袋定的这一站要做的是模型路由与负载均衡这个服务配置背后绑定了哪些模型实例如果有多个实例按什么策略选一个轮询按健康度按成本如果首选模型挂了或超时要不要自动切换到备用模型选好目标之后网关做一次真正的协议转换——把内部统一格式翻译成目标模型那家的格式然后把请求发出去再把模型的响应尤其是流式响应原样、增量地透传回客户端。第⑥站观测——这一路发生的事都要留下账本请求和响应都走完之后最后一站是观测。这一站不是请求结束后补记一笔而是贯穿全程的从接入到转发每个环节都在往日志、指标里写数据。最后要能回答这次请求走了哪条路、被哪些插件改过消耗了多少 prompt token、多少 completion token按模型单价算这次调用花了多少钱归到哪个团队这些数据最后会被聚合起来形成每日成本、每团队用量这类报表。没有这一站前面几站做的事都是黑盒——你能用但你看不见。四、用一张时序图看完整链路为了让你有个全局感我拿一个具体的场景——“带提示词模板的多轮对话请求”——画一张时序图。这个场景会把上面六站几乎都串起来模型实例历史缓存网关客户端模型实例历史缓存网关客户端① 接入请求 API Key② 协议识别判断是 OpenAI 格式③ 加工套用提示词模板③ 加工拉取历史对话返回历史记录③ 加工拼接历史 压缩(如超长)④ 限流估算 token比对预算⑤ 转发选择健康模型实例⑤ 转发协议转换后发送流式响应增量返回流式透传增量返回⑥ 观测统计 token、成本、日志这张图里有一个细节值得你留意响应不是等模型全部输出完再一次性返回的而是边收边发的流式透传。网关在⑤站收到模型的增量输出立刻转发给客户端最后才在⑥站做统计收尾。这个流式的细节是 AI 网关和传统网关在工程上差异最大的地方之一我后面会用一整篇专门讲。五、踩坑与边界这条流水线的真实代价讲完原理照例说说我交过学费的地方。坑一请求被多个插件接力修改排障极难这是插件接力这种设计的最大代价。一个请求在③站可能被套模板→填历史→压上下文连续改了三次到了线上如果模型说出来的话不对劲你很难一眼看出是哪一站、哪个插件把提示词改坏了。我们踩过的真实场景是模型突然开始答非所问排查了半天最后发现是某次升级把压缩上下文的优先级调到了填历史之前——先压缩再填历史把刚压缩过的内容又拼了一遍旧历史提示词直接乱了。所以可观测性⑥站不是可选项是必须项。一定要让网关记录每个插件进来时请求长什么样、出去时变成了什么样否则排障就是大海捞针。坑二每一站都有延迟链路越长越明显流水线每多一站请求就要多停留一点。特别是③站加工和④站限流计费它们要读 body、解析、估算 token都是有开销的。如果你把一个请求配上了十几二十个插件累积的延迟会非常可观。我们的经验是插件不是越多越好只在真正需要的链路里启用。一个纯转发、什么都不加工的轻量路由就别套一长串加工插件。边界不是所有请求都需要走完六站要特别说清楚这六站不是每个请求都必须全走一遍的固定流程。实际情况是轻量请求比如一个简单翻译可能只走 ①→②→⑤→⑥跳过加工和限流重量请求长上下文、高成本才会把 ③④ 这些语义治理站都走全。这正是插件接力设计的好处按需启用而不是一刀切。理解了这一点你在配置网关时心里就有一个这个请求该走几站的清单了。结语这一篇我带你走完了一个 AI 请求在网关里的六站旅程接入 → 协议识别 → 加工 → 限流计费 → 转发 → 观测。如果说上一篇讲的是网关读的是信的内容那这一篇讲的就是网关怎么一步步读、怎么一步步改、怎么一步步记。到这里你已经理解了网关内部在做什么。但还有一个更麻烦的问题没解决——上一篇我埋过一个伏笔网关要读懂请求前提是它能识别出请求走的是哪家协议的格式而这几家协议的格式互相不兼容。下一篇我就专门讲这个——多协议的世界到底乱在哪网关又是怎么用协议无关层把这个乱摊子收拾起来的。