统一接入层：AI 网关
第一个模型接进来的方式通常是在业务代码里直接调供应商 SDK，密钥写在环境变量里。这在只有一个模型、一个团队、没有合规问题的时候是完全合理的。
问题出在第二个：第二个模型、第二个团队、或者第二个合规问题出现的那一刻，横切关注点就已经存在了——鉴权、限流、预算、降级、审计、脱敏。区别只在于它们住在一个受控的控制面里，还是散落在每个调用模型的服务里各写一遍。
1. 成熟度：先认清自己在哪一级
0 级：业务代码里直接调 SDK，密钥在环境变量，一个模型，没有降级。所有横切关注点要么没有，要么各服务自己写。
1 级：抽了一个共享客户端库包住 SDK。一致性好了一些，但密钥和限额仍然住在每个部署里——轮换一次凭证要重新发布所有服务。
2 级：真正的网关代理全部流量，握着密钥，集中做限流和精确缓存。密钥的爆炸半径缩小，业务不再持有供应商凭证。
3 级：策略化路由、跨供应商熔断降级、语义缓存、按团队的预算且在线强制。供应商出故障平台仍然在线，成本不再让财务惊讶。
4 级：数据驻留感知的路由、集中 PII 脱敏与审计、实时成本台账，网关自身水平扩展且按基础设施标准做 SLO。安全与财务评审可以直接拿网关产出的证据过。
多数在 2026 年跑着多个 AI 功能的团队卡在 1 级，痛感也正好出现在 1 级的天花板上。
2. 虚拟 key：把凭证从业务代码里拿走
业务拿到的不是供应商密钥，是网关签发的虚拟 key。它绑定团队、预算、可用模型和数据分级。
这一改动的价值在轮换：供应商密钥泄露或要更换时，平台侧换掉即可，不需要重新发布任何业务服务。反过来，如果密钥散在各服务里，一次轮换就是一次全站发布。
原则很简单：网关持有凭证，应用只拿到"执行某一类请求的许可"。
3. 限流与预算必须在线强制
只统计不拦截的预算等于没有预算——它只能在钱花完之后告诉你花超了。限额要在请求路径上内联判断，超了就拒绝，并返回明确原因。
限流要按身份，不能全局一个值。一个全局上限会让某个跑批任务把生产应用需要的配额吃光（三个维度怎么分见《限流的三个维度》）。
预算的粒度也要分层：团队级防跑飞，功能级做归因，单会话级防 Agent 循环。第三层尤其重要——一次失控的多步循环可以在几分钟内烧掉一个月的额度，而它看起来只是一次普通的用户请求。
4. 降级是一次新的安全决策
这是最容易被做错的一环。供应商超时了，网关"随便找一个能用的模型"接上——这在可用性上是对的，在其他几个维度上可能是错的：新模型的数据驻留区域不同、能力不同、通过该场景评测的程度不同。
正确的要求是：降级目标必须预先登记为等价替代。没有登记过的等价目标时，应当拒绝请求或进入"无工具受限模式"，而不是降级到任意可用模型。
同样重要的是透明：响应里必须带上"实际由哪个模型服务"以及"是否走了降级"。隐藏这些信息，调试和评测就都做不了——你甚至不知道自己刚才测的是哪个模型。
5. 失败要 fail closed，并且说得清为什么
网关会拒绝请求，拒绝必须返回一个明确原因，而不是一个笼统的错误码。区分开这几类：
- 认证失败（401）
- 超限额（429）—— 说明是哪个维度超了
- 策略拒绝（模型未获批 / 区域不允许 / 数据分级不匹配）
- 预算耗尽
- 上游全部不可用且无登记的等价替代
每一类都要有对应的可观测信号。策略拒绝次数突然上升，通常意味着某个上游适配器坏了或者有人在滥用。
6. 缓存是网关策略，不是业务里随手加的 Redis
缓存看起来很香，但在多租户下它是最容易出事故的一环。缓存键必须包含租户、模型、策略版本和影响答案的参数。否则会出现 A 租户拿到 B 租户的答复，或者提示词改了之后仍然返回旧结果。
哪些能缓存也要分类：FAQ、知识库问答、分类标签这类确定性强、且不依赖实时状态与权限的任务可以缓存；涉及用户隐私、实时状态、订单处理、权限差异的请求不应当缓存。命中边界怎么划见《语义缓存的命中边界》。
同时，缓存必须被纳入"删除流程"——用户要求删除数据时，缓存里的副本不能成为漏网的那一份。
7. 流式与工具调用要单独处理
流式响应在完成之前是不完整的。 不要在收到片段时就执行高影响动作——这个片段之后可能被取消，也可能被输出校验判为不合规。
工具调用要在执行前校验。 网关要检查工具名和参数：供应商适配器不能悄悄改类型、漏掉必填字段、或者引入一个未登记的工具。每个 schema 都要版本化，并保留兼容性测试。
断连之后仍然要记账。 客户端断开不代表上游停止计费，成本核算要把"已生成但未被读取"的部分算进去（这一点在《Token 成本的三个杠杆》里展开过）。
8. 观测：最少要有这些
没有下面这些指标，后面所有优化都是拍脑袋：
请求数 / 成功率 / 错误码分布
首 token 延迟 / 总延迟
输入 token / 输出 token / 估算成本
降级次数与实际服务模型分布
按团队与功能的成本归因
缓存命中率
更完整的埋点设计见《给大模型链路装仪表》。这里只强调一点：成本必须能归因到功能和团队，否则你永远回答不了"是哪个功能花掉了这个月的预算"。
9. 网关不是银弹
说清楚它的边界，免得把不该它扛的也压上去：
它成了关键链路。 所有模型流量都过它，它的可用性、性能、扩缩容、灰度发布都要按基础设施标准来做。一个"顺手写的转发服务"是不合格的。
策略会越来越复杂。 路由、预算、限流、安全、降级全集中之后，如果没有清晰的配置模型和变更审计，网关本身会变成新的黑盒。配置要版本化，变更要有审计记录。
它不能替代业务判断。 这笔订单能不能退、这个用户有没有权限、这个动作要不要审批——这些规则最终仍由业务系统决定。网关做的是"技术策略的一致性执行"，不是业务裁决。
统一接口会抹平差异。 OpenAI 兼容格式很好用，但并非所有模型能力都能被完美抽象。某个供应商特有的参数或工具调用语义被静默丢弃，是很常见的一类 bug——遇到不支持的能力要返回受控错误，不能默默降级。
10. 最小起步顺序
不要一次拉满，按风险从高到低：
- 统一入口：所有业务只调一个内部地址，接口兼容主流风格，SDK 改动最小
- 收敛配置：租户与虚拟 key、模型与真实密钥与价格、路由与降级顺序、限流与安全与脱敏策略——四类配置先集中
- 补观测：先有指标，再谈优化
- 加治理：凭证隔离与审计 → 租户预算与 token 限流 → 超时重试降级 → 输入输出护栏 → 灰度与缓存与质量评估
什么时候该建：不是"规模大了再说"，而是第二个模型、第二个团队、第二个合规问题出现任意一个的时候。那时横切关注点已经存在，你只是在选它们住在哪里。