为什么直连三方模型 API 在企业中不可行？
直连方式存在几个严重缺陷：各个项目组重复申请 Key 导致费用失控、单一供应商宕机时缺乏无缝容灾能力、员工误操作可能将高价值内部源码直接发送给公共模型。
AI Gateway 的五大核心能力组件
- 智能多模型路由与熔断：当主力模型（如 Claude 3.5 Sonnet）出现 5xx 错误或限流时，网关在 100ms 内自动平滑重试降级至 DeepSeek-V3 或 GPT-4o；
- 统一 MCP 权限代理：所有针对企业内部数据库或生产集群的 MCP 请求必须经过网关的 RBAC 鉴权与审计日志打标；
- 租户配额与 Token 实时记账：按部门、项目与员工维度统计 Token 消耗并实施软硬配额告警；
- 企业合规与敏感词防火墙：在双向数据流中实时过滤内部 IP、密钥与涉密商业机密。
落地示例：分三阶段收敛直连调用
第一阶段是盘点。把散落在各仓库的模型端点与工具端点列成清单，标注调用方、月度 Token 量级、是否携带内部数据。仅这一步就能暴露重复申请 Key 的问题。
第二阶段是旁路接入。网关先以透明代理模式部署，只做转发、日志与计量，不改任何业务代码，观察一到两周，确认审计字段完整后再启用配额与路由策略。
第三阶段才真正切流。按团队灰度，客户端只需把 Base URL 指向网关，模型名与请求参数保持不变。路由与策略建议写成配置纳入版本管理：
# 示意结构，实际字段名以所选网关产品的规范为准
listeners:
- path: /v1/chat/completions
upstreams:
- name: primary # 主力模型
weight: 80
- name: fallback # 兜底模型
weight: 20
policies:
- token-quota # 按租户记账
- outbound-redaction # 出站脱敏
集中式网关与直连的取舍对比
| 决策点 | 集中式网关 | SDK 直连加本地重试 |
|---|---|---|
| 密钥管理 | 单点托管，轮换成本低 | 分散在各仓库，泄漏面大 |
| 故障切换 | 统一降级策略，秒级生效 | 每个团队各自实现 |
| 成本可见性 | 天然聚合到部门维度 | 需额外埋点统计 |
| 请求延迟 | 多一跳转发 | 无额外开销 |
| 运维投入 | 需要平台团队长期维护 | 几乎为零 |
通常的判据是：调用方超过三个团队，或者存在生产数据出站风险时，治理收益会盖过那一跳延迟；只有一个实验脚本时，直连更划算。
上线前必须做的四项验证
注入上游 5xx 与超时，确认降级链路真的生效而不是只写在配置里；用超长上下文触发配额，确认返回的是明确限流错误而非静默截断；从审计日志反查一次调用的入站出站内容是否已被脱敏；月底把网关统计量与供应商账单对账，偏差要能逐项解释。四项全过才适合继续扩大接入范围。
常见故障速查
| 现象 | 原因 | 处理 |
|---|---|---|
| 降级后回答风格漂移 | 兜底模型未复用同一套提示模板 | 在网关侧统一注入并做回归比对 |
| MCP 调用被随机拒绝 | 工具名单与角色权限不同步 | 以注册表为唯一事实源刷新策略 |
| 配额告警明显滞后 | 记账走异步批量落库 | 改为同步计数或缩短聚合周期 |
| 流式输出中途断连 | 网关空闲超时短于任务时长 | 调大读超时并保留心跳帧 |
| 网关统计与账单不符 | 未计入重试与工具回传 Token | 把重试次数与工具结果一并记账 |
小结
判断网关是否真的落地，不看有没有部署，而看三个可验证的问题：任一模型供应商今天故障，业务能否不发版继续运行；任意一次工具调用能否在审计里追到具体的人和用途；月底账单能否拆到部门粒度。三问都为"是"，架构才算成立。想先摸清团队在用什么模型与工具，可以从 /mcp 与 /blog 目录开始整理清单，再决定网关要拦什么。