当前位置：首页 > 全部内容 > Codex+智谱GLM完整跑通教程(全网唯一测试通过)

Codex+智谱GLM完整跑通教程(全网唯一测试通过)

作者：技术拾光时间：2026-05-30 08:03:07浏览：587

利用litellm作为协议翻译网关，将Codex的ResponsesAPI请求转换为智谱GLM支持的ChatCompletions协议，并手动修复litellm两个已知bug（过滤client_metadata等参数及非function类型工具），从而成功实现跨平台、跨协议的跨界调用，确保了兼容性与功能完整性，使得Codex应用能够无缝调用智谱GLM模型。

近期，Codex这一话题再度引发业内关注。据相关团队反馈，该工具在节省Token方面表现突出，GPT-5.2-Codex编码模型的使用体验也较为流畅。然而，国内开发者面临一个现实困境：Codex目前仅支持连接OpenAI自家模型。

我们团队长期使用Claude Code，同时持有智谱GLM的Coding套餐。是否可以将GLM模型直接接入Codex使用？答案是肯定的，但无法实现"直连"——中间必须增加一层协议转换。

许多开发者的第一反应是使用CC Switch，毕竟该工具专为模型切换场景设计。但实践证明，CC Switch对Claude Code有效，对Codex却无法正常工作。

CC Switch：功能边界解析

CC Switch作为一款AI编码工具配置管理软件，主要功能包括管理API Key、Base URL、MCP Server、系统提示词等。它支持一键切换Claude Code、Codex、Gemini CLI的provider，操作确实便捷。

对于Claude Code而言，CC Switch完全够用。由于GLM提供了Anthropic兼容接口（/api/anthropic），只需将ANTHROPIC_BASE_URL指向对应地址，Claude Code即可直接连接GLM，运行无碍。

但Codex的情况不同——它强制要求使用OpenAI的Responses API协议（POST /v1/responses），而GLM仅支持Chat Completions协议（POST /v4/chat/completions）。

CC Switch可以修改URL，但无法转换协议。将Codex的Base URL指向GLM后，Codex发送Responses API请求，GLM将返回404错误。协议层面的不兼容，导致工具无法发挥作用。

解决方案：litellm协议转换

既然Codex使用Responses API，而GLM无法识别，可以在中间部署一个协议转换层：

Codex Desktop → litellm（协议转换）→ 智谱 GLM

litellm是一款开源大模型网关，其核心优势在于支持多种API协议互转。自某个版本起，它已支持Responses API到Chat Completions的桥接模式，这正是所需功能。

安装与配置litellm

安装过程简便，通过pip即可完成：

pip install litellm

确认版本不低于1.66.3（低于该版本不支持Responses API桥接）：

python3 -c "import importlib.metadata; print(importlib.metadata.version('litellm'))"
输出类似：1.83.11

此外，需要准备好智谱API Key。需特别注意，智谱提供两个接口地址，切勿混淆：

  • 标准接口：open.bigmodel.cn/api/paas/v4
  • Coding接口：open.bigmodel.cn/api/coding/…

如果购买的是coding-plan套餐，必须使用Coding接口地址；标准套餐则使用标准接口。接口选择错误，后续所有配置将无效。

配置litellm

创建配置文件~/.claude/litellm-config.yaml：

model_list:
  # 为 Codex 配置的条目
  - model_name: glm-5.1
    litellm_params:
      model: custom_openai/glm-5.1
      api_base: https://open.bigmodel.cn/api/coding/paas/v4
      api_key: 你的智谱API-Key

配置完成后启动litellm：

nohup litellm --config ~/.claude/litellm-config.yaml --port 4000 > /tmp/litellm.log 2>&1 &

验证启动状态：

curl -s http://127.0.0.1:4000/health | python3 -c "import sys,json; d=json.load(sys.stdin); print(f'healthy: {d[\"healthy_count\"]}')"
# 输出：healthy: 1

测试Responses API桥接是否正常：

curl -s -X POST http://127.0.0.1:4000/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer 你的API-Key" \
  -d '{"model":"glm-5.1","input":"你好","stream":false}'

返回包含output字段的JSON，说明协议转换成功。接下来配置Codex Desktop。

配置Codex

Codex的配置文件位于~/.codex/config.toml，编辑如下：

model_provider = "custom"
model = "glm-5.1"
model_reasoning_effort = "high"
disable_response_storage = true

[model_providers]
[model_providers.custom]
name = "custom"
wire_api = "responses"
requires_openai_auth = true
base_url = "http://127.0.0.1:4000"

需注意以下关键点：

  1. model设置为glm-5.1，需与litellm配置中的model_name保持一致。
  2. wire_api保持"responses"，告知Codex仍使用Responses API（litellm负责协议转换）。
  3. base_url指向本地litellm地址http://127.0.0.1:4000。

然后编辑认证文件~/.codex/auth.json：

{
  "OPENAI_API_KEY": "你的智谱API-Key"
}

完全退出Codex Desktop后重新打开，在新对话中发送消息测试。若litellm配置正确，Codex应能收到GLM的回复——但大概率会遇到两个报错，需按以下步骤处理。

修复litellm的两个已知问题（必需操作）

litellm的Responses API桥接模式存在两个已知问题，官方尚未修复，若不手动修改将无法正常运行。

首先找到litellm安装路径：

python3 -c "import litellm; print(litellm.__path__[0])"
# 类似：/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/litellm

需修改的文件为responses/litellm_completion_transformation/handler.py。

问题一：client_metadata未过滤

报错信息：AsyncCompletions.create() got an unexpected keyword argument 'client_metadata'

原因是Codex发送的请求中包含client_metadata字段（Codex自身使用的元数据），litellm在协议转换时未过滤该字段，直接传递给了底层OpenAI客户端，导致客户端无法识别而报错。

打开handler.py，找到异步方法async_response_api_handler中的以下代码段：

acompletion_args = {}
acompletion_args.update(kwargs)
acompletion_args.update(litellm_completion_request)
litellm_completion_response: Union[

在await litellm.acompletion之前插入过滤代码：

acompletion_args = {}
acompletion_args.update(kwargs)
acompletion_args.update(litellm_completion_request)

# --- Patch: 过滤Responses API专有参数 ---
for _k in ["client_metadata", "max_output_tokens", "previous_response_id"]:
    acompletion_args.pop(_k, None)

litellm_completion_response: Union[

同步方法response_api_handler中存在相同代码，同样进行修改（将acompletion_args替换为completion_args）。

问题二：非function类型工具未过滤

Codex发送的工具列表中包含web_search、code_interpreter、file_search等OpenAI专有工具类型，而GLM仅支持function类型。litellm同样未进行过滤处理。

在上一步的参数过滤代码之后，紧跟添加工具过滤：

# --- Patch: 过滤非function类型工具 ---
_tools = acompletion_args.get("tools")
if _tools and isinstance(_tools, list):
    acompletion_args["tools"] = [t for t in _tools if t.get("type") == "function"]

litellm_completion_response: Union[

同步方法同理，将acompletion_args替换为completion_args。

修改完成后重启litellm：

kill $(lsof -i :4000 -t)
nohup litellm --config ~/.claude/litellm-config.yaml --port 4000 > /tmp/litellm.log 2>&1 &

然后打开Codex Desktop发送消息，正常情况下连接应已成功建立。

总结

以下是最终链路和相关配置汇总：

Codex Desktop (Responses API) → litellm (:4000) → 智谱 GLM (Chat Completions)

涉及的主要配置文件：

  • ~/.claude/litellm-config.yaml — litellm网关配置（模型、API地址、Key）
  • ~/.codex/config.toml — Codex配置（模型、协议、网关地址）
  • ~/.codex/auth.json — Codex API Key
  • ~/.zshrc — Claude Code环境变量（GLM直连配置）
  • litellm handler.py — 源码修改（两个问题修复）

核心逻辑可概括为：协议不兼容时，增加转换层。

CC Switch属于配置管理工具，而非协议转换工具。Claude Code与GLM协议本身兼容，因此无需转换；Codex与GLM协议不兼容，必须依靠litellm在中间进行协议转换。明确这两者的区别，配置过程将更加顺畅。

总之，如需使用国内模型，而对方未提供/v1/responses API协议，可参照此方案实施。最后需要指出，近期Codex关注度再次提升，其在节省Token方面的表现确实出色，输出质量也保持稳定，尤其适合不偏好Claude Code命令行模式的用户群体。