Codex 升级到下一代协议，国内大模型集体 404 Not Found——不是能力问题，是接口代差——LeisureLinux
如果你使用 Codex CLI（v0.122+）搭配 DeepSeek 或阿里百炼等国内大模型，可能会遇到一个令人困惑的错误：
unexpected status 404 Not Found: Unknown error, url: https://api.deepseek.com/v1/responses
这不是模型的能力问题，也不是 API Key 的问题——这是 Codex 项目架构演进中的一个重大断层变动（Breaking Change）。本文复盘整个排查过程与解决方案。
本文看点
01
为什么 Codex 强制废弃 Chat Completions？
02
为什么国内大模型无法直连？
本地 Proxy 桥接转换方案
01
BREAKING CHANGE
为什么 Codex 强制废弃 Chat Completions？
OpenAI 在升级 Codex CLI 时，彻底将底层交互规范由传统 Chat API 迁移到了全新的 Responses API（/v1/responses） ，并硬编码锁死了 wire_api = \"responses\" 。核心技术原因包括：
原因 01 旧协议无法承载 Agentic 交互
旧的 chat/completions 诞生于 GPT-3.5 时代，本质上是「一问一答」的模型。而现代 Agent 级编程工具需要频繁进行 Tool Calling （本地执行命令、修改文件、读写 Git）、多轮 Reasoning/Thinking 思考过程交织、以及长连接 SSE/WebSocket 双向控制。这些能力在简陋的 Chat 协议上做扩展，越堆越臃肿。
原因 02 状态管理下沉到协议层
在 Responses API 下，上下文管理、Thinking 过程的暂存、Tool 回调的 ID 匹配全都在协议层标准化了。OpenAI 官方团队在 GitHub 上明确表示：为了维持兼容旧的 Chat 协议，导致代码库膨胀且极易引入 Regression（功能退化），因此 决定彻底砍掉对 wire_api = \"chat\" 的支持 ，强制仅支持 Responses 协议。
02
PROTOCOL GAP
为什么国内大模型无法直连？
这 不是 DeepSeek 等模型的能力问题 ，而是 「协议规范接口（Protocol Endpoint）」的代差 ：
「不是连不上，是鸡同鸭讲——Codex 说 Responses 语，DeepSeek 只会 Chat 语。」
DeepSeek、百炼等平台目前提供的仍然是 OpenAI 兼容规范的 Chat Completions 接口 （包含 messages 、 /v1/chat/completions 的标准 JSON 格式）。而 Codex CLI 当前发出的却是结构完全不同的 Responses API 请求 （包含 input 、 instructions 、 reasoning_effort 等字段，路由为 /v1/responses ）。当 Codex CLI 把 Responses 协议的 Payload 发给 DeepSeek 时，服务端的 Gateway 识别不到对应的接口，直接抛出 404 Not Found 。
03
SOLUTION
社区的解决方案：本地 Proxy 桥接转换
因为 Codex 在客户端代码层面做死了硬编码， 唯一的解法就是通过本地中间件（Proxy）完成双向协议转换 ：
FLOW
[ Codex CLI ] ─── /v1/responses ───→ [ 本地 Proxy ]
↓ 协议转换桥接
[ 国内平台 (DeepSeek / 百炼) ] ←── /v1/chat/completions
TOOL 1 CC Switch
提供本地路由服务，专为 Codex 这种强绑定 Responses API 的 CLI 工具设计。自动把 Codex 发出的 /v1/responses 请求实时拦截，重写映射回 DeepSeek 的 /chat/completions 格式。
TOOL 2 codeproxy-ai/cli
基于 Node.js 的轻量级通用本地代理。支持请求体转化、SSE 流式输出转译、Thinking/Reasoning 思考过程回传以及 Tool Calling 的拦截映射。安装方式：
npm install -g \@codeproxy/cli
codeproxy \\
--base-url https://api.deepseek.com/v1 \\
--model deepseek-v4-flash \\
--apikey \\\"\$DEEPSEEK_API_KEY\\\" \\
--upstream-format openai-chat
proxy 默认监听 127.0.0.1:8787 。然后在 Codex 的 \~/.codex/config.toml 中，将 base_url 改为指向本地 proxy：
CONFIG
[model_providers.deepseek]
name = \"DeepSeek\"
base_url = \"http://127.0.0.1:8787/v1\"
env_key = \"DEEPSEEK_API_KEY\"
TOOL 3 openai/codex-responses-api-proxy
官方/社区针对 Node/NPM 分发的轻量级转译工具，安装后本地跑一个服务，Codex 的 base_url 直接指向 http://127.0.0.1:3000/v1 即可正常工作。
「这属于技术栈升级带来的标准不兼容——Codex 升级到了下一代协议（Responses API），而大多数第三方 API 平台目前依然暴露的是上一代标准协议（Chat Completions API）。挂一层轻量级的本地 Proxy 是目前体验最稳、无需修改客户端代码的标准解法。」
END
如果你觉得今天这篇有收获，欢迎 点赞、在看、转发 三连，我们下篇见。
[【OpenClaw 实操】OpenClaw Dreaming：AI 智能体的梦境记忆系统](https://mp.weixin.qq.com/s?__biz=MzA5NzgyNzA0MA==&mid=2650318903&idx=1&sn=d2769dd5a5b29cf05ccd9032f57845ef&scene=21#wechat_redirect){linktype="2" localeditorid="1vkfzcefnglxpn0agw" target="_blank" textvalue="【OpenClaw 实操】OpenClaw Dreaming：AI 智能体的梦境记忆系统"}[【OpenClaw 实操】本地嵌入模型踩坑记：从 FTS 到向量嵌入的五条路](https://mp.weixin.qq.com/s?__biz=MzA5NzgyNzA0MA==&mid=2650318894&idx=1&sn=453816ea657e4234b022509f5d4cb398&scene=21#wechat_redirect){linktype="2" localeditorid="k1ixwlxapvnfqsny0w" target="_blank" textvalue="【OpenClaw 实操】本地嵌入模型踩坑记：从 FTS 到向量嵌入的五条路"}\
