05 · Codex 接入第三方模型：先想清楚值不值得，再动配置

" 适合读者：已经能使用 Codex，但想通过 DeepSeek、其他国产模型或公司内部模型网关降低成本、改善访问速度的人。 本文目标：讲清楚第三方模型接入的收益、风险、基本路线和排错方法。读完后，你应该知道：这件事不是新手必做项，也不是改一个模型名就一定能跑。 注：第三方模型的接口、模型名、协议兼容性变化很快。本文只讲判断框架和安全做法，不写死任何平台的当前地址或模型名。

先说结论：刚入门不建议马上接第三方模型

第三方模型接入听起来很诱人：

• • 成本可能更低
• • 国内访问可能更顺
• • 可以接公司内部模型网关
• • 可以把不同任务分给不同模型

但它也会带来新问题：

• • 协议不一定兼容
• • 工具调用不一定稳定
• • 报错更难判断
• • 模型能力可能不适合复杂代码任务
• • API key 和数据安全要自己负责

如果你还没熟悉 Codex 的基础用法，建议先用官方默认模型跑通 01~04 章的流程。等你知道正常 Codex 应该怎么工作，再来判断第三方接入到底哪里出了问题。

否则你会同时面对三类问题：

1. 1. Codex 配置问题
2. 2. 第三方平台接口问题
3. 3. 模型能力问题

这三类混在一起，新手很难排查。

一、第三方模型接入到底在接什么？

Codex 本身是编程代理。模型只是它背后的“大脑”之一。

你让 Codex 做任务时，大致会发生：

Codex 收集上下文 -> 发给模型 -> 模型返回计划或代码 -> Codex 调用工具执行 -> 再反馈给模型

如果你接第三方模型，本质上就是让 Codex 把模型请求发给另一个提供商。

关键难点是：第三方提供商必须听得懂 Codex 发过去的请求格式。

这就涉及协议兼容。

二、为什么不是所有 OpenAI 兼容接口都能用？

很多平台会写“兼容 OpenAI API”。但这句话还不够精确。

OpenAI API 里有不同接口形态，例如 Chat Completions、Responses 等。一个平台可能兼容其中一部分，但不一定完整支持 Codex 当前需要的全部能力。

所以你会遇到这种情况：

• • 普通聊天接口能用
• • 用 curl 测试能返回
• • 其他工具能接
• • 但 Codex 里一跑就 400 或工具调用异常

这不一定是你 TOML 写错了。它可能是协议兼容不完整。

判断时要看三点：

1. 1. 第三方是否明确支持 Codex 所需的 API 形态。
2. 2. 是否支持工具调用、结构化输出、长上下文等能力。
3. 3. 报错是鉴权问题、模型名问题，还是请求格式问题。

三、什么场景值得尝试？

适合尝试

你可以考虑第三方模型，如果：

• • 官方模型访问不稳定。
• • API 成本压力明显。
• • 你主要做低风险、日常型任务。
• • 公司已经有统一模型网关。
• • 你愿意花时间排查配置和协议问题。

典型任务包括：

• • 改文档
• • 解释小文件
• • 批量整理 Markdown
• • 生成简单测试草稿
• • 做只读分析初稿

不建议尝试

不建议把第三方模型作为默认选择，如果：

• • 你刚开始学习 Codex。
• • 你主要处理复杂架构、疑难 bug、安全相关代码。
• • 你不能接受接入失败和偶发兼容问题。
• • 你已经有足够的官方 Codex 额度。
• • 任务涉及敏感代码，但第三方平台没有通过公司审批。

一句话：

" 第三方模型适合“可控实验”，不适合“盲目替换默认大脑”。

四、两条路线：直连配置和代理转换

第三方接入大体有两种路线。

路线一：Codex 直接配置 provider

如果第三方平台接口兼容 Codex 当前需要的协议，可以在 Codex 配置里添加自定义 provider。

示意结构大概是：

model_provider ="your_provider"model ="your-model-name"[model_providers.your_provider]name ="Your Provider"base_url ="<第三方 API 地址>"env_key ="YOUR_PROVIDER_API_KEY"

注意：这只是结构示例，不是可直接复制的真实配置。

真实配置要以三份文档为准：

1. 1. Codex 当前配置文档
2. 2. 第三方平台 API 文档
3. 3. 你所在团队的安全要求

尤其是base_url、model、协议类型、鉴权方式，这些都可能变化。

路线二：通过代理做协议转换

如果第三方只兼容一部分 OpenAI API，或者格式不完全一样，可以用代理服务做转换。

流程大概是：

Codex -> 本地代理 -> 第三方模型平台 -> 本地代理 -> Codex

代理的作用是把 Codex 发出的请求转换成第三方能懂的格式，再把第三方返回的结果转换回来。

这种方式优点是兼容性可能更好。缺点也明显：

• • 多了一层服务，排错更复杂。
• • 代理本身要可信。
• • 代理可能看到你的请求内容。
• • 团队环境里要经过安全审核。

新手如果只是学习，不建议一开始就走代理路线。它适合已经理解原理、确实有需求的人。

五、API key 应该怎么放？

无论直连还是代理，API key 都不要写死在文章、仓库或提示词里。

更稳的做法是用环境变量。

macOS / Linux 临时设置示例：

export YOUR_PROVIDER_API_KEY="你的 key"

Windows PowerShell 临时设置示例：

$env:YOUR_PROVIDER_API_KEY="你的 key"

然后在配置文件里只写环境变量名：

env_key ="YOUR_PROVIDER_API_KEY"

这样配置文件里不会出现真实 key。

还要记住：

• • 不要把 key 放进AGENTS.md。
• • 不要把 key 发给 Codex 让它“帮你配置”。
• • 不要把 key 截图发到群里。
• • 不要提交.env 或包含 key 的配置文件。

六、最小验证：先别让它改项目

第三方模型接通后，第一步不要让它改真实代码。

先做只读测试：

请只回复一句话：你现在可以正常响应。不要读取文件，不要修改文件。

如果能回复，再让它读一个小文件：

请读取 README 的前几段，用三句话概括。不要修改文件。

再进一步，让它做一个低风险小任务：

请在一个临时目录里创建 hello.txt，内容是 hello。完成后告诉我文件路径。

这样一步步验证：

1. 1. 模型能不能响应。
2. 2. Codex 能不能正常传上下文。
3. 3. 工具调用和文件操作是否稳定。
4. 4. 它的输出质量是否可接受。

不要一上来就说“帮我重构整个项目”。那样失败了也不知道是哪一层失败。

七、常见报错怎么判断？

特别注意 400。

很多人看到 400 会一直改 key、改模型名。其实 400 更常见的原因是请求格式不被支持。你要看错误信息里有没有 schema、tool call、responses、messages 之类关键词。

八、接通后怎么用更合理？

第三方模型不一定要替代所有任务。更合理的是分工。

可以这样分：

如果你同时有多个工具，没必要强行让 Codex 承担所有第三方模型任务。

一个现实策略是：

• • Codex 官方模型：处理复杂代码和高可靠任务。
• • 第三方模型：处理低风险、批量、文档和初稿任务。
• • 公司模型网关：处理有合规要求的内部场景。

九、什么时候应该放弃接入？

有些接入不值得继续折腾。

如果你已经遇到这些情况，可以先停：

• • 配置了很久仍然 400。
• • 代理工具不透明，看不懂它转发了什么。
• • 模型经常错误调用工具。
• • 输出代码你很难信任。
• • 团队没有批准把代码上下文发给第三方。
• • 成本节省很少，但维护成本很高。

工程上，能跑不等于值得用。

接第三方模型的目标应该是提升效率或降低成本。如果它让你花更多时间排错，就暂时不是好方案。

十、这一章你真正要记住什么？

1. 1. 第三方模型不是新手必选项。
2. 2. Codex 接第三方的关键难点是协议兼容，不只是模型名。
3. 3. API key 要用环境变量，不要写进仓库和提示词。
4. 4. 验证要从最小只读请求开始。
5. 5. 401 多半是鉴权，404 多半是模型名，400 多半是协议。
6. 6. 第三方模型适合低风险任务，复杂代码任务仍建议用可靠模型。
7. 7. 如果维护成本超过节省成本，就先放弃。

第三方模型接入不是“省钱按钮”，更像一条可选的工程路线。走之前先判断需求，走的时候小步验证，走不通就及时止损。

参考资料说明

本文参考以下类型资料整理：

• • Codex config / model providers：自定义模型提供商配置
• • OpenAI API compatibility：OpenAI API 协议兼容性
• • Responses API / Chat Completions：不同 API 形态
• • Third-party model provider docs：第三方模型平台官方文档
• • API key security：密钥管理与安全实践
• • Proxy / gateway pattern：本地代理与协议转换思路