企业官网建设流程全解析

如果你正在尝试将 Codex CLI 接入 DeepSeek 等国产大模型，大概率已经遇到了两个“拦路虎”：一是找不到 CC Switch 或 Codex++ 的官方下载渠道，二是即使找到了，也可能因为网络问题无法顺利安装或更新。这篇文章要解决的问题很直接：在不依赖良好网络、无需下载 CC Switch 或 Codex++ 的情况下，如何让 Codex CLI 稳定地使用 DeepSeek 的 API。

核心思路是绕开复杂的第三方客户端，直接通过本地代理路由的方式，让 Codex 的 OpenAI Responses API 协议与 DeepSeek 的 OpenAI Chat Completions API 协议“握手成功”。这种方法本质上是在本地搭建一个轻量的协议转换层，它不依赖任何特定的 GUI 工具，只需要一个能运行 Python 脚本的环境。整个过程对硬件几乎没有特殊要求，不依赖 GPU，普通 CPU 和 2GB 左右的内存即可运行，重点在于配置的正确性。

本文将带你完成从零开始的完整流程：理解为什么需要协议转换、准备必要的环境（Codex CLI 和 DeepSeek API Key）、编写并启动一个简易的本地路由代理、最后在 Codex 中完成配置和测试。你会得到一个完全由自己控制、部署在本地的“平替方案”，彻底解决下载和网络依赖问题。

1. 核心能力速览

在深入操作之前，我们先通过一个表格快速了解这个方案的核心特性和你需要准备什么。

2. 为什么需要本地路由？协议冲突详解

Codex CLI 在设计上默认对接的是 OpenAI 的Responses API。这是一种较新的、为 AI 助手交互优化的流式 API 协议。而 DeepSeek、Kimi、智谱AI等国内大部分提供 OpenAI 兼容接口的服务商，目前普遍支持的是更早、更通用的Chat Completions API协议。

这两种协议在请求体结构、响应格式、尤其是流式传输（Server-Sent Events, SSE）的事件字段上存在差异。如果你直接将 DeepSeek 的 Chat 端点（如https://api.deepseek.com/chat/completions）填到 Codex 的配置里，最常见的结果就是：Codex 无法正确解析返回的模型列表（导致/model命令失效），或者发起请求后收到404、400错误，又或者流式响应在 Codex 界面中显示乱码或直接中断。

因此，我们需要一个“翻译官”——本地路由代理。它的工作流程非常清晰：

1. 监听：在本地（如127.0.0.1:15721）启动一个 HTTP 服务。
2. 转换请求：当 Codex 向http://127.0.0.1:15721/v1/responses发送请求时，代理将其拦截，把Responses格式的请求体转换为Chat Completions格式，然后转发给真正的 DeepSeek API (https://api.deepseek.com/chat/completions)。
3. 转换响应：收到 DeepSeek 的Chat Completions格式响应（无论是 JSON 还是 SSE 流）后，再将其转换回Responses格式，返回给 Codex。
4. 认证中转：在转发请求时，自动将你的 DeepSeek API Key 添加到请求头中，无需在 Codex 配置里暴露密钥。

这样一来，Codex 以为自己一直在和标准的 OpenAI Responses API 对话，而实际提供服务的是 DeepSeek。CC Switch 这类工具的核心价值就是自动化完成了上述所有步骤，并提供了图形界面。而我们接下来的方案，则是用代码手动实现这个核心路由逻辑。

3. 环境准备与前置条件

开始之前，请确保你的系统满足以下条件。整个过程在 Windows (PowerShell/CMD)、macOS (Terminal) 或 Linux (Bash) 上均可进行。

3.1 安装并验证 Codex CLI

这是本方案的绝对前提。Codex CLI 是 Anthropic 官方提供的命令行工具。

1. 访问官方渠道：通过 Anthropic 官网或可靠的开发者社区获取最新的 Codex CLI 安装指南。通常可以通过包管理器（如pip、brew）或直接下载二进制文件安装。
2. 运行一次：安装后，在终端中执行一次codex命令。这一步至关重要，因为它会在你的用户目录下创建默认的配置文件~/.codex/config.toml（Linux/macOS）或%USERPROFILE%\.codex\config.toml（Windows）。如果这个文件不存在，后续的配置将无法进行。
3. 验证安装：运行codex --version或codex --help，确认命令行工具可以正常响应。

3.2 获取 DeepSeek API Key

你需要一个有效的 DeepSeek API 密钥。

1. 访问 DeepSeek 开放平台官网。
2. 注册并登录账号。
3. 在控制台中创建一个新的 API 密钥，并妥善保存。通常会有免费的试用额度。

3.3 准备 Python 环境

我们将使用 Python 编写代理脚本，需要安装aiohttp库来处理异步 HTTP 请求。

1. 检查 Python：在终端输入python --version或python3 --version，确保版本在 3.8 及以上。
2. 安装依赖：打开终端，执行以下命令安装必要的库。

   pip install aiohttp

   如果速度慢，可以使用国内镜像源，例如：

   pip install aiohttp -i https://pypi.tuna.tsinghua.edu.cn/simple

4. 创建并启动本地路由代理服务

这是整个方案的核心。我们将创建一个 Python 脚本deepseek_proxy.py，它包含了协议转换和代理转发逻辑。

4.1 编写代理脚本

在你喜欢的工作目录下（例如~/codex_proxy），创建一个新文件deepseek_proxy.py，并将以下代码复制进去。

#!/usr/bin/env python3 """ DeepSeek API Proxy for Codex CLI. Converts OpenAI Responses API requests to/from OpenAI Chat Completions API. """ import asyncio import json import os from aiohttp import web, ClientSession, ClientTimeout # ========== 配置区域：请根据你的情况修改 ========== DEEPSEEK_API_KEY = "sk-your-deepseek-api-key-here" # 替换为你的真实 API Key DEEPSEEK_BASE_URL = "https://api.deepseek.com" # DeepSeek API 基础地址 PROXY_HOST = "127.0.0.1" # 本地代理监听地址 PROXY_PORT = 15721 # 本地代理监听端口，可修改 # ================================================ async def convert_responses_to_chat(responses_body): """将 Codex Responses API 请求体转换为 DeepSeek Chat Completions 请求体。""" # Codex Responses API 的请求结构 # DeepSeek Chat Completions API 的请求结构 # 核心映射关系： # responses_body['input'] -> chat_body['messages'] # responses_body['model'] -> chat_body['model'] # responses_body['stream'] -> chat_body['stream'] chat_body = { "model": responses_body.get("model", "deepseek-chat"), "messages": [], "stream": responses_body.get("stream", False), "temperature": responses_body.get("temperature", 0.7), "max_tokens": responses_body.get("max_tokens", 2048), } # 处理输入消息。Responses API 的 input 字段通常是字符串或消息数组。 input_data = responses_body.get("input", "") if isinstance(input_data, str): # 如果是字符串，当作一条用户消息 chat_body["messages"].append({"role": "user", "content": input_data}) elif isinstance(input_data, list): # 如果是数组，尝试转换为 Chat 的 messages 格式 for msg in input_data: # 这里需要根据实际的 Responses 消息格式进行适配，以下为通用处理 if isinstance(msg, dict): role = msg.get("role", "user") # Responses API 可能使用 `content` 或 `text` 字段 content = msg.get("content") or msg.get("text") or "" if content: chat_body["messages"].append({"role": role, "content": content}) # 清理可能的空消息 chat_body["messages"] = [m for m in chat_body["messages"] if m.get("content")] # 如果转换后消息为空，添加一个默认消息防止错误 if not chat_body["messages"]: chat_body["messages"].append({"role": "user", "content": "Hello"}) return chat_body async def convert_chat_to_responses(chat_response, stream_mode=False): """将 DeepSeek Chat Completions 响应转换为 Codex Responses API 响应。""" if stream_mode: # 流式响应：需要逐行转换 SSE 事件 # 这是一个简化版，实际需要处理 `data: {...}` 格式 # 本示例返回原样流，Codex 可能兼容。更复杂的转换需参考官方协议。 return chat_response else: # 非流式 JSON 响应 try: chat_data = await chat_response.json() except: # 如果响应不是 JSON，可能是错误信息，直接返回 return chat_response # 构建 Responses 格式的响应 responses_data = { "output": [], "model": chat_data.get("model", ""), "id": chat_data.get("id", ""), } choice = chat_data.get("choices", [{}])[0] message = choice.get("message", {}) if message: responses_data["output"].append({ "type": "message", "role": message.get("role", "assistant"), "content": message.get("content", ""), }) return web.json_response(responses_data) async def proxy_handler(request): """处理所有来自 Codex 的代理请求。""" path = request.path if path in ["/v1/responses", "/responses"]: # 1. 获取 Codex 的请求数据 try: req_data = await request.json() if request.can_read_body else {} except: req_data = {} # 2. 转换为 DeepSeek Chat API 格式 chat_body = await convert_responses_to_chat(req_data) stream_mode = chat_body.get("stream", False) # 3. 准备转发到 DeepSeek headers = { "Authorization": f"Bearer {DEEPSEEK_API_KEY}", "Content-Type": "application/json", } deepseek_url = f"{DEEPSEEK_BASE_URL}/chat/completions" # 4. 发起请求 timeout = ClientTimeout(total=60) async with ClientSession(timeout=timeout) as session: async with session.post(deepseek_url, json=chat_body, headers=headers) as deepseek_resp: # 5. 将 DeepSeek 的响应转换后返回给 Codex response = await convert_chat_to_responses(deepseek_resp, stream_mode) return response else: # 处理其他路径，例如模型列表查询 (Codex 可能会请求 /v1/models) if path in ["/v1/models", "/models"]: # 返回一个模拟的模型列表，让 Codex 识别 fake_models = { "object": "list", "data": [ { "id": "deepseek-chat", "object": "model", "created": 1686935000, "owned_by": "deepseek" }, { "id": "deepseek-coder", "object": "model", "created": 1686935001, "owned_by": "deepseek" } ] } return web.json_response(fake_models) return web.Response(text=f"Proxy active. Requested path: {path}", status=200) async def health_check(request): """健康检查端点。""" return web.Response(text="OK") async def init_app(): """初始化 Web 应用。""" app = web.Application() app.router.add_post('/v1/responses', proxy_handler) app.router.add_post('/responses', proxy_handler) app.router.add_get('/v1/models', proxy_handler) app.router.add_get('/models', proxy_handler) app.router.add_get('/health', health_check) return app def main(): """启动代理服务器。""" print(f"[INFO] Starting DeepSeek proxy server on {PROXY_HOST}:{PROXY_PORT}") print(f"[INFO] Target API: {DEEPSEEK_BASE_URL}") print("[INFO] Press Ctrl+C to stop the server.") # 验证 API Key 是否已配置 if DEEPSEEK_API_KEY.startswith("sk-your-"): print("[ERROR] Please edit `deepseek_proxy.py` and set your real DEEPSEEK_API_KEY!") return web.run_app(init_app(), host=PROXY_HOST, port=PROXY_PORT) if __name__ == '__main__': main()

关键操作：

1. 找到代码开头的配置区域。
2. 将DEEPSEEK_API_KEY = "sk-your-deepseek-api-key-here"中的字符串替换成你从 DeepSeek 平台获取的真实 API Key。
3. （可选）如果你需要使用其他端口，可以修改PROXY_PORT的值，但要确保不与系统其他服务冲突。

4.2 启动代理服务

保存文件后，在终端中进入该文件所在目录，运行以下命令启动代理：

python deepseek_proxy.py

如果一切正常，你将看到类似以下的输出，表示代理服务已在127.0.0.1:15721运行：

[INFO] Starting DeepSeek proxy server on 127.0.0.1:15721 [INFO] Target API: https://api.deepseek.com [INFO] Press Ctrl+C to stop the server. ======== Running on http://127.0.0.1:15721 ======== (Press CTRL+C to quit)

请保持这个终端窗口打开，代理服务需要持续运行。你可以最小化它。

5. 配置 Codex CLI 使用本地代理

现在，我们需要告诉 Codex CLI，它的 API 端点是我们刚刚启动的本地代理。

5.1 定位并编辑 Codex 配置文件

根据你的操作系统，找到 Codex 的配置文件：

• Linux/macOS:~/.codex/config.toml
• Windows:%USERPROFILE%\.codex\config.toml(例如C:\Users\YourName\.codex\config.toml)

用文本编辑器（如 VSCode、Notepad++、Sublime Text 或系统自带的记事本）打开这个文件。

5.2 修改配置文件

在config.toml文件中，你需要找到或添加[api]部分，并进行如下配置：

# ~/.codex/config.toml 示例配置 [api] # 将 API 地址指向我们本地运行的代理服务器 base_url = "http://127.0.0.1:15721/v1" # Codex 使用的 API 类型，必须保持为 "responses" wire_api = "responses" # 认证部分：由于我们的代理脚本会自行添加 DeepSeek 的 API Key， # 这里可以填写一个占位符，或者如果你之前的配置里有 OpenAI 的 key，可以注释或删除。 # 关键点是，Codex 会发送这个 key 给代理，但代理脚本会忽略它并使用自己配置的 key。 api_key = "dummy-key-or-your-old-openai-key" # 占位符即可 # 可选：配置模型目录（如果Codex无法自动发现模型） # 我们的代理脚本提供了 /v1/models 端点来返回模拟的模型列表。 # 通常 Codex 会自动查询，如果遇到问题可以尝试显式指定 # model_catalog_json = "/path/to/your/custom_model_catalog.json"

重点说明：

• base_url: 必须设置为http://127.0.0.1:15721/v1。如果你的代理脚本使用了不同的端口，请相应修改。
• wire_api: 必须保持为"responses"，这是 Codex 客户端的协议，我们的代理会处理转换。
• api_key: 这里填写的值不会被用于访问 DeepSeek。它只是 Codex 发起请求时携带的一个凭证。我们的代理脚本在转发请求时，会使用脚本内硬编码的DEEPSEEK_API_KEY替换掉它。因此，你可以填写任何字符串（如dummy-key），或者保留你之前用于其他服务的 key（这不会有安全问题，因为请求不会直接发往外部）。

5.3 重启 Codex CLI

修改并保存config.toml后，必须重启 Codex CLI。如果你之前已经在终端中运行了codex交互会话，请退出（通常按Ctrl+D或输入/exit），然后重新运行codex命令启动一个新的会话。

6. 功能测试与效果验证

配置完成后，我们通过几个步骤来验证代理是否工作正常。

6.1 验证基础连接与模型列表

在新的 Codex CLI 会话中，首先尝试列出可用的模型：

/model

如果代理工作正常，Codex 会调用我们脚本中的/v1/models端点，并显示类似以下的模型列表（名称来自我们脚本中的模拟数据）：

Available models: - deepseek-chat - deepseek-coder

这表明 Codex 已经成功通过本地代理获取到了“模型”信息。

6.2 发送测试请求

现在，发送一个简单的测试提示词：

Hello, who are you?

或者

用Python写一个快速排序函数。

观察点：

1. Codex 终端：你应该能看到 Codex 开始接收流式响应（如果启用了流式输出），并正常显示 DeepSeek 生成的回答。
2. 代理服务终端：你应该能看到类似"POST /v1/responses HTTP/1.1" 200的日志输出，表明请求被成功代理和转发。

6.3 验证流式输出

Codex 默认支持流式输出。确保你的对话是流畅的，没有出现截断或乱码。如果流式输出有问题，可能是代理脚本中的流式响应转换不够完善。对于基础使用，我们提供的简化转换在多数情况下可以工作。

6.4 进行多轮对话

尝试进行多轮对话，检查上下文是否能够正常保持。例如：

Q: 什么是Python的列表推导式？ A: (等待DeepSeek回答) Q: 给我一个例子。

观察第二次提问时，Codex/代理是否将历史对话上下文正确地传递给了 DeepSeek。

7. 接口 API 与进阶调用

我们的本地代理本质上是一个标准的 HTTP 服务，这意味着它不仅服务于 Codex CLI，也可以被其他任何能够发送 HTTP 请求的工具调用，用于测试或集成。

7.1 直接调用代理 API 进行测试

你可以使用curl命令来模拟 Codex 的请求，直接测试代理：

curl -X POST http://127.0.0.1:15721/v1/responses \ -H "Content-Type: application/json" \ -H "Authorization: Bearer dummy-key" \ -d '{ "model": "deepseek-chat", "input": "请用一句话介绍你自己。", "stream": false }'

如果成功，你会收到一个经过转换的、Codex Responses 格式的 JSON 响应。

7.2 使用 Python 脚本调用

你也可以编写 Python 脚本，像使用普通 API 一样使用这个代理：

import requests import json proxy_url = "http://127.0.0.1:15721/v1/responses" headers = { "Content-Type": "application/json", "Authorization": "Bearer dummy-key" # 这个key会被代理替换 } payload = { "model": "deepseek-chat", "input": "解释一下神经网络。", "stream": False, "temperature": 0.5, "max_tokens": 500 } response = requests.post(proxy_url, headers=headers, json=payload, timeout=30) if response.status_code == 200: result = response.json() print("Response:", json.dumps(result, indent=2, ensure_ascii=False)) else: print(f"Error: {response.status_code}", response.text)

7.3 处理批量任务

对于批量处理任务，建议在调用方（你的脚本）层面实现队列和重试机制，而不是依赖这个简单的代理。例如，你可以：

1. 读取一个包含多个问题的文件。
2. 循环调用上述代理接口。
3. 为每个请求添加适当的延迟，避免触发上游 API 的速率限制。
4. 实现错误重试逻辑（如遇到网络超时或 5xx 错误时重试）。
5. 将每个响应保存到独立的文件或数据库中。

8. 资源占用与性能观察

这个自建代理方案的优势之一就是资源消耗极低且透明可控。

• CPU 与内存：代理脚本本身只是一个简单的 HTTP 转发服务，不执行任何模型推理。在空闲时，CPU 使用率接近 0%，内存占用通常在 100 MB 以下。在转发请求时，会有轻微的网络 I/O 和 JSON 解析开销，但对系统性能影响微乎其微。
• 网络延迟：整个链路的延迟 =本地网络延迟 (Codex -> 本地代理) + 代理处理延迟 + 你的网络到 DeepSeek API 的延迟 + DeepSeek 处理延迟。由于前两部分都在本地，延迟几乎可以忽略（<1ms）。因此，最终用户体验到的响应速度主要取决于你的网络连接到api.deepseek.com的速度以及 DeepSeek 服务的处理时间。
• 稳定性：服务的稳定性取决于两个因素：
  1. 本地代理脚本的稳定性：只要 Python 进程不崩溃，它就稳定。代码中包含了基本的错误处理，对于常规使用是足够的。
  2. 你的网络到 DeepSeek API 的稳定性：这是主要变量。如果出现连接超时，代理脚本会返回错误给 Codex。
• 监控：你可以直接观察运行代理的终端窗口，所有进出的 HTTP 请求都会打印日志（取决于aiohttp的默认日志级别）。这是最直接的监控方式。

9. 常见问题与排查方法

在部署和使用过程中，你可能会遇到以下问题。请根据现象按顺序排查。

10. 最佳实践与使用建议

为了让这个自建代理方案运行得更稳定、更安全，建议遵循以下实践：

1. API Key 管理：切勿将写有真实 API Key 的脚本上传到 GitHub 等公开仓库。可以考虑将 API Key 存储在环境变量中，让脚本从环境变量读取。

   import os DEEPSEEK_API_KEY = os.getenv("DEEPSEEK_API_KEY", "default-key-if-not-set")

   然后在启动脚本前设置环境变量：

   # Linux/macOS export DEEPSEEK_API_KEY=your_real_key_here python deepseek_proxy.py # Windows (PowerShell) $env:DEEPSEEK_API_KEY="your_real_key_here" python deepseek_proxy.py

2. 进程守护：对于长期使用，建议使用进程守护工具（如systemd(Linux)、launchd(macOS)、nssm(Windows)）将代理脚本作为后台服务运行，并设置开机自启和崩溃重启。

3. 日志记录：当前的脚本只有基础输出。对于生产环境，应该配置更完善的日志记录，将请求、响应、错误信息写入文件，便于后期排查问题。可以使用 Python 标准的logging模块。

4. 配置化：将监听端口、目标 API 地址等配置项提取到外部配置文件（如config.json或config.yaml）中，避免每次修改都要动代码。

5. 协议兼容性：本文提供的脚本是一个最小可行实现 (MVP)，重点在于演示原理。OpenAI 的 Responses API 和 Chat Completions API 的字段映射可能更复杂，特别是对于工具调用（function calling）、推理过程（reasoning）等高级特性。如果你需要完全兼容，需要仔细对照两者的官方文档，完善转换函数。

6. 备用方案：这个自建代理是 CC Switch 的“平替”，它给了你最大的控制权和避开了网络下载问题。但如果未来 CC Switch 有了更便捷的获取方式，或者你找到了其他稳定的第三方客户端，依然可以切换回去。只需将 Codex 的config.toml中的base_url改回对应的地址即可。

通过以上步骤，你已经成功搭建了一个不依赖 CC Switch 或 Codex++、完全自主控制的 Codex-to-DeepSeek 本地代理桥梁。这个方案将复杂的协议转换和网络问题隔离在本地，让你能更专注于使用 Codex CLI 进行高效的开发工作。如果在实践中遇到本文未覆盖的特定问题，深入分析代理脚本的日志和 Codex 的错误信息，往往是解决问题的关键。