最近在折腾原生 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/responses，Codex 就无法直接调用。

这就导致一个问题：

  • 第三方 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-proxy

responses-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 能力、测试工作流或者做轻度代码辅助，已经非常不错了。

四、准备工作

需要准备：

  1. Rust / Cargo 环境；
  2. agnes-20-flash 的 API Key；
  3. 原生 Codex；
  4. responses-proxy 项目代码；
  5. 一个可编辑的 Codex 配置文件。

如果你还没有 Rust 环境，可以参考官方安装方式：

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

安装完成后确认：

cargo --version
rustc --version

五、下载 responses-proxy 并构建

首先克隆项目：

git clone https://github.com/CallOrRet/responses-proxy.git
cd responses-proxy

然后构建：

cargo build --release

如果只是测试，也可以直接使用：

cargo run --release

不过实际使用时，建议结合配置文件启动。

六、配置 responses-proxy

在项目目录下创建或修改 config.yaml。

配置内容需要根据 agnes-20-flash 官方文档提供的 OpenAI 兼容地址填写。整体思路如下：

server:
  host: "127.0.0.1"
  port: 4000

upstream:
  base_url: "https://你的-agnes-api地址/v1"
  api_key: "你的-agnes-api-key"
  model: "agnes-20-flash"

不同版本的 responses-proxy 配置字段可能略有区别，建议以项目 README 为准。核心参数一般包括：

  • 本地监听地址；
  • 本地监听端口；
  • 上游 API 地址；
  • 上游 API Key；
  • 默认模型名称。

假设 agnes-20-flash 的 OpenAI 兼容接口为：

https://api.agnes-ai.com/v1

那么可以类似这样配置：

server:
  host: "127.0.0.1"
  port: 4000

openai:
  base_url: "https://api.agnes-ai.com/v1"
  api_key: "sk-xxxxxx"
  model: "agnes-2.0-flash"

注意：如果Codex不认第三方模型名称的话，这里可以用别名进行替换：

models:
  gpt-5.4-mini:
    provider:
      base-url: https://apihub.agnes-ai.com/v1
	  api_key: "sk-xxxxxx"
      timeout: 60
    model: agnes-2.0-flash

这样codex中还保留gpt-5.4-mini一样可以调用到agnes-2.0-flash。

再次提醒：具体字段名称请以 responses-proxy 项目最新文档为准。这里只展示接入思路。

七、启动代理服务

配置完成后，在 responses-proxy 项目目录执行：

nohup cargo run --release -- --config ./config.yaml &

如果你想先在前台观察日志，可以运行：

cargo run --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 里。

九、测试是否成功

启动代理后，可以直接运行 Codex：

codex

然后输入一些简单任务，例如：

请帮我写一个 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 提示连接失败怎么办？

先检查本地代理是否启动：

curl http://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 配置中是否需要填写 key：

api_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 正好解决了这个问题。

最终方案如下：

  1. 下载并构建 responses-proxy；
  2. 在 config.yaml 中配置 agnes-20-flash 的 API 地址、Key 和模型名；
  3. 启动代理：
nohup cargo run --release -- --config ./config.yaml &
  1. 修改 Codex 配置：
base_url = "http://127.0.0.1:4000/v1"
wire_api = "responses"
  1. 运行 Codex，即可使用 agnes-20-flash。

这套方案的优点是简单、开源、无需修改 Codex，缺点是免费模型速度和稳定性一般，可能出现 Reconnecting /5。

如果只是体验和轻度使用，agnes-20-flash 已经足够。
如果需要更稳定的 Codex 编程体验，可以考虑使用：

https://api.aimanyi.top/

配合 responses-proxy，就能把更多 OpenAI 兼容模型接入原生 Codex。

# python # 人工智能 # 自然语言处理 # 神经网络 # AI作画 # gpt-3
Logo
AI硬件创业社区

智能硬件社区聚焦AI智能硬件技术生态，汇聚嵌入式AI、物联网硬件开发者，打造交流分享平台，同步全国赛事资讯、开展 OPC 核心人才招募，助力技术落地与开发者成长。

更多推荐

cover

零知派ESP32--基于HW-504从零搭建双人对战贪吃蛇教程

avatar AI硬件创业社区

HAL_IWDG

IWDG（Independent Watchdog，独立看门狗）：STM32 内置的独立硬件容错外设，用于解决程序死机、跑飞、卡死问题。核心机制：硬件自动倒计时，若程序长时间不喂狗（刷新倒计时），系统判定程序异常，自动复位单片机，让设备恢复正常运行。IWDG独立看门狗是基于内部LSI时钟的硬件容错外设，独立于系统运行，通过递减倒计时机制监控程序运行，超时未喂狗则自动复位单片机，解决程序死机、跑飞问

avatar AI硬件创业社区

武理信院嵌入式课设-脉冲宽度测量

only代码无仿真。硬件用的正点原子stm32f103zet6。

avatar AI硬件创业社区