DeepSeek V4 Pro 可以通过 DeepSeek 原生支持的 Responses API 驱动 Codex。它的官方模型 ID 是 deepseek-v4-pro，DeepSeek 文档提供 low、high、max 三档 reasoning effort（思考强度）。更安全的配置顺序是：备份 Codex 共享配置，选择经过检查的官方脚本或手动路径，用小任务验证 Provider 和模型，再在大型 Agent 任务前检查官方实时价格。
这里刻意把两个概念分开：DeepSeek V4 Pro 是模型后端，Codex 是操作文件和工具的 Agent harness。如果这两层仍然容易混淆，修改配置前可以先看 Agent harness 和 Model 的区别。
Codex 能不能使用 DeepSeek V4 Pro？
可以。DeepSeek 的 V4 Pro 发布说明给出了 deepseek-v4-pro 这个 API 模型 ID，并列出 low、high、max 三档思考强度。另一份 Codex 官方接入指南说明，DeepSeek API 支持 Codex 使用的 Responses API。
这不会让 DeepSeek V4 Pro 变成 OpenAI 官方模型，也不代表 DeepSeek、OpenAI 或 Agent.Space 共同运营这项接入。这里发生的是：Codex 通过兼容的 API 协议调用第三方模型 Provider。因此，计费、模型行为、可用性和数据处理方式都需要按照实际配置的 Provider 账户来评估。
修改 Codex 配置前先做什么
开始配置前先做四件事：
- 至少启动一次 Codex。 DeepSeek 指南要求先让 Codex 配置目录存在，再由配置流程进行修改。
- 备份
~/.codex/config.toml。 这个文件不只服务眼前的一个终端 Session。根据接入指南，Codex CLI、ChatGPT 桌面端中的 Codex 和 Codex IDE extension 会共用它。 - 准备 DeepSeek API Key，但不要泄露。 不要把 Key 粘贴进代码仓库、截图、文章、Issue 或共享的 Shell History。DeepSeek 当前的手动示例会把凭证写入
~/.codex/config.toml；要把这个文件当作秘密文件限制访问，绝不能提交、截图或分享。 - 决定是否允许自动脚本修改这份共享文件。 官方脚本更方便，但先检查下载脚本会改什么，是合理的安全步骤。手动路径慢一点，却更容易审计。
备份不是多余动作。切换 Provider 可能影响不止当前 Codex 窗口，而且官方记录的 Session 行为也与当前登录和配置路径有关。
两种官方配置路径
DeepSeek 提供自动脚本和手动配置两种方式。无论选哪一种，最终都要确认四项状态：Provider 是 DeepSeek、Provider Base URL 是 https://api.deepseek.com/、Wire API 是 responses，并且实际准备使用的模型是 deepseek-v4-pro。
方案一：检查后使用官方配置脚本
当前指南分别提供 macOS/Linux 和 Windows 脚本。官方说明显示，脚本会询问 API Key、备份已有配置、写入 Codex 使用的模型目录、修改 config.toml，然后验证结果。
应该打开当前 DeepSeek Codex 配置页，不要从一篇旧文章直接复制命令。如果环境要求审查变更，先检查脚本，再按对应操作系统的说明执行。完成后确认激活的是 deepseek-v4-pro；配置工具里的示例或默认模型不一定就是本文讨论的模型。
方案二：手动配置 Provider
如果希望看清每一项改动，可以按照同一官方指南中的手动配置部分操作。至少要核对：
- 顶层 Model 指向
deepseek-v4-pro； - 当前选择的 Provider 是 DeepSeek；
- Provider Base URL 与当前 DeepSeek API Endpoint 完全一致；
- Wire API 是
responses； - 凭证只保存在当前官方 Codex/DeepSeek 配置要求的位置；
- 模型目录文件和 Context 设置来自当前官方示例，而不是旧教程。
不要混用多篇指南里的配置片段。只更新一部分的 Provider Block 看起来可能合理，但会让 Codex 访问错误 Endpoint 或错误模型。一次只做一项受控修改，保存后启动一个新的低风险 Codex 任务来验证响应。
无论使用哪一种方式，都记录修改前的备份位置，以及修改后的 Provider 和 Model 名称。这两项信息会让回滚比凭记忆重建配置容易得多。
low、high、max 应该怎么选
DeepSeek 为 V4 Pro 记录了三档 reasoning effort，但这不等于每个 Coding 任务都应该使用 max。可以从下面这套起始策略开始：
这张表是工作流建议，不是 Provider Benchmark。合适档位取决于仓库、Prompt、工具和验收标准。先用能可靠完成任务的最低档，通过测试或 Review 验证结果，只有具体失败原因需要时再提高思考强度。
怎么判断价格是否适合
不要只复制一个 Token 单价，就把它当成一次 Coding 任务的成本。DeepSeek 的 API 实时价格页分别列出缓存命中输入、未命中输入和输出价格，也可能提供分时折扣。数字和时段会变化，所以估算或发布当天都要使用当前表格。
估算 Agent 工作流时，要把这些部分算进去：
- 第一次输入： 指令、仓库 Context、附加文件和系统 Context。
- 重复输入： 多轮对话中再次发送的 Context；缓存行为会明显改变实际输入成本。
- 工具输出： Command 结果、Diff 和重新进入 Context 的文件内容。
- 模型输出： 解释、计划、Patch 和总结。
- 重试与分支： 失败尝试或并行探索可能成倍增加总量，即使最后答案很短。
- 思考策略： 更高档位可能值得使用，但它应该是一项明确决策，而不是看不见的默认值。
最简单且有用的做法是估算一个范围：普通任务、长 Context 任务和重试较多的任务。分别套用当前官方输入和输出价格，再在 Provider 或 Client 支持的地方设置消费或使用边界。这样比只比较宣传页上的输出单价更接近真实决策。
共享配置、Session 与回滚
DeepSeek 指南说明，受支持的 Codex 客户端会共用 ~/.codex/config.toml。因此要把它当成影响范围更大的配置变更：
- 切换 Provider 前，先结束或保存重要工作；
- 保留改动前生成、带日期的备份；
- 记录新 Session 实际使用的 Model 和 Provider；
- 不要因为旧 Session 在新登录路径下看不到，就直接删除旧配置。
同一份指南还说明，Session History 会按登录方式分组。切换 Provider 或登录方式后，旧 Session 可能像是消失了；恢复之前的配置后，它又会重新出现。这是身份与配置边界，并不必然表示工作已经被删除。
如果新配置失败，先回滚到已知可用的备份，重启相关 Codex Client，再确认 Provider 和一个旧 Session，然后才进行下一项修改。不要在已经不确定的配置上继续叠加多项猜测性改动。
V4 Pro 是否适合你的 Codex 工作流
DeepSeek V4 Pro 是一个候选项，不是自动适合所有人的默认答案。应该围绕实际任务判断：
- 兼容性： 当前 DeepSeek 配置能否在你使用的 Codex Client 中正常工作？
- 任务质量： 在合理的思考强度下，结果能否通过仓库的测试和 Review 标准？
- 成本可见性： 能否根据真实任务记录估算输入、输出、缓存与重试成本？
- 运维边界： API Key 管理、Provider 条款和数据路径是否符合项目要求？
- 可替换性： 能否更换模型，而不必重建 Workspace 或失去需要保留的任务 Context？
Agent.Space 中的 DeepSeek harness 指南讨论的是另一层：使用面向 DeepSeek 的 Agent 环境，而不是把 DeepSeek V4 Pro 配置成 Codex 背后的模型。要做更广的 API 决策，可以看 Agent.Space Developer API 指南中的模型发现和配置路径。不要先假定某个模型已经可用，最终以实时目录为准。
结论
要在 Codex 中使用 DeepSeek V4 Pro，先备份共享 Codex 配置，选择一条当前官方配置路径，指定 deepseek-v4-pro，再用容易撤销的小任务验证。主动选择思考强度，用 DeepSeek 实时价格表估算完整 Agent Loop 的成本，并保留旧配置以便回滚。
如果还想比较一条独立 API 路径，可以查看当前 Agent.Space Developer API的模型目录、配置和价格。可用范围会变化，因此最终产品支持状态应以实时页面为准，而不是以本文为准。