Responses API 与 Chat Completions 有何区别：协议选择与兼容边界

Responses API 与 Chat Completions 不是同一个接口换了两个 URL，而是两种不同的请求与响应形态。选择哪一个，不取决于哪个名称更熟悉，而取决于当前客户端实际实现了什么、目标服务公开支持什么。本文讨论协议边界；Base URL 的字段语义和重复路径问题请单独看 OpenAI API Base URL 排错指南。

先由客户端决定协议

Codex 当前按 Responses 形态工作。其他支持 OpenAI 兼容配置的客户端，可能固定使用某一种协议，也可能在 Provider 设置中暴露选择项。先读该客户端当前版本的官方说明和本地提示，再决定是否需要切换；不要把另一个工具的示例请求直接复制过来。

兼容性要分别核对什么

1. 请求形态：输入、消息组织和可选字段由所选协议定义。
2. 响应处理：客户端是否能解析普通响应、流式输出和错误结构，需要以一次最小请求确认。
3. 扩展能力：工具调用、文件、结构化输出等功能是否可用，不能只凭“OpenAI 兼容”四个字推断。
4. 服务信息：模型、权限、限额和可用性以当前服务公开信息与实际返回为准。

因此，“能填 Base URL”只说明客户端可能允许配置入口，不等于它已经覆盖所有协议与扩展能力。关于这一层的概念，可继续阅读 OpenAI 兼容 API 是什么。

做一次小而可读的协议验证

1. 记录客户端版本和选中的协议。
2. 在本机受控配置中使用已授权的有效凭据，不把 Key 放进 URL、浏览器脚本、截图或公开终端记录。
3. 发送不含业务资料的短请求，只检查返回是否被客户端正确解析。
4. 遇到 401、403、429、502/503 时停止盲目重试，按 状态码排错指南 分流。

再回到具体接入

如果你使用 Codex，先看 Codex API 配置自检；如果需要判断配置来源和覆盖关系，继续看 Codex config.toml 配置指南。服务端当前模型、权限和可用性以 Shana 实时文档为准。