做 Agent 項目的朋友大概率都經(jīng)歷過一個階段Demo 跑得飛起一上線賬單直接教你做人。我自己就見過一個團(tuán)隊日活不到一千的 Copilot 產(chǎn)品一個月的大模型賬單飆到六位數(shù)。核心原因很直接——Agent 不像普通 API 調(diào)用內(nèi)部要循環(huán)多次大模型推理每次還要把工具返回、歷史記錄、系統(tǒng)提示全部塞回上下文燒 token 的速度肉眼可見。這也就是 openJiuwen X-Router 這個項目出現(xiàn)的背景一套帶自演進(jìn)能力的模型路由系統(tǒng)讓 Agent 在質(zhì)量基本不掉的情況下把大模型成本壓下去接近一半。它適合正在做 Agent 應(yīng)用、被模型賬單搞得頭疼的開發(fā)者也適合想優(yōu)化多模型調(diào)用策略、但又不想手工維護(hù)規(guī)則的人。我先把話說在前面這活兒真正難的不是“路由”本身而是“自演進(jìn)”這三個字——路由策略要自己跟著任務(wù)分布變而不是寫死一套規(guī)則然后等著失靈。下面我把整個設(shè)計思路、核心實現(xiàn)、部署接入和實測數(shù)據(jù)全部拆開講踩過的坑也一并記錄在內(nèi)。1. 先把問題看清楚Agent 的成本到底被誰吃掉了1.1 一次 Agent 任務(wù)的賬單拆開全是流水很多人對 Agent 成本的認(rèn)知還停留在“輸入 token 輸出 token”這種簡單乘法上實際完全不是這么回事。一個普通的“比價查詢 Agent”用戶問一句“幫我對比附近幾家超市的牛奶價格”它在后臺干的事遠(yuǎn)不止一次大模型調(diào)用第一次調(diào)用解析任務(wù)、拆解計劃決定要調(diào)用哪些工具第二次調(diào)用決定調(diào)用什么工具輸出 function call 參數(shù)第三次調(diào)用把工具返回結(jié)果讀進(jìn)來判斷信息是否足夠、要不要繼續(xù)查第四次調(diào)用把最終結(jié)果組織成自然語言回復(fù)用戶有時候還帶 self-reflection后臺還要多一步自我檢查。這還只是理想情況工具調(diào)失敗、結(jié)果不完整重試次數(shù)直接翻倍。更要命的是上下文膨脹。每輪調(diào)用都要把之前的對話歷史、工具輸出全部帶回去任務(wù)進(jìn)行到第 10 輪上下文可能已經(jīng)堆到四五萬 token。如果你給 Agent 配的是頂級 Pro 模型單次任務(wù)燒掉 20 萬到 40 萬 token 完全是常態(tài)折算下來一次任務(wù)幾塊錢甚至十幾塊錢。這里最諷刺的地方在于這些任務(wù)里有相當(dāng)大比例難度并不高完全用不到頂級模型的推理能力。用一個便宜模型輸出效果幾乎沒差別成本卻可能只有原來的十分之一。80% 的簡單流量用著最貴的模型這就是 Agent 成本居高不下的真正原因。1.2 靜態(tài)路由方案為什么在 Agent 場景不中用先澄清一點(diǎn)模型路由并不是個新概念A(yù)PI 網(wǎng)關(guān)層早就有人做了。但市面上很多網(wǎng)關(guān)的路由策略是靜態(tài)規(guī)則最常見的套路是“輸入超過 2000 token 走大模型低于 2000 走小模型”。這種方案在普通接口調(diào)用場景沒什么大問題放到 Agent 場景就漏洞百出。問題出在三個地方長度不等于難度。一個 300 token 的復(fù)雜推理題可能比一個 2000 token 的“復(fù)制粘貼類任務(wù)”難得多。拿長度當(dāng)難度指標(biāo)很容易把簡單任務(wù)送進(jìn)貴模型把復(fù)雜任務(wù)送進(jìn)小模型。語義表達(dá)差異太大。用戶可以換一百種說法問同一件事關(guān)鍵詞規(guī)則永遠(yuǎn)追不上語言表達(dá)的多樣性。今天加一個規(guī)則明天就有新說法漏網(wǎng)。任務(wù)分布是活著的東西。業(yè)務(wù)方改了 Prompt、增刪了工具、上了新功能任務(wù)畫像就漂移了。寫死的路由規(guī)則在寫下的那一刻就已經(jīng)開始過時。所以靜態(tài)路由適合的是相對穩(wěn)定的接口調(diào)用場景在 Agent 這種動態(tài)性極強(qiáng)的場景里過不了幾天就會變成一堆需要不斷打補(bǔ)丁的爛賬。1.3 自演進(jìn)模型路由的本質(zhì)把路由變成閉環(huán)“自演進(jìn)”是 openJiuwen X-Router 區(qū)別于普通路由網(wǎng)關(guān)的核心賣點(diǎn)說白了就是三個環(huán)節(jié)轉(zhuǎn)成一個閉環(huán)路由決策、結(jié)果反饋、策略更新。先由路由器決定這次請求走哪個模型Agent 執(zhí)行完之后驗證器或用戶把結(jié)果質(zhì)量信號傳回來系統(tǒng)定期用這些信號更新路由參數(shù)讓路由策略自己適應(yīng)任務(wù)分布的變化。如果說傳統(tǒng)網(wǎng)關(guān)是一個固定分岔路口那自演進(jìn)路由就是一位有經(jīng)驗的老司機(jī)——他不僅知道這條路怎么走還會根據(jù)路況實時調(diào)整策略。表現(xiàn)為 “這個任務(wù)類型最近用 Lite 模型成功率變低了下次遇到直接走 Pro”。這套能力對 Agent 項目特別關(guān)鍵因為任務(wù)分布永遠(yuǎn)是動態(tài)的路由策略只有跟著動態(tài)走才不會被時間淘汰。2. openJiuwen X-Router 的整體設(shè)計把路由當(dāng)作可學(xué)習(xí)系統(tǒng)來搭2.1 雙層路由架構(gòu)規(guī)則快路徑 模型慢路徑X-Router 第一眼看上去最讓人舒服的設(shè)計是它沒有把所有判斷都交給一個黑盒模型而是拆成了非常清楚的兩個層級。第一層叫規(guī)則層負(fù)責(zé)處理硬約束。比如財務(wù)審計類的請求要強(qiáng)制走 Pro 模型某些用戶要求不降級或者預(yù)算已經(jīng)快觸底了需要熔斷。這層的判斷成本為零、延遲為零主要用來當(dāng)安全兜底不承擔(dān)智能任務(wù)。第二層才是模型層把經(jīng)過規(guī)則層過濾的請求交給一個輕量分類器做語義復(fù)雜度打分輸出三檔結(jié)論lite / mid / pro。也就是說高優(yōu)請求在規(guī)則層就被攔截了剩下的普通流量才輪到路由模型來判斷這樣既保證關(guān)鍵業(yè)務(wù)不出事又讓路由模型只處理它擅長的事情。這個設(shè)計背后有個很實在的考量把規(guī)則和模型混在一起會導(dǎo)致系統(tǒng)更難排查、更難回滾。規(guī)則層是死邏輯模型層是活邏輯分開之后出問題可以很清楚地知道是哪部分出了問題回滾范圍也小得多。2.2 反饋信號從哪來驗證器、用戶反饋、隱式統(tǒng)計路由系統(tǒng)有個天然痛點(diǎn)模型選得對不對要等任務(wù)執(zhí)行完才知道。所以反饋回路是決定自演進(jìn)能不能跑起來的關(guān)鍵。openJiuwen X-Router 的做法是定義標(biāo)準(zhǔn)接口要求 Agent 在任務(wù)執(zhí)行完以后把評估結(jié)果回傳?；貍餍盘栔饕腥愹炞C器Validator信號程序自動檢驗比如 JSON 格式對不對、SQL 能不能跑通過、關(guān)鍵字段是否缺失。這類信號最客觀推薦優(yōu)先接入。顯式反饋用戶實際點(diǎn)了贊還是踩了踩權(quán)重最高。但用戶一般懶得點(diǎn)樣本稀疏只能作為校準(zhǔn)參考。隱式信號Agent 執(zhí)行統(tǒng)計比如這個任務(wù)的調(diào)用輪數(shù)、整體耗時、失敗重試次數(shù)。如果某個請求讓 Agent 反復(fù)重試那大概率是模型能力不夠用。這三類信號最終統(tǒng)一匯總成每個請求的“質(zhì)量得分”作為 X-Router 自演進(jìn)更新的原材料。沒有反饋閉環(huán)的路由是盲人摸象有了反饋閉環(huán)路由系統(tǒng)才算是長了眼睛。2.3 自演進(jìn)閉環(huán)的四個階段監(jiān)控、分析、調(diào)整、灰度X-Router 的自演進(jìn)更新不是邊跑邊改的野路子而是按照標(biāo)準(zhǔn)四階段循環(huán)來做的階段核心動作產(chǎn)出物Monitor 監(jiān)控采集所有請求的路由結(jié)果和反饋信號原始樣本日志、實時指標(biāo)Analyze 分析按任務(wù)類型統(tǒng)計不同模型的成功率和成本模型質(zhì)量對比報表Adjust 調(diào)整基于目標(biāo)函數(shù)優(yōu)化路由閾值和模型分配權(quán)重新一版路由策略參數(shù)Apply 應(yīng)用把新策略灰度發(fā)布邊放量邊觀察指標(biāo)線上策略版本號這套流程下來路由策略變成了一個可以迭代版本的系統(tǒng)而不是一堆不能修改的臨時規(guī)則。每次策略更新都有版本號出問題可以直接回滾。2.4 為什么選擇了在線自演進(jìn)而不是離線訓(xùn)練這個點(diǎn)我在設(shè)計階段糾結(jié)了很久。一開始的設(shè)想是定期離線訓(xùn)練一個路由模型用歷史數(shù)據(jù)批量更新。后來發(fā)現(xiàn)根本跑不通原因也很簡單——Agent 的任務(wù)分布變化太快了。今天上線一個新工具明天用戶的語言習(xí)慣變了離線模型訓(xùn)練一次要幾個小時訓(xùn)練完事上線的已經(jīng)是過時策略。X-Router 最終采用的是在線自演進(jìn)方案并且在策略里加入了 bandit 思想的探索機(jī)制。也就是說大部分流量按當(dāng)前已知的最優(yōu)策略分配但同時保留一小部分流量做隨機(jī)試探。比如 95% 的請求按當(dāng)前模型分配5% 的請求故意送到其他檔位的模型測試效果通過試探樣本的反饋來發(fā)現(xiàn)潛在地更優(yōu)策略。這種探索與利用的平衡保證了系統(tǒng)不會因為固守當(dāng)前策略而錯過更優(yōu)解也不會因為頻繁亂試探而影響大部分流量的體驗。3. X-Router 核心實現(xiàn)路由判定與成本控制的關(guān)鍵細(xì)節(jié)3.1 任務(wù)復(fù)雜度畫像不應(yīng)該只看 Query 長度之前說過用“輸入長度”判斷任務(wù)難度是靜態(tài)路由的死穴。X-Router 的做法是給每個請求構(gòu)建一份“任務(wù)復(fù)雜度畫像”核心評估以下六個維度意圖復(fù)雜度這個請求是要簡單事實查詢還是需要多步推理檢索深度是否需要調(diào)用多個工具或檢索多個數(shù)據(jù)源推理要求答案是直接從資料里復(fù)制還是需要從多條信息中歸納推導(dǎo)輸出格式復(fù)雜度只需要一段話還是需要結(jié)構(gòu)化 JSON、表格、圖表風(fēng)險等級任務(wù)內(nèi)容是否涉及財務(wù)、醫(yī)療等高風(fēng)險決策上下文規(guī)模預(yù)期歷史輪數(shù)較多、上下文較長時對模型的長期記憶能力有更高要求實際實現(xiàn)時并沒有追求每個維度的絕對精確而是保證相對排序的穩(wěn)定。拿意圖復(fù)雜度來說它做到的是“能區(qū)分出這個任務(wù)大概率是簡單的還是復(fù)雜的”而不是試圖給出一個絕對評分。追求絕對精確只會讓特征工程變成無底洞。3.2 路由分類器為什么不用 LLM而是輕量模型有一個非常自然的想法是讓一個大模型來當(dāng)路由器由它判斷請求的復(fù)雜度再決定要不要升級。我在調(diào)研初期確實認(rèn)真考慮過很快就否了——因為這么做等于往路徑上插入了一次額外的大模型調(diào)用既增加了 token 開銷又給整個 Agent 加了幾百毫秒的延遲。路由的意義是省錢路由器本身卻在燒錢這筆賬怎么算都不劃算。X-Router 的最終方案是embedding 模型加一個極淺的 MLP 分類器。輸入由 query 的 embedding 向量和手工特征的拼接向量組成輸出是 lite / mid / pro 三檔的概率分布。因為分類器非常輕量單次判斷延遲可以壓縮到幾十毫秒以內(nèi)成本幾乎可以忽略。下面貼一段簡化版的路由判定邏輯方便理解整體流程import numpy as np def route_request(query_text, feature_vector, router_model, embed_fn): # 1. 規(guī)則的硬約束檢查 if is_forced_pro(query_text): return pro if is_blocked_or_budget_over(query_text): return lite # 2. 計算 embedding query_embedding embed_fn(query_text) # 3. 拼接 query_embedding 和手工特征 merged np.concatenate([query_embedding, feature_vector]) # 4. 分類器輸出三檔概率 prob router_model.predict_proba([merged])[0] # [p_lite, p_mid, p_pro] # 5. 按閾值決定路由結(jié)果 if prob[2] 0.6: # pro 概率高 - 走強(qiáng)模型 return pro elif prob[1] 0.5: # mid 概率較高 - 走中等模型 return mid else: return lite這里的閾值不是寫死不動的自演進(jìn)過程中會動態(tài)調(diào)整。Adjust 階段干的事情說白了就是拿著歷史反饋數(shù)據(jù)重新計算這三個檔位的最優(yōu)判定邊界。3.3 成本控制不能只靠路由還要有預(yù)算熔斷路由只能決定“這次請求走哪個模型”但一個完整的成本控制方案還需要在更高一層做預(yù)算管理。X-Router 在路由層實現(xiàn)了軟性熔斷機(jī)制。具體做法是按租戶、按天設(shè)置預(yù)算桶。每一次路由請求都會估算即將消耗的 token 成本從預(yù)算桶里預(yù)扣。當(dāng)預(yù)算快到紅線時路由系統(tǒng)會自動把策略向低成本方向偏移本來走 mid 的請求降到 lite本來走 pro 的核心鏈路以外的請求也降到 mid。預(yù)算見底時觸發(fā)硬熔斷要么拒絕服務(wù)要么全部流量降到最低成本模型保證業(yè)務(wù)不斷。這個機(jī)制的價值在于成本是可預(yù)知、可控制的。不然就算有路由月底賬單依然可能超支失控。3.4 自演進(jìn)策略的安全網(wǎng)質(zhì)量底線與版本回滾自演進(jìn)這個詞聽起來很美好但也潛藏風(fēng)險系統(tǒng)為了降低成本會不會把越來越多的請求壓向小模型導(dǎo)致整體質(zhì)量緩慢下滑這是任何自動調(diào)優(yōu)系統(tǒng)都繞不開的失控風(fēng)險。X-Router 在設(shè)計中配置了三層安全網(wǎng)質(zhì)量閾值自動兜底如果某個任務(wù)類型的 Lite 模型成功率低于設(shè)定值比如 85%策略會自動把這些請求回歸到 Pro 模型。策略版本管理每一次 Adjust 產(chǎn)生的策略都有版本號任何異常都可以秒級回滾到上一個穩(wěn)定版本。人工熔斷開關(guān)出現(xiàn)緊急問題時可以一鍵凍結(jié)所有策略更新把系統(tǒng)切回純靜態(tài)規(guī)則模式。這三層安全網(wǎng)的價值在于系統(tǒng)可以自演進(jìn)但它的邊界永遠(yuǎn)受業(yè)務(wù)安全約束。我一直認(rèn)為做自演進(jìn)系統(tǒng)的人必須時刻警惕“全自動”這三個字真正的全自動不是沒有剎車而是剎車永遠(yuǎn)在旁邊等著。4. 實操接入把 X-Router 接到 Agent 項目的完整步驟4.1 接入對業(yè)務(wù)代碼的侵入比想象中小得多X-Router 上線之前團(tuán)隊最擔(dān)心的是 Agent 代碼要大改。真正接完才發(fā)現(xiàn)因為它在實現(xiàn)上兼容 OpenAI SDK 的協(xié)議接入基本是無感的——只需要把 Agent 原本請求的 base_url 改成 X-Router 的網(wǎng)關(guān)地址并在請求頭里帶上租戶標(biāo)識原有代碼的 model 參數(shù)即便保持不變路由器也會接管真實的模型選擇。這對 LangChain、Dify、AutoGen 這類框架來說非常友好框架內(nèi)部的 Model 調(diào)用不感知底層變化省掉了大量改造工作量。如果以后想下線 X-Router把 base_url 改回去就完成回退沒有任何歷史包袱。4.2 環(huán)境準(zhǔn)備與啟動用 Docker 拉起來就能跑實際部署 openJiuwen X-Router 的流程比想象中順暢。整個系統(tǒng)包含兩部分路由網(wǎng)關(guān)本體和反饋分析組件官方給了 Docker Compose 編排一條命令就能把整套環(huán)境拉起來。啟動前要準(zhǔn)備兩項基本配置一是路由分類器和 embedding 模型的模型服務(wù)地址二是 Agent 側(cè)反饋上報 API 的對接密鑰。下面是一段簡化版配置文件的關(guān)鍵字段說明router: model_pool: lite: endpoint: http://lite-model-service:8000/v1 api_key: sk-xxx weight: 0.6 mid: endpoint: http://mid-model-service:8000/v1 api_key: sk-xxx weight: 0.3 pro: endpoint: http://pro-model-service:8000/v1 api_key: sk-xxx weight: 0.1 default_route: mid safety: min_lite_success_rate: 0.85 budget_lock_enabled: true force_pro_whitelist: - finance_audit - medical_consult feedback: endpoint: http://x-router-feedback:9000/report validation_header: x-request-id模型池的 weight 字段是最開始的路由權(quán)重這個值只影響初始狀態(tài)系統(tǒng)跑起來之后自演進(jìn)過程會根據(jù)反饋數(shù)據(jù)逐步修改實際分配比例。配置階段不需要去精調(diào)權(quán)重重點(diǎn)是把策略和熔斷開關(guān)設(shè)好。4.3 反饋上報接口怎么對接x-request-id 是關(guān)鍵路由出結(jié)果之后質(zhì)量反饋必須回傳否則自演進(jìn)閉環(huán)就是空轉(zhuǎn)。X-Router 要求 Agent 在發(fā)起第一次路由請求時拿到一個 x-request-id整個任務(wù)執(zhí)行過程中所有相關(guān)調(diào)用都攜帶這個 ID任務(wù)結(jié)束后統(tǒng)一上報驗證結(jié)論。上報邏輯一般在兩個地方接入一是在 Agent 框架完成工具調(diào)用后馬上把結(jié)構(gòu)化結(jié)果發(fā)給驗證器做自動校驗二是用戶界面收到顯式點(diǎn)贊或點(diǎn)踩時把這些信號通過反饋上報 API 傳回去。真實項目中 I 建議先做自動驗證器的信號因為這是唯一可以全量覆蓋的信號源顯式用戶反饋可以后續(xù)慢慢補(bǔ)。4.4 灰度發(fā)布先讓 10% 流量試水自演進(jìn)系統(tǒng)上線最忌諱一步到位全量切換。推薦做法是按流量灰度推進(jìn)先把 10% 的流量切到 X-Router保持全部請求映射到 Pro 模型這一步只是驗證協(xié)議和網(wǎng)絡(luò)鏈路路由層暫時不改變模型決策。下個階段開啟路由決策但路由閾值設(shè)得非常保守只有極度明顯的簡單任務(wù)才分配給 Lite 模型。觀察成功率。逐步放開閾值和探索比例讓自演進(jìn)真正跑起來每調(diào)一次版本就等一個完整的反饋統(tǒng)計周期。整個過程至少經(jīng)歷兩到三個灰度階段切忌跨階段冒進(jìn)。5. 落地實測50% 成本下降是怎么算出來的5.1 測試場景與對照組設(shè)計我們最終在三個場景做了實測分別對應(yīng) Agent 應(yīng)用最典型的三種形態(tài)場景任務(wù)特征對照組實驗組客服 Agent大量重復(fù)問答少量復(fù)雜投訴全量 Pro 模型X-Router 自動路由RAG 知識庫助手事實檢索為主少量多跳推理全量 Pro 模型X-Router 自動路由數(shù)據(jù)分析 Agent工具調(diào)用頻繁結(jié)構(gòu)化輸出多全量 Pro 模型X-Router 自動路由對照組保留原有全量 Pro 模型配置實驗組在同樣流量下接 X-Router所有業(yè)務(wù)代碼和 Prompt 嚴(yán)格保持一致唯一變量就是模型路由策略。每個場景跑了完整一周避免拿一天數(shù)據(jù)拍腦袋下結(jié)論。5.2 實測數(shù)據(jù)與成本核算實測跑完以后三個場景的匯總數(shù)據(jù)如下指標(biāo)對照組實驗組變化Lite 模型流量占比0%58%~65%新增Mid 模型流量占比0%15%~22%新增Pro 模型流量占比100%15%~25%大幅下降整體任務(wù)成功率99.2%97.6%下降 1.6%平均單次任務(wù)延遲3.8s3.2s下降 0.6s每周大模型 API 費(fèi)用基準(zhǔn) 100%48.2%下降 51.8%成本下降接近 52%和項目目標(biāo)高度吻合。成功率從 99.2% 降到 97.6%這個差異在多數(shù)場景下業(yè)務(wù)側(cè)可以接受但必須說明的是金融、醫(yī)療這類容錯率極低的場景絕對不能用同一套標(biāo)準(zhǔn)。實驗組延遲反而更低原因是輕量模型的響應(yīng)速度更快抵消了路由層帶來的少量延遲。5.3 為什么下降一半而不是更多放開膽子的話成本其實還能再往下壓。實驗組里 Pro 15%~25% 的流量如果全部強(qiáng)行降到 mid成本至少再降 10 個百分點(diǎn)。但我們沒這么做原因很實際小模型偶爾犯錯的樣本全集中在那些最復(fù)雜的推理鏈上強(qiáng)行壓價會踩到質(zhì)量紅線反而得不償失。另外要說清楚50% 這個數(shù)字不是每個項目都能復(fù)現(xiàn)的。能不能省這么多高度依賴任務(wù)分布中簡單任務(wù)的比例。如果某個 Agent 本身就是做復(fù)雜推理的簡單任務(wù)占比很低那路由能優(yōu)化的空間天然就有限。判斷一個項目適不適合上路由標(biāo)準(zhǔn)只有一條簡單任務(wù)占比是否足夠高。6. 常見問題與排查技巧實錄6.1 路由全部被派到 Pro 模型成本沒降上線后發(fā)現(xiàn)賬單變化不大先別急著罵路由算法大概率是反饋環(huán)節(jié)斷了或者規(guī)則層太嚴(yán)。第一個要查的是反饋上報接口有沒有收到數(shù)據(jù)如果反饋為空自演進(jìn)策略會默認(rèn)保守傾向于把請求全送到 Pro 模型。第二個要查的是 force_pro 白名單是不是把大量普通請求都寫進(jìn)去了。我見過有團(tuán)隊圖省事直接把整個租戶加進(jìn)白名單那路由自然等于沒生效。6.2 Lite 模型經(jīng)常把簡單任務(wù)答錯如果簡單任務(wù)的小模型成功率低于設(shè)定閾值優(yōu)先懷疑的應(yīng)該是任務(wù)分類畫像不準(zhǔn)確而不是模型本身太弱。處理思路是先把答錯的樣本撈出來逐個查看驗證器的判定依據(jù)看看這些請求是真難還是驗證器太嚴(yán)格。另一個常見原因是 embedding 模型質(zhì)量不夠區(qū)分不開語義相近但難度差異很大的任務(wù)這時候該做的是換更好的 embedding 模型。6.3 如何判斷自演進(jìn)閉環(huán)真的在生效看策略版本變更記錄是最直觀的方法。如果系統(tǒng)跑了一周路由策略版本號和初始版本完全沒有變化說明閉環(huán)沒轉(zhuǎn)起來。正常狀態(tài)下系統(tǒng)每隔一兩個反饋統(tǒng)計周期就會微調(diào)一次路由參數(shù)可能是閾值偏移一點(diǎn)點(diǎn)可能是某個任務(wù)分類的模型分配發(fā)生變化。版本號不動的系統(tǒng)等于沒接自演進(jìn)。6.4 上線一段時間后效果緩慢退化這個問題我踩過最深的坑。起初以為策略是穩(wěn)定的放養(yǎng)一段時間后成功率悄悄往下掉賬單又開始慢慢往上爬。事后定位原因就是任務(wù)分布漂移了業(yè)務(wù)加了新工具用戶提問方式也變了舊的策略版本沒有及時跟上。解決辦法是把策略自動更新的頻率提上去同時給 Monitor 階段加上告警當(dāng)某任務(wù)類型的成功率連續(xù)異常下降時就自動觸發(fā)策略重算而不是等周會復(fù)盤時才發(fā)現(xiàn)。6.5 問題排查速查表現(xiàn)象主要原因排查方向路由全部走 Pro反饋為空 / 白名單過寬檢查反饋上報率和 force_pro 配置Lite 成功率過低任務(wù)畫像不準(zhǔn) / Embedding 區(qū)分度弱撈失敗樣本、驗證驗證器閾值成本下降不明顯簡單任務(wù)占比低 / 策略未更新統(tǒng)計任務(wù)分布、查看策略版本變動策略版本一直不變自演進(jìn)閉環(huán)斷了檢查 Analyze 定時任務(wù)和反饋數(shù)據(jù)量效果逐漸退化任務(wù)分布漂移調(diào)整策略更新頻率、觸發(fā)自動重算告警延遲上升路由分類器耗時過高優(yōu)化 Embedding 和 MLP 的推理鏈路這整套項目做完我個人最大的體會是模型路由不是一個“選個模型就完了”的體力活它是一個需要反饋、迭代、灰度、回滾支撐的系統(tǒng)工程。如果你現(xiàn)在正準(zhǔn)備給 Agent 項目降本我建議先別一頭扎進(jìn)路由算法里第一步把反饋數(shù)據(jù)接扎實了比什么奇技淫巧都管用。最后再分享一個小技巧路由策略的更新永遠(yuǎn)不要一次性調(diào)到底每次只調(diào)一個維度留足觀察期才能在省錢和質(zhì)量之間找到那條真正穩(wěn)的曲線。