照着 MAI Gateway 和 CC Switch 的配置资料做了一次接入走查。最明显的变化，是供应商 Key、项目权限、模型映射和费用归属终于可以分开处理。本文记录具体接法，也把容易踩的坑写清楚。

这不是一篇生产环境性能测评。我做的是配置资料走查和接入演练，文中的地址、Key 都是占位符，没有拿虚构数据冒充真实客户效果。

事情是从一份 Codex 配置说明开始的。

我原本以为，接企业 AI 网关无非是把原来的 API 地址替换一下。结果照着流程走到第三步，我发现真正该先处理的不是地址，而是 Key。

这边接入的网关是魔芋企业AI网关，MAI Gateawy。魔芋AI大模型网关I全球大模型一站式调用及服务平台

很多研发团队接 AI 编程工具时，路径都差不多。某个同事先申请一把供应商 Key，复制到自己的电脑里。后来大家觉得好用，这把 Key 又被塞进 CI、测试机和几个脚本。模型需要切换时，再申请第二把、第三把。

接口能跑，账也能扣。

只是半年后没人敢轮换第一把 Key，因为谁也说不清它还藏在哪台机器里。

这才是问题。

我最后只给 Codex 留了三项配置

在 MAI Gateway 的接法里，上游模型供应商的 Key 由网关保管。研发工具拿到的是网关签发的企业令牌。对兼容 OpenAI 接口的应用，常见改动可以收敛成三个字段。

base_url = "https://gateway.example.com/v1"
api_key  = "mai_project_token_xxx"
model    = "codex-default"

这里的 model 最好不要直接写死某家供应商的具体版本。我更愿意给业务侧一个稳定的模型别名，例如 codex-default、code-fast 或 code-review，再由网关把别名映射到实际模型。

这样以后更换渠道、做主备切换或者让一部分请求去新版本，主要调整网关配置。代码仓库不用跟着每次搬家。

但有个细节不能糊弄。模型别名只能屏蔽名称差异，屏蔽不了能力差异。上下文窗口、工具调用、思考参数、图片输入和流式返回是否兼容，仍然要逐项测试。

一个统一地址，不等于所有模型突然长得一模一样。

我是怎么走完这次配置演练的

我先在 MAI Gateway 里单独建了一个用于 Codex 的项目令牌。名称里写清环境和用途，例如 codex-dev，再确认可用模型、有效期、权限范围和访问来源。

单独建令牌看起来多一步，后面排障会轻很多。调用异常时，可以只停 Codex 这条链路，不用把同项目的客服机器人或批处理脚本一起掐掉。费用明细也能落到具体工具，而不是所有研发调用挤在一把公共 Key 上。

接着回到 CC Switch，在 Codex 页签选择自定义供应商，填入刚生成的企业令牌和 MAI Gateway 的 OpenAI Response 兼容地址。配置资料里的正式环境地址以 /v1 结尾，实际部署时应使用企业自己的网关地址，不要把示例域名直接抄进生产。

然后拉取模型列表，补模型映射。

这一段最容易配出一种很迷惑的故障。菜单里显示的是 Code Pro，实际请求字段却填了另一个不存在的模型名。前端看起来已经切换成功，请求一发就报模型不可用。我的做法是把三个名字并排核对。

检查项	它解决什么问题
菜单显示名	人在 Codex 里看到什么
实际请求模型	网关收到哪个模型标识
网关侧路由目标	最后调用哪条供应商或私有模型链路

三者不必相同，但映射关系必须有人维护。

配置完成后，CC Switch 会生成对应的 auth.json 和 config.toml 内容。再到路由设置里打开 Codex 本地路由，确认当前 Provider 已切换。思考模式、Thinking Budget、图片降级和请求整流这些选项，不建议看见开关就全开。上游模型支持什么，就开到什么。

到这里，页面上已经显示接入成功。

可我觉得，能返回第一条回答，只能算把线接通了。

上生产前，我会故意把它弄坏几次

只测一条正常问答，几乎测不出网关接入的问题。更实用的是准备一组小型冒烟测试，至少覆盖下面这些情况。

1. 普通非流式请求能否返回，模型名和用量记录是否正确。

2. 流式输出是否中途断开，首 Token 时间有没有明显变化。

3. 工具调用、结构化输出和长上下文能否按预期工作。

4. 填错令牌时，返回的是可识别的鉴权错误，还是一团模糊的 500。

5. 项目配额耗尽后，是拒绝、限速还是切低成本模型，行为是否符合预案。

6. 主链路被临时停用后，备用链路能否接住请求，回答质量有没有越过底线。

7. 撤销这枚令牌后，旧配置是否立即失效，日志里能不能找到对应记录。

最后一项很重要。

很多团队花大量时间验证「能不能接上」，却没有验证「能不能安全地断开」。人员离职、项目结束、Key 泄露时，撤销和追溯往往比创建更急。

网关值不值

我也想过这个问题。

如果只是一个人、一个项目、一家模型供应商，直接配置官方 Key 最轻。为了显得架构完整硬加一层，维护工作反而更多。

但当研发团队开始同时使用 Codex、Claude Code、内部 Agent 和自动化脚本，情况就变了。大家需要的不只是接口转发，还要知道谁在调用、能用哪些模型、一天能花多少、Key 从哪里访问、某条链路挂了以后怎么办。

MAI Gateway 更适合放在这个阶段。它把模型与供应商管理、企业令牌、项目配额、费用记录、路由和日志放到同一条请求链路里。业务代码仍然负责业务，网关负责把调用边界守住。

它也不是万能适配器。某家模型特有的参数、多模态文件上传、工具协议差异和质量评测，仍然需要研发团队自己处理。网关能减少重复连接工作，不能替代集成测试。

我走完这遍配置以后，模型列表变长没让我多兴奋。上游 Key 终于可以从开发者电脑里拿走，这件事更实在。

地址统一只是表面变化。

从此以后敢轮换、敢停用，也敢查账，这才让人轻松。