1. 為什么企業(yè)不是“接個(gè) API”那么簡(jiǎn)單大概在兩年前我所在的技術(shù)團(tuán)隊(duì)第一次把大模型接入到內(nèi)部系統(tǒng)里。當(dāng)時(shí)大家普遍的想法很簡(jiǎn)單拿到一個(gè) API Key調(diào)通一個(gè)接口能在頁(yè)面里跑通一個(gè)對(duì)話窗口就算“擁抱大模型”了。但真正跑起來(lái)之后問(wèn)題接踵而至。先是各個(gè)項(xiàng)目組各自申請(qǐng)賬號(hào)密鑰散落在代碼倉(cāng)庫(kù)、配置文件、甚至聊天記錄里然后是費(fèi)用賬單變得完全不可控有人用 GPT-4 跑批量任務(wù)有人用同一個(gè) Key 在測(cè)試環(huán)境反復(fù)調(diào)試月底財(cái)務(wù)一看賬單直接懵了再后來(lái)是安全部門(mén)找上門(mén)因?yàn)槟硞€(gè)內(nèi)部工具把客戶相關(guān)的數(shù)據(jù)拼進(jìn)了 prompt 里而這條請(qǐng)求走了哪家模型、存了哪些日志完全沒(méi)有記錄可查。這些問(wèn)題的本質(zhì)不是某個(gè)模型的能力不行而是企業(yè)缺少一個(gè)統(tǒng)一管理大模型流量的入口。這個(gè)入口就是后來(lái)我們花了大力氣建設(shè)的東西——大模型網(wǎng)關(guān)。簡(jiǎn)單說(shuō)它處在業(yè)務(wù)系統(tǒng)和各類(lèi)大模型之間所有的大模型請(qǐng)求都先經(jīng)過(guò)它由它負(fù)責(zé)路由、鑒權(quán)、限流、緩存、審計(jì)以及成本核算。這也是我寫(xiě)這篇實(shí)踐指南的初衷。大模型網(wǎng)關(guān)不是一個(gè)“裝個(gè)開(kāi)源軟件就能用”的玩具它涉及企業(yè)現(xiàn)有的網(wǎng)絡(luò)架構(gòu)、安全合規(guī)要求、成本管理機(jī)制還要和研發(fā)流程里的自動(dòng)化編程工具配合起來(lái)才能形成真正的生產(chǎn)力。接下來(lái)我會(huì)從基礎(chǔ)概念講起再落到我們實(shí)際落地過(guò)程中踩過(guò)的坑和沉淀下來(lái)的做法。2. 大模型網(wǎng)關(guān)到底在網(wǎng)關(guān)什么核心能力拆解2.1 模型路由按場(chǎng)景分流而不是所有請(qǐng)求都用同一個(gè)模型網(wǎng)關(guān)最基礎(chǔ)也最重要的能力是模型路由。大多數(shù)企業(yè)不會(huì)只接一家大模型供應(yīng)商開(kāi)源模型、商業(yè) API、私有化部署的模型往往會(huì)同時(shí)存在。如果沒(méi)有網(wǎng)關(guān)業(yè)務(wù)方就得自己在代碼里寫(xiě)一堆 if-else 來(lái)切換供應(yīng)商這會(huì)造成嚴(yán)重的代碼耦合。網(wǎng)關(guān)把這一層抽取出來(lái)之后路由策略就變成了配置問(wèn)題。我在實(shí)際項(xiàng)目里通常會(huì)把路由維度分為三類(lèi)按任務(wù)類(lèi)型、按業(yè)務(wù)優(yōu)先級(jí)、按成本區(qū)段。任務(wù)類(lèi)型指的是對(duì)話、摘要、代碼生成、向量化這類(lèi)不同工作負(fù)載不同任務(wù)的延遲敏感度和質(zhì)量要求差別很大業(yè)務(wù)優(yōu)先級(jí)則決定了高優(yōu)業(yè)務(wù)可以打到更強(qiáng)的模型上而低優(yōu)任務(wù)可以回退到便宜模型成本區(qū)段則是把流量的預(yù)算做進(jìn)路由規(guī)則里比如某個(gè)部門(mén)這個(gè)月的預(yù)算快用完了自動(dòng)把非核心流量切到更經(jīng)濟(jì)的模型。路由規(guī)則看起來(lái)就是個(gè)配置但真正設(shè)計(jì)的時(shí)候有一個(gè)容易忽略的點(diǎn)路由必須支持可灰度、可回退。我們?cè)谏暇€初期就吃過(guò)虧把所有流量一刀切到新接入的模型上結(jié)果那個(gè)模型對(duì)某些行業(yè)術(shù)語(yǔ)的理解明顯不如原來(lái)的模型線上反饋量直接上升。后來(lái)我們養(yǎng)成了一個(gè)習(xí)慣任何路由變更都先跑 1% 的流量觀察結(jié)果指標(biāo)再逐步放量。2.2 語(yǔ)義緩存省錢(qián)的同時(shí)別讓用戶覺(jué)得“變笨了”大模型的調(diào)用成本是真實(shí)存在的尤其當(dāng)你在做一些重復(fù)性較高的業(yè)務(wù)時(shí)比如客服話術(shù)生成、報(bào)表解讀、知識(shí)庫(kù)問(wèn)答。我們發(fā)現(xiàn)企業(yè)內(nèi)部有大量請(qǐng)求其實(shí)是高度相似的用戶換個(gè)措辭問(wèn)同一個(gè)問(wèn)題背后模型要做的事情幾乎一樣。這時(shí)候如果每次請(qǐng)求都真實(shí)調(diào)用一次大模型成本是很大的浪費(fèi)。網(wǎng)關(guān)層可以做語(yǔ)義緩存。它和傳統(tǒng)緩存的區(qū)別在于傳統(tǒng)緩存靠 key 精確匹配而語(yǔ)義緩存會(huì)先把用戶輸入做向量化計(jì)算與之前請(qǐng)求的相似度超過(guò)閾值就直接返回歷史結(jié)果不再調(diào)用大模型。但這里有一個(gè)非常關(guān)鍵的細(xì)節(jié)不是所有場(chǎng)景都適合開(kāi)語(yǔ)義緩存。如果業(yè)務(wù)的時(shí)效性要求很高比如查實(shí)時(shí)庫(kù)存、查當(dāng)天訂單狀態(tài)這類(lèi)請(qǐng)求一旦命中過(guò)期緩存用戶感受到的就是“模型是不是傻了”。我的處理方式是把緩存策略和路由策略綁定在一起對(duì)知識(shí)庫(kù)問(wèn)答、文檔寫(xiě)作這類(lèi)相對(duì)靜態(tài)的場(chǎng)景開(kāi)啟語(yǔ)義緩存對(duì)涉及實(shí)時(shí)數(shù)據(jù)的場(chǎng)景強(qiáng)制繞過(guò)緩存并且給所有緩存結(jié)果打上數(shù)據(jù)新鮮度標(biāo)簽讓業(yè)務(wù)方自己決定是否能接受緩存命中。2.3 限流與配額保護(hù)模型服務(wù)也保護(hù)你的預(yù)算大模型 API 是有并發(fā)限制的而且商業(yè)模型按 token 計(jì)費(fèi)。如果沒(méi)有限流某個(gè)業(yè)務(wù)方突然發(fā)起大量請(qǐng)求輕則拖垮整個(gè)網(wǎng)關(guān)重則耗盡企業(yè)當(dāng)月的調(diào)用預(yù)算。限流這件事企業(yè)級(jí)網(wǎng)關(guān)和高并發(fā)場(chǎng)景下的秒殺系統(tǒng)很像核心算法無(wú)非是令牌桶、滑動(dòng)窗口、漏桶這幾類(lèi)。我對(duì)令牌桶的理解可以用一個(gè)生活化的類(lèi)比想象一個(gè)公共飲水機(jī)桶里每秒鐘會(huì)掉一滴水進(jìn)杯子這個(gè)“水”就是令牌請(qǐng)求進(jìn)來(lái)必須拿走一個(gè)令牌才能繼續(xù)用模型如果杯子滿了請(qǐng)求就得排隊(duì)或者被拒絕。令牌桶的好處是允許一定程度的突發(fā)流量適合真實(shí)業(yè)務(wù)場(chǎng)景里那種“早上十點(diǎn)大家都在問(wèn)相似問(wèn)題”的尖峰。我在生產(chǎn)環(huán)境用的是一套雙層限流方案網(wǎng)關(guān)對(duì)每個(gè)業(yè)務(wù)方做配額限制比如一個(gè)部門(mén)每分鐘最多 100 次請(qǐng)求同時(shí)再對(duì)上游模型通道做整體限流防止網(wǎng)關(guān)本身被打爆。配額限制的粒度也很重要建議至少細(xì)分到“業(yè)務(wù)方模型級(jí)別”不然就會(huì)出現(xiàn)某個(gè)部門(mén)把便宜的模型額度用完了另一個(gè)部門(mén)想用的時(shí)候只能干等。2.4 安全、審計(jì)與數(shù)據(jù)邊界網(wǎng)關(guān)存在的最大理由之一如果說(shuō)路由和限流是網(wǎng)關(guān)的“效率”屬性那么安全和審計(jì)就是網(wǎng)關(guān)的“生存”屬性。在國(guó)內(nèi)企業(yè)的合規(guī)要求下任何涉及用戶個(gè)人信息的請(qǐng)求如果沒(méi)有統(tǒng)一的出口管控和日志審計(jì)風(fēng)險(xiǎn)是非常大的。網(wǎng)關(guān)必須做到三件事。第一密鑰統(tǒng)一管理業(yè)務(wù)方拿到的只是網(wǎng)關(guān)簽發(fā)的憑證而不是上游模型的真實(shí) API Key這樣就算某個(gè)內(nèi)部系統(tǒng)的密鑰泄露了影響范圍也很有限。第二請(qǐng)求內(nèi)容脫敏網(wǎng)關(guān)在把請(qǐng)求轉(zhuǎn)發(fā)給模型之前對(duì)手機(jī)號(hào)、身份證號(hào)、銀行卡號(hào)等敏感信息做識(shí)別和替換模型收到的是脫敏后的文本返回結(jié)果再還原。第三全鏈路審計(jì)日志誰(shuí)在什么時(shí)間、調(diào)用了哪個(gè)模型、發(fā)送了什么內(nèi)容、拿到了什么返回這些都需要可查詢。這一步不光是合規(guī)要求也是出了問(wèn)題之后快速定位原因的唯一手段。我經(jīng)常跟團(tuán)隊(duì)里的工程師說(shuō)網(wǎng)關(guān)是企業(yè)在 AI 時(shí)代的一個(gè)“門(mén)衛(wèi)”它不產(chǎn)生模型能力但決定了誰(shuí)能用、能用多少、用了是否安全。3. 從零落地網(wǎng)關(guān)選型、架構(gòu)和那些必須避開(kāi)的坑3.1 三種落地路徑的對(duì)比做技術(shù)選型之前先要想清楚一個(gè)問(wèn)題你們企業(yè)是想要一個(gè)“能用的網(wǎng)關(guān)”還是想要一個(gè)“能長(zhǎng)期演進(jìn)的網(wǎng)關(guān)”。這兩者的投入完全不同。我遇到過(guò)三種主流路徑。第一種是直接用云廠商提供的托管網(wǎng)關(guān)比如在云上開(kāi)通模型服務(wù)時(shí)自帶的 API 管理能力。這個(gè)方案最省事適合那種還在驗(yàn)證階段、不想投入太多研發(fā)資源的中小團(tuán)隊(duì)但缺點(diǎn)也比較明顯一旦你的模型供應(yīng)商是多家的甚至包含私有化部署的開(kāi)源模型托管網(wǎng)關(guān)通常很難統(tǒng)一納管。第二種是使用開(kāi)源的網(wǎng)關(guān)項(xiàng)目。目前社區(qū)里已經(jīng)有不少成熟項(xiàng)目支持多模型接入、統(tǒng)一鑒權(quán)、成本統(tǒng)計(jì)這些核心功能而且生態(tài)比較活躍。這個(gè)方案適合有一定研發(fā)能力、想要掌控細(xì)節(jié)的團(tuán)隊(duì)也是我比較推薦的方向。開(kāi)源網(wǎng)關(guān)的好處是靈活壞處是很多企業(yè)級(jí)能力需要自己二次開(kāi)發(fā)比如和內(nèi)部 SSO 對(duì)接、審計(jì)日志推送、告警系統(tǒng)聯(lián)動(dòng)。第三種是從零自研。說(shuō)實(shí)話自研網(wǎng)關(guān)的技術(shù)門(mén)檻并沒(méi)有想象中那么高它本質(zhì)上就是一個(gè) API 轉(zhuǎn)發(fā)層加上鑒權(quán)、限流、緩存、審計(jì)這些標(biāo)準(zhǔn)中間件能力。但如果企業(yè)已經(jīng)有統(tǒng)一的 API 網(wǎng)關(guān)平臺(tái)直接在現(xiàn)有網(wǎng)關(guān)上擴(kuò)展一個(gè)大模型轉(zhuǎn)發(fā)插件往往比另起爐灶更合理。自研最大的成本不在開(kāi)發(fā)而在后續(xù)的持續(xù)維護(hù)和兼容性跟進(jìn)比如上游模型供應(yīng)商的接口變動(dòng)、新模型接入時(shí)的協(xié)議適配。3.2 我推薦的部署架構(gòu)和關(guān)鍵配置我實(shí)際落地時(shí)采用的是一套比較標(biāo)準(zhǔn)的架構(gòu)前置統(tǒng)一接入層、網(wǎng)關(guān)核心引擎、模型通道適配層。統(tǒng)一接入層面向內(nèi)部業(yè)務(wù)系統(tǒng)提供統(tǒng)一的 OpenAI 兼容接口網(wǎng)關(guān)核心引擎處理鑒權(quán)、限流、路由、緩存、審計(jì)模型通道適配層對(duì)接各家模型供應(yīng)商包括 OpenAI 兼容協(xié)議、各家私有協(xié)議以及內(nèi)網(wǎng)部署的模型服務(wù)。在部署形態(tài)上網(wǎng)關(guān)服務(wù)本身是無(wú)狀態(tài)的可以水平擴(kuò)展?fàn)顟B(tài)全部放到 Redis 里。限流計(jì)數(shù)、緩存、路由規(guī)則都走 Redis這樣即使某個(gè)網(wǎng)關(guān)實(shí)例掛了流量也能平滑切換到其他實(shí)例。關(guān)鍵配置上我覺(jué)得最值得關(guān)注的幾個(gè)點(diǎn)包括模型超時(shí)時(shí)間默認(rèn)給 60 秒但針對(duì)流式對(duì)話場(chǎng)景要單獨(dú)調(diào)請(qǐng)求體大小限制防止有人通過(guò)網(wǎng)關(guān)轉(zhuǎn)儲(chǔ)大文件導(dǎo)致內(nèi)存溢出以及重試策略冪等請(qǐng)求可以自動(dòng)重試一次非冪等請(qǐng)求一定不能自動(dòng)重試。3.3 落地過(guò)程中的三個(gè)大坑坑一把網(wǎng)關(guān)變成單點(diǎn)。我見(jiàn)過(guò)有團(tuán)隊(duì)把所有大模型請(qǐng)求都打到一臺(tái)網(wǎng)關(guān)實(shí)例上問(wèn)原因說(shuō)是流量不大沒(méi)必要集群。結(jié)果某天這臺(tái)機(jī)器因?yàn)榇疟P(pán)滿導(dǎo)致服務(wù)宕機(jī)整個(gè)公司所有 AI 功能全線不可用。網(wǎng)關(guān)是無(wú)狀態(tài)的天生適合多實(shí)例部署前面加個(gè)負(fù)載均衡器成本很低但穩(wěn)定性提升是質(zhì)變?？佣褜徲?jì)日志寫(xiě)入到業(yè)務(wù)數(shù)據(jù)庫(kù)。審計(jì)日志的數(shù)據(jù)量增長(zhǎng)極快每條請(qǐng)求的 req 和 resp 內(nèi)容動(dòng)輒幾 KB 甚至幾十 KB如果和業(yè)務(wù)表放在同一個(gè)庫(kù)里很快就會(huì)拖慢業(yè)務(wù)查詢。審計(jì)日志應(yīng)該走獨(dú)立的存儲(chǔ)比如對(duì)象存儲(chǔ)加檢索服務(wù)或者專(zhuān)門(mén)的日志系統(tǒng)?？尤龥](méi)考慮模型供應(yīng)商的限流差異。開(kāi)源模型的私有化部署通常沒(méi)有嚴(yán)格的限流但商業(yè) API 的限流是硬性的。如果你在網(wǎng)關(guān)層設(shè)了一個(gè)非常大的限流閾值上游也會(huì)反過(guò)來(lái)限制你的并發(fā)這時(shí)候請(qǐng)求會(huì)大量報(bào)錯(cuò)。后來(lái)我們會(huì)定期拉取供應(yīng)商賬號(hào)的配額數(shù)據(jù)在網(wǎng)關(guān)層動(dòng)態(tài)調(diào)整閾值。4. 自動(dòng)化編程的實(shí)戰(zhàn)推進(jìn)從輔助編碼到工程化協(xié)同4.1 先想清楚自動(dòng)化編程的邊界搞定了大模型網(wǎng)關(guān)之后我們開(kāi)始推進(jìn)第二個(gè)方向自動(dòng)化編程。其實(shí)“自動(dòng)化編程”這個(gè)詞很容易讓人產(chǎn)生誤解以為目標(biāo)是讓 AI 自動(dòng)寫(xiě)完整套業(yè)務(wù)系統(tǒng)這個(gè)預(yù)期不現(xiàn)實(shí)至少在現(xiàn)階段AI 的能力邊界更適合定義為“輔助程序員高效完成研發(fā)鏈路中的具體環(huán)節(jié)”。我從實(shí)踐里得出的結(jié)論是自動(dòng)化編程的落地路徑應(yīng)該分為三檔第一檔是代碼補(bǔ)全和對(duì)話式編程幫工程師更快寫(xiě)出代碼第二檔是自動(dòng)生成單元測(cè)試、自動(dòng)化生成代碼評(píng)審意見(jiàn)、自動(dòng)修復(fù)已知告警第三檔是更進(jìn)一步的智能體能獨(dú)立完成一個(gè)簡(jiǎn)單的需求任務(wù)比如生成一個(gè) CRUD 接口、寫(xiě)一份數(shù)據(jù)庫(kù)表結(jié)構(gòu)的變更腳本。我們的經(jīng)驗(yàn)是先把第一檔和第二檔做成團(tuán)隊(duì)的默認(rèn)工具再逐步試探第三檔。4.2 代碼補(bǔ)全類(lèi)工具的高效用法代碼補(bǔ)全工具現(xiàn)在的成熟度已經(jīng)很高了模型會(huì)根據(jù)上下文自動(dòng)生成下一段代碼。但我發(fā)現(xiàn)很多團(tuán)隊(duì)用了工具之后代碼質(zhì)量反而下降原因是使用者把它當(dāng)成了搜索引擎直接把生成的代碼復(fù)制粘貼完全不過(guò)腦。我的建議是代碼補(bǔ)全最有效的場(chǎng)景是“消除機(jī)械勞動(dòng)”而不是“替代思考”。比如寫(xiě)一段重復(fù)性極高的 DTO 映射、生成常見(jiàn)的增刪改查樣板代碼、根據(jù)接口定義生成前端類(lèi)型定義這些用 AI 生成效率提升非常明顯。但涉及到業(yè)務(wù)邏輯的關(guān)鍵分支、并發(fā)邊界、事務(wù)一致性這些地方必須由人來(lái)仔細(xì)推敲。我們內(nèi)部還專(zhuān)門(mén)維護(hù)了一份“AI 生成代碼的審查清單”涵蓋空指針、資源泄漏、異常處理、魔法值這幾個(gè)高頻問(wèn)題。因?yàn)槟Ｐ蜕傻拇a表面上看語(yǔ)法沒(méi)問(wèn)題但在邊界處理上經(jīng)常會(huì)有隱患。4.3 單測(cè)生成和代碼評(píng)審最容易見(jiàn)效的切入口如果讓我推薦自動(dòng)化編程最值得先做的場(chǎng)景一定是單元測(cè)試生成。程序員普遍不喜歡寫(xiě)單測(cè)覺(jué)得枯燥、重復(fù)、費(fèi)時(shí)間但這個(gè)工作恰恰非常適合大模型來(lái)做。模型讀到你的函數(shù)簽名、上下文、歷史提交記錄之后生成的測(cè)試用例覆蓋面往往比人寫(xiě)的還廣。我們做過(guò)一個(gè)實(shí)驗(yàn)用自動(dòng)化工具給一個(gè)訂單服務(wù)模塊生成單測(cè)生成的用例數(shù)量是手寫(xiě)的三倍分支覆蓋率提升了大概 20 個(gè)百分點(diǎn)。當(dāng)然生成的用例不是全部能直接通過(guò)大概有三分之二的用例需要人工微調(diào)但哪怕是這樣整體效率也比從零手寫(xiě)高很多。代碼評(píng)審是另一個(gè)高頻場(chǎng)景。傳統(tǒng)的人工評(píng)審特別依賴評(píng)審人的經(jīng)驗(yàn)和精力實(shí)際執(zhí)行起來(lái)經(jīng)常流于形式。我們把代碼評(píng)審機(jī)器人接到現(xiàn)有的代碼托管平臺(tái)上每次提交代碼自動(dòng)觸發(fā)從代碼風(fēng)格到潛在的邏輯問(wèn)題都跑一遍把結(jié)果附加到 MR 的評(píng)論里。人工評(píng)審者可以把精力集中在業(yè)務(wù)架構(gòu)、方案取舍這些機(jī)器看不了的問(wèn)題上。4.4 自動(dòng)化編程的工程化配套工具只是自動(dòng)化編程的一部分真正落地還需要配套的工程化機(jī)制。我的經(jīng)驗(yàn)是三條。第一代碼生成必須和既有代碼規(guī)范綁定。我們?cè)谏晒ぞ叩奶崾驹~里注入了團(tuán)隊(duì)的代碼規(guī)范片段比如命名規(guī)范、異常處理方式、日志輸出格式這樣生成出來(lái)的代碼至少不會(huì)被 Code Review 因?yàn)轱L(fēng)格問(wèn)題打回。第二AI 生成的所有代碼必須走完整的 CI 流程。單元測(cè)試、靜態(tài)掃描、構(gòu)建、部署流水線一個(gè)都不能少。AI 寫(xiě)代碼也會(huì)犯錯(cuò)但它犯錯(cuò)的方式和人不一樣必須靠流水線幫他兜底。第三要建立 AI 代碼的追蹤機(jī)制。哪些代碼是 AI 生成的是在什么時(shí)間、基于什么上下文生成的這些信息要保留。不然出了問(wèn)題連排查的起點(diǎn)都找不到。5. 把網(wǎng)關(guān)和自動(dòng)化編程捏成一個(gè)整體5.1 統(tǒng)一接入之后的研發(fā)提效閉環(huán)前面講的網(wǎng)關(guān)和自動(dòng)化編程其實(shí)是兩個(gè)獨(dú)立的方向但它們?cè)谄髽I(yè)實(shí)際運(yùn)行中必須要打通。打通之后才能形成一個(gè)完整的研發(fā)提效閉環(huán)。舉一個(gè)我們內(nèi)部真實(shí)發(fā)生的例子。代碼補(bǔ)全工具一開(kāi)始是每個(gè)工程師自己注冊(cè)賬號(hào)去用的用得挺好但問(wèn)題在于不同工程師用了不同供應(yīng)商的編程助手體驗(yàn)不一致費(fèi)用也分散而且代碼補(bǔ)全工具產(chǎn)生的請(qǐng)求內(nèi)容涉及企業(yè)源代碼這個(gè)數(shù)據(jù)流完全游離在安全管控之外。后來(lái)我們把編程助手的流量也納管到了統(tǒng)一的大模型網(wǎng)關(guān)下面。工程師在前端用的還是原來(lái)的編程助手 IDE 插件但請(qǐng)求統(tǒng)一經(jīng)過(guò)網(wǎng)關(guān)統(tǒng)一做鑒權(quán)、審計(jì)、限流。研發(fā)同學(xué)沒(méi)有感知到變化但安全部門(mén)放心了費(fèi)用也看得見(jiàn)了。這算是網(wǎng)關(guān)在“AI 時(shí)代基礎(chǔ)設(shè)施”這個(gè)角色上一個(gè)非常典型的應(yīng)用。5.2 可觀測(cè)性建設(shè)讓成本和效果都看得見(jiàn)大模型網(wǎng)關(guān)鋪開(kāi)之后可觀測(cè)性建設(shè)是我最想強(qiáng)調(diào)的事情。傳統(tǒng)的監(jiān)控指標(biāo)比如 QPS、延遲、錯(cuò)誤率在網(wǎng)關(guān)場(chǎng)景下還不夠你還需要看到 token 消耗量、成本消耗、緩存命中率、模型分布、業(yè)務(wù)方用量排行這些維度。我建議網(wǎng)關(guān)的指標(biāo)面板上至少要有這幾個(gè)視圖實(shí)時(shí)請(qǐng)求量按模型維度的分布按業(yè)務(wù)方的 token 消耗排行緩存命中率趨勢(shì)單次請(qǐng)求的成本明細(xì)。有了這些數(shù)據(jù)你才能回答管理層最關(guān)心的兩個(gè)問(wèn)題——AI 的投入產(chǎn)生了多少效果以及錢(qián)花在了哪里。成本管理上還有一個(gè)細(xì)節(jié)要給每個(gè)業(yè)務(wù)方設(shè)置預(yù)算閾值而不是等賬單出來(lái)了再分?jǐn)偂Ｎ覀冊(cè)诰W(wǎng)關(guān)上做了預(yù)算預(yù)警業(yè)務(wù)方用量達(dá)到月預(yù)算的 80% 時(shí)自動(dòng)告警給負(fù)責(zé)人超過(guò)預(yù)算后可以配置自動(dòng)降級(jí)到更便宜的模型或者直接阻斷非核心調(diào)用。5.3 組織與流程上的推動(dòng)經(jīng)驗(yàn)技術(shù)落地到一定程度之后瓶頸往往出現(xiàn)在組織層面。很多團(tuán)隊(duì)推廣 AI 工具的阻力不是工具不好用而是大家不愿意改變習(xí)慣。我自己的體會(huì)是最好的方式是找到團(tuán)隊(duì)里兩三個(gè)愿意嘗鮮的種子用戶讓他們先跑出效果形成標(biāo)桿案例再鋪開(kāi)給其他成員。另一個(gè)經(jīng)驗(yàn)是不要把“AI 使用率”當(dāng)成唯一的 KPI。逼著每個(gè)工程師每天必須用多少次 AI 是沒(méi)意義的反而會(huì)滋生湊數(shù)行為。更合理的指標(biāo)是看研發(fā)交付的效率有沒(méi)有提升——比如需求平均交付周期有沒(méi)有縮短、單測(cè)覆蓋率有沒(méi)有上升、線上缺陷密度有沒(méi)有下降。這些指標(biāo)能被 AI 間接影響但它們本身是正經(jīng)的研發(fā)質(zhì)量指標(biāo)不會(huì)因?yàn)橛昧?AI 就失真。6. 我踩過(guò)的坑和那些希望早點(diǎn)知道的事6.1 別一上來(lái)就追求“大而全”我們最早制定網(wǎng)關(guān)建設(shè)方案的時(shí)候規(guī)劃了特別多能力多租戶、復(fù)雜的計(jì)費(fèi)體系、智能路由、動(dòng)態(tài)模型切換、一鍵遷移……后來(lái)發(fā)現(xiàn)越大的方案越難落地半年都上線不了。后來(lái)我們把范圍收縮到最小可行版本統(tǒng)一的模型接入、密鑰管理、基礎(chǔ)限流、日志審計(jì)。這四個(gè)能力上線之后立刻解決了之前最痛苦的成本和安全問(wèn)題后面的高級(jí)能力再迭代補(bǔ)充。自動(dòng)化編程也一樣不要想著第一天就讓 AI 自動(dòng)修 Bug、自動(dòng)評(píng)審、自動(dòng)生成上線報(bào)告。先從代碼補(bǔ)全和單測(cè)生成這兩個(gè)點(diǎn)切入跑順了再擴(kuò)展。6.2 評(píng)估指標(biāo)要在動(dòng)手之前定下來(lái)做這類(lèi)基礎(chǔ)設(shè)施項(xiàng)目最怕的事情是上線之后不知道該怎么評(píng)估成功失敗。網(wǎng)關(guān)上線前我們定了幾條硬指標(biāo)請(qǐng)求成功率不低于 99.5%、網(wǎng)關(guān)轉(zhuǎn)發(fā)延遲增加不超過(guò) 20 毫秒、通過(guò)緩存節(jié)省的成本占總模型費(fèi)用的比例、以及安全審計(jì)完整性達(dá)到 100%。有了這些指標(biāo)每一輪優(yōu)化都有明確的方向也能跟管理層講清楚投入產(chǎn)出比。6.3 團(tuán)隊(duì)認(rèn)知對(duì)齊比工具選型更重要最后說(shuō)一句可能聽(tīng)起來(lái)有點(diǎn)虛、但確實(shí)是最重要的話工具和方案再完善最終使用它們的還是人。我見(jiàn)過(guò)有團(tuán)隊(duì)引進(jìn)了一流的工具但工程師因?yàn)椴涣私庠矶阉?dāng)成玩具也見(jiàn)過(guò)團(tuán)隊(duì)用很樸素的工具但因?yàn)槊總€(gè)人都知道邊界、知道什么場(chǎng)景該用、什么場(chǎng)景不該用整體效果反而非常好。我們后來(lái)每周會(huì)固定搞一次內(nèi)部的 AI 實(shí)踐分享會(huì)每次由一個(gè)人分享他在過(guò)去一周里用 AI 工具解決的一個(gè)真實(shí)問(wèn)題十幾分鐘很輕量。這種形式不需要額外投入太多時(shí)間但對(duì)團(tuán)隊(duì)整體認(rèn)知的提升效果非常明顯。我個(gè)人在經(jīng)歷了網(wǎng)關(guān)建設(shè)和自動(dòng)化編程落地這兩件事之后最大的體會(huì)是技術(shù)選型和架構(gòu)設(shè)計(jì)當(dāng)然重要但真正決定一個(gè)企業(yè)能不能把大模型用起來(lái)、用得好取決于它有沒(méi)有建立起一套讓模型能力安全、有序、可控地進(jìn)入日常工作的基礎(chǔ)設(shè)施和配套機(jī)制。如果你所在的公司也在做類(lèi)似的事情希望這篇實(shí)踐指南能幫你少走一些彎路。