OpenAI 兼容协议是什么：原理、边界与用法
为什么改一行 base_url 就能切换 GPT、Claude、Gemini、DeepSeek？讲清 OpenAI 兼容层的工作原理、支持的功能范围，以及什么时候必须用原生端点。
「兼容 OpenAI 协议」是大模型行业的事实标准——几乎每个网关、每个本地部署框架、每个客户端都声明支持它。但「兼容」到底兼容到什么程度，什么时候会失真，值得花五分钟讲清楚。
OpenAI 协议的核心是什么
狭义的 OpenAI 协议就是这几个端点：
POST /v1/chat/completions— 对话补全，95% 的使用场景POST /v1/embeddings— 文本向量化POST /v1/images/generations— 图像生成
对话请求的结构：一组带角色的消息（system / user / assistant），加采样参数（temperature、max_tokens），返回 assistant 的回复和 token 用量。协议本身非常薄，这正是它能成为标准的原因——实现成本低，替换成本更低。
网关在中间做了什么
当你的请求发到 https://api.zaimod.com/v1/chat/completions，指定模型是 claude-sonnet-5 时，网关做了三件事：
- 协议翻译：把 OpenAI 格式的 messages 翻译成 Anthropic 的
/v1/messages格式（比如 system 提示词要从消息列表里拆出来单独传） - 渠道路由：按模型和分组找到可用渠道，失败自动切换
- 计费计量：统计本次请求的 token 用量，按「模型单价 × 分组倍率」记账
响应再翻译回 OpenAI 格式返回给你。整个过程对代码透明，唯一的配置就是 base_url 和 key。
兼容层的边界：什么时候必须用原生端点
翻译是有损的。以下场景建议直连原生协议：
- Claude 的 extended thinking：思考过程的块结构在 OpenAI 格式里没有对应物
- Gemini 的原生多模态特性：视频理解、grounding 等参数翻译后可能丢失
- 厂商独有参数：比如 Anthropic 的 prompt caching 控制项
zaimod 同时暴露三种协议，按需选择：
| 协议 | 端点 | 适用 |
|---|---|---|
| OpenAI | https://api.zaimod.com/v1 | 通用、工具链集成 |
| Anthropic | https://api.zaimod.com/v1/messages | Claude 全特性 |
| Gemini | https://api.zaimod.com/v1beta/models/{model}:generateContent | Gemini 原生特性 |
流式输出与工具调用
两件事要特别注意：
流式（SSE）：OpenAI 格式的 delta 增量在翻译时保持逐块转发，所以打字机效果不受影响。但某些网关在异常时会中断流，客户端务必处理不完整 JSON。
工具调用（function calling / tools）：三家厂商的工具调用语义有差异（比如并行调用、strict 模式），兼容层做了最大程度的映射，但复杂的多轮工具链建议先小流量验证。
选型建议
- 已有 OpenAI 代码库、想快速加模型 → 兼容层，改 base_url 就完事
- 深度使用单一厂商特性 → 原生端点
- 需要跨厂商 A/B 测试 → 兼容层 + 模型名切换，测试完再固化
理解了「薄协议 + 有损翻译」这两点，你就能准确判断手里的工具链在什么场景下该走哪条通道。
延伸阅读
#openai 兼容#openai api 协议#chat completions#base_url
免费创建 API Key