企业官网建设流程全解析

过去两年“AI应用开发”几乎成了企业级应用的标配话题，但真正动手做过多模型接入的Java团队，多少都有点有苦说不出的感觉。我见过好几个团队，业务侧的需求明明很简单，今天要接模型A，明天要换模型B，后天又要加一个模型C做效果对比，结果底层接口协议不统一，每家模型的鉴权方式、流式响应、token计费模型全都不一样，业务代码被各种SDK的细节塞满，换一个模型就像动一次大手术。这篇文章不聊概念，就聊聊我在实际项目里怎么用一套统一模型接入层破解“多模型接入”困局，从设计思路、代码落地到工程化避坑，给同样被模型碎片化折腾的Java开发者一个可以直接抄作业的参考。

1. 多模型接入困局是怎么形成的

1.1 被困住的第一道锁：供应商锁定与模型切换的隐性成本

先讲一个我实际遇到的场景。某公司有三个业务系统，分别接入了不同厂商的大模型接口：客服系统接的模型A，内容生成系统接的模型B，审核系统接的模型C。刚开始各干各的，看起来没什么问题。但半年后模型B宣布调整API版本，新接口的请求参数和返回值结构变了，内容生成系统整整花了两个迭代才完成迁移，期间所有依赖这个能力的产品功能全部冻结。

这种困境的核心并不是模型本身不好用，而是业务代码和模型厂商的接口协议深度耦合了。你用Java写业务逻辑，却到处都是某个模型的SDK调用、某个厂商特有的请求对象、某个模型的返回结果解析。每一处依赖都是在给未来的自己埋雷。一旦模型涨价、效果不达标、或者有更合适的新模型出现，想换模型的时候才发现，改造范围横跨服务层、持久层甚至前端展示逻辑。

我把这种模式叫作“点对点集成”，它最大的问题是没有缓冲地带。业务侧直接面向具体的模型SDK编程，供应商的任何风吹草动都会直接传导到业务代码里。更麻烦的是，这种耦合会随着接入模型数量的增加而成指数级增长——不是线性，是指数级，因为每个业务模块都可能需要同时兼容多个模型的差异。

1.2 接口碎片化：每家模型都是一套自成一体的协议

如果只用过一家大模型的API，你可能觉得“API不就那样嘛，发个请求带上prompt，拿回结果不就行了”。但一旦开始接第二家、第三家，就会明白什么叫碎片化。

先说请求格式。有的模型接口走标准的OpenAI风格，参数叫messages，里面是role和content的数组；有的模型接口走自定义风格，参数叫input，结构是完全嵌套的JSON；还有的模型虽然对外宣称兼容OpenAI格式，但实际实现里塞了不少私有的扩展字段。作为调用方，你永远不知道一个看起来普通的请求包会让哪家模型报错。

再说返回格式。有的模型返回纯文本字符串，有的返回一个包含choices、usage、created等多个字段的复杂结构，有的是SSE流式返回，有的却只支持简单的HTTP长连接。更别提各家在错误码、限流策略、超时行为上的差异——有的模型超时是报HTTP 408，有的是返回200但内部标注一个超时错误码，还有的干脆直接断开连接让你去猜。

如果这些差异只存在于底层，那问题还不大。麻烦的是，它们会一路渗透进业务代码。我在一个项目里看到过这样的代码：业务逻辑里判断模型的返回结果，直接去取data.choices[0].message.content，换一个模型就得改这一行，连带着下面的空值判断、异常分支、日志字段全部要重做。这就是接口碎片化的后果：每个模型都逼着你为它写一套专属的适配逻辑。

1.3 成本与路由：token计费让财务对账变成噩梦

除了技术层面的割裂，多模型接入还有一个经常被低估的麻烦——成本管理。不同模型的计费维度不一样，有的是按token计费，有的按字符数计费，有的还会区分输入token和输出token的单价。在只接一个模型的时候，这事很好办，看一家厂商的账单就行。但接了三家模型之后，你需要在代码里准确记录每一次调用的输入输出token数、模型版本、调用时间，再把它们和三家厂商的账单做交叉验证。

我见过一个团队做这件事的方式：让开发同学每天手动从日志里捞token统计，再用Excel对账。这不仅是效率低下的问题，更致命的是一旦某个模型切换了版本，token计算口径变了，对账数据就对不上了。如果不在代码层面对token计量做统一管理，这些数据永远只能是估算，准确性无从谈起。

这才是“多模型接入困局”的全貌：技术层面的接口割裂、运维层面的成本混乱、业务层面的供应商锁定。这三股力量拧在一起，让每一个Java开发团队在面对“多模型接入”这个需求时都变得格外谨慎。

2. 破局思路：用适配器思想构建模型中立层

2.1 核心设计原则：业务层永远只面对一个接口

既然问题的根源是业务代码和模型SDK的深度耦合，那破局的核心思路就一句话：在业务代码和具体模型之间，插入一层稳定的中间层。业务侧只依赖这层抽象接口，不直接依赖任何一家模型的SDK。所有模型相关的细节，都被封装在中间层之下。

这个思路并不新鲜，本质上就是后端开发里很成熟的适配器模式。但真正把它应用到大模型接入场景，比想象中的要难。原因在于大模型接口的交互模式太丰富，你要抽象的不是一个“发个请求拿个结果”的同步方法，而是一整套面向流式、面向token计量、面向动态路由的交互模型。

我来定义一个最小可用的模型网关接口，让大家感受一下抽象到什么程度才合适：

public interface ChatModelGateway { /** * 核心聊天补全方法，返回完整结果 * 适合不关心流式输出的简单场景 */ ChatCompletionResponse complete(ChatCompletionRequest request); /** * 流式聊天补全方法，返回响应式流 * 适合需要打字机效果、实时展示的场景 */ Flux<ChatCompletionChunk> completeStream(ChatCompletionRequest request); /** * 模型供应商标识，比如 openai-compatible、qwen-compatible 等 */ String provider(); /** * 当前适配器是否支持处理指定的模型名 */ boolean supports(String modelName); }

这个接口是整层抽象的基石。provider()方法用来标识适配器归属，supports()方法用来做路由判断，complete()和completeStream()分别覆盖同步与流式两类主流交互模式。所有业务模块只和这个接口打交道，不关心底层调用的是哪家模型。

在设计这个接口时，最关键的决定是把请求和返回都定义成平台中立的数据结构，而不是直接用某个厂商的SDK对象。比如ChatCompletionRequest里包含model、messages、temperature、maxTokens等通用字段，ChatCompletionResponse里包含content、inputTokens、outputTokens、finishReason等通用字段。这些对象是整个中间层的通用语言，不同模型适配器负责在这套通用语言和各家SDK之间做翻译。

2.2 工具选型：Spring AI还是LangChain4j，还是自研

定了设计思路之后，下一个问题必然是：有没有现成的框架可以用？市面上确实有两个主流的Java生态AI框架，一个是Spring生态的Spring AI，一个是LangChain4j。我之前两个都仔细评估过，也分别在项目里试用过。

Spring AI的优势是它背靠Spring生态，如果你本身就在用Spring Boot，那集成成本很低。它提供了ChatClient接口，支持流式调用、Prompt模板、结构化输出转换，还能像Spring Data一样通过@Tool注解快速暴露Java方法给模型调用。团队如果全栈Spring，用它来起步是很顺手的。

LangChain4j的优势则在它的抽象模型更贴近LangChain的设计理念，对RAG、AiService等高层抽象做得更完整，如果你要做的应用是以Agent和知识库为核心的，LangChain4j的组件化能力会更强。

但两个框架有一个共同的问题：它们都在快速迭代中，而且为了适配所有模型，抽象层都比较厚。你在享受它们提供的便利的同时，也等于把一部分控制权交给了框架。对于大多数Java企业来说，如果目标是做一款长期稳定的产品，而不是快速试验一个Demo，我更推荐“轻自研”：在Spring生态下，用适配器模式自己搭建一个模型网关层，不依赖任何AI框架的庞杂抽象，只保留最核心的模型接入能力。

这就像建房子，Spring AI相当于精装房，拎包入住，但户型不能改；自研等于清水房，前期麻烦一点，但每个隔断都能按你的需求来。对于多模型接入这种核心资产，我更愿意掌握控制权。

2.3 配置中心与路由策略：把“用哪个模型”变成运行时决策

中间层解决了接口统一的问题，还有一个关键问题需要解决：路由策略。在多模型接入场景下，“用哪个模型”这件事不应该被硬编码在业务代码里，而应该是一个运行时可变的配置。

我把路由策略分为两个层级。第一层是粗粒度路由，面向场景。比如客服系统走模型A，内容生成走模型B，审核系统走模型C。这种路由规则通常在配置中心里定义，以“场景标识+请求参数”为输入，输出对应的模型适配器。

第二层是细粒度路由，面向请求。比如同一套内容生成系统里，80%的流量走模型B，20%的流量走模型D做效果对比；或者当模型B的响应延迟超过阈值时，自动熔断并切换到模型D。这些策略不可能静态写死，必须通过配置中心下发。

我用一张配置表的思路来管理路由规则，字段大致是：场景名称、适配器名称、模型名称、权重、熔断阈值、开关状态。Spring Cloud Config或者Nacos都可以承载这套配置，只需要保证配置变更能实时推送到各个实例即可。

配置化路由带来的收益是巨大的。最直观的一点是，当业务方说“我想试试用模型D来做内容生成”的时候，整个过程不需要发版，不需要改代码，只需要在配置中心加一条路由规则，调整灰度权重，就可以在线上直接做A/B测试。模型切换变成了一个运维操作，而不是一次开发任务。

3. 代码落地：从零搭建一个多模型接入框架

3.1 定义统一模型网关工厂与IoC装配

有了统一接口和路由配置，接下来要做的是把它们串起来。第一步是实现一个模型网关工厂，它的职责是：根据配置中心下发的路由规则，找到对应的适配器实例，组装请求并完成调用。

我用一个ModelGatewayRouter来做这件事。它内部维护一个适配器注册表，启动时从Spring容器里拿到所有ChatModelGateway实现类，注册到Map里；每次请求来了，根据当前场景配置和请求参数找到匹配的适配器，交给它执行。

@Component public class ModelGatewayRouter { private final Map<String, ChatModelGateway> gatewayMap = new ConcurrentHashMap<>(); public ModelGatewayRouter(List<ChatModelGateway> gateways) { gateways.forEach(g -> gatewayMap.put(g.provider(), g)); } public ChatCompletionResponse complete(String scene, ChatRequest request) { RouteRule rule = routeRuleManager.getRule(scene); ChatModelGateway gateway = gatewayMap.get(rule.getProvider()); if (gateway == null) { throw new ModelGatewayException("No gateway for provider: " + rule.getProvider()); } request.setModel(rule.getTargetModel()); return gateway.complete(request); } public Flux<ChatCompletionChunk> completeStream(String scene, ChatRequest request) { RouteRule rule = routeRuleManager.getRule(scene); ChatModelGateway gateway = gatewayMap.get(rule.getProvider()); if (gateway == null) { throw new ModelGatewayException("No gateway for provider: " + rule.getProvider()); } request.setModel(rule.getTargetModel()); return gateway.completeStream(request); } }

这里有一个容易被忽略的设计点：为什么用provider()做Map的key，而不是用modelName()。因为一个适配器往往能支持同一协议风格的多个模型型号，用provider做key更稳定。比如某个适配器支持OpenAI兼容协议，它内部可以根据传入的model字段来区分是调用标准模型还是轻量模型，而对外始终是同一个适配器入口。

Spring IoC在这个过程中起了很关键的作用。只要在类上标注@Component或者@Service，Spring就会自动把适配器实现注入到构造函数里。后续每新增一个模型接入，只要写一个新的适配器实现类，系统就能自动识别，业务代码零改动。

3.2 实现不同模型的适配器：翻译层的核心细节

适配器是整个中间层里代码量最大的部分，也是真正考验功底的地方。每个适配器的任务都相同：把统一的ChatRequest翻译成对应模型的SDK请求，然后把SDK返回翻译回统一的ChatResponse。

以支持OpenAI风格协议的适配器为例。翻译逻辑主要集中在两块。第一块是消息转换，通用协议里的messages数组需要映射到OpenAI SDK里的ChatMessage对象列表，同时保留system、user、assistant三种角色；第二块是参数映射，比如通用协议里的maxTokens需要映射到SDK里的max_tokens，temperature的范围从0到2的浮点数映射到对应模型允许的范围。

对于走自定义协议、不兼容OpenAI风格的模型，适配器的写法则更偏向传统的HTTP客户端调用。我们拿到请求参数后，拼装JSON body，调用WebClient发起POST请求，解析响应的JSON结构，再转换成统一的ChatResponse对象。

适配器还有一个隐藏的细节需要处理：不同模型的入参差异。有些模型支持stop参数控制停止序列，有些模型不接受这个参数；有些模型支持response_format来控制JSON输出，有些模型则会直接报错。通用的做法是给ChatRequest增加一个Map<String, Object> extraParams字段，适配器只提取自己关心的参数，忽略不支持的参数。这样既能保留各家模型的灵活性，又不会破坏统一接口的稳定性。

3.3 流式响应与响应式适配

流式响应是大模型应用里最影响体验能力之一，但也是适配层里最容易翻车的环节。不同模型对SSE的实现有细微差别：有的只返回最终结果流，有的会在每条消息里带完整的增量内容，还有的会在流式过程中插入心跳包。

我在网关接口里直接使用了Project Reactor的Flux来统一流式响应的返回类型。这是Spring WebFlux体系下的标准响应式类型，好处是它不仅能在WebFlux环境里直接作为HTTP响应体返回，也能在Spring MVC环境里通过SseEmitter做适配，上下游都能接受。

适配器内部的流式转换，核心逻辑是把SDK提供的流式事件流，映射成统一的ChatCompletionChunk对象流。以OpenAI风格协议为例，SDK通常提供onPartialMessage之类的回调或者一个Flux<ChatCompletionChunk>，我们只需要在map操作里做字段重映射。遇到那种原生不支持流式、只支持一次性返回的模型，适配器可以在内部模拟一个只有一个元素的Flux流，把完整响应包装成单块chunk偷摸塞进去，这样业务层永远只面对统一的流式模型，不会因为某个模型不支持SSE而被迫改代码。

写到这里想强调一个工程上的原则：统一抽象的边界，不是在“所有模型能力相同”的前提下设计的，而是在“能力有差异、但交互模式必须统一”的前提下设计。不支持流式的模型可以内部模拟流式，不支持的参数可以默默忽略，这样业务层的心智模型始终是稳定的。

3.4 超时、重试与熔断降级

模型接口的稳定性远远达不到企业级应用的要求标准。高峰期延迟飙升、限流报错、超时断连，都是常态。如果不在网关层做保护，这些问题会直接压垮上游业务。

我在网关层内置了三级保护机制。第一级是超时控制。每个场景都可以单独配置连接超时和读超时时间，比如内容生成场景配置120秒读超时，客服问答场景配置30秒读超时。不同的模型、不同的prompt长度、不同的业务容忍度，超时阈值应该各不相同。

第二级是重试策略。对于网络抖动和瞬时限流，简单的指数退避重试通常就能解决。但重试要具备两个必要条件：请求是幂等的、flexible to retry，以及目前没有超过最大重试次数。对于流式响应，如果已经向用户输出了几个token然后连接断了，这时重试会让用户看到重复内容，所以流式场景我不建议盲目重试，而是向上抛异常，让业务层决定是否进行兜底。

第三级是熔断降级。当某个模型连续错误率超过阈值，比如一分钟内错误率超过30%，熔断器打开，后续请求在熔断周期内直接切换备用模型或者返回兜底话术。我用了一个轻量级的滑动窗口计数器来统计错误率，没有引入额外的熔断框架，实现起来大概两百行代码，但效果非常稳定。

4. 工程化落地的关键细节

4.1 流式响应的线程模型与背压处理

流式接入带来了一个经典的Java后台工程问题：在WebFlux环境下，响应式执行模型和传统阻塞式IO模型混用，容易导致线程池被耗尽。

我第一次把模型网关集成到Spring MVC项目时踩过一个坑。业务层用的是Spring MVC，但网关层用了WebFlux的WebClient做流式调用，结果在流量上来之后，Tomcat线程池的线程被大量阻塞等待上游模型响应，最终整体可用性下降。排查下来发现，问题出在WebClient底层默认使用的是Netty的EventLoop线程，而这些线程在等待模型响应时被持续占用，无法再处理其他请求。

解决方案是把WebClient配置为使用独立的线程池，并设置合理的并发上限。对流式调用来说，还要关注背压问题——下游消费速度慢于上游生产速度时，默认的缓冲策略可能导致内存溢出。我在网关层对流式响应的缓冲大小做了明确限制，并在无法及时消费时主动丢弃部分数据而非无限堆积。

这些细节看起来不起眼，但它们是多模型接入真正能在生产环境平稳运行的隐形地基。模型层魔术做得再好，如果基础网络层没打牢，一切都会白费。

4.2 token计量与成本控制：系统自动统计

回到最开始提到的成本管理问题。我在设计统一接口的时候，特意在ChatCompletionResponse里保留了inputTokens和outputTokens两个字段，所有适配器在返回结果时，必须从SDK响应里提取这两个值并填充进去。对于那种SDK不直接返回token用量的模型，适配器内部需要先做一次估算填充，返回结果之后再异步用真实用量修正。

这个“先估算、后修正”的策略在实际使用中效果很好。业务侧读取响应时，token数据已经可用，无需等待；当异步修正完成后，我们再把准确数据更新到成本统计表里。整个成本数据逐条落库，每天跑任务统计各场景、各模型的累计输入输出token量及对应费用。

在有这个机制之前，让开发去手动捞日志对账的时代彻底结束了。每次模型调用的成本、每个场景的月度开销、每个供应商的历史费用对比，都能通过一个简单的管理后台查清楚。这个后台不仅是财务工具，更是业务决策的支撑——当业务方提出“要不要换成更便宜的模型”，你能立刻给出一组数据来支撑判断，而不是拍脑袋。

4.3 灰度发布与模型切换的演练

模型网关层建立后，模型切换从开发任务变成了运维动作，但这不意味着可以毫无顾虑地切。新模型在线上表现如何，是否存在幻觉率更高、响应不稳定、格式输出不符合预期等问题，都需要有一个可控的观察过程。

我在路由配置里支持卡控灰度逻辑：按用户ID取模分配流量，或者按请求头携带的特定标记来强制某个用户走新模型。实测下来最常用的还是按百分比灰度，比如先配置新模型5%的流量，观察一天的错误率和延迟指标，没问题再逐步调到30%、70%，最后全量。

灰度切换不只是技术操作，还要有配套的数据对比。我在网关层为每次调用生成了唯一的traceId，记录请求参数、模型名称、响应结果、token用量、延迟和错误信息。这样在做灰度对比的时候，可以直接按traceId把同一份业务的请求在旧模型和新模型上的表现拉到一起看。

特别提醒一点：大模型的灰度切换需要比传统服务更长的观察期。传统服务切流看错误率和延迟就够了，但大模型还要关注生成内容的质量，这个只能靠人工评测或设置自动评测任务来兜底。哪怕是自动评测，也要准备一个足够覆盖业务场景的评测集。

4.4 测试策略：没有良好抽象，模型测试就是一团乱麻

多模型接入的测试是一个大难题。真实调用外部模型做集成测试既慢又不稳定，还有成本和限流问题；不调用真实的模型又没法验证业务逻辑的正确性。我做了三层测试策略来应对。

第一层是单元测试，核心是验证适配器的翻译逻辑。把所有对外部模型的HTTP调用mock掉，固定输入请求，断言转换后的SDK请求参数是否准确，以及SDK响应到统一响应的转换是否正确。这一层不关心模型能力强不强，只关心代码逻辑对不对，跑得越快越好。

第二层是契约测试，核心是验证不同适配器对外表现的一致性。准备一组固定的输入Prompt，分别通过各适配器的统一接口去调用真实模型，然后把返回结果和统一协议里的约束逐一对比。这种测试不追求覆盖率，只求覆盖典型的业务场景，比如正常问答、空输入、超长文本、特殊字符等。

第三层是测试环境的轻量桩服务。我们在测试环境搭建一个模拟大模型接口的桩服务，复现真实模型在不同场景下的请求和返回特征，供开发同学日常调试使用。桩服务最大的价值是它可以模拟极端情况，比如延迟飙高、返回错误码、网络断连等，这些在真实模型接口上很难按需重现。

这三层测试加起来，可以让团队在几乎不依赖外部模型服务的情况下完成绝大部分开发工作，只有到了发版前做验收时才需要真实调用一次模型做全链路确认。这个策略帮我省下的时间成本，比写适配器的成本高好几倍。

4.5 观测体系：让每次调用都有据可查

最后一个工程化细节是观测体系。多模型接入之后，问题排查的复杂度上了一个台阶，原来只需要看自己服务的日志，现在还要看外部模型的响应是否符合预期。如果没有一套好的观测体系，出了故障你连“到底是业务代码的问题还是模型返回的问题”都分不清。

我在网关层统一打印结构化的调用日志，包含traceId、场景名、模型名、请求token数、响应token数、首次响应时延、总时延、错误码、返回结果摘要等字段。这些日志直接通过日志平台采集，并同步接入到监控大盘。监控大盘的核心指标有两个：模型调用成功率、模型响应延迟P95。

有了这些数据之后，很多问题都能在分钟级定位。比如某段时间内容生成时长明显上涨，我能在监控大盘里直接看出是模型B的P95延迟升高导致的，快速决定是否要做切换，而不是让业务同学反馈问题之后再去翻日志。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

下面梳理一下我在多个项目里反复遇到的高频问题。很多坑是在不同团队里以不同形式重演了一遍又一遍的，值得整理出来供大家参考。

这七个问题基本覆盖了我在多模型接入项目里遇到的绝大多数生产事故。里面最容易被忽略的是第一个：统一响应兼容层。很多模型在返回结果为空时，会省略一些字段，或者返回null数组。如果适配器不做归一化处理，业务层总会遇到莫名其妙的空指针，而且这种空指针因为只在新模型下出现，很难从经验里预判。

5.2 几个查漏补缺的排查技巧

除了速查表里的常规问题，还有几个排查技巧，是从实际故障里提炼出来的，常规文档很少提到。

第一个技巧是善用“模型返回原始报文留痕”。每次调用外部模型时，把原始请求报文和原始响应报文都记录下来，存储在日志系统或者专门的存储表里。很多问题在统一接口层面看不出来，但要回到原始报文才能定位。比如模型返回了一个不在预期结构的JSON字段，统一接口解析失败，只靠统一的ChatCompletionResponse根本看不出端倪。

第二个技巧是处理好“长连接下的连接池泄漏”。从HTTP连接池的角度看，调用大模型接口和调用普通HTTP接口有一个明显区别——单次调用耗时长。如果连接池配置过小，而并发请求又集中在同一个模型上，会表现为“模型服务正常，但调用方大量超时”。

我排查过一个问题，某模型接口在高峰期平均耗时30秒，而连接池最大连接数是50，意味着同一时刻最多只有50个请求在走这个模型的连接，多出来的50个请求全部在池外面排队。这个问题的解法不是无限加大连接池，而是要在应用层做好并发控制，根据模型的TP95延迟和单实例可用连接数，算出一个合理的并发上限，超出的请求直接走降级策略，而不是让它们在池外无限等待。

第三个技巧是注意“不同模型对不同提示词的上下文长度反应完全不同”。有的模型上下文窗口大，几万token不觉得吃力；有的模型上下文稍长就开始输出质量明显下降。这类问题不是技术Bug，但会让模型切换的效果评估产生很大偏差。切换模型做A/B测试时，一定要保证对比双方使用相同的上下文截断策略，不能一个截到8K、另一个截到32K，否则你对比的根本不是模型能力，而是上下文处理差异。

6. 模型接入层完成之后还能怎么延伸

说实话，当初搭建这个统一模型网关层，最初只是想解决“换模型要改代码”的痛点。但实际落地之后，我发现它的价值远不止于此。当所有模型调用都收敛到一个统一入口之后，原本分散在各处的模型调用能力变成了一个可以被统一管理、统一观测、统一治理的基础设施。

这也意味着，后续如果团队想引入更多AI能力，比如多模态、向量化检索、Agent编排、自动评测，都可以在这个模型中立层上继续扩展。新能力的接入不需要重新铺设一套连接逻辑，而是作为新的适配器实现类，挂到同样的路由框架下。

以我们的实践来看，建立这样一个模型中立层的整体投入大概是两到三周的开发量加一个迭代的打磨期，但它带来的收益是持续性的：每个新模型接入的时间从按周计算压缩到按天甚至按小时计算，模型切换变成一个低风险、可灰度、可回滚的常规运维动作。这在大模型技术还在快速迭代的当下，几乎是一个Java团队必须具备的应变能力。

最后分享一个小技巧：模型网关层的代码结构一定要保持简单，不要为了追求“高大上”引入过多复杂的抽象和框架。这个层的核心使命就是翻译和路由，把复杂留给业务，把统一留给细节。我在迭代过程中几次想往里面加入编排能力和知识库集成，最终都忍住了。守住这个层的边界，它才能长期稳定地成为团队AI应用开发的基石，而不是变成另一个需要被重构的麻烦制造者。