AI网关听起来像个路由器：选择模型，在某个模型宕机时切换到备用，然后退到一边。这恰恰是网关最不值一提的功能。

它真正要做的是治理——成本控制、安全、审计。路由只是清单上的一项，远非头号任务。这篇文章会展开这四个方面，并给出每个控制点背后的具体配置。

打开网易新闻 查看精彩图片

设想一家公司，有五个服务直接调用大语言模型：一个客服机器人、一个RAG管线、一个内部LangGraph智能体、一个夜间批量摘要程序，还有一套面向客户的聊天功能。没有网关，每个服务各自对接模型供应商。

这意味着：每个服务都保存着自己那份供应商API密钥，批量摘要程序泄露一次，就是整个预算的泄露。限流和重试策略全看各团队心情，通常意味着“零”直到第一次事故出现。没人能实时看到花费，财务发现某个失控的智能体时，已经是收到账单的节点，而非凌晨两点它开始狂烧token的那一刻。PII扫描靠各团队的土规矩，有的团队会清理，有的不做，而且没人对什么是敏感数据达成过共识。日志记录至少存在五种格式，如果确实有记录的话。

这不是同一个问题重复了五次，而是五个都有问题、都只做了一半的残缺版本。拿到审计人员面前，没有一个经得起检查。

把这些混乱压缩到一个控制平面。一个网关，让所有服务通过OpenAI兼容接口与它对话，所有规则在请求抵达供应商之前就在这一个盒子里强制执行。下面四个控制全部内置其中。我用LiteLLM作为代理，贯穿所有控制点的主题是：不要重复建设平台已经擅长的能力，只需正确接线并让它生效。

第一个控制点是真正以token而不是请求次数来计量成本的治理。普通的API网关只会数请求量。对大语言模型来说，这是用错了单位，而且错得代价高昂。一个十个单词的提示和一趟烧掉上万token的智能体操作，都登记为“一次请求”，花费却天差地别。要控制开支，就要追踪token。

而且不能只盯着一个全局数字，要按身份统计：每个API密钥、每个团队、每个客户。一个全局计数器只能告诉你船在下沉，却说不清哪个舱室进水。

所以设计是层级预算：团队预算是真正执行限制的单位，每个用户都隶属一个团队。团队之上汇总到组织/客户预算。请求在触碰供应商之前，如果任一层级超支，就会被拒绝。用户作为身份依然存在，支出会归属到具体个人（控制点4的审计链条需要它），但用户层级没有预算强制，这是有意为之。LiteLLM只会在用户不属于任何团队时才执行用户自己的预算，因此对于任何有团队的用户，用户层级预算形同虚设。真正起约束作用的层级是团队，然后是组织。用户只负责归属。

预算按固定窗口重置，具体的配置可以在代理中以极简方式定义。通过这种设计，平台不再只是被动转发请求，而是变成了一个能够主动截断异常开支的治理层，让成本管控不再依赖事后对账单的恐慌。