什么是「OpenAI 兼容」——为什么这是 AI 领域最重要的标准

当你听到 JJAPI 这类 API 网关说自己「OpenAI 兼容」，听起来像是营销话术。其实不是——这是一个 AI API 能拥有的最有用属性，值得花时间理解。

API 的本质就是 wire 格式

OpenAI REST 接口已经事实上成为标准。所有主流托管服务——Together、Anyscale、Groq、Mistral、Fireworks，包括 JJAPI——都实现了同一个 POST /v1/chat/completions，请求 JSON 都是这个形状：

{
  "model": "gpt-4o",
  "messages": [
    {"role": "system", "content": "..."},
    {"role": "user", "content": "..."}
  ],
  "temperature": 0.7,
  "stream": false
}

…返回也是同一个形状：

{
  "id": "chatcmpl-...",
  "choices": [
    {
      "message": {"role": "assistant", "content": "..."},
      "finish_reason": "stop"
    }
  ],
  "usage": {"prompt_tokens": 12, "completion_tokens": 8}
}

因为这种收敛，OpenAI SDK 成了通用客户端。把 base_url 指向任何兼容的厂商，你的代码继续跑。

这意味着什么

1. 零迁移成本。 从 OpenAI 切到便宜的厂商，改一个变量。
2. 多厂商组合。 用 Claude 做难推理、DeepSeek 做廉价劳动力——同一个 SDK 调用，模型字符串不同。
3. 工具继承。 LangChain、LlamaIndex、Vercel AI SDK、Continue、Cursor、Cherry Studio——所有会和 OpenAI 对话的工具，都会和 JJAPI 对话。
4. 没有锁定后悔。 几年后 GPT-7 成为主流，你的代码已经准备好了。

「OpenAI 兼容」覆盖不到什么

OpenAI 生态里有几个新功能在不同厂商间还是不一致的：

• Assistants API（/v1/assistants、threads 等）——状态重、收敛慢。
• Realtime API（基于 WebSocket）——演化快；JJAPI 支持兼容子集，但有边界。
• Files API——各厂商上传方式不同；上游支持的话我们镜像 OpenAI 语义。

但 95% 的生产代码（聊天、embedding、图像生成、转录），OpenAI 兼容已经够用。

JJAPI 怎么实现兼容

我们透明地把非 OpenAI payload（Claude 的 tool 格式、Gemini 的 parts 列表、DeepSeek 的 reasoning 块）翻译进出 OpenAI 形状。流式 SSE 不管上游 wire 协议是什么，统一规范化为 OpenAI 事件格式。

结论：你写 OpenAI 风格代码，JJAPI 处理所有阻抗失配。