每接一家大模型就要改一次代码：适配器架构如何把上游接口差异与变更收敛在一层

很多团队的大模型接入代码，最初都写得很简单：一个请求地址、一个密钥，几十行就跑通了。等到业务需要第二家、第三家模型时，代码里开始出现按厂商分支的判断语句，参数名要换、返回结构要拆、流式解析要重写，维护成本随接入数量线性上涨。这正是适配器架构要解决的问题，它不是为了架构图上好看，而是为了让新增一家模型厂商不再意味着一轮改造。

适配器架构的核心思路并不复杂：在调用方和上游服务之间插入一层中间层，对内向业务暴露一套稳定的统一契约，对外为每个上游提供一份独立的适配实现。调用方只认识统一契约，上游的字段命名、鉴权方式、协议细节全部被封在各自的适配模块里。可以把它理解成旅行用的电源转换插头：墙上的插座五花八门，但你的设备只需要一个固定的接口形状。

先看差异究竟出在哪里。最表层是鉴权与路由，有的厂商用标准的 Bearer Token，有的要求在请求头里带额外签名，有的把版本号写进路径、有的写进请求体。再往下是请求体结构，同一件事在不同厂商那里可能是完全不同的写法，参数名称、默认值、取值范围、是否必填都不一致。

更麻烦的是响应侧。对话补全的返回结构看似相似，但字段层级、结束原因、用量统计的命名和位置往往各有主张。一旦开启流式输出，差异会被进一步放大：分片的数据格式、结束标记、工具调用参数的增量拼装方式，都需要逐家适配。如果业务代码直接解析上游原始响应，任何一家调整格式，都会变成一次线上事故排查。

错误处理同样是重灾区。同一个语义的错误，有人返回 400 并附一段文本，有人返回 200 却把错误塞进响应体，错误码的取值体系更是各成一套。限流触发时的表现、退避重试的建议等待时间、配额不足与密钥失效如何区分，这些都必须在上层统一成可判断的语义，否则重试逻辑写多少遍都不对。

这就回答了那个常见疑问：为什么每个模型厂商都要独立适配。因为差异是常态，而不是靠一两个开关就能抹平的例外。厂商的模型能力、版本节奏、工程实现都属于各自的技术资产，既没有动力也没有义务统一到同一套外部标准上。既然上游不会主动收敛，收敛的工作就只能放到中间层来做。

模块化设计之所以能吸收这些差异，关键在于把变化关进边界里。统一契约一旦固定，各厂商适配模块就变成可插拔的插件：新增一家，只写一个新适配器；某家下线或大改，只改对应模块，其余部分不受牵连。再配合一张能力声明表，把是否支持流式、是否支持工具调用、上下文长度区间等信息登记在册，路由与降级判断就有据可依，而不是散落在一堆条件判断里。

光有结构还不够，还必须配套质量控制。成熟的做法包括：针对每个适配模块维护一组契约测试，确保统一契约的行为不因上游变更而漂移；用真实请求做录制回放，让回归验证不依赖线上环境；变更上线走灰度，先放小比例流量观察错误率和耗时变化；同时把上游返回的原始信息保留在链路追踪里。出问题时既能定位到是哪一段映射出了偏差，也能快速回滚。

自己搭一层也不是不行，但成本要算清楚。适配层看起来只是一个函数库，实际要投入的是持续的人力：新模型上线要跟、字段弃用要跟、协议升级要跟，还要有人维护测试用例和线上告警。对模型调用量不大、或者只是做验证性项目的团队来说，这部分固定投入往往比调用费用本身更显眼。

也正因如此，把适配层作为公共服务来提供，成了模型 API 中转平台存在的技术理由之一。以快米兔的模型 API 中转为例，它把各厂商的接口差异收敛在平台内部，业务侧对接的是统一契约，注册即送 5 元测试金，按量计费，不设套餐门槛，适合先小规模验证再逐步放量的团队。对使用者而言，最直接的变化是新模型上线时不必再组织一次接入改造。

挑选这类平台时，值得关注的不是模型列表有多长，而是几件更基础的事：新增模型从发布到可调用的时间差，统一契约在不同厂商之间的一致性程度，错误语义和重试建议是否清晰，用量与计费口径是否可核对。这些指标决定的是长期维护成本，而不是第一天的接通速度。具体资费与能力范围以官方说明为准。

回到最初的问题，适配器架构的本质是把不确定性收进一层可控的边界。上游厂商的接口差异与版本变更不会消失，能改变的只是它们对业务代码的渗透程度。对绝大多数团队来说，让这层边界由平台承担、自己专注在业务逻辑上，通常是更省事的路径；而当调用规模足够大、定制需求足够特殊时，再考虑把这层能力收回来自己维护，也是一种合理选择。