最近几天，我身边好几个做开发的朋友都在折腾同一件事：怎么把那些好用的AI编程助手，比如Codex，从云端“搬”到自己电脑上，再给它换个更聪明、更便宜的“大脑”，比如DeepSeek。

一开始我也纳闷，直接用官方的在线服务不香吗？直到自己也试了试，才发现问题所在：网络延迟、API调用次数限制、数据隐私顾虑，还有那笔不小的订阅费用。尤其是当你需要频繁、稳定地调用AI来辅助写代码、重构或者生成文档时，一个本地化、可自定义的解决方案，吸引力就太大了。

但这个过程，远不是下载一个安装包那么简单。它更像是在组装一台精密的仪器：你需要一个能稳定运行的前端界面（Codex），一个强大的本地推理引擎，以及一个高效、兼容的后端模型（DeepSeek）。任何一个环节的配置出错，都可能让整个流程卡住。

今天这篇文章，我就把自己从零开始，成功在本地部署Codex并接入DeepSeek模型的全过程，以及其中踩过的坑、总结的经验，完整地分享出来。我们的目标不是简单地复现一个教程，而是理解这套组合方案背后的工作逻辑，掌握从“单次跑通”到“稳定可用”的完整路径。

1. 先理清思路：本地部署的本质是“协议转换与路由”

在开始动手之前，我们必须先想明白一件事：为什么Codex不能直接“认识”DeepSeek？我们部署的到底是什么？

Codex，通常指的是一个基于VS Code的AI编程助手插件或客户端。它被设计为与特定的AI服务提供商（如早期的GitHub Copilot后端）进行通信。这种通信遵循一套预设的API协议。而DeepSeek、GLM、Kimi等第三方大模型，它们提供的API接口格式、请求参数、响应结构很可能与Codex期望的格式不同。

因此，本地部署的核心挑战，不是“安装”某个软件，而是搭建一个“翻译官”和“调度中心”。这个“翻译官”需要做两件事：

1. 协议转换：将Codex发出的请求，“翻译”成DeepSeek API能理解的格式。
2. 路由分发：将转换后的请求，正确发送到DeepSeek服务（无论是本地运行的模型，还是其官方API），并将返回的结果再“翻译”回Codex能识别的格式。

基于这个理解，整个方案的架构就清晰了：

[你的VS Code + Codex插件] -> (发送标准请求) -> [本地代理服务] -> (转换为DeepSeek API请求) -> [DeepSeek服务（本地/云端）] -> (返回结果) -> [本地代理服务] -> (转换回标准响应) -> [Codex插件呈现结果]

关键判断：我们不需要、也通常无法修改Codex客户端的代码。所有的工作都集中在构建和配置这个本地代理服务上。这也是为什么搜索材料中强调“核心就一点：不动Codex本身，只改配置，再起一个代理”。

2. 环境准备与核心组件选择：避开版本依赖的“暗礁”

明确了架构，下一步就是准备“零件”。这里最容易出问题的不是操作步骤，而是版本兼容性。很多教程失败，就是因为忽略了这一点。

2.1 基础运行环境：Node.js与Python

本地代理服务通常由Node.js或Python编写。你需要确保环境符合要求。

• Node.js：建议安装LTS（长期支持）版本，如18.x或20.x。避免使用过新或过旧的版本。安装后，在终端执行node -v和npm -v确认版本。
• Python：建议使用Python 3.8至3.11之间的版本。Python 3.12+可能在某些依赖包上存在兼容性问题。安装后，执行python --version或python3 --version确认。

注意：如果你的系统已经安装了多个版本的Python或Node，请确保在后续操作中使用的命令（如pip或npm）指向的是你确认过的正确版本。可以使用which pip3或where node来检查路径。

2.2 关键组件选择：代理服务方案

这是整个部署的核心。社区有多种实现方案，我们需要根据自身技术栈和需求选择。

1. 通用HTTP代理服务：这是最灵活的方式。你可以用任何熟悉的语言（Node.js + Express, Python + Flask/FastAPI）编写一个简单的HTTP服务器。它的工作就是接收Codex的请求，按照DeepSeek的API文档重组请求体，发送，处理响应，再返回。这种方式需要你手动处理协议转换逻辑，适合喜欢折腾、想完全掌控流程的开发者。
2. 专用转