1. 从一个尴尬的现场说起为什么“能跑”的AI应用总是活不过三个月我见过太多团队在AI项目上的起落。最典型的一幕是某个业务部门用两周时间搭出一个智能问答Demo演示当天效果惊艳领导拍板推广。三个月后这个应用悄无声息地下线了。原因不是模型不行而是当它要接入第三个业务系统、要支撑两百人同时使用、要保证回答里不出现越权数据时整个东西就散架了。这个场景暴露的问题跟模型能力强不强关系不大。真正缺的是一个AI应用底座。QuickBlue 就是冲着这个问题来的——它不是一个具体的AI功能而是一套让AI应用能够稳定生长、持续演进的底层支撑体系。你可以把它理解成盖楼时的地基和框架楼里装修成什么样可以随时改但承重结构必须一开始就立住。这篇文章适合三类人看正在做AI应用但被工程问题拖住的技术负责人、准备把AI能力接入现有业务系统的架构师、以及想搞清楚“AI应用底座”到底解决什么问题的开发者。我会把 QuickBlue 这类底座的核心构成、技术选型逻辑、以及实际落地时最容易踩的坑一条条拆开讲清楚。关键词里的微服务、Spring Cloud、JDK 21 这些不是堆砌的标签它们各自对应着底座要解决的具体工程问题后面会逐一对应上。先说结论AI应用底座要解决的核心矛盾是AI能力的快速迭代与企业系统的稳定性要求之间的冲突。模型版本一周一换但业务系统不能跟着一周一崩。底座的价值就是在这两者之间架一层缓冲和治理结构。2. QuickBlue 到底在解决什么把AI应用的“一次性”变成“可复用”2.1 没有底座时AI应用是怎么一步步失控的先看没有底座的典型路径。第一个AI功能上线团队直接写一个服务里面塞进模型调用、提示词拼接、结果解析、业务逻辑。能跑没问题。第二个功能来了复制一份改改。第三个功能要复用第一个功能里的用户权限判断于是把代码拷过去。到第五个功能时你发现同一个权限逻辑存在五份副本其中三份已经不一致了。更麻烦的是模型层。今天用A模型明天业务要求换成B模型做对比后天要加一个本地小模型做兜底。如果模型调用散落在各个业务服务里每次换模型就是一场全局搜索替换的噩梦。还有提示词——它们往往硬编码在代码里改一个标点都要重新发版。这就是“一次性”AI应用的宿命每个功能都是独立的孤岛孤岛之间靠复制粘贴连接。规模小的时候看不出问题一旦要横向扩展维护成本呈指数上升。2.2 底座思维把变化的部分和不变的部分分开QuickBlue 这类底座的核心思路是做一次彻底的关注点分离。把AI应用拆成几层每层只负责一件事层与层之间通过稳定的接口通信。最底层是基础设施层负责模型接入、算力调度、向量存储这些资源型能力。这一层的变化频率中等——换模型、加模型会发生但不会天天变。中间是能力编排层负责把模型能力、业务工具、知识库组合成可复用的“技能”。比如“查询订单并生成摘要”是一个技能“根据用户问题检索知识库并回答”是另一个技能。这一层变化频率最高因为业务需求总在调整。最上层是应用层面向具体场景比如客服助手、内部知识问答、文档审核。这一层应该尽可能薄只做场景适配和交互核心逻辑都沉在下面两层。这样分层之后换模型只动基础设施层调整业务逻辑只动编排层加一个新场景只动应用层。每一层的变更不会波及另外两层这就是底座带来的稳定性。2.3 为什么这件事非做不可三个绕不过去的现实约束第一个约束是成本。模型调用是要花钱的而且不同模型价格差异巨大。没有底座做统一的路由和缓存你根本不知道钱花在了哪里也没法做成本优化。QuickBlue 这类底座通常会内置调用计量和缓存机制相同的问题第二次问就不需要再调模型。第二个约束是合规与安全。企业数据不能随便喂给外部模型哪些数据能出、哪些不能出必须有一个统一的管控点。如果每个应用各自为政安全策略就是纸糊的。底座提供统一的数据脱敏和权限校验入口这是企业级应用的硬需求。第三个约束是可观测性。AI应用出问题时你需要知道是模型响应慢、提示词写错了、还是检索没召回正确文档。没有底座提供的链路追踪和日志聚合排查一个问题可能要翻五个服务的日志。微服务架构下的分布式追踪能力在这里不是锦上添花而是刚需。3. 拆开看骨架QuickBlue 底座里到底有哪些关键组件3.1 微服务拆分不是越细越好而是边界要准QuickBlue 采用微服务架构但微服务拆分有个常见的误区——很多人以为拆得越细越“架构先进”。实际恰恰相反拆得过细会导致服务间调用链路过长一个请求经过七八个服务延迟叠加不说排查问题也极其痛苦。合理的拆分边界应该围绕业务能力而不是技术分层。在AI应用底座里我倾向于这样划分服务边界服务模块职责变更频率模型网关服务统一模型接入、路由、限流、计量低编排引擎服务技能定义、流程编排、工具调用高知识库服务文档管理、向量化、检索中会话管理服务多轮对话状态、上下文窗口管理中权限与审计服务数据权限、操作审计、脱敏低应用接入服务对外API、场景适配高这个拆分的逻辑是变更频率相近的放在一起变更频率差异大的分开。模型网关和权限审计很少改独立出去编排和应用接入经常改独立部署互不影响。注意微服务拆分的第一原则是“高内聚低耦合”但第二原则往往被忽略——“部署独立性”。如果两个模块总是一起发版那它们就不该拆成两个服务。3.2 Spring Cloud 在底座里的角色不只是服务发现Spring Cloud 在 QuickBlue 这类底座中承担的是服务治理的基础设施角色。很多人对 Spring Cloud 的理解停留在“服务注册与发现”但实际上它在AI底座里有几个更关键的用途。配置中心让提示词、模型参数、路由规则这些高频变更的内容可以动态刷新不需要重启服务。这一点对AI应用特别重要因为提示词的调整频率远高于普通业务代码。网关层做统一的鉴权、限流、请求日志。AI应用的请求往往耗时较长模型推理需要时间网关的超时配置和熔断策略需要特别调整不能照搬普通微服务的配置。Sentinel 做流量控制这在AI场景下尤其必要。模型调用有并发上限超过之后要么排队要么降级。Sentinel 可以配置基于QPS的限流规则配合 Redis 集群做分布式限流保证不会因为突发流量把模型服务打垮。这里有个实操细节Sentinel 的规则如果只存在内存里服务重启就丢了。生产环境必须配置Sentinel Datasource 对接 Redis 集群做规则持久化。配置方式是在 Sentinel 控制台设置动态数据源指向 Redis规则变更后推送到所有实例。这个配置不做每次重启都要重新配规则运维会疯掉。3.3 JDK 21为什么底座要追新版本JDK 21 是 LTS 版本引入的虚拟线程Virtual Threads对AI应用底座来说是一个实质性利好。AI应用的请求模式是“大量并发、每个请求等待时间长”传统线程池模式下每个请求占一个线程线程数受限于操作系统并发上不去。虚拟线程让每个请求的线程开销降到极低可以轻松支撑数万并发。对于模型网关这种需要同时处理大量等待模型响应的服务来说虚拟线程带来的吞吐量提升是数量级的。当然追新版本也有代价。部分老旧的第三方库可能还没适配 JDK 21需要做兼容性验证。我的建议是底座的核心服务模型网关、编排引擎用 JDK 21边缘的、依赖复杂老库的服务可以暂时留在 JDK 17逐步迁移。4. 从零搭一个AI底座关键决策点和实操路径4.1 模型网关的设计统一入口是底线模型网关是整个底座最不能省掉的组件。它的核心职责是所有模型调用必须经过它不允许业务服务直接调模型API。为什么这条是底线因为一旦有服务绕过网关直接调模型你就失去了对模型调用的统一管控——计量、限流、缓存、降级全部失效。这就像公司规定所有采购必须走采购部但总有人自己下单最后账对不上。模型网关需要实现几个关键能力统一接口适配。不同模型的API格式不同网关要做一层适配对上暴露统一的调用接口。业务侧只关心“给我一个回答”不关心背后是哪个模型。路由策略。根据请求的类型、用户等级、成本预算把请求路由到不同的模型。简单问题走小模型复杂问题走大模型这是最基本的成本优化手段。缓存层。相同或相似的问题如果命中缓存就直接返回不调模型。缓存键的设计需要考虑提示词模板版本否则模板改了但缓存没失效会返回错误结果。降级与熔断。主模型不可用时自动切换到备用模型。备用模型的效果可能差一些但至少服务不中断。// 模型网关的核心路由逻辑示意简化版 public ModelResponse route(ModelRequest request) { // 1. 检查缓存 String cacheKey buildCacheKey(request); ModelResponse cached cacheService.get(cacheKey); if (cached ! null) { return cached; } // 2. 根据策略选择模型 String modelId routingStrategy.select(request); // 3. 调用模型带熔断保护 ModelResponse response circuitBreaker.executeSupplier( () - modelClient.invoke(modelId, request) ); // 4. 写入缓存 cacheService.put(cacheKey, response); return response; }4.2 编排引擎让业务人员也能调整AI行为编排引擎是底座里最“业务友好”的部分。它的目标是把AI能力的组合方式从代码里抽出来变成可配置的流程。一个典型的编排场景用户提问 → 判断问题类型 → 如果是订单问题调用订单查询工具 → 把查询结果和原始问题一起交给模型生成回答 → 返回。这个流程如果用代码写每次调整顺序都要改代码发版。用编排引擎业务人员可以在界面上拖拽调整。编排引擎的实现方式有多种轻量级的可以用 JSON 定义流程重量级的可以引入 BPMN 引擎。我的经验是AI场景下的编排不需要太复杂支持顺序、条件分支、并行调用这三种基本结构就覆盖了90%的场景。过度设计反而增加学习成本。4.3 知识库与向量检索RAG的工程化落地知识库是AI应用底座里技术栈最独立的一块。它涉及文档解析、分块、向量化、存储、检索这一整套流程每个环节都有坑。文档分块是最容易被低估的环节。分块太大检索精度下降分块太小上下文丢失。我的经验值是中文文档每块300到500字英文文档每块200到300词块之间保留10%到20%的重叠。这个参数没有绝对标准需要根据实际文档类型做A/B测试。向量模型的选择要考虑语言支持。有些向量模型对中文支持不好检索出来的结果相关性很差。选型时一定要用实际业务文档做召回测试不能只看 benchmark 分数。混合检索往往比纯向量检索效果好。向量检索擅长语义匹配但对精确的关键词匹配比如产品编号、人名可能漏掉。把向量检索和关键词检索的结果做融合排序召回率会明显提升。提示知识库的更新策略需要提前设计。是全量重建索引还是增量更新全量重建简单但耗时增量更新快但容易出不一致。我的建议是日常增量更新每周做一次全量重建兜底。5. 落地时最容易翻车的几个地方5.1 会话状态管理别把上下文塞进数据库就完事多轮对话的状态管理看起来简单——把历史消息存起来下次带上就行。但实际落地时会遇到几个问题。上下文窗口有限。模型能接受的 token 数是有上限的对话轮次多了之后历史消息会超出窗口。你需要一个策略来决定保留哪些历史是保留最近N轮还是做摘要压缩还是用向量检索召回相关历史。每种策略的效果和成本不同需要根据场景选择。并发会话的隔离。同一个用户可能在多个设备上同时对话会话状态需要正确隔离。如果会话ID设计不当可能出现A设备的对话串到B设备上。状态存储的性能。如果把每轮对话都写数据库高频对话场景下数据库压力会很大。通常的做法是热数据放 Redis冷数据定期归档到数据库。5.2 提示词版本管理改一个词可能毁掉整个功能提示词是AI应用的“源代码”但很多团队对它的管理极其随意——直接在生产环境改改完就生效没有版本记录没有回滚机制。我踩过的一个坑运营同事觉得回答太啰嗦在提示词里加了一句“请简洁回答”结果模型把一些必要的解释也省掉了用户投诉回答不完整。因为没有版本记录花了半天才定位到是提示词改动导致的。正确的做法是把提示词纳入版本管理每次修改记录变更内容、修改人、修改原因。上线新版本前做A/B测试确认效果后再全量。QuickBlue 这类底座通常会提供提示词管理模块支持版本、灰度、回滚。5.3 模型输出的不确定性你的系统准备好接住“意外”了吗模型输出是概率性的同样的输入可能得到不同的输出。这意味着你的下游系统不能假设输出格式永远正确。最常见的翻车场景是你要求模型返回 JSON 格式大部分时候它确实返回 JSON但偶尔会多一句解释文字导致 JSON 解析失败。如果你的代码没有做容错处理整个请求就挂了。防御措施有三层第一在提示词里明确格式要求并给出示例第二解析时做容错比如用正则提取 JSON 部分第三解析失败时走降级逻辑比如返回默认值或转人工。三层都做上才能保证系统稳定。5.4 成本失控看不见的账单最可怕AI应用的成本结构和传统应用完全不同。传统应用的成本主要是服务器相对固定。AI应用的成本和调用量直接挂钩一次流量高峰可能带来意想不到的账单。我见过一个案例某个内部工具没有做限流一个员工写了个脚本循环调用一天之内消耗了平时一个月的模型调用量。因为没有实时监控和告警等到发现时已经晚了。底座必须内置成本监控按应用、按用户、按模型维度统计调用量和费用设置预算阈值和告警。超过阈值时自动限流或降级。这不是可选项是必选项。6. 这套底座适合谁不适合谁QuickBlue 这类AI应用底座不是万能药它有明确的适用边界。适合的场景企业内有多个AI应用需求需要统一管控模型调用对数据安全和合规有要求需要统一的权限和审计AI应用需要与现有业务系统深度集成团队有一定微服务基础能维护分布式系统。不太适合的场景只有一个简单的AI功能且短期没有扩展计划团队规模很小没有专职运维对响应延迟极度敏感无法接受网关带来的额外跳转通常几毫秒但极端场景下需要考虑。如果你属于前者底座带来的长期收益远大于初期的搭建成本。如果你属于后者直接写一个单体服务可能更务实。架构决策没有绝对的对错只有适不适合当前的阶段。我在实际项目中的体会是底座的价值在第二个、第三个AI应用接入时才会真正显现。第一个应用时你会觉得底座是负担第二个应用时你会庆幸有底座第三个应用时没有底座你根本不敢接。所以判断要不要上底座不要看现在有几个应用要看半年后预计有几个。