一句话定义：OpenAI 兼容 API（OpenAI-compatible API）指第三方模型服务照着 OpenAI 官方接口的形状对外提供服务——请求路径、请求体字段、流式返回格式都尽量对齐，于是任何为 OpenAI 写的代码，通常只要改 base_url 和 API Key 就能跑起来。
打个比方：家里的墙面插座标准统一，换电视、换电脑、换台灯都不用重新布线。OpenAI 的 /v1/chat/completions 就是这个插座孔。请求体里核心是 messages 数组，每条消息有 role（system、user、assistant、tool）和 content，再配上 model、temperature、stream 等参数；开启流式后，服务端返回一串以 data: 开头的 SSE 片段，每片带一点 delta。形状定了，插头就都能插上。
为什么全行业都长成这个样子？因为客户端生态只写一遍适配层就够了。IDE 插件、聊天客户端、编排框架、评测脚本，早就围绕这套结构写好了代码。新模型厂商想让人“五分钟接入”，最省事的做法不是发明一套更优雅的协议，而是把插座做成一样的。对用户是零迁移成本，对厂商是直接蹭到整个生态。
但这套模具也在反向塑造行业：
| 维度 | 兼容带来的好处 | 兼容锁住的东西 |
|---|---|---|
| 接入 | 只改地址和密钥 | 协议演进的节奏由别人定 |
| 工具链 | 现成客户端直接可用 | 新的交互范式很难被表达 |
| 语义 | 对话、工具调用有共识 | 各家“兼容度”参差，边缘字段各写各的 |
真正的坑在细节里。system 角色在部分模型上不存在，要合并进首条 user 消息；tool_calls 对 JSON Schema 的支持程度不一；流式返回里 usage 可能不返回，或者统计口径不同；推理模型常加 reasoning_content 这类非标准字段；图片、音频等多模态的 content 结构各家也有出入。所谓“兼容”，往往是 80% 兼容，剩下 20% 得在你的真实业务里试出来。
和相邻概念的区别：OpenAI 官方 API 是原版；OpenAI 兼容 API 是别人照着做的实现；代理或网关只是把请求转发给后端，本身不产出推理；权重格式兼容解决的是模型文件怎么被加载，和接口协议是两回事。
对从业者的实际意义：把模型服务当成“可替换的依赖”来设计。地址、模型名、密钥全部配置化，业务逻辑别依赖非标准字段，上线前用自己的一组用例（流式、工具调用、超长输入、错误码）跑一遍兼容性测试。对普通职场人则是一句提醒：换模型供应商不一定意味着重做产品，但也不等于完全无感。具体支持范围，以各家官方页面为准。