上个月想试 Kimi K3。我第一反应是去找它的 SDK 和接入文档，做好了改半天代码的准备。结果官方文档第一页就写着：Kimi API 兼容 OpenAI 与 Anthropic 两种格式，改一个 base_url 就能跑。
后来我又去翻了智谱和 DeepSeek 的文档。都在这么玩。这篇把我核对过的地址、踩过的坑，一次讲清。
base_url 是什么
调大模型 API 时，代码里总有一个地址，形如 https://api.openai.com/v1。这就是 base_url。SDK 在它后面拼上 /chat/completions 这类路径，把请求发过去。
平时你可能压根没写过这个参数。OpenAI SDK 有默认值，不填就指向官方地址，所以很多人根本不知道它的存在，直到某天要换供应商，才发现代码里到处写死了官网地址。
换个角度理解。SDK 是快递员，base_url 是收货地址。包裹的打包规格不变，你只是换了收货的那家店，店家照同一套规格收货拆包，再把回执寄回来，你不用重新学一遍怎么打包。
为什么改个地址就能用
2023 年前后，OpenAI 的请求格式成了事实标准：messages 数组、model 字段、role 分角色，响应里取 choices[0].message.content。几乎所有厂商都照这个格式实现了自己的接口，你在旧项目里写好的解析代码、重试逻辑、错误处理，大部分原样能跑。
Anthropic 的 Messages API 格式也一样铺开了。Claude Code 这类工具只认这种格式。于是各家又开了一条 Anthropic 兼容路径，专供这些工具接入。
对厂商来说这是获客手段。你从别家迁过来，改一行配置就行，学习成本是零。
三个现成的地址
下面这些地址我都对照官方文档核实过，时间是 2026 年 10 月。
Kimi（月之暗面）：OpenAI 格式用 https://api.moonshot.cn/v1，模型名配 kimi-k3、kimi-k2.7-code 这类；Anthropic 格式把 base URL 指向 https://api.moonshot.cn/anthropic。官方原话是「已经在使用 Anthropic SDK、Claude Code 等工具的开发者，只需把 base URL 指向这个地址，即可直接调用 Kimi 模型」。
智谱：Anthropic 兼容地址是 https://open.bigmodel.cn/api/anthropic。官方文档的说法是，改掉 API 密钥和基础 URL 两处，就能直接切到智谱的模型服务。
DeepSeek：Anthropic 兼容地址 https://api.deepseek.com/anthropic，OpenAI 格式则是 https://api.deepseek.com。
我写过一篇 Kimi K3 API 的上手教程，充值、模型名、价格都整理在里面，配合这篇文章食用更顺。
改地址时要动哪几样
三件事。地址、密钥、模型名。就这些。
地址换成新平台，密钥换成新平台后台生成的 key，model 字段从 gpt-xx 换成 kimi-k3 或 glm-5.3 这类新名字。请求结构、消息格式、响应解析，全都不用动。
鉴权方式跟着格式走：OpenAI 格式是 Authorization: Bearer 请求头，Anthropic 格式是 x-api-key 请求头。用 SDK 时这些它都替你处理好了，只有手写 HTTP 请求、或者排查 curl 报错的时候，才需要留意请求头对不对。
四个常见的坑
一、路径写错。OpenAI 格式的路径以 /v1 结尾，Anthropic 兼容的路径以 /anthropic 开头，两条路不能混。我第一次配智谱时就手滑写成了 /api/anthropic/v1，对着报错查了十分钟，最后发现是多打了半截路径。
二、密钥用错家。Moonshot 的 key 配到智谱的地址上，对方系统里查不到这个 key，直接 401。401、402、429 这些报错怎么排查，我之前单独写过一篇。
三、模型名没换。地址换了，model 还是别家的名字，会报 model not found。每家的模型名都不一样，这个没法猜，以官方模型列表为准。
四、套了网关还写原厂地址。用 One API、New API、LiteLLM 这类聚合网关时，base_url 要指向网关自己的地址，key 也用网关发给你的，原厂 key 留着没用。两层混着配，是我见过最多的报错来源。
什么场景值得这么换
我实际用下来，有两个半场景。
一是给 Claude Code 换引擎。它只说 Anthropic 方言，把 base_url 指向 Kimi 或智谱的兼容地址，就能用别家模型干活。Kimi 官方文档甚至专门给 Claude Code 写了接入指南。
二是聚合管理。自己搭个网关，一个地址后面挂多家模型，记账、限流、切换都在一处。我在聚合方案的实测文章里展开过这个做法。
那半个是省钱。同一套代码，哪家有活动切哪家。再配合上下文缓存、Batch API 这些省钱开关，成本还能压一截。
兼容层的边界
先说结论。主干兼容，不是百分百复刻，别指望每个细节都对得上。
举个我从文档里挖出来的例子。Kimi 的上下文缓存写入参数 cache_control，在 Anthropic 兼容格式里要放在请求顶层，你要是写在 messages 消息体里，它会被悄悄忽略，不报错、不生效。这种细节不翻文档根本想不到，踩到了还以为是自己代码写错了。
所以我的习惯是，主干请求放心切。要用冷门参数了，先翻对应厂商的文档确认一眼，一分钟的事，能省一小时的排查。
常见问题
问：兼容层的响应和官方一模一样吗？
主干字段一致。usage 里的细分字段各家有自己的拆法，缓存命中数的字段名就不太一样。解析账单相关字段时留意一下。
问：一个 key 能同时调两家吗？
不能。key 是各平台独立发的。地址和 key 必须配套，跨平台必 401。
问：会不会突然不兼容？
主干格式已是行业标准，大变的概率低。但新能力通常先出现在原生格式，兼容层跟进有延迟。关键业务建议订阅厂商的更新日志。
改一个字符串就能换掉模型供应商。数据库换厂商要重新导数据，消息队列换厂商要改客户端，而大模型这边，所谓迁移成本，很多时候真的就是一行配置。这事放在别的软件领域，挺难想象。