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