Codex 接入国产模型教程：2026 wire_api 变更后的正确配法

如果你在 2026 年照着网上流传的教程给 Codex CLI 配 DeepSeek、GLM、Kimi，大概率会直接报错。原因不是你抄错了，而是 Codex 已经彻底移除了 chat/completions 协议支持——那行几乎出现在每一篇老教程里的 wire_api = "chat"，现在会让 Codex 启动即失败。Codex 接入国产模型这件事本身没有死，但配法完全变了：Codex 如今只讲 Responses API 一种协议，而国内大模型厂商的官方接口清一色只提供 Chat Completions 端点，两边对不上。这篇教程先讲清楚变更细节和协议本质，再给出 2026 年真正能跑通的三条路线。

为什么你的 Codex 配置突然失效了

这是一次有预告、有过渡期的破坏性变更，只是国内中文社区的教程更新速度没跟上。OpenAI 官方给出的理由是：chat/completions 这套接口诞生于 GPT-3.5 时代，已经明显拖累了 Codex 迭代新能力的速度（推理链、工具调用、多轮状态都在 Responses API 里表达得更自然）。整条时间线大致如下：

问题的本质：Responses API 和 Chat Completions 差在哪

很多人以为「OpenAI 兼容」是个统一标准，只要厂商说自己兼容 OpenAI，换个 base_url 就能通用。实际上「OpenAI 兼容」在 2026 年已经分裂成两套东西：

• Chat Completions（/v1/chat/completions）——老标准，请求体核心是一个 messages 数组。国内厂商说的「OpenAI 兼容」99% 指的是这一套。
• Responses API（/v1/responses）——OpenAI 2025 年推出的新接口，把推理过程、工具调用、多轮上下文合并成一个有状态的模型，请求体结构和 Chat Completions 并不一样。
• Codex 发出去的请求是 Responses 格式。国内厂商的服务端看到这种请求体只会返回 400 或字段缺失错误，因为它根本没有对应的路由和解析逻辑。

所以解决思路只有一条：在 Codex 和上游模型之间插一层，把 Responses 请求翻译成 Chat Completions 发给上游，再把上游返回的 SSE 流重新打包成 Responses 格式吐回给 Codex。区别只在于这层翻译由谁来做——你本机的代理、中转服务商，还是模型运行时本身。

三条能跑通的路线（先看这张表）

路线一：本地协议转换代理（推荐，最省事）

目前中文社区用得最多的方案是 CC Switch 这类本地代理工具。它内置了 DeepSeek、Kimi、MiniMax、硅基流动等常见 Chat 协议厂商的预设，本机起一个监听端口，把 Codex 发来的 Responses 请求转成 Chat Completions 发给上游，再把响应流反向重组。操作步骤：

1. 1在 CC Switch 的 Codex 标签页新增供应商，选内置的 DeepSeek（或 GLM / Kimi）预设，填入你在厂商官网申请的 API Key 并保存。
2. 2进入「设置 → 路由」页，打开主路由开关（默认监听 127.0.0.1:15721），再把「Codex」这一项的路由开关也打开。
3. 3在 Codex 供应商列表里启用刚才那个 DeepSeek 供应商。
4. 4重启 Codex 终端会话，让它重新加载 ~/.codex/config.toml。

工具会自动帮你把 ~/.codex/config.toml 写成下面这个样子——注意 base_url 指向的是本机代理端口，而 wire_api 依然是 responses（因为对 Codex 来说，它面前这个代理就是一个标准的 Responses 服务端）：

# ~/.codex/config.toml
model = "deepseek-v4-pro"
model_provider = "deepseek"

[model_providers.deepseek]
name = "DeepSeek (local routing)"
# 关键：指向本机代理，而不是 https://api.deepseek.com
base_url = "http://127.0.0.1:15721/v1"
env_key = "DEEPSEEK_API_KEY"
# 关键：2026 年这里只能是 responses，写 chat 会直接启动失败
wire_api = "responses"
request_max_retries = 4

路线二：用原生支持 Responses API 的中转网关

如果你不想在本机多开一个常驻进程，可以直接用已经在服务端实现了 /v1/responses 的聚合网关（OpenRouter、AiHubMix 这类）。它们把翻译工作做在自己机房里，你在 Codex 里只需要填网关地址和网关的 Key，模型名换成网关的命名即可。配置长这样：

# ~/.codex/config.toml
model = "deepseek-v4-pro"          # 具体模型 ID 以网关文档为准
model_provider = "gateway"

[model_providers.gateway]
name = "Aggregator Gateway"
base_url = "https://your-gateway.example.com/v1"
env_key = "GATEWAY_API_KEY"
wire_api = "responses"

# 有些网关要求带自定义头做路由或计费归属
[model_providers.gateway.http_headers]
"X-Title" = "codex-cli"

选网关时务必先确认一件事：它是否真的暴露了 /v1/responses 端点。不少中转商宣传的「全面兼容 OpenAI」其实只做了 Chat Completions，接 Codex 一样会失败。最快的验证方法是直接 curl 一下这个端点，看返回的是正常响应还是 404。

# 验证网关是否真的实现了 Responses API
curl -i https://your-gateway.example.com/v1/responses \
  -H "Authorization: Bearer $GATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-v4-pro","input":"ping"}'

# 404 / Not Found  → 这家只做了 chat/completions，接不了 Codex
# 200 或正常业务报错 → 端点存在，可以继续配

路线三：本地模型走内置 provider

Codex 内置了 openai、ollama、lmstudio 三个 provider id，它们不能被自定义配置覆盖。官方在弃用公告里明确推荐：跑本地开源模型的用户走 LM Studio，因为它已经实现了 Responses API；Ollama 侧的 Responses 支持在公告发布时还处于「计划中」状态，接入前建议先确认你装的版本是否已经支持。

# 用 LM Studio 跑本地模型（它自身实现了 responses 端点）
oss_provider = "lmstudio"
model = "qwen3-coder-30b"   # 换成你在 LM Studio 里实际加载的模型 ID

这条路线的好处是代码完全不出本机、没有 token 费用；代价是本地能跑动的模型（一般 7B～32B）在长上下文、多步工具调用上明显弱于云端旗舰模型，做小改动尚可，扛复杂重构会比较吃力。

config.toml 字段速查

用户级配置在 ~/.codex/config.toml，项目级配置在项目里的 .codex/config.toml（只有项目被标记为受信任时才加载，且不能覆盖机器本地的 provider、认证、遥测等敏感键）。自定义 provider 的可用字段：

顶层的 model 和 model_provider 决定默认用哪个供应商的哪个模型，其中 model_provider 的值要能对应上某个 [model_providers.<id>] 表的 id。如果你想在官方模型和国产模型之间快速切换，Codex 还支持 profile 机制，用 codex --profile <名字> 切换配置组。

# 用指定 profile 启动（配置组名字对应你的 profile 配置文件）
codex --profile deepseek

# 查看当前生效的配置来源，排查「改了没生效」最快的一招
codex --help

国内主流模型接入信息速查

常见报错排查

配不动？换个 CLI 可能更省心

说句实在话：如果你的核心诉求只是「用国产模型做终端 AI 编程」，而不是非 Codex 不可，那绕开这个协议问题是更划算的选择。Claude Code 走的是 Anthropic 协议，智谱、月之暗面等厂商都直接提供了官方兼容端点，配两个环境变量就能用；Qwen Code、iFlow CLI、CodeBuddy 这些国产 CLI 更是原生对接国内模型，零折腾。Codex 的优势在于它和 OpenAI 自家模型的配合最默契、apply_patch 这类编辑能力打磨得很细——如果你就是冲着这些来的，再花时间搭翻译层才值得。

工具配置只是入门门槛，真正拉开差距的是你怎么组织上下文、怎么把需求拆成 AI 能稳定完成的任务、以及怎么审查它写出来的代码。IMAI 的体系化课程就是围绕这些真正决定产出质量的环节展开的——从终端 AI 编程工具链的搭建，到用 AI 做出能交付的完整产品，欢迎来看看。