1. 为什么存量培训系统的AI改造不能“直接调接口”
我接手这个培训系统的时候，团队里最普遍的声音是：AI升级嘛，把大模型API接进来不就行了？当时业务方提的需求也很直接：学员提问要能自动回答、课程资料要能自动生成摘要、考试题目要能智能推荐。听起来都是典型的大模型应用场景，按常规路子走，给系统里塞几个HTTP调用，加几个prompt模板，确实能快速跑通demo。
但问题恰恰出在“快速跑通”之后。
第一个坑是模型供应商绑定。demo用的是A厂商的模型，prompt调得好好的，等到要上生产环境，发现B厂商的模型在某些维度更合适、成本更低，或者A厂商突然调整了接口策略。结果所有业务代码里散落着对A厂商SDK的依赖、对A厂商返回格式的解析逻辑、对A厂商token计费方式的耦合。想切换？基本等于重写一遍。
第二个坑是多业务场景的接入混乱。培训系统不是只有一个AI入口：智能问答是一个场景，课程摘要是一个场景，题目生成是另一个场景，还有管理后台里给培训专员用的辅助工具。每个场景都要跟大模型打交道，如果各自为政，每个开发按自己的习惯去接不同的模型、写不同的prompt、处理不同的异常，一段时间之后，这套系统就变成了一个无人能维护的“黑话集合”。
第三个坑是存量系统的技术债。老系统是Java技术栈，Spring生态，内部模块划分比较传统，很多接口还是内部RPC调用。AI能力的接入如果做成独立的旁路系统，运营上割裂；如果直接侵入原有业务模块，又把系统的耦合度推向了不可控的高度。
这三个问题叠加起来，让我意识到一件事：存量培训系统的AI升级，本质上不是在“加功能”，而是在“接入一种新的基础设施能力”。既然是基础设施，就不能让每个业务方直接面对千奇百怪的模型供应商，而是需要一个统一的入口，把AI能力变成一种可治理、可观测、可切换的内部服务。
2. 统一AI能力网关的整体分层思路
想清楚问题之后，我参考了服务治理里的网关模式，又结合了中间件设计里的适配层思路，最终定下来的架构分四层。
最上层是业务接入层。这一层面对的是培训系统内部各个业务模块，它不关心底层用的是大模型A还是大模型B，只关心自己能拿到什么能力。我们对外提供的是能力API，比如“智能问答”“文本摘要”“题目生成”“相似度判断”这几个粗粒度的能力接口。业务方调用这些接口，传入业务上下文参数，拿回结构化结果。
中间核心层就是统一AI能力网关。这层负责四件事：接收业务请求、解析能力定义、编排调用链路、统一处理结果返回。翻译成大白话就是：网关知道“智能问答”这个能力背后需要调用哪个模型、需要什么prompt模板、需要什么样的后处理逻辑。它是整个架构的大脑。
再往下是适配器层。这一层是跟具体模型供应商打交道的唯一地方。每个模型供应商对应一个独立的适配器实现，比如OpenAI适配器、通义千问适配器、文心一言适配器、本地开源模型适配器。适配器负责把网关下发的标准请求参数，翻译成各家模型的API格式，再把各家模型的返回结果，统一解析成网关定义的标准输出结构。
最底层是模型资源层。包括各个云厂商的大模型API，也包括私有化部署的开源模型服务。这一层对上层完全透明，哪天换了一个模型供应商，只需要新增一个适配器实现，改一下路由配置，业务侧完全无感。
这套分层结构解决了我前面说的三个核心痛点：模型切换变成配置项而不是代码重构；多业务场景共用一套接入规范；存量系统只需要跟网关对接，不需要跟任何外部模型服务直接交互。
3. 适配层设计是这套方案的灵魂
3.1 标准化的能力描述协议
适配层要能工作，前提是定义一套“中间语言”。我的做法是设计了一个内部标准的能力请求和响应结构，所有业务方的请求都转换成这个标准结构，所有适配器返回的结果也统一转换成这个标准结构。
请求结构包含几个核心字段：能力类型（intent）、业务参数（params）、会话上下文（context）、超时策略（timeout）、风格偏好（style）。响应结构包含：状态码（code）、结果内容（content）、结构化数据（data）、消耗信息（usage）、调试信息（debug）。
举个例子，业务方调用“智能问答”，传进来的原始request到了网关之后，网关会进行协议转换，转换后的结构大致是：
{ "intent": "qa_chat", "params": { "question": "如何创建一门新的培训课程？", "course_id": "C20240315" }, "context": { "session_id": "sess_8f6a2e", "user_id": "u_10086", "history": [] }, "style": { "temperature": 0.3, "max_tokens": 800 } }适配器拿到这个标准协议之后，负责把intent映射到具体模型对应的prompt模板和模型参数上，把params注入到模板里，然后调用模型API。返回结果后，适配器再把模型回复包装成标准响应结构。
3.2 Prompt模板为什么必须外置管理
在适配器内部直接写死prompt是很多初做AI应用的人爱犯的错误。推到代码里看起来省事，但实际运营中，prompt的调整频率远高于代码发布频率。业务方每隔几天就会反馈：问答的语气太生硬了、摘要的长度要再精简一点、题目生成的难度系数不符合预期。
这些改动如果都通过发版来解决，开发和运维都会被拖死。所以我把prompt模板全部外置到了配置中心，并且为每个能力维度维护了多个模板版本。模板里使用占位符引用标准协议的字段，适配器运行时动态渲染。
模板管理走的是配置中心的发布审批流程，业务运营同学能看到的是一份可读的prompt配置文件，技术团队只负责保证适配器能正确渲染模板。这个设计在后来的运营中帮了大忙，很多微调工作根本不需要开发介入。
3.3 函数调用的适配机制
培训系统里面有些操作是需要真实调用后端服务的，比如查询学员的培训记录、获取某门课程的章节列表、提交考试结果。大模型本身没有这些业务数据，也不可能让它直接访问数据库，所以适配器里引入了function calling的机制。
标准协议里定义了一个tools字段，业务方在发起请求时可以声明本次会话允许调用哪些内部工具。适配器转换成模型支持的function calling格式，当模型判断需要查询实时数据时，会返回一个函数调用指令，适配器捕获这个指令后，通过网关回调业务系统的内部服务，拿到结果再回传给模型，最终生成完整的回答。
这个机制的落地让智能问答不再只是“拿着训练数据硬答”，而是能真正查系统里的实时数据来做推理。比如学员问“我这个月的学习进度怎么样”，模型可以先调用“查询学习进度”的函数，拿到真实数据后再组织回答。这类应用体验的提升是质的飞跃。
3.4 多模型路由策略
适配层还要解决一个问题：同一个能力，不同场景可能用不同模型更合适。比如基础问答用快速且便宜的模型就够，但涉及复杂逻辑推理的题目解析，可能需要更强的模型才能保证质量。
我在网关里设计了一套可配置的路由策略，支持按能力类型、业务线、用户等级、甚至prompt复杂度来路由到不同的模型适配器。具体的路由规则放在配置中心，运维同学可以在不发布代码的情况下调整不同场景的模型分配比例。
路由策略不仅是“选哪个模型”，还包括降级逻辑。当优先模型服务异常或响应超时时，网关自动把请求降级到备选模型，保证业务不中断。这个降级能力在多模型接入之后变成了日常运营的标配，因为任何一个云厂商的模型服务都不可能保证100%可用。
4. 存量系统的接入改造该从哪里下手
4.1 盘点存量业务场景的AI替换优先级
架构设计得再漂亮，落到存量系统改造上，还是要一步一步来。我把培训系统里的AI需求按“改造成本”和“业务价值”两个维度做了个四象限评估，最终选了三个场景作为首期改造目标：课程资料智能摘要、培训智能问答、考题智能生成。
这三个场景有一个共同点：调用链路相对独立，不涉及复杂的事务一致性，适合作为AI能力接入的试点。改造它们可以把网关和适配层的核心链路完整跑通，同时业务上也能看到明显的效率提升。
没有一上来就碰那些跟核心业务强耦合的复杂场景，比如基于学员画像的个性化学习路径推荐，这类场景涉及的数据链路太长，如果网关能力还不够成熟，很容易把AI升级这件好事做成一场事故。
4.2 Spring AI在存量子系统里的角色
适配器层要对接各家模型，我一开始打算每个适配器都独立写一套HTTP调用逻辑，各家SDK实现各自的鉴权、重试、超时处理。写了个原型之后就放弃了——重复劳动太多，出错概率也高。
后来引入了Spring AI这个项目作为适配器层的底座。它提供了一套统一的API来对接不同的大模型供应商，内部抽象了ChatClient、EmbeddingClient等基础组件，并且支持通过配置切换不同厂商的实现。我在这套抽象之上再做一层更贴近培训业务语义的适配逻辑，整体代码干净了不少。
比较贴心的是Spring AI对主流的模型服务商都有现成支持，包括OpenAI、通义千问、文心一言等，也有针对Ollama这类本地模型的集成方案。对于我们这种需要经常在不同模型之间切换的存量系统来说，等于省掉了一半的适配开发量。
4.3 存量鉴权体系与网关的身份透传
老系统有自己的一套登录和权限体系，用户操作培训系统时已经带上了身份信息。AI能力网关在接收内部请求时，必须能把调用者的身份透传到业务后端，才能实现数据权限的管控。
我的方案是在网关内部建立了一套轻量级调用凭证机制。业务系统调用网关的时候，在请求头里带上内部签名的token，网关解析后提取用户身份和权限上下文，作为标准协议的context字段传入适配器。适配器在触发函数调用时，再把身份信息透传给内部服务，保证学员只能查询到自己权限范围内的数据。
这个设计避免了两套账号体系的重复建设，存量系统的改造面控制在“业务系统多签一次名”的范围内，不需要用户重新登录。
4.4 旧功能平滑过渡的发布策略
AI能力接入旧系统，最忌讳的是新旧逻辑并行时出现数据不一致。比如培训智能问答上线后，学员问了一堆问题，AI答错了，然后人工客服那边又记录了一条工单，两边就对不上账了。
我们采用了“灰度渐进”的发布策略：先放一部分测试学员账号走AI问答链路，同时保留原有人工客服入口；确认AI回答质量和稳定性达标后，再逐步扩大流量比例。人机协同的阶段，通过统一的消息表记录AI回答和人工介入的记录，等AI链路验证充分后再完全切换。
这个过程中，网关侧的情景管理（session、context、trace）起了大作用。每一条AI回答都能追溯到具体的模型调用链、token消耗和prompt版本，出了问题可以快速定位原因，而不是看着一堆日志无从下手。
5. 实施过程中踩过的几个硬坑
5.1 token计费模型与超时控制不能按传统思维设计
存量系统做AI接入，最容易忽略的问题是超时和计费。传统接口的超时设置几百毫秒到几秒就够，但大模型生成的响应时间天然较慢，尤其是复杂推理场景，动辄十几秒甚至几十秒。如果网关层沿用传统的快速失败策略，业务方会发现AI功能三天两头报超时。
我把网关的请求超时策略分成了三级：基础问答类接口容忍10-15秒，生成类任务（摘要、题目的批量生成）走异步任务模式，超时上限拉到60秒以上，真正耗时的任务干脆用消息队列异步化处理，前端展示“任务已提交，稍后查看结果”。
token消耗的统计也做了改造。旧系统没有这个概念，但AI功能上线后，每个能力调用的成本跟token数直接挂钩。网关里必须有统一的usage上报，按业务线、按能力维度统计每天的token消耗和费用预估。没有这套数据，月底看到云厂商账单的时候基本是崩溃的。
5.2 大模型的“幻觉”在业务侧需要兜底策略
培训系统是一个对内容准确性要求比较高的场景。AI生成的课程摘要如果存在错误，学员跟着错了，问题就大了。我见过不少团队在大模型落地时，把模型的输出当成“标准答案”直接展示给用户，这是很危险的做法。
我们的兜底策略分三层：第一层，提示词层面明确限制模型“不要编造数据”，没有把握的内容要明确说“不确定”；第二层，在适配层对生成结果做规则校验，比如摘要内容必须包含课程的核心知识点关键词，检测不到就重新生成或降级为抽取式摘要；第三层，在业务展示层增加“AI生成内容仅供参考”的标识，并接入学员的反馈机制，让人工审核兜底。
这个方案做不到100%防呆，但至少把“幻觉率”控制在了可接受的范围，还提升了系统的可问责性。
5.3 多模型切换演练不能只在预发环境做
适配层的价值是支持模型灵活切换，但切换这件事本身如果不演练，真到出故障的时候一定会手忙脚乱。我在上线后第二周，主动做了一次故障演练：把主模型的路由权重全部切到备选模型，让系统在“异常”情况下运行了整整一天。
结果发现了不少问题：备选模型的返回格式有差异，导致某个适配器解析报错；备选模型对同一个prompt的推理效果差异明显，业务侧反馈摘要质量下降了。这些问题在平时不会被发现，因为没有流量走到备选模型上。演习之后，我调整了备选模型的prompt模板，并把这种切换演练固化成每个月一次的常态运维动作。
5.4 数据缓存策略容易把简单问题搞复杂
大模型接口的响应时间远高于普通后端接口，所以一开始我想把AI回答缓存起来，相同问题不再重复请求模型。设计了一套基于相似度匹配的缓存方案，问题来了：学员问“怎么创建课程”和“如何创建培训课程”语义一样，但文本不一样，怎么判断命中缓存？
后来我用了向量相似度计算来做缓存键的模糊匹配，也就是把问题用embedding模型转成向量，缓存库里存向量和对应的回答，命中阈值设置成0.92。这套方案运行了一段时间，命中率大约能到20%到30%，对重复性较高的入门类问题效果明显。但注意，不能为了追求高命中率而把阈值调得太低，否则会出现语义相近但实际答案不同的场景被错误复用。
6. 培训场景里网关和适配层的实际落地效果
以课程摘要功能为例，之前的实现方式是培训专员手动编写课程要点，这门课有十几个章节，人工写摘要平均需要40到60分钟。接入AI能力网关后，由适配器调用多模态模型识别课件内容，再通过标准协议生成结构化摘要草稿，培训专员只需要花5到10分钟做审核微调，整体效率提升了约80%。
智能问答场景的价值更明显。老系统里学员遇到问题主要靠人工客服或者微信群提问，响应时间基本以小时计。接上AI问答后，高频问题大概90%都能由模型直接回答，平均响应时间降到秒级，而且回答内容还能附带课程对应章节的跳转链接，这个体验上的提升是肉眼可见的。这个功能的实现，依赖适配器里的function calling机制，模型必须能查询到课程章节的实时数据。
路由策略在实际运营中带来的成本优化也很可观。基础类问答默认路由到性价比更高的轻量模型，复杂推理任务才调用高端模型。经过一段时间的调优，同样的业务量，模型成本比一开始预期降低了接近四成。
7. 这套方案的后续演进方向
网关和适配层跑通之后，很多过去不敢想的业务应用开始变得可行了。比如智能学情分析、AI辅助课程设计、自动化试题评审，这些都已经有了初步的立项讨论。
我的计划是在网关层进一步沉淀统一的可观测体系，包括全链路的token追踪、prompt效果对比、模型质量评估。没有这些数据，后续的模型优化和供应商谈判都站不住脚。
在工具链层面，考虑引入AI辅助编程工具来提升存量系统的开发效率。老系统的改造是个持久战，光靠人工写代码推进速度太慢。不过引入这些工具之前，必须先把代码仓库的规范和权限管好，否则AI生成的代码混进来业务错误代码，排查成本反而更高。
再往下走，还有一个方向是把这些AI能力沉淀成内部的技术中台，让集团内部其他存量系统也能复用这套统一AI能力网关，而不是每个系统都从零开始对接各家大模型。这条路还长，但方向应该是没错的。
虽然现在这套方案还在持续打磨，但我个人最大的体会是：存量系统做AI升级，最难的不是模型选型，也不是prompt调优，而是想清楚怎么让AI能力变成一种规范化的基础设施，而不是散落在各个业务代码里的“一次性调用”。统一AI能力网关加适配层的路子，至少要能保证一点：明天出现一个更好的模型，我们有能力在不动业务的前提下平稳切过去。对做技术的人来说，这是一种很踏实的掌控感。
