這幾年前我做AI項(xiàng)目大家見面問得最多的還是模型效果怎么樣、準(zhǔn)確率幾個(gè)點(diǎn)。但從去年開始問題慢慢變了變成了這系統(tǒng)上線之后會(huì)不會(huì)跑著跑著自己就嗝屁了——模型輸出開始胡說八道、Agent卡進(jìn)死循環(huán)瘋狂刷日志、半夜三更收到告警說服務(wù)大面積超時(shí)。這些問題本質(zhì)上都是同一個(gè)話題怎么讓AI系統(tǒng)活著。讓AI活著不是擬人化的玄學(xué)而是AI工程里的生命周期與可運(yùn)維性課題。這里的AI也不是指某一個(gè)模型權(quán)重而是包括模型部署、提示詞、記憶、工具調(diào)用、Agent編排、監(jiān)控告警在內(nèi)的一整套系統(tǒng)。只要其中一環(huán)斷了AI就死給你看。這篇作為白皮書系列的第九篇我想把過去幾年在AI可運(yùn)維性上踩過的坑、跑通的路系統(tǒng)地梳理一遍重點(diǎn)圍繞模型選型、Agent架構(gòu)、自愈機(jī)制、成本控制和問題排查展開希望能給正在被AI系統(tǒng)線上穩(wěn)定性折磨的同行一些可以直接落地的思路。1. 先理解活著的本質(zhì)這是運(yùn)維問題不是算法問題我見過太多團(tuán)隊(duì)把AI活著誤判成模型效果問題。模型效果不好表現(xiàn)是輸出明顯錯(cuò)誤而系統(tǒng)死掉表現(xiàn)是輸出看起來正常但不可用或者服務(wù)整個(gè)卡死。兩者的排查方向、解決手段完全不同。1.1 三個(gè)真實(shí)的AI死亡現(xiàn)場第一個(gè)現(xiàn)場是上下文腐爛。一個(gè)帶記憶的聊天系統(tǒng)跑了兩周之后模型開始反復(fù)說車轱轆話甚至把幾天前的錯(cuò)誤信息當(dāng)成事實(shí)。表面看是模型變笨了實(shí)際上是你的上下文管理邏輯出了問題——積累的舊信息占據(jù)了大量注意力還把用戶的新指令擠出去了。第二個(gè)現(xiàn)場是Agent死循環(huán)。一個(gè)負(fù)責(zé)寫報(bào)告的多Agent系統(tǒng)子Agent不斷調(diào)用搜索工具每次拿到結(jié)果都覺得不滿意又繼續(xù)搜日志刷了幾個(gè)GAPI賬單瘋狂上漲但用戶那邊始終沒等到最終答案。這種情況崩潰的不是模型是任務(wù)編排狀態(tài)機(jī)。第三個(gè)現(xiàn)場是上游連鎖崩潰。模型接口出現(xiàn)限流系統(tǒng)沒有熔斷所有請(qǐng)求排隊(duì)等待數(shù)據(jù)庫連接池被打滿最后整個(gè)服務(wù)雪崩。這已經(jīng)不是AI問題而是典型的后端故障但因?yàn)殒溌防镉蠥I環(huán)節(jié)很多人反而不知道從哪里排查。這三個(gè)現(xiàn)場指向同一件事讓AI活著核心不是調(diào)高某個(gè)閾值而是要做系統(tǒng)的免疫系統(tǒng)建設(shè)。模型只是大腦應(yīng)用是骨架監(jiān)控、自愈、降級(jí)、容錯(cuò)才是免疫系統(tǒng)。很多時(shí)候AI死了兇手不是模型本身而是免疫系統(tǒng)先失效了。1.2 重新定義AI系統(tǒng)的生命力我給AI活著下一個(gè)可工程化的定義系統(tǒng)在長周期運(yùn)行中保持可用、穩(wěn)定、可控效果不隨時(shí)間和數(shù)據(jù)積累而衰減并且在部分組件異常時(shí)仍能輸出兜底結(jié)果。這里有幾個(gè)可量化的對(duì)應(yīng)指標(biāo)可用性服務(wù)成功率、平均響應(yīng)時(shí)間、錯(cuò)誤率穩(wěn)定性輸出格式合法率、任務(wù)完成率、無效調(diào)用占比可控性所有模型調(diào)用有日志、有審計(jì)、有權(quán)限控制可恢復(fù)故障發(fā)生后能在多少時(shí)間內(nèi)自愈或自動(dòng)降級(jí)如果你現(xiàn)在負(fù)責(zé)一個(gè)AI系統(tǒng)可以先用這四個(gè)維度給自己打個(gè)分。很多系統(tǒng)上線第一天全部滿分兩周后就開始直線下滑就是因?yàn)樵谠O(shè)計(jì)之初只考慮了怎么讓模型跑通沒考慮怎么讓它一直跑通。這也是我寫這篇的核心原因與其等系統(tǒng)死了再去搶救不如在一開始就把生命力設(shè)計(jì)進(jìn)去。2. 底子不好AI活不長久模型選型與運(yùn)行環(huán)境很多AI系統(tǒng)的夭折其實(shí)從選型那一刻就注定了。模型選型不考慮場景約束部署架構(gòu)不考慮并發(fā)訴求后面一切運(yùn)維手段都是徒勞。2.1 模型選型的四個(gè)硬指標(biāo)我選模型從來不是只看誰跑分高而是看四個(gè)維度效果、延遲、成本、可控性。這四個(gè)維度互相牽扯必須按場景排優(yōu)先級(jí)。拿結(jié)構(gòu)化輸出舉例。如果你的系統(tǒng)需要AI生成固定JSON格式的SQL或配置那么推理發(fā)散度就是一個(gè)重要指標(biāo)。有的模型生成內(nèi)容質(zhì)量很高但輸出格式極不穩(wěn)定經(jīng)常夾帶解釋性文字解析器一跑就崩。這種場景下一個(gè)效果稍微弱一點(diǎn)但格式穩(wěn)定性強(qiáng)的小模型反而能讓系統(tǒng)活得更久。你需要重點(diǎn)看模型卡的幾個(gè)參數(shù)上下文窗口能裝多少Token決定你的記憶策略怎么設(shè)計(jì)最大輸出Token有些場景需要長輸出比如寫長文、生成代碼這個(gè)不夠會(huì)直接截?cái)嗳蝿?wù)是否原生支持工具調(diào)用決定Agent編排的復(fù)雜度和穩(wěn)定性推理成本曲線輸入和輸出Token的價(jià)格往往不同輸出貴的模型在長任務(wù)場景要謹(jǐn)慎另外還要看模型的性格。有的模型默認(rèn)回答比較簡短適合客服有的模型回答問題特別啰嗦適合寫報(bào)告。這個(gè)通過讀模型的示例輸出就能判斷不用等上線踩坑。2.2 部署方式API調(diào)用還是本地推理現(xiàn)在主流有兩種方式直接調(diào)用API和本地部署。各有代價(jià)。API調(diào)用省事但你要面對(duì)三個(gè)不穩(wěn)定因素限流、故障、上游策略變化。我見過不止一次因?yàn)樯嫌文Ｐ徒涌谂R時(shí)調(diào)整導(dǎo)致下游全線報(bào)錯(cuò)的情況。所以API調(diào)用必須做三層防護(hù)合理配比限流預(yù)估值、加一層輕量緩存、留一個(gè)降級(jí)通道。本地部署的優(yōu)勢是可控但坑也不少。首先是顯存規(guī)劃模型權(quán)重、KV Cache、推理框架的開銷都要算進(jìn)去。你買了一塊24G顯存的卡不一定能跑起一個(gè)13B模型的高并發(fā)服務(wù)因?yàn)镵V Cache會(huì)吃掉大量顯存。其次是并發(fā)與冷啟動(dòng)服務(wù)不預(yù)熱就接流量前幾十個(gè)請(qǐng)求會(huì)慢到直接超時(shí)。我的建議是核心鏈路用高可用API輔助鏈路或兜底邏輯用本地小模型。這樣即使上游出問題你至少能降級(jí)到一個(gè)笨但能用的方案上而不是全盤崩潰。3. 擁有好架構(gòu)的Agent才能活得有章法如果你還停留在把提示詞寫漂亮點(diǎn)模型輸出就穩(wěn)定的階段那說明AI系統(tǒng)還沒有真正建立起骨架。真正讓AI長期穩(wěn)定工作的核心是Agent架構(gòu)和系統(tǒng)化編排。3.1 單Agent的生命力設(shè)計(jì)狀態(tài)機(jī)大于提示詞單Agent本質(zhì)上是一個(gè)循環(huán)感知輸入、規(guī)劃動(dòng)作、調(diào)用工具、觀察結(jié)果、再規(guī)劃。這個(gè)循環(huán)能不能穩(wěn)定運(yùn)轉(zhuǎn)取決于你把它當(dāng)成一個(gè)系統(tǒng)工程還是一條寫滿花哨提示詞的流水線。我強(qiáng)烈建議把Agent當(dāng)狀態(tài)機(jī)而不是大號(hào)聊天框來設(shè)計(jì)。每個(gè)Agent應(yīng)該明確自己的當(dāng)前狀態(tài)等待輸入、正在規(guī)劃、等待工具結(jié)果、生成最終輸出、失敗重試。狀態(tài)必須在代碼里顯式管理不能靠模型自己記住。工具調(diào)用是最容易出問題的環(huán)節(jié)。我常用的規(guī)范是給每個(gè)工具加護(hù)欄明確輸入輸出的JSON Schema模型輸出先用校驗(yàn)器過一遍格式不對(duì)就要求重寫每個(gè)工具調(diào)用必須有超時(shí)上限防止外部接口卡死拖垮Agent工具失敗要返回結(jié)構(gòu)化錯(cuò)誤信息幫助Agent理解下一步該做什么很多Agent死在工具調(diào)用上并不是因?yàn)槟Ｐ捅慷枪ぞ邲]有定義清楚。比如你沒有告訴模型搜索超時(shí)了就換個(gè)關(guān)鍵詞不要重復(fù)點(diǎn)十次它就真的會(huì)笨笨地重復(fù)同一個(gè)動(dòng)作到天荒地老。3.2 多AI協(xié)作從一超多強(qiáng)到各司其職單Agent再強(qiáng)把任務(wù)越接越多也會(huì)上下文混亂、職責(zé)不清、不可維護(hù)。這正是多AI協(xié)作要解決的問題。我實(shí)踐下來比較順手的模式是調(diào)度者-執(zhí)行者一個(gè)調(diào)度Agent負(fù)責(zé)任務(wù)拆分、分配和結(jié)果匯總多個(gè)執(zhí)行Agent各負(fù)責(zé)一個(gè)專業(yè)方向。好處有三層故障隔離某個(gè)執(zhí)行Agent掛了不影響其他環(huán)節(jié)重新做事上下文隔離每個(gè)Agent只維護(hù)自己的上下文不會(huì)被其他領(lǐng)域的舊信息污染并發(fā)效率多個(gè)任務(wù)可以并行執(zhí)行整體吞吐比單Agent串行高很多但多AI協(xié)作最容易翻車的點(diǎn)在于循環(huán)依賴。比如Agent A的任務(wù)完成依賴Agent BB又依賴A兩邊互相等系統(tǒng)就死鎖了。解決思路是約定單向依賴樹調(diào)度在最頂層執(zhí)行在底層不允許底層互相直接調(diào)用所有協(xié)調(diào)都走調(diào)度。另外每個(gè)Agent都應(yīng)該有明確的退出條件。就像圍棋里要有一個(gè)目數(shù)判斷Agent也該知道什么程度算完成任務(wù)。否則你會(huì)看到協(xié)作系統(tǒng)不斷精益求精永遠(yuǎn)停不下來。4. 關(guān)鍵工程中樞監(jiān)控、自愈與容錯(cuò)這部分是讓AI活著的靈魂。沒有這套機(jī)制系統(tǒng)上線那天就是它身體狀態(tài)的巔峰之后全靠運(yùn)氣。4.1 監(jiān)控的不僅是資源更是行為健康傳統(tǒng)監(jiān)控盯的是CPU、內(nèi)存、磁盤這些資源指標(biāo)。但AI系統(tǒng)的特殊之處在于資源指標(biāo)一切正常模型行為照樣可能出問題。所以我額外關(guān)注三類行為指標(biāo)。第一類是輸出健康度。包含輸出格式合法率、內(nèi)容重復(fù)率、空響應(yīng)率。怎么聽重復(fù)可以計(jì)算連續(xù)多輪輸出的文本相似度超過閾值就告警?？枕憫?yīng)就是模型輸出了空字符串這種故障往往最隱蔽因?yàn)镠TTP狀態(tài)碼還是200。第二類是任務(wù)完成率。發(fā)送給Agent的任務(wù)有多少在預(yù)期時(shí)間內(nèi)完成了有多少因?yàn)檠h(huán)、超時(shí)、解析失敗而中斷這是反映AI系統(tǒng)真實(shí)存活水平的核心指標(biāo)。第三類是成本異常波動(dòng)。Token消耗量如果出現(xiàn)突然暴漲往往意味著Agent進(jìn)入了某種失控循環(huán)這個(gè)告警甚至比錯(cuò)誤率告警更有價(jià)值因?yàn)樗茉谫~單爆炸前提醒你。4.2 自愈機(jī)制像一個(gè)免疫系統(tǒng)自愈的核心邏輯是遇到問題不慌先按預(yù)案處理。我把自愈機(jī)制拆成三個(gè)層級(jí)從輕到重。第一層是重試。對(duì)偶發(fā)的超時(shí)、限流直接重試一兩次就能解決。但每次重試要有退避避免突發(fā)流量把所有請(qǐng)求都變成重試風(fēng)暴。第二層是熔斷。如果一個(gè)上游接口連續(xù)失敗超過閾值就主動(dòng)切斷對(duì)該接口的調(diào)用直接走降級(jí)邏輯。這就像人得了重感冒先臥床休息別硬撐著出門亂跑。第三層是兜底。兜底方案可以是一條固定的規(guī)則、一個(gè)本地小模型甚至是讓人工介入。比如AI Agent無法自動(dòng)處理某類工單時(shí)直接把工單轉(zhuǎn)給人工團(tuán)隊(duì)這就是一種優(yōu)雅的活著。另外所有自愈動(dòng)作都需要有審計(jì)日志。你不僅要讓系統(tǒng)活著還要讓它知道自己是怎么活下來的。復(fù)盤時(shí)如果沒有日志就會(huì)變成玄學(xué)調(diào)試。4.3 檢查點(diǎn)讓AI任務(wù)進(jìn)度可恢復(fù)長耗時(shí)的AI任務(wù)是最容易猝死的。如果你讓Agent寫一份100頁的報(bào)告跑到第80頁時(shí)進(jìn)程崩潰重啟了任務(wù)就得從頭再來這種體驗(yàn)會(huì)讓人直接想放棄AI。解決辦法是引入檢查點(diǎn)機(jī)制。Agent每一步執(zhí)行完之后把關(guān)鍵狀態(tài)——當(dāng)前進(jìn)度、已收集的資料、中間結(jié)果、下一步計(jì)劃——持久化到數(shù)據(jù)庫或?qū)ο蟠鎯?chǔ)中。崩潰重啟之后先讀取檢查點(diǎn)從最近完成的位置繼續(xù)而不是從零開始。這個(gè)思路和我們寫代碼做斷點(diǎn)調(diào)試一樣的道理。我甚至建議在關(guān)鍵任務(wù)中途給用戶發(fā)送進(jìn)度通知一方面提升體驗(yàn)另一方面等于在暗示系統(tǒng)還活著有問題可以及時(shí)發(fā)現(xiàn)。5. 讓AI不僅活著還活得漂亮調(diào)優(yōu)、成本與護(hù)欄系統(tǒng)穩(wěn)定運(yùn)行只是及格真正的目標(biāo)是讓AI承擔(dān)更多有價(jià)值的任務(wù)同時(shí)成本可控、行為合規(guī)。5.1 參數(shù)調(diào)優(yōu)不要迷信隨機(jī)性很多AI工程新手特別喜歡把temperature調(diào)到0.8、0.9覺得這樣更有創(chuàng)造性。在聊天場景這可能很浪漫但在工程場景這是災(zāi)難——任務(wù)失敗率會(huì)顯著上升。我自己的經(jīng)驗(yàn)是凡是涉及結(jié)構(gòu)化輸出、代碼生成、數(shù)據(jù)處理的任務(wù)temperature盡量往低里調(diào)在0到0.3之間。需要?jiǎng)?chuàng)意發(fā)散的場景也最好不要超過0.7否則可以在任務(wù)里顯式注入多樣性需求比如說請(qǐng)?zhí)峁┤N不同角度的方案而不是靠調(diào)高溫度賭運(yùn)氣。另一個(gè)容易被忽略的參數(shù)是max_tokens。如果不設(shè)置或者設(shè)得過大模型的輸出可能會(huì)陷入不必要的冗長同時(shí)成本飆升。建議根據(jù)任務(wù)類型給max_tokens一個(gè)合理上限并在輸出超限時(shí)截?cái)嗖⒆詣?dòng)補(bǔ)充提示避免任務(wù)直接失敗。5.2 成本控制讓AI長期活著的前提是燒得起一個(gè)AI系統(tǒng)即使技術(shù)再穩(wěn)如果成本失控也會(huì)被業(yè)務(wù)叫停這也是一種死亡。所以我一般會(huì)在成本上做三件事。一是路由分層。簡單任務(wù)走便宜的小模型復(fù)雜任務(wù)才走貴的大模型。你可以用一個(gè)前置分類器判斷任務(wù)難度或者用規(guī)則匹配關(guān)鍵詞。二是上下文壓縮。這是成本大頭。很多系統(tǒng)運(yùn)行時(shí)間越長塞給模型的歷史消息越多每個(gè)請(qǐng)求都帶著幾萬Token的背景費(fèi)用自然直線上升。建議定期對(duì)歷史對(duì)話做摘要壓縮只保留關(guān)鍵事實(shí)和結(jié)論把完整的低價(jià)值歷史歸檔成文本存儲(chǔ)。三是緩存命中。對(duì)高頻相似問題的答案做語義緩存命中緩存時(shí)直接返回結(jié)果不用調(diào)用模型成本直接降一個(gè)量級(jí)。5.3 護(hù)欄工程系統(tǒng)的不過線底線最后一條是護(hù)欄。AI系統(tǒng)的可控性有一條底線它不能做的事情必須在設(shè)計(jì)層面就攔住而不是靠模型自覺。內(nèi)容安全護(hù)欄是第一步。無論你是做對(duì)話還是生成用戶輸入和模型輸出都要過一層內(nèi)容安全檢測識(shí)別并過濾不當(dāng)內(nèi)容敏感詞、色情、暴力等類別都要覆蓋。很多平臺(tái)上線后出事并不是因?yàn)槟Ｐ蛺阂舛且驗(yàn)闆]有在兩端設(shè)計(jì)攔截。另一個(gè)非常重要但常被忽略的護(hù)欄是數(shù)據(jù)隱私。AI系統(tǒng)會(huì)收集用戶輸入、日志、中間狀態(tài)如果日志未脫敏用戶隱私會(huì)直接暴露在監(jiān)控大數(shù)據(jù)中。建議對(duì)所有包含姓名、電話、郵箱、地址、ID的字段做脫敏替換后再寫入日志。權(quán)限控制也很關(guān)鍵。多Agent系統(tǒng)里不同的Agent應(yīng)該有不同的工具權(quán)限范圍防止低權(quán)限任務(wù)調(diào)用高權(quán)限工具造成越權(quán)操作。這個(gè)和微服務(wù)架構(gòu)里的最小權(quán)限原則一模一樣只不過對(duì)象從服務(wù)變成了AI。6. 常見故障排查實(shí)錄AI系統(tǒng)疑難雜癥速查表這章我把實(shí)操中真正高頻的故障和排查思路整理成一個(gè)速查表形式上看是表格但背后的邏輯都是我在現(xiàn)場摸爬滾出來的。故障現(xiàn)象常見根因排查思路與解決建議模型輸出越來越重復(fù)、像復(fù)讀機(jī)上下文累積舊信息、溫度太低檢查上下文壓縮策略輪次過多時(shí)摘要?dú)v史適當(dāng)上調(diào)temperature到0.3Agent反復(fù)調(diào)用同一個(gè)工具不停止缺少循環(huán)檢測和退出條件設(shè)置最大調(diào)用次數(shù)檢測連續(xù)相同動(dòng)作后終止或換策略偶發(fā)長延遲、大量超時(shí)API限流、節(jié)點(diǎn)冷啟動(dòng)加本地緩存配置限流退避重試核心服務(wù)提前預(yù)熱輸出格式頻繁解析失敗模型穩(wěn)定性差、提示詞約束不夠換更穩(wěn)定的模型在提示詞里給JSON示例加一層格式校驗(yàn)與自動(dòng)修復(fù)響應(yīng)質(zhì)量突然下降上游模型策略變動(dòng)、上下文被污染對(duì)比歷史日志與模型版本檢查是否有錯(cuò)誤內(nèi)容寫入上下文賬單短時(shí)間內(nèi)暴漲Agent失控循環(huán)、上下文無限膨脹立刻看Token消耗Top任務(wù)加循環(huán)熔斷對(duì)長上下文做告警這里有幾個(gè)排障技巧特別值得展開。排查AI變笨問題時(shí)不要只盯著當(dāng)前請(qǐng)求的日志要往前翻幾輪。AI的上下文是一個(gè)累積過程很多時(shí)候是前幾輪的錯(cuò)誤信息被當(dāng)成了事實(shí)后面的推理全被帶偏。在日志系統(tǒng)里把每個(gè)會(huì)話的完整上下文鏈路串起來看遠(yuǎn)比只看單次請(qǐng)求更容易定位。排查Agent卡死時(shí)最快的路徑是看工具調(diào)用序列。打印出每一步的工具名稱、輸入摘要、輸出狀態(tài)和耗時(shí)你就能迅速看出卡在哪個(gè)環(huán)節(jié)。如果工具調(diào)用連續(xù)返回錯(cuò)誤多半是工具定義或權(quán)限配置有問題直接修工具比調(diào)Agent提示詞高效得多。排查成本失控時(shí)我會(huì)在日志里對(duì)每個(gè)請(qǐng)求標(biāo)注Token消耗和成本按任務(wù)類型做聚合。這樣你能一眼看出是哪個(gè)環(huán)節(jié)在燒錢是某個(gè)Agent的循環(huán)還是某個(gè)用戶的超長會(huì)話定位后再針對(duì)性地加限額和告警。還有一個(gè)小技巧給所有模型調(diào)用統(tǒng)一加一層代理層在代理層統(tǒng)一做超時(shí)、重試、緩存、日志埋點(diǎn)這樣即使未來切換底層模型也只需要改代理配置不用翻遍全工程。排查突發(fā)故障還有一個(gè)反直覺的心得不要只盯著AI鏈路崩潰時(shí)的錯(cuò)誤日志要先回滾最近發(fā)布的配置。我踩過最大的坑就是死磕了半天模型提示詞最后發(fā)現(xiàn)是前端同事改了一個(gè)請(qǐng)求字段導(dǎo)致模型輸入結(jié)構(gòu)變了。AI系統(tǒng)牽一發(fā)而動(dòng)全身上線前對(duì)模型輸入結(jié)構(gòu)做回歸測試比什么都重要。以上這些都是我在反復(fù)救活A(yù)I系統(tǒng)的過程中積累的實(shí)踐記錄。白皮書容易寫出云淡風(fēng)輕的架構(gòu)圖但真正讓AI活著的是那些檢查點(diǎn)、熔斷閾值、脫敏規(guī)則、日志鏈路上日復(fù)一日的打磨。如果這篇能幫你少熬夜修一次告警少付一筆失控賬單那它就不算白寫。最后再聊一點(diǎn)個(gè)人體會(huì)AI系統(tǒng)的活著永遠(yuǎn)是一門動(dòng)態(tài)功課。模型在升級(jí)、業(yè)務(wù)在變化、數(shù)據(jù)在積累你今天制定的護(hù)欄和監(jiān)控閾值半年后可能就失效了。所以別把運(yùn)維方案當(dāng)成一錘子買賣每隔一段時(shí)間為你的AI系統(tǒng)做一次體檢——把監(jiān)控指標(biāo)攤開看看測一次故障演練跑一遍降級(jí)流程確認(rèn)所有自愈機(jī)制仍然有效。這個(gè)過程和保養(yǎng)車一樣花不了多少時(shí)間但它能決定你的AI系統(tǒng)是在活著還是在薛定諤地活著。