最近在折腾原生 Codex 的模型接入时遇到了一个比较典型的问题当前 Codex 主要支持wire_api responses模式而很多第三方 OpenAI 兼容服务只提供/v1/chat/completions接口无法直接接入。其中agnes-20-flash是一个来自新加坡的免费 LLM 服务官方提供了不少框架集成方案但并没有针对原生 Codex 的直接接入教程。经过多次尝试各种中转方案后最终发现可以通过开源项目responses-proxy完美解决这个问题。本文就记录一下完整过程如何使用responses-proxy将agnes-20-flash接入原生 Codex并顺带推荐一个更稳定、更适合长期使用的中转服务 满意AI——https://api.aimanyi.top一、背景为什么 Codex 不能直接接第三方 OpenAI API很多第三方模型服务都会号称“兼容 OpenAI API”但这里的“兼容”通常指的是兼容/v1/chat/completions也就是传统的 Chat Completions API。而现在的原生 Codex 更倾向于使用wire_api responses也就是 OpenAI 新的 Responses API 风格。因此即使第三方服务支持 OpenAI 格式只要它没有实现/v1/responsesCodex 就无法直接调用。这就导致一个问题第三方 LLM 服务可以被 ChatGPT Web UI、Open WebUI、Cherry Studio、LiteLLM 等工具调用但是原生 Codex 调用失败Codex 配置里的wire_api responses又不能改成/v1/chat/completions模式所以必须找一个中间层把 Responses API 转换成 Chat Completions API。这正是responses-proxy的价值所在。二、方案选择responses-proxy项目地址https://github.com/CallOrRet/responses-proxyresponses-proxy的核心作用可以简单理解为在本地启动一个兼容/v1/responses的代理服务然后将请求转发到后端的/v1/chat/completions接口。也就是说Codex ↓ /v1/responses responses-proxy ↓ /v1/chat/completions agnes-20-flash这样 Codex 仍然保持wire_api responses但是底层实际调用的是 agnes-20-flash 提供的 OpenAI Chat Completions 接口。三、agnes-20-flash 简介agnes-20-flash是 Agnes AI 提供的免费 LLM 服务官方文档地址https://agnes-ai.com/zh-Hans/docs/agnes-20-flash它的优点很明显免费可用提供 OpenAI 兼容接口对国内外开发者都比较友好适合做轻量级代码补全、对话、测试和原型验证能接入多种常见 AI 客户端和框架。但也有一些客观限制免费服务不保证高可用响应速度有时较慢可能出现连接重试高峰期偶尔会报错在 Codex 中可能看到类似Reconnecting /5的提示。不过作为一个免费模型用来体验 Codex 的 agent 能力、测试工作流或者做轻度代码辅助已经非常不错了。四、准备工作需要准备Rust / Cargo 环境agnes-20-flash 的 API Key原生 Codexresponses-proxy 项目代码一个可编辑的 Codex 配置文件。如果你还没有 Rust 环境可以参考官方安装方式curl--protohttps--tlsv1.2-sSfhttps://sh.rustup.rs|sh安装完成后确认cargo--versionrustc--version五、下载 responses-proxy 并构建首先克隆项目gitclone https://github.com/CallOrRet/responses-proxy.gitcdresponses-proxy然后构建cargobuild--release如果只是测试也可以直接使用cargorun--release不过实际使用时建议结合配置文件启动。六、配置 responses-proxy在项目目录下创建或修改config.yaml。配置内容需要根据 agnes-20-flash 官方文档提供的 OpenAI 兼容地址填写。整体思路如下server:host:127.0.0.1port:4000upstream:base_url:https://你的-agnes-api地址/v1api_key:你的-agnes-api-keymodel:agnes-20-flash不同版本的responses-proxy配置字段可能略有区别建议以项目 README 为准。核心参数一般包括本地监听地址本地监听端口上游 API 地址上游 API Key默认模型名称。假设 agnes-20-flash 的 OpenAI 兼容接口为https://api.agnes-ai.com/v1那么可以类似这样配置server:host:127.0.0.1port:4000openai:base_url:https://api.agnes-ai.com/v1api_key:sk-xxxxxxmodel:agnes-2.0-flash注意如果Codex不认第三方模型名称的话这里可以用别名进行替换models:gpt-5.4-mini:provider:base-url:https://apihub.agnes-ai.com/v1api_key:sk-xxxxxxtimeout:60model:agnes-2.0-flash这样codex中还保留gpt-5.4-mini一样可以调用到agnes-2.0-flash。再次提醒具体字段名称请以responses-proxy项目最新文档为准。这里只展示接入思路。七、启动代理服务配置完成后在responses-proxy项目目录执行nohupcargorun--release----config./config.yaml如果你想先在前台观察日志可以运行cargorun--release----config./config.yaml正常情况下服务会监听在http://127.0.0.1:4000对应的 Codex 请求地址就是http://127.0.0.1:4000/v1八、修改 Codex 配置接下来修改 Codex 的配置文件。通常位置可能是~/.codex/config.toml或者你自己的 Codex 配置路径。关键配置如下base_url http://127.0.0.1:4000/v1 wire_api responses重点是wire_api responses不要改。因为 Codex 需要继续以 Responses API 模式运行而responses-proxy会负责把它转换成上游支持的 Chat Completions 请求。完整示例可以类似model agnes-20-flash base_url http://127.0.0.1:4000/v1 wire_api responses api_key dummy这里的api_key是否需要真实填写取决于responses-proxy的实现方式。有些代理会在本地忽略 Codex 传入的 key直接使用配置文件里的上游 key有些则会读取请求头转发。所以如果不确定可以先填一个占位值api_key dummy真正的 agnes key 放到responses-proxy的config.yaml里。九、测试是否成功启动代理后可以直接运行 Codexcodex然后输入一些简单任务例如请帮我写一个 Python 函数实现快速排序。如果配置正确Codex 应该可以正常回复并且responses-proxy终端中能看到请求日志。可以看下我在code-server中链接的效果十、实际体验经过测试这套方案可以让原生 Codex 成功使用agnes-20-flash。整体链路如下Codex 原生 Responses 请求 ↓ 本地 responses-proxy ↓ OpenAI Chat Completions 格式请求 ↓ agnes-20-flash体验上有几个特点1. 能用而且接入成本不高相比自己写适配层responses-proxy省去了大量协议转换工作。只要 Rust 环境没问题基本上下载、配置、启动即可。2. 保持 Codex 原生配置不需要魔改 Codex也不需要改源码。Codex 侧仍然是wire_api responses这点非常重要因为 Codex 当前对 Responses API 的支持更完整。3. 免费模型速度一般agnes-20-flash是免费服务所以速度不能和商业 API 相比。有时会出现响应慢、重连或者中断。比较常见的情况是 Codex 显示Reconnecting /5这通常不是responses-proxy的问题而是上游免费模型服务响应不稳定或超时导致的。4. 适合轻量使用如果只是用来测试 Codex跑简单代码任务写小脚本做 prompt 调试学习 agent 工作流那么agnes-20-flash responses-proxy是一个很不错的免费组合。但如果要高强度使用尤其是长上下文、多文件修改、复杂代码重构建议换更稳定的 API 服务。十一、常见问题1. Codex 提示连接失败怎么办先检查本地代理是否启动curlhttp://127.0.0.1:4000/v1/models如果该接口不支持也可以直接看responses-proxy日志是否有请求进入。确认base_url http://127.0.0.1:4000/v1 wire_api responses不要写成base_url http://127.0.0.1:4000一般 Codex 需要包含/v1。2. 为什么已经配置了 API Key还是鉴权失败检查两个地方第一config.yaml中上游 key 是否正确api_key:sk-xxxx第二Codex 配置中是否需要填写 keyapi_key dummy如果代理要求从请求头读取 key则 Codex 里也要配置真实 key。如果代理自己从配置文件读取 key则 Codex 里可以填占位 key。3.Reconnecting /5是什么问题这通常表示 Codex 正在等待流式响应但连接出现了中断或超时。可能原因包括agnes 免费服务响应慢上游服务负载较高网络连接不稳定流式输出被中途切断请求内容过长模型当前不可用。解决方式简化任务减少上下文重新发起请求换一个更稳定的 API 服务或使用下面推荐的中转服务。十二、更稳定的选择推荐 api.aimanyi.top如果你希望获得更稳定、更快、更适合长期使用的 Codex 接入体验可以考虑https://api.aimanyi.top/相比免费模型服务稳定的中转服务通常有这些优势可用模型更多响应速度更快并发能力更好流式输出更稳定更适合 Codex 这类 agent 工具长文本和代码任务成功率更高具有专属codex令牌 可避免频繁Reconnecting /5。对于 Codex 来说模型服务的稳定性非常重要。因为 Codex 不只是普通聊天它经常需要读取文件理解上下文生成 patch多轮工具调用等待流式结果执行复杂代码修改任务。如果上游模型经常超时体验会非常割裂。因此我个人建议想免费体验使用agnes-20-flash responses-proxy想稳定日用使用api.aimanyi.top这类更可靠的中转服务想保持原生 Codex仍然可以结合responses-proxy做协议适配。也就是说你可以把 upstream 从 agnes 切换成 aimanyi 的 OpenAI 兼容地址Codex 侧配置保持不变base_url http://127.0.0.1:4000/v1 wire_api responses只需要修改responses-proxy的上游配置即可。十三、总结这次折腾的核心结论是原生 Codex 当前主要使用wire_api responses而很多第三方 OpenAI 兼容 API 只支持/v1/chat/completions。要接入这些服务需要一个 Responses API 到 Chat Completions API 的转换层。responses-proxy正好解决了这个问题。最终方案如下下载并构建responses-proxy在config.yaml中配置 agnes-20-flash 的 API 地址、Key 和模型名启动代理nohupcargorun--release----config./config.yaml修改 Codex 配置base_url http://127.0.0.1:4000/v1 wire_api responses运行 Codex即可使用 agnes-20-flash。这套方案的优点是简单、开源、无需修改 Codex缺点是免费模型速度和稳定性一般可能出现Reconnecting /5。如果只是体验和轻度使用agnes-20-flash 已经足够。如果需要更稳定的 Codex 编程体验可以考虑使用https://api.aimanyi.top/配合responses-proxy就能把更多 OpenAI 兼容模型接入原生 Codex。