做長任務(wù) Agent 的工程人應(yīng)該都經(jīng)歷過這種深夜瞬間凌晨三點(diǎn)日志里躺著一行timeout after 30000ms任務(wù)卡在 70% 的位置前幾個(gè)小時(shí)的 Token 全部白燒你還得爬起來手工清理狀態(tài)、回滾數(shù)據(jù)、重新觸發(fā)。那一刻你會產(chǎn)生一個(gè)很現(xiàn)實(shí)的疑問我們費(fèi)這么大勁到底是讓 AI 幫我們省時(shí)間還是讓我們陪它熬夜過去兩年我做了不少 Agent 原型。單輪問答型的最開心兩三百行代碼模型一調(diào)用、答案出來、任務(wù)結(jié)束效果肉眼可見。但當(dāng) Agent 從“回答一個(gè)問題”變成“完成一項(xiàng)工作”——比如連續(xù)跑一個(gè)月的市場分析、自動整理幾百個(gè)文件、無人值守地調(diào)度外部系統(tǒng)——工程問題的性質(zhì)就徹底變了。這不是把 Prompt 寫長一點(diǎn)能解決的。從單次回答走向長任務(wù)執(zhí)行真正發(fā)生變化的是Agent 不再是一個(gè)無狀態(tài)的函數(shù)而是一個(gè)需要持續(xù)運(yùn)行、重復(fù)讀寫狀態(tài)、隨時(shí)應(yīng)對失敗、被監(jiān)控和限制的長期進(jìn)程。它從一個(gè)“會說話的模型”變成了一個(gè)“必須被托管的工作負(fù)載”。于是在這個(gè)轉(zhuǎn)變背后問題就浮出來了工程工作到底發(fā)生在哪里我的結(jié)論很明確工程重心不在模型這一側(cè)而在圍繞任務(wù)構(gòu)建的整個(gè)執(zhí)行框架里——狀態(tài)管理、編排控制、失敗恢復(fù)、成本護(hù)欄、可觀測性。下面我就基于自己做過長任務(wù) Agent 的真實(shí)項(xiàng)目把這幾個(gè)核心位置分別拆開講清楚每一處到底在做什么以及為什么這些工作沒有辦法用“模型智能”替代。1. 單次回答的思維慣性為什么扛不住長任務(wù)執(zhí)行1.1 無狀態(tài)回答與有狀態(tài)進(jìn)程之間的鴻溝當(dāng)我們調(diào)用大模型聊天接口時(shí)本質(zhì)上在做一件非常簡單的事把一段文本發(fā)給模型模型基于上下文生成一段新文本返回。整個(gè)過程是無狀態(tài)的——輸入、輸出、結(jié)束。即使是多輪對話也不過是每次把歷史拼接進(jìn)去模型自己并不維護(hù)真正的“記憶”。長任務(wù)執(zhí)行則完全不同。假設(shè)一個(gè) Agent 被要求“每天早晨抓取行業(yè)新聞生成分析摘要發(fā)送到項(xiàng)目群并歸檔到知識庫”這個(gè)任務(wù)要連續(xù)運(yùn)行 30 天。這時(shí)候真正重要的問題變成了今天幾點(diǎn)運(yùn)行跑完沒有上次生成了什么摘要和昨天的內(nèi)容重復(fù)了嗎抓取接口突然掛了是跳過今天還是持續(xù)重試消息發(fā)送成功但歸檔寫失敗算完成還是部分完成用戶中途改了目標(biāo)是重啟任務(wù)還是斷點(diǎn)續(xù)跑這些問題沒有一個(gè)是模型“聰明”一點(diǎn)就能自己解決的它們幾乎全部依賴工程層面對任務(wù)狀態(tài)的建模。我把這個(gè)差距概括為“函數(shù)式思維”與“進(jìn)程式思維”的區(qū)別。單次回答是函數(shù)輸入 X返回 Y。長任務(wù)是進(jìn)程啟動、運(yùn)行、暫停、恢復(fù)、終止中間還要持久化大量中間產(chǎn)物。1.2 長任務(wù) Agent 的狀態(tài)到底包含什么實(shí)際落地時(shí)至少要維護(hù)這幾類狀態(tài)狀態(tài)類別典型字段說明任務(wù)目標(biāo)狀態(tài)objective、current_phase、status當(dāng)前做到哪一步目標(biāo)有沒有變化執(zhí)行歷史狀態(tài)events、step_results、checkpoints每一步做了什么、結(jié)果如何依賴資源狀態(tài)credentials、config、外部系統(tǒng)連接信息運(yùn)行環(huán)境是否就緒預(yù)算與配額狀態(tài)token_budget、cost、remaining_retry防失控的核心數(shù)據(jù)人工協(xié)同狀態(tài)waiting_for_human、decision_log哪些節(jié)點(diǎn)在等人審批用結(jié)構(gòu)化存儲來維護(hù)這些狀態(tài)而不是全部塞進(jìn)對話歷史里讓模型去“記住”。模型再聰明狀態(tài)也必須滿足三個(gè)硬性要求可查詢、可恢復(fù)、可審計(jì)。對話歷史天然不具備這些能力。你很難從一個(gè)聊天記錄里回答“上一步到底用了哪個(gè)工具參數(shù)”但你能從一張結(jié)構(gòu)化事件表里兩秒查出來。1.3 工程視角的轉(zhuǎn)變從提示設(shè)計(jì)到執(zhí)行設(shè)計(jì)早幾年聊 Agent 工程大多數(shù)人默認(rèn)核心是 Prompt。在單輪場景下Prompt 確實(shí)能決定 90% 的效果。但長任務(wù)場景跑下來你會發(fā)現(xiàn)“提示語”的作用在快速衰減——因?yàn)槭〉沫h(huán)節(jié)往往不是“模型理解不了指令”而是“任務(wù)跑到中段狀態(tài)臟了”“外部系統(tǒng)返回了完全意外的數(shù)據(jù)”“超時(shí)重試把業(yè)務(wù)做重復(fù)了”。我做過的幾個(gè)長任務(wù)項(xiàng)目基本都經(jīng)歷了三個(gè)階段。第一階段是興奮期覺得只要描述清楚目標(biāo)Agent 就能自己搞定一切于是把目標(biāo)塞進(jìn) Prompt直接while true循環(huán)調(diào)用。第二階段是翻車期任務(wù)跑兩天后各種問題接踵而至上下文爆炸、死循環(huán)、重復(fù)執(zhí)行、任務(wù)中斷后無法恢復(fù)、賬單嚇人所有人開始瘋狂打補(bǔ)丁。第三階段才是工程期老老實(shí)實(shí)把任務(wù)當(dāng)成一個(gè)分布式系統(tǒng)來設(shè)計(jì)狀態(tài)落庫、步驟冪等、失敗分級、預(yù)算截?cái)唷⑷炭捎^測之后穩(wěn)定性才真正上來。這個(gè)歷程太典型了。所以先給一個(gè)結(jié)論放在這里**長任務(wù) Agent 的工程工作不在提示詞里而在任務(wù)運(yùn)行時(shí)的工程容器里。**接下來的幾個(gè)章節(jié)就是對這個(gè)容器核心模塊的逐層拆解。2. 任務(wù)不是對話把目標(biāo)拆解成可落庫的狀態(tài)圖2.1 拆解層級目標(biāo)、階段、步驟長任務(wù)管控的第一步是把“一個(gè)模糊的大目標(biāo)”拆成計(jì)算機(jī)能管理的最小單元。我常采用四層結(jié)構(gòu)Objective目標(biāo)一句話定義最終成果例如“完成 Q3 競品分析報(bào)告”。Milestone階段大目標(biāo)的分隔點(diǎn)例如“收集數(shù)據(jù)”“分析數(shù)據(jù)”“生成報(bào)告”。Task任務(wù)具體工作項(xiàng)例如“抓取 5 個(gè)競品官網(wǎng)的更新動態(tài)”。Step步驟一次原子操作例如“調(diào)用瀏覽器工具抓取 xx 網(wǎng)頁并解析正文”。這里有個(gè)實(shí)操經(jīng)驗(yàn)拆得越細(xì)可控性越強(qiáng)但編排成本也越高。比較合適的粒度是“一個(gè) Step 對應(yīng)一次外部動作或一次模型決策”比如一次搜索、一次讀取、一次寫入、一次需要判斷的節(jié)點(diǎn)。這樣既能保證恢復(fù)粒度又不會讓狀態(tài)表爆炸。拆解之后并不是所有任務(wù)都是線性執(zhí)行的。很多長任務(wù)天然包含分支、等待、循環(huán)。所以底層建議用狀態(tài)機(jī)或任務(wù)圖來建模。每個(gè) Step 可以有前置條件、執(zhí)行動作、后置校驗(yàn)前置條件不滿足就阻塞等待。但我也要潑一盆冷水**千萬不要一上來就搞流程引擎。**在任務(wù)還只有十幾個(gè) Step 時(shí)用數(shù)據(jù)庫狀態(tài)表加循環(huán)調(diào)度就足夠了甚至可以是最樸素的while switch。等真正需要處理并發(fā)和復(fù)雜依賴時(shí)再上圖形化編排引擎。否則你會有一種“為了裁一棵樹買了整個(gè)家具工廠”的荒謬感。2.2 狀態(tài)存儲與檢查點(diǎn)跑一半掛了不能從頭再來任務(wù)一旦開始運(yùn)行最重要的工程動作是“隨時(shí)落狀態(tài)”。每完成一個(gè) Step就把這個(gè) Step 的輸入、輸出摘要、Token 消耗、開始結(jié)束時(shí)間寫進(jìn)持久化存儲。模型調(diào)用是昂貴的而落庫是廉價(jià)的不要省這筆錢。我習(xí)慣用這樣一組表來承載任務(wù)狀態(tài)task_instance表task_idobjectivestatuscurrent_phaseinput_snapshot任務(wù)啟動時(shí)的完整輸入?yún)?shù)JSON 快照created_atupdated_atlast_heartbeattask_event表event_idtask_idstep_idevent_typedatacreated_atstep_result表idtask_idstep_namestatusinput_summaryoutput_summarytoken_usagemodellatency_msstarted_atfinished_attask_event尤其重要。它是一條只增不減的事件流每一次決策、每一次工具調(diào)用、每一次失敗都追加為一條事件。為什么要用事件流而不是只維護(hù)一份“最新狀態(tài)”第一事件流天然可回放排查問題時(shí)能看到完整決策路徑第二事件流支持冪等重建即使?fàn)顟B(tài)表損壞也能從事件記錄里恢復(fù)第三做審計(jì)和成本分析時(shí)只需要掃這一張表。檢查點(diǎn)checkpoint則是為了恢復(fù)。在任務(wù)的生命周期里每完成一個(gè)安全節(jié)點(diǎn)就寫入檢查點(diǎn)。所謂安全節(jié)點(diǎn)通常是“所有前置操作已完成且結(jié)果已確認(rèn)”的位置。進(jìn)程重啟后調(diào)度器讀取最近檢查點(diǎn)把目標(biāo)、當(dāng)前階段、近期事件摘要重新組裝進(jìn) Prompt讓 Agent 接著跑而不是重頭再來。2.3 冪等設(shè)計(jì)長任務(wù)最常見的翻車現(xiàn)場長任務(wù)工程中重復(fù)執(zhí)行是頭號事故來源而且越簡單的場景越容易翻車。舉一個(gè)我踩過的例子某個(gè)文檔處理任務(wù)流程是“讀取文件 → 解析內(nèi)容 → 調(diào)用模型總結(jié) → 寫入輸出 → 發(fā)通知”。某次模型總結(jié)步驟超時(shí)了程序判定失敗并重試整個(gè)任務(wù)。重啟后從第一步重新執(zhí)行結(jié)果文件被寫入了兩份下游同事收到了兩次重復(fù)通知。單次回答場景里根本不會有這種問題——回答失敗就重新問一次模型沒有副作用。但長任務(wù)里每一步都可能對外部系統(tǒng)產(chǎn)生真實(shí)影響重放操作就是真實(shí)的生產(chǎn)事故。解決思路其實(shí)不復(fù)雜為每個(gè)外部寫操作生成一個(gè)冪等鍵。比如“數(shù)據(jù)導(dǎo)入”任務(wù)中每條導(dǎo)入記錄都帶上source_batch_id record_no作為唯一鍵寫入時(shí)數(shù)據(jù)庫按唯一鍵去重。批量工具調(diào)用、發(fā)消息、生成文件、提交工單全部做同樣的處理。另一個(gè)常用做法是把“命令是否已執(zhí)行”記錄在步驟狀態(tài)里重試時(shí)先查狀態(tài)如果該步驟已完成就直接跳過、進(jìn)入下一步。實(shí)際中還需要給外部 API 調(diào)用編號每次模型說要調(diào)用工具先分配一個(gè)invocation_id執(zhí)行結(jié)果和invocation_id綁定重試同一決策時(shí)帶上相同 ID外部系統(tǒng)就能識別重復(fù)。這不是新發(fā)明就是把分布式系統(tǒng)里的“冪等消費(fèi)”概念搬進(jìn) Agent 任務(wù)的每一個(gè)副作用操作上。3. 編排的核心戰(zhàn)場兩次模型調(diào)用之間發(fā)生了什么3.1 Agent 循環(huán)的完整拆分很多人理解的 Agent 循環(huán)是三行偽代碼讓模型思考、讓模型調(diào)用工具、把結(jié)果還給模型。真正工程化后的循環(huán)要復(fù)雜得多我把它拆成六個(gè)連續(xù)階段讀取狀態(tài)從任務(wù)存儲中取出當(dāng)前階段、目標(biāo)、前置結(jié)果。組裝上下文按預(yù)算裁剪相關(guān)歷史、檢索必要信息、拼接當(dāng)前指令。模型決策模型產(chǎn)出下一步動作可能是調(diào)用某個(gè)工具、指定參數(shù)或給出中間結(jié)論。動作執(zhí)行工具層執(zhí)行外部操作可能是 HTTP 請求、文件讀寫、數(shù)據(jù)庫查詢、發(fā)送消息。結(jié)果驗(yàn)證用確定性規(guī)則或獨(dú)立校驗(yàn)器評估動作結(jié)果是否符合預(yù)期。狀態(tài)回寫將動作結(jié)果、驗(yàn)證結(jié)論、Token 消耗追加到事件流推進(jìn)狀態(tài)機(jī)。在這六步里最容易被忽略也最容易出事的是第 5 步“結(jié)果驗(yàn)證”。大量 Agent 實(shí)現(xiàn)是“模型說調(diào)用就調(diào)用工具返回什么直接塞回 Prompt”完全不做結(jié)果層面的判斷。于是會出現(xiàn)這種情況搜索接口返回了 500 錯(cuò)誤頁模型卻把錯(cuò)誤內(nèi)容當(dāng)成正常搜索結(jié)果繼續(xù)分析發(fā)送郵件接口返回“成功”但實(shí)際發(fā)到了測試郵箱表格寫入說完成實(shí)際只有表頭。我的工程要求很簡單每一個(gè)工具動作都配一個(gè)驗(yàn)證模塊能驗(yàn)證就寫確定性斷言。比如“響應(yīng) status 必須是 200 且 body 包含 title 字段”“寫庫后必須能 SELECT 回來”。模型可以判斷語義但工程上一定要有規(guī)則兜底。3.2 上下文管理長任務(wù)的慢性病這是長任務(wù) Agent 區(qū)別于單次回答最折磨人的地方。任務(wù)跑到第 20 輪如果每輪都把全部歷史塞回模型Prompt 會迅速膨脹。我第一次做長任務(wù)時(shí)跑到第 15 輪就發(fā)現(xiàn)模型開始“忘記”用戶最初的目標(biāo)經(jīng)常答非所問。排查時(shí)一查 Token 用量發(fā)現(xiàn)每輪上下文已經(jīng)超過 5 萬 Token。根因根本不是模型不行而是工程上沒有做上下文治理。目前常用的手段有以下幾種滾動摘要早期步驟的原始結(jié)果每隔幾輪被模型壓縮成一個(gè)摘要后續(xù)只保留摘要摘要過長再壓縮成摘要的摘要。結(jié)構(gòu)化外部化工具調(diào)用的完整輸出存進(jìn)數(shù)據(jù)庫Prompt 里只放“該步驟已完成結(jié)果見附件 ID x”這類引用信息需要細(xì)節(jié)時(shí)再用檢索工具去取。裁剪與召回對歷史事件按重要度打分保留高價(jià)值信息低價(jià)值信息裁剪后存外部記憶需要時(shí)通過語義搜索召回。上下文預(yù)算每輪進(jìn)入模型前計(jì)算 Token 預(yù)算比如單輪限制 16K歷史太長就先做摘要再進(jìn) Prompt。核心原則是**長期記憶是數(shù)據(jù)庫的職責(zé)不是 Prompt 的職責(zé)。**模型只需要拿到“眼前這一步需要的最小信息集”。這也是長任務(wù) Agent 和大模型單輪對話在工程上最本質(zhì)的差異之一。3.3 人工確認(rèn)節(jié)點(diǎn)與等待語義不是所有動作都應(yīng)該讓 Agent 自己說了算。在長任務(wù)里凡是“成本高、影響大、不可逆”的動作都應(yīng)該插入人工確認(rèn)節(jié)點(diǎn)。比如對外發(fā)送通知、提交訂單、刪除數(shù)據(jù)、發(fā)布內(nèi)容。如果沒有審批機(jī)制Agent 一旦決策失誤后果會被放大成真實(shí)事故。工程實(shí)現(xiàn)上我一般讓狀態(tài)機(jī)支持waiting_for_human這個(gè)狀態(tài)。當(dāng) Agent 走到審批節(jié)點(diǎn)時(shí)不是繼續(xù)瞎猜而是把待確認(rèn)內(nèi)容、影響范圍、下一步選項(xiàng)推送給用戶可以通過 IM、郵件或控制臺任務(wù)卡展示然后任務(wù)掛起、存儲狀態(tài)、開啟超時(shí)計(jì)時(shí)。用戶在控制臺點(diǎn)擊“批準(zhǔn) / 拒絕 / 修改參數(shù)”任務(wù)恢復(fù)。等待語義必須顯式設(shè)計(jì)否則很容易出現(xiàn)“任務(wù)看似活著但卡住了”的現(xiàn)象。我給每個(gè)waiting_for_human節(jié)點(diǎn)也設(shè)置超時(shí)。比如策略是超過 6 小時(shí)未確認(rèn)則再次推送超過 24 小時(shí)未確認(rèn)則自動掛起并通知管理員。這樣人工環(huán)節(jié)本身也不會成為靜默堵點(diǎn)。這套等待恢復(fù)機(jī)制的技術(shù)含量不算高但它直接決定了 Agent 能否被放心地投入真實(shí)業(yè)務(wù)流程。沒有人工確認(rèn)節(jié)點(diǎn)的長任務(wù) Agent本質(zhì)上是一個(gè)沒有剎車的自動駕駛性能和風(fēng)險(xiǎn)成正比。4. 失敗分類與重試設(shè)計(jì)長任務(wù)工程里最殘酷的一課4.1 失敗的層次不是所有失敗都該重試長任務(wù)跑久了失敗是必然的問題只在于系統(tǒng)怎么應(yīng)對失敗。如果對所有失敗一視同仁統(tǒng)一走“重試”那最直接的后果是有些重試毫無意義有些重試把問題放大。我把運(yùn)行中遇到的失敗分成四類失敗類型典型例子處理策略瞬時(shí)錯(cuò)誤網(wǎng)絡(luò)超時(shí)、限流、服務(wù) 5xx指數(shù)退避重試上限約 3-5 次確定性錯(cuò)誤參數(shù)不合法、權(quán)限不足、文件不存在不重試讓模型修正參數(shù)或改變策略業(yè)務(wù)校驗(yàn)失敗工具執(zhí)行成功但結(jié)果不符合預(yù)期規(guī)則返回校驗(yàn)信息模型換方案限次數(shù)不可收斂模型反復(fù)嘗試同樣的失敗動作強(qiáng)制暫停轉(zhuǎn)入人工這個(gè)分類看起來簡單實(shí)際意義很大。瞬時(shí)錯(cuò)誤重試是正確的因?yàn)橥獠糠?wù)抖一下會自己恢復(fù)確定性錯(cuò)誤重試一百次也是同樣結(jié)果不如把錯(cuò)誤信息回傳給模型讓模型重新思考動作參數(shù)業(yè)務(wù)校驗(yàn)失敗不能簡單重試要讓模型理解“這次動作雖然執(zhí)行成功但結(jié)果不滿足驗(yàn)收條件”。我還會給每個(gè) Step 加一個(gè)retry_policy字段不同步驟掛不同的策略而不是走全局同一套。比如“調(diào)用外部接口”默認(rèn)指數(shù)退避重試 3 次“寫入數(shù)據(jù)庫”默認(rèn)失敗即停、需要人工處理“發(fā)送通知”默認(rèn)失敗后轉(zhuǎn)入補(bǔ)償流程。策略掛在步驟上恢復(fù)邏輯才有針對性。4.2 重試的放大效應(yīng)從單點(diǎn)抖動到任務(wù)雪崩這里想單獨(dú)講一個(gè)高頻翻車場景重試疊加導(dǎo)致的雪崩。假設(shè)一個(gè) Agent 任務(wù)是批量調(diào)用某個(gè)第三方平臺的開放接口每個(gè)批次要處理 2000 條數(shù)據(jù)。某次對方接口開始限流如果重試策略是無腦重試會發(fā)生什么第一次調(diào)用失敗等 0.5 秒重試失敗等 1 秒所有 Worker 同步重試瞬間把第三方接口打到更嚴(yán)重的限流形成惡性循環(huán)。其結(jié)果不僅是任務(wù)失敗還可能因?yàn)橛|發(fā)對方封禁策略導(dǎo)致整個(gè)賬號被限制。這類問題的解法在傳統(tǒng)后端領(lǐng)域已經(jīng)很成熟直接平移過來就好退避抖動 熔斷 并發(fā)限制。我在任務(wù)調(diào)度層加了一個(gè)熔斷開關(guān)當(dāng)某個(gè)外部服務(wù)的連續(xù)失敗率達(dá)到閾值比如 30%就把對這個(gè)服務(wù)的調(diào)用暫時(shí)降級或暫停讓任務(wù)先處理其他分支等冷卻窗口過了再恢復(fù)。加了熔斷之后第三方抖動造成的連帶傷害肉眼可見地減少了。關(guān)鍵轉(zhuǎn)變在于Agent 的任務(wù)框架不能把“模型調(diào)用”和“外部工具調(diào)用”混為一談。模型調(diào)用失敗可以用重試解決但外部工具調(diào)用失敗要考慮業(yè)務(wù)語義。拿捏不住這一點(diǎn)所謂的智能 Agent 會在最簡單的問題上暴露最原始的架構(gòu)缺陷。4.3 部分完成與補(bǔ)償任務(wù)不是非黑即白長任務(wù)里最難處理的不是“完全失敗”而是“部分完成”。比如一個(gè)任務(wù)的目標(biāo)是“把 10 份文件從 A 系統(tǒng)同步到 B 系統(tǒng)”跑到第 7 份時(shí) A 系統(tǒng)接口掛了。這時(shí)候整任務(wù)標(biāo)記為failed不公平前 7 份白干了標(biāo)記為success更不對還有 3 份沒完成。我建議的做法是讓任務(wù)狀態(tài)機(jī)支持“部分完成 斷點(diǎn)續(xù)跑”。任務(wù)本身維持running或升級為suspended狀態(tài)但明確記錄已完成步驟列表、失敗步驟列表、剩余步驟列表。重啟恢復(fù)后調(diào)度器從剩余步驟開始而不是重新執(zhí)行所有步驟。這就是檢查點(diǎn)機(jī)制真正的價(jià)值。另外還要考慮補(bǔ)償compensation。有些操作一旦部分執(zhí)行必須做回滾或?qū)_。比如批量提交審批的任務(wù)提交到一半失敗這時(shí)候如果直接續(xù)跑可能造成重復(fù)提交正確方式是先查詢未審批單據(jù)補(bǔ)提交缺失的單據(jù)并清除重復(fù)記錄。補(bǔ)償邏輯最好在任務(wù)編排階段就定義好而不是等事故發(fā)生了再來打補(bǔ)丁。4.4 防死循環(huán)別讓 Agent 進(jìn)入“螺旋加班”狀態(tài)長任務(wù)自動循環(huán)跑著跑著出現(xiàn)死循環(huán)是真實(shí)存在的。我自己就遇過Agent 被要求整理一批 PDF其中一份文件解析失敗。模型試圖重試解析失敗換一種解析方法還是失敗換個(gè)標(biāo)題再看一次還是失敗。整個(gè)任務(wù)卡在同一個(gè)文件上循環(huán)了將近 30 輪消耗大量 Token毫無進(jìn)展。為什么會出現(xiàn)這種情況因?yàn)槟Ｐ驮陂_放場景下天然傾向于“繼續(xù)嘗試”而沒有一個(gè)“我應(yīng)該停下來求助”的機(jī)制。這個(gè)傾向在單次問答里無所謂在長任務(wù)里就是燒錢黑洞。工程上的防死循環(huán)主要有三條。一是全局循環(huán)上限比如每個(gè)階段最多執(zhí)行 N 輪模型決策超過就強(qiáng)制暫停。二是失敗模式識別連續(xù) M 次收到同一類錯(cuò)誤自動標(biāo)記“此處需要人工判斷”。三是給模型顯式的退出信號在系統(tǒng)提示詞中聲明“如果同一目標(biāo)嘗試多次仍失敗請生成 NEED_HELP 決策而不是繼續(xù)嘗試?！边@個(gè)設(shè)計(jì)本質(zhì)上是在給“自由意志”裝剎車。沒有剎車的 Agent 不是效率工具是風(fēng)險(xiǎn)工具。5. 護(hù)欄越界即事故成本、權(quán)限與完成度驗(yàn)證5.1 成本預(yù)算Token 不是自來水是真金白銀做單次回答 Agent 的人通常對 Token 成本不敏感一次問答幾毛錢無所謂。但長任務(wù) Agent 的成本模型完全不一樣任務(wù)持續(xù)運(yùn)行、頻繁循環(huán)幾十輪調(diào)用是常態(tài)。如果任務(wù)里還包含文本處理、PDF 解析、批量搜索每天的 Token 消耗可能是單次回答的幾十倍甚至上百倍。我有一次跑一個(gè)“批量總結(jié)競品文檔”的任務(wù)沒有做預(yù)算限制結(jié)果一個(gè)晚上跑了 128 輪模型調(diào)用消耗超過 120 萬 Token。賬單出來的時(shí)候我整個(gè)人是清醒的智能的代價(jià)是真的貴。工程上必須做三重預(yù)算控制任務(wù)級預(yù)算給每個(gè) Task 設(shè)置最大 Token 數(shù)和最大金額超限自動暫停。階段級預(yù)算每個(gè) Milestone 分配額度防止單階段耗盡全局可用資源。實(shí)時(shí)監(jiān)控每次模型調(diào)用后累計(jì)消耗超過閾值觸發(fā)告警超過硬頂強(qiáng)制凍結(jié)任務(wù)。預(yù)算告警要接人工通知。比如消耗超過 50% 時(shí) IM 通知超過 80% 時(shí)再次通知超過 100% 自動掛起。不要讓一個(gè)無人值守任務(wù)悄悄把預(yù)算燒完。5.2 最小權(quán)限與高風(fēng)險(xiǎn)動作審批長任務(wù)的執(zhí)行環(huán)境比單次回答更需要權(quán)限管控。原因很簡單單次回答沒有外部副作用但長任務(wù)會調(diào)用真實(shí)工具、真實(shí)接口、真實(shí)寫操作。如果你給 Agent 配了一個(gè)“管理員”級別的賬號它一旦被惡意注入的指令誤導(dǎo)后果就是整個(gè)系統(tǒng)范圍內(nèi)的事故。我的經(jīng)驗(yàn)法則是**給 Agent 進(jìn)程分配最小的專用憑證只開放任務(wù)必需的 API 權(quán)限所有刪除、覆蓋、發(fā)送、支付、發(fā)布類動作默認(rèn)走人工審批節(jié)點(diǎn)絕不賦予 Agent 自動執(zhí)行權(quán)限。**工具調(diào)用使用允許名單模式Agent 只能調(diào)用名單內(nèi)的工具遇到未授權(quán)工具直接返回“無權(quán)限”而不是繼續(xù)嘗試。有人會說這樣 Agent 就不“自主”了。我的回答是自主是工程給的邊界內(nèi)的自主不是無限自由。真實(shí)的自動化系統(tǒng)從來都是“被約束的自動化”不約束的 Agent 只能待在 Demo 里。5.3 完成度驗(yàn)證Agent 說做完了不等于真的做完了長任務(wù)“跑完”并不等于“做好”。模型的自我評估天然帶有樂觀傾向它傾向于認(rèn)為自己已經(jīng)完成了用戶目標(biāo)。工程上必須對完成度做獨(dú)立驗(yàn)證。我在任務(wù)結(jié)尾會加一個(gè)“完成校驗(yàn)階段”做三件事讓 Agent 輸出執(zhí)行報(bào)告完成了哪些步驟、每步結(jié)果的依據(jù)是什么、哪些地方和原目標(biāo)有偏差。通過自動化規(guī)則核查關(guān)鍵產(chǎn)出比如“報(bào)告文件存在且非空”“所有源文件已歸檔”“目標(biāo)系統(tǒng)記錄數(shù)已核對”。人工抽查或獨(dú)立評審對關(guān)鍵任務(wù)把執(zhí)行報(bào)告和核心產(chǎn)物發(fā)給一個(gè)獨(dú)立評審者可以是人也可以是另一個(gè)模型實(shí)例評審?fù)ㄟ^后才允許把任務(wù)標(biāo)記為success。這套“做完 驗(yàn)完 完成”的語義看起來保守但在真實(shí)業(yè)務(wù)里非常有用。它讓任務(wù)從“跑完流程”升級為“交付結(jié)果”用戶對 Agent 的信任也是這么一點(diǎn)點(diǎn)建立起來的。6. 長任務(wù)的可觀測性Debug 從“猜謎”變成“回放”6.1 事件流打底每輪決策都值得留痕長任務(wù) Debug 和單次回答 Debug 完全兩碼事。單次回答出問題直接看模型輸出就完了。長任務(wù)出問題你需要回答的是這個(gè) Agent 為什么在昨天下午三點(diǎn)做了一個(gè)奇怪的操作它當(dāng)時(shí)看到了什么上下文哪個(gè)步驟觸發(fā)了它做這個(gè)決策要回答這些問題必須讓執(zhí)行過程可回放。前面說的task_event表就是基礎(chǔ)每個(gè)模型調(diào)用記錄當(dāng)時(shí)組裝后的完整 Prompt 摘要、模型、輸入輸出 Token、耗時(shí)每次工具調(diào)用記錄工具名、參數(shù)、輸出摘要、返回狀態(tài)每個(gè)錯(cuò)誤記錄錯(cuò)誤類型、錯(cuò)誤信息、重試次數(shù)。所有事件按時(shí)間順序落庫。注意一個(gè)實(shí)操細(xì)節(jié)不要把完整 Prompt 都存進(jìn)每個(gè)事件會很占空間。我通常存“Prompt 摘要 關(guān)鍵上下文片段 完整調(diào)用 ID”調(diào)用 ID 指向獨(dú)立日志存儲。這樣既保證可回放又不至于把數(shù)據(jù)庫撐爆。6.2 任務(wù)時(shí)間線與回放模式有了事件流就可以給每個(gè)任務(wù)生成一條時(shí)間線從啟動、規(guī)劃、每一步?jīng)Q策、工具調(diào)用、失敗重試、人工等待到最終完成或終止。界面按時(shí)間展示每條事件包含時(shí)間、類型、關(guān)鍵摘要?；胤拍Ｊ绞俏易鲩L任務(wù)最依賴的 Debug 手段。所謂回放就是按時(shí)間順序把事件重新走一遍重現(xiàn) Agent 的決策路徑。遇到“任務(wù)結(jié)果完全不符合預(yù)期”的情況第一件事就是打開回放看它在哪一步開始偏離目標(biāo)是哪條上下文讓它做出了錯(cuò)誤判斷。答案比盲改 Prompt 快得多?？梢怨蚕硪粋€(gè)經(jīng)驗(yàn)數(shù)據(jù)我修長任務(wù)問題的耗時(shí)分布大約 40% 在“定位哪一步出了問題”30% 在“理解當(dāng)時(shí)為什么會這么決策”20% 在“制定修復(fù)方案”10% 在“實(shí)施修復(fù)”。如果沒有事件流和回放前兩項(xiàng)會無限膨脹Debug 基本靠猜。6.3 心跳與靜默告警長任務(wù)的“活人監(jiān)護(hù)”長任務(wù)系統(tǒng)最危險(xiǎn)的一個(gè)狀態(tài)是“靜默死亡”進(jìn)程還在線程還在但循環(huán)不再推進(jìn)也沒有任何報(bào)錯(cuò)。這個(gè)狀態(tài)比崩潰更可怕。崩潰會立刻觸發(fā)告警靜默死亡不會。防止靜默死亡的辦法是給任務(wù)加心跳。每次狀態(tài)變更都更新last_heartbeat字段調(diào)度器或定時(shí)巡檢定期掃描如果某個(gè)running狀態(tài)的任務(wù)心跳超過閾值比如 10 分鐘沒有變化就判定“可能卡住”觸發(fā)告警并把任務(wù)掛起。實(shí)際中我還加過“看護(hù)進(jìn)程”如果任務(wù)在一個(gè)階段內(nèi)沒有任何事件產(chǎn)出看護(hù)進(jìn)程會主動詢問模型“當(dāng)前還在處理嗎”如果模型連續(xù)兩次未正確響應(yīng)就強(qiáng)制重啟該階段或轉(zhuǎn)入人工。有人擔(dān)心這樣會誤傷正在慢速運(yùn)行的任務(wù)。會所以心跳閾值要結(jié)合任務(wù)特點(diǎn)設(shè)置耗時(shí)長的外部等待可以明確標(biāo)記為“等待外部系統(tǒng)”不算靜默。這里的原則是寧可偶爾誤告警也不要讓異常靜默吞掉生產(chǎn)事故。6.4 復(fù)盤跑完任務(wù)后把日志變成經(jīng)驗(yàn)最后想提一個(gè)工作習(xí)慣每個(gè)長任務(wù)跑完一版后花時(shí)間做一次“任務(wù)復(fù)盤”。我會讓系統(tǒng)自動生成執(zhí)行摘要總耗時(shí)、總 Token 消耗、失敗最多的階段、人工介入次數(shù)、成本分布。然后人工查看這些數(shù)據(jù)找出最值得優(yōu)化的環(huán)節(jié)。可能是某個(gè)工具調(diào)用頻繁失敗可能是某類 Prompt 總引導(dǎo)模型走彎路也可能是上下文裁剪策略過于激進(jìn)導(dǎo)致模型丟失關(guān)鍵信息。這一步看似不是核心功能但實(shí)際上對長任務(wù) Agent 的持續(xù)優(yōu)化至關(guān)重要。沒有復(fù)盤你就是反復(fù)踩同一個(gè)坑有復(fù)盤每跑一周任務(wù)系統(tǒng)就變聰明一點(diǎn)。工程上的長期主義往往就是從這些不起眼的例行流程里長出來的。做長任務(wù) Agent 這一年多我最大的體會是當(dāng) Agent 從“單次回答”走向“長任務(wù)執(zhí)行”工程上真正發(fā)生工作的位置幾乎全都在模型外部——狀態(tài)怎么存、失敗怎么處理、成本怎么限制、行為怎么審計(jì)、結(jié)果怎么驗(yàn)證。模型的智能負(fù)責(zé)做決策工程框架負(fù)責(zé)讓決策安全落地。這兩者之間不存在替代關(guān)系Prompt 寫得再好也替代不了冪等鍵、檢查點(diǎn)和預(yù)算熔斷。所以如果你正打算開始做長任務(wù) Agent我的建議很直白先別急著調(diào) Prompt。先把任務(wù)狀態(tài)表設(shè)計(jì)好、把失敗分類定義清楚、把可觀測性底子打牢然后再去追求 Agent 的自由度。框架穩(wěn)了Agent 才能真正跑得遠(yuǎn)。