1. 這篇文章真正要解決的問題過去半年明顯感覺到一個(gè)現(xiàn)象越來越多團(tuán)隊(duì)開始用 AI 智能體跑真實(shí)業(yè)務(wù)但真正把智能體推到生產(chǎn)環(huán)境的人幾乎都遇到過同一個(gè)尷尬時(shí)刻——任務(wù)執(zhí)行到一半預(yù)算沒了。這里的“預(yù)算”不一定指錢。它可能是 API 的 token 配額可能是上下文窗口的長度上限可能是單次任務(wù)的耗時(shí)上限也可能是用戶給智能體設(shè)定的“最多調(diào)用幾次工具”。無論哪種形式結(jié)果都類似智能體在任務(wù)進(jìn)行到最關(guān)鍵一步時(shí)被硬生生掐斷用戶拿到的不是最終答案而是一堆中間產(chǎn)物、一個(gè)報(bào)錯(cuò)或者干脆是一段沉默。更麻煩的是很多智能體在預(yù)算耗盡前根本不會(huì)提前規(guī)劃。它不知道自己還能用多少 token不知道當(dāng)前任務(wù)還有多長不知道哪些步驟可以放棄、哪些步驟必須保住。于是它只能憑感覺繼續(xù)往前跑直到觸到限制然后“犧牲”——中途退出、返回截?cái)鄡?nèi)容、循環(huán)重試或者給出一個(gè)質(zhì)量明顯下降的結(jié)果。這個(gè)困境的本質(zhì)不是模型能力不夠而是工程預(yù)算約束沒有被納入智能體的設(shè)計(jì)邏輯。一個(gè) AI 智能體如果只想著“完成任務(wù)”不考慮“剩余資源夠不夠完成”在生產(chǎn)環(huán)境里必然出問題。從實(shí)踐看這個(gè)領(lǐng)域真正值得關(guān)注的不是某個(gè)具體框架而是一套“預(yù)算感知”的工程設(shè)計(jì)思路任務(wù)怎么拆、資源怎么分、中途怎么檢查、快耗盡時(shí)怎么降級、最后怎么兜底。這篇文章就圍繞這套思路展開讀完你可以直接照著做把你的智能體從“跑著跑著就犧牲”改造成“預(yù)算再緊也能善終”。2. 智能體“犧牲”的四種典型形態(tài)先梳理一下智能體在預(yù)算耗盡前最常見的四種失敗形態(tài)。只有先能準(zhǔn)確識(shí)別“它正在走向犧牲”才談得上干預(yù)。第一種上下文窗口溢出。現(xiàn)在主流大模型的 context window 雖然越來越大但并不是無限大。智能體在執(zhí)行長任務(wù)時(shí)會(huì)把歷史對話、工具返回結(jié)果、中間文件內(nèi)容不斷塞進(jìn)上下文。當(dāng) token 總數(shù)超過窗口上限模型直接報(bào)錯(cuò)之前的所有工作全部作廢。這種情況在“讀長文檔 多輪工具調(diào)用 生成最終報(bào)告”這類任務(wù)中尤其常見。第二種成本預(yù)算超支。很多智能體部署在線上服務(wù)里按 token 計(jì)費(fèi)。如果任務(wù)沒有事先拆分成本預(yù)算一個(gè)任務(wù)可能調(diào)用幾十次外部 API每次調(diào)用回傳的內(nèi)容又很大最后賬單遠(yuǎn)遠(yuǎn)超出預(yù)期。這種失敗不像上下文溢出那樣有明確的報(bào)錯(cuò)往往是在月底看賬單時(shí)才被發(fā)現(xiàn)但傷害更大。第三種執(zhí)行循環(huán)與死鎖。智能體在某個(gè)子任務(wù)上反復(fù)試錯(cuò)比如同一個(gè)工具失敗后重試、重試后再失敗、再換參數(shù)重試。每輪循環(huán)都在消耗 token 和調(diào)用次數(shù)但進(jìn)度為零。如果沒有明確的循環(huán)上限和輪次限制它會(huì)在預(yù)算耗盡之前一直打轉(zhuǎn)。第四種質(zhì)量靜默下降。這種最隱蔽。有的智能體在接近預(yù)算上限時(shí)不會(huì)直接失敗而是開始“敷衍”——摘要越來越短、關(guān)鍵細(xì)節(jié)丟失、跳過核驗(yàn)步驟、直接假設(shè)某個(gè)外部調(diào)用成功。結(jié)果接口返回 200但答案質(zhì)量已經(jīng)嚴(yán)重縮水線上用戶根本不會(huì)知道。這四種形態(tài)都有一個(gè)共同點(diǎn)問題不是出在“模型不會(huì)做”而是出在“系統(tǒng)沒讓它在有限資源下學(xué)會(huì)取舍”。傳統(tǒng)軟件里有超時(shí)時(shí)間、有熔斷、有降級策略到了 AI 智能體這里很多團(tuán)隊(duì)反而把這些工程常識(shí)忘了直接把所有決策權(quán)交給模型。所以下面要講的就是把傳統(tǒng)分布式系統(tǒng)的“預(yù)算 - 熔斷 - 降級 - 兜底”思路遷移到智能體架構(gòu)里。3. 核心概念預(yù)算感知智能體在動(dòng)手寫代碼之前需要先統(tǒng)一幾個(gè)術(shù)語。這些詞后面會(huì)反復(fù)出現(xiàn)如果概念不清楚看代碼時(shí)容易卡住。Token 預(yù)算Token Budget一次任務(wù)允許消耗的最大 token 數(shù)量。它可能是錢API 計(jì)費(fèi)也可能是長度上下文窗口限制在工程上統(tǒng)一建模為一個(gè)數(shù)值即可。上下文窗口Context Window模型單次處理文本的最大長度。所有歷史消息、工具結(jié)果、系統(tǒng)提示詞都要放在這個(gè)窗口里。預(yù)算管理必須考慮“窗口剩余空間”即使你的費(fèi)用預(yù)算還很充足。任務(wù)分解Task Decomposition把一個(gè)復(fù)雜任務(wù)拆成若干子任務(wù)每個(gè)子任務(wù)有獨(dú)立的資源預(yù)算。拆分之后單個(gè)子任務(wù)的失敗不會(huì)拖垮整個(gè)任務(wù)。檢查點(diǎn)Checkpoint智能體在某個(gè)子任務(wù)完成后主動(dòng)檢查當(dāng)前預(yù)算消耗和任務(wù)進(jìn)度決定繼續(xù)、壓縮、降級還是終止。優(yōu)雅降級Graceful Degradation當(dāng)預(yù)算不足時(shí)智能體主動(dòng)放棄非必要環(huán)節(jié)只保證核心目標(biāo)完成。比如不生成詳細(xì)圖表只給結(jié)論不重跑驗(yàn)證只標(biāo)記“未驗(yàn)證”。兜底輸出Fallback Output當(dāng)所有策略都無法讓任務(wù)完整完成時(shí)至少要返回一個(gè)可用的中間結(jié)果而不是報(bào)錯(cuò)或空白。把這些概念串起來就是一套“預(yù)算感知型智能體”的架構(gòu)任務(wù)開始前規(guī)劃預(yù)算 → 執(zhí)行中定期檢查 → 接近上限時(shí)觸發(fā)壓縮或降級 → 徹底不夠時(shí)給出兜底結(jié)果。下面進(jìn)入實(shí)操用一個(gè)最小示例把這套機(jī)制跑通。4. 環(huán)境準(zhǔn)備與最小代碼骨架本文示例使用 Python 3.9重點(diǎn)演示思想不綁定具體框架。你可以用 LangChain、Dify、Coze 或自研封裝核心邏輯是一樣的。準(zhǔn)備以下環(huán)境Python 3.9 及以上版本任意國產(chǎn)或國際大模型的 API 訪問權(quán)限本文用openai風(fēng)格的接口做演示實(shí)際請?zhí)鎿Q為你的服務(wù)商 SDK一個(gè)支持異步的任務(wù)隊(duì)列不強(qiáng)制但推薦便于做超時(shí)控制先建立一個(gè)最小工程目錄agent-budget-demo/ ├── main.py # 入口演示完整流程 ├── agent.py # 智能體執(zhí)行器 ├── budget.py # 預(yù)算管理器 ├── summarize.py # 上下文摘要工具 └── requirements.txt # 依賴第一步先寫預(yù)算管理器。它負(fù)責(zé)記錄“總預(yù)算、已消耗、剩余量”并提供檢查接口。# 文件路徑agent-budget-demo/budget.py from dataclasses import dataclass dataclass class Budget: total_tokens: int used_tokens: int 0 property def remaining(self) - int: return self.total_tokens - self.used_tokens property def used_ratio(self) - float: return self.used_tokens / self.total_tokens def consume(self, tokens: int) - None: self.used_tokens tokens def can_continue(self) - bool: return self.remaining 0 class BudgetManager: 預(yù)算管理器維護(hù)總預(yù)算、子任務(wù)預(yù)算和全局檢查邏輯。 當(dāng)剩余比例低于閾值時(shí)通過回調(diào)通知執(zhí)行器做降級。 def __init__(self, total_tokens: int): self.budget Budget(total_tokenstotal_tokens) self.history [] def record(self, stage: str, tokens: int) - None: self.budget.consume(tokens) self.history.append( { stage: stage, tokens: tokens, remaining: self.budget.remaining, } ) def check(self) - dict: ratio self.budget.used_ratio if ratio 0.8: return {status: critical, ratio: ratio} if ratio 0.5: return {status: warning, ratio: ratio} return {status: normal, ratio: ratio}這個(gè)類本身很簡單但它決定了后面所有降級動(dòng)作的觸發(fā)時(shí)機(jī)。比較關(guān)鍵的設(shè)計(jì)是預(yù)算消耗不是模型返回后統(tǒng)一算而是每個(gè)階段都做記錄。這樣能精確定位“哪個(gè)子任務(wù)吃掉了最多 token”。5. 任務(wù)分解與上下文瘦身第二步是任務(wù)分解和上下文壓縮工具。任務(wù)分解解決“任務(wù)太大不能一口氣做完”的問題上下文壓縮解決“歷史信息太多塞不進(jìn)去”的問題。這里用一段偽代碼演示典型的任務(wù)分解流程# 文件路徑agent-budget-demo/main.py節(jié)選 def plan_subtasks(goal: str) - list[dict]: 把一個(gè)復(fù)雜任務(wù)拆成子任務(wù)列表。 每個(gè)子任務(wù)包含任務(wù)內(nèi)容、預(yù)計(jì)消耗級別、是否可降級。 return [ { id: read_core_doc, prompt: 閱讀并理解核心文檔提取關(guān)鍵要點(diǎn), level: high, degradable: False, }, { id: load_supplement, prompt: 加載補(bǔ)充材料補(bǔ)充背景信息, level: medium, degradable: True, }, { id: search_latest, prompt: 搜索最新動(dòng)態(tài)更新數(shù)據(jù), level: medium, degradable: True, }, { id: write_report, prompt: 輸出最終報(bào)告, level: high, degradable: False, }, ]核心原則哪些步驟是不可舍棄的哪些步驟可以在預(yù)算緊張時(shí)跳過。比如“搜索最新動(dòng)態(tài)”可以降級為“基于已有知識(shí)生成”但“輸出最終報(bào)告”不能省。然后寫上下文摘要工具。它的作用是當(dāng)歷史內(nèi)容太多時(shí)把前面的長文本壓縮成更短的摘要保留關(guān)鍵信息釋放上下文空間。# 文件路徑agent-budget-demo/summarize.py def summarize_messages(client, messages: list[dict], target_tokens: int) - list[dict]: 將歷史消息壓縮成一段摘要替換原消息列表。 注意這是一個(gè)簡化示例實(shí)際場景需根據(jù)消息結(jié)構(gòu)做更細(xì)粒度的處理。 text \n.join(msg[content] for msg in messages) prompt ( 請把下面這段對話歷史壓縮為不超過300字的技術(shù)摘要。 保留任務(wù)目標(biāo)、已完成的步驟、尚未完成的關(guān)鍵點(diǎn)、關(guān)鍵數(shù)據(jù)與結(jié)論。 不要添加新內(nèi)容不要漏掉核心信息。\n\n f{text} ) resp client.chat.completions.create( modelyour-model-name, messages[{role: user, content: prompt}], max_tokenstarget_tokens, ) summary resp.choices[0].message.content return [{role: system, content: f歷史摘要{summary}}]這個(gè)函數(shù)的本質(zhì)是用一次額外的模型調(diào)用來“買”上下文空間。它本身會(huì)消耗 token所以觸發(fā)時(shí)機(jī)必須謹(jǐn)慎只有在下一次任務(wù)需要更長上下文、且當(dāng)前剩余空間不足時(shí)才調(diào)用。否則壓縮行為本身反而會(huì)加速預(yù)算耗盡。6. 智能體執(zhí)行器預(yù)算監(jiān)控與優(yōu)雅降級第三步是核心執(zhí)行器。它把前面所有模塊串起來在每一步執(zhí)行后調(diào)用預(yù)算管理器檢查狀態(tài)根據(jù)狀態(tài)決定下一步動(dòng)作。# 文件路徑agent-budget-demo/agent.py import time class BudgetAwareAgent: def __init__(self, client, budget_manager: BudgetManager): self.client client self.budget_manager budget_manager self.history [] self.results {} def run(self, goal: str, subtasks: list[dict]) - dict: # 這里的 MAX_LOOP 和 DEFAULT_RETRY 應(yīng)該從配置讀取 MAX_LOOP 3 for sub in subtasks: status self.budget_manager.check() if status[status] critical: if sub[degradable]: print(f[降級] 跳過可降級任務(wù): {sub[id]}) self.results[sub[id]] {skipped: True} continue else: print(f[關(guān)鍵] 任務(wù)不可跳過嘗試壓縮后繼續(xù): {sub[id]}) # 簡化示例每次任務(wù)調(diào)用模型 token_cost self._execute_subtask(sub[prompt], MAX_LOOP) # 記錄預(yù)算消耗 self.budget_manager.record(sub[id], token_cost) # 每次執(zhí)行后檢查 current self.budget_manager.check() print(f[預(yù)算] 任務(wù) {sub[id]} 消耗 {token_cost} token f剩余 {self.budget_manager.budget.remaining}狀態(tài) {current[status]}) # 如果已經(jīng)臨界先嘗試壓縮歷史 if current[status] critical: self._safe_compress() return self._finalize() def _execute_subtask(self, prompt: str, max_loop: int) - int: 執(zhí)行單個(gè)子任務(wù)返回消耗的 token 數(shù)。 # 這里是實(shí)際的模型調(diào)用邏輯 # 注意設(shè)置單次調(diào)用的 max_tokens 上限避免單次調(diào)用把預(yù)算吃光 ... return 123 # 示例返回值 def _safe_compress(self): 安全壓縮上下文。這里需要判斷當(dāng)前剩余空間是否還能支持一次壓縮調(diào)用。 if self.budget_manager.budget.remaining 500: print([警示] 剩余預(yù)算不足以支撐上下文壓縮放棄壓縮操作) return print([壓縮] 觸發(fā)上下文摘要壓縮) def _finalize(self) - dict: 兜底輸出無論任務(wù)完成度如何都返回一個(gè)結(jié)構(gòu)化結(jié)果。 return { status: completed, results: self.results, budget_history: self.budget_manager.history, }這個(gè)執(zhí)行器里最關(guān)鍵的是_safe_compress里的判斷壓縮本身也要花 token如果預(yù)算剩余連壓縮調(diào)用都支撐不起就不能做壓縮而是應(yīng)該直接進(jìn)入輸出階段。很多智能體項(xiàng)目在預(yù)算優(yōu)化時(shí)反而把預(yù)算耗盡就是因?yàn)楹雎粤恕皟?yōu)化動(dòng)作本身有成本”。再看一下_execute_subtask應(yīng)該如何處理單次調(diào)用的超時(shí)和重試。AI 智能體最常見的預(yù)算殺手不是正常調(diào)用而是失敗后的無腦重試# 文件路徑agent-budget-demo/agent.py補(bǔ)充方法 def _call_with_retry(self, messages: list[dict], max_tokens: int, retry_times: int 2) - str: 帶重試的模型調(diào)用。每一次重試都會(huì)消耗 token 所以重試上限必須顯式配置不能依賴模型自行判斷。 attempt 0 while attempt retry_times: try: resp self.client.chat.completions.create( modelyour-model-name, messagesmessages, max_tokensmax_tokens, timeout30, ) return resp.choices[0].message.content except Exception as e: attempt 1 if attempt retry_times: raise RuntimeError(f模型調(diào)用失敗已重試 {retry_times} 次: {e}) # 退避等待 time.sleep(1 * attempt) raise RuntimeError(unreachable)重試次數(shù)、單次調(diào)用的max_tokens、超時(shí)時(shí)間這三項(xiàng)是預(yù)算管理的底層基礎(chǔ)設(shè)施。如果這三項(xiàng)沒有顯式配置上層再多的預(yù)算策略都是空談。7. 完整示例一個(gè)長報(bào)告生成任務(wù)下面用一個(gè)完整場景把所有模塊跑通。任務(wù)讓智能體基于一份內(nèi)部技術(shù)文檔搜索補(bǔ)充資料生成一份 2000 字的調(diào)研報(bào)告。完整主程序# 文件路徑agent-budget-demo/main.py from budget import BudgetManager from agent import BudgetAwareAgent def main(): # 1. 初始化預(yù)算。假設(shè)總預(yù)算只有 5000 token方便模擬臨界場景。 budget_manager BudgetManager(total_tokens5000) # 2. 初始化智能體 client create_client() # 替換為真實(shí)的 client 初始化 agent BudgetAwareAgent(client, budget_manager) # 3. 定義任務(wù) goal 基于內(nèi)部文檔撰寫一份關(guān)于容器化部署最佳實(shí)踐的調(diào)研報(bào)告 subtasks [ {id: read_core_doc, prompt: 閱讀理解內(nèi)部核心文檔, level: high, degradable: False}, {id: load_supplement, prompt: 加載補(bǔ)充材料提取背景信息, level: medium, degradable: True}, {id: search_latest, prompt: 搜索社區(qū)最新實(shí)踐動(dòng)態(tài), level: medium, degradable: True}, {id: write_report, prompt: 生成最終調(diào)研報(bào)告, level: high, degradable: False}, ] result agent.run(goal, subtasks) print(執(zhí)行完成最終結(jié)果結(jié)構(gòu)) print(result[status]) for stage in result[budget_history]: print(stage) def create_client(): # 這里替換為你的模型客戶端初始化 # 例如 openai.OpenAI(api_key..., base_url...) return None if __name__ __main__: main()運(yùn)行這個(gè)示例會(huì)看到每一階段的預(yù)算消耗情況。當(dāng)預(yù)算進(jìn)入 critical 狀態(tài)后load_supplement和search_latest這類可降級任務(wù)會(huì)被跳過而read_core_doc和write_report會(huì)保留。最終輸出的budget_history能清楚看到每一步花了多少 token這對于定位智能體的預(yù)算黑洞非常有用。8. 運(yùn)行結(jié)果與效果驗(yàn)證這個(gè)示例不執(zhí)行真實(shí)模型調(diào)用所以不會(huì)看到真實(shí)的 token 消耗數(shù)字。但它的價(jià)值在于提供了一個(gè)可觀測、可調(diào)整的預(yù)算管理骨架。要驗(yàn)證這個(gè)架構(gòu)是否真的有效建議做三組實(shí)驗(yàn)實(shí)驗(yàn)一基準(zhǔn)測試。不啟用預(yù)算管理讓智能體直接跑同一個(gè)任務(wù)記錄總耗時(shí)、總 token 消耗、任務(wù)完成度。實(shí)驗(yàn)二預(yù)算充足測試。把預(yù)算設(shè)成 20000 token啟用預(yù)算管理跑同一個(gè)任務(wù)。理想結(jié)果是任務(wù)完整完成驗(yàn)證預(yù)算管理不會(huì)在預(yù)算充足時(shí)誤觸發(fā)降級。實(shí)驗(yàn)三預(yù)算緊張測試。把預(yù)算壓到 5000 token再跑同一個(gè)任務(wù)。核心驗(yàn)證點(diǎn)是智能體是否做到了“保核心、舍外圍”最終是否返回了報(bào)告而不是中途報(bào)錯(cuò)。判斷標(biāo)準(zhǔn)主要有三條預(yù)算緊張時(shí)任務(wù)是否仍然返回結(jié)構(gòu)化結(jié)果即使報(bào)告精度下降。預(yù)算充足時(shí)是否沒有出現(xiàn)不必要的降級操作。預(yù)算歷史記錄是否完整能定位每一步的 token 消耗。如果實(shí)驗(yàn)三出現(xiàn)了“智能體在 write_report 階段直接報(bào)錯(cuò)”的情況說明預(yù)算分配策略有問題核心任務(wù)沒有預(yù)留足夠的預(yù)算。這時(shí)應(yīng)該調(diào)整各子任務(wù)的預(yù)算權(quán)重讓不可降級的任務(wù)優(yōu)先獲得預(yù)算。更穩(wěn)妥的做法是在任務(wù)規(guī)劃階段就預(yù)分配預(yù)算def plan_subtasks_with_budget(subtasks: list[dict], total_budget: int) - list[dict]: 按優(yōu)先級給子任務(wù)預(yù)分配預(yù)算。 不可降級任務(wù)分配 60% 預(yù)算可降級任務(wù)共享剩余 40%。 hard_budget int(total_budget * 0.6) soft_budget total_budget - hard_budget for sub in subtasks: if not sub[degradable]: sub[allocated_budget] hard_budget // sum( 1 for s in subtasks if not s[degradable] ) else: sub[allocated_budget] soft_budget // sum( 1 for s in subtasks if s[degradable] ) return subtasks這種預(yù)先分配的方式比執(zhí)行過程中實(shí)時(shí)判斷更可控。它把“不確定性”從運(yùn)行時(shí)轉(zhuǎn)移到了設(shè)計(jì)時(shí)這正是我們在工程上更希望看到的狀態(tài)。9. 常見問題與排查方法預(yù)算管理相關(guān)的智能體問題有個(gè)特點(diǎn)表面現(xiàn)象五花八門根因往往集中在幾個(gè)地方。下面列出高頻問題。問題現(xiàn)象可能原因排查方式解決方案智能體運(yùn)行到中后期突然報(bào)“context length exceeded”沒有提前做上下文壓縮歷史消息堆積過多查看預(yù)算歷史中的 token 增長曲線重點(diǎn)看每次工具返回的原始內(nèi)容大小在子任務(wù)完成后立即對結(jié)果做摘要限制單次工具返回的最大長度任務(wù)沒完成但預(yù)算還剩很多智能體卻不肯繼續(xù)循環(huán)重試次數(shù)過多或單次任務(wù) max_tokens 設(shè)置過小導(dǎo)致多次往返查看歷史記錄中的重試日志和每次調(diào)用的完成原因合理設(shè)置單次調(diào)用的 max_tokens增加單次任務(wù)的 token 上限降級后核心輸出質(zhì)量嚴(yán)重下降用戶無法接受降級策略只做了“跳過”沒有做“簡化”檢查降級分支的具體邏輯為不可跳過的任務(wù)提供“簡化模式”只輸出結(jié)論、不寫詳細(xì)論證壓縮歷史后模型遺忘關(guān)鍵背景摘要提示詞沒有明確要求保留關(guān)鍵細(xì)節(jié)檢查摘要工具的 prompt在摘要提示詞中明確“必須保留具體數(shù)字、日期、決策結(jié)論、未完成事項(xiàng)”預(yù)算檢查頻率太低發(fā)現(xiàn)時(shí)已經(jīng)來不及檢查點(diǎn)只在子任務(wù)結(jié)束時(shí)觸發(fā)在模型調(diào)用前、收到響應(yīng)后都增加檢查點(diǎn)把預(yù)算檢查做成 decorator 或中間件強(qiáng)制每次調(diào)用前檢查多子任務(wù)并行執(zhí)行時(shí)總預(yù)算失控并行任務(wù)各自計(jì)算消耗沒有共享預(yù)算檢查是否使用全局 BudgetManager 實(shí)例用集中式預(yù)算管理器或使用 Redis 之類的外部存儲(chǔ)做共享計(jì)數(shù)真正容易踩坑的是第一行。很多團(tuán)隊(duì)做智能體時(shí)只關(guān)注 prompt 寫得對不對忽略了“工具返回結(jié)果”的大小。實(shí)際上一次搜索返回的 20 條網(wǎng)頁摘要可能就吃掉 3000 token。如果不限制工具返回內(nèi)容的長度上下文窗口再大也撐不住。10. 最佳實(shí)踐與工程建議預(yù)算管理這件事越早設(shè)計(jì)越好。等智能體已經(jīng)寫了很多提示詞和工具調(diào)用邏輯后再加預(yù)算管理改動(dòng)成本會(huì)高很多。以下幾點(diǎn)是從生產(chǎn)環(huán)境實(shí)踐中提煉的建議。第一把預(yù)算設(shè)計(jì)成可配置項(xiàng)而不是寫死在代碼里。預(yù)算值、降級閾值、壓縮觸發(fā)比例應(yīng)該放在配置中心或環(huán)境變量中。不同場景的任務(wù)預(yù)算需求差異很大生成一份周報(bào)可能 3000 token 就夠了做一份行業(yè)調(diào)研可能需要 30000 token。把預(yù)算參數(shù)化才能做到“同一套代碼適配不同任務(wù)”。配置示例agent: budget: default_total_tokens: 10000 critical_ratio: 0.8 warning_ratio: 0.5 context: max_history_tokens: 4000 compress_ratio: 0.5 retry: max_attempts: 2 timeout_seconds: 30 degradable: enabled: true第二所有 AI 調(diào)用都要有超時(shí)和重試上限且重試次數(shù)必須小于等于 2。很多智能體“預(yù)算耗盡”的真相是同一個(gè)調(diào)用失敗了 5 次每次都消耗完整的輸入 token。設(shè)置重試上限是最便宜的預(yù)算保護(hù)措施。第三對每一次模型調(diào)用做 token 審計(jì)。記錄 prompt 的 token 數(shù)、completion 的 token 數(shù)、模型名稱、耗時(shí)、重試次數(shù)。有了這些數(shù)據(jù)才能回答“預(yù)算花到哪里去了”。推薦把審計(jì)日志輸出到標(biāo)準(zhǔn) JSON 格式方便后續(xù)接入監(jiān)控系統(tǒng){ timestamp: 2025-06-01T10:00:00Z, agent: report-agent, subtask: write_report, model: your-model-name, prompt_tokens: 3500, completion_tokens: 1200, total_tokens: 4700, cache_hit: false, elapsed_ms: 8420 }第四給每個(gè)任務(wù)定義“最低可用輸出”。也就是說不管預(yù)算多緊張這個(gè)任務(wù)至少要交付什么。比如調(diào)研報(bào)告任務(wù)的最低可用輸出是“標(biāo)題 三個(gè)核心結(jié)論 風(fēng)險(xiǎn)提示”而不是“完整 2000 字報(bào)告”。把這個(gè)最低輸出定義成單獨(dú)的 prompt在預(yù)算臨界時(shí)調(diào)用。這個(gè)設(shè)計(jì)思路可以保證智能體即使“犧牲”也是帶著最小成果犧牲而不是空手而歸。第五安全與權(quán)限邊界不能因?yàn)轭A(yù)算緊張而放開。預(yù)算不足時(shí)智能體可能會(huì)嘗試?yán)@過某些校驗(yàn)以節(jié)省 token比如跳過敏感操作確認(rèn)、直接使用預(yù)設(shè)憑證。這在生產(chǎn)環(huán)境是絕對禁止的。預(yù)算管理只能影響“做不做外圍任務(wù)”不能影響“是否遵守權(quán)限和審批約束”。涉及刪除、寫入、資金操作時(shí)無論預(yù)算剩余多少都必須走完審批流程。11. 總結(jié)與下一步實(shí)踐方向“AI 智能體在預(yù)算耗盡前的犧牲困境”不是一個(gè)技術(shù)噱頭而是每個(gè)真正把智能體落到生產(chǎn)環(huán)境的團(tuán)隊(duì)都會(huì)遇到的工程問題?；氐胶诵呐袛嘀悄荏w不應(yīng)該是一個(gè)只會(huì)“悶頭往前跑”的執(zhí)行器而應(yīng)該是一個(gè)“時(shí)刻知道資源還有多少、知道哪些可以放棄、知道放棄之后怎么兜底”的預(yù)算感知系統(tǒng)。這不是某個(gè)框架的功能而是你可以在自己的代碼里實(shí)現(xiàn)的工程機(jī)制。下一步建議你從三個(gè)方向入手如果你是剛接觸智能體開發(fā)先不要急著接復(fù)雜框架。按照本文的最小骨架實(shí)現(xiàn)一個(gè)帶預(yù)算管理的智能體跑通一個(gè)真實(shí)任務(wù)體會(huì)“預(yù)算檢查點(diǎn)”對任務(wù)質(zhì)量的直接影響。如果你已經(jīng)在用 Dify、Coze、LangGraph 這類平臺(tái)請檢查它們提供的預(yù)算限制、超時(shí)控制、斷點(diǎn)恢復(fù)功能把本文的降級思路映射到平臺(tái)的對應(yīng)能力上。如果你已經(jīng)在生產(chǎn)環(huán)境跑智能體優(yōu)先做兩件事給所有模型調(diào)用加上 token 審計(jì)日志給每個(gè)任務(wù)定義最低可用輸出。這兩件事投入小、收益大。把每個(gè)智能體都當(dāng)作要上生產(chǎn)環(huán)境的服務(wù)來設(shè)計(jì)而不僅僅是一個(gè)“能回答問題”的腳本。預(yù)算不是限制而是需求的一部分。學(xué)會(huì)在有限預(yù)算下做取舍你的智能體才能真正從實(shí)驗(yàn)室走進(jìn)業(yè)務(wù)線。