Codex CLI 接入 DeepSeek/Qwen：本地 Bridge 代理方案全流程

API配置与调试低代码/无代码命令行工具应用搭建开发工作流开源模型模型性价比端侧部署长上下文推理

2026-05-25 10:51

892 浏览

0 点赞

AI 速览

介绍通过本地Bridge代理方案，在终端工具Codex CLI中接入DeepSeek-V4-Pro和Qwen3.7-Max等第三方大模型的完整流程。核心事实 - 协议冲突：Codex 0.133版本后强制使用OpenAI Responses API，导致第三方模型无法直接连接 - 解决方案：部署本地Bridge代理（如deepseek-claude-setup）进行协议翻译，实现Responses API与Chat Completions或Anthropic Messages的互通 - DeepSeek接入：申请API Key，启动代理服务，配置环境变量指向localhost:3000即可调用 - Qwen接入：需支持Anthropic Messages协议翻译，注意tool use格式兼容性，配置config.toml指定base_url和token 价值点为开发者提供绕过官方限制、低成本使用高性能国产模型进行本地代码辅助开发的实操指南。

Codex CLI 一直是今年开发者圈子里最容易被忽视的工具之一。你在终端里说一句"帮我重构这个函数"，它会自己去读文件、改代码、跑测试，整套流程不用你复制粘贴，Agent 能力基本是开箱即用的。

但问题也恰好出在这里——0.133 版本之后，Codex 强制切换到了 OpenAI 的 Responses API，这是 OpenAI 自家的协议规范，DeepSeek-V4-Pro、Qwen3.7-Max 这类第三方模型根本不认。你把第三方的 API key 直接填进去，大概率收到 model_not_found 或类似报错。

Codex CLI 接入 DeepSeek/Qwen：本地 Bridge 代理方案全流程

这不是你的配置写错了，是两种协议在说不同的"方言"。Codex 说的是 Responses API，而第三方模型只听得懂 Chat Completions 或 Anthropic Messages 这两套规范。

问题根源：协议不兼容

Codex 的 Responses API 和第三方模型的协议差异，本质是架构层面的分歧，不是功能上的缺失。改 Codex 源码？太重了，也不现实。

真正可行的办法是在本地起一个 Bridge 代理：让 Codex 以为自己还在跟 OpenAI 说话，但所有请求实际上都被代理拦截，翻译成第三方模型能理解的格式，再把响应包回 Responses API 的结构返回给 Codex。整个链路大概是这样的：

Codex CLI（Responses API）
    ↓
本地 Bridge 代理（协议翻译）
    ↓
DeepSeek-V4-Pro / Qwen3.7-Max

代理跑在本地，Codex 把请求发到 http://localhost:3000，代理完成翻译后转发给对应的 API 端点，响应再原路包回来。你不需要动 Codex 一行代码，只需要配一个环境变量让它把请求指向本地代理。

DeepSeek-V4-Pro：三步跑通

目前最成熟的 Bridge 方案是 deepseek-claude-setup 这个 Node.js 项目，专门做 Responses API ↔ Chat Completions 的翻译。

第一步，去 DeepSeek 开放平台（platform.deepseek.com）申请 API key，新用户有赠送额度，够用来测试。

第二步，启动 Bridge 代理：

npx deepseek-claude-setup@latest

它会自动检查环境、安装依赖、启动代理服务，默认监听 localhost:3000。

第三步，配置 Codex 指向代理：

export OPENAI_BASE_URL="http://localhost:3000"
export OPENAI_API_KEY="your-deepseek-api-key"

codex "分析这个项目的依赖冲突"

Codex 以为自己连的是 OpenAI，但所有请求都已经被代理转给了 DeepSeek-V4-Pro。

Qwen3.7-Max：进阶接入

Qwen3.7-Max 的接入思路相同，但协议翻译方向不一样——它走的是 Anthropic Messages API，所以 Bridge 代理需要做的是 Responses API ↔ Anthropic Messages 的双向翻译。

Qwen3.7-Max 有一个值得关注的优势：上下文窗口支持 1M tokens，处理超大型代码库时比很多模型宽松得多。

不过有一点要注意：Qwen3.7-Max 的 tool use（函数调用）格式和 OpenAI 规范存在细微差别。如果 Bridge 代理版本较旧，可能在 Codex 发起工具调用后，代理解析响应时出错。解决方式是确认代理支持完整的 tool use 翻译链路，别用太旧的版本。

config.toml 完整配置（Qwen3.7-Max）：

model_provider = "qwen_local"
model = "qwen3.7-max"
model_reasoning_effort = "high"
disable_response_storage = true

[model_providers.qwen_local]
name = "Qwen Local Proxy"
base_url = "http://127.0.0.1:17862/v1"
wire_api = "responses"
experimental_bearer_token = "sk-xxxxxx"
request_max_retries = 0
stream_max_retries = 0
stream_idle_timeout_ms = 600000

[features]
goals = true

[profiles.default]
model_provider = "qwen_local"
model = "qwen3.7-max"
model_reasoning_effort = "high"

几个关键字段说明一下：wire_api 固定写 responses，让 Codex 以为在跟 OpenAI 通信；stream_idle_timeout_ms 设成 600000（10分钟），防止长推理任务超时断开；disable_response_storage 关掉 OpenAI 的响应存储，第三方模型不支持这个特性。

DeepSeek-V4-Pro 的配置结构一样，把 model 改成 deepseek-v4-pro，base_url 指向 DeepSeek Bridge 代理的端口（通常是 3000），experimental_bearer_token 换成 DeepSeek 的 API key 即可。

如果嫌每次手动改 config.toml 麻烦，可以用 cc-switch 管理多个配置：

cc-switch deepseek   # 切换到 DeepSeek-V4-Pro
cc-switch qwen       # 切换到 Qwen3.7-Max
cc-switch current    # 查看当前配置

跑不通？按这个顺序排查

配完还是有问题的话，按顺序来：

先用 codex --version 确认版本在 0.133 以上，旧版本还不强制使用 Responses API。然后用 curl http://localhost:3000/v1/models 确认代理服务正在运行，应该返回模型列表。接着直接用 curl 测试第三方 API——如果这一步报错，问题在 key 或网络，和 Codex 与代理无关。最后，用 DEBUG=* codex "你的指令" 开启详细日志，能看到 Codex 发出去的请求和收到的响应，定位问题更直接。

Bridge 代理听起来像是绕路的 hack，但在很多生产环境里这本来就是标准架构——两套协议之间的适配层，不是奇技淫巧。

通过这套方案，你能用到 Codex 的完整 Agent 能力：文件读写、代码编辑、命令执行、DeepSeek 的 Thinking 推理展示，以及正常的 tool use 调用链路。对于中文开发场景，DeepSeek-V4-Pro 和 Qwen3.7-Max 的代码理解能力已经相当扎实，加上 Codex 的 Agent 框架，整体编程体验值得认真试一试。

好文章，需要你的鼓励