Codex 支持通过配置文件定义模型提供商。接入第三方兼容接口时，重点是 base_url、认证环境变量、模型 ID 和 wire_api。当前官方配置参考将 wire_api 定义为 responses，因此兼容服务必须实际支持 Responses API；仅支持 Chat Completions 并不足以覆盖 Codex 的代理任务。
快速结论
Codex 自定义 Provider 需要真实可用的 Responses API。把 wire_api 设为 responses、Key 放进 env_key 指向的环境变量，并用创建文件和显示 git diff 的最小任务验收；普通聊天成功不能代替工具事件与会话链路验证。
开始前检查
先确认目标模型和接口支持 Responses API。不要因为普通聊天接口可用，就推断文件操作、工具调用和连续代理任务也可用。
准备独立环境变量：
export AIFAST_API_KEY="你的_API_Key"配置步骤
在用户级 ~/.codex/config.toml 中增加自定义提供商。项目级 .codex/config.toml 不能覆盖 model_provider、model_providers 和 Provider 认证。示例结构：
model = "YOUR_MODEL_ID"
model_provider = "aifast"
[model_providers.aifast]
name = "AI快站"
base_url = "https://www.aifast.hk/v1"
env_key = "AIFAST_API_KEY"
wire_api = "responses"注意：
YOUR_MODEL_ID必须替换为控制台实际开放的模型 ID。- 如果服务只支持 Chat Completions，不要假设改一个字段就能完整支持 Codex。
- API Key 放在环境变量中，不写入
config.toml。 - 自定义 Provider ID 不要使用保留的
openai、ollama或lmstudio。 - 上述 Base URL 对应的常规 Responses 地址是
https://www.aifast.hk/v1/responses，不是/v1/v1/responses。
最小验证任务
先在临时目录以严格配置模式启动：
codex --strict-config确认启动时没有未知字段错误后，在 Codex 中运行：
创建一个 hello.txt，内容为 connection ok，然后显示 git diff。验证四件事：
- Codex 能识别模型。
- 请求落到预期的
/v1/responses，没有变成/v1/v1/responses。 - 工具调用能正常返回。
- 文件修改范围与任务一致。
常见问题
Unsupported parameter 或响应字段缺失
这通常意味着兼容层没有完整实现 Responses API，而不是提示词问题。保存错误正文并核对接口协议。
普通问答成功，执行工具失败
Codex 代理任务依赖工具调用事件和连续响应。文本生成成功只能证明基础请求可用，不能证明完整代理链路可用。
找不到环境变量
从启动 Codex 的同一个终端执行：
test -n "$AIFAST_API_KEY" && echo "Key 已加载"不要输出完整 Key。
下一步
完成基础配置后，继续按Codex 中转 API 验收与排错清单核对实际 Provider、Responses 路径、流式事件、工具调用、上下文压缩和会话恢复。不要用一次普通文本回答代替代码 Agent 验收。
在真实仓库使用前，先测试只读分析、单文件修改、多文件修改和测试命令四类任务，并保留一个可以快速切回的原提供商配置。
- 核对当前模型与价格： 查看 AI快站模型价格，确认目标模型当前支持 Responses API。
- 创建独立测试 Key： 注册 AI快站，先限制额度并从只读任务开始。