做 Agent 項目最頭疼的不是功能跑不通而是每一輪對話都在燒錢。我之前維護的一個內(nèi)部自動化工具早期圖省事所有子任務全部丟給旗艦模型處理上線第一個月賬單出來直接把我從椅子上嚇起來。后來我花了大概一周時間把原來的單一大模型調(diào)用改造成“Claude Haiku 5.5 做子智能體路由”的多層結構整體賬單砍掉了六成左右而且響應速度還快了不少。這篇文章就把我的改造思路、路由設計、關鍵代碼和踩過的坑一起整理出來給正被 Agent 成本壓得難受的開發(fā)者們一個可復用的參考方案。這套東西適合誰如果你正在做客服機器人、文檔自動化、智能問答、工作流編排這類項目每個請求都會調(diào)用大模型 API且任務類型混雜、難度差異大強烈建議花點時間看完。不需要你有多深的多智能體框架基礎我也不是用什么重型框架做的核心就是“輕量模型做判斷 分層路由 子智能體內(nèi)部兜底升級”三招。1. 為什么要做子智能體路由1.1 成本浪費的根源模型能力和任務難度錯配先說一個很樸素但經(jīng)常被忽略的事實不是所有任務都需要最強的模型。我當時那個自動化工具主要處理的是用戶的自然語言請求可能是“幫我查一下上周的報表數(shù)據(jù)”也可能是“分析一下這份二十頁文檔里的關鍵風險點”。前者只要做關鍵詞抽取和數(shù)據(jù)庫查詢后者需要長上下文理解和深層推理。這兩種任務放在同一個模型下處理其實是一種資源錯配攔住所有請求的要是旗艦級模型才能保證最難的場景不出錯但代價就是大量簡單任務也在按旗艦模型的價格計費。這就好比請一位資深專家專門幫你接電話記錄留言偶爾讓他做個高難度決策當然沒問題但是如果每天 90% 的時間都在做簡單的信息轉達那這個用人成本就徹底浪費了。我當時的調(diào)用結構就是這種“高射炮打蚊子”的狀態(tài)。另一個容易被忽略的是 token 消耗結構。真實業(yè)務里的任務大部分都是短問題、短輸出比如“把這段文本轉換成 json 格式”“給這篇文章起三個標題”“判斷用戶情緒是正面還是負面”。這些任務即使讓旗艦模型來做它給出的輸出質(zhì)量和小模型并沒有本質(zhì)差距但花費卻可能差出一個數(shù)量級。任務難度和模型能力的錯配才是成本爆炸的核心根源。1.2 路由方案的整體思路和選型考量我最終的方案不是簡單地“簡單任務用輕量模型復雜任務用旗艦模型”這種二選一而是做成了三層結構。第一層是入口路由。所有進來的請求先用 Claude Haiku 5.5 做一個快速預分類判斷這個請求應該進哪個子智能體并且給出一個置信度分數(shù)。第二層是子智能體內(nèi)部執(zhí)行。每個子智能體有自己獨立的 prompt 和工具集同時內(nèi)部也有一套“難度分級”邏輯如果 Haiku 5.5 在執(zhí)行過程中發(fā)現(xiàn)任務實際難度超出自身能力比如推理鏈變得很長或者用戶反復追問需要綜合多份文檔會自動升級到更強的模型。第三層是結果校驗和兜底重試。關鍵對話我們會在輕量模型輸出后做一次結構化校驗不合格就重新路由到強模型。選 Claude Haiku 5.5 作為路由判斷的核心原因很直接它便宜、延遲低而且對分類和抽取這類“判斷型任務”的完成質(zhì)量非常高。路由層本質(zhì)上是一個低成本的“調(diào)度員”它不需要寫多好的長文只需要準確判斷任務類型和難度就夠了。用旗艦模型做這個判斷當然更準一點但那個開銷會讓路由本身失去性價比。另外我用的是函數(shù)調(diào)用的方式來實現(xiàn)路由決策而不是讓模型自由發(fā)揮這樣可以減少輸出格式不穩(wěn)定的問題。1.3 模型組合方案的選擇經(jīng)過一段時間的對比我最終把任務分成三檔對應三種模型策略檔位典型任務默認模型兜底升級策略輕量檔意圖分類、格式轉換、關鍵詞抽取、短文本摘要、簡單問答Claude Haiku 5.5結果校驗不通過時升級到中端模型中端檔多步驟信息整理、帶工具調(diào)用的數(shù)據(jù)查詢、中等長度文檔理解中端模型推理復雜時升級到旗艦模型旗艦檔長文檔綜合分析、復雜代碼調(diào)試、深度規(guī)劃、多輪復雜推理旗艦模型無直接使用最強能力這個分層邏輯本質(zhì)上是把任務難度和模型能力做了一次匹配。一開始我也想只用“輕量 旗艦”兩檔但實測發(fā)現(xiàn)很多任務介于兩者之間直接給旗艦太貴給輕量又容易出錯中間檔剛好能接住這部分流量。三層下來流量分布大概是 55% 落在輕量檔、35% 落在中端檔、10% 落在旗艦檔。這正是成本能大幅下降的核心原因只有少數(shù)請求真正動用了高價模型。2. 子智能體路由的核心設計2.1 路由目標識別任務類型和難度路由層的核心目標只有兩個判斷任務類型決定進哪個子智能體評估任務難度決定默認用哪個檔位的模型。這兩件事合在一起本質(zhì)是一次多標簽分類。我給路由層設計的輸出是結構化 JSON比如{ task_type: data_query, difficulty: easy, confidence: 0.93, reason: user requests a simple report lookup, requires_tools: [database_query], escalation_hint: false }為了讓 Claude Haiku 5.5 穩(wěn)定輸出這個結構我在系統(tǒng)提示詞里明確給出了可選的 task_type 枚舉列表并且要求它只輸出 JSON所有字段必填。這里有個關鍵經(jīng)驗不要讓它自由生成字段而是要給出固定的 schema否則后面解析代碼會寫得很痛苦。另外我在路由層還做了一個“是否升級”的初步判斷字段 escalation_hint。比如用戶的問題是“幫我查一下這個訂單的發(fā)貨狀態(tài)”任務簡單、不需要升級路由層能高置信度識別但如果用戶的問題是“幫我根據(jù)這三份政策文件擬一個合規(guī)建議”哪怕任務類型明確難度字段也應該標記為 hard直接進入旗艦檔。這個判斷并不需要多高深的推理但要非常細致地定義邊界尤其要注意從句子的長度、需求中的指令數(shù)量、是否涉及多文檔來源來推斷。任務的第一步如果分錯后面整個智能體鏈條都會跑偏所以路由層的準確性是整個系統(tǒng)的命脈。為了確保準確我建議把路由層的 prompt 寫成一個“選擇題”模式先是任務說明然后是候選類型列表每個類型給兩到三個典型示例。模型本質(zhì)上是在做模式匹配給它越清晰的選項輸出就越穩(wěn)定。2.2 子智能體內(nèi)部的自適應升級機制入口路由做的是第一次分配但光有這一層還不夠。現(xiàn)實場景里經(jīng)常出現(xiàn)一種情況一個請求聽起來很簡單比如“幫我算一下這個項目的預算”結果真執(zhí)行起來發(fā)現(xiàn)預算表里涉及匯率換算、稅費計算、多版本數(shù)據(jù)對比復雜度遠超預期。所以我給每個子智能體內(nèi)部都加了自適應升級機制不是死板地“路由說簡單就走輕量模型”而是讓子智能體在執(zhí)行過程中持續(xù)監(jiān)測自己的狀態(tài)。我定義了三個升級信號。第一個是結構信號如果工具調(diào)用鏈長度超過了預設閾值比如超過三步說明任務比預想復雜自動升級。第二個是重試信號當模型生成的中間結果出現(xiàn)了解析錯誤、參數(shù)缺失、工具返回空值等問題時觸發(fā)升級。第三個是置信度信號執(zhí)行完關鍵步驟后讓模型給出一個整體信心分低于 0.7 就說明能力不夠需要更強的模型接手。這套機制本質(zhì)上是一個“能力邊界感知器”。輕量模型在某些場景里會“逞強”——它會給出一個看起來很合理的答案但其實是錯的。設置這些監(jiān)控信號之后子智能體可以在犯錯之前察覺到不對勁把請求上交。具體到代碼實現(xiàn)上我會在每個子智能體的執(zhí)行函數(shù)里返回一個額外的 meta 信息包含used_models、tool_call_count、confidence_score和escalated_to四個字段。這樣整條調(diào)用鏈一目了然出問題也能快速定位是哪個環(huán)節(jié)決定的升級。2.3 路由層的完整調(diào)用形態(tài)整個調(diào)用形態(tài)我用文字描述一下不用畫圖譜也能理解。用戶請求進入系統(tǒng)后先經(jīng)過一個入口函數(shù)這個函數(shù)內(nèi)部起一個名為route_task的輕量模型調(diào)用得到 JSON 分類結果。然后根據(jù) task_type 查找路由表路由表中記錄了每個子智能體的處理器函數(shù)以及該智能體的默認模型檔位。之后調(diào)用對應子智能體子智能體內(nèi)部根據(jù)難度字段決定第一次執(zhí)行用的模型并在執(zhí)行過程中根據(jù)升級信號動態(tài)調(diào)整。如果需要升級無非兩種做法一種是把當前上下文原樣拼到下一個模型的 system prompt 里重新執(zhí)行一遍另一種是只讓升級模型“接著寫”把前面輕量模型的思考過程作為一個參考背景。我實測下來第二種對 token 更省但質(zhì)量穩(wěn)定性不如第一種。升級成本高但升級后是新模型全權接手能避免“兩個模型思路打架”的問題。需要注意路由層本身也是一次模型調(diào)用它也會產(chǎn)生 token 消耗。但這筆開銷很小我的路由 prompt 壓縮到了 800 tokens 以內(nèi)加上輸出結構固定單次路由成本大約只有主任務調(diào)用成本的 2%~5%。這才是整個方案成立的關鍵調(diào)度員很便宜分錯了也不心疼。3. 實操過程與關鍵代碼實現(xiàn)3.1 先封裝一個統(tǒng)一的模型調(diào)用客戶端我不建議在業(yè)務代碼里到處寫原生的 API 調(diào)用那樣后期改模型和調(diào)參數(shù)會變成一場災難。我先封裝了一個非常薄的客戶端層統(tǒng)一管理模型名稱、溫度參數(shù)、超時時間和重試次數(shù)。寫代碼前先確認環(huán)境我用的是 Python 3.11API 走的是平臺官方接口依賴庫主要是openai兼容模式的客戶端和pydantic做數(shù)據(jù)校驗項目結構里單獨放一個llm_client.py。# llm_client.py import json import time class LLMClient: def __init__(self, api_key, base_url, default_timeout30): self.api_key api_key self.base_url base_url self.default_timeout default_timeout def _post(self, model, messages, temperature, timeout): # 這部分按你實際使用的 SDK 來寫 # 我用的是兼容 /chat/completions 的接口直接構造 POST 請求 payload { model: model, messages: messages, temperature: temperature, } resp self._raw_post(payload, timeout) return resp def chat(self, model, messages, temperature0.2, timeoutNone): t timeout or self.default_timeout resp_json self._post(model, messages, temperature, t) return resp_json[choices][0][message][content] def chat_json(self, model, messages, temperature0.1): # 強制要求模型返回 JSON 格式 content self.chat(model, messages, temperaturetemperature) try: return json.loads(content) except json.JSONDecodeError: # 這里是高頻坑模型偶爾會把 markdown 代碼塊包在 JSON 外層 # 我用一個簡單的清洗函數(shù)去掉噪音再做一次解析 cleaned self._strip_code_fence(content) return json.loads(cleaned) staticmethod def _strip_code_fence(text): text text.strip() if text.startswith(json): text text[len(json):] if text.startswith(): text text[3:] if text.endswith(): text text[:-3] return text.strip()這個封裝層里有幾個點值得說。第一temperature默認值不能亂給路由判斷和結構化抽取用 0.1~0.2低溫度能明顯減少字段輸出混亂的情況生成類任務可以放到 0.7 以上但那不在這個客戶端的默認范圍里。第二JSON 解析一定要做容錯真實環(huán)境下模型輸出經(jīng)常帶著 Markdown 代碼塊標記不做清洗的話一個json.loads直接暴斃整個鏈路就斷了。3.2 路由函數(shù)與子智能體定義路由函數(shù)是整個系統(tǒng)的中樞。我的做法是定義一組子智能體處理器每個處理器是一個普通的 Python 函數(shù)簽名統(tǒng)一為def handler(context: dict) - dict返回內(nèi)容統(tǒng)一為{reply: str, meta: dict}。# router.py ROUTER_SYSTEM_PROMPT 你是一個任務調(diào)度器。用戶會輸入一個請求你需要輸出一個 JSON字段如下 { task_type: report_query | data_analysis | text_rewrite | image_desc | code_debug | others, difficulty: easy | medium | hard, confidence: 0.0-1.0, requires_tools: [搜索工具名], escalation_hint: false } 規(guī)則 - 只輸出 JSON不要輸出任何解釋文字。 - 如果請求長度很短且需求非常明確difficulty 為 easy。 - 如果請求包含多步驟指令、多文檔引用、長文本分析difficulty 至少為 medium。 - confidence 低于 0.6 時escalation_hint 必須為 true。 def route_task(user_input: str, llm_client: LLMClient): messages [ {role: system, content: ROUTER_SYSTEM_PROMPT}, {role: user, content: user_input}, ] route_result llm_client.chat_json(claude-haiku-5.5, messages) task_type route_result[task_type] difficulty route_result[difficulty] confidence route_result[confidence] escalation route_result.get(escalation_hint, False) handler get_handler(task_type) return { task_type: task_type, difficulty: difficulty, confidence: confidence, handler: handler, escalation_hint: escalation, } def get_handler(task_type: str): # 這里可以用字典映射避免大量 if-else handlers { report_query: handle_report_query, data_analysis: handle_data_analysis, text_rewrite: handle_text_rewrite, image_desc: handle_image_desc, code_debug: handle_code_debug, others: handle_others, } return handlers.get(task_type, handle_others)子智能體的內(nèi)部結構我拿其中一個handle_text_rewrite來舉例。這個子智能體的職責是文本改寫默認模型是輕量檔但當文本長度超過一定閾值或是改寫要求非常高比如要調(diào)整語氣、適配不同平臺風格就會走中端檔。# handlers/text_rewrite.py REWRITE_PROMPT 你是一個文本改寫助手。用戶會給出原文和要求請按照要求改寫并保持核心信息不變。如果原文超過2000字請先輸出一句需要深度加工等待用戶確認后再繼續(xù)。改寫結果需簡潔自然。 def handle_text_rewrite(context: dict, llm_client: LLMClient): original_text context[user_input] demand context.get(demand, ) if len(original_text) 2000: # 明顯的復雜度信號直接走中端檔 model claude-sonnet-5.5 elif 論文 in demand or 專業(yè)術語 in demand or 嚴格格式 in demand: model claude-sonnet-5.5 else: model claude-haiku-5.5 messages [ {role: system, content: REWRITE_PROMPT}, {role: user, content: f原文{original_text}\n要求{demand}}, ] output llm_client.chat(model, messages) return {reply: output, meta: {model_used: model, tool_call_count: 0}}這里面其實藏了一個很關鍵的設計選擇我把難度判斷邏輯做成了顯式規(guī)則 模型動態(tài)判斷的混合體。純靠模型判斷長文本改寫這種特征非常明顯的場景偶爾也會被分錯純靠規(guī)則又覆蓋不了千奇百怪的請求。所以規(guī)則的歸規(guī)則模型的歸模型最后兩條路的結果一起決定走哪個檔位準確率比單一方式高不少。3.3 成本統(tǒng)計與效果實測在看數(shù)字之前先明確一個統(tǒng)計口徑我對比的是改造前和改造后的單月 API 賬單業(yè)務流量基本一致任務樣本相同沒有額外促銷抵扣。改造前所有請求統(tǒng)一走旗艦模型改造后所有請求先過 Claude Haiku 5.5 路由層然后在三個檔位之間分配。我用一個簡化的模擬數(shù)據(jù)來說明方便你理解比例關系指標改造前全旗艦改造后路由分層請求總量100000 次100000 次每次平均輸入 tokens1200012000每次平均輸出 tokens15001500輕量檔流量占比0%55%中端檔流量占比0%35%旗艦檔流量占比100%10%單次平均成本相對值1.0約 0.38總成本相對值1.0約 0.38實際賬單算下來我從原來的每月成本降到了原來的 38% 左右正好是“砍掉六成”的水平。其中路由層自身的開銷因為每次只傳遞不到 1000 個 token所以占比非常小可以忽略不計。響應時間也順手優(yōu)化了輕量檔的平均延遲大約比旗艦模型快了 40%用戶體感明顯更跟手。這個表里的數(shù)據(jù)只是一個基準線。如果你業(yè)務里的簡單任務比例更高比如超過 70%那成本降幅會更大可能會到 70% 以上如果你的任務大多是長文檔綜合分析和復雜代碼那分層收益就沒那么大甚至可能因為路由開銷而不劃算。所以上線這個方案之前我強烈建議先拉一下自己業(yè)務日志里的任務長度和類型分布別盲目套用別人的數(shù)字。4. 常見問題與排查技巧實錄4.1 路由誤判和回退策略路由層最常見的坑就是誤判。比如用戶問“這個功能怎么打不開”它可能被分類成“技術咨詢”但其實是“故障報修”后續(xù)的子智能體 prompt 和工具集就全不對了。我做了兩層防護。第一層是置信度閾值 強制升級。當路由層的 confidence 低于 0.6 時不管難度字段是什么直接把任務升級到中端檔并允許該檔位內(nèi)的模型重新評估路由結果。第二層是結果校驗鉤子。每個子智能體執(zhí)行完后如果發(fā)現(xiàn)輸出中包含“我不確定”“無法回答”“需要更多信息”這類弱信號并且任務屬于 easy 檔就會自動重新走一遍路由流程這次用中端檔模型做二次分類。這個機制的思路不是讓路由層永不犯錯而是讓錯誤有止損點。一次錯誤路由導致的額外成本可能只是正確路由成本的幾倍但總比直接給用戶一個答非所問的結果要好。4.2 延遲與緩存的平衡加了路由層之后鏈路多了一次調(diào)用理論上延遲會變高。但我的實際體驗是因為大多數(shù)任務最終落在了響應更快的輕量模型上整體延遲反而降了。不過還是有兩個點需要提前處理好。第一個是路由超時。路由判斷如果超過 3 秒會嚴重影響用戶體驗所以我在調(diào)用客戶端里單獨設置了更短的超時時間。如果路由調(diào)用超時直接按 medium 難度、走中端檔處理而不是讓用戶無限等待。第二個是緩存設計。同一個用戶短時間內(nèi)反復查詢同一個問題比如“我的訂單到哪了”每次都會觸發(fā)路由和主調(diào)用純屬浪費。我把粗粒度緩存直接掛在路由層前面請求輸入先做一次規(guī)范化比如去掉時間戳、去掉無意義空格然后查緩存命中就直接返回不再調(diào)用任何模型。還有一點和 token 成本直接相關上下文裁剪。子智能體在升級時會把之前的完整對話傳給更強的模型但這里有個坑——舊上下文里可能包含大量無關的中間結果比如路由層的分析、工具調(diào)用的調(diào)試輸出這些對最終答案沒有幫助卻占著寶貴的上下文窗口。我在升級時只傳遞用戶原始問題、工具返回的關鍵數(shù)據(jù)和之前的最終回答中間污染信息全部丟掉。這個操作能讓升級調(diào)用的 token 消耗減少 30% 左右。4.3 質(zhì)量監(jiān)控與回歸測試成本降下來之后最怕的就是質(zhì)量也跟著降。我建了一個非常輕量的回歸集從歷史日志里抽了 200 條請求覆蓋各個任務類型和難度檔位每輪改造后都跑一遍自動對比看輸出答案是否符合預期。這里有一個很實用的技巧讓旗艦模型當裁判。我用旗艦模型對輕量模型的輸出做打分維度包括信息完整性、邏輯一致性和格式正確性。每批抽樣 30 條算平均分低于閾值就告警。這時候旗艦模型的調(diào)用量不需要很大幾百條抽樣而已成本完全可控。另外一定要做 prompt 版本管理。同一個路由 prompt你改了一個字的規(guī)則可能對真實流量的命中率造成幾個百分點的波動。我給每個版本的 system prompt 打一個版本號寫進日志里。這樣一旦線上質(zhì)量出現(xiàn)波動可以馬上回溯是哪個 prompt 版本引起的。4.4 降成本的邊界條件最后聊一下這個方案的反面——什么情況不適合做子智能體路由。如果你的業(yè)務里所有請求都是高難度推理比如全是長文檔綜合分析、復雜代碼生成那路由層的存在幾乎沒有意義因為每次都會命中旗艦檔路由本身還多了一筆開銷。如果你的業(yè)務對延遲極其敏感比如實時語音交互多一次路由調(diào)用會明顯拖慢響應那也不劃算更優(yōu)的方案是直接用單個高質(zhì)量模型加緩存。如果你的任務識別本身就很難比如開放式閑聊用戶下一句要說什么根本無法預判路由分類的準確率會慘不忍睹這時候硬做分層只會把簡單問題復雜化。我當時決定上這套方案是拉過真實日志確認了任務分布里至少有六成屬于簡單到中等難度才敢動手的。這個前置調(diào)研省不了否則就是紙上談兵。結尾做這輪改造我最大的體會不是“換了個便宜的模型”而是把成本管理當成一個路由問題去解決——先分清楚什么任務值多少錢再決定讓誰去干。Claude Haiku 5.5 在這里的角色不是主力干活的而是那個特別省錢的調(diào)度員真正復雜的活它干不了但“判斷活難不難”這件事它干得又快又好。如果你正在被 Agent 賬單困擾我建議你先把任務分布統(tǒng)計出來再按“輕量 中端 旗艦”的檔位去設計路由規(guī)則至少不會虧。最后再分享一個小技巧上線路由方案后別忘了把路由層的每次判斷結果都記錄到日志里然后每周做一次“路由誤判復盤”。我就是在復盤時發(fā)現(xiàn)凡是涉及金額計算的 easy 類請求被分錯的風險特別高于是專門加了一條“金額計算一律升級到中端檔”的硬規(guī)則。這種細節(jié)規(guī)則只能來自實際數(shù)據(jù)任何一個統(tǒng)一的路由模板都替代不了。你業(yè)務里也一定有類似的隱形坑跑一段時間日志就會自己浮出來。 用Claude Haiku 5.5做子智能體路由，Agent成本直降六成
做 Agent 項目最頭疼的不是功能跑不通而是每一輪對話都在燒錢。我之前維護的一個內(nèi)部自動化工具早期圖省事所有子任務全部丟給旗艦模型處理上線第一個月賬單出來直接把我從椅子上嚇起來。后來我花了大概一周時間把原來的單一大模型調(diào)用改造成“Claude Haiku 5.5 做子智能體路由”的多層結構整體賬單砍掉了六成左右而且響應速度還快了不少。這篇文章就把我的改造思路、路由設計、關鍵代碼和踩過的坑一起整理出來給正被 Agent 成本壓得難受的開發(fā)者們一個可復用的參考方案。這套東西適合誰如果你正在做客服機器人、文檔自動化、智能問答、工作流編排這類項目每個請求都會調(diào)用大模型 API且任務類型混雜、難度差異大強烈建議花點時間看完。不需要你有多深的多智能體框架基礎我也不是用什么重型框架做的核心就是“輕量模型做判斷 分層路由 子智能體內(nèi)部兜底升級”三招。1. 為什么要做子智能體路由1.1 成本浪費的根源模型能力和任務難度錯配先說一個很樸素但經(jīng)常被忽略的事實不是所有任務都需要最強的模型。我當時那個自動化工具主要處理的是用戶的自然語言請求可能是“幫我查一下上周的報表數(shù)據(jù)”也可能是“分析一下這份二十頁文檔里的關鍵風險點”。前者只要做關鍵詞抽取和數(shù)據(jù)庫查詢后者需要長上下文理解和深層推理。這兩種任務放在同一個模型下處理其實是一種資源錯配攔住所有請求的要是旗艦級模型才能保證最難的場景不出錯但代價就是大量簡單任務也在按旗艦模型的價格計費。這就好比請一位資深專家專門幫你接電話記錄留言偶爾讓他做個高難度決策當然沒問題但是如果每天 90% 的時間都在做簡單的信息轉達那這個用人成本就徹底浪費了。我當時的調(diào)用結構就是這種“高射炮打蚊子”的狀態(tài)。另一個容易被忽略的是 token 消耗結構。真實業(yè)務里的任務大部分都是短問題、短輸出比如“把這段文本轉換成 json 格式”“給這篇文章起三個標題”“判斷用戶情緒是正面還是負面”。這些任務即使讓旗艦模型來做它給出的輸出質(zhì)量和小模型并沒有本質(zhì)差距但花費卻可能差出一個數(shù)量級。任務難度和模型能力的錯配才是成本爆炸的核心根源。1.2 路由方案的整體思路和選型考量我最終的方案不是簡單地“簡單任務用輕量模型復雜任務用旗艦模型”這種二選一而是做成了三層結構。第一層是入口路由。所有進來的請求先用 Claude Haiku 5.5 做一個快速預分類判斷這個請求應該進哪個子智能體并且給出一個置信度分數(shù)。第二層是子智能體內(nèi)部執(zhí)行。每個子智能體有自己獨立的 prompt 和工具集同時內(nèi)部也有一套“難度分級”邏輯如果 Haiku 5.5 在執(zhí)行過程中發(fā)現(xiàn)任務實際難度超出自身能力比如推理鏈變得很長或者用戶反復追問需要綜合多份文檔會自動升級到更強的模型。第三層是結果校驗和兜底重試。關鍵對話我們會在輕量模型輸出后做一次結構化校驗不合格就重新路由到強模型。選 Claude Haiku 5.5 作為路由判斷的核心原因很直接它便宜、延遲低而且對分類和抽取這類“判斷型任務”的完成質(zhì)量非常高。路由層本質(zhì)上是一個低成本的“調(diào)度員”它不需要寫多好的長文只需要準確判斷任務類型和難度就夠了。用旗艦模型做這個判斷當然更準一點但那個開銷會讓路由本身失去性價比。另外我用的是函數(shù)調(diào)用的方式來實現(xiàn)路由決策而不是讓模型自由發(fā)揮這樣可以減少輸出格式不穩(wěn)定的問題。1.3 模型組合方案的選擇經(jīng)過一段時間的對比我最終把任務分成三檔對應三種模型策略檔位典型任務默認模型兜底升級策略輕量檔意圖分類、格式轉換、關鍵詞抽取、短文本摘要、簡單問答Claude Haiku 5.5結果校驗不通過時升級到中端模型中端檔多步驟信息整理、帶工具調(diào)用的數(shù)據(jù)查詢、中等長度文檔理解中端模型推理復雜時升級到旗艦模型旗艦檔長文檔綜合分析、復雜代碼調(diào)試、深度規(guī)劃、多輪復雜推理旗艦模型無直接使用最強能力這個分層邏輯本質(zhì)上是把任務難度和模型能力做了一次匹配。一開始我也想只用“輕量 旗艦”兩檔但實測發(fā)現(xiàn)很多任務介于兩者之間直接給旗艦太貴給輕量又容易出錯中間檔剛好能接住這部分流量。三層下來流量分布大概是 55% 落在輕量檔、35% 落在中端檔、10% 落在旗艦檔。這正是成本能大幅下降的核心原因只有少數(shù)請求真正動用了高價模型。2. 子智能體路由的核心設計2.1 路由目標識別任務類型和難度路由層的核心目標只有兩個判斷任務類型決定進哪個子智能體評估任務難度決定默認用哪個檔位的模型。這兩件事合在一起本質(zhì)是一次多標簽分類。我給路由層設計的輸出是結構化 JSON比如{ task_type: data_query, difficulty: easy, confidence: 0.93, reason: user requests a simple report lookup, requires_tools: [database_query], escalation_hint: false }為了讓 Claude Haiku 5.5 穩(wěn)定輸出這個結構我在系統(tǒng)提示詞里明確給出了可選的 task_type 枚舉列表并且要求它只輸出 JSON所有字段必填。這里有個關鍵經(jīng)驗不要讓它自由生成字段而是要給出固定的 schema否則后面解析代碼會寫得很痛苦。另外我在路由層還做了一個“是否升級”的初步判斷字段 escalation_hint。比如用戶的問題是“幫我查一下這個訂單的發(fā)貨狀態(tài)”任務簡單、不需要升級路由層能高置信度識別但如果用戶的問題是“幫我根據(jù)這三份政策文件擬一個合規(guī)建議”哪怕任務類型明確難度字段也應該標記為 hard直接進入旗艦檔。這個判斷并不需要多高深的推理但要非常細致地定義邊界尤其要注意從句子的長度、需求中的指令數(shù)量、是否涉及多文檔來源來推斷。任務的第一步如果分錯后面整個智能體鏈條都會跑偏所以路由層的準確性是整個系統(tǒng)的命脈。為了確保準確我建議把路由層的 prompt 寫成一個“選擇題”模式先是任務說明然后是候選類型列表每個類型給兩到三個典型示例。模型本質(zhì)上是在做模式匹配給它越清晰的選項輸出就越穩(wěn)定。2.2 子智能體內(nèi)部的自適應升級機制入口路由做的是第一次分配但光有這一層還不夠。現(xiàn)實場景里經(jīng)常出現(xiàn)一種情況一個請求聽起來很簡單比如“幫我算一下這個項目的預算”結果真執(zhí)行起來發(fā)現(xiàn)預算表里涉及匯率換算、稅費計算、多版本數(shù)據(jù)對比復雜度遠超預期。所以我給每個子智能體內(nèi)部都加了自適應升級機制不是死板地“路由說簡單就走輕量模型”而是讓子智能體在執(zhí)行過程中持續(xù)監(jiān)測自己的狀態(tài)。我定義了三個升級信號。第一個是結構信號如果工具調(diào)用鏈長度超過了預設閾值比如超過三步說明任務比預想復雜自動升級。第二個是重試信號當模型生成的中間結果出現(xiàn)了解析錯誤、參數(shù)缺失、工具返回空值等問題時觸發(fā)升級。第三個是置信度信號執(zhí)行完關鍵步驟后讓模型給出一個整體信心分低于 0.7 就說明能力不夠需要更強的模型接手。這套機制本質(zhì)上是一個“能力邊界感知器”。輕量模型在某些場景里會“逞強”——它會給出一個看起來很合理的答案但其實是錯的。設置這些監(jiān)控信號之后子智能體可以在犯錯之前察覺到不對勁把請求上交。具體到代碼實現(xiàn)上我會在每個子智能體的執(zhí)行函數(shù)里返回一個額外的 meta 信息包含used_models、tool_call_count、confidence_score和escalated_to四個字段。這樣整條調(diào)用鏈一目了然出問題也能快速定位是哪個環(huán)節(jié)決定的升級。2.3 路由層的完整調(diào)用形態(tài)整個調(diào)用形態(tài)我用文字描述一下不用畫圖譜也能理解。用戶請求進入系統(tǒng)后先經(jīng)過一個入口函數(shù)這個函數(shù)內(nèi)部起一個名為route_task的輕量模型調(diào)用得到 JSON 分類結果。然后根據(jù) task_type 查找路由表路由表中記錄了每個子智能體的處理器函數(shù)以及該智能體的默認模型檔位。之后調(diào)用對應子智能體子智能體內(nèi)部根據(jù)難度字段決定第一次執(zhí)行用的模型并在執(zhí)行過程中根據(jù)升級信號動態(tài)調(diào)整。如果需要升級無非兩種做法一種是把當前上下文原樣拼到下一個模型的 system prompt 里重新執(zhí)行一遍另一種是只讓升級模型“接著寫”把前面輕量模型的思考過程作為一個參考背景。我實測下來第二種對 token 更省但質(zhì)量穩(wěn)定性不如第一種。升級成本高但升級后是新模型全權接手能避免“兩個模型思路打架”的問題。需要注意路由層本身也是一次模型調(diào)用它也會產(chǎn)生 token 消耗。但這筆開銷很小我的路由 prompt 壓縮到了 800 tokens 以內(nèi)加上輸出結構固定單次路由成本大約只有主任務調(diào)用成本的 2%~5%。這才是整個方案成立的關鍵調(diào)度員很便宜分錯了也不心疼。3. 實操過程與關鍵代碼實現(xiàn)3.1 先封裝一個統(tǒng)一的模型調(diào)用客戶端我不建議在業(yè)務代碼里到處寫原生的 API 調(diào)用那樣后期改模型和調(diào)參數(shù)會變成一場災難。我先封裝了一個非常薄的客戶端層統(tǒng)一管理模型名稱、溫度參數(shù)、超時時間和重試次數(shù)。寫代碼前先確認環(huán)境我用的是 Python 3.11API 走的是平臺官方接口依賴庫主要是openai兼容模式的客戶端和pydantic做數(shù)據(jù)校驗項目結構里單獨放一個llm_client.py。# llm_client.py import json import time class LLMClient: def __init__(self, api_key, base_url, default_timeout30): self.api_key api_key self.base_url base_url self.default_timeout default_timeout def _post(self, model, messages, temperature, timeout): # 這部分按你實際使用的 SDK 來寫 # 我用的是兼容 /chat/completions 的接口直接構造 POST 請求 payload { model: model, messages: messages, temperature: temperature, } resp self._raw_post(payload, timeout) return resp def chat(self, model, messages, temperature0.2, timeoutNone): t timeout or self.default_timeout resp_json self._post(model, messages, temperature, t) return resp_json[choices][0][message][content] def chat_json(self, model, messages, temperature0.1): # 強制要求模型返回 JSON 格式 content self.chat(model, messages, temperaturetemperature) try: return json.loads(content) except json.JSONDecodeError: # 這里是高頻坑模型偶爾會把 markdown 代碼塊包在 JSON 外層 # 我用一個簡單的清洗函數(shù)去掉噪音再做一次解析 cleaned self._strip_code_fence(content) return json.loads(cleaned) staticmethod def _strip_code_fence(text): text text.strip() if text.startswith(json): text text[len(json):] if text.startswith(): text text[3:] if text.endswith(): text text[:-3] return text.strip()這個封裝層里有幾個點值得說。第一temperature默認值不能亂給路由判斷和結構化抽取用 0.1~0.2低溫度能明顯減少字段輸出混亂的情況生成類任務可以放到 0.7 以上但那不在這個客戶端的默認范圍里。第二JSON 解析一定要做容錯真實環(huán)境下模型輸出經(jīng)常帶著 Markdown 代碼塊標記不做清洗的話一個json.loads直接暴斃整個鏈路就斷了。3.2 路由函數(shù)與子智能體定義路由函數(shù)是整個系統(tǒng)的中樞。我的做法是定義一組子智能體處理器每個處理器是一個普通的 Python 函數(shù)簽名統(tǒng)一為def handler(context: dict) - dict返回內(nèi)容統(tǒng)一為{reply: str, meta: dict}。# router.py ROUTER_SYSTEM_PROMPT 你是一個任務調(diào)度器。用戶會輸入一個請求你需要輸出一個 JSON字段如下 { task_type: report_query | data_analysis | text_rewrite | image_desc | code_debug | others, difficulty: easy | medium | hard, confidence: 0.0-1.0, requires_tools: [搜索工具名], escalation_hint: false } 規(guī)則 - 只輸出 JSON不要輸出任何解釋文字。 - 如果請求長度很短且需求非常明確difficulty 為 easy。 - 如果請求包含多步驟指令、多文檔引用、長文本分析difficulty 至少為 medium。 - confidence 低于 0.6 時escalation_hint 必須為 true。 def route_task(user_input: str, llm_client: LLMClient): messages [ {role: system, content: ROUTER_SYSTEM_PROMPT}, {role: user, content: user_input}, ] route_result llm_client.chat_json(claude-haiku-5.5, messages) task_type route_result[task_type] difficulty route_result[difficulty] confidence route_result[confidence] escalation route_result.get(escalation_hint, False) handler get_handler(task_type) return { task_type: task_type, difficulty: difficulty, confidence: confidence, handler: handler, escalation_hint: escalation, } def get_handler(task_type: str): # 這里可以用字典映射避免大量 if-else handlers { report_query: handle_report_query, data_analysis: handle_data_analysis, text_rewrite: handle_text_rewrite, image_desc: handle_image_desc, code_debug: handle_code_debug, others: handle_others, } return handlers.get(task_type, handle_others)子智能體的內(nèi)部結構我拿其中一個handle_text_rewrite來舉例。這個子智能體的職責是文本改寫默認模型是輕量檔但當文本長度超過一定閾值或是改寫要求非常高比如要調(diào)整語氣、適配不同平臺風格就會走中端檔。# handlers/text_rewrite.py REWRITE_PROMPT 你是一個文本改寫助手。用戶會給出原文和要求請按照要求改寫并保持核心信息不變。如果原文超過2000字請先輸出一句需要深度加工等待用戶確認后再繼續(xù)。改寫結果需簡潔自然。 def handle_text_rewrite(context: dict, llm_client: LLMClient): original_text context[user_input] demand context.get(demand, ) if len(original_text) 2000: # 明顯的復雜度信號直接走中端檔 model claude-sonnet-5.5 elif 論文 in demand or 專業(yè)術語 in demand or 嚴格格式 in demand: model claude-sonnet-5.5 else: model claude-haiku-5.5 messages [ {role: system, content: REWRITE_PROMPT}, {role: user, content: f原文{original_text}\n要求{demand}}, ] output llm_client.chat(model, messages) return {reply: output, meta: {model_used: model, tool_call_count: 0}}這里面其實藏了一個很關鍵的設計選擇我把難度判斷邏輯做成了顯式規(guī)則 模型動態(tài)判斷的混合體。純靠模型判斷長文本改寫這種特征非常明顯的場景偶爾也會被分錯純靠規(guī)則又覆蓋不了千奇百怪的請求。所以規(guī)則的歸規(guī)則模型的歸模型最后兩條路的結果一起決定走哪個檔位準確率比單一方式高不少。3.3 成本統(tǒng)計與效果實測在看數(shù)字之前先明確一個統(tǒng)計口徑我對比的是改造前和改造后的單月 API 賬單業(yè)務流量基本一致任務樣本相同沒有額外促銷抵扣。改造前所有請求統(tǒng)一走旗艦模型改造后所有請求先過 Claude Haiku 5.5 路由層然后在三個檔位之間分配。我用一個簡化的模擬數(shù)據(jù)來說明方便你理解比例關系指標改造前全旗艦改造后路由分層請求總量100000 次100000 次每次平均輸入 tokens1200012000每次平均輸出 tokens15001500輕量檔流量占比0%55%中端檔流量占比0%35%旗艦檔流量占比100%10%單次平均成本相對值1.0約 0.38總成本相對值1.0約 0.38實際賬單算下來我從原來的每月成本降到了原來的 38% 左右正好是“砍掉六成”的水平。其中路由層自身的開銷因為每次只傳遞不到 1000 個 token所以占比非常小可以忽略不計。響應時間也順手優(yōu)化了輕量檔的平均延遲大約比旗艦模型快了 40%用戶體感明顯更跟手。這個表里的數(shù)據(jù)只是一個基準線。如果你業(yè)務里的簡單任務比例更高比如超過 70%那成本降幅會更大可能會到 70% 以上如果你的任務大多是長文檔綜合分析和復雜代碼那分層收益就沒那么大甚至可能因為路由開銷而不劃算。所以上線這個方案之前我強烈建議先拉一下自己業(yè)務日志里的任務長度和類型分布別盲目套用別人的數(shù)字。4. 常見問題與排查技巧實錄4.1 路由誤判和回退策略路由層最常見的坑就是誤判。比如用戶問“這個功能怎么打不開”它可能被分類成“技術咨詢”但其實是“故障報修”后續(xù)的子智能體 prompt 和工具集就全不對了。我做了兩層防護。第一層是置信度閾值 強制升級。當路由層的 confidence 低于 0.6 時不管難度字段是什么直接把任務升級到中端檔并允許該檔位內(nèi)的模型重新評估路由結果。第二層是結果校驗鉤子。每個子智能體執(zhí)行完后如果發(fā)現(xiàn)輸出中包含“我不確定”“無法回答”“需要更多信息”這類弱信號并且任務屬于 easy 檔就會自動重新走一遍路由流程這次用中端檔模型做二次分類。這個機制的思路不是讓路由層永不犯錯而是讓錯誤有止損點。一次錯誤路由導致的額外成本可能只是正確路由成本的幾倍但總比直接給用戶一個答非所問的結果要好。4.2 延遲與緩存的平衡加了路由層之后鏈路多了一次調(diào)用理論上延遲會變高。但我的實際體驗是因為大多數(shù)任務最終落在了響應更快的輕量模型上整體延遲反而降了。不過還是有兩個點需要提前處理好。第一個是路由超時。路由判斷如果超過 3 秒會嚴重影響用戶體驗所以我在調(diào)用客戶端里單獨設置了更短的超時時間。如果路由調(diào)用超時直接按 medium 難度、走中端檔處理而不是讓用戶無限等待。第二個是緩存設計。同一個用戶短時間內(nèi)反復查詢同一個問題比如“我的訂單到哪了”每次都會觸發(fā)路由和主調(diào)用純屬浪費。我把粗粒度緩存直接掛在路由層前面請求輸入先做一次規(guī)范化比如去掉時間戳、去掉無意義空格然后查緩存命中就直接返回不再調(diào)用任何模型。還有一點和 token 成本直接相關上下文裁剪。子智能體在升級時會把之前的完整對話傳給更強的模型但這里有個坑——舊上下文里可能包含大量無關的中間結果比如路由層的分析、工具調(diào)用的調(diào)試輸出這些對最終答案沒有幫助卻占著寶貴的上下文窗口。我在升級時只傳遞用戶原始問題、工具返回的關鍵數(shù)據(jù)和之前的最終回答中間污染信息全部丟掉。這個操作能讓升級調(diào)用的 token 消耗減少 30% 左右。4.3 質(zhì)量監(jiān)控與回歸測試成本降下來之后最怕的就是質(zhì)量也跟著降。我建了一個非常輕量的回歸集從歷史日志里抽了 200 條請求覆蓋各個任務類型和難度檔位每輪改造后都跑一遍自動對比看輸出答案是否符合預期。這里有一個很實用的技巧讓旗艦模型當裁判。我用旗艦模型對輕量模型的輸出做打分維度包括信息完整性、邏輯一致性和格式正確性。每批抽樣 30 條算平均分低于閾值就告警。這時候旗艦模型的調(diào)用量不需要很大幾百條抽樣而已成本完全可控。另外一定要做 prompt 版本管理。同一個路由 prompt你改了一個字的規(guī)則可能對真實流量的命中率造成幾個百分點的波動。我給每個版本的 system prompt 打一個版本號寫進日志里。這樣一旦線上質(zhì)量出現(xiàn)波動可以馬上回溯是哪個 prompt 版本引起的。4.4 降成本的邊界條件最后聊一下這個方案的反面——什么情況不適合做子智能體路由。如果你的業(yè)務里所有請求都是高難度推理比如全是長文檔綜合分析、復雜代碼生成那路由層的存在幾乎沒有意義因為每次都會命中旗艦檔路由本身還多了一筆開銷。如果你的業(yè)務對延遲極其敏感比如實時語音交互多一次路由調(diào)用會明顯拖慢響應那也不劃算更優(yōu)的方案是直接用單個高質(zhì)量模型加緩存。如果你的任務識別本身就很難比如開放式閑聊用戶下一句要說什么根本無法預判路由分類的準確率會慘不忍睹這時候硬做分層只會把簡單問題復雜化。我當時決定上這套方案是拉過真實日志確認了任務分布里至少有六成屬于簡單到中等難度才敢動手的。這個前置調(diào)研省不了否則就是紙上談兵。結尾做這輪改造我最大的體會不是“換了個便宜的模型”而是把成本管理當成一個路由問題去解決——先分清楚什么任務值多少錢再決定讓誰去干。Claude Haiku 5.5 在這里的角色不是主力干活的而是那個特別省錢的調(diào)度員真正復雜的活它干不了但“判斷活難不難”這件事它干得又快又好。如果你正在被 Agent 賬單困擾我建議你先把任務分布統(tǒng)計出來再按“輕量 中端 旗艦”的檔位去設計路由規(guī)則至少不會虧。最后再分享一個小技巧上線路由方案后別忘了把路由層的每次判斷結果都記錄到日志里然后每周做一次“路由誤判復盤”。我就是在復盤時發(fā)現(xiàn)凡是涉及金額計算的 easy 類請求被分錯的風險特別高于是專門加了一條“金額計算一律升級到中端檔”的硬規(guī)則。這種細節(jié)規(guī)則只能來自實際數(shù)據(jù)任何一個統(tǒng)一的路由模板都替代不了。你業(yè)務里也一定有類似的隱形坑跑一段時間日志就會自己浮出來。