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