1. 從一堆散裝AI腳本到統(tǒng)一底座我為什么開始關(guān)注QuickBlue去年下半年我陸續(xù)幫三四個(gè)團(tuán)隊(duì)做過AI功能的落地。場(chǎng)景各不相同有的是給客服系統(tǒng)加智能問答有的是給內(nèi)部知識(shí)庫(kù)做語義檢索還有的是給業(yè)務(wù)系統(tǒng)嵌一個(gè)文檔摘要模塊。按理說這些需求都不算復(fù)雜但真正動(dòng)手之后我發(fā)現(xiàn)每個(gè)團(tuán)隊(duì)踩的坑幾乎一模一樣模型調(diào)用散落在各個(gè)業(yè)務(wù)代碼里密鑰硬編碼在配置文件中提示詞版本混亂換個(gè)模型要改十幾處地方上線之后連個(gè)統(tǒng)一的調(diào)用日志都找不到。這種狀態(tài)下AI功能不是能力而是負(fù)債。你每加一個(gè)AI場(chǎng)景就多一份維護(hù)成本。后來我開始琢磨能不能把這些共性的東西抽出來做成一個(gè)統(tǒng)一的接入層讓業(yè)務(wù)團(tuán)隊(duì)只管我要什么能力而不用管模型怎么調(diào)、密鑰怎么管、流量怎么控。這個(gè)思路就是現(xiàn)在大家說的AI應(yīng)用底座。QuickBlue 這個(gè)項(xiàng)目正是在這個(gè)背景下進(jìn)入我視野的。它定位為一個(gè)面向企業(yè)的AI應(yīng)用底座把模型接入、能力編排、權(quán)限管控、可觀測(cè)性這些臟活累活收攏到一層業(yè)務(wù)側(cè)通過標(biāo)準(zhǔn)接口調(diào)用。關(guān)鍵詞里出現(xiàn)的微服務(wù)、JDK 21、Spring Cloud說明它不是一個(gè)小玩具而是奔著企業(yè)級(jí)分布式架構(gòu)去的。這篇文章我不打算寫成產(chǎn)品說明書而是想從一個(gè)一線從業(yè)者的角度把AI應(yīng)用底座到底解決什么問題QuickBlue這類項(xiàng)目?jī)?nèi)部大概怎么搭落地時(shí)會(huì)遇到哪些坑這幾件事講透。如果你正在糾結(jié)要不要給團(tuán)隊(duì)引入一層AI底座或者你已經(jīng)在做類似的事情這篇應(yīng)該能幫你少走點(diǎn)彎路。2. AI應(yīng)用底座到底在解決什么拆開散裝AI的五個(gè)痛點(diǎn)2.1 模型調(diào)用散落改一個(gè)參數(shù)要翻遍整個(gè)代碼庫(kù)先說最直觀的問題。我見過一個(gè)項(xiàng)目光是調(diào)用大模型的地方就有十七處分布在六個(gè)微服務(wù)里。每處都自己new一個(gè)HTTP客戶端自己拼請(qǐng)求體自己處理超時(shí)。后來廠商調(diào)整了接口的字段名整個(gè)團(tuán)隊(duì)花了兩天才改完還漏了一處線上報(bào)錯(cuò)才發(fā)現(xiàn)。AI應(yīng)用底座的第一層價(jià)值就是把模型調(diào)用收斂成統(tǒng)一出口。業(yè)務(wù)代碼不再直接面對(duì)模型廠商的SDK而是調(diào)用底座暴露的標(biāo)準(zhǔn)接口。模型換了、參數(shù)變了、廠商切了業(yè)務(wù)側(cè)無感知。這跟當(dāng)年我們做支付系統(tǒng)時(shí)把各家支付渠道封裝成統(tǒng)一網(wǎng)關(guān)是一個(gè)道理——變化被擋在底座內(nèi)部業(yè)務(wù)只依賴穩(wěn)定契約。2.2 密鑰與配額失控誰在什么時(shí)候調(diào)了多少?zèng)]人說得清第二個(gè)痛點(diǎn)是治理。模型調(diào)用是要花錢的而且不同團(tuán)隊(duì)、不同場(chǎng)景的用量差異極大。如果沒有統(tǒng)一管控很容易出現(xiàn)某個(gè)測(cè)試環(huán)境瘋狂調(diào)用把配額跑光或者某個(gè)離職同事的密鑰還在被使用。底座需要提供的能力包括密鑰集中托管、按租戶/應(yīng)用/用戶維度的配額限制、調(diào)用量統(tǒng)計(jì)與告警。這些在傳統(tǒng)微服務(wù)里是標(biāo)準(zhǔn)配置但很多團(tuán)隊(duì)做AI功能時(shí)完全沒考慮等到賬單出來才傻眼。QuickBlue 這類底座把這塊做成基礎(chǔ)設(shè)施業(yè)務(wù)側(cè)接入即獲得治理能力不用各自造輪子。2.3 提示詞版本混亂改了效果變差回滾都找不到舊版本提示詞工程現(xiàn)在越來越像代碼工程但很多團(tuán)隊(duì)還停留在在代碼里寫死一個(gè)字符串的階段。改了一版提示詞效果變差想回滾卻發(fā)現(xiàn)舊版本沒存。更麻煩的是同一個(gè)能力在不同服務(wù)里各寫一份提示詞改了一處忘了另一處行為不一致。底座通常會(huì)提供提示詞模板管理模板獨(dú)立于代碼存儲(chǔ)支持版本、支持灰度、支持按場(chǎng)景綁定。業(yè)務(wù)側(cè)傳參底座負(fù)責(zé)渲染。這樣提示詞的迭代就和代碼發(fā)布解耦了運(yùn)營(yíng)同學(xué)甚至可以在不改代碼的情況下調(diào)優(yōu)。2.4 缺乏可觀測(cè)性出了問題只能靠猜AI調(diào)用和普通接口調(diào)用有個(gè)很大區(qū)別它的輸出是不確定的延遲波動(dòng)大失敗原因五花八門限流、超時(shí)、內(nèi)容審核攔截、模型自身異常。如果沒有完整的調(diào)用鏈路追蹤排查問題基本靠猜。底座需要把每次調(diào)用的輸入、輸出、耗時(shí)、token消耗、命中的模型版本、失敗原因都記錄下來并且能和業(yè)務(wù)側(cè)的請(qǐng)求鏈路關(guān)聯(lián)。這塊做得好不好直接決定了你線上出問題時(shí)是十分鐘定位還是十小時(shí)定位。2.5 能力無法復(fù)用每個(gè)團(tuán)隊(duì)都在重復(fù)造輪子最后一個(gè)也是最隱蔽的痛點(diǎn)。A團(tuán)隊(duì)做了文檔摘要B團(tuán)隊(duì)也要做于是B團(tuán)隊(duì)從頭再來一遍。C團(tuán)隊(duì)做了敏感詞過濾D團(tuán)隊(duì)不知道又做了一套。企業(yè)內(nèi)部的AI能力沒有沉淀每次都是新起點(diǎn)。底座的核心使命之一就是能力沉淀與復(fù)用。把通用的AI能力摘要、分類、抽取、問答、改寫做成可被復(fù)用的服務(wù)新場(chǎng)景直接編排組合而不是從零開發(fā)。這才是底座兩個(gè)字真正的分量。3. QuickBlue的架構(gòu)骨架微服務(wù)、JDK 21與Spring Cloud怎么組合3.1 為什么是微服務(wù)而不是單體有人會(huì)問一個(gè)AI接入層搞成微服務(wù)是不是過度設(shè)計(jì)我的判斷是取決于規(guī)模。如果只是三五個(gè)場(chǎng)景、一個(gè)團(tuán)隊(duì)用單體完全夠。但企業(yè)級(jí)底座面對(duì)的是多團(tuán)隊(duì)、多租戶、多模型、高并發(fā)單體很快會(huì)變成瓶頸。微服務(wù)化帶來的好處很實(shí)際模型接入服務(wù)可以獨(dú)立擴(kuò)容它是最耗資源的治理服務(wù)可以獨(dú)立部署它最需要穩(wěn)定性能力編排服務(wù)可以獨(dú)立迭代它變化最快。故障隔離也更清晰——某個(gè)模型廠商掛了不至于拖垮整個(gè)底座。QuickBlue 選擇微服務(wù)路線本質(zhì)上是為企業(yè)級(jí)這三個(gè)字買單。代價(jià)是運(yùn)維復(fù)雜度上升所以它必須依賴成熟的微服務(wù)生態(tài)來兜底這就引出了 Spring Cloud。3.2 JDK 21帶來的實(shí)際收益關(guān)鍵詞里特意點(diǎn)了 JDK 21這不是隨便選的。JDK 21 是 LTS 版本對(duì)這類IO密集型的底座服務(wù)來說有幾個(gè)實(shí)打?qū)嵉暮锰?。虛擬線程是最大的亮點(diǎn)。AI調(diào)用本質(zhì)上是大量等待外部響應(yīng)的IO操作傳統(tǒng)線程池模式下線程數(shù)就是并發(fā)上限線程被阻塞時(shí)資源白白浪費(fèi)。虛擬線程讓一個(gè)請(qǐng)求一個(gè)線程的模型重新變得可行吞吐量提升明顯代碼還不用改成響應(yīng)式那套復(fù)雜寫法。我實(shí)測(cè)過類似的場(chǎng)景在IO等待占比高的服務(wù)里虛擬線程能把吞吐拉高一個(gè)量級(jí)而代碼幾乎不用動(dòng)。另外 JDK 21 在 ZGC、模式匹配、記錄類等方面的成熟也讓底座這種需要長(zhǎng)期運(yùn)行、頻繁處理結(jié)構(gòu)化數(shù)據(jù)的服務(wù)受益。選 LTS 版本做底座是穩(wěn)妥的做法。3.3 Spring Cloud在底座里的角色分工Spring Cloud 在 QuickBlue 里承擔(dān)的是分布式基礎(chǔ)設(shè)施的角色具體分工大致是這樣關(guān)注點(diǎn)典型組件在底座中的作用服務(wù)注冊(cè)發(fā)現(xiàn)Nacos / Consul各微服務(wù)互相找到對(duì)方配置管理Nacos Config模型參數(shù)、限流閾值動(dòng)態(tài)下發(fā)網(wǎng)關(guān)Spring Cloud Gateway統(tǒng)一入口、鑒權(quán)、路由熔斷限流Sentinel保護(hù)底座不被突發(fā)流量打垮鏈路追蹤Sleuth / Micrometer Tracing串聯(lián)業(yè)務(wù)請(qǐng)求與AI調(diào)用這里有個(gè)現(xiàn)實(shí)問題必須提Spring Cloud Alibaba 的部分組件已經(jīng)進(jìn)入維護(hù)模式甚至停更這是很多團(tuán)隊(duì)選型時(shí)的糾結(jié)點(diǎn)。我的建議是底座這種長(zhǎng)生命周期的基礎(chǔ)設(shè)施選型要看兩件事——社區(qū)是否活躍、是否有可替代方案。注冊(cè)配置中心可以考慮 Nacos 的持續(xù)版本或 Consul熔斷限流 Sentinel 依然可用但要關(guān)注替代品如 Resilience4j。不要因?yàn)槟硞€(gè)組件曾經(jīng)很火就無腦綁定底座是要用三五年的東西。3.4 一張我理解的底座分層圖雖然不能畫圖但我可以用文字把 QuickBlue 這類底座的分層講清楚從上到下大致是四層接入層網(wǎng)關(guān)、鑒權(quán)、租戶識(shí)別、限流。所有外部請(qǐng)求從這里進(jìn)。能力層能力編排、提示詞渲染、模型路由。業(yè)務(wù)要的摘要問答在這里被組裝出來。模型接入層對(duì)接各家模型廠商統(tǒng)一協(xié)議、統(tǒng)一錯(cuò)誤碼、統(tǒng)一重試策略。治理與觀測(cè)層貫穿所有層的配額、計(jì)費(fèi)、日志、追蹤、告警。業(yè)務(wù)團(tuán)隊(duì)通常只接觸接入層和能力層下面兩層對(duì)他們是透明的。這個(gè)分層的關(guān)鍵在于邊界清晰模型接入層的變化不會(huì)泄漏到能力層能力層的變化不會(huì)影響接入層的契約。4. 落地一個(gè)AI底座我在實(shí)操中踩過的坑4.1 統(tǒng)一協(xié)議這件事比想象中難理論上把所有模型調(diào)用抽象成一個(gè)統(tǒng)一接口很美好。實(shí)操中你會(huì)發(fā)現(xiàn)不同廠商的能力差異很大有的支持流式輸出有的不支持有的有function call有的沒有有的按token計(jì)費(fèi)有的按調(diào)用次數(shù)。你想用一個(gè)接口覆蓋所有要么接口設(shè)計(jì)得極其復(fù)雜要么就得做能力降級(jí)。我的經(jīng)驗(yàn)是核心接口保持最小公約數(shù)高級(jí)能力用擴(kuò)展字段或獨(dú)立接口。比如基礎(chǔ)的文本生成接口只保證輸入文本、輸出文本、超時(shí)、重試這些通用能力流式、function call 這些做成可選能力調(diào)用方按需聲明。不要試圖設(shè)計(jì)一個(gè)萬能接口那是災(zāi)難的開始。4.2 流式輸出與微服務(wù)的兼容問題流式輸出SSE在單體應(yīng)用里很簡(jiǎn)單但在微服務(wù)網(wǎng)關(guān)的架構(gòu)下會(huì)碰到麻煩。網(wǎng)關(guān)默認(rèn)可能緩沖響應(yīng)導(dǎo)致流式變成攢一波再發(fā)用戶體驗(yàn)全無。Nginx、Spring Cloud Gateway 都需要專門配置才能正確透?jìng)髁魇巾憫?yīng)。我踩過的坑是本地測(cè)試一切正常上了網(wǎng)關(guān)就變成一次性返回。排查了半天才發(fā)現(xiàn)是網(wǎng)關(guān)的緩沖配置。所以底座在設(shè)計(jì)流式能力時(shí)必須把網(wǎng)關(guān)配置納入部署清單并且要有專門的端到端測(cè)試用例覆蓋流式場(chǎng)景不能只測(cè)單服務(wù)。4.3 配額統(tǒng)計(jì)的精度與性能矛盾配額限制要求實(shí)時(shí)準(zhǔn)確但每次調(diào)用都去數(shù)據(jù)庫(kù)扣減配額在高并發(fā)下數(shù)據(jù)庫(kù)直接被打爆。這是個(gè)經(jīng)典難題。常見的解法是分層統(tǒng)計(jì)本地內(nèi)存做粗粒度計(jì)數(shù)定期匯總到RedisRedis再異步落庫(kù)。允許一定時(shí)間窗口內(nèi)的誤差換取性能。但要注意如果業(yè)務(wù)對(duì)超用極其敏感比如按量付費(fèi)給外部客戶那精度要求就高可能需要用Redis的原子操作做準(zhǔn)實(shí)時(shí)扣減。這里沒有銀彈取決于你的業(yè)務(wù)容忍度。QuickBlue 這類底座通常會(huì)把這做成可配置策略讓接入方自己選。4.4 提示詞模板的注入安全提示詞模板支持變量替換就必然面臨注入問題。如果用戶輸入的內(nèi)容被直接拼進(jìn)提示詞惡意用戶可能通過構(gòu)造輸入來改變模型行為這就是所謂的提示詞注入。底座的防護(hù)思路有幾種對(duì)變量做轉(zhuǎn)義和長(zhǎng)度限制、把用戶輸入和系統(tǒng)指令用明確的分隔符隔開、在關(guān)鍵場(chǎng)景加一層輸入審核。這些措施不能百分百防住但能大幅提高攻擊成本。我的建議是底座要把輸入凈化做成默認(rèn)開啟的能力而不是讓每個(gè)業(yè)務(wù)方自己去想。4.5 版本升級(jí)時(shí)的兼容性噩夢(mèng)底座是給多個(gè)業(yè)務(wù)方用的一旦接口變更影響面很大。我見過因?yàn)榈鬃?jí)導(dǎo)致上游三個(gè)業(yè)務(wù)同時(shí)故障的事故。教訓(xùn)是底座的接口變更必須走嚴(yán)格的兼容性流程。新增字段可以刪除字段不行修改語義必須新開版本廢棄接口要有足夠長(zhǎng)的過渡期和明確的下線通知。這件事說起來簡(jiǎn)單做起來需要紀(jì)律。建議在底座項(xiàng)目里就把 API 版本管理、變更評(píng)審、灰度發(fā)布這些流程固化下來別等到出事才補(bǔ)。5. 企業(yè)到底該不該上AI應(yīng)用底座一份決策參考5.1 什么階段適合引入底座不是所有團(tuán)隊(duì)都需要底座。我的判斷標(biāo)準(zhǔn)是看三個(gè)信號(hào)AI場(chǎng)景數(shù)量超過五個(gè)且還在增加散裝維護(hù)開始吃力。使用團(tuán)隊(duì)數(shù)量超過兩個(gè)團(tuán)隊(duì)在用AI能力需要統(tǒng)一治理。合規(guī)與成本壓力有明確的審計(jì)、配額、成本核算要求。三個(gè)信號(hào)中滿足兩個(gè)就該認(rèn)真考慮底座了。如果只有一個(gè)場(chǎng)景、一個(gè)團(tuán)隊(duì)老老實(shí)實(shí)寫業(yè)務(wù)代碼更劃算別為了架構(gòu)而架構(gòu)。5.2 自研還是選型現(xiàn)成方案自研的好處是貼合自身業(yè)務(wù)壞處是周期長(zhǎng)、坑多。選型現(xiàn)成方案比如 QuickBlue 這類的好處是開箱即用壞處是可能不完全匹配你的場(chǎng)景且要評(píng)估其長(zhǎng)期維護(hù)能力。我的建議是核心治理能力優(yōu)先用成熟方案業(yè)務(wù)特有的能力編排可以自研。比如模型接入、配額、追蹤這些通用性強(qiáng)的沒必要自己造而你們公司特有的業(yè)務(wù)能力組合現(xiàn)成方案大概率覆蓋不了自己寫更合適。混合策略往往比純自研或純采購(gòu)更務(wù)實(shí)。5.3 引入底座后的組織配套技術(shù)底座從來不是純技術(shù)問題。引入底座意味著業(yè)務(wù)團(tuán)隊(duì)的開發(fā)方式要變不能再自己直連模型要走底座接口不能再自己管密鑰要申請(qǐng)配額。這些改變需要配套的流程和文檔否則底座會(huì)被繞過。我見過最失敗的情況是底座做出來了但業(yè)務(wù)團(tuán)隊(duì)嫌麻煩繼續(xù)自己直連模型底座成了擺設(shè)。所以推行底座時(shí)一定要有胡蘿卜加大棒——用底座能拿到配額、能看監(jiān)控、能復(fù)用能力胡蘿卜同時(shí)把直連模型的路堵死大棒。組織配套跟不上再好的技術(shù)也落不了地。6. 我對(duì)這類底座未來演進(jìn)的一點(diǎn)觀察從我這段時(shí)間的實(shí)踐看AI應(yīng)用底座正在從模型接入層往能力操作系統(tǒng)演進(jìn)。早期的底座只解決怎么調(diào)模型現(xiàn)在的底座開始解決怎么編排能力怎么治理AI資產(chǎn)怎么讓AI能力像水電一樣被調(diào)用。QuickBlue 這類項(xiàng)目把微服務(wù)、JDK 21、Spring Cloud 這些成熟的企業(yè)級(jí)技術(shù)棧用在AI場(chǎng)景上思路是對(duì)的——AI落地到最后拼的不是模型多先進(jìn)而是工程化能力多扎實(shí)。模型會(huì)不斷迭代但一套好的底座架構(gòu)能扛住多次模型換代。我個(gè)人在實(shí)際操作中的體會(huì)是底座的價(jià)值不在于它支持多少模型而在于它讓業(yè)務(wù)團(tuán)隊(duì)忘記模型的存在。當(dāng)業(yè)務(wù)同學(xué)只關(guān)心我要一個(gè)摘要能力而不用管背后是哪個(gè)模型、哪個(gè)版本、怎么限流時(shí)這個(gè)底座才算真正成功了。這條路還很長(zhǎng)但方向是清晰的。