一个要长期可用的大模型舆情监测系统，最大的工程挑战不是「接入某一个模型」，而是「持续接入不断变化的一批模型」。Kimi、腾讯元宝、字节豆包、秘塔、通义千问，再加海外的 OpenAI、Claude，接入方式、认证机制、限流策略、反爬规则各不相同，而且会不定期调整。把这些差异散落在业务代码里，系统会迅速变成无法维护的意大利面。本文分享应对这种多变性的架构设计：用「适配器」层把变化隔离出去。
核心思路：用统一接口抽象「提问—获取回答」
不管底层是哪个平台，舆情监测要做的事是一致的：发起一个提问，拿回一段回答（连同引用、截图等证据）。所以第一步是定义一个与具体平台无关的统一接口，把「提问」和「回答」抽象成稳定的数据结构。业务层只依赖这个接口，不关心背后调用了谁。
每个平台一个适配器
接口之下，为每个平台实现一个独立适配器，由它把统一接口的请求翻译成该平台特定的调用方式，再把平台返回的原始结果翻译回统一的回答结构。平台改了接口，只需改对应那一个适配器，业务层和其他平台完全不受影响，这就是适配器模式的价值：把变化的范围牢牢锁在一个模块之内。
两条不能违反的依赖原则
- 接口隔离：统一接口只暴露业务真正需要的能力，不把某个平台的特殊参数泄露到公共接口上，否则抽象就被某个具体实现绑架了。
- 单向依赖：依赖只能从「业务层 → 接口 → 适配器」单向流动，适配器绝不能反向调用业务逻辑。方向一旦双向，模块就再也拆不开。
动态选择适配器
运行时，系统根据任务指定的平台，把请求动态路由到对应适配器。新增一个平台，只要实现并注册一个新适配器即可，无需改动调度逻辑，这正是「对扩展开放、对修改封闭」的落地。
用契约测试守住「翻译」的正确性
适配器的本质是「翻译」，而翻译最容易在平台悄悄改版时失真：字段改了名、回答结构多了一层嵌套、错误码含义变了。靠人工发现这些往往要等到数据出问题之后。更稳妥的做法是为每个适配器写一组契约测试：用录制下来的该平台真实响应样本，断言适配器能把它正确翻译成统一结构。平台一旦改版导致样本解析失败，测试立刻报红，而不是让脏数据悄悄流进业务。
把版本多变性也纳入抽象
同一个平台还会有多个并存的版本：老接口未下线、新接口已上线，或灰度中。把「平台」和「版本」拆成两个维度：一个平台可以挂载多个版本化的适配器实现，路由时按配置选择版本。这样切换新版接口、或在新旧版本间灰度对比，都不需要动业务层，只是改一处路由配置。平台下线老接口时，删掉对应版本的适配器即可，风险被关在一个文件里。
把「不稳定」当成常态来设计
外部平台一定会失败：超时、限流、反爬校验、临时改版。健壮的适配器层必须把这些当成常态：
- 超时与重试：为每次外部调用设合理超时，对可恢复的失败做有限次退避重试。
- 降级与熔断：某个平台持续异常时，自动暂停对它的调度、隔离故障，避免拖垮整个监测队列。
- 证据留存：每次调用保留原始回答与渲染截图，既是业务上的证据链，也是排查平台变更的依据。
可观测性：让「哪个适配器出问题」一眼可见
适配器越多，定位故障越难。所以监控指标必须按「平台 加 版本」这个维度拆开：每个适配器各自的成功率、平均耗时、验证码触发率、解析失败率。某平台一旦改版，往往先表现为该适配器的解析失败率突然抬升，有了分维度的指标，你能在用户察觉数据异常之前就定位到是哪个适配器、哪个版本出了问题。把这些指标和上面的契约测试结合，就形成了「测试拦截已知变更、监控发现未知变更」的双层防线。
这套设计带来什么
当适配器层稳定下来后，「接入新模型」从一项牵一发动全身的改造，变成一次局部的、低风险的新增工作；「应对平台改版」也从救火，变成测试报红后改一个文件。对舆情监测这种强依赖外部、且外部高频变动的系统而言，把变化隔离在边界、再用契约测试和分维度监控守住边界，是长期可维护性的根本保证。