Codex 支持通过配置文件定义模型提供商。接入第三方兼容接口时，重点是 base_url、认证环境变量、模型 ID 和 wire_api。配置字段可能随 Codex 版本更新，上线前应同时核对当前官方配置参考。
开始前检查
先确认接口支持 Codex 当前使用的 API 类型。新版本通常优先使用 Responses API；只实现 Chat Completions 的兼容服务不一定能覆盖 Codex 的全部代理能力。
准备独立环境变量：
export AIFAST_API_KEY="你的_API_Key"配置步骤
在 Codex 配置文件中增加自定义提供商。示例结构：
model = "YOUR_MODEL_ID"
model_provider = "aifast"
[model_providers.aifast]
name = "AI快站"
base_url = "https://www.aifast.club/v1"
env_key = "AIFAST_API_KEY"
wire_api = "responses"注意：
YOUR_MODEL_ID必须替换为控制台实际开放的模型 ID。- 如果服务只支持 Chat Completions，不要假设改一个字段就能完整支持 Codex。
- API Key 放在环境变量中，不写入
config.toml。
最小验证任务
先在临时目录运行：
创建一个 hello.txt，内容为 connection ok，然后显示 git diff。验证四件事：
- Codex 能识别模型。
- 请求没有落到
/v1/v1。 - 工具调用能正常返回。
- 文件修改范围与任务一致。
常见问题
Unsupported parameter 或响应字段缺失
这通常意味着兼容层没有完整实现 Responses API，而不是提示词问题。保存错误正文并核对接口协议。
普通问答成功，执行工具失败
Codex 代理任务依赖工具调用事件和连续响应。文本生成成功只能证明基础请求可用，不能证明完整代理链路可用。
找不到环境变量
从启动 Codex 的同一个终端执行：
test -n "$AIFAST_API_KEY" && echo "Key 已加载"不要输出完整 Key。
下一步
在真实仓库使用前，先测试只读分析、单文件修改、多文件修改和测试命令四类任务，并保留一个可以快速切回的原提供商配置。