OpenAI 协议兼容：chat/completions 和 responses 的区别

两个端点

chat/completions：事实标准

{
  "model": "gpt-4o",
  "messages": [
    { "role": "system", "content": "你是助手" },
    { "role": "user", "content": "你好" }
  ],
  "stream": true
}

为什么它成为标准：出现早、结构简单、生态广。你写的任何 OpenAI SDK 代码基本都能跑。

responses：较新的形态

{
  "model": "gpt-4o",
  "input": "你好"
}

设计上更贴近「一次交互」而不是「对话历史」的模型，对工具调用、多步任务的支持更结构化。Codex CLI 等较新的官方工具依赖它。

兼容性问题的实际影响

你的工具需要 /v1/responses
        ↓
站点只实现了 /v1/chat/completions
        ↓
404 Not Found

这就是很多人「配置全对但就是不通」的原因。

怎么判断一个站支持哪些

# 测 chat/completions
curl -s -o /dev/null -w "chat: %{http_code}\n" -X POST https://站点/v1/chat/completions \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o","messages":[{"role":"user","content":"hi"}],"max_tokens":5}'

# 测 responses
curl -s -o /dev/null -w "responses: %{http_code}\n" -X POST https://站点/v1/responses \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o","input":"hi"}'

返回 200 或 400（参数问题）都表示端点存在；404 / 405 表示没实现。

除了协议，还有哪些兼容性差异

即使端点存在，实现深度也可能不同：

这就是为什么「能用」和「好用」之间还有距离。

一个实用建议

先用你真实的工具测，别用 curl 测。

curl 只能验证端点存在，验证不了你实际工具依赖的那些细节。用一个最小但真实的工作流跑一遍，能一次性暴露大部分兼容性问题。

找不到支持 responses 的站怎么办

1. 换工具 —— 用只依赖 chat/completions 的同类工具
2. 自建协议转换层 —— 用 LiteLLM 这类网关做转换
3. 走官方 —— 官方端点当然都支持

第 2 项对技术要求高，但一次投入能长期解决兼容问题。

相关阅读

• Codex CLI 配置第三方 API 的注意事项
• Claude Code 接入中转站完整配置教程（含排错）
• /v1/models 接口是什么，为什么它能验证一家中转站