模型API中转的适配器架构：为什么同一份请求参数要按厂商分别翻译

同一个产品要接两三家模型，代码里很快就会出现一层又一层判断。原因是每家厂商的接口长得都不一样：鉴权参数放在请求头还是查询串，消息体用 messages 数组还是 content 块，流式返回按什么粒度切片，各自有各自的做法。业务团队真正想写的只是“调模型”这一件事，却被迫先处理一堆协议细节。

适配器架构就是冲着这个问题来的。它在业务代码和上游厂商之间放一层中间件，内部约定一套统一的请求与响应格式，入口收到统一格式后，由对应厂商的适配器翻译成该厂商能识别的参数，拿到结果再反向翻译回统一格式。上层不需要知道这次调用最终发给了谁。

听起来像是“写几个格式转换函数”，但实际差异远不止字段名。以工具调用为例，有的厂商返回结构化的函数名与参数 JSON，有的把调用意图混在文本里由调用方自行解析；系统提示词有的单独占一个字段，有的必须塞进消息数组第一条。多模态输入更明显，图片传 URL 还是 base64、挂在哪个层级，各家规则并不一致。

再叠加上鉴权与签名方式、流式分片结构、超时与限流行为、错误码语义，差异清单会越拉越长。这些差异如果散落在业务代码里，接一家新厂商就是一次伤筋动骨的改造，上游改一次接口就要重新回归整条链路，测试成本会快速累积。

所以每个模型厂商要独立适配，第一个原因是协议语义不同，很难用一套万能映射覆盖。即便是对外宣称兼容 OpenAI 协议的厂商，也往往在扩展字段、默认参数、返回结构上保留了自己的习惯，硬套统一模板，轻则丢掉部分能力，重则线上直接报错。

第二个原因是变更节奏不同。厂商会更新模型版本、下线旧模型、调整参数默认值、收紧限流策略，这些动作的时间点彼此独立，也不会提前对齐。适配器把变更关在一个模块里，上游改动只影响对应适配器，业务层不用跟着发版。

第三个原因是错误语义需要归一化。限流触发、内容审核拦截、上下文超长、模型临时不可用，各家返回的错误码和提示文案都不一样。适配器把它们整理成统一的可枚举类型，上层才可能写出同一份重试、降级与熔断策略。

模块化的价值也正在这里。一个层次比较清楚的适配器层，通常会拆成鉴权模块、请求映射模块、响应解析模块、流式处理模块和错误归一化模块。新增一家厂商，只需要新增一组实现并注册进去，主干调度逻辑不必改动，代码评审的范围也能控制在局部。

再往上走一层是能力声明。把“哪个模型支持工具调用、哪个支持图片输入、上下文上限多少、是否支持结构化输出”从代码里抽出来，做成配置或元数据表，路由层读这份声明来决定请求发给谁。模型上下线、能力调整于是变成一次配置变更，而不是一次代码上线。

不过适配不等于抹平一切。如果强行把所有厂商的能力压成最小公约数，特有的推理模式、缓存机制、结构化输出就会被悄悄丢掉。比较务实的做法是分层处理：统一层保证通用调用能跑通，透传层允许业务直接传厂商原生参数，必要时还能拿回未经加工的原始响应。

对使用模型 API 中转的团队来说，判断适配层做得好不好，有几项可以直接观察：换模型是否只需要改一个模型名，流式与同步是否共用一套接口，错误码能否统一捕获，厂商原生参数能否透传，新模型上线是否要等平台发版。这些问题问清楚，比只对着参数表比较更有参考价值。

落到具体选择上，快米兔的模型 API 中转注册送 5 元测试金、按量计费，适合先小流量验证适配层是否顺手，再决定要不要扩大调用规模，具体能力与计费细节以官方说明为准。适配器架构说到底是把上游的不确定性挡在业务之外，让团队把精力留给产品本身，而不是反复处理接口之间的细碎差异。