折腾一下 Codex 接上 DeepSeek 了：CLI 和 App 都能用

胡琦

发布于 2026-05-20 15:47:09

10.8K0

文章被收录于专栏：胡琦胡琦

大家好，我是胡琦。

最近有好几个朋友都问我 Codex 怎么使用 DeepSeek 模型，其中原由是 OpenAI 接口从原来的 Chat Completions API 演进到了 Responses API。

像Codex 这类 AI 编程 Agent，本质上已经不是简单的“发一句话、回一段文本”了。它需要读项目、调用工具、生成补丁、执行命令、处理多轮状态。OpenAI 的接口也从早期 Completions API，逐步演进到 Chat Completions API，再到更适合 Agent 场景的 Responses API。

所以这次接入 DeepSeek 的关键点，不只是“换一个模型地址”，而是要让 DeepSeek 能够接住 Codex 发出的 Responses API 风格请求。Moon Bridge 做的，正是这一层适配和转发。

我看到 DeepSeek 官方的 awesome-deepseek-agent 仓库里整理了一篇「接入 Codex」的文档。

原文讲的是：通过 Moon Bridge 做一层本地转发，让 Codex 可以把请求转到 DeepSeek 模型上。Codex 是 OpenAI 的编程 Agent，支持 CLI 和 App 使用；它使用 OpenAI Responses API 与模型通信，所以这里需要 Moon Bridge 作为转发层。(GitHub[1])

我自己实测了一下，发现不只是 Codex CLI 可以用，codex.app 也是可以用的。

也就是说，这条链路可以变成：

Codex CLI / codex.app
        ↓
读取同一份 Codex 配置
        ↓
请求本地 Moon Bridge
        ↓
Moon Bridge 转发到 DeepSeek V4 Pro

一、为什么需要 Moon Bridge？

Codex 本身是按照 OpenAI Responses API 来和模型通信的。

但 DeepSeek 并不是直接以 Codex 预期的 Responses API 方式接入，所以中间需要一个适配层。原文使用的是 Moon Bridge，它的作用可以理解成：

Codex 以为自己在调用一个 OpenAI Responses API 兼容服务，实际上请求先打到本地 Moon Bridge，然后再由 Moon Bridge 转发到 DeepSeek。

这也是整个方案最关键的地方。

它不是让 Codex 原生支持 DeepSeek，而是通过本地转发层，把 Codex 的调用方式和 DeepSeek 的模型能力接起来。

二、先准备环境

开始之前，需要准备这些东西：

1. Node.js 18+
2. Go 1.25+
3. Codex CLI
4. DeepSeek API Key
5. Moon Bridge 项目

原文要求 Node.js 18+、Go 1.25+，并通过 npm 安装 Codex CLI。(GitHub[1])

安装 Codex CLI：

npm install -g @openai/codex

或者安装 Codex.app : https://chatgpt.com/codex

验证一下安装是否成功：

codex --version
go version

这里我建议先把 CLI 跑通。原因很简单：CLI 的日志和报错更直接，适合排查链路问题。等 CLI 跑通之后，再切到 codex.app，体验会更自然。

三、获取 DeepSeek API Key

接下来，到 DeepSeek 开放平台创建并复制 API Key。原文第二步也是要求前往 DeepSeek 开放平台创建 API Key。(GitHub[1])

拿到 Key 后，后面会写进 Moon Bridge 的 config.yml。

获取DeepSeek API Key： https://platform.deepseek.com/api_keys

四、配置 Moon Bridge

先克隆 Moon Bridge 项目：

git clone https://github.com/ZhiYi-R/moon-bridge.git
cd moon-bridge
# 切换到指定 commit
git reset --hard 4dd578afb25a5389c3f658390ac49a6190efcf52

然后创建 config.yml。

原文给出的最小配置如下，核心是启用 DeepSeek V4 Pro，并把默认模型路由到 moonbridge。(GitHub[1])

mode: "Transform"

server:
  addr: "127.0.0.1:38440"

models:
  deepseek-v4-pro:
    context_window: 1000000
    max_output_tokens: 384000
    extensions:
      deepseek_v4:
        enabled: true
    default_reasoning_level: "high"
    supported_reasoning_levels:
      - effort: "high"
        description: "High reasoning effort"
      - effort: "xhigh"
        description: "Extra high reasoning effort"
    supports_reasoning_summaries: true
    default_reasoning_summary: "auto"

providers:
  deepseek:
    base_url: "https://api.deepseek.com/anthropic"
    api_key: "sk-your-deepseek-api-key"
    user_agent: "moonbridge/1.0"
    web_search:
      support: "auto"
    offers:
      - model: deepseek-v4-pro
        pricing:
          input_price: 2
          output_price: 8
          cache_write_price: 1
          cache_read_price: 0.2
        
routes:
  moonbridge:
    model: deepseek-v4-pro
    provider: deepseek

这份配置里有几个关键点。

第一，Moon Bridge 本地监听：

server:
  addr: "127.0.0.1:38440"

第二，DeepSeek 的 API 地址和 API Key：

base_url: "https://api.deepseek.com/anthropic"
api_key: "sk-your-deepseek-api-key"

第三，对外暴露的模型名是：

routes:
  moonbridge:
    model: deepseek-v4-pro
    provider: deepseek

也就是说，后面 Codex 侧不需要直接感知 deepseek-v4-pro，它只要访问 deepseek 这个模型名即可。

如果后面你还想扩展图片输入、Web Search 或多 Provider 路由，可以再参考 Moon Bridge 的 config.example.yml 扩展配置。原文也提到，这份最小配置之外，可以继续扩展图片输入、Web Search 和多 Provider 路由。(GitHub[1])

五、启动 Moon Bridge

配置好之后，在 Moon Bridge 项目目录下启动服务：

go run ./cmd/moonbridge --config config.yml

启动后，这个终端需要保持运行。

默认情况下，Moon Bridge 会监听：

127.0.0.1:38440

并提供 OpenAI Responses 兼容接口：

http://127.0.0.1:38440/v1/responses

原文也明确写到，Moon Bridge 默认监听 127.0.0.1:38440，并提供 /v1/responses 接口。(GitHub[1])

到这里，本地转发层就已经起来了。

六、生成 Codex 配置

接下来，另开一个终端，在 Moon Bridge 目录下生成 Codex 需要的配置文件。当然如果 Codex 已经配置 config.toml，只需补充：

model_provider = "deepseek"
model = "deepseek-v4-pro"

[model_providers.deepseek]
name = "deepseek"
base_url = "http://127.0.0.1:38440/v1"
wire_api = "responses"

[model_properties."deepseek-v4-pro"]
context_window = 262144
max_context_window = 1048576
supports_parallel_tool_calls = true
supports_reasoning_summaries = true
input_modalities = ["text"]

这一步会生成两个核心文件：

config.toml
models_catalog.json

执行下面这段命令：

CODEX_HOME_DIR="${CODEX_HOME:-$HOME/.codex}"
mkdir -p "$CODEX_HOME_DIR"

MODEL="$(go run ./cmd/moonbridge --config config.yml --print-codex-model)"

go run ./cmd/moonbridge \
  --config config.yml \
  --print-codex-config "$MODEL" \
  --codex-base-url "http://127.0.0.1:38440/v1" \
  --codex-home "$CODEX_HOME_DIR" \
  > "$CODEX_HOME_DIR/config.toml"

原文说明，这一步会写入 Codex provider 配置，并使用 wire_api = "responses"；同时生成 models_catalog.json，里面包含模型能力元数据，比如上下文窗口、推理档位和工具支持。(GitHub[1])

可以检查一下目录：

ls -la "$CODEX_HOME_DIR"

正常应该能看到类似：

config.toml
models_catalog.json

这两个文件非常关键。Codex 能不能识别模型，基本就看这里。

七、启动 Codex CLI

现在进入你真正要处理的项目目录：

cd /path/to/my-project
CODEX_HOME="$CODEX_HOME_DIR" codex --cd "$PWD"

如果前面的配置都正确，Codex CLI 会把 OpenAI Responses 请求发送给 Moon Bridge，再由 Moon Bridge 路由到 DeepSeek V4。原文第 6 步也是这样描述的。(GitHub[1])

这时就可以像平时使用 Codex 一样，让它：

读代码
解释代码
修改代码
生成补丁
跑测试
定位 bug

我建议第一次测试不要上来就让它改大工程，可以先让它做一个很小的任务，比如：

请阅读这个项目的 README，总结项目结构。

或者：

请分析程序运行的调用链，不要修改代码。

先确认模型能正常响应，再逐步增加复杂度。

也可以去模型服务后台看看，确认有被调用：

八、codex.app 也可以用

这里是我实测后觉得最值得补充的一点：

codex.app 也是可以用的。

原文里也写了一句：Codex App 可以使用同一份生成的 Codex 配置。(GitHub[1])

我的理解是，关键不在于你用 CLI 还是 App，而在于 Codex 能不能读到这份配置：

config.toml
models_catalog.json

只要这份配置生成正确，Moon Bridge 正常运行，codex.app 就可以和 CLI 一样，通过本地的 Moon Bridge 转发请求到 DeepSeek。

所以完整链路是：

codex.app
   ↓
读取 Codex 配置
   ↓
请求 http://127.0.0.1:38440/v1
   ↓
Moon Bridge
   ↓
DeepSeek V4 Pro

我自己的建议是：

先用 Codex CLI 跑通链路。
再打开 codex.app 验证。
如果 App 里异常，再回到 CLI 和 Moon Bridge 日志里排查。

这样排错会简单很多。

九、一键启动脚本

如果不想每次手动执行这么多步骤，Moon Bridge 也提供了一个面向 Codex CLI 的辅助脚本。

原文给出的命令是：

./scripts/start_codex_with_moonbridge.sh --project-directory /path/to/my-project

这个脚本可以一键构建并启动代理、生成 Codex 配置并启动 Codex。(GitHub[1])

【配图占位：一键启动脚本执行截图】

不过我个人更建议第一次手动跑一遍。

因为手动跑一遍，你会清楚知道每一步分别在做什么：

Moon Bridge 有没有启动？
Codex 配置写到哪里了？
本地端口是不是 38440？
Codex 请求有没有打到 /v1/responses？
DeepSeek API Key 有没有生效？

等链路理解清楚之后，再用一键脚本就很舒服。

十、如何验证是否接通？

可以先查看 Moon Bridge 暴露出来的模型列表：

curl http://127.0.0.1:38440/v1/models

再发送一条 Responses 测试请求：

curl http://127.0.0.1:38440/v1/responses \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonbridge",
    "input": "请用一句话打个招呼。",
    "max_output_tokens": 100
  }'

原文也提供了这两种验证方式：查看 /v1/models，以及向 /v1/responses 发送测试请求。(GitHub[1])

当 Codex 发起请求后，Moon Bridge 终端里应该能看到类似日志：

POST /v1/responses

原文也提到，Codex 发出请求后，Moon Bridge 终端应出现 POST /v1/responses 日志。(GitHub[1])

如果能看到这个日志，说明 Codex 的请求已经打到 Moon Bridge 了。

如果此时模型也能正常回复，那整条链路基本就是通的。

十一、常见问题

1. connection refused

这个一般是 Moon Bridge 没启动，或者端口不一致。

重点检查：

server:
  addr: "127.0.0.1:38440"

以及你请求的地址是不是：

http://127.0.0.1:38440/v1

原文的常见问题里也说明，connection refused 通常是 Moon Bridge 未启动，或者 server.addr 使用了其他端口。(GitHub[1])

2. Codex 看不到模型

重新执行生成 Codex 配置的步骤。

重点确认：

config.toml

是否真的生成到了 CODEX_HOME 目录下。

3. 401 或认证失败

检查 config.yml 里的 DeepSeek API Key。

重点看这几个问题：

Key 有没有复制完整？
Key 前后有没有多余空格？
是不是用了旧 Key？
是不是把 sk-your-deepseek-api-key 忘记替换了？

4. 402 或余额错误

这个一般就是 DeepSeek 开放平台账户余额问题。

去控制台检查账户余额和计费状态即可。

原文也把 402 归为余额错误，需要检查 DeepSeek 开放平台账户余额。(GitHub[14])

5. 图片输入失败

如果启用了 Visual 扩展，需要单独配置视觉 Provider，比如 Kimi 的 API Key。

如果暂时不需要图片输入，可以先移除：

visual.enabled: true

先把文本链路跑通。

原文也提到，如果启用了 Visual 扩展，需要单独配置视觉 Provider；也可以移除 visual.enabled: true 来禁用 Visual 扩展。(GitHub[1])

十二、我对这个方案的理解

这个方案本质上做的是一件事：

用 Moon Bridge 把 Codex 的 OpenAI Responses API 调用，转发到 DeepSeek。

所以它的价值不只是“能跑”，而是把几个东西解耦了。

第一，Codex 侧不用大改

Codex 仍然按照自己熟悉的 Responses API 方式工作。

它不需要直接理解 DeepSeek 的接口细节，也不需要为 DeepSeek 单独写一套 Codex 适配逻辑。

第二，模型路由更灵活

Moon Bridge 在中间承担了 provider、model、routing、metadata 这些工作。

今天可以路由到 DeepSeek，后面理论上也可以扩展到更多模型或更多能力。

这对于喜欢折腾本地 AI 工具链的人来说很有价值。

第三，CLI 和 App 可以复用同一套配置

这个是我实测后最喜欢的一点。

因为很多时候 CLI 适合调试，但 App 更适合日常使用。

所以比较舒服的工作流是：

用 CLI 跑通链路和日志
用 codex.app 做日常开发
Moon Bridge 作为本地转发层常驻

十三、完整流程总结

最后，把完整流程压缩一下：

1. 安装 Node.js 18+ 和 Go 1.25+
2. 安装 Codex CLI
3. 获取 DeepSeek API Key
4. 克隆 Moon Bridge
5. 编写 config.yml
6. 启动 Moon Bridge 本地服务
7. 生成 Codex 的 config.toml 和 models_catalog.json
8. 先用 Codex CLI 测试链路
9. 再用 codex.app 复用同一份配置
10. 通过 Moon Bridge 日志排查请求是否打通

这条路线最有意思的地方，是把 Codex 的 Agent 体验 和 DeepSeek 的模型能力 接到了一起。

我实测下来，CLI 能跑，App 也能跑。

如果你也在折腾 AI 编程工具，这个方案值得试一下。