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