開(kāi)門見(jiàn)山說(shuō)一句如果你正在做智能體類應(yīng)用大概率已經(jīng)經(jīng)歷過(guò)來(lái)自賬單的驚嚇。一個(gè)看起來(lái)并不復(fù)雜的問(wèn)答任務(wù)最后卻消耗了幾十萬(wàn)token一個(gè)本該三步結(jié)束的工具調(diào)用因?yàn)槟Ｐ屠@來(lái)繞去的思考而變成十幾步。這些問(wèn)題如果不在設(shè)計(jì)階段就處理等Agent跑起來(lái)之后再去優(yōu)化成本會(huì)呈指數(shù)級(jí)上升。這篇主要講三件事資源感知優(yōu)化、推理技術(shù)、評(píng)估與監(jiān)控。這三者放在一起本質(zhì)上是在解決同一個(gè)問(wèn)題讓智能體不僅“能做”而且“做得起、做得快、做得好”。很多人把資源感知當(dāng)成省錢工具其實(shí)不止。一次長(zhǎng)時(shí)間運(yùn)行的Agent任務(wù)如果上下文越來(lái)越長(zhǎng)響應(yīng)速度會(huì)越來(lái)越慢最終可能直接超時(shí)。資源問(wèn)題會(huì)傳導(dǎo)到產(chǎn)品體驗(yàn)、穩(wěn)定性和可觀測(cè)性是Agent能否從Demo走向生產(chǎn)的核心約束。所以這期的內(nèi)容不聊概念全部按可落地的思路來(lái)講。1. 資源感知優(yōu)化讓智能體像老會(huì)計(jì)一樣精打細(xì)算1.1 資源感知不是提前壓預(yù)算而是讓Agent知道自己還能花多少首先要糾正一個(gè)誤區(qū)資源感知優(yōu)化不是把所有Prompt壓縮到極致也不是一律選用小模型。這些東西如果做得太激進(jìn)Agent會(huì)變得“聽(tīng)不懂人話”最終靠重試和反復(fù)運(yùn)行來(lái)補(bǔ)救總體成本反而更高。我理解的資源感知是Agent在每一步行動(dòng)時(shí)都清楚自己當(dāng)前還有多少Token預(yù)算、多少步驟預(yù)算、多少成本限額并能根據(jù)這些約束主動(dòng)調(diào)整策略。比如當(dāng)上下文還剩15000個(gè)Token時(shí)模型應(yīng)當(dāng)決定是否調(diào)用一個(gè)可能返回大量?jī)?nèi)容的工具當(dāng)任務(wù)已經(jīng)消耗了90%預(yù)算但還沒(méi)找到答案時(shí)Agent不應(yīng)該繼續(xù)埋頭執(zhí)行而應(yīng)該明確告訴上層“我建議換一種方式”。本質(zhì)上這就是給Agent加了一個(gè)“大腦里的記賬本”。每一次模型調(diào)用、每一輪工具返回、每一步思考消耗都要被記錄并且反饋到下一步?jīng)Q策中。很多框架已經(jīng)支持usage回傳但真正把usage數(shù)據(jù)當(dāng)決策依據(jù)的項(xiàng)目很少。大多數(shù)情況是日志里記了代碼里沒(méi)用。1.2 先把常見(jiàn)模式的資源消耗摸透再談優(yōu)化先看一張我平時(shí)做設(shè)計(jì)時(shí)經(jīng)常用到的對(duì)照表把常見(jiàn)的Agent模式、主要消耗和優(yōu)化方向放在一起看模式主要資源消耗點(diǎn)典型風(fēng)險(xiǎn)推薦優(yōu)化方向基礎(chǔ)循環(huán)LLM調(diào)用工具執(zhí)行Prompt中的上下文重復(fù)、模型輸出token上下文膨脹響應(yīng)變慢緩存歷史、裁剪對(duì)話、壓縮總結(jié)單輪工具調(diào)用工具返回結(jié)果直接塞進(jìn)上下文工具輸出過(guò)大導(dǎo)致超限截?cái)唷⒔Y(jié)構(gòu)化提取、按需獲取字段檢索增強(qiáng)生成每輪檢索重復(fù)Embedding、文檔片段過(guò)多檢索片段占滿上下文緩存向量、只取關(guān)鍵片段、重排序多Agent協(xié)作多個(gè)模型并行調(diào)用協(xié)商輪次多token按倍數(shù)消耗延遲高限制對(duì)話輪數(shù)、引入仲裁模型自我反思/自我修正重復(fù)生成反思結(jié)果與原答案反思過(guò)度導(dǎo)致成本翻倍設(shè)定反思次數(shù)上限只在小范圍重試長(zhǎng)文檔處理長(zhǎng)文本分段、多輪摘要、壓縮單次處理成本過(guò)高先粗篩再精讀、增量式摘要這張表其實(shí)揭示了一個(gè)規(guī)律Agent消耗資源的真正大頭往往不是回答本身而是“反復(fù)”。上下文反復(fù)攜帶、工具反復(fù)調(diào)用、思考反復(fù)生成、錯(cuò)誤反復(fù)修正。要控制資源最重要的是控制重復(fù)。1.3 三種立刻能用的資源控制手段預(yù)算、緩存、降級(jí)先說(shuō)預(yù)算。很多開(kāi)源Agent框架都有max_iterations這類參數(shù)但它只限制步數(shù)不限制Token和成本。更合理的做法是三元預(yù)算步數(shù)預(yù)算、Token預(yù)算、成本預(yù)算。任意一個(gè)被擊中就觸發(fā)終止或者降級(jí)。舉個(gè)例子可以這樣定義一個(gè)運(yùn)行上下文class AgentBudget: def __init__(self, max_steps, max_cost, max_tokens): self.max_steps max_steps self.max_cost max_cost self.max_tokens max_tokens self.current_steps 0 self.total_cost 0 self.total_tokens 0 def can_continue(self): return ( self.current_steps self.max_steps and self.total_cost self.max_cost and self.total_tokens self.max_tokens ) def register_usage(self, usage_data, cost_data): self.current_steps 1 self.total_tokens usage_data.get(total_tokens, 0) self.total_cost cost_data每次模型返回后把usage和cost注冊(cè)進(jìn)去循環(huán)判斷can_continue。這套邏輯大概半小時(shí)就能接完但對(duì)穩(wěn)定性的提升非常明顯。再說(shuō)緩存。緩存分三層Prompt緩存同一段系統(tǒng)提示詞在大模型側(cè)本身就可能有緩存這部分能省就省不要在每次請(qǐng)求里動(dòng)態(tài)拼接重復(fù)內(nèi)容。工具結(jié)果緩存同一個(gè)查詢條件、同一個(gè)用戶、同一個(gè)工具在5分鐘內(nèi)返回過(guò)相同結(jié)果可以直接復(fù)用。向量檢索緩存相同Query命中的文檔片段結(jié)果可以緩存避免重復(fù)Embedding。第三是降級(jí)。不要全局只用一個(gè)大模型。判斷任務(wù)難度后可以用一條簡(jiǎn)單的路由規(guī)則需要復(fù)雜推理時(shí)走大模型簡(jiǎn)單分類、提取、改寫(xiě)直接走小模型。這個(gè)路由不一定要靠模型來(lái)判用關(guān)鍵詞、參數(shù)數(shù)量、工具類型等規(guī)則就能覆蓋80%的場(chǎng)景。預(yù)算越緊張路由越要前置。2. 推理技術(shù)既要答得對(duì)又要算得快2.1 控制推理深度比控制模型參數(shù)更有效控制推理技術(shù)最容易犯的錯(cuò)是把所有任務(wù)都設(shè)計(jì)成“先讓模型想一遍再回答”。對(duì)于復(fù)雜任務(wù)這沒(méi)問(wèn)題但對(duì)于明確的任務(wù)比如“把這個(gè)地址解析成結(jié)構(gòu)化字段”“將日期轉(zhuǎn)換成時(shí)間戳”讓模型做深度推理就是純浪費(fèi)。如果你檢查一下真實(shí)項(xiàng)目里的賬單會(huì)發(fā)現(xiàn)大量Token都花在了模型重新發(fā)明輪子上。模型在推理時(shí)把JSON schema重新描述了一遍把工具說(shuō)明重新理解了一遍甚至把用戶問(wèn)題轉(zhuǎn)述了一遍。這些都屬于可壓縮成本。一個(gè)比較有效的辦法是在Prompt中顯式設(shè)置推理預(yù)算。不是只設(shè)置max_tokens而是把“推理應(yīng)該多長(zhǎng)”寫(xiě)進(jìn)系統(tǒng)提示詞例如對(duì)于簡(jiǎn)單指令“直接返回結(jié)果不要解釋過(guò)程?！睂?duì)于中等任務(wù)“最多給出三條推理過(guò)程然后直接輸出?！睂?duì)于復(fù)雜任務(wù)“允許分步思考但每步不超過(guò)50個(gè)Token。”這樣模型會(huì)傾向于在給定范圍內(nèi)輸出。濫用長(zhǎng)思考鏈在正確率上不一定有回報(bào)但在賬單上一定有回報(bào)。2.2 用“守門員模式”攔截明顯可以零成本解決的問(wèn)題推理優(yōu)化不是每次都要請(qǐng)大模型出場(chǎng)。很多請(qǐng)求在到達(dá)大模型之前就可以用規(guī)則、函數(shù)或者小模型解決這就是守門員模式。我常寫(xiě)的一個(gè)基礎(chǔ)攔截邏輯大致是這樣def preflight_check(user_input, available_tools): # 1. 如果輸入已經(jīng)是合法JSON直接解析不調(diào)用LLM if looks_like_json(user_input): return parse_and_return(user_input) # 2. 如果用戶明確要求調(diào)用某個(gè)工具且參數(shù)齊全 if extract_intent(user_input) in available_tools: return call_tool_directly(user_input) # 3. 如果這是一個(gè)數(shù)學(xué)計(jì)算或時(shí)間日期查詢 if is_calculator_query(user_input): return run_calculator(user_input) # 4. 以上都不滿足才進(jìn)入LLM return route_to_llm(user_input)這個(gè)模式看起來(lái)簡(jiǎn)單但大多數(shù)人不敢做因?yàn)閾?dān)心規(guī)則太脆。實(shí)際經(jīng)驗(yàn)是只需要攔截掉最明顯的幾個(gè)高頻場(chǎng)景就能省下10%到30%的推理成本而且這些場(chǎng)景的規(guī)則幾乎不會(huì)誤殺。2.3 用結(jié)構(gòu)化輸出壓縮往返次數(shù)推理優(yōu)化另一個(gè)大頭是重試。模型輸出不符合預(yù)期然后解析失敗、再調(diào)用一次模型、再失敗這種循環(huán)比模型本身貴得多。解決思路是把輸出格式從“自由文本”變成“強(qiáng)約束結(jié)構(gòu)”。在調(diào)用模型時(shí)直接聲明輸出JSON Schema并要求模型按Schema返回。如果是工具調(diào)用優(yōu)先使用函數(shù)調(diào)用模式讓模型輸出參數(shù)而不是自由結(jié)果。這里有個(gè)容易被忽略的細(xì)節(jié)點(diǎn)很多模型在輸出結(jié)構(gòu)化對(duì)象時(shí)會(huì)把多余的說(shuō)明文字也帶出來(lái)。要解決可以在解析時(shí)只提取第一個(gè)合法JSON塊其余內(nèi)容全部丟棄不要因?yàn)榕赃叾嗔藥讉€(gè)字就判定失敗并重試。當(dāng)然也不要因?yàn)樾ｒ?yàn)失敗就直接重試整個(gè)推理過(guò)程。更好的做法是如果格式差一點(diǎn)點(diǎn)就做修正如果語(yǔ)義都錯(cuò)了才需要重新走模型。重試本身也應(yīng)該消耗預(yù)算否則模型會(huì)利用“反正可以無(wú)限重來(lái)”的空間反復(fù)嘗試。2.4 并行與串行的選擇該并行時(shí)不要等待推理技術(shù)的另一個(gè)關(guān)鍵點(diǎn)是任務(wù)拆分。當(dāng)一個(gè)Agent任務(wù)需要執(zhí)行多個(gè)獨(dú)立工具調(diào)用時(shí)串行執(zhí)行不僅慢而且每一步都會(huì)把前一步結(jié)果重新塞進(jìn)上下文造成Token重復(fù)增長(zhǎng)。如果工具之間沒(méi)有依賴關(guān)系一定要設(shè)計(jì)成并行調(diào)用。比如同時(shí)查詢天氣、日歷、航班信息這三個(gè)調(diào)用互相獨(dú)立完全可以在同一個(gè)循環(huán)里發(fā)出然后統(tǒng)一接收結(jié)果。并行不僅能降低延遲還能減少上下文里的中間輪次。核心原則能獨(dú)立就并行能合并就合并能緩存就緩存。不過(guò)并行也要有上限不能一次開(kāi)幾十個(gè)線程去調(diào)外部接口。一般我會(huì)給Agent設(shè)置一個(gè)“最大并發(fā)工具數(shù)”默認(rèn)3到5個(gè)避免外部服務(wù)限流或者下游系統(tǒng)被打爆。運(yùn)行時(shí)還要有超時(shí)控制單個(gè)工具超過(guò)10秒就標(biāo)記失敗并繼續(xù)其他任務(wù)。3. 評(píng)估與監(jiān)控沒(méi)有觀測(cè)感的智能體就是一只深不見(jiàn)底的黑箱3.1 先定義“好”再把“好”變成可測(cè)指標(biāo)很多項(xiàng)目把Agent寫(xiě)好以后靠人工點(diǎn)幾個(gè)頁(yè)面覺(jué)得“效果不錯(cuò)”就上線了。這在技術(shù)評(píng)審上還湊合一旦用戶規(guī)模上來(lái)問(wèn)題根本沒(méi)法定位。評(píng)估和監(jiān)控的前提是先有一套統(tǒng)一指標(biāo)。我自己常用的Agent效果指標(biāo)體系如下指標(biāo)類別具體指標(biāo)用途任務(wù)成功率目標(biāo)是否完成、最終回答是否滿足要求判斷Agent有沒(méi)有能力效率指標(biāo)完成步數(shù)、耗時(shí)、總Token數(shù)判斷Agent有沒(méi)有繞路穩(wěn)定指標(biāo)超時(shí)率、失敗率、重試次數(shù)判斷Agent可不可靠成本指標(biāo)單任務(wù)成本、模型調(diào)用次數(shù)判斷Agent值不值得跑質(zhì)量指標(biāo)工具調(diào)用正確率、上下文命中率判斷中間決策是否準(zhǔn)確這套指標(biāo)不是給監(jiān)控面板看的它必須能拆到每一次運(yùn)行里。一個(gè)任務(wù)為什么花了20步拆開(kāi)看可能是某一步反復(fù)調(diào)用了同一個(gè)工具一個(gè)任務(wù)為什么Token消耗巨大拆開(kāi)看可能是某一個(gè)中間結(jié)果太大了。不能只看最終結(jié)果過(guò)程指標(biāo)才是定位問(wèn)題的關(guān)鍵。3.2 離線評(píng)估用“考場(chǎng)”把Agent的底細(xì)摸清楚在把Agent投入線上之前最好先建一個(gè)離線評(píng)估集。不要追求規(guī)模大要追求覆蓋到真實(shí)場(chǎng)景。至少包含三類樣本簡(jiǎn)單指令明確、單步能完成用于檢驗(yàn)基礎(chǔ)執(zhí)行能力。復(fù)雜任務(wù)需要多步推理、工具聯(lián)動(dòng)用于檢驗(yàn)規(guī)劃能力。邊界場(chǎng)景缺參數(shù)、條件沖突、需要拒絕執(zhí)行用于檢驗(yàn)安全能力。評(píng)估腳本里需要同時(shí)校驗(yàn)最終結(jié)果和中間過(guò)程。最終結(jié)果可以用字符串匹配、語(yǔ)義相似度或LLM裁判來(lái)打分中間過(guò)程要檢查“是否調(diào)用了預(yù)期工具”“參數(shù)是否正確”“是否出現(xiàn)了多余步驟”。這一步比最終結(jié)果評(píng)估更重要因?yàn)楹芏噱e(cuò)誤會(huì)在中間環(huán)節(jié)被補(bǔ)救掉但補(bǔ)救本身也意味著資源浪費(fèi)。離線評(píng)估不是做一次就結(jié)束。每次修改Prompt、模型或工具邏輯都應(yīng)該重跑同一套基線集。我個(gè)人習(xí)慣把評(píng)估結(jié)果寫(xiě)入每次提交的備注里確?！靶Ч兒谩笔怯袛?shù)據(jù)支撐的而不是“感覺(jué)變好”。3.3 線上監(jiān)控每次Agent動(dòng)作都要能回放監(jiān)控的第一原則所有關(guān)鍵信息都要落日志。不要只記錄最終答案要記錄每一個(gè)步驟的輸入、輸出、模型名稱、Token用量、耗時(shí)、工具名、參數(shù)、異常信息。舉個(gè)例子一次運(yùn)行的日志可以這樣組織{ trace_id: a1b2c3, session_id: user-123-session-456, step: 2, model: large-model-v3, input_tokens: 4521, output_tokens: 126, cost_usd: 0.012, latency_ms: 834, tool_name: search_documents, tool_arguments: {q: site architecture}, error: null }每行日志都必須帶上trace_id和session_id。這樣一旦線上出現(xiàn)高成本任務(wù)或異?；卮鹂梢灾苯影颜麠l鏈路拉出來(lái)復(fù)盤而不是對(duì)著一個(gè)錯(cuò)誤信息猜。監(jiān)控指標(biāo)上至少要有四塊面板成本、延遲、錯(cuò)誤率、Token消耗分布。成本面板要能按用戶、按模型、按工具下鉆延遲面板要能按模型和工具維度分析錯(cuò)誤率面板要重點(diǎn)盯“同一工具連續(xù)失敗”和“Agent進(jìn)入死循環(huán)”Token分布面板要看上下文重復(fù)率和高消耗單步。3.4 用“死循環(huán)檢測(cè)”保護(hù)運(yùn)行時(shí)智能體最常見(jiàn)的線上事故就是陷入某個(gè)回路反復(fù)執(zhí)行。比如Agent發(fā)現(xiàn)查詢結(jié)果不夠調(diào)用搜索搜索返回更多結(jié)果又把結(jié)果全部塞進(jìn)上下文繼續(xù)搜索……這種循環(huán)不消耗步驟預(yù)算嗎不一定因?yàn)楹芏嗨姥h(huán)里的每一步都算步驟預(yù)算但步驟預(yù)算往往設(shè)置得很大。我建議至少做三件事設(shè)置最大步驟限制默認(rèn)不超過(guò)10到15步。設(shè)置“同一工具重復(fù)調(diào)用檢測(cè)”同一工具連續(xù)調(diào)用超過(guò)3次且參數(shù)相似立即終止。設(shè)置“狀態(tài)無(wú)變化檢測(cè)”如果前后兩輪的工具結(jié)果和模型輸出沒(méi)有實(shí)質(zhì)差異就說(shuō)明在空轉(zhuǎn)。這些檢測(cè)優(yōu)先級(jí)很高比模型本身是否聰明更重要。因?yàn)槟Ｐ团紶枙?huì)犯糊涂但系統(tǒng)不能跟著一起糊涂。4. 從資源感知到運(yùn)營(yíng)的閉環(huán)一個(gè)可以直接抄作業(yè)的最小樣板4.1 給Agent循環(huán)加裝“儀表盤限速器”把資源感知、推理優(yōu)化、評(píng)估監(jiān)控串起來(lái)的方式不是去改每一個(gè)Prompt而是在Agent運(yùn)行循環(huán)外加一層統(tǒng)一運(yùn)行時(shí)。這層運(yùn)行時(shí)負(fù)責(zé)預(yù)檢、預(yù)算判斷、模型路由、結(jié)構(gòu)化校驗(yàn)、日志埋點(diǎn)、循環(huán)檢測(cè)。一個(gè)最小實(shí)現(xiàn)可以這樣寫(xiě)def run_agent_with_guard(agent, user_input, config): budget AgentBudget( max_stepsconfig[max_steps], max_costconfig[max_cost], max_tokensconfig[max_tokens] ) session_log [] context initialize_context(user_input) while budget.can_continue(): # 預(yù)檢先用規(guī)則/小模型判斷可以直接回復(fù)還是需要工具 preflight_result preflight_check(context) if preflight_result.should_stop: return preflight_result.answer, session_log # 模型路由根據(jù)任務(wù)復(fù)雜度選擇不同模型 selected_model route_to_model(context, budget) # 推理預(yù)算動(dòng)態(tài)設(shè)置max_tokens max_tokens calculate_dynamic_max_tokens(context, selected_model) # 調(diào)用模型 response, usage selected_model.invoke( context, max_tokensmax_tokens, output_schemapreflight_result.expected_schema ) # 記錄用量更新預(yù)算 budget.register_usage(usage, estimate_cost(usage, selected_model)) # 校驗(yàn)輸出 if not validate_step(response): handle_fallback(response, context) continue # 死循環(huán)檢測(cè) if is_repeat_without_change(session_log, response): return 檢測(cè)到重復(fù)執(zhí)行已自動(dòng)終止。, session_log # 記錄日志 session_log.append({ step: budget.current_steps, model: selected_model.name, token_usage: usage, cost: budget.total_cost, response: response, }) # 更新上下文可能裁剪、壓縮 context update_context_under_budget(context, response, budget) return handle_budget_exceeded(context), session_log這里每一步都有對(duì)應(yīng)函數(shù)每個(gè)函數(shù)都不復(fù)雜組合起來(lái)就能覆蓋絕大多數(shù)場(chǎng)景。不需要一開(kāi)始就上一套復(fù)雜框架先把這條循環(huán)跑通再逐步擴(kuò)展。4.2 上線前一定要避開(kāi)的五個(gè)坑第一坑為了省Token把系統(tǒng)提示詞刪得只剩下關(guān)鍵詞。結(jié)果模型輸出質(zhì)量肉眼可見(jiàn)下降靠重試找回效果成本反而更高。提示詞壓縮可以但不能把約束和示例全部刪光。第二坑只設(shè)max_steps不檢查步驟內(nèi)容。步驟上限能擋死循環(huán)但擋不住重復(fù)勞動(dòng)。就算只跑6步可能6步都在調(diào)同一個(gè)工具所以必須有重復(fù)調(diào)用檢測(cè)。第三坑評(píng)估只看最終回答不看中間規(guī)劃。這樣Agent會(huì)變成“結(jié)果對(duì)了但路全走錯(cuò)”的選手。一旦環(huán)境變化或工具參數(shù)變化正確率會(huì)立刻崩塌。第四坑日志里什么都有但沒(méi)有關(guān)聯(lián)ID。離線排查時(shí)根本沒(méi)有辦法把一次用戶會(huì)話的過(guò)程串起來(lái)只能靠時(shí)間戳碰運(yùn)氣。建議從第一天起就強(qiáng)制設(shè)計(jì)trace_id和session_id。第五坑剛開(kāi)始做模型路由就追求“所有任務(wù)都用小模型”最后小模型反復(fù)無(wú)法處理任務(wù)大模型又被降級(jí)整體體驗(yàn)和成本雙輸。路由要先跑日志分析清楚哪些任務(wù)高頻、哪些任務(wù)廉價(jià)再定策略。4.3 迭代節(jié)奏先跑通再省錢再上監(jiān)控如果你現(xiàn)在手頭已經(jīng)有一個(gè)Agent建議按這個(gè)順序改造先把運(yùn)行日志補(bǔ)齊能回放每一步再跑一周線上數(shù)據(jù)找出成本最高的20%任務(wù)針對(duì)這些任務(wù)做預(yù)算限制和模型路由然后離線評(píng)估集跟上最后把監(jiān)控面板和預(yù)警接好。不要一上來(lái)就同時(shí)做所有優(yōu)化。我見(jiàn)過(guò)不少團(tuán)隊(duì)第一天就把Prompt壓縮、動(dòng)態(tài)模型路由、日志埋點(diǎn)全部鋪開(kāi)結(jié)果反而無(wú)法判斷是哪個(gè)改動(dòng)帶來(lái)的效果變化。一步一步來(lái)每一步都有對(duì)照組比一次性改造可維護(hù)得多?；氐介_(kāi)頭那句話智能體不是“在思考”而是在“消費(fèi)”。每一次推理消耗Token每一次工具調(diào)用消耗時(shí)間和成本每一次錯(cuò)誤重試消耗預(yù)算。做資源感知優(yōu)化、推理控制、評(píng)估監(jiān)控不是為了顯得工程嚴(yán)謹(jǐn)而是讓Agent作為產(chǎn)品能長(zhǎng)期立得住。這套東西越早落地后期返工就越少。