如何使用 DeepSeek 驱动 Codex：无需 OpenAI 账号，从原理到实战完整配置
如何使用 DeepSeek 驱动 Codex：无需 OpenAI 账号，从原理到实战完整配置
最近开始使用 Codex 后，我发现一个很有意思的问题：
Codex 一定要绑定 OpenAI / ChatGPT 账号才能使用吗？
如果你的目标只是使用 Codex 本身，并不一定非要走 ChatGPT 官方账号这条路径。
Codex 本身提供了 Model Provider 配置机制，而 DeepSeek 又原生提供了与 Codex 所需要的 Responses API 兼容接口。
于是整个调用链可以变成：
Codex
│
│ Responses API
▼
DeepSeek API
│
▼
DeepSeek-V4-Flash
也就是说，我们不需要修改 Codex 源码，也不需要自己开发一个 Codex 插件。
真正需要做的是：
- 让 Codex 知道 DeepSeek 是一个模型提供方；
- 告诉 Codex DeepSeek 模型的元数据；
- 把 Codex 的请求地址指向 DeepSeek；
- 使用 DeepSeek API Key 进行认证；
- 告诉 Codex 使用 Responses API。
DeepSeek 官方目前已经提供了专门的 Codex 接入方案。Codex CLI、ChatGPT 桌面端以及 VS Code 的 Codex IDE Extension 都可以共享这套配置。(DeepSeek API 文档)
一、先理解：Codex 到底是怎么调用模型的？
在开始修改配置之前，先把整个过程搞明白。
很多人第一次接第三方模型时，会把问题理解成：
Codex
↓
把 OpenAI API Key
换成 DeepSeek API Key
其实并没有这么简单。
Codex 在中间还有一个非常重要的概念：
Model Provider
整个关系更接近：
Codex
│
▼
Model Provider
│
┌────────┴────────┐
│ │
Model API Endpoint
│ │
└────────┬────────┘
▼
DeepSeek API
│
▼
DeepSeek-V4-Flash
因此：
Provider 决定“模型服务在哪里”，Model 决定“具体调用哪个模型”。
这就是为什么我们需要修改 config.toml。
二、为什么 DeepSeek 可以接入 Codex？
这里真正的关键不是“DeepSeek 模仿 OpenAI”。
而是：
DeepSeek API 原生支持 Responses API。
DeepSeek 官方目前提供：
POST https://api.deepseek.com/responses
并按照 OpenAI Responses API 的格式返回 response 对象。
DeepSeek 官方文档明确说明，为满足 Codex 等 Agent 场景的需求，DeepSeek API 增加了 Responses API 支持。当前 Responses API 支持 deepseek-v4-flash。(DeepSeek API 文档)
所以 Codex 和 DeepSeek 之间可以直接建立这样的关系：
Codex
│
│ Responses API
▼
https://api.deepseek.com/
│
▼
deepseek-v4-flash
这也是整个方案能够成立的基础。
三、这里有一个非常重要的区别：Chat API ≠ Responses API
DeepSeek 本身同时提供多种 API 形式。
例如传统的：
/v1/chat/completions
以及现在用于 Codex 的：
/responses
两者不要混淆。
传统 Chat Completions 更像：
messages
↓
模型
↓
回答
而 Responses API 可以承载：
input
instructions
reasoning
function_call
function_call_output
web_search
custom tool
这对于 Coding Agent 非常重要。
DeepSeek 当前 Responses API 已经支持函数工具、Web Search，以及 Codex 所需的 apply_patch custom tool；其他部分内置工具则可能被忽略。(DeepSeek API 文档)
所以：
“第三方模型支持 OpenAI API”并不意味着它一定能够驱动 Codex。
真正需要确认的是：
是否支持 Responses API？
是否支持 Codex 需要的工具调用？
返回格式是否兼容？
四、DeepSeek 接入 Codex 实际上做了什么？
DeepSeek 官方方案非常值得研究。
它并不是只修改一个配置文件。
实际上涉及两个文件：
~/.codex/
│
├── config.toml
│
└── models.json
这两个文件承担的职责完全不同。
五、config.toml：告诉 Codex“请求发给谁”
首先是：
~/.codex/config.toml
它主要解决：
使用哪个模型？
使用哪个 Provider？
API 请求发到哪里？
怎么认证？
使用什么协议？
一个最小的 DeepSeek 配置类似：
model = "deepseek-v4-flash"
model_provider = "deepseek"
preferred_auth_method = "apikey"
forced_login_method = "api"
model_reasoning_effort = "high"
model_catalog_json = "~/.codex/models.json"
[model_providers.deepseek]
name = "deepseek"
base_url = "https://api.deepseek.com/"
wire_api = "responses"
experimental_bearer_token = "<你的 DeepSeek API Key>"
这段配置看起来不长，但每一行都有作用。
六、model：告诉 Codex 使用哪个模型
model = "deepseek-v4-flash"
这表示：
Codex 默认使用 DeepSeek-V4-Flash。
这里一定要使用 DeepSeek API 实际识别的模型 ID。
目前 DeepSeek 官方模型页面显示：
deepseek-v4-flash
deepseek-v4-pro
但这里有一个非常重要的限制：
当前 DeepSeek Responses API 仍只支持
deepseek-v4-flash。
所以如果你看到 deepseek-v4-pro 也能通过普通 API 调用，不代表它现在就能直接作为 Codex 的 Responses API 后端。DeepSeek 当前模型能力表明确把 Responses API 标为 Flash 支持、Pro 不支持。(DeepSeek API 文档)
七、model_provider：告诉 Codex 使用哪个提供方
配置：
model_provider = "deepseek"
下面：
[model_providers.deepseek]
这两个名字实际上是对应关系：
model_provider = "deepseek"
│
▼
[model_providers.deepseek]
所以如果你写：
model_provider = "my-provider"
那么下面就应该存在：
[model_providers.my-provider]
八、base_url：真正决定请求发到哪里
配置：
base_url = "https://api.deepseek.com/"
这一步非常关键。
它告诉 Codex：
不要把模型请求发送到默认 OpenAI 服务，而是发送到 DeepSeek API。
最终请求路径可以理解为：
Codex
│
│ POST
▼
https://api.deepseek.com/responses
│
▼
DeepSeek-V4-Flash
DeepSeek 官方 Responses API 的 Base URL 就是：
https://api.deepseek.com/
并且官方示例也是通过这个地址调用 Responses API。(DeepSeek API 文档)
九、wire_api = "responses"：这是整个配置最重要的一行
配置：
wire_api = "responses"
它的作用是告诉 Codex：
与这个 Provider 通信时，使用 Responses API 协议。
也就是说：
Codex
│
│ wire_api = responses
▼
Responses API
│
▼
DeepSeek
如果你使用的是普通 Chat Completions 接口，却告诉 Codex 使用 Responses API，就会出现接口不匹配的问题。
这也是为什么网上一些比较老的第三方 Codex 教程不能直接照抄。
十、preferred_auth_method 和 forced_login_method
配置：
preferred_auth_method = "apikey"
forced_login_method = "api"
这两个配置解决的是另外一个问题：
Codex 到底使用什么方式进行身份认证？
我们现在不走：
ChatGPT 登录
而是：
API Key
因此：
preferred_auth_method = "apikey"
表示优先使用 API Key。
而：
forced_login_method = "api"
进一步告诉 Codex：
当前使用 API 模式，而不是 ChatGPT 账号登录模式。
DeepSeek 官方的 Codex 配置正是这样设置的。(DeepSeek API 文档)
十一、experimental_bearer_token 是什么？
配置：
experimental_bearer_token = "<你的 DeepSeek API Key>"
这里放的是：
DeepSeek API Key
例如：
sk-xxxxxxxxxxxxxxxx
它最终对应 HTTP 请求中的 Bearer Token。
可以理解成：
Codex
│
▼
experimental_bearer_token
│
▼
DeepSeek API Key
│
▼
Authorization: Bearer ...
DeepSeek 官方当前 Codex 接入文档就是通过这个字段配置 API Key。(DeepSeek API 文档)
十二、为什么还需要 models.json？
这是很多教程容易忽略、但实际上非常重要的一点。
你可能会产生一个疑问：
我已经告诉 Codex 模型名字是
deepseek-v4-flash了，为什么还需要models.json？
因为：
model = "deepseek-v4-flash"
只能告诉 Codex：
我要使用哪个模型。
但是 Codex 还需要知道：
这个模型有多大的上下文？
支持哪些推理档位？
支持什么工具？
支持什么输入？
是否支持并行 Tool Call？
应该如何显示？
最低需要什么 Codex 版本？
这些信息就是：
models.json
负责提供的。
DeepSeek 官方文档明确说明，models.json 是模型目录，用来向 Codex 声明模型元数据，包括上下文窗口、推理强度、工具调用格式等。(DeepSeek API 文档)
十三、所以两个文件的职责其实非常清晰
可以记住这张图：
~/.codex/
│
├── config.toml
│ │
│ ├── 我使用哪个模型？
│ ├── Provider 是谁？
│ ├── API 地址在哪里？
│ ├── 怎么认证？
│ └── 使用什么 API？
│
└── models.json
│
├── 模型是什么？
├── 上下文多大？
├── 支持哪些能力？
├── 推理等级有哪些？
└── Codex 应该如何使用它？
简单来说：
config.toml解决“怎么连接模型”。
models.json解决“怎么理解这个模型”。
这就是 DeepSeek 接入 Codex 最值得理解的地方。
十四、手动配置 DeepSeek
如果你想完全理解原理，可以不用脚本，自己配置。
首先确保 Codex 已经运行过一次：
codex
这样一般会创建：
~/.codex
然后：
~/.codex/
创建：
models.json
十五、models.json 应该写什么？
这里不建议博客正文把官方完整的几百行 models.json 全部展开。
因为它本质上是：
Codex 模型目录的元数据。
真正使用时，推荐直接使用 DeepSeek 官方提供的一键配置脚本生成它。
官方脚本会同时完成：
备份
↓
生成 models.json
↓
修改 config.toml
↓
校验配置
而且会保留原有 MCP、项目权限等配置。(DeepSeek API 文档)
如果你的博客是为了教学，可以告诉读者：
models.json不建议自己凭感觉填写，因为其中很多字段是 Codex 内部模型目录使用的元数据。直接使用官方脚本生成，比手工拼接更加可靠。
十六、最推荐的方式：使用 DeepSeek 官方配置脚本
如果目标是：
快速完成接入，并尽量避免手动配置错误。
推荐直接使用 DeepSeek 官方提供的配置脚本。
macOS / Linux：
bash <(curl -fsSL https://cdn.deepseek.com/api-docs/codex-deepseek-setup-en.sh)
Windows PowerShell：
irm https://cdn.deepseek.com/api-docs/codex-deepseek-setup-en.ps1 | iex
DeepSeek 官方文档目前提供这两种方式，并且脚本会自动备份原配置、生成 models.json、修改 config.toml，最后进行语法校验。(DeepSeek API 文档)
建议正式使用时直接从 DeepSeek 官方文档复制脚本地址，不要从不明博客复制第三方改写过的脚本。
十七、运行脚本之前需要准备什么？
首先：
codex
至少运行过一次。
为什么？
因为脚本需要找到：
~/.codex/
然后准备一个：
DeepSeek API Key
可以在 DeepSeek Platform 创建。
API Key 大致是：
sk-xxxxxxxx
不要把真实 Key 发到群里，也不要提交到 Git。
十八、脚本实际上帮你做了什么？
这一步特别值得理解。
你执行：
bash <(curl ...)
表面上只是：
运行脚本
实际上背后完成：
DeepSeek Setup Script
│
┌──────────────┼──────────────┐
▼ ▼ ▼
备份配置 模型目录 Provider
│ │ │
▼ ▼ ▼
backup-deepseek models.json config.toml
│ │
└──────┬───────┘
▼
Codex 可识别
而且官方脚本在写入之前还会校验：
config.toml
models.json
如果语法校验失败，会停止修改。(DeepSeek API 文档)
这比让用户手动复制一大段配置更安全。
十九、配置完成后怎么确认成功？
启动：
cd /path/to/my-project
codex
如果启动信息出现：
model: deepseek-v4-flash
说明模型配置已经生效。
DeepSeek 官方文档也明确将 Codex CLI 启动信息中的模型名称作为验证方式。(DeepSeek API 文档)
二十、第一次不要直接让 Codex 修改项目
配置完成后，不建议马上输入：
重构整个项目。
先测试最基本的模型调用：
分析一下当前项目的目录结构，不要修改任何文件。
如果能够正常返回，再测试：
找到 UserController，
分析它调用的 Service 和 Repository。
不要修改代码。
最后再：
给当前项目增加一个 /health 接口，
完成后运行测试。
这样能够逐步验证：
模型连接
↓
代码理解
↓
工具调用
↓
代码修改
↓
命令执行
二十一、为什么“能聊天”不代表“能驱动 Codex”？
这是第三方模型接入 Coding Agent 时最容易产生的误解。
普通聊天：
用户
↓
模型
↓
文本
Codex：
用户
↓
Codex
↓
模型
↓
Tool Call
↓
读取文件
↓
修改文件
↓
执行命令
↓
测试
↓
模型再次判断
所以 Codex 对模型的要求比普通聊天高很多。
DeepSeek 当前 Responses API 对 Codex 兼容尤其值得注意的是：
function
web_search
custom apply_patch
这些工具能力中，apply_patch 是专门与 Codex 场景相关的兼容项。(DeepSeek API 文档)
二十二、DeepSeek 为什么要提供 models.json？
现在再回过头看这个问题，就很好理解了。
假设 Codex 只知道：
model = deepseek-v4-flash
它还不知道：
Context Window = ?
Reasoning = ?
Tool Call = ?
Image = ?
Patch = ?
所以需要：
models.json
告诉 Codex：
DeepSeek-V4-Flash
│
├── context_window
├── reasoning levels
├── tool support
├── input modalities
├── shell type
├── model display name
└── compatibility information
官方模型目录中就包含这些元数据。(DeepSeek API 文档)
二十三、为什么不能只改 config.toml？
这是一个很重要的结论。
很多人可能会尝试：
model = "deepseek-v4-flash"
[model_providers.deepseek]
base_url = "https://api.deepseek.com/"
然后发现：
为什么 Codex 还是不能正常工作？
因为：
config.toml
主要解决：
Provider
Endpoint
Authentication
Model selection
Protocol
而：
models.json
解决：
Model metadata
所以完整方案实际上是：
Codex
│
┌───────┴────────┐
▼ ▼
config.toml models.json
│ │
│ │
怎么连接模型 怎么理解模型
│ │
└───────┬────────┘
▼
DeepSeek Model
二十四、为什么切换模型也需要修改模型目录？
例如未来你希望使用：
deepseek-v4-flash
或者其他兼容 Codex 的 DeepSeek 模型。
不仅需要：
model = "xxx"
还需要 Codex 的模型目录存在对应的模型定义。
所以 DeepSeek 官方脚本实际上把：
模型选择
+
模型元数据
+
Provider 配置
一起管理。
这也是为什么推荐使用官方脚本，而不是自己东拼西凑。
二十五、ChatGPT 桌面端也能使用吗？
可以。
DeepSeek 官方文档目前说明：
Codex CLI、ChatGPT 桌面端和 VS Code Codex IDE Extension 共享同一份配置。
也就是说：
~/.codex/
│
┌───────┼────────┐
▼ ▼ ▼
Codex CLI Desktop VS Code
│ │ │
└───────┼────────┘
▼
DeepSeek
因此一般不需要：
CLI 配一次
桌面端再配一次
VS Code 再配一次
而是：
配置 ~/.codex
↓
多个 Codex 客户端读取
DeepSeek 官方文档明确说明了这一点。(DeepSeek API 文档)
二十六、VS Code 也不需要重新配置
如果你使用 Codex IDE Extension：
VS Code
↓
Codex Extension
↓
读取 Codex 配置
↓
DeepSeek
因此安装插件之后，使用的是同一套模型 Provider 配置。(DeepSeek API 文档)
二十七、为什么切换到 DeepSeek 后历史会话可能“消失”？
这个问题也很容易让人误解。
假设之前：
ChatGPT
↓
Codex
后来切换：
DeepSeek
↓
Codex
你可能发现：
咦，我以前的 Codex 会话怎么没了？
不要马上认为数据被删除了。
DeepSeek 官方说明，Codex 会根据认证方式对会话进行分组：
ChatGPT 官方认证
│
▼
一组会话
API Provider
│
▼
另一组会话
所以切换 Provider 后，界面可能只显示当前配置对应的会话。
恢复原配置后，之前的会话仍然可以重新出现。(DeepSeek API 文档)
二十八、一个完整的调用链到底是什么？
现在把整个过程串起来。
当你执行：
codex
实际上可以把过程理解成：
① Codex 启动
│
▼
② 读取 ~/.codex/config.toml
│
▼
③ 找到 model_provider = deepseek
│
▼
④ 找到 [model_providers.deepseek]
│
├── base_url
├── wire_api
└── authentication
│
▼
⑤ 读取 ~/.codex/models.json
│
▼
⑥ 找到 deepseek-v4-flash 的模型元数据
│
▼
⑦ Codex 按 Responses API 构造请求
│
▼
⑧ https://api.deepseek.com/responses
│
▼
⑨ DeepSeek-V4-Flash
│
▼
⑩ 返回 Response / Tool Call
│
▼
⑪ Codex 继续执行 Agent 流程
这就是 DeepSeek 驱动 Codex 的完整逻辑。
二十九、如果出现 401，应该检查什么？
例如：
401 Unauthorized
第一反应检查：
API Key
确认：
experimental_bearer_token
是否正确。
以及 Key 是否已经失效。
三十、如果出现 404，重点检查什么？
如果：
404 Not Found
重点检查：
base_url
wire_api
尤其是：
wire_api = "responses"
以及：
base_url = "https://api.deepseek.com/"
因为 Codex 最终需要访问的是 Responses API。
三十一、如果提示模型不存在怎么办？
例如：
model not found
检查：
model = "deepseek-v4-flash"
是否与服务端模型 ID 一致。
同时确认：
models.json
中是否存在对应的模型定义。
三十二、如果 Responses API 调用失败怎么办？
先确认你使用的模型。
目前 DeepSeek 官方文档仍明确写着：
Responses API
↓
deepseek-v4-flash
而：
deepseek-v4-pro
目前仍没有 Responses API 支持。(DeepSeek API 文档)
所以：
model = "deepseek-v4-pro"
并不等价于：
Pro 可以直接作为 Codex 的 Responses API 后端。
这一点一定要区分。
三十三、为什么 DeepSeek-V4-Flash 特别适合这个场景？
DeepSeek 在 2026 年 7 月发布的 V4-Flash API 更新中明确提到，V4-Flash 原生支持 Responses API，并针对 Codex 等 Agentic Coding 场景进行了适配。官方公布的测试中也包含 Terminal Bench、DeepSWE、DSBench 等 Coding Agent 相关评测。(DeepSeek API 文档)
所以这里并不是简单的：
一个聊天模型
+
一个 API 兼容层
而是：
Codex
↓
Responses API
↓
DeepSeek-V4-Flash
↓
Agentic Coding
这才是这套方案真正有意思的地方。
三十四、最终配置结构
如果把整个配置浓缩成一张图：
~/.codex/
│
├── config.toml
│ │
│ ├── model
│ ├── model_provider
│ ├── authentication
│ └── model_providers.deepseek
│ │
│ ├── base_url
│ ├── wire_api
│ └── bearer_token
│
└── models.json
│
└── deepseek-v4-flash
│
├── context window
├── reasoning
├── tools
├── input modalities
└── Codex metadata
最终：
Codex
│
┌────────┴────────┐
│ │
config.toml models.json
│ │
Provider / API Model Metadata
│ │
└────────┬────────┘
▼
DeepSeek-V4-Flash
│
▼
Responses API
三十五、最推荐的实际操作方式
如果你的目标是：
我现在就想让 Codex 使用 DeepSeek。
建议直接走官方脚本。
第一步：确保 Codex 已经运行过
codex
第二步：执行 DeepSeek 官方配置脚本
macOS / Linux：
bash <(curl -fsSL https://cdn.deepseek.com/api-docs/codex-deepseek-setup-en.sh)
Windows：
irm https://cdn.deepseek.com/api-docs/codex-deepseek-setup-en.ps1 | iex
第三步：输入 DeepSeek API Key
获取 Key 后，根据脚本提示完成配置。
第四步：选择模型
当前实际以：
deepseek-v4-flash
作为 Responses API / Codex 接入示例。
第五步：启动 Codex
cd your-project
codex
如果看到：
model: deepseek-v4-flash
说明已经生效。
DeepSeek 官方脚本还会备份原来的配置，因此后续可以恢复。(DeepSeek API 文档)
三十六、最后真正应该记住的是什么？
如果把这篇文章压缩成一句话：
DeepSeek 接入 Codex 的本质，不是“把 Codex 改成 DeepSeek”，而是让 Codex 通过自定义 Model Provider，把 Responses API 请求发送到 DeepSeek，同时通过
models.json告诉 Codex 如何理解和使用这个第三方模型。
整个过程就是：
Codex
│
▼
model_provider
│
▼
DeepSeek Provider
│
┌─────────┴─────────┐
▼ ▼
base_url wire_api
│ │
▼ ▼
api.deepseek.com responses
│ │
└─────────┬─────────┘
▼
DeepSeek API
│
▼
deepseek-v4-flash
│
▼
Coding Agent
而：
config.toml
解决的是：
“怎么找到并连接模型？”
models.json
解决的是：
“Codex 应该怎样认识这个模型？”
这两个部分组合起来，才构成了完整的第三方模型接入。
三十七、几个容易踩坑的误区
最后把最容易遇到的几个问题总结一下。
| 误区 | 正确理解 |
|---|---|
| 换 API Key 就能接入 | 不够，还需要 Provider 和协议配置 |
| 支持 OpenAI API 就一定支持 Codex | 不一定，需要看 Responses API |
| Chat Completions 可以直接代替 Responses API | 不能简单等价 |
只修改 config.toml 就够了 | DeepSeek 官方方案还需要模型目录 |
model 写对就行 | 还需要模型元数据 |
deepseek-v4-pro 能调用 API，所以能直接接 Codex | 当前官方文档仍标注 Responses API 不支持 Pro |
| CLI、VS Code、桌面端分别配置 | 官方文档说明它们共享 Codex 配置 |
| 切换 Provider 后历史会话被删除 | 通常是认证方式不同导致会话分组显示不同 |
| API Key 可以写到 Git | 绝对不要 |
总结
这次真正把 DeepSeek 接入 Codex 的过程拆开以后，会发现它其实并不复杂：
Codex
↓
Provider
↓
Responses API
↓
DeepSeek
↓
deepseek-v4-flash
但真正值得学习的是背后的配置模型：
config.toml
+
models.json
+
Responses API
+
API Key
其中：
model：选择模型model_provider：选择模型提供方base_url：指定 API 地址wire_api：指定 Responses APIpreferred_auth_method/forced_login_method：走 API Key，而不是 ChatGPT 登录experimental_bearer_token：DeepSeek API Keymodels.json：向 Codex 注册第三方模型的能力和元数据
这样理解以后，以后再遇到其他第三方模型接入 Codex，就不会只知道“复制一段配置”，而是能够自己判断：
这个模型有没有 Codex 所需的 API？
↓
是不是 Responses API？
↓
工具调用是否兼容？
↓
Codex 的 Provider 怎么配置？
↓
模型元数据怎么告诉 Codex？
↓
最终请求能不能正常跑通？
这才是这篇教程真正应该让读者掌握的东西。
**注：**本文按照 DeepSeek 当前官方文档整理。DeepSeek 的 Responses API、模型支持范围和 Codex 配置方式仍可能继续变化；目前官方资料对
deepseek-v4-flash的 Responses API 支持是明确的，而deepseek-v4-pro的支持状态在不同官方页面存在时间更新滞后，因此实际操作时应以 DeepSeek 当前 API 能力页和 Codex 接入页为准。(DeepSeek API 文档)
官方参考： DeepSeek：Integrate with Codex · DeepSeek：Responses API
智能硬件社区聚焦AI智能硬件技术生态，汇聚嵌入式AI、物联网硬件开发者，打造交流分享平台，同步全国赛事资讯、开展 OPC 核心人才招募，助力技术落地与开发者成长。
更多推荐
10
0- 0
已为社区贡献1条内容
所有评论(0)