Responses API 和 Chat Completions 有什么区别

这篇解决一个最容易让国内模型配置“看起来正确、实际报 404”的问题：服务商写着“OpenAI 兼容”，不代表它一定兼容 Codex。

官方依据：OpenAI Codex Manual 的 Custom model providers 与 wire_api 配置说明。当前官方配置只支持 responses。

教程目标

完成后你能判断一个模型服务是否可以直接配置为 Codex 自定义 provider，还是需要协议转换层。

开始前准备

准备服务商当前官方文档中的三项信息：

1. Base URL。
2. 实际请求路径，例如 /v1/responses 或 /v1/chat/completions。
3. 官方请求示例和模型名。

不要只看“兼容 OpenAI”这句宣传文案。

第 1 步：先分清两个接口

检查项	Responses API	Chat Completions
常见路径	/v1/responses	/v1/chat/completions
常见输入字段	input	messages
Codex 自定义 provider 当前支持	支持	不可直接配置

两者都可能被称为“OpenAI 兼容接口”，但请求和响应结构不同。

第 2 步：检查服务商文档

把服务商文档地址发给 Codex，先让它只读判断：

请只读检查这个模型服务商的官方 API 文档，不要修改任何配置。

请分别确认：
1. 是否明确提供 /responses 或等价的 Responses API。
2. 是否只提供 /chat/completions。
3. 请求字段使用 input 还是 messages。
4. 是否有官方依据证明能作为 Codex 自定义 provider 使用。
5. 如果证据不足，明确写“不能确认”，不要猜。

最后给出结论：
- 可以直接配置 Codex provider；
- 需要协议转换层；
- 暂时不能确认。

预期结果是得到协议证据和明确结论，而不是只得到一段 config.toml。

第 3 步：决定配置路线

明确支持 Responses API

可以继续准备 model、model_provider、base_url 和 env_key。仍要先生成草稿、备份旧配置，再做最小请求验证。

只支持 Chat Completions

不要添加 wire_api = "chat"。当前 Codex 官方配置没有把它列为支持值。

可选路线是：

• 等服务商提供 Responses API。
• 使用可信、可审查的协议转换层。
• 使用服务商或工具提供的专用集成，但先做供应链和密钥风险检查。

文档说不清楚

暂停写配置，向服务商确认。不要用“试试看”替代兼容性结论，因为失败可能表现为 404、字段错误、流式响应错误或工具调用异常。

常见误区

• base_url 能访问，不等于协议兼容。
• 能列出模型，不等于能完成 Codex 工具调用。
• 普通对话能回复，不等于读文件、执行工具和流式输出都正常。
• 第三方转换工具能跑通，不等于模型服务商原生支持 Codex。

验收结果

你做到这里，如果看到下面 3 个结果，就说明本篇完成：

1. 你能指出服务商提供的是 Responses 还是 Chat Completions。
2. 你没有给只支持 Chat Completions 的地址直接写入 Codex 原生 provider。
3. 你知道使用转换层前还要检查来源、权限、密钥和回滚方式。

下一篇看：使用第三方 Codex 工具前的安全检查。