什么是适配器架构，为什么每个大模型厂商都要在API中转层做一次独立适配？

适配器架构是在API中转层为每个上游模型厂商单独实现接口翻译与协议转换的模块化设计，把各家在鉴权方式、请求字段、流式格式、错误码、限流策略上的差异收敛成内部统一契约，使上游改版只影响对应的那一个适配器，而不波及路由、计费、日志和业务侧代码。它不适用于上游接口完全同构、字段几乎一致的场景，那种情况用一套通用调用即可，硬拆适配器只会增加维护面。 判断一个中转系统是否需要适配器架构，看的是上游差异是否已经穿透到业务层。当调用方代码里开始出现针对某家模型的特殊分支，比如为了兼容某家必须把消息体多包一层、为了另一家必须把系统提示词拆成独立字段，说明差异已经泄漏到应用层，此时引入适配器是为了把这类分支收回边界内。反之，如果所有上游都遵循同一套字段命名和返回结构，适配器就是过度设计。 适配器架构的本质不是多写一层代码，而是把变化点从调用链路上游隔离到独立模块。每个适配器对外暴露相同的内部接口，对内负责三件事：把统一请求翻译成上游能理解的报文、把上游返回翻译回统一结构、把上游特有的异常映射成内部错误码。这样上层调度、计费、重试逻辑只依赖内部契约，不需要知道背后接的是哪一家。 模型厂商要独立适配，第一个原因是鉴权与传输层协议并不统一。有的厂商走标准 Bearer Token，有的把密钥放在自定义请求头，有的要求请求签名与时间戳，有的对传输编码有额外约束。这些差异无法用参数开关穷举，因为签名算法、时间戳格式、密钥派生方式各不相同，只能为每家写一段独立的鉴权构造逻辑。 第二个原因是请求体结构差异远比字段改名更深。同样是多轮对话，各家在消息数组的嵌套方式、角色枚举取值、系统提示词是否独立、多模态内容如何拼装、工具调用声明放在哪里，都有不同约定。更麻烦的是同一家厂商不同代际模型之间也会改结构，比如老模型把工具描述放在顶层，新模型收进消息体内。适配器的价值就在于把这种代际差异锁在单个文件里，而不是散落到每个业务调用点。 第三个原因是流式返回的格式各家自定义程度很高。服务端推送事件的字段名、增量内容所在位置、结束标志、用量统计的出现时机、错误在流中途如何下发，这些细节直接决定调用方能否正确解析。如果中转层不做归一化，调用方就得为每家写一套解析器，上游一旦调整事件结构，所有下游解析同时失效。适配器把流式事件转换成统一的增量结构，是保障调用方稳定的关键一层。 第四个原因是错误码与限流语义缺乏行业统一标准。同类问题在不同厂商那里可能表现为不同的状态码、不同的错误标识、不同的重试建议，有的把限流放在响应头，有的放在响应体，有的要求退避指定秒数。适配器负责把这些信号映射成内部统一的错误类型和重试策略，让上层调度能按同一套规则决定是重试、切换通道还是直接返回失败。 模块化设计吸收上游变更的核心手段，是让适配器成为唯一的变更入口。上游发布新版本、调整字段、废弃某个参数时，改动范围被限制在对应适配器内部，内部契约保持稳定，路由规则、计费口径、日志字段、监控指标都不用跟着改。这也是判断适配器分层是否做对的标准：一次上游接口改版，如果只需要动一个模块并且不需要回归全部业务，分层就是成立的。 判断句之外的工程细节在于内部契约的设计粒度。内部契约要足够抽象，不能被某家上游的字段结构牵着走，否则新增厂商时会发现契约本身就在迁移某一家的表达方式；同时又要保留足够信息，不能抽象到丢失上游特有的能力标识，否则适配器拿不到区分模型能力的依据。实践中常见的做法是按能力维度定义契约，把对话、补全、向量、重排、工具调用拆成独立能力接口，每家按自己支持的能力实现对应适配器。 适配器与路由调度是两层不同的职责，混在一起会同时失去两者的可维护性。适配器只回答如何与某一家正确通信，不关心选哪家、按什么成本选、失败后切哪条通道；调度层只回答选哪条通道，不关心该通道的报文字段长什么样。把两者分开后，新增一家厂商是新增一个适配器并注册能力，调整调度策略是改路由配置，两者的变更互不牵连。 计费与用量统计也依赖适配器提供统一的计量口径。各家的用量字段命名不同，有的按输入输出分别计数，有的把缓存命中单独列出，有的在流式结束时才给出汇总。如果不在适配器层做归一，计费模块就得为每家写一套解析规则，一旦上游调整用量字段，账单会出现对不上的情况。把用量提取收敛到适配器，是对账可核验的前提。 适配器架构的代价同样需要说清，它增加了一层转换开销和一组必须长期维护的模块。每接入一家厂商就要维护一个适配器，上游升级要跟进，上游下线要清理，测试用例要覆盖协议转换的边界情况。对于只接一两家上游、接口长期稳定的场景，这层抽象带来的收益可能低于维护成本，此时更合适的做法是保留少量适配逻辑而不追求完整分层。 验证适配器分层是否有效，可以看一次上游变更到业务恢复的时间。分层做对时，上游发版导致字段调整，改动集中在适配器，回归范围是协议转换的单测和该通道的连通性检查；分层没做对时，同样的调整会引出一连串针对业务代码的修改。把变更影响面作为验收标准，比看目录结构更能反映架构是否真正起到了隔离作用。 从更长的周期看，模型厂商的接口会持续演进，独立适配不是一次性工作而是常态维护。适配器架构提供的是一种让演进可控的组织方式：上游差异被收进边界，变更影响被限制在模块内，内部契约保持稳定，调用方按统一方式接入。是否采用它取决于上游异构程度和变更频率，异构越明显、变更越频繁，这层模块化设计的价值越突出。