企业官网建设流程全解析

最近在开发者社区里，一个高频出现的问题是：“想用 Codex 调用免费模型，是不是必须装 CC Switch？” 随之而来的，是各种关于cc switch local proxy failed的报错截图，从 400、401、403 到 502，几乎覆盖了 HTTP 状态码全家桶。很多开发者被这些配置和代理问题劝退，以为这是一条技术门槛极高的路径。

但事实可能恰恰相反。“不装 CC Switch，把免费模型接进 Codex” 的核心，其实是一个 API 路由与格式转换的思路问题，而非复杂的本地代理部署。很多人被“中转”、“代理”这些词吓到了，以为必须部署一个复杂的中间件。实际上，如果你理解了 Codex 的请求格式和免费模型 API 的差异，完全可以用更轻量、更可控的方式实现对接。这篇文章将为你拆解这个过程的本质，并提供一套从原理到实操的完整方案，让你绕过复杂的 CC Switch 配置，直接打通链路。

我们将重点关注几个核心问题：Codex 到底是什么？它期待的请求格式是怎样的？主流的免费模型 API（如 DeepSeek、Ollama 本地模型）又返回什么格式？两者不匹配的“鸿沟”在哪里？最后，我们将用一个简单的 Python 服务作为“格式转换器”，演示如何优雅地桥接两者。读完本文，你将能独立部署一个专属于你的、稳定可靠的“免费模型 Codex 中转站”。

1. 核心问题拆解：为什么需要“中转”？

在深入代码之前，我们必须先理清一个根本矛盾：Codex 客户端（如 VSCode 插件、桌面版）与五花八门的免费模型 API 之间，存在天然的协议和格式壁垒。

Codex 客户端通常遵循 OpenAI API 格式。这意味着它发送的 HTTP 请求，其 URL 路径、请求头（尤其是Authorization: Bearer <key>）和请求体（JSON 结构，包含model,messages,stream等字段）都预期与api.openai.com/v1/chat/completions兼容。许多客户端甚至写死了这个端点。

而免费模型 API 各有各的“脾气”。例如：

• DeepSeek 官方 API：端点可能是https://api.deepseek.com/chat/completions，虽然格式类似 OpenAI，但可能在特定字段（如reasoning_content）上有额外要求。
• Ollama 本地模型：端点通常是http://localhost:11434/api/chat，其请求/响应 JSON 结构与 OpenAI 有显著差异。
• 其他开源模型平台：可能有完全自定义的接口。

当你直接用 Codex 客户端去连接http://localhost:11434时，客户端会向/v1/chat/completions发送 OpenAI 格式的请求，而 Ollama 根本识别不了这个路径和格式，自然会返回404 Not Found或400 Bad Request。

CC Switch 的角色，就是一个通用代理和协议转换器。它监听一个端口，接收 Codex 客户端的“类 OpenAI”请求，然后根据配置，将请求翻译成目标模型 API 能理解的格式，转发出去，再将响应翻译回 OpenAI 格式，返回给客户端。它试图用一个工具解决所有模型的适配问题。

我们的替代思路是：既然核心是格式转换，那么我们可以为目标模型编写一个专用的、轻量的“适配器服务”。这个服务只做一件事：在它监听的端口上，提供一个与 OpenAI API 完全兼容的接口，内部则将请求转换并转发给真正的模型 API。这样做的好处是：

1. 依赖极简：通常只需要一个基础的 HTTP 服务器框架（如 Flask, FastAPI）。
2. 高度可控：转换逻辑完全透明，调试和排查问题一目了然。
3. 规避复杂配置：无需理解 CC Switch 复杂的配置文件和路由规则。
4. 针对性优化：可以针对特定模型的特性（如流式响应、特殊参数）做精细处理。

接下来，我们将以对接DeepSeek 官方 API和本地 Ollama为例，详细演示如何构建这个“适配器”。

2. 环境准备与工具选择

在开始构建适配器之前，你需要准备好基础环境和目标模型服务。

2.1 基础开发环境

• Python 3.8+：我们将使用 Python 编写适配器服务，因其生态丰富，编写 HTTP 服务便捷。
• 包管理工具：pip。
• HTTP 客户端工具：如curl或 Postman，用于测试 API。
• 一个可用的免费模型源：
  • 选项A：DeepSeek API：你需要一个 DeepSeek 账户并获取其 API Key。访问其官方平台即可获取。
  • 选项B：本地 Ollama：在本地安装并运行 Ollama，并拉取一个模型（如llama3.2:1b,qwen2.5:0.5b）。

2.2 关键 Python 库

我们将使用FastAPI来构建适配器，因为它轻量、异步支持好，非常适合 API 网关类应用。同时需要httpx或requests库来转发请求。

创建一个新的项目目录，并安装依赖：

mkdir codex_adapter && cd codex_adapter python -m venv venv # Windows: venv\Scripts\activate # Linux/Mac: source venv/bin/activate pip install fastapi uvicorn httpx

• fastapi&uvicorn：用于创建和运行我们的适配器 Web 服务。
• httpx：一个现代、异步的 HTTP 客户端库，用于向真正的模型 API 发送请求。

3. 原理剖析：OpenAI API 格式与转换逻辑

要让 Codex 客户端“认为”它在和 OpenAI 对话，我们的适配器必须精准模拟 OpenAI Chat Completions API 的输入和输出。

3.1 OpenAI API 格式速览

一个典型的 OpenAI 风格请求如下：请求 (Request)：

POST /v1/chat/completions Headers: { "Authorization": "Bearer sk-...", "Content-Type": "application/json" } Body: { "model": "gpt-3.5-turbo", "messages": [ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "Hello!"} ], "stream": false, "temperature": 0.7 }

响应 (Response)：

{ "id": "chatcmpl-123", "object": "chat.completion", "created": 1677652288, "model": "gpt-3.5-turbo", "choices": [{ "index": 0, "message": { "role": "assistant", "content": "Hello there! How can I help you today?" }, "finish_reason": "stop" }], "usage": { "prompt_tokens": 9, "completion_tokens": 12, "total_tokens": 21 } }

流式响应 (Streaming Response)：当stream: true时，响应是一系列 SSE (Server-Sent Events) 数据块，每个块格式如data: {"id":"...","choices":[{"delta":{"content":"Hello"}}]}\n\n。

3.2 目标 API 格式差异

1. DeepSeek API：非常接近 OpenAI，但注意网络热词中提到的错误：the \reasoning_content` in the thinking mode must be passed back to the api.。这表明 DeepSeek 的某些模型或模式可能要求返回reasoning_content` 字段，我们的适配器可能需要处理这个字段的透传。
2. Ollama API：差异较大。
   • 端点：POST /api/chat
   • 请求体：包含model,messages,stream等，但结构可能不同，例如消息格式可能简化。
   • 响应体：非流式下，直接返回message对象，没有choices数组包裹。

适配器的核心工作就是：

1. 接收一个 OpenAI 格式的请求。
2. 提取关键字段（model,messages,stream等）。
3. 按照目标 API 的格式要求，重新组装请求体。
4. 将请求转发给目标 API。
5. 接收目标 API 的响应。
6. 将响应重新组装成 OpenAI 格式，返回给客户端。

4. 实战：为 DeepSeek API 编写适配器

我们首先实现一个针对 DeepSeek API 的适配器。由于两者格式高度相似，我们的工作主要是“透传”和“字段映射”。

4.1 项目结构

codex_adapter/ ├── main.py # 适配器主程序 ├── config.py # 配置文件（可选） └── requirements.txt # 依赖列表

4.2 适配器代码实现 (main.py)

# main.py import os from typing import Optional, List, Dict, Any import httpx from fastapi import FastAPI, HTTPException, Request from fastapi.responses import StreamingResponse import json import logging # 配置日志 logging.basicConfig(level=logging.INFO) logger = logging.getLogger(__name__) app = FastAPI(title="Codex Adapter for DeepSeek") # 配置（可从环境变量读取） DEEPSEEK_API_BASE = os.getenv("DEEPSEEK_API_BASE", "https://api.deepseek.com") DEEPSEEK_API_KEY = os.getenv("DEEPSEEK_API_KEY", "") # 务必在此设置或通过环境变量传入 ADAPTER_PORT = int(os.getenv("ADAPTER_PORT", "8000")) # 全局 HTTP 客户端，支持连接复用 client = httpx.AsyncClient(timeout=httpx.Timeout(60.0)) def build_deepseek_headers(api_key: str) -> Dict[str, str]: """构建发送给 DeepSeek API 的请求头""" headers = { "Authorization": f"Bearer {api_key}", "Content-Type": "application/json", } # 可以根据需要添加其他 DeepSeek 特定的头部，例如版本头 # headers["X-DeepSeek-Version"] = "2024-01-01" return headers @app.post("/v1/chat/completions") async def chat_completions(request: Request): """ 模拟 OpenAI /v1/chat/completions 端点。 接收 OpenAI 格式请求，转发给 DeepSeek，并返回 OpenAI 格式响应。 """ if not DEEPSEEK_API_KEY: raise HTTPException(status_code=500, detail="DeepSeek API Key not configured.") try: # 1. 解析客户端（Codex）发来的请求 body = await request.json() logger.info(f"Received request: {json.dumps(body, ensure_ascii=False)[:500]}") # 提取关键参数 messages = body.get("messages", []) model = body.get("model", "deepseek-chat") # 默认模型，或从映射关系获取 stream = body.get("stream", False) temperature = body.get("temperature", 0.7) max_tokens = body.get("max_tokens") # 2. 构建转发给 DeepSeek 的请求体 deepseek_payload = { "model": model, # 注意：这里直接使用客户端传来的 model，需确保 DeepSeek 支持 "messages": messages, "stream": stream, "temperature": temperature, } # 可选字段 if max_tokens is not None: deepseek_payload["max_tokens"] = max_tokens # 处理可能存在的其他字段，如 top_p, presence_penalty 等 # 特别注意：如果遇到 thinking mode，需要确保 reasoning_content 的处理 # 这里假设 body 中如果有 reasoning 相关字段，直接透传 if "reasoning" in body: deepseek_payload["reasoning"] = body["reasoning"] # 3. 发送请求到 DeepSeek API deepseek_url = f"{DEEPSEEK_API_BASE}/chat/completions" headers = build_deepseek_headers(DEEPSEEK_API_KEY) if stream: # 流式响应处理 async def stream_generator(): async with client.stream( "POST", deepseek_url, json=deepseek_payload, headers=headers ) as response: if response.status_code != 200: error_text = await response.aread() logger.error(f"DeepSeek API error: {response.status_code}, {error_text}") yield f"data: {json.dumps({'error': {'message': f'Upstream error: {response.status_code}'}})}\n\n" return async for chunk in response.aiter_lines(): if chunk: # DeepSeek 流式响应格式可能与 OpenAI 略有不同，需要适配 # 假设 DeepSeek 返回的是标准 SSE 格式: data: {...}\n\n if chunk.startswith("data: "): # 直接透传，或进行细微格式调整 yield chunk + "\n" else: # 如果不是标准 data: 前缀，包装一下 yield f"data: {chunk}\n\n" return StreamingResponse(stream_generator(), media_type="text/event-stream") else: # 非流式响应处理 resp = await client.post(deepseek_url, json=deepseek_payload, headers=headers) resp.raise_for_status() deepseek_data = resp.json() # 4. 将 DeepSeek 响应转换为 OpenAI 格式 # 假设 deepseek_data 结构非常接近 OpenAI，我们主要确保字段名一致 openai_format_response = { "id": deepseek_data.get("id", f"chatcmpl-{hash(str(deepseek_data))}"), "object": "chat.completion", "created": deepseek_data.get("created", 0), "model": deepseek_data.get("model", model), "choices": deepseek_data.get("choices", []), "usage": deepseek_data.get("usage", {}) } # 处理 reasoning_content 等 DeepSeek 特有字段的映射（如果需要） # 例如，如果 DeepSeek 返回了 reasoning_content，可以将其放入 choices[0].message 中 # 这部分需要根据 DeepSeek 实际返回结构调整 logger.info(f"Response adapted successfully.") return openai_format_response except httpx.HTTPStatusError as e: logger.error(f"HTTP error from DeepSeek: {e.response.status_code} - {e.response.text}") raise HTTPException(status_code=e.response.status_code, detail=f"Upstream error: {e.response.text}") except json.JSONDecodeError as e: logger.error(f"JSON decode error: {e}") raise HTTPException(status_code=400, detail="Invalid JSON in request or response.") except Exception as e: logger.error(f"Unexpected error: {e}", exc_info=True) raise HTTPException(status_code=500, detail=f"Internal adapter error: {str(e)}") @app.get("/health") async def health_check(): """健康检查端点""" return {"status": "ok", "service": "codex-deepseek-adapter"} if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0", port=ADAPTER_PORT)

4.3 配置与运行

1. 设置环境变量（推荐）：

   # Linux/Mac export DEEPSEEK_API_KEY="your_deepseek_api_key_here" export DEEPSEEK_API_BASE="https://api.deepseek.com" export ADAPTER_PORT=8000 # Windows (PowerShell) $env:DEEPSEEK_API_KEY="your_deepseek_api_key_here" $env:DEEPSEEK_API_BASE="https://api.deepseek.com" $env:ADAPTER_PORT=8000

   或者，你也可以直接修改代码中的DEEPSEEK_API_KEY变量（不推荐，尤其是提交到版本库时）。

2. 运行适配器：

   python main.py

   服务将在http://localhost:8000启动。

3. 测试适配器： 使用curl模拟 Codex 客户端发送请求：

   curl -X POST http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer any_string_here" \ # 适配器会忽略此处的Key，使用自己的配置 -d '{ "model": "deepseek-chat", "messages": [{"role": "user", "content": "Hello, who are you?"}], "stream": false }'

   你应该能收到一个格式与 OpenAI 完全兼容的 JSON 响应。

5. 实战：为本地 Ollama 编写适配器

与 DeepSeek 相比，Ollama 的 API 格式差异更大，因此适配器需要做更多转换工作。

5.1 创建 Ollama 适配器 (main_ollama.py)

# main_ollama.py import os from typing import Optional, List, Dict, Any, AsyncGenerator import httpx import json import logging from fastapi import FastAPI, HTTPException, Request from fastapi.responses import StreamingResponse logging.basicConfig(level=logging.INFO) logger = logging.getLogger(__name__) app = FastAPI(title="Codex Adapter for Ollama") OLLAMA_API_BASE = os.getenv("OLLAMA_API_BASE", "http://localhost:11434") OLLAMA_DEFAULT_MODEL = os.getenv("OLLAMA_DEFAULT_MODEL", "llama3.2:1b") # 默认使用的 Ollama 模型 ADAPTER_PORT = int(os.getenv("ADAPTER_PORT", "8001")) # 使用不同端口避免冲突 client = httpx.AsyncClient(timeout=httpx.Timeout(300.0)) # Ollama 可能响应较慢 def transform_to_ollama_messages(openai_messages: List[Dict]) -> List[Dict]: """将 OpenAI 格式的 messages 转换为 Ollama 格式。 Ollama 的 messages 通常也是 role/content 结构，但可能需要简化。 这里我们进行直接映射，因为 Ollama 的 /api/chat 也接受 role/content。 """ ollama_messages = [] for msg in openai_messages: # 基本映射，可根据需要处理 system 消息等 ollama_messages.append({ "role": msg["role"], "content": msg["content"] }) return ollama_messages def transform_from_ollama_response(ollama_response: Dict, openai_model_name: str) -> Dict: """将 Ollama 的响应转换为 OpenAI 格式""" # Ollama 非流式响应示例: {"model":"llama3.2:1b","created_at":"...","message":{"role":"assistant","content":"..."},"done":true} ollama_message = ollama_response.get("message", {}) return { "id": f"chatcmpl-{hash(str(ollama_response))}", "object": "chat.completion", "created": ollama_response.get("created_at", ""), "model": openai_model_name, # 返回客户端请求的模型名，而非 Ollama 内部模型名 "choices": [{ "index": 0, "message": { "role": ollama_message.get("role", "assistant"), "content": ollama_message.get("content", "") }, "finish_reason": "stop" if ollama_response.get("done", True) else None }], "usage": { # Ollama 默认不返回 token 使用情况，可以留空或尝试估算 "prompt_tokens": 0, "completion_tokens": 0, "total_tokens": 0 } } async def generate_ollama_stream(ollama_stream: AsyncGenerator[bytes, None], openai_model_name: str) -> AsyncGenerator[str, None]: """将 Ollama 的流式响应转换为 OpenAI SSE 格式""" async for chunk in ollama_stream: if chunk: try: # Ollama 流式响应是 JSON 对象序列，每行一个 chunk_str = chunk.decode('utf-8').strip() if chunk_str: ollama_data = json.loads(chunk_str) # 构建 OpenAI 格式的数据块 delta_content = ollama_data.get("message", {}).get("content", "") if delta_content: openai_chunk = { "id": f"chatcmpl-{hash(str(ollama_data))}", "object": "chat.completion.chunk", "created": ollama_data.get("created_at", 0), "model": openai_model_name, "choices": [{ "index": 0, "delta": {"content": delta_content}, "finish_reason": None }] } yield f"data: {json.dumps(openai_chunk)}\n\n" # 如果收到 done: true，发送一个 finish_reason 为 stop 的块 if ollama_data.get("done", False): final_chunk = { "id": f"chatcmpl-{hash(str(ollama_data))}", "object": "chat.completion.chunk", "created": ollama_data.get("created_at", 0), "model": openai_model_name, "choices": [{ "index": 0, "delta": {}, "finish_reason": "stop" }] } yield f"data: {json.dumps(final_chunk)}\n\n" except json.JSONDecodeError: logger.warning(f"Failed to decode Ollama stream chunk: {chunk}") except Exception as e: logger.error(f"Error processing stream chunk: {e}") @app.post("/v1/chat/completions") async def chat_completions(request: Request): """适配器端点：将 OpenAI 请求转换为 Ollama 请求""" try: body = await request.json() logger.info(f"Received request for Ollama adapter.") # 提取参数 messages = body.get("messages", []) # 客户端可能传 'gpt-3.5-turbo'，但我们需要映射到本地 Ollama 模型 # 这里简化处理：使用环境变量配置的默认模型，或客户端指定（需维护映射表） client_model = body.get("model", OLLAMA_DEFAULT_MODEL) # 简单映射：如果客户端模型名包含特定字符，则使用特定 Ollama 模型 # 例如，你可以建立一个映射字典 model_map = { "gpt-3.5-turbo": OLLAMA_DEFAULT_MODEL, "llama3.2": "llama3.2:1b", "qwen2.5": "qwen2.5:0.5b", } ollama_model = model_map.get(client_model, OLLAMA_DEFAULT_MODEL) stream = body.get("stream", False) temperature = body.get("temperature", 0.7) # 转换消息格式 ollama_messages = transform_to_ollama_messages(messages) # 构建 Ollama 请求体 ollama_payload = { "model": ollama_model, "messages": ollama_messages, "stream": stream, "options": { "temperature": temperature } } ollama_url = f"{OLLAMA_API_BASE}/api/chat" if stream: # 流式请求 async with client.stream( "POST", ollama_url, json=ollama_payload, headers={"Content-Type": "application/json"} ) as response: if response.status_code != 200: error_text = await response.aread() logger.error(f"Ollama API error: {response.status_code} - {error_text}") raise HTTPException(status_code=response.status_code, detail=error_text) return StreamingResponse( generate_ollama_stream(response.aiter_bytes(), client_model), media_type="text/event-stream" ) else: # 非流式请求 resp = await client.post(ollama_url, json=ollama_payload) resp.raise_for_status() ollama_data = resp.json() openai_format_response = transform_from_ollama_response(ollama_data, client_model) logger.info(f"Ollama response adapted.") return openai_format_response except httpx.HTTPStatusError as e: logger.error(f"Ollama HTTP error: {e.response.status_code} - {e.response.text}") raise HTTPException(status_code=e.response.status_code, detail=f"Ollama error: {e.response.text}") except Exception as e: logger.error(f"Unexpected error in Ollama adapter: {e}", exc_info=True) raise HTTPException(status_code=500, detail=str(e)) @app.get("/health") async def health_check(): # 可以添加对 Ollama 服务的健康检查 try: async with client: resp = await client.get(f"{OLLAMA_API_BASE}/api/tags") if resp.status_code == 200: return {"status": "ok", "ollama": "reachable"} else: return {"status": "degraded", "ollama": "unreachable"} except Exception: return {"status": "degraded", "ollama": "unreachable"} if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0", port=ADAPTER_PORT)

5.2 运行与测试 Ollama 适配器

1. 确保 Ollama 服务正在运行：

   ollama serve # 另开一个终端拉取模型（如果尚未拉取） ollama pull llama3.2:1b

2. 运行适配器：

   export OLLAMA_API_BASE="http://localhost:11434" export OLLAMA_DEFAULT_MODEL="llama3.2:1b" export ADAPTER_PORT=8001 python main_ollama.py

3. 测试：

   curl -X POST http://localhost:8001/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-3.5-turbo", # 这个名称会被映射到 llama3.2:1b "messages": [{"role": "user", "content": "Write a hello world in Python."}], "stream": false }'

6. 在 Codex 客户端中配置使用你的适配器

现在，你的本地适配器服务已经运行在http://localhost:8000(DeepSeek) 或http://localhost:8001(Ollama)。接下来需要在 Codex 客户端中配置。

核心原理：将 Codex 客户端的 API Base URL 指向你的适配器地址，并提供一个任意（或留空）的 API Key（因为适配器内部使用了真实的 Key）。

具体配置步骤因 Codex 客户端（如 VSCode 插件、桌面版）而异，但通常可以在设置中找到类似API Base URL或Custom Endpoint的选项。

1. VSCode Codex 插件：在设置中搜索Codex，找到API Endpoint或Base URL，将其设置为http://localhost:8000/v1（注意，有些客户端需要包含/v1，有些只需要到端口）。API Key可以填写任意非空字符串（如sk-dummy），因为我们的适配器目前忽略了这个 Key（实际 Key 在环境变量中）。更安全的做法是适配器也验证客户端传来的 Key，实现多用户隔离。
2. Codex 桌面版/其他客户端：在设置或配置文件中，找到类似openai.base_url的配置项，将其修改为你的适配器地址。

配置示例（假设）：

• API Base URL:http://localhost:8000/v1或http://localhost:8000
• API Key:sk-this-is-a-dummy-key-for-codex

配置完成后，在 Codex 客户端中发起对话，请求就会被发送到你的适配器，进而转发到 DeepSeek 或 Ollama，并将响应返回给客户端。

7. 常见问题与排查思路

在部署和使用过程中，你可能会遇到以下问题。下表列出了常见现象、可能原因和解决方案。

8. 进阶优化与最佳实践

上面的示例提供了最核心的转换功能。对于一个可用于生产环境或团队共享的适配器，你还需要考虑以下几点：

1. 安全性增强：

   • API Key 管理：不要在代码中硬编码 Key。使用环境变量、配置文件或密钥管理服务。适配器也可以验证客户端传来的 Key，实现简单的访问控制。
   • 请求限流：防止恶意用户刷爆你的 API 额度或本地资源。可以使用slowapi等库添加速率限制。
   • 输入输出过滤：对传入的messages内容和返回的响应进行基本的敏感词或有害内容过滤。

2. 可观测性：

   • 结构化日志：使用structlog或json-logging输出结构化日志，方便接入 ELK 或 Loki。
   • 指标监控：添加 Prometheus 指标，监控请求量、延迟、错误率。
   • 请求/响应记录：在调试阶段，可以记录请求和响应的摘要（注意脱敏），但生产环境需谨慎处理隐私数据。

3. 性能与稳定性：

   • 连接池：使用httpx.AsyncClient作为全局客户端，可以复用 HTTP 连接，提升性能。
   • 重试机制：对于目标 API 的临时性失败（如 5xx 错误），可以实现指数退避重试。
   • 超时设置：根据模型响应特性，为不同的操作（连接、读、写）设置合理的超时。
   • 异步处理：使用async/await避免阻塞，提高并发能力。

4. 功能扩展：

   • 多模型路由：在一个适配器内支持多个后端模型。可以根据客户端请求中的model字段，路由到不同的 API Base URL 和转换逻辑。
   • 负载均衡：如果有多个同模型实例，可以实现简单的轮询或加权负载均衡。
   • Fallback 策略：当主模型服务不可用时，自动切换到备用模型。
   • 支持更多端点：除了/chat/completions，还可以适配/embeddings,/models等端点，让客户端功能更完整。

5. 配置化管理： 将模型映射、API 地址、密钥等抽象到配置文件（如config.yaml）或数据库中，便于动态更新。

通过实现上述优化，你的这个轻量级适配器将从一个简单的脚本，进化成一个健壮、可维护的微服务。

9. 总结：自主可控的集成之路

回到最初的问题：“不装 CC Switch，把免费模型接进 Codex” 是否可行？答案是肯定的，而且这条路径给了开发者更深层的控制力和理解。

我们通过剖析 Codex 客户端与模型 API 之间的协议差异，明确了“适配器”的核心使命——协议转换。随后，我们分别针对 DeepSeek API 和本地 Ollama 服务，用不到 200 行的 Python 代码实现了两个专用的适配器。它们接收 OpenAI 格式的请求，进行精准的格式转换后转发给目标服务，再将响应“伪装”成 OpenAI 格式返回。最后，只需在 Codex 客户端中修改 API 地址指向本地适配器，即可完成整个链路的打通。

这种方法相比使用 CC Switch 这类通用工具有几个显著优势：依赖极简，核心逻辑清晰；调试方便，任何问题都可以在自己的代码中定位；高度定制，可以针对特定模型的怪异行为进行精细处理。当然，它也需要你付出一些理解协议和编写代码的成本。

对于开发者而言，这不仅仅是一个解决具体问题的教程，更是一种思路的启发。在 AI 工具链日益复杂的今天，理解底层协议并能够构建轻量的“胶水”代码，是摆脱对单一工具依赖、实现真正自主集成的关键能力。下次当你遇到两个系统因协议不同而无法对话时，不妨想想：是不是可以写一个简单的适配器，让它们直接沟通？

你可以从本文提供的代码示例开始，将其部署在你的开发环境或内网服务器中。建议先在一个测试用的 Codex 客户端配置中进行尝试，成功后再应用到主力环境。如果在实践过程中遇到新的问题，欢迎在评论区交流探讨。