各家 JS SDK 共用一把聚合站 key：谁的 OpenAI 兼容度够用

为什么先看 base URL 这一个开关

大多数团队接聚合站的第一个动作，是把官方 SDK 的 base URL 指到聚合端点。这一步能不能成功，取决于两件事：SDK 是否暴露 base URL 配置项，以及它发出的请求体是否被 OpenAI 兼容层接受。

前者是纯粹的接口设计问题，后者才是真正的坑。下面按这两条线索分别看。

检查 SDK 是否暴露 base URL

在 JS 生态里，判断一个 SDK 能否零改动接入，可以直接看它的构造函数参数。

• 如果 SDK 的 client 配置对象里有 baseURL、baseUrl 或 apiBase 字段，通常改一行就能指向聚合站。
• 如果只接受 apiKey 且内部硬编码域名，就必须走环境变量（如果它读的话）或者请求拦截器。
• 还有一类是框架封装，比如某些 LangChain 风格的集成，base URL 需要从外层 wrapper 往下透传。

一个实用的排查顺序是：先看类型定义的 Options 接口，再看有没有 fetch 或 axios 实例可以注入，最后才考虑 monkey patch。

OpenAI 兼容层实际接受什么

聚合站对外通常提供一个 OpenAI 形状的 /v1/chat/completions。兼容层能接受的请求体，一般是官方 OpenAI Chat Completions 的子集。这意味着：

• model、messages、temperature、max_tokens、stream 这些字段基本都会被透传或映射。
• tools、toolchoice、responseformat 这类较新的字段，各家后端支持程度不一致，兼容层可能接受但下游模型未必正确响应。
• 厂商私有字段（比如某些模型特有的 thinking 开关、缓存控制、安全参数）通常不会被识别，要么被忽略，要么直接报参数错误。

所以「OpenAI 兼容」不等于「OpenAI 等价」，它保证的是请求形状能被解析，不保证语义完全对齐。

六家 SDK 的接入形态

下面的分类只描述接入时需要关注的差异点，不涉及具体版本号和字段名承诺。

OpenAI 官方 SDK 作为通用客户端

最省事的做法往往不是用各家的 SDK，而是直接用 OpenAI 的 JS SDK 指向聚合站。因为聚合站本身就是 OpenAI 形状，baseURL 一改就能用。代价是你要自己管理模型名映射，并且失去各家 SDK 提供的类型提示和流式事件封装。

如果你的项目同时调用多个后端，这条路通常比装六个 SDK 更轻。

Claude 的 JS SDK

Anthropic 的 SDK 有自己的 Messages API 形状，和 OpenAI 的 messages 结构不完全一样，尤其是 system 提示的位置、content block 的表示方式。它支持自定义 base URL，但发出去的请求体是 Anthropic 形状。

能不能直接打到聚合站，取决于聚合站是否同时暴露 Anthropic 兼容端点。如果只暴露 OpenAI 端点，就需要在客户端做一层请求体转换，或者干脆改用 OpenAI SDK。

GPT 系列

用官方 OpenAI SDK 时不存在兼容问题，改 base URL 即可。需要注意的是模型名要换成聚合站认可的标识，以及某些新参数是否被下游支持。

DeepSeek、Qwen、GLM、Kimi

这几家的官方 JS SDK 或 OpenAI 兼容客户端，情况比较接近：

• 多数提供 OpenAI 兼容模式，意味着你可以用 OpenAI SDK 加不同的 base URL 访问，也可以用它们自己的 SDK。
• 自带 SDK 的 base URL 配置项命名不统一，有的叫 baseURL，有的叫 base_url，有的只在环境变量里读。
• 请求体差异主要集中在可选字段上，比如流式响应的 usage 统计、工具调用的返回格式、reasoning 内容的字段名。

因此对这几家，最常见的做法是统一走 OpenAI SDK，把差异收敛到「模型名 + 少量参数」这一层。

一份可复用的接入清单

把上面内容整理成可执行步骤：

1. 先确认聚合站暴露的端点形状（OpenAI 兼容、Anthropic 兼容，还是两者都有）。
2. 优先用 OpenAI JS SDK 作为统一客户端，baseURL 指向聚合站，apiKey 用聚合站签发的 key。
3. 为每个后端维护一份模型名映射表，不要把官方模型名硬编码在业务代码里。
4. 对每个后端做一次最小冒烟测试：普通对话、流式输出、带工具调用各跑一遍。
5. 只有在需要厂商私有能力时，才单独引入该厂商的 SDK，并接受它带来的第二个请求形状。

需要打补丁的典型场景

以下几种情况，单纯改 base URL 不够：

• 流式解析差异：某些 SDK 假设 SSE 事件的字段结构固定，聚合站转译后字段名可能变化，导致解析失败。
• 工具调用格式：tool_calls 的增量拼接方式在不同后端间有差异，需要按响应实际结构处理。
• 默认参数冲突：SDK 可能自动注入一些参数，聚合站或下游不认，报 400。
• 鉴权头差异：OpenAI 形状用 Authorization: Bearer，Anthropic 形状用 x-api-key，跨形状调用时要改 header。

这些补丁通常不大，但必须逐项验证，不能假设「兼容」等于「无差异」。

和小结有关的判断

如果你的目标是「一个 key 调多个模型」，最稳的路径是用 OpenAI JS SDK 作为唯一客户端，把各后端的差异压在模型名和少量参数上。厂商自带 SDK 更适合你确实需要其私有能力的时候，而不是作为多模型接入的默认方案。

在计费上要清楚：通过聚合站调用本身有加价，用户侧按官方价乘以固定系数扣费，和直接用官方 API 的成本结构不同；具体系数以站点公示为准。