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

Codex 最近大家又开始讨论了,听隔壁部门讲,賊省token,而且GPT-5.2-Codex 编码模型确实好用。但国内开发者面对一个现实问题:它只能连 OpenAI 的模型

因为我们部门一直在用Claude code,且有智谱 GLM 的 coding 套餐,想直接喂给 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 不一样。Codex 强制使用 OpenAI 的 Responses API 协议(POST /v1/responses),而 GLM 只认 Chat Completions 协议(POST /v4/chat/completions)。

所以今天我们就聊一个事,那就是你既想用国内的模型,但是它又没有/v1/responses API协议的情况,该怎么搭配Codex使用

CC Switch 能帮你改 URL,但改不了协议。你把 Codex 的 Base URL 指向 GLM,Codex 发一个 Responses API 请求过去,GLM 直接返回 404。

一句话总结:CC Switch 是「换地址牌」,不是「翻译官」。Claude Code + GLM 协议本身兼容,换个地址就行;Codex + GLM 协议不兼容,换地址没用,得有人中间做翻译。

新方案:litellm 做协议翻译

既然 Codex 说 Responses API,GLM 听不懂,那就在中间放一个翻译:

Codex Desktop → litellm(协议翻译)→ 智谱 GLM

litellm 是一个开源的 LLM 代理网关,支持多种 API 协议互转。关键是它从某个版本开始支持了 Responses API 到 Chat Completions 的桥接模式。

安装配置 litellm

直接 pip 安装:

linux 复制代码
pip install litellm

确认版本 >= 1.66.3(低于这个版本不支持 Responses API 桥接):

linux 复制代码
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:

linux 复制代码
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

注意看模型前缀是 custom_openai/ 不是 openai/。这个很关键------litellm 源码里 openai provider 被硬编码为支持原生 Responses API,用 openai/ 前缀的话 litellm 会把请求原样转发给 GLM,还是 404。custom_openai/ 没有注册 Responses API 配置,litellm 才会走翻译路径。

配置写好后启动 litellm:

linux 复制代码
nohup litellm --config ~/.claude/litellm-config.yaml --port 4000 > /tmp/litellm.log 2>&1 &

验证一下是否正常:

linux 复制代码
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 桥接是否通:

linux 复制代码
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,编辑成这样:

linux 复制代码
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

json 复制代码
{
  "OPENAI_API_KEY": "你的智谱API-Key"
}

完全退出 Codex Desktop 再重新打开,在新对话里发条消息试试。到这一步如果 litellm 配置正确,Codex 已经能收到 GLM 的回复了------但大概率你会遇到两个报错。接着看下一步。

修复 litellm 的两个 Bug(必做)

litellm 的 Responses API 桥接模式有两个已知但至今没修的 bug,不改的话根本跑不通。需要手动 patch 源码。

先找到 litellm 安装路径:

linux 复制代码
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

Bug 一:client_metadata 没过滤

报错长这样:AsyncCompletions.create() got an unexpected keyword argument 'client_metadata'

Codex 发的请求里带了个 client_metadata 字段(Codex 自己用的元数据),litellm 翻译的时候没过滤,直接丢给了底层 OpenAI 客户端,客户端不认识就炸了。

打开 handler.py,找到 异步方法 async_response_api_handler 里的这段:

py 复制代码
        acompletion_args = {}
        acompletion_args.update(kwargs)
        acompletion_args.update(litellm_completion_request)

        litellm_completion_response: Union[

await litellm.acompletion 前面插入过滤代码:

py 复制代码
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)。

Bug 二:非 function 类型工具没过滤

Codex 发的工具列表里有 web_searchcode_interpreterfile_search 这些 OpenAI 专有工具类型,GLM 只支持 function 类型。litellm 照样没过滤。

在上一步的参数过滤代码后面,紧跟加上工具过滤:

py 复制代码
        # --- 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:

linux 复制代码
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 --- 源码 patch(两个 bug 修复)

核心思路就一句话:协议不兼容,就加个翻译。

CC Switch 是配置管理工具,不是协议转换工具。Claude Code + GLM 协议本身兼容所以不需要翻译,Codex + GLM 协议不兼容所以必须靠 litellm 中间转一道。分清这两件事,配置起来就不会走弯路。

最后讲下

还是刚才那句话,你既想用国内的模型,但是它又没有/v1/responses API协议的情况,就是这么玩,另外多说一句,最近codex又被炒起来,大家也可以多看看,很省token,而且输出质量不受影响,毕竟并不是所有人都喜欢用Claude code 的命令行模式。

相关推荐
乘风gg8 小时前
AI Coding 提效 2 倍是真的吗?到底怎么衡量效果
前端·ai编程·claude
修远客8 小时前
持久化与缓存:Agent的数据底座 — 没有持久化的Agent像金鱼记忆,重启就忘
llm·agent·ai编程
左青8 小时前
markdown 即数据库:为 AI 会话设计一个"文件协议"工作流
ai编程
小四的小六8 小时前
AI写测试翻车实录:测试全绿,上线还是崩了——一个format函数暴露的盲区
aigc·openai·ai编程
码途AI工坊9 小时前
大模型时代必修课:懂 Token 的人,用 1 块钱跑出别人 100 块钱的效果。
ai编程
Jul1en_9 小时前
Matt 与 Uncle Bob 的播客访谈有感
开发语言·经验分享·笔记·ai·开源·github·ai编程
是2的10次方啊9 小时前
AI 能写代码了,还要学设计模式、Spring 源码和 JVM 吗?
ai编程
全栈弄潮儿18 小时前
不要先问“用哪个 AI”,先盘点你的开发工作流
aigc·openai·ai编程
杨杨杨大侠19 小时前
大模型的权重到底怎么用?拆开一个 token 的生成过程
aigc·openai·ai编程
吴佳浩 Alben19 小时前
Agent 怎么做自动化评测?构建端到端的 Agent Evaluation 体系
人工智能·语言模型·架构·自动化·ai编程