前两天有个朋友问我Codex 能不能接国产大模型他想把日常的代码任务挂到 DeepSeek 上省点 API 费用。我说能但过程不算无脑——配置文件里那几个字段能让你绕一整个下午。现在社区里铺天盖地都是 Codex 的安装教程、使用教程但真正把 Codex CLI 接到 DeepSeek 这类国产模型服务的实战记录不算多尤其是那些“照着配置却跑不通”的报错基本都得自己撞一遍才知道怎么回事。这篇文章面向谁主要是两类人一是已经装了 Codex CLI、想用更便宜的模型跑日常编码任务的朋友二是正在观望、想知道“国产模型 官方编码 Agent”到底能不能落地的人。内容会覆盖环境准备、config.toml 的实际改法、常见报错的排查链路以及我最真实的实测反馈。不吹不黑能跑通就是能跑通跑不通我也会把报错原文和解决路径贴出来。1. 为什么官方编码 Agent 非要折腾第三方模型1.1 原生 Codex 的模型入口有多窄Codex CLI 是 OpenAI 官方的终端编码 Agent跑起来之后能在你的仓库里读代码、改文件、执行命令交互方式有点像在终端里雇了一个会写代码的实习生。但它的原始设计很“排外”默认情况下只认 OpenAI 自己的模型服务登录、鉴权、请求协议全是围绕官方端点设计的。你想换模型官方一开始并没有给这条路。直到 2025 年Codex 逐步开放了自带模型提供方BYOKBring Your Own Key的能力这才让第三方模型有了正规入口。所谓“正规”是说你可以通过配置文件声明一个 model_provider告诉 Codex CLI“有个供应商在某个地址提供兼容接口你去这里拉模型”。DeepSeek 官方提供了 OpenAI 兼容的 API于是“Codex 对接 DeepSeek”这条路就通了。这个设计对想省钱的人来说是个好消息。因为 Codex 本身只是个壳真正干活的是背后的模型。壳不用换把引擎换掉日常轻量级任务的开支能降一个量级。1.2 成本账DeepSeek 的输入输出价格模型先算一笔公开账。我以 DeepSeek 官方公示的价格为准实际价格以官网为准这里只说明量级deepseek-chat输入约 2 元/百万 tokens输出约 3 元/百万 tokens。deepseek-reasoner输入约 4 元/百万 tokens输出约 16 元/百万 tokens。缓存命中的输入侧价格通常更低有时能到 0.5 元/百万 tokens。对比 Codex 默认的官方模型同样的编码任务费用差距大致在几十倍级别。当然只比单价不算公平还要看任务成功率、工具调用稳定性和上下文处理能力。但对我们这种日常写脚本、改 bug、补文档为主的用法来说国产模型足够覆盖大多数场景单价便宜意味着可以放心让它多跑几轮不用每敲一次回车都心疼钱包。1.3 这条路能走通的前提条件接入前你可以先自查一下三样东西缺一不可一个能直连访问的 API 端点这里指 DeepSeek 开放平台提供的官方接口。一个有效的 DeepSeek API Key。一个足够新的 Codex CLI 版本至少是支持 model_providers 配置的版本。有个常见误区是有人以为把 base_url 改成 api.deepseek.com 就完事了。实际上 Codex 还需要知道应该用哪种 wire protocol 去请求这个端点这跟后面要说的wire_api字段直接相关也是大多数配置失败的根源。2. 动手前先备齐这几样东西2.1 安装新版 Codex CLI安装本身不复杂两条路任选npm install -g openai/codex # 或者 macOS 上用 brew brew install codex装完以后务必确认版本codex --version如果你拿到的版本比较旧建议直接升级。原因很简单model_providers 是后来才加入的功能版本太老的话配置写对了也不生效。我见过有人拿着一年前的版本折腾半天最后升级一下就好了属于典型的“版本不对努力白费”。2.2 搞定 DeepSeek API Key去 DeepSeek 开放平台注册账号创建 API Key。创建之后先把 Key 保存好因为平台通常只完整显示一次。拿到 Key 后可以在本地先做一个快速连通性测试export DEEPSEEK_API_KEYsk-你的key curl https://api.deepseek.com/v1/models -H Authorization: Bearer $DEEPSEEK_API_KEY如果返回一串模型列表说明 Key 有效、网络通、API 端点也没问题。这一步花不了两分钟但能帮你把“Key 写错”和“Codex 配置写错”这两类问题提前分开。2.3 必须先搞懂三个单词model_provider、model_registry、model很多人第一次打开 config.toml 就懵了因为里面同时出现了三个长得差不多的概念。我打个比方model_provider是“供应商名片”上面写着商家叫什么、地址在哪、认证方式是什么。model_registry是“供货单”把供应商和它实际提供的模型型号对应起来。model是最终下单时选的货号也就是你命令行里指定的那个名字。Codex 的约定是你在model_providers里声明一个供应商然后在model_registry里登记这个供应商下的模型最后运行时通过--model指定用哪款。三步缺一不可顺序也不能乱。3. config.toml 的实际改法从一份能跑通的配置说起3.1 一份可以直接用的配置模板Codex CLI 的配置文件默认在~/.codex/config.toml。修改前建议先备份一份。这里给出一份我验证过能跑通 DeepSeek 的基础配置model deepseek-chat [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api chat [model_registry.deepseek:deepseek-chat] provider deepseek model deepseek-chat其中env_key的值是环境变量名意思是 Codex 会去读你 shell 环境里的DEEPSEEK_API_KEY而不是把 Key 明文写在配置文件里。这样更安全也方便多台机器复用配置。3.2 wire_api 填 chat 还是 responses关键中的关键这是整篇配置里最容易被忽略、也最容易出错的字段。Codex 原生请求走的是 OpenAI 的 Responses API也就是 POST 到/v1/responses。而 DeepSeek 目前对外提供的 OpenAI 兼容接口主要是 Chat Completions也就是/v1/chat/completions。这两个端点不是同一个东西。所以当 Codex 要对接 DeepSeek 时你需要告诉它这个供应商用的是 chat 协议请你在本地把请求转成 chat/completions 格式再发过去。对应配置就是wire_api chat如果你把它填成responsesCodex 会按原生格式去请求 DeepSeek多半会撞上 404 或者 invalid request。少数已经兼容 Responses 协议的服务商可以填responses但 DeepSeek 目前的常规姿势还是chat。顺带说一句社区里一些第三方“切换器”工具本质上就是帮你做这个协议转换和地址改写的。既然我们已经在配置层把wire_api chat写对了这类工具其实不是必需品。3.3 通过 codex exec 做一次真实请求配置写完环境变量设置好先别急着进交互模式用一条最简单的命令验证链路export DEEPSEEK_API_KEYsk-你的key codex exec --model deepseek-chat 用一句话说明 base64 是什么如果配置没问题终端会返回一行不短的回答。如果报 “not a git repo” 之类的提示可以加上--skip-git-repo-check再跑一次。这一步能通说明模型路由、协议转换、鉴权都没问题接下来再谈实战。4. 踩坑实录三个浪费时间的报错4.1 表面上是 local proxy failed实际是切换器与新协议冲突很多人喜欢用社区里的“模型切换器”来改 Codex 配置尤其是想把官方模型和国产模型来回切的时候。这类工具通常会在本地起一个中转服务把 Codex 发出来的请求改写后转发到目标模型服务。某次我在配置 DeepSeek 后就撞上了这么个报错原文类似cc switch local proxy failed while handling codex endpoint /responses这个报错的本质是切换器的本地中转服务挂了而且它还在按/responses路径去处理请求。我当时的排查链路是这样走的先用系统命令查本机端口占用确认中转服务是不是端口被占了。然后把 config.toml 备份还原成原生格式避免切换器反复改写。不经过切换器直接用codex exec --model deepseek-chat发起原生请求。确认原生请求能通之后再回头看切换器的配置发现它把 base_url 和协议改写逻辑弄重复了。最后我的结论是既然 Codex 原生就支持 model_providers完全没必要再套一层本地中转。绕开切换器直接用原生配置这个报错就不存在了。如果你也在用这类工具建议优先排查“是不是切换器版本和 Codex 版本不兼容”而不是先去怀疑 DeepSeek API 出了问题。4.2 auth token is unavailableCodex 在认证源上的优先级问题这个报错也很经典原文是codex auth token is unavailable出现这个报错通常不是因为你的 DeepSeek Key 错了而是 Codex 在启动时先尝试找它“认识”的 OpenAI 凭据没有找到就直接报错根本没走到读取 providerenv_key那一步。不同版本的 Codex 行为略有差异我的处理办法是在 shell 配置里显式 exportDEEPSEEK_API_KEY确保环境变量已经生效。如果还报错尝试给OPENAI_API_KEY也设置一个非空占位值让 Codex 的本地认证检查先通过。检查~/.codex/auth.json里有没有历史遗留的过期 token有的话先备份再清掉。这个问题的底层逻辑是 Codex 的认证优先级设计——它默认以官方凭据为准自定义 provider 是“备选路径”。弄清楚这一点你就不会在环境变量上反复折腾了。4.3 404 或 invalid endpointbase_url 多一个斜杠少一个斜杠的区别配置里的base_url看起来简单实则非常容易出幺蛾子。常见两种错误地址写成https://api.deepseek.com不写/v1Codex 拼接请求路径时就可能变成/chat/completions而 DeepSeek 那边期望的是/v1/chat/completions结果直接 404。地址写成https://api.deepseek.com/v1/末尾多了个斜杠某些版本拼路径时会出现双斜杠导致连接异常。正确的是base_url https://api.deepseek.com/v1不要小看这一个字段。我知道有人在这个问题上耗了一下午最后发现只是少写了一个/v1。遇到 404 或者连接失败第一件事不是怀疑网络而是把 base_url 打出来对着请求日志看一遍。5. 接入之后DeepSeek 在 Codex 里的真实表现5.1 我用它做了什么级别的任务接入配置跑通之后我连续几天把日常任务都切到 DeepSeek 上总结了它的实际表现。我的任务清单大致是给一个 Python CLI 项目新增参数解析逻辑。修复几个单元测试失败。生成 Markdown 格式的项目说明文档。一次中等规模的跨文件重构。结果是单文件小任务非常稳定模型基本能理解你的意图代码改动也符合预期。工具调用成功率也还可以没有出现频繁掉链子的情况。但跨文件重构类任务表现明显吃力经常出现“接口改了、调用方忘更新”的假性完成状态。遇到这种情况我的处理方式是把任务拆成多步每步明确指出现有文件路径而不是让它一次搞定。5.2 一次典型会话的成本估算我按一次“给中型仓库补充 CLI 参数与测试”的任务来估算大致消耗为输入约 20 万 tokens输出约 1 万 tokens。按 DeepSeek 官方公开价格计算输入成本20 万 / 100 万 × 2 元 0.4 元输出成本1 万 / 100 万 × 3 元 0.03 元总计不到 0.5 元。如果是缓存命中输入侧还能更便宜。同样的任务放在官方模型上成本大概率是它的几十倍。这就是“廉价模型”最直观的价值——不是性能最好而是让你敢放开手让它试错。5.3 AGENTS.md 才是白嫖体验的分水岭这是我实测下来最大的感受。Codex 支持在仓库根目录放一个AGENTS.md相当于给它一份“长期工作手册”。模型在每次任务开始前都会读到这个文件。对国产模型来说这份文档的重要性远大于官方模型——因为它在复杂上下文里的指令遵循能力相对弱一些明确写清楚规则能显著减少“自由发挥”。我在仓库里放的内容大概是# Rules - 不修改与本次任务无关的配置文件 - 输出代码前先跑一遍现有单元测试 - 修复 bug 时先补充复现用例再改代码 - 保持 Python 3.10 兼容 - 修改公共接口时必须同步更新所有调用方加上这份文档之后最明显的改善是模型不再自作主张去动无关文件改完代码也会主动提示你跑了哪些测试。同样是省钱模型有没有 AGENTS.md体验完全是两回事。6. 让廉价模型真正好用的几条操作建议6.1 双模型路由小改动和硬骨头分开打如果你有多个模型可用我建议不要“从一而终”。日常加注释、写脚本、改小 bug用 deepseek-chat遇到架构调整、复杂重构再切回推理能力更强的大模型。Codex 运行时可以用--model直接指定模型切换成本很低codex --model deepseek-chat codex --model deepseek-reasoner我的习惯是先让 deepseek-reasoner 做规划和方案评审给出修改清单然后切到 deepseek-chat 去执行具体代码改动。这样既不牺牲任务质量又能把账单压住。6.2 压住上下文别把廉价当成无限DeepSeek 再便宜也不能把整个仓库一股脑塞进去。上下文窗口越大模型对早期指令的“记忆”越模糊这是所有大模型的通病廉价模型尤其明显。我建议用/compact压缩对话历史让它只保留关键结论。谨慎使用-f添加文件只加当前任务真正依赖的文件。任务分阶段跑别一个会话里做三件完全不相干的事。看起来很基础但很多人就是在这里栽跟头模型越跑越蠢其实不是模型不行是上下文太脏。6.3 善用 exec 模式和 plan-then-apply 模式Codex 不是只有全自动交互模式。你完全可以让它先出方案、后动手减少“瞎改”的概率codex exec --model deepseek-chat 分析 src/ 下的模块依赖问题给出修改方案先不要改代码等它输出方案你审一遍没问题再让它落地执行。对于国产模型来说这种“先计划后执行”的用法非常关键因为它的自主判断能力弱一些但只要你把方向和边界划清楚它能干得又快又便宜。最后再分享一个小技巧config.toml 这种文件一定要纳入版本管理或者至少备份一份到私人仓库。Codex 版本更新偶尔会调整配置格式照抄旧教程容易翻车。我自己就吃过这个亏所以现在每次升级完第一件事就是跑一遍codex exec --model deepseek-chat确认链路没断。Codex 和 DeepSeek 这个组合我现在日常用得挺顺手。它不是官方模型那种“全自动高级工程师”更像一个需要你把规则写清楚、把步骤拆细的实习生。但考虑到每次任务几毛钱的成本这个实习生的性价比我觉得是值得的。