最近被算力问题折腾得不轻。团队里跑AI辅助开发的服务器队列动不动就要等半小时云端API的免费配额早就见底付费额度又贵得肉疼更要命的是单一模型处理稍微大一点的代码库干到一半就上下文溢出整个任务直接报废。实在没办法我把三个不同风格的模型同时接进了Codex让它们在同一个工作流里分工协作复杂的架构设计交给推理强模型繁琐的写码和补丁交给性价比模型格式化、检查这类轻活丢给本地小模型。这篇文章就是这次改造的完整记录从路由策略、统一网关到日常操作每一步都有代码和实测数据适合正在被配额、排队、长上下文折磨的个人开发者和运维团队参考。1. 整体设计为什么要把不同模型塞进 Codex1.1 算力紧张到底卡在哪先说清楚痛点不然你没法理解后面所有设计。我最初的做法和大多数人一样一个核心模型从头用到尾。代码设计、写函数、写测试、查bug、重构全压在同一个模型上。表面上看省了切换成本实际上每一次请求都在消耗同一个高价位模型的算力。到了业务高峰期云端推理服务排队严重一次简单的代码补全也要等几十秒本地自建的推理服务则是显存不够跑7B以下的小模型勉强能出结果但质量不稳定稍微复杂一点的逻辑就给你一本正经地胡编。等到项目开始处理超过三千行的仓库时另一个问题暴露了上下文窗口被打满。Codex为了理解整个任务会把多轮对话、文件内容、历史修改记录全部带到后续请求里单模型一轮请求就要把几万token的上下文重新计算一遍。算力就这么被白白吃掉速度越来越慢费用越来越高。所以算力紧张的根源不是“模型不够强”而是“任务类型和模型能力不匹配”。把每一个任务都交给最强模型是最简单但最浪费的做法。正确的思路是让不同模型干自己最擅长的事把算力花在刀刃上。1.2 Codex 在协作架构里的真实定位一开始我也纠结过为什么要拿Codex当底座市面上AI编程工具不少直接用别的工具不行吗我的答案是Codex本来就具备任务规划、工具调用、文件读写、多步执行的能力本质上是一个agent框架。它不是简简单单的聊天窗口而是一个能把“开发任务”拆成“多个子操作”并逐步执行的调度器。这意味着我可以在Codex这一层控制“这个子操作交给哪个模型去执行”而不是让用户手动复制粘贴到不同模型之间来回切换。换句话说Codex负责的是“流程编排”模型负责的是“单点能力”。前者决定下一步该干什么后者决定这一步干得怎么样。这种分层天然适合多模型协作。还有一个实际考虑团队里其他成员已经熟悉Codex的交互方式他们不想学习一套新的插件或者脚本。如果我只改底层模型接入对普通使用者完全透明他们依然在同一个界面上敲命令、看diff、接受建议但背后的模型已经不同了。这种“前端不动、后端换血”的做法推广阻力最小。1.3 方案总览入口、路由、适配三层架构整个改造我只用了三天核心是一个轻量网关服务外加一套路由规则。三层结构是这样的层级职责落地方式入口层开发者通过Codex下发任务Codex CLI 项目内提示词约定路由层识别任务类型决定交给哪个模型自建网关根据请求内的任务标签和模型字段转发适配层把不同模型返回结果统一成Codex认识的格式网关里的协议转换与错误兜底入口层最省事Codex本身不用改代码。路由层是改造重点我写了一个HTTP网关模拟Codex熟悉的对话补全接口但内部按规则把请求转发到不同的真实模型服务。适配层则是踩坑之后补上的因为不同模型的返回格式多多少少有些差异网关要统一清洗一遍再还给Codex。从Codex的视角看它只是连上了一个“看起来像单模型”的服务从真实模型的视角看它们各自被网关调用互不知情。整条链路里唯一的“大脑”就是路由规则什么时候用强模型什么时候用便宜模型什么时候直接走本地。2. 模型分工策略与路由规则设计2.1 不同模型的能力画像与分工接入之前我先把要用的几个模型做了能力画像。别急着抄配置先明白每个模型适合干什么后面的路由规则才有依据。我用四个模型做演示代号分别是model-r、model-g、model-l和model-f。模型r是推理能力强、价格也高的重型模型适合做架构设计和代码审查模型g是综合能力不错、价格中等的性价比模型适合写业务代码和脚本模型l是本地部署的小参数模型不花钱、速度快、数据不出内网但能力弱适合格式化、简单替换、静态检查这类机械任务模型f则是轻量云端模型主要处理补注释、改命名、生成测试用例这类相对简单但需要一定理解力的活。分工表可以这样列角色代号典型任务成本架构师model-r重构方案、接口设计、复杂review高主力开发model-gCRUD、脚本、接口实现、修bug中格式工model-l代码格式化、批量替换、简单校验低/本地测试员model-f生成单测、补注释、小范围修改低这套分工的逻辑是高成本模型的请求量必须压到最低只处理那些“值得”的任务中成本模型承担绝大部分日常写码低成本模型虽然能力有限但可以频繁调用反正便宜。实际跑了一周之后我确认这条路是通的——同一功能开发下来费用减少了百分之五十以上耗时也没有明显变长。2.2 路由规则怎么写才不玄学很多人一听“路由”就觉得要搞人工智能、语义识别其实完全不是。我用的方案非常朴素在Codex的提示词里约定一个任务标记比如每次要求Codex做什么之前手动加上“任务类型重构”或者“任务类型写单测”这样的前缀。网关收到请求后解析这个标记再对照路由表决定转发到哪个模型。路由配置我放在一个YAML文件里看起来大概是这样# routing.yaml rules: - when: task_type: [重构, 方案, 架构, review] use: model-r - when: task_type: [测试, 格式化, 注释, 简单替换] use: model-l - when: task_type: [CRUD, 脚本, 接口, 爬虫, 实现] use: model-g fallback: model-g timeout_seconds: 60 max_retries: 2 retry_backoff_seconds: 2为什么用“任务标记”而不是用模型自己判断因为会让Codex在路由层额外消耗推理算力得不偿失。人工打一个前缀只多花几秒钟换来的是整个路由过程零成本、零误差这比任何花哨的AI路由都靠谱。路由规则里还有一个容易被忽略的关键fallback。如果某个任务类型没有匹配到任何规则自动切成model-g如果主模型请求超时或者报错也自动降级到model-g。要保证任何请求都有去处不能因为一条规则写漏了就让整个流程卡死。2.3 降级策略主模型挂了不能停在线服务最怕的不是慢而是单点故障。你不可能指望model-r永远不超时、不限流。所以降级策略是必须提前想好的。我的原则很简单主模型失败时先重试一次间隔2秒再失败直接降级到次选模型重试两次都失败再返回错误给Codex。这套逻辑写在网关的请求转发层里对Codex完全透明。Codex只关心最终有没有收到有效输出不关心到底是谁在回答。降级还需要考虑任务风险。如果是“重构方案”这种高难度任务降级到model-g之后可能出不了高质量方案这时候我宁可返回一个错误让开发者介入而不是让模型硬编一个错误方案。但如果是“格式化代码”这类低危任务降级到model-l完全没问题。所以路由规则里最好再增加一个字段risk_level。- when: task_type: [重构, 方案, 架构, review] use: model-r fallback: model-g risk_level: high - when: task_type: [格式化, 简单替换] use: model-l fallback: model-f risk_level: low高风险的失败宁可报错低风险的失败必须兜住。这是我跑了两周之后总结出来的纪律一开始我不管什么都降级结果出现过一次model-r超时、自动降级到model-g、生成了完全偏离需求的重构方案的情况浪费了整整半天。2.4 成本与token预算控制多模型接入之后成本控制的核心不再是“哪个模型便宜”而是“这个任务该不该用贵模型”。我按三档预算管理第一档是model-r只允许在架构设计、代码审查、疑难杂症排查时调用每次调用前网关检查当前小时累计消耗token超了就强制切到model-g并发出警告第二档是model-g日常写码的主力预算充足但也不是无限超过单任务token上限会被要求拆小任务第三档是model-l和model-f基本不设限本地部署的model-l甚至没有费用。网关记录每次请求的token消耗并且每十分钟输出一次汇总日志。跑了一周之后我看数据发现最烧钱的操作根本不是代码生成而是多轮对话里反复把整个仓库内容塞进上下文。后来我把Codex的使用习惯改成“每个子任务只带需要的文件和函数”费用立刻掉了一大截。token预算不能光靠自觉必须有硬性开关。网关里我设置了一个简单规则单个请求若超过上下文窗口的百分之八十直接拒绝并把错误信息返回给Codex让Codex自己精简上下文后重试。这比让模型“硬撑着跑”要稳定得多。3. 从零实现网关搭建与Codex接入全流程3.1 先搭一个统一模型网关网关本质上就是一个带路由规则的HTTP代理用Python的Web框架实现非常快。我选用了一个轻量异步框架几十行代码就能跑通核心逻辑。下面是一个简化但可运行的核心版本# gateway.py import os import httpx from fastapi import FastAPI, Request from fastapi.responses import JSONResponse app FastAPI() ROUTES { model-r: https://endpoint-example-r/v1/chat/completions, model-g: https://endpoint-example-g/v1/chat/completions, model-f: https://endpoint-example-f/v1/chat/completions, model-l: http://127.0.0.1:8000/v1/chat/completions, } VALID_KEYS {your-gateway-key} app.post(/v1/chat/completions) async def chat_completions(request: Request): auth request.headers.get(Authorization, ).replace(Bearer , ) if auth not in VALID_KEYS: return JSONResponse( {error: {message: unauthorized}}, status_code401 ) payload await request.json() target payload.get(model, model-g) upstream_key os.environ.get(UPSTREAM_API_KEY, ) headers { Authorization: fBearer {upstream_key}, Content-Type: application/json, } timeout httpx.Timeout(90.0) try: async with httpx.AsyncClient(timeouttimeout) as client: resp await client.post( ROUTES[target], jsonpayload, headersheaders ) data resp.json() return JSONResponse(contentdata, status_coderesp.status_code) except httpx.ReadTimeout: return JSONResponse( {error: {message: upstream timeout, fallback needed}}, status_code504, )这段代码的核心是Codex发来的请求里带一个model字段网关根据这个字段查路由表把请求转发到真实模型服务。真实模型可以是云端API也可以是本地推理服务只要地址配置正确即可。跑通这个基础版之后我再补了两件事一是把路由规则从代码里拆到YAML配置因为每次改模型优先顺序都改代码太蠢了二是给所有上游响应添加统一的字段格式转换保证Codex能识别。网关部署在一台内网小机器上内存占用不到两百兆完全不影响开发机性能。3.2 把 Codex 接到网关Codex本身支持自定义模型接入方式通过配置文件和环境变量指向你的网关即可。我用的配置长这样# 环境变量示例 export OPENAI_BASE_URLhttp://127.0.0.1:8000/v1 export OPENAI_API_KEYyour-gateway-key# ~/.codex/config.toml model model-r model_provider custom [model_providers.custom] name my-gateway base_url http://127.0.0.1:8000/v1 api_key_env_var OPENAI_API_KEY wire_api chat注意不同版本的Codex字段名可能略有差异我这里的配置在我手头版本上验证过如果你用的版本不同查看一下对应版本的自定义provider说明补齐即可。这个配置的效果是Codex启动后认为自己在跟一个叫model-r的模型对话所有请求都发到本机的8000端口由网关决定最终调用谁。我在日常使用中会把配置里的默认model写成model-g因为大部分请求不需要动用model-r。只有当我在提示词里写了任务标记“重构”或“review”时网关才会把请求转发给model-r。这里有一个细节如果你想在同一个Codex会话里切换模型不用重启Codex只要改提示词里的标记就行。比如我先让model-r做方案设计拿到方案之后在下一轮提问里加“任务类型实现”网关识别后就自动切成model-g。整个过程对Codex来说是连续的它甚至不知道背后换了模型。3.3 一次真实的协作开发过程理论讲再多不如看一次真实协作过程。我拿最近的一个任务举例给内部工具写一个批量文件重命名功能要求支持按正则表达式匹配、支持预览、支持撤销。第一轮我让Codex调用model-r做设计。提示词里写上“任务类型方案”然后把需求贴进去。model-r用几分钟给出了完整的模块划分解析规则层、文件树遍历层、安全校验层、事务回滚层还顺便设计了函数签名和数据结构。这一轮是整个开发里最值钱的几十分钟因为后续所有代码都是照着这个设计走。第二轮我告诉Codex“任务类型实现”把model-r的设计文档贴回去。网关自动路由到model-gmodel-g按设计文档把核心代码写了出来。这个过程不需要模型r参与model-g处理这种“看图施工”的活已经绰绰有余。第三轮代码写完后我让Codex跑一遍静态检查并格式化提示词里写“任务类型格式化”。网关收到后直接转发给model-l本地小模型完成了import排序、空行规整、命名微调几乎零成本。第四轮我要求补单元测试任务标记是“测试”网关切到model-f。model-f生成了针对正则匹配和回滚逻辑的核心测试用例我把测试跑了一遍有两个边界用例没过又把失败信息贴回去让它修一次就过了。整个流程下来模型r只被调用了一次模型g一次模型l一次模型f两次。和之前全部用模型r相比费用降低了一半以上而且整个开发时间缩短了因为那些机械任务不再排在高价模型的队列后面等待。3.4 实跑数据换了模型组合之后光说“省了多少钱”不够说服力我拉了最近三周的数据做对比。以前只用单一强模型现在多模型协作处理任务的对象是几个典型开发需求。任务旧方案耗时新方案耗时旧方案费用新方案费用成功率批量重命名工具约10分钟约7分钟高中提升明显接口文档生成约8分钟约3分钟高低持平代码审查约6分钟约5分钟高中提升明显格式化与补注释约3分钟约1分钟中低持平数据是我按实际情况粗略估算的绝对值不重要关键是趋势重型和机械任务分流之后真正需要深度思考的请求量少了总耗时和总费用都往下降。还有一个意外发现成功率其实提高了。原因在于——以前强模型也会在小任务上翻车比如格式化和补注释偶尔会多余改动代码现在这类任务交给本地小模型虽然智商不高但机械执行反而稳定很少自作主张。4. 常见问题与排查技巧实录4.1 模型返回不兼容 Codex 格式第一个坑就是格式兼容。不同模型服务的返回结构有差异有的字段名不同有的缺少tool_calls有的多了一层包装。Codex本身比较严格解析不到预期的字段就会报错或者干脆忽略输出。我的解决办法是在网关里加一个响应规范化函数把所有上游返回统一成Codex熟悉的格式。规范化逻辑大致是拿到上游JSON提取出回复文本如果有function call或tool call信息也单独提取出来重新组装成Codex要求的结构。这个函数我放在网关转发层对上游透明对Codex也透明。调试时我强烈建议开启网关的详细日志把上游原始返回和规范化之后的返回都打印出来。第一次调试时我就是靠日志对比发现某个模型把回复内容放在了content的数组里而Codex期望的是字符串改了一行解析逻辑就好了。4.2 上下文太长截断、摘要、分片多模型协作并不能解决上下文溢出反而会暴露这个问题。Codex在接过上游模型的输出后会把之前的历史继续往后带几轮下来上下文越滚越大。我的处理办法是“分片式硬隔离”Codex会话被拆成几个阶段每个阶段只携带必要的信息。比如设计阶段只给需求文档和约束条件不塞代码实现阶段只给设计摘要和目标文件名不给完整版设计文档测试阶段只给当前函数和失败日志。如果某个函数太长我会先让model-f对代码做一次分段总结再让model-g基于摘要工作。这个操作看起来绕了一圈实际上比把几千行代码直接塞给模型高效得多。记住一个原则模型看到的信息越相关输出质量越高信息全塞进去只会让模型抓不住重点。4.3 限流和并发控制真实模型服务都会有速率限制有时候不是算力不够而是单位时间内请求太多了。一开始我没做限流控制结果高峰期网关向上游发出了大量并发请求触发限流所有请求排队等待体验比单模型还差。后来我在网关里加了一个简单的信号量并发控制加指数退避重试。并发上限设置为3超过的直接在网关内排队遇到限流错误时第一次等2秒重试第二次等4秒第三次等8秒最多重试两次。这套机制跑下来上游限流错误基本绝迹网关反而变成了一层平滑缓冲。4.4 生成结果不稳定温度、校验、重试分布式模型服务有个特性同一个输入多次请求的结果可能不同。写代码这种场景结果不稳定非常麻烦。尤其model-g偶尔会给出风格迥异的实现逻辑一样但命名、结构完全不同。我的策略是按任务类型调整温度参数。方案设计类任务温度调到0.2几乎不随机保证输出稳定实现类任务调到0.4保证有一定灵活性但不会跑偏测试生成类任务温度调到0.7让模型多生成一些不同用例。温度设置我直接写在网关的路由配置里每个模型对应一个默认温度上游请求发起时统一注入。如果遇到前端反馈“这次和上次回答不一样”我还有一个笨办法在网关里保留同一任务的最近一次成功结果缓存相同请求在短时间内直接返回缓存。这个缓存不需要很大只存最近的几十条请求就已经能解决大部分“怎么又变了”的抱怨。4.5 安全与数据边界网关鉴权与日志脱敏接多模型之后必须考虑数据安全。尤其是接入本地模型和外部云端模型混合使用哪些数据能出内网哪些不能要在路由阶段就拦下来。我的做法是三级控制第一网关只接受来自内网的请求非内网IP直接拒绝第二请求里凡是包含代码文件路径的一律打上“敏感”标签敏感标签的任务只能走model-l本地模型不能出网第三日志模块做了脱敏处理网关只记录模型代号、请求耗时、token消耗、状态码不记录任何代码正文和对话内容。这样即使日志泄露别人也看不到实际代码内容。还要提醒一点外部模型服务商的API Key不要直接配置在Codex端而是统一放在网关的环境变量里。这样即使某台开发机上Codex配置泄露别人也拿不到上游密钥最多只能打到你自己的网关入口风险可控。一点体感和后面打算说句实话这套多模型接入方案最大的收益不是省成本而是让我重新认识了“模型”这件事。以前下意识把模型当成一个固定不变的成品缺点了只能忍着现在模型变成了可替换组件算力分配变成了路由配置整个AI辅助开发流程有了更大的调节余地。如果让我重新做一遍我会把路由和日志做得比现在更早、更扎实。路由规则决定了成本和稳定性的基线日志则是优化路线的唯一依据。没有日志你根本不知道钱花在哪、时间耗在哪、哪个模型在频繁翻车。最后分享一个小技巧把网关里每个请求的model、延迟、token数、错误码全部打点坚持跑一周然后用表格拉一拉统计数据。你会发现一个很有意思的现象——最耗钱的任务往往不是最复杂的任务而是那些因为上下文设计不合理、被反复重试的任务。先修掉这种浪费再考虑换更强的模型也不迟。
