Codex 接入 GLM 实战：Responses API 配置与工具调用验证

2026 年，AI 编程工具的使用方式已经发生了明显变化。开发者不再满足于让模型生成一段函数，而是希望它能够进入现有代码仓库，分析文件之间的调用关系，定位实际运行错误，并在修改完成后执行测试。随着 Coding Agent 逐渐进入日常开发流程，另一个问题也开始受到关注：如果已经习惯使用 Codex 完成项目开发，是否可以保留它的操作方式，同时更换底层模型？

这个问题并不只是为了降低 API 成本。对于希望使用国产模型的开发者，将 GLM 接入 Codex 意味着有机会继续利用既有的终端交互、文件操作和任务执行机制，同时根据项目需要选择不同的模型服务。

Codex 本身是 OpenAI 推出的编程 Agent 工具，但它的执行框架与底层模型并不是完全相同的概念。根据官方配置文档，Codex CLI 允许用户通过 config.toml 定义自定义模型提供方，包括 API 基础地址、认证方式和模型名称。

不过，能够自定义模型提供方，并不意味着所有兼容 OpenAI 接口的模型都能直接使用。2026 年以来，Codex 在自定义服务协议方面发生了重要变化。根据当前官方源码，其自定义模型提供方已经统一采用 Responses API，而旧教程中常见的 Chat Completions 适配方式不再适用于最新版本。

这一变化直接影响 GLM 接入 Codex 的可行性。开发者需要同时确认 Codex 的协议要求、GLM 服务端实际提供的接口，以及所使用 API 渠道的兼容情况。只修改模型名称和 API 地址，并不足以保证 Coding Agent 可以完成真实的软件工程任务。

一、Codex 为什么不等于底层模型？理解 Coding Agent 的三个组成部分

Codex 最初受到关注，与它能够在终端中直接操作代码仓库有关。开发者可以进入项目目录，使用自然语言描述需要完成的任务。Codex 根据当前上下文决定是否读取文件、执行命令或修改代码，并将工具运行结果重新提供给模型。

对于一次普通代码解释任务，模型可能只需要读取文件并生成回答。但如果用户要求修复 Bug，Codex 通常还需要组织多轮工具操作。它可能先搜索相关函数，再检查依赖关系，随后修改代码并执行测试。如果测试失败，还需要根据错误信息判断是否继续处理。

整个过程由多个软件组件共同完成。

1. Codex CLI 负责管理本地交互、工具执行和权限控制。
2. 底层大语言模型负责理解用户意图，并根据上下文生成回答或工具调用请求。
3. 模型 API 则承担两者之间的通信，使 Codex 能够将消息发送到远程模型服务，并取得返回结果。

这三个部分彼此关联，但职责不同。

例如，假设开发者要求 Codex 修复某个 Python 函数。模型可以判断需要使用文件读取工具，并生成相应的工具调用信息。真正读取本地文件的操作由 Codex 执行，而不是远程模型直接访问开发者电脑。

当文件内容被读取后，Codex 将必要的执行结果重新发送给模型，模型再继续分析。

因此，即使更换底层模型，只要新模型能够正确理解 Codex 提供的上下文，并返回符合协议的工具调用内容，就有可能继续使用原有的 Coding Agent 工作流。

但这里存在一个限制：不同模型对工具调用、结构化输出和长上下文的支持方式可能不同。即使使用相同的 Codex 客户端，也不能保证不同模型具有完全相同的任务执行效果。

对于开发者来说，Codex 是否能够接入 GLM，本质上是一个协议兼容与执行能力验证问题，而不只是模型能否生成 Python 代码。

二、Codex 如何与模型服务通信？Responses API 为什么重要？

很多开发者对 OpenAI 兼容接口的理解，主要来自 Chat Completions API。

在常见的聊天应用中，开发者通过 POST /v1/chat/completions发送请求，请求体包含模型名称、消息数组和必要参数。服务端生成响应后，返回文本内容或工具调用信息。

由于这种接口形式较为常见，不少国产模型也提供兼容实现。开发者只需要修改 API Key、Base URL 和模型 ID，就能够通过类似的 SDK 调用不同模型。

但 Codex 对接口的要求更加复杂。

Coding Agent 不仅需要完成单轮聊天，还需要处理多步骤任务执行。模型可能连续返回工具调用，随后接收工具执行结果，再继续生成新的操作。对于较长的开发任务，还涉及流式响应、上下文维护和推理过程管理。

OpenAI Responses API 为这类交互提供了不同于传统 Chat Completions 的请求与响应结构。

在 Responses API 中，模型输出可以包含不同类型的项目，例如普通消息、函数调用以及其他结构化内容。工具调用使用独立的调用标识，应用需要根据这些信息执行工具，并将结果关联到相应调用。

这与传统 Chat Completions 主要围绕 messages 数组组织对话的方式存在区别。

下面是一个简化的 Responses API 请求示例：

{
  "model": "YOUR_MODEL_ID",
  "input": [
    {
      "role": "user",
      "content": "解释Python中的装饰器"
    }
  ],
  "stream": true
}

这里的模型名称只是占位符。示例用于展示协议结构，不代表任意模型服务都能处理此请求。

相比之下，Chat Completions 通常采用以下结构：

{
  "model": "YOUR_MODEL_ID",
  "messages": [
    {
      "role": "user",
      "content": "解释Python中的装饰器"
    }
  ]
}

两个接口虽然都能完成文本生成，但请求字段、响应结构和工具调用处理方式并不完全一致。仅仅因为服务商支持/chat/completions，就判断其能够用于最新版 Codex，是不准确的。

2026 年 Codex 自定义 Provider 发生了什么变化？

根据 OpenAI 当前公开的 Codex 源码，自定义模型提供方通过model_providers定义。其wire_api字段对应的协议类型已经限定为responses。

旧版本配置中常见的：

wire_api = "chat"

在当前版本中已经不再被支持。相关源码会针对这一配置返回错误，并提示开发者改用 Responses 协议。

因此，网上部分旧版教程虽然在发布时能够使用，但直接复制到当前 Codex CLI 中，可能在配置解析阶段就失败。

新版配置应该采用：

wire_api = "responses"

不过，这项修改只解决 Codex 客户端使用什么协议的问题。服务端还必须真正支持 Responses API，并能够正确处理 Codex 发送的请求。

如果第三方模型服务只有 Chat Completions 接口，直接改成responses并不会使其自动具备相应能力。

这也是 GLM 接入 Codex 时最值得关注的技术边界。

三、国产 GLM 能否直接接入 Codex？需要确认哪些兼容条件？

GLM 系列模型已经形成面向推理、代码生成和 Agent 任务的产品体系。智谱公开的 GLM-5 系列资料将软件工程和 Agentic Engineering 列为重要应用方向，相关模型也支持结构化工具调用及多轮任务处理。

从模型能力来看，GLM 具备参与 Coding Agent 任务的基础条件。但是否能够在 Codex 中正常使用，还取决于实际调用服务支持的协议。

这里需要将模型能力与 API 能力分开讨论。
GLM 模型可以理解代码和生成工具调用信息，并不代表任何提供 GLM 服务的 API 地址都支持 OpenAI Responses 协议。对于不同服务区域、套餐或模型版本，接口支持范围可能存在差异。

尤其是 GLM Coding Plan 与普通按量计费模型 API，可能使用不同的认证方式和调用入口。开发者不能简单把某个 Coding Plan 地址当作通用 Responses API 地址使用。

此前，已有开发者在 Codex 官方 GitHub 仓库提交 GLM 接入问题，反馈自定义 Chat Completions 提供方在角色转换过程中遇到错误。部分请求使用了 developer 角色，而对应服务端只接受特定消息角色，最终导致请求失败。

这类问题说明，即使两个系统都声称兼容 OpenAI 接口，仍可能因为协议版本、角色字段和响应处理方式不同而出现问题。

对于当前 Codex 版本，需要重点验证以下能力：

• Responses API：是否提供可调用的/v1/responses兼容端点
• 模型标识：当前账户是否具有目标 GLM 模型的调用权限
• 工具调用：是否能返回 Codex 可以识别的函数调用结构
• 流式输出：是否支持正确的 SSE 事件格式
• 多轮交互：是否能正确处理工具调用结果和后续请求
• 上下文处理：是否支持任务所需的输入规模
• 认证机制：是否能够使用 Codex 支持的 API Key 认证方式

这些能力需要在具体服务端进行验证。一个模型能够通过 Python SDK 完成普通对话，只能证明基础文本调用可用，不能直接证明它可以承担 Codex 中的文件编辑任务。

对于准备使用 GLM 的开发者，更合理的接入流程，是先确认目标服务支持 Responses API，再测试工具调用，最后才进入真实项目开发。

四、GLM 接入 Codex 的配置实践：从安装到模型验证

下面以 Codex CLI 为例，说明如何配置自定义模型提供方，并建立一套用于验证 GLM 兼容性的测试流程。
示例基于截至 2026 年 10 月官方公开的 Codex 配置结构编写。由于不同 GLM 服务的 API 路径和模型权限可能不同，涉及具体服务地址的位置采用占位符，不将未经验证的接口写成可直接运行的官方地址。

1. 安装 Codex CLI

Codex 官方 GitHub 仓库提供了 npm 安装方式，开发者可以通过以下命令安装：

npm install -g @openai/codex

安装完成后检查版本：

codex --version

如果终端无法识别 codex 命令，需要确认 Node.js 和 npm 已正确安装，并检查 npm 全局可执行文件目录是否加入系统 PATH。

在 Windows 系统中，Codex 也提供官方原生安装方式。具体安装要求可以参考 OpenAI 官方仓库，以免沿用过旧的系统环境说明。

2. 找到 Codex 配置文件

Codex CLI 默认从用户目录读取配置。

• Windows 路径：C:\Users\你的用户名\.codex\config.toml
• Linux/macOS 路径：~/.codex/config.toml

如果文件不存在，可以手动创建对应目录和配置文件。
Codex 也支持项目级配置，但与认证及 Provider 有关的设置，应优先放入用户级配置文件。根据最新官方参考文档，项目级配置不能覆盖部分机器本地的 Provider 和认证相关字段。

3. 配置 GLM 模型提供方

假设开发者已经取得一个支持 Responses API 的 GLM 模型服务地址，并确认当前账户可以调用相应模型，可以在config.toml中添加以下配置：

model = "YOUR_GLM_MODEL_ID"
model_provider = "glm_custom"

approval_policy = "on-request"
sandbox_mode = "workspace-write"

[model_providers.glm_custom]
name = "GLM Compatible Provider"
base_url = "https://YOUR_RESPONSES_API_BASE/v1"
env_key = "GLM_API_KEY"
wire_api = "responses"

• model：需要调用的模型 ID，必须使用服务端实际提供的名称，不能根据模型产品名称自行推断。
• model_provider：指定当前使用的提供方，必须与下方[model_providers.glm_custom]的标识对应。
• base_url：API 基础地址，填写服务商公布的 Responses 兼容入口，不要直接复用 Chat Completions 地址。
• env_key：读取 API 密钥的环境变量名，避免明文写入密钥。
• wire_api：指定 Codex 采用 Responses API 通信。

示例还设置了需要确认的审批策略，以及限制在工作区内执行文件修改的沙箱模式。具体权限行为仍应以当前 Codex 版本和操作系统提供的安全机制为准。

>
> 注意：base_url 通常包含 API 版本前缀，Codex 会在其基础上拼接请求路径。如果填写完整/responses路径，客户端重复追加路径会触发 404 错误。

4. 配置 API Key

Windows PowerShell：

$env:GLM_API_KEY="你的实际API密钥"

Linux / macOS：

export GLM_API_KEY="你的实际API密钥"

密钥从模型服务平台获取，禁止提交到 Git 仓库，不要公开发布。

5. 启动 Codex 并测试基础连接

cd codex-glm-demo
codex

如果配置正常，Codex 会使用自定义 Provider 连接 GLM 服务。

首次连通不等于全部 Coding Agent 能力可用，优先执行只读测试指令：

>
> 请解释当前 Python 项目的目录结构。暂时不要修改任何文件。

• 401：核对 API Key、环境变量是否被 Codex 进程读取。
• 404：确认 Responses 端点真实存在。
• 请求字段非法 / 角色不支持：属于协议实现差异，并非单纯密钥配置问题。

>
> 本文不提供未经实测的运行截图，不同 GLM 服务地址的兼容性需要开发者在自有账户下实测验证。

6. 使用koalaAPI 作为可选接入路径

koalaAPI 是模型中转网关，完全兼容 OpenAI Python / Node SDK，原有 SDK、Prompt、参数全部保留，仅修改 baseURL 即可切换模型，实现分钟级迁移。注册账户后可在控制台一键生成 API 密钥，支持按团队、项目、成员分配独立密钥与额度。对于已经使用考拉 API 统一管理多模型调用的开发者，可直接将其作为 Codex 的模型 API 接入层，不用为每个模型单独维护认证与服务地址。

前提：平台支持目标 GLM 模型，并且完整实现 Responses API 兼容。

参考配置模板：

model = "YOUR_KOALA_GLM_MODEL_ID"
model_provider = "koala_glm"

[model_providers.koala_glm]
name = "GLM via KoalaAPI Gateway"
base_url = "https://koalaapi.com/v1"
env_key = "KOALA_API_KEY"
wire_api = "responses"

网关地址、模型 ID 以平台控制台信息为准。

配置完成后，必须依次验证普通文本响应、工具调用、流式输出。koalaAPI 网关保留流式输出与 Function Call 能力，但网关不会自动将 Chat Completions 接口转换成符合 Codex 要求的 Responses 接口，不能仅凭 OpenAI SDK 兼容就默认 Codex 可正常工作。

五、实战验证：让 GLM 通过 Codex 理解代码、修复 Bug 并执行测试

配置完成后，搭建小型 Python 项目验证 Coding Agent 完整链路。本示例无外部依赖，可区分模型理解能力与工具调用链路是否正常。

项目目录：

codex-glm-demo/
├── pagination.py
└── test_pagination.py

pagination.py

def paginate(items, page, page_size):
    start = page * page_size
    end = start + page_size
    return items[start:end]

缺陷：页码从 1 开始场景下，第一页索引计算错误。

test_pagination.py

from pagination import paginate

def test_first_page():
    items = list(range(30))
    result = paginate(items, 1, 10)
    assert result == list(range(10))

def test_second_page():
    items = list(range(30))
    result = paginate(items, 2, 10)
    assert result == list(range(10, 20))

执行测试：

python -m pytest -q

测试预期失败，对应分页偏移 bug。

在项目目录启动 Codex，输入任务指令：

>
> 请阅读 pagination.py 和 test_pagination.py，定位导致分页测试失败的原因。先解释问题，再进行最小修改，不要改变函数签名或测试断言。修改完成后运行 pytest，并说明测试结果。

该任务可一次性验证多环节：

1. 文件读取工具调用是否生效
2. 模型代码理解能力
3. 文件写入 / 修改权限与沙箱策略
4. 终端命令执行
5. 根据测试结果做二次推理

预期修复代码：

def paginate(items, page, page_size):
    start = (page - 1) * page_size
    end = start + page_size
    return items[start:end]

再次执行 pytest，测试用例通过。

重要说明：上述为理论预期修复结果，本文未使用真实 GLM+Codex 环境做端到端实测，不代表任意 GLM 服务都可以稳定完成该任务。

推荐使用 Git 追踪变更：

git diff

检查模型修改范围，避免无关代码改动。

即使自动化测试全部通过，生产环境仍需要额外评审，测试覆盖率、异常输入、上下游依赖都可能隐藏问题。

六、接入成功之后，为什么还需要继续测试工具调用和上下文管理？

基础代码修复通过，仅代表模型可完成简单任务。面向真实开发，必须验证长任务稳定性。

工具调用成功率的累积风险

Coding Agent 完成跨文件修改往往需要连续十多次工具调用。
举例：单次工具调用成功率 95%，连续 10 次调用全部成功理论概率约 59.9%。

仅为数学示例，不代表 GLM 实测成功率。

Agent 虽可通过重试提升成功率，但会带来额外 Token 消耗与成本。单轮函数调用表现良好 ≠ 长程软件工程任务稳定可靠。

上下文窗口不等于有效项目理解能力

编程 Agent 上下文包含用户需求、系统提示、源码、工具返回日志。对于大型仓库，增量读取文件优于一次性传入全部代码。

即使模型支持超长上下文，仍要验证：

• 精准定位目标函数
• 多轮修改保持任务一致性
• 不随意修改无关代码

Codex 自带上下文压缩与会话管理，第三方模型能否适配取决于 Responses 协议实现，不能默认长会话无异常。

流式输出验证要点

Codex 依赖流式 SSE 事件实时处理 Agent 执行流程。文本生成正常，但流式中断、事件结构错误，依然会造成任务中断。

Codex 自定义 Provider 支持调整重试次数、流空闲超时参数，用于缓解网络波动。但协议本身不兼容的情况下，调大超时参数无法解决根本问题。

模型效果评估思路

团队可以构建标准化工程测试集，覆盖简单 Bug 修复、跨文件修改、新增单元测试。
评估指标：

• 任务完成率
• 单次任务平均工具调用轮次
• 任务级总成本（而非单纯单价对比）

部分模型 Token 单价低，但频繁重试、反复修改，整体任务成本反而更高。评估核心指标：成功完成一次开发任务的资源消耗，而非单次 API 请求。

使用koalaAPI 管理模型调用的团队，可将 Token 消耗与任务 ID 关联，统计不同任务类型的成本。最终计费以平台账单为准。

七、GLM 接入 Codex 的常见问题与排查思路

排查需要沿着完整通信链路分层定位，不要直接把所有问题归为模型能力不足。

表格

很多时候 “无法执行文件操作” 不是模型不会生成工具调用，而是网关 / 模型服务返回的工具调用结构体缺少 Codex 要求的字段。

八、Codex 接入国产模型，真正值得关注的是什么？

Codex 支持自定义模型提供方，给开发者替换底层模型的选择权。GLM 等国产模型有机会复用 Codex 成熟的终端交互、本地文件操作、任务执行框架。

但存在硬性前置条件：新版 Codex 自定义 Provider 强制要求 Responses API。模型本身代码能力再强，如果服务端只实现 Chat Completions 接口，无法直接接入。

接入流程的正确顺序：

1. 确认 GLM 服务提供兼容 Responses API 的端点
2. 配置 config.toml 自定义 provider
3. 小型工程用例验证文件读写、代码修改、命令执行闭环
4. 长任务、多文件场景做稳定性测试

基础对话通过只是第一步，长上下文、多轮工具调用、流式 SSE 事件都需要验证。对于生产级 Coding Agent，复杂任务稳定性远比重演一次 demo 更重要。

长远来看，Coding Agent 框架与底层大模型解耦是行业趋势：客户端负责本地项目操作与权限管控，远端模型服务负责推理，统一 API 接入层简化多模型运维。

但分层架构不能消除模型能力差异，也不能自动修复协议兼容缺陷。必须依靠可复现的工程测试，判断模型是否适配项目。

Codex 并不必然只能使用 OpenAI 模型，但 “支持自定义 Provider” 和 “GLM 完整兼容 Codex” 之间存在大量需要验证的技术环节。

对于想要落地国产模型 + Codex 方案的开发者，合理路径是从协议验证起步，使用小型工程任务验证基础闭环，再逐步扩展到复杂代码仓库与长时间 Agent 任务。

只有模型输出、工具执行、结果验证形成稳定闭环，GLM 接入 Codex 才从接口配置变成可长期使用的开发方案。

了解更多：https://koalaapi.com