GodeX：让任意模型都能跑在 Codex 上的 Responses API 网关

OpenAI 的 Codex CLI 和一系列开发者 Agent 工具正在快速铺开，但它们都绑定在 OpenAI 的 Responses API 上。国内开发者手里有 DeepSeek、智谱、MiniMax、小米等模型的 API Key，却因为接口格式不同，没法直接接入 Codex 生态。GodeX 1.0.0 的发布，本质上就是解决这个"最后一公里"问题——它是一个本地网关，把 Responses API 的请求翻译成 Chat Completions API 的格式，让任何只提供 Chat Completions 的模型提供商，都能被 Codex CLI 当作原生后端调用。

Responses API 和 Chat Completions API 的断层

OpenAI 在 2025 年推出了 Responses API，和传统的 Chat Completions API 有几个关键差异：

• 对话模型不同：Responses API 不依赖 messages 数组，而是用 input 字段，支持更灵活的对话结构。
• 工具调用机制不同：Responses API 内建了 code_interpreter、file_search、web_search 等工具，返回结构中直接包含工具执行结果，而不是像 Chat Completions 那样需要客户端自己解析 tool_calls 再手动调用。
• 流式输出格式不同：Responses API 的 SSE 事件类型更丰富，包含 response.created、response.output_item.added 等细粒度事件。

Codex CLI、OpenAI Agents SDK 等工具都基于这套 API 构建。而 DeepSeek、智谱 GLM、MiniMax、小米等国内模型提供商，目前只提供 Chat Completions API（部分兼容 OpenAI 格式，但只是 Chat Completions 层面的兼容）。这就形成了一个断层：你有模型、有工具，但中间缺一个翻译层。

GodeX 的翻译策略

GodeX 作为本地网关，核心做了三件事：

1. 协议转换：接收 Responses API 格式的请求，将其转换为目标模型提供商的 Chat Completions API 格式；再将 Chat Completions 的响应转换回 Responses API 格式返回给客户端。
2. 工具调用适配：把 Responses API 中的工具定义（如 code_interpreter）映射到 Chat Completions 的 tools / tool_calls 机制，并在本地执行工具调用后把结果注入回对话流。
3. 流式事件映射：把 Chat Completions 的 stream SSE 事件（choices.delta 等）重新封装成 Responses API 的 SSE 事件格式。

从架构上看，GodeX 就是一个典型的 API Gateway 模式——客户端无感知，后端多模型切换。

快速上手：5 分钟让 Codex CLI 用上 DeepSeek

下面是一个可以直接跑的配置示例。假设你已经安装了 Codex CLI 和 GodeX。

安装 GodeX

# 通过 npm 安装
npm install -g godex

# 或者从源码构建
git clone https://github.com/godex-project/godex.git
cd godex
go build -o godex ./cmd/godex

配置模型提供商

GodeX 通过配置文件定义模型映射。创建 godex.yaml：

gateway:
  port: 8080
  base_url: "http://localhost:8080"

providers:
  deepseek:
    type: chat_completions
    base_url: "https://api.deepseek.com/v1"
    api_key: "${DEEPSEEK_API_KEY}"   # 从环境变量读取
    models:
      - id: "deepseek-chat"
        response_id: "deepseek-r1"    # 对外暴露的模型 ID

  zhipu:
    type: chat_completions
    base_url: "https://open.bigmodel.cn/api/paas/v4"
    api_key: "${ZHIPU_API_KEY}"
    models:
      - id: "glm-4-plus"
        response_id: "glm-4-plus"

  minimax:
    type: chat_completions
    base_url: "https://api.minimax.chat/v1"
    api_key: "${MINIMAX_API_KEY}"
    models:
      - id: "MiniMax-Text-01"
        response_id: "minimax-text"

启动网关并接入 Codex CLI

# 设置 API Key 环境变量
export DEEPSEEK_API_KEY="sk-your-deepseek-key"

# 启动 GodeX 网关
godex serve --config godex.yaml

# 配置 Codex CLI 指向本地网关
export OPENAI_BASE_URL="http://localhost:8080/v1"
export OPENAI_API_KEY="sk-your-deepseek-key"   # 用目标模型的 Key

# 用 Codex CLI 执行任务，实际调用 DeepSeek
codex "用 Python 写一个快速排序，包含单元测试"

关键点：Codex CLI 看到的是一个标准的 OpenAI Responses API 端点，它不知道背后是 DeepSeek。你只需要改 OPENAI_BASE_URL，其他代码零修改。

用 Python SDK 直接调用网关

如果你不用 Codex CLI，而是用 OpenAI Python SDK 写自己的 Agent：

from openai import OpenAI

# 指向 GodeX 本地网关，用 DeepSeek 的 Key
client = OpenAI(
    base_url="http://localhost:8080/v1",
    api_key="sk-your-deepseek-key"
)

# 标准 Responses API 调用，GodeX 会翻译成 Chat Completions 发给 DeepSeek
response = client.responses.create(
    model="deepseek-r1",
    input="解释 Transformer 中 self-attention 的计算流程，给出伪代码"
)

print(response.output_text)

这段代码和调用 OpenAI 原生 Responses API 的写法完全一致，唯一改动就是 base_url 和 api_key。

工具调用的适配边界

GodeX 对工具调用的适配是整个网关中最复杂的部分，也是使用时需要留意边界的地方：

• code_interpreter：Codex CLI 的核心能力是让模型写代码并在沙箱中执行。GodeX 需要在本地维护一个执行环境，把模型的代码输出截取、执行、再把结果喂回对话。这意味着你的机器上需要有对应的运行环境（Python、Node.js 等）。
• web_search / file_search：这些工具在 Responses API 中是服务端执行的，但 Chat Completions 提供商不支持。GodeX 需要自己实现这些工具的本地版本，或者通过插件机制接入外部搜索服务。
• 自定义工具：如果你在 Responses API 请求中定义了自己的 function 工具，GodeX 会将其映射为 Chat Completions 的 function_call，这部分兼容性较好，因为两者结构相似。

实际使用中，纯文本对话和简单工具调用基本无障碍；复杂的多轮工具编排（比如 Codex 先搜索文档、再写代码、再执行验证）取决于 GodeX 对本地工具链的实现完整度。

选型考量：什么时候该用 GodeX

GodeX 解决的是一个明确的接入问题，但它不是万能的。几个判断维度：

一个务实的路径：先用 GodeX 把 Codex CLI 接到你手头的模型上跑起来，验证基本对话和代码生成能力；再逐步测试工具调用场景，看哪些工具在你的使用中是必须的，对应的本地实现是否满足需求。

GodeX 的价值不在于它有多完美，而在于它让"用 Codex 但不想只绑 OpenAI"这件事从不可能变成了可能。对于国内开发者来说，这是一个值得立刻试一下的工具。