通过兼容OpenAI的端点调用Claude、GPT和Gemini

Anthropic 和 Google 现在都提供了与 OpenAI 兼容的接口，因此只需修改几行代码，就能将现有的 OpenAI SDK 代码用于 Claude 或 Gemini，而无需重新编写集成代码。难点不在于首次发送请求，而在于要了解每个兼容层会隐秘地忽略哪些功能，以及同时维护多个此类接口需要付出什么代价。下文将详细介绍每个服务提供商的具体客户端配置、对生产环境智能体至关重要的已知缺陷，以及将三者整合到同一个基础 URL 和密钥下的权衡因素。

“与 OpenAI 兼容”实际上意味着什么

任何能够接受 OpenAI SDK 所发送请求格式的接口都属于兼容 OpenAI 的 API：即包含 messages 数组、相同的流式传输标志以及相同的工具调用结构。由于该格式早在多年前就已成为事实标准，如今大多数模型供应商都会提供某种版本的接口，这样团队无需修改客户端代码即可尝试不同的模型。

不过，“兼容”并不意味着完全一致。虽然网络上传输的请求结构相同，但各个参数的含义可能有所不同，而且那些不受支持的选项通常会被接受并忽略而非直接拒绝。正是这种处理方式使得这类接口存在风险：不会出现明显的故障，缺失的功能只会表现为质量下降的输出，而不会报错。

Anthropic 的兼容层

Anthropic的OpenAI SDK兼容性文档将此层视为测试和比较模型功能的一种方式，而非推荐的正式使用方案。文档中还列出了具体的限制：

• 函数调用时的strict标志会被忽略，因此工具调用相关的JSON数据无法保证符合您指定的结构。
• 尽管原生Anthropic API支持提示词缓存功能，但通过该兼容层却无法实现。
• 由于Claude仅接受一个初始系统提示词，所有系统消息和开发者消息都会在对话开始时合并为一条系统消息。

这些因素都不会妨碍快速进行实验。但它们都可能让那些依赖工具参数符合特定架构、依靠缓存来控制延迟与成本，或需要在对话过程中注入系统指令的正式应用出问题。

Google的兼容层

Google方面的功能开箱即用更为完善。根据其关于OpenAI兼容性的Gemini文档，标准对话补全、流式处理以及函数调用功能均可正常使用。不过Google也明确指出，并非所有针对特定提供商的功能都能在两种API之间互相转换，因此建议一旦需要Gemini特有的功能，就立即切换到原生Gemini API。

运行所有这些功能的成本

单独来看，每一层都是评估某个模型的可行临时方案。但若将这三家服务提供商都集成到同一个应用中，开销就会成倍增加：三个基础网址、三组API密钥、三个计费控制面板、三套速率限制，还有三组会被自动忽略的参数列表，所有这些都是为了让代码在每家服务提供商那里都能保持一致。

将OpenAI SDK指向Claude

要将OpenAI SDK的集成切换为Claude，只需进行三项修改：更改基础网址，用Anthropic的API密钥替代OpenAI的密钥，以及指定Claude模型的名称。这是在不使用Anthropic官方SDK之前快速测试Claude的最佳方式。导入语句则保持不变：

import os
from openai import OpenAI

该客户端是使用Anthropic的端点以及从环境变量中读取的密钥构建的，其调用本身属于标准的聊天完成功能。请注意，所显示的代码片段中缺少客户端结束括号与response =之间的换行符，在复制时需将它们拆分为两条独立的语句：

client = OpenAI(
    api_key=os.environ.get("ANTHROPIC_API_KEY"),
    base_url="https://api.anthropic.com/v1/",
)response = client.chat.completions.create(
    model="claude-opus-5",
    messages=[{"role": "user", "content": "Explain how AI works"}],
)

对于简单的聊天完成功能，这就是全部的迁移内容。凡是依赖于上述缺点的功能都需要更加谨慎处理。如果您的应用依赖严格的工具架构、提示词缓存或完整的扩展思考输出，应使用Anthropic的原生API来获取完整功能，而非其类似OpenAI的简化版本。像所示那样的模型名称会频繁变化，因此请在服务提供商的模型列表中确认当前的标识符。

将OpenAI SDK指向Gemini

同一交换功能的 Gemini 版本针对的是 Google 的端点。你需要一个 Gemini API 密钥，可在 Google AI Studio 中创建。同样，只需使用标准的 OpenAI 导入方式即可：

from openai import OpenAI

客户端使用 Gemini 密钥以及 Google 的 OpenAI 兼容基础 URL，请求体保持不变。此处同样存在缺失的换行符问题，而且像 Claude 示例中那样，最好用环境变量替换硬编码的密钥占位符：

client = OpenAI(
    api_key="YOUR_GEMINI_API_KEY",
    base_url="https://generativelanguage.googleapis.com/v1beta/openai/",
)response = client.chat.completions.create(
    model="gemini-3.7-flash",
    messages=[{"role": "user", "content": "Explain how AI works"}],
)

流式处理和函数调用都可以通过该端点实现。Gemini 的推理控制功能是通过 OpenAI 的 reasoning_effort 参数来实现的，但这种映射并不总是完全对应，且取决于你调用的 Gemini 模型。如果你希望在新功能发布后立即使用仅支持 Gemini 的功能，那么使用原生 SDK 仍然是更快捷的方式。

那 GPT 自身呢？

OpenAI 自身的 API 不需要兼容层，因为它定义了所有其他服务都必须遵循的格式。但这并不能解决多供应商的问题，只是将问题转移而已。按照 OpenAI 的格式编写的代码日后添加 Anthropic 和 Google 的服务层会更为方便，但你仍然需要为每个供应商分别管理不同的密钥、速率限制以及特殊要求。

通过单一网关路由所有模型

各个供应商自身的服务层都无法解决多供应商的问题，因为它们都只负责路由自己的模型。LLM 网关则填补了这一空白：它是一个兼容 OpenAI 格式的单一端点，会根据你指定的 model 将请求转发到 Claude、GPT 或 Gemini，这样你的代码就无需再追踪哪些特殊要求属于哪个供应商了。

这次迁移过程与前两次完全相同。下面的示例使用了某个商业网关的端点；任何兼容 OpenAI 的网关都遵循相同的模式。导入过程没有变化：

from openai import OpenAI

现在客户端通过网关密钥来指定网关的基地址，而模型名称则用于选择上游服务提供商。与之前一样，在 response = 之前需添加换行符：

client = OpenAI(
    api_key="YOUR_SAYGM_API_KEY",
    base_url="https://api.saygm.com/v1",
)response = client.chat.completions.create(
    model="claude-opus-5",
    messages=[{"role": "user", "content": "Explain how AI works"}],
)

要更换服务提供商，只需将 model 更改为 gpt-5.6-luna 或 gemini-3.7-flash，其余部分保持不变。这些模型名称仅为撰写本文时的示例，请查看网关的模型目录以获取当前有效的标识符。对于已支持 OpenAI 兼容设置的开发工具，如 Cursor、Cline、Claude Code 以及 Vercel AI SDK，同样的配置即可使用：一个基础 URL 和一个密钥就能访问网关提供的所有模型，而无需针对特定提供商进行设置。不同工具对基础 URL 和密钥的字段名称有所不同，具体设置请参考网关的集成文档。

网关不会更改的内容

通过网关传输数据并不会突破底层服务提供商的兼容性限制。即便以 OpenAI 格式通过网关发送 Claude 请求，也无法获得提示词缓存功能或强制性的严格格式要求；上述所有限制依然适用。

由于每个提示词和响应都必须经过网关，因此它也成了你的信任边界的一部分。某些供应商会宣传保密措施，比如在经过硬件认证的受信任执行环境中处理请求，从而防止网关运营商读取数据流量。不过这些保障仅针对网关本身；模型提供商仍会按照其自身的规则接收并处理你的请求。应分别评估这两层服务，并根据供应商的技术文档而非营销宣传来验证其相关声明。

常见的迁移问题

Claude或Gemini特有的功能能在兼容OpenAI的层中保留吗？

只有那些能被该层映射的功能才能保留。无论你是直接调用服务提供商的兼容接口，还是通过网关转发请求，所有无法被转换的功能都会丢失。在Claude上，这包括提示词缓存、PDF处理以及完整的扩展思考输出功能；在Gemini上，则包括模型特有的推理参数。如果你依赖这些功能，就必须为对应的代码路径调用原生API。

切换需要付出什么成本？

使用网关时通常按令牌数量计费，方式与直接调用服务提供商类似，但不同模型和供应商的费率各不相同，且部分网关还会加收额外费用。在将生产环境流量迁移之前，请先查看目标模型当前公布的定价信息。

如果服务提供商出现故障会怎样？

这是支持单一端点的最有力论据。为故障转移而构建的网关无需修改应用程序代码即可重定向到备用模型，而三种直接集成方式则各自需要独立的重试和备用逻辑。需记住，备用模型是另一种模型：为 Claude 定制的提示词在 Gemini 上的表现可能不同，且工具调用的可靠性也有所差异。在依赖自动故障转移之前，请先在备用模型链中的每个模型上测试关键提示词。

选择迁移路径

• 评估另一家提供商：使用该提供商自带的兼容 OpenAI 的端点。这正是其设计目的，设置只需三行代码即可完成。

在生产环境中使用两三个服务提供商：建议采用网关方案，因为它可以消除重复的密钥、控制面板以及速率限制处理机制，并实现故障转移的集中管理。

根据各服务提供商的特定功能而定：对于这些功能，无论选择其他何种方案，都应保持使用原生SDK调用。

无论选择哪种方式，都应将基础URL、密钥和模型名称存储在配置文件中而非代码里，并为应用程序依赖的功能添加集成测试，比如确保工具调用符合预设架构。这样，参数缺失等问题会以测试失败的形式显现，而不会引发生产环境故障。

核心要点

• 兼容OpenAI的端点仅要求请求格式符合标准，而非所有行为；不支持的参数通常会被忽略而不会产生错误。
• Anthropic的层会忽略strict工具模式，缺乏提示词缓存功能且会将系统消息合并在一起，其官方文档中也仅将其视为测试路径。
• Gemini的层在聊天、流式处理和函数调用方面表现良好，但针对不同提供商的特殊选项仍需依赖原生API。
• 单一网关可简化跨提供商的密钥管理、计费及故障转移流程，但它会继承所有兼容性限制，并增加一个需要信任的实体。