★ FEATURED ARTICLE 1. 从一次内部技术评审说起QuickBlue 到底想解决什么问题去年年底我参加了一场内部技术评审议题是“业务团队到底该不该自己搭 AI 应用”。会上有个做供应链的团队负责人吐槽他们花了三周时间用各种开源框架拼出了一套“智能问答文档解析”的服务结果上线第二天就发现模型调用超时没人管、会话上下文丢失、权限体系跟公司主账号完全对不上。更麻烦的是隔壁另一个团队也在做几乎一模一样的事情只是换了个模型供应商代码却完全没法复用。这个场景我猜很多做企业级开发的人都遇到过。单个 AI 功能做出来不难难的是把它变成可复用、可治理、可观测的基础能力。QuickBlue 就是在这个背景下进入我视野的——它把自己定位成“AI 应用底座”而不是又一个 AI 应用。这两个词差别很大应用是给最终用户用的底座是给开发和运维团队用的。先把概念说清楚。QuickBlue 是一套面向企业内部的 AI 应用基础框架核心目标是把模型接入、会话管理、提示词编排、权限控制、调用审计、成本统计这些“每个 AI 应用都要做一遍”的事情收敛成一套标准化的底层服务。业务团队只需要关注自己的业务逻辑和提示词剩下的脏活累活交给底座。它适合谁我认为三类人最该关注一是正在被多个业务团队重复造轮子的平台架构师二是想快速验证 AI 场景但不想陷进基础设施泥潭的业务开发三是需要统一管控模型调用成本和数据流向的技术管理者。为什么现在这个时间点特别需要它因为企业 AI 落地已经从“能不能做出来”进入“能不能管得住”的阶段。早期大家比的是谁先跑通 Demo现在比的是谁能把几十个 AI 功能稳定地跑在生产环境里还不失控。QuickBlue 这类底座的本质就是把 AI 能力从“手工作坊”推向“流水线生产”。2. 拆解“AI 应用底座”这个定位它和普通框架差在哪2.1 底座不是框架是能力收敛层很多人第一次听到“AI 应用底座”会下意识觉得又是一个开发框架。我的理解是框架解决的是“怎么写代码”底座解决的是“怎么让一堆代码协同工作并且被管理”。这两者的抽象层级不一样。举个具体例子。你用某个流行的 AI 开发框架写一个对话接口框架帮你处理了模型调用的参数拼装和流式返回。但当你公司有 20 个这样的接口时问题就来了这 20 个接口分别调用了哪些模型每个月的 token 消耗是多少有没有人把敏感数据发给了外部模型某个模型供应商挂了能不能自动切到备用这些问题框架不管底座必须管。QuickBlue 的设计思路就是把“横切关注点”全部上提。所谓横切关注点就是那些跟具体业务无关、但每个业务都要处理的事情。我整理了一张对比表能比较清楚地看出底座和普通框架的分工差异关注点普通 AI 框架QuickBlue 底座模型调用提供 SDK 封装统一网关多模型路由与降级会话管理需自行实现内置会话存储与上下文策略权限控制基本不涉及对接企业账号体系细粒度授权成本统计无按应用/团队/模型多维统计调用审计无全链路日志与合规留痕提示词管理代码里硬编码集中管理支持版本与灰度这张表里最关键的一行其实是“提示词管理”。我见过太多团队把提示词直接写在代码里改一个标点都要重新发版。底座把提示词抽出来集中管理之后运营人员都能参与优化迭代速度完全不是一个量级。2.2 为什么企业不能继续“每个团队自己搭”我算过一笔账。一个中等规模的业务团队从零搭建一套能上生产的 AI 服务包括模型接入、会话存储、权限对接、日志监控、成本统计保守估计需要 2 到 3 个后端工程师投入 4 到 6 周。如果有 10 个团队都要做那就是 80 到 180 人周。而其中 70% 的工作是重复的。更隐蔽的代价是治理成本。当每个团队用自己的方式调用模型技术管理者根本拿不到全局视图。哪个模型最贵、哪个应用调用量异常、哪些数据流出去了全是黑盒。等到出问题再回头排查成本比一开始就统一高得多。QuickBlue 这类底座的价值就在于把边际成本压下来。第一个接入的团队可能还要花点时间理解底座的使用方式但从第二个团队开始接入成本会急剧下降因为模型接入、权限、审计这些都已经现成了。这就是典型的平台效应前期投入大后期边际成本趋近于零。2.3 底座的核心能力清单结合我对 QuickBlue 的了解和同类产品的观察一个合格的 AI 应用底座至少要具备这几块能力我按重要性排个序统一模型网关屏蔽不同模型供应商的接口差异支持路由、降级、限流。这是最基础的一块没有它后面都无从谈起。会话与上下文管理多轮对话的状态存储、上下文窗口裁剪策略、会话隔离。这块直接决定用户体验。提示词编排与版本管理把提示词当配置管理支持变量注入、版本回滚、A/B 测试。权限与租户隔离对接企业统一账号做到应用级、团队级、数据级的隔离。可观测与成本统计调用链路追踪、token 消耗统计、异常告警。安全与合规敏感信息过滤、内容审核、调用留痕。这六块能力里我认为最容易被低估的是“会话与上下文管理”。很多团队觉得存个对话历史很简单但真到了生产环境上下文窗口怎么裁剪、多轮对话怎么保持一致性、会话数据怎么按租户隔离全是坑。QuickBlue 把这块做成标准能力省下的不只是代码量更是踩坑的时间。3. 技术栈选型背后的逻辑JDK 21、Spring Cloud 2025 与 Vite 83.1 JDK 21为什么底座必须吃上虚拟线程QuickBlue 选择 JDK 21 作为运行时基线这个决定我认为非常关键值得单独说说。JDK 21 是 LTS 版本最大的亮点是虚拟线程正式转正。对于 AI 应用底座这种 IO 密集型场景虚拟线程带来的收益是实打实的。传统平台线程模型下一个线程对应一个操作系统线程创建成本高、数量有限。AI 应用的特点是大量时间花在等待模型响应上一个请求可能阻塞几秒甚至几十秒。如果用传统线程池几百个并发请求就能把线程池打满后面的请求只能排队。虚拟线程把“等待”这件事的成本降到了极低同样一台机器能支撑的并发数提升一个数量级。我做过一个粗略的压测对比同样是等待模型返回的场景线程模型并发 500 请求并发 2000 请求内存占用传统平台线程响应正常线程池接近满大量请求排队超时高虚拟线程响应正常响应正常延迟略增低这个对比不是说虚拟线程万能而是说在 AI 这种“等得多、算得少”的场景里它几乎是量身定做的。QuickBlue 把 JDK 21 作为基线等于强制所有接入方享受这个红利也避免了团队之间运行时版本碎片化。注意虚拟线程虽好但不要在里面做 CPU 密集计算也不要滥用 synchronized 导致载体线程被钉住。底座层面通常会把这些约束封装好但业务代码里还是要留意。3.2 Spring Cloud 2025微服务治理的成熟选择底座本身是个分布式系统模型网关、会话服务、权限服务、统计服务大概率是分开部署的。Spring Cloud 2025 提供的是服务发现、配置中心、熔断限流、网关路由这一整套微服务治理能力。为什么不用更轻量的方案因为企业级底座面对的是多团队、多环境、多版本的复杂局面。配置要能动态刷新服务要能优雅上下线某个模型供应商挂了要能自动熔断这些需求 Spring Cloud 生态都有成熟组件对应。选它的核心逻辑是“不重复造轮子”把精力留给 AI 特有的能力建设。Spring Cloud 2025 跟 JDK 21 的配合也比较顺虚拟线程在 Web 容器和 HTTP 客户端层面都有支持。底座里的模型调用本质上就是 HTTP 请求用虚拟线程 响应式客户端能把等待模型响应这段时间的资源占用压到最低。3.3 Vite 8前端控制台的构建提速QuickBlue 会有一个管理控制台用来配置模型、管理提示词、查看统计。前端选 Vite 8 作为构建工具理由很直接快。底座的开发迭代频率不低尤其是控制台这种交互密集的部分改一行代码等十几秒编译是折磨。Vite 基于原生 ES 模块的开发服务器冷启动基本是秒级热更新几乎是即时的。Vite 8 在构建产物优化和依赖预构建上又做了改进生产构建的体积和速度都有提升。对于底座这种“后端重、前端也不轻”的项目前端构建速度直接影响开发体验。我自己的经验是构建工具从传统打包器换到 Vite 之后日常开发的等待时间能减少一半以上这个收益在长期项目里非常可观。3.4 三者的协同关系把这三个技术点串起来看逻辑就很清楚了JDK 21 提供高并发运行时基础Spring Cloud 2025 提供分布式治理能力Vite 8 提供高效的前端开发体验。它们分别对应底座的运行时、服务层和控制台三个层面选型上互相不冲突而且都指向同一个目标——让底座本身足够稳、足够快、足够好维护。4. 实操从零接入 QuickBlue 底座的完整流程4.1 环境准备与依赖确认假设你所在的企业已经部署好了 QuickBlue 底座服务现在你要把一个业务应用接进去。第一步是确认环境。# 确认 JDK 版本必须是 21 及以上 java -version # 期望输出类似openjdk version 21.0.x # 确认 Maven 版本 mvn -version依赖方面底座通常会提供一个 SDK starter你只需要在项目里引入它而不是手动拼装各种客户端。这是底座设计的典型思路把复杂性封装在 starter 里业务方一行依赖搞定。dependency groupIdcom.quickblue/groupId artifactIdquickblue-spring-boot-starter/artifactId version1.0.0/version /dependency引入之后在配置文件里填上底座的服务地址和应用标识。应用标识很重要它是后续权限、统计、审计的维度。quickblue: endpoint: http://quickblue-gateway.internal:8080 app-id: supply-chain-assistant app-secret: ${QUICKBLUE_APP_SECRET}提示app-secret 千万不要硬编码在配置文件里提交到代码仓库用环境变量或配置中心注入。我见过不止一个团队把密钥直接写进 yml 然后推到了公共仓库。4.2 模型接入与路由配置底座的核心价值之一就是模型接入的标准化。你不需要关心底层用的是哪家模型只需要在底座控制台配置好模型供应商和路由规则业务代码里统一调用底座的接口。配置模型路由时我建议按“场景”而不是按“模型”来组织。比如定义一个叫chat-default的路由背后可以挂主模型和备用模型主模型超时或报错时自动降级到备用。这样业务代码里只认chat-default模型切换对业务完全透明。// 业务代码里只依赖底座的统一客户端 Autowired private QuickBlueClient quickBlueClient; public String chat(String userInput) { ChatRequest request ChatRequest.builder() .routeKey(chat-default) // 路由键不是具体模型名 .sessionId(currentSessionId) .userInput(userInput) .build(); return quickBlueClient.chat(request).getContent(); }这里的关键设计是routeKey。业务方永远不直接指定模型名模型的选择、切换、降级全部由底座的路由策略决定。这样做的好处是当某个模型涨价或者下线时底座管理员改一下路由配置就行业务代码一行都不用动。4.3 会话与上下文管理多轮对话的上下文管理是很多团队自己实现时最容易出问题的地方。QuickBlue 把这块做成了标准能力你只需要传sessionId底座负责存储和裁剪上下文。上下文裁剪策略通常有几种按轮数裁剪、按 token 数裁剪、按时间窗口裁剪。我一般推荐按 token 数裁剪因为它直接对应模型的上下文窗口限制最不容易出问题。假设模型上下文窗口是 8K token系统提示词占了 500那留给历史对话的就是 7500 左右底座会自动把最早的消息挤出去。// 会话创建底座返回 sessionId String sessionId quickBlueClient.createSession( SessionCreateRequest.builder() .appId(supply-chain-assistant) .userId(currentUserId) .contextStrategy(ContextStrategy.TOKEN_LIMIT) .maxTokens(7500) .build() );注意会话数据涉及用户隐私底座通常会做加密存储和租户隔离。但业务方也要注意不要把不该进上下文的数据塞进去比如完整的身份证号、银行卡号。底座有敏感信息过滤但过滤规则需要你主动配置。4.4 提示词编排与版本管理把提示词从代码里抽出来是底座带来的最大效率提升之一。在 QuickBlue 控制台里你可以为每个应用维护多套提示词模板支持变量占位符和版本管理。你是一个供应链助手当前用户是 {{userName}} 所在部门是 {{department}}。 请基于以下知识库内容回答问题 {{knowledgeContext}} 用户问题{{userInput}}业务代码里只需要传变量模板由底座渲染。这样做的好处是运营和产品同学可以直接在控制台调整提示词改完即时生效不需要开发介入发版。我实测下来这个能力让提示词的迭代周期从“天”缩短到了“分钟”。版本管理也很实用。你可以给提示词打版本标签新版本先灰度给 10% 的流量观察效果再全量。出问题了直接回滚到上一个版本比代码回滚快得多。4.5 权限对接与租户隔离企业环境里AI 应用必须跟统一账号体系打通。QuickBlue 通常支持对接主流的身份认证协议把企业账号体系里的用户、角色、组织架构同步过来。权限控制我建议做到应用级和数据级两层。应用级控制谁能访问哪个 AI 应用数据级控制谁能看到哪些会话和统计。比如财务部门的 AI 助手普通员工只能用自己的会话部门管理员能看部门汇总只有平台管理员能看全局。// 底座在网关层做权限校验业务代码里可以直接拿当前用户上下文 UserContext user QuickBlueContext.getCurrentUser(); if (!user.hasPermission(supply-chain:chat)) { throw new AccessDeniedException(无权访问该应用); }租户隔离是另一个容易被忽视的点。如果底座服务多个业务线会话数据、提示词、统计报表都要按租户隔离不能串。底座一般通过 appId 和 tenantId 双重维度来做隔离业务方接入时要确保这两个标识配置正确。5. 常见问题与排查技巧实录5.1 模型调用超时与降级失效这是接入底座后最常遇到的问题。表现是业务侧报超时但底座日志显示模型其实返回了只是慢。排查思路分三步先看是不是模型本身慢再看是不是网络链路问题最后看降级策略有没有生效。我整理了一个速查表现象可能原因排查方法解决方向偶发超时模型供应商抖动看底座模型调用耗时分布配置合理的超时和重试持续超时网络或网关问题检查底座到模型的链路联系底座运维降级不生效路由策略配置错误检查 routeKey 对应策略修正降级规则降级后仍报错备用模型也异常查看备用模型状态增加多级降级我的经验是超时时间不要设得太短。AI 模型生成一段长文本十几秒很正常。设个 3 秒超时那基本每次都会触发降级。一般对话场景设 30 秒复杂推理场景设 60 秒比较合理。5.2 上下文丢失与串话上下文丢失的典型表现是用户明明上一轮说了自己的名字下一轮模型却问“您怎么称呼”。这通常是 sessionId 没有正确传递或者会话存储出了问题。串话更严重表现为 A 用户看到了 B 用户的对话内容。这基本可以断定是租户隔离或会话隔离配置有问题。排查时重点看 sessionId 的生成规则和存储的隔离维度。提示sessionId 一定要跟 userId 绑定校验不能只靠 sessionId 查会话。否则一旦 sessionId 泄露或被猜到就会造成越权访问。5.3 成本统计对不上账成本统计对不上一般是统计口径的问题。要确认几个点统计的是输入 token 还是输出 token还是两者都算是否包含了失败请求的消耗不同模型的计价单位是否统一。我建议底座的成本统计至少做到三个维度按应用、按团队、按模型。这样既能看总账也能定位到具体是谁在用、用在哪。如果发现某个应用成本异常高先看是不是提示词太长导致输入 token 暴涨这是最常见的原因。5.4 提示词版本回滚后不生效提示词回滚后不生效八成是缓存问题。底座为了性能通常会缓存提示词模板回滚后缓存没刷新就会继续用旧版本。解决办法是回滚操作触发缓存失效或者等缓存自然过期。另一个可能是灰度规则没清干净。如果之前配了灰度回滚时只回滚了模板没清灰度规则那部分流量还是会走到旧逻辑。回滚时一定要把灰度规则一起处理掉。5.5 虚拟线程相关的坑用了 JDK 21 虚拟线程之后有几个坑要特别注意。一是不要在虚拟线程里用 synchronized 包住阻塞操作会导致载体线程被钉住虚拟线程的优势就没了。二是 ThreadLocal 在虚拟线程里行为有变化如果底座或业务代码依赖 ThreadLocal 传上下文要改成用底座提供的上下文传递机制。我踩过的一个坑是某个老版本的数据库连接池对虚拟线程支持不好导致连接泄漏。后来升级了连接池版本才解决。所以用虚拟线程时要确认所有依赖的中间件客户端都支持。6. 底座落地的一些个人体会接入 QuickBlue 这类底座技术上其实不难难的是组织和习惯的转变。我见过团队把底座接进去了但提示词还是写在代码里模型还是直接调供应商接口等于白接。底座的价值只有在“真的用起来”之后才能体现。我的建议是接入初期就定好规矩所有模型调用必须走底座网关所有提示词必须进控制台管理所有会话必须用底座的会话服务。一开始可能会觉得麻烦但坚持一两个月等你要做成本分析、要切换模型、要排查问题的时候就会庆幸当初没偷懒。另外底座的选型不要只看功能清单要看它的扩展性。企业需求变化很快今天用这家模型明天可能就要换今天只要对话明天可能就要加知识库检索。底座如果扩展性不好每次加需求都要改底座本身那就失去意义了。QuickBlue 在这方面的设计思路是把模型接入、提示词、会话都做成可插拔的这个方向是对的。最后分享一个我自己的小技巧接入底座后先拿一个非核心的小应用试水跑通全流程把权限、统计、审计这些边角都验证一遍再推广到核心业务。这样风险可控也能积累经验。直接拿核心业务上出了问题影响面太大。
阅读完成 · 觉得有帮助？
