一个已经接了 OpenAI 的项目，为什么我后来还是补了统一模型网关

项目最开始接大模型的时候，我的想法很简单：先接 OpenAI，把功能跑起来，别一上来搞太重。

这个思路在前期是对的。因为业务还没验证清楚，过早搞复杂架构，很多时候是在给自己加戏。

但项目往后走了一段时间，我开始明显感觉到一个问题：模型接入这件事，表面上像是“调 API”，实际上很快就会变成“治理接口层”。

最开始只接一家模型的时候，代码真的很干净。可一旦开始考虑这些问题，复杂度马上就上来了：

• 想接第二家模型做效果对比
• 某条线路不稳定时想加主备
• 想把不同业务的调用额度分开
• 想知道某次失败到底是业务问题还是模型问题
• 想让 Dify、Cursor、内部工具都共用一套模型入口

这时候如果继续在业务层里硬接，就会进入一种“短期省事，长期越来越乱”的状态。

我后来换了个思路：不要把“模型调用”当成一个 SDK 问题，而是把它当成接口治理问题处理。

也就是说，在业务系统和模型供应商之间，加一层统一模型网关。它不负责你的业务逻辑，但把这些原本分散的问题集中起来：

• 多模型统一接入
• 路由和主备切换
• Key / 额度 / 白名单管理
• 流式输出和文件处理
• 请求追踪和排障

我比较在意的一点是，这层最好别要求业务重写太多东西。因为一旦迁移成本太高，团队通常就会拖着不改。

所以我后来更偏向用兼容 OpenAI / Anthropic 协议的方案。这样原来的项目很多时候只要改：

• Base URL
• API Key
• model

就能先把调用迁过去。

这个收益在项目还小时不一定特别明显，但只要你开始接知识库、工作流、Agent、代码助手，或者同时要照顾多个上游模型，这层价值会越来越大。

我自己的体感是：单模型阶段追求“先跑起来”没问题，但只要往生产环境走，统一网关这一层早晚得补。越晚补，业务耦合越深，后面改起来越难。

如果你现在也正好处在“已经接了 OpenAI，但后面模型越来越多，治理越来越乱”的阶段，可以自己试试这种做法。我最近整理的入口放这里，想少折腾的话可以直接看看：

连连智枢

不是说它能替代业务设计，而是把模型接入这一层先收拢住，后面你做扩展会轻松很多。

如果大家感兴趣，我下一篇可以直接写代码版，拆一下“已有项目怎么只改 3 个参数迁过去”。