OpenAI兼容API：未经正式标准化的事实行业标准

没有任何标准组织为此写过规范。没有委员会为此投票。也不存在 RFC。但如果你在过去两年里用 LLM API 搭建过任何东西，你几乎肯定是在一种格式基础上构建的——而整个行业现在已将这种格式视为默认——却从未有人正式宣布它为标准。

这种格式就是提供商现在标注的"OpenAI 兼容 API"。值得追问的是：一件事是如何在不经过通常制造标准的那种流程的情况下成为标准的？因为这种事以前也发生过，而且它告诉你一些关于这件事走向的有用信息。

事实标准有一种固定模式，这次完全符合

你日常依赖的大多数技术并非从约定好的标准开始。USB-C 成为通用标准不是因为某个委员会在一夜之间强制它存在——而是因为足够多的制造商汇聚到它上面，以至于使用任何其他标准的成本变得高于采用它的成本。HTTP 成为 Web 的默认传输协议，不是因为它在形式上优于所有替代方案，而是因为足够多的互联网基础设施是基于它构建的，以至于偏离它意味着重建别人已经免费拥有的基础设施。

这个模式是一致的：事实标准的出现不是因为它是可能最好的设计，而是因为足够多的生态系统假设了它，而不使用它的切换成本攀升到了偏离变得不合理的程度。

"OpenAI 兼容"正完全沿着这条路径发展。OpenAI 没有发布规范并要求提供商针对它认证。实际发生的是：OpenAI 的 API 足够早、足够受欢迎，以至于大量的工具链——SDK、编排框架、公司内部工具、成千上万的教程和代码示例——都是基于它特定的请求和响应结构构建的。一旦这些工具链规模化存在，任何新的模型提供商都面临一个选择：发明自己的格式并要求每个开发者仅为他们构建一个转换层，或者采用已经能与一切配合工作的形状。

现在几乎所有主要提供商都在选择第二个方案，原因与制造商选择 USB-C 相同：不是因为它被强制，而是因为不选择它现在是更昂贵的选项。

为什么"没有人正式命名它"才是有趣的部分

这里有一件事值得思考：这个特定案例的特殊之处在于：没有 OpenAI 兼容性联盟。没有背后有治理机构认证标志。当一个提供商说"OpenAI 兼容"时，这是一种自我描述，而不是针对已发布规范的合规性声明——这意味着这个术语覆盖了一个范围，而不是单一的保证。

一些提供商是真正、彻底的兼容——相同的端点结构、相同的流式行为、相同的错误形状，可以无缝替换。其他的在核心 chat/completions 结构上兼容，但边缘情况（函数调用细微差别、某些参数名称、流式边缘情况）有所不同——这些差异只有在实际集成时才会发现。因为没有正式规范，"兼容"是一个你通过测试来验证的说法，而不是你可以直接认为理所当然的保证。

这实际上是事实标准成熟的正常阶段。HTTP 在 RFC 将其正式化之前也经历了同样混乱的时期。USB-C 合规性在廉价电缆和认证电缆之间差异很大，以至于仅凭"USB-C"并不能告诉你一切都能相同工作。有机产生的标准往往在后来被正式化——一旦足够多的生态系统依赖它们，歧义成为一个真正值得用真实规范来解决的问题——围绕 LLM API，现在已经有迹象表明正式化的对话正在发生，因为生态系统已经度过了最早期的阶段。

现在这在实践中的含义

鉴于"OpenAI 兼容"是一个真实的、有用的趋同，但还不是正式验证的保证，以下几点随之而来：

将兼容性声明视为一个强烈的先验，而不是确定性。对于简单的 chat completion 用例，兼容性声明在绝大多数情况下都站得住脚。对于使用更高级功能的任何场景——函数调用、结构化输出、特定的流式行为——在假设完全对等之前，值得针对你的实际用例进行真实测试。

兼容性的价值随着汇聚在它上面的提供商数量而复利。一个提供商是 OpenAI 兼容的，为你节省了与那个提供商整合的工作。整个生态系统汇聚在上面，意味着你的应用层代码默认变成提供商无关的——你在选择模型时不再选择 API 形状，而只是选择模型本身。

这种趋同是多提供商基础设施成为可能的首要条件。一旦足够多的提供商共享一个请求形状，一个位于多个提供商之上并通过相同形状暴露它们所有服务的层，就不再是一个艰难的工程问题，而成为相当自然的基础设施。这本质上是统一 AI API 网关背后的机制——这类服务通过一个一致的接口路由 DeepSeek、Qwen、Kimi、GLM 和其他 OpenAI 兼容提供商。RouteAI 就是一个建立在这种趋同之上的例子——作为一个类别值得了解，无论它是否适合你正在构建的具体需求——因为如果底层提供商还没有汇聚到共享形状，它就不会作为一个简单的、低开销的层存在。

真正有趣的不是任何一个提供商的兼容性声明。而是整个真正的竞争市场——每个提供商都有真正的财务动机让开发者锁定在他们特定的格式上——反而汇聚到共享一个格式，因为不这样做会让所有人的采用都变得更困难，包括那个试图建立差异化的提供商。

这比正式标准更强有力地从某种角度来说。正式标准被采用是因为它们被强制。这一次被采用是因为，重复地、独立地，提供商得出结论：让自己的产品更容易被切换进入是符合他们自身利益的——尽管这技术上也让切换离开变得更容易。对于一个竞争性市场来说，自愿汇聚到这一点不是一件小事。

下一次当"OpenAI 兼容"作为提供商文档中的一个要点出现时，值得少把它当作一个功能来理解，多把它当作一个信号：这个提供商选择在模型实际做什么上竞争，而不是在离开它有多难上竞争。

TL;DR："OpenAI 兼容 API"不是有治理机构的官方标准——而是一个事实标准，遵循与 USB-C 或早期 HTTP 相同的模式：足够多的生态系统汇聚到一种形状，使得偏离它比采用它更昂贵。因为没有正式规范，"兼容"覆盖了一个从完全无缝替换到部分匹配的光谱，所以值得针对你的具体用例进行验证，而不是假设完全对等。这种趋同也使得多提供商网关（如 RouteAI 等）作为简单基础设施而非艰难工程问题成为可能。

这是我在这篇文章中引用的工具： www.fastrouteai.com