乐于分享
好东西不私藏
当前位置：夜雨聆风 > 技术教程 > 软件教程 > Codex App 国产大模型“卡壳”了?Responses API 兼容性痛点与社区 PR 救场实战

Codex App 国产大模型“卡壳”了?Responses API 兼容性痛点与社区 PR 救场实战

当前时间： 2026-05-04 16:56:20 更新时间： 2026-05-04 分类：软件教程 评论(0)

Codex App 国产大模型“卡壳”了?Responses API 兼容性痛点与社区 PR 救场实战

Codex App 国产大模型“卡壳”了？Responses API 兼容性痛点与社区 PR 救场实战

大家好，我是 weijia。最近 Codex App（OpenAI 推出的 AI 编程智能体桌面客户端）火爆开发者圈，它能并行管理多个 Agent、支持 Worktree、多线程开发，配合 GPT-5 系列模型简直是 coding 神器。

所以我后来有个想法，就是让国产大模型也能在 Codex App 中使用。

由于国产模型具有明显的价格优势，如果能将其作为 API 调用，再配合最先进的 Agent 桌面端应用，体验应该会非常好。

曾经很多操作，就是想把国产的大模型用到 Claude Code 这种 CLI 工具里面使用。

为什么呢？

1. 它工具内置的一些调用逻辑非常优秀。

2. 配合国内模型或者其他第三方模型，会有明显的性能优势，表现得也会更加聪明。

那么现在我觉得最好用的肯定是 CodeX App。

所以现在的想法是将国产大模型接入到 CodeX App，但是它有一些坑点，接下来我为大家讲一下：

developers.openai.com

developers.openai.com

但国内开发者一上手就踩坑：Kimi、GLM、DeepSeek 等国产大模型基本无法正常在 Codex App 里跑。明明 API Key 配置好了，却报错、卡住或功能残缺。

我之前尝试过各种中转方案（包括 CPA），虽然能部分解决，但 CodeX App 专用的 Response 回复模式 还是不兼容。直到我拉取了一个未提交、未合并的 PR，问题才彻底解决——现在 Kimi 等国产模型在 Codex App 上已经能丝滑运行了。

今天这篇文章，就来系统聊聊这个兼容性问题、根源、解决方案，以及我亲测的 PR 实践。希望帮到同样被“卡”的朋友们。

1. 核心问题：Responses API vs Chat Completions API

Codex App（包括 CLI 和桌面版）底层依赖 OpenAI 2025 年推出的 Responses API（官方称为新一代响应式接口）。这个 API 专为 Agent 智能体设计：

  • 支持服务器端状态管理（store: true）
  • 一次性多工具调用（Tool Use）
  • 更高效的推理循环和缓存
  • 优化了复杂工作流、长上下文和代码执行场景

而传统 Chat Completions API（/v1/chat/completions）是 GPT-3.5 时代的产物，主要用于简单对话，虽然大部分国产大模型都完美兼容，但无法满足 Codex 的 Agent 循环需求。

medium.com

developers.openai.com

OpenAI 已经在 Codex 中逐步弃用 Chat Completions（config.toml 里 wire_api = “chat” 会触发弃用警告，2026 年初将彻底移除）。国产大模型厂商目前大多只适配了 Chat 模式，Responses API 支持还处于“待办”状态（智谱 GLM 甚至有开发者专门提 Issue 请求官方支持）。

abdulazizahwan.com

The AI with a Near-Perfect Memory: Why Moonshot AI Kimi is a Game-Changer –  Abdul Aziz Ahwan

结果就是：直接接入 = 连不上或功能不全。

2. 早期解决方案：CPA 等中转代理的“部分胜利”

社区很快出现了各种中转代理方案，其中 CPA（CLIProxyAPI） 是比较成熟的一个。它能把国产模型的 Chat Completions 接口“包装”成 OpenAI 兼容格式，让 Codex CLI 勉强跑起来。

blog.laozhang.ai

Codex config.toml: Where It Lives, What Wins, and Safe Examples | LaoZhang  AI Blog

很多朋友（包括我）安装 CPA 后，确实能连上 Kimi、GLM 等，但在正式的 CodeX App 里依然存在兼容性问题：

  • Agent 循环偶尔中断
  • Tool Call 不稳定
  • 部分高级特性（如并行线程、计算机使用）无法触发
  • 配置稍有偏差就报 “wire_api” 不匹配

CPA 解决了“能连上”的问题，但没能彻底抹平 Responses API 的协议差异。这也是为什么很多教程里说“CLI 能用，App 不行”。

3. 终极救场：拉取未合并 PR 后的完美体验

我刷 GitHub 时，发现了一个尚未提交正式 PR、也未被合并的社区补丁。它主要做了两件事：

  1. 优化了自定义 model_provider 对 Responses API 的兼容处理；
  2. 为 Kimi（Moonshot K2 系列）等国产模型添加了更精细的 wire_api 适配和请求转换逻辑。

操作步骤（亲测有效）：

  1. 克隆 Codex 官方仓库（或对应 fork）；
  2. 切换到那个分支，拉取 PR 代码；
  3. 在 ~/.codex/config.toml 中按如下方式配置（以 Kimi 为例）：

toml

[model_providers.kimi]
name = "Kimi K2 (via PR patch)"
base_url = "https://api.moonshot.cn/v1"  # 或你的 CPA 中转地址
api_key = "sk-你的KimiKey"
wire_api = "responses"  # 关键：强制走 Responses 模式
# 其他可选：headers、query_params 等按 PR 建议补充
  1. 重启 Codex App，选择对应 Provider 和模型（Kimi K2.5 / GLM-5.1 等）。

拉取后，我直接在 CodeX App 里新建 Thread 测试了一个完整项目重构任务：Kimi 不仅能正常响应，还完美支持了 Tool Call、代码执行和多轮迭代，速度和稳定性比之前 CPA 方案提升明显。

make.wordpress.org

GitHub Pull Requests for Code Review – Make WordPress Core

目前这个 PR 还在社区讨论阶段，但已经可以本地编译运行。如果你也遇到同样问题，建议先去相关 Issue 搜索“Responses API Kimi”或“国产模型 wire_api”，大概率能找到类似补丁。

4. 实际体验与建议

  • 优点
    ：国产模型中文理解强、价格亲民、上下文窗口大（Kimi 256K+），配合 Codex App 的 Agent 能力后，性价比直接起飞。
  • 注意事项
    ：
    • 优先选择官方已支持 Responses 的中转平台（少数平台已跟进）；
    • 配置时务必把 wire_api = “responses” 写在 model_providers 下（不是 profiles）；
    • 代理网络要稳，Responses API 对延迟更敏感；
    • 关注官方弃用进度，长期看还是希望国产厂商原生支持。

未来展望：随着 GLM、Moonshot、DeepSeek 等官方逐步跟进 Responses API，这个兼容性问题会自然消失。但在过渡期，社区 PR + 精准配置 就是最快解决方案。

你也在用 Codex App 接国产模型吗？欢迎评论区分享你的配置或遇到的坑。一起把这个生态玩起来！

（本文基于个人实测和公开社区讨论，配置以最新版本为准，建议备份 config.toml 再操作。）

图片来源：OpenAI 官方文档、GitHub、Moonshot 官网及社区教程。