最近身边不少朋友都在问，怎么才能让那个看起来很酷的AI编程助手 Codex 用上 DeepSeek 的模型。他们要么是觉得 OpenAI 的 API 太贵，要么是网络环境不稳定，总想找个更接地气、更实惠的替代方案。我一开始也觉得，这不就是改个 API 地址和 Key 的事儿吗？结果上手一折腾才发现，事情远没想象中那么简单。Codex 默认只认 OpenAI 自家的Responses API，而 DeepSeek 提供的是标准的Chat Completions API。这两者就像一个是说方言，一个是说普通话，协议格式、流式输出、工具调用的方式全都不一样。直接把 DeepSeek 的地址填进去，Codex 要么一脸茫然地报 404，要么连模型列表都刷不出来。问题的核心，其实不在于“接入”这个动作本身，而在于如何让两个说不同“语言”的系统能顺畅对话。这背后需要的，是一个可靠的“协议翻译官”。折腾了一下午，我最终用CC Switch这个工具解决了所有问题。整个过程，从踩坑到跑通，让我对“本地部署”和“模型接入”有了更深的理解——它绝不仅仅是换个地址，而是一套关于兼容性、稳定性和长期可用性的系统工程。1. 为什么直接改配置行不通？理解协议差异是第一步很多人，包括最初的我，都以为让 Codex 用上 DeepSeek，就像在浏览器里换个搜索引擎一样简单：找到设置，填入新的 API 地址和 Key，完事。但实际操作后你会发现，Codex 的设置里根本没有让你自定义 API 地址的地方。这不是 Codex 设计得封闭，而是因为它和 OpenAI 的生态绑定得太深。Codex 底层调用的是一套名为OpenAI Responses API的接口。这套接口是 OpenAI 为其自家 AI 智能体（如 Codex、Claude Code）专门设计的，并非我们熟知的通用 Chat Completions API。它们之间的差异，主要体现在三个方面：请求与响应格式：Responses API 的请求体结构、字段命名和响应流格式，都与标准的 Chat Completions API 不同。DeepSeek 的服务器收到一个它不认识的“方言”请求，自然会返回错误。流式输出处理：Codex 那种一个字一个字蹦出来的效果，依赖于 Responses API 特定的流式数据返回方式。如果中间转换不当，很容易导致输出卡顿、中断，或者直接无法流式显示。工具调用（Function Calling）：Codex 能读取文件、操作浏览器的能力，依赖于一套特定的工具调用协议。如果协议转换层没有处理好这部分，那么 Codex 的这些“智能”功能在接入第三方模型后就会全部失效。所以，问题的本质是协议不兼容。我们需要一个中间层，这个中间层需要做三件事：协议转换：将 Codex 发出的 Responses API 请求，“翻译”成 DeepSeek 能理解的 Chat Completions API 请求。路由转发：把翻译好的请求发送到正确的 DeepSeek API 端点。响应回译：将 DeepSeek 返回的标准响应，再“包装”回 Codex 能识别的 Responses API 格式。这个中间层，就是CC Switch。它的角色不是一个简单的代理，而是一个真正的协议适配器。理解了这一点，后面的配置步骤就不再是机械的点击，而是每一步都