Agent 跑到一半掛了是做 Agent 落地的人遲早要撞上的事。我維護(hù)某客服工單處理系統(tǒng)時(shí)一個(gè)多步驟 Agent 任務(wù)跑了半個(gè)多小時(shí)調(diào)用了二十多次模型結(jié)果倒數(shù)第二步因?yàn)榈谌轿锪鹘涌谙蘖髦苯訏佸e。整個(gè)任務(wù)從頭重跑Token 花了兩倍用戶還在那多等了十分鐘。那之后我下定決心把“斷點(diǎn)繼續(xù)”做進(jìn) Agent 的底層框架這篇就講我在實(shí)戰(zhàn)里總結(jié)出來的完整方案失敗到底長什么樣、檢查點(diǎn)怎么設(shè)計(jì)、工具調(diào)用的重復(fù)副作用怎么處理、什么斷點(diǎn)值得救、恢復(fù)時(shí)有哪些暗坑。適合正在做 Agent 應(yīng)用的人看尤其是那些被重跑成本、Token 浪費(fèi)、任務(wù)不可恢復(fù)折磨過的同學(xué)。這篇不聊概念全是能落地的設(shè)計(jì)思路和代碼結(jié)構(gòu)。1. 先搞清楚失敗長什么樣Agent 中斷的常見形態(tài)與根因做斷點(diǎn)恢復(fù)之前必須先把你遇到的“失敗”分類。我見過太多人一上來就寫恢復(fù)邏輯結(jié)果恢復(fù)邏輯本身就是個(gè)脆弱的玩具因?yàn)檫B失敗發(fā)生在哪個(gè)階段都沒搞清楚。1.1 進(jìn)程級失敗與邏輯級失敗兩種不同的恢復(fù)思路Agent 跑掛了從表象上看是“任務(wù)沒完成”“報(bào)錯了”但底層原因可以分成兩大類。進(jìn)程級失敗是指運(yùn)行環(huán)境出了問題內(nèi)存溢出、容器被殺、部署重啟、依賴服務(wù)崩潰、進(jìn)程被 OOM Killer 干掉。這類失敗的特點(diǎn)是Agent 的整個(gè)狀態(tài)包括保存在內(nèi)存里的聊天記錄、任務(wù)隊(duì)列、中間變量全部沒了。邏輯級失敗則是指 Agent 自身在“規(guī)劃—執(zhí)行—觀察”循環(huán)中走入了死胡同上下文溢出、模型輸出格式不符合解析要求、工具調(diào)用返回了意外結(jié)構(gòu)、規(guī)劃步驟形成了死循環(huán)或者某一步拋出了沒有兜底的異常。這兩類的恢復(fù)策略完全不同。進(jìn)程級失敗只要能拿回外部持久化的狀態(tài)原地重建執(zhí)行環(huán)境就可以續(xù)跑。邏輯級失敗單純續(xù)跑往往沒用因?yàn)閷?dǎo)致失敗的條件還在你得先修正計(jì)劃、截?cái)嗌舷挛幕蛘咔袚Q策略。我在最初設(shè)計(jì)恢復(fù)機(jī)制時(shí)犯過的一個(gè)錯誤就是把所有失敗都當(dāng)成“拋異?！碧幚怼：髞戆l(fā)現(xiàn)上下文溢出根本不會拋異常就是模型輸出忽然變得亂七八糟解析器報(bào)錯然后整個(gè)循環(huán)結(jié)束。這類失敗如果只做“重試”只會把同樣的錯誤再來一遍。1.2 按執(zhí)行層拆解失敗點(diǎn)模型、工具、編排三處最脆弱把 Agent 一次完整執(zhí)行拆開看失敗概率最高的就三處模型調(diào)用、工具調(diào)用、編排解析。模型調(diào)用這層的失敗主要是超時(shí)、限流、服務(wù)不可用以及最要命的“輸出不符合預(yù)期”。輸出不符合預(yù)期包括JSON 格式破裂、字段缺失、意圖偏移、廢話連篇。這層失敗的特征是失敗點(diǎn)之前的狀態(tài)往往還是干凈的重試的代價(jià)也可控。工具調(diào)用這層的失敗就復(fù)雜了。第三方 API 超時(shí)、返回 5xx、返回結(jié)構(gòu)變化、限流限頻都會導(dǎo)致 Agent 拿不到可用觀測結(jié)果。更麻煩的是工具調(diào)用可能有副作用——扣費(fèi)、發(fā)消息、寫數(shù)據(jù)庫、調(diào)外部系統(tǒng)。這類失敗不能簡單重試因?yàn)樯弦淮握{(diào)用可能已經(jīng)在服務(wù)端執(zhí)行成功了只是結(jié)果沒傳回來。編排層的失敗則發(fā)生在我們自己寫的 Agent 框架里。比如多步執(zhí)行的狀態(tài)管理沖突、步驟依賴關(guān)系斷裂、上下文窗口被塞滿、規(guī)劃進(jìn)入死循環(huán)。這類失敗最隱蔽因?yàn)樗幌衲Ｐ驼{(diào)用那樣有明確的錯誤碼往往需要翻日志才能定位。有一個(gè)很反直覺的事實(shí)真正讓 Agent 任務(wù)全盤崩潰的往往不是模型而是我們對工具返回值的處理太草率。模型偶爾偷個(gè)懶、格式飄一下只要解析層做了容錯都能救回來。但工具調(diào)用一旦帶著副作用失敗后續(xù)所有步驟的狀態(tài)就不可信了。1.3 一個(gè)真實(shí)的任務(wù)執(zhí)行鏈路里狀態(tài)到底存在哪要設(shè)計(jì)斷點(diǎn)恢復(fù)你得先回答一個(gè)問題一個(gè) Agent 任務(wù)在任意時(shí)刻狀態(tài)的完整集合是什么我用過的最樸素但有效的模型是從四個(gè)維度記錄狀態(tài)。任務(wù)級元數(shù)據(jù)任務(wù) ID、目標(biāo)描述、創(chuàng)建時(shí)間、當(dāng)前階段、已重試次數(shù)。執(zhí)行計(jì)劃與進(jìn)度規(guī)劃出來的步驟列表哪些步驟已完成哪些正在執(zhí)行。上下文消息歷史和模型交互的完整消息列表包括系統(tǒng)提示、用戶目標(biāo)、歷次助手回復(fù)、工具調(diào)用結(jié)果。工具調(diào)用的副作用賬本哪些工具被調(diào)過、傳了什么參數(shù)、返回了什么結(jié)果、是否確認(rèn)成功。這四個(gè)維度缺一個(gè)恢復(fù)的時(shí)候就會出問題。比如只保存消息歷史不保存步驟進(jìn)度那恢復(fù)時(shí)就得從第一條消息重新推理雖然模型能“回憶”出之前干了什么但工具已經(jīng)帶副作用執(zhí)行過了重推的時(shí)候很可能重復(fù)調(diào)用。我在實(shí)際項(xiàng)目里習(xí)慣把所有狀態(tài)統(tǒng)一存在一個(gè)可持久化的狀態(tài)對象里每個(gè)步驟執(zhí)行前都序列化一次。這樣崩潰之后我拿到的不是一段孤立的日志而是“這個(gè)任務(wù)在那一刻的完整照片”。2. 斷點(diǎn)繼續(xù)的底層思路把 Agent 執(zhí)行當(dāng)成一條可回放的日志很多人一聽“斷點(diǎn)繼續(xù)”第一反應(yīng)是“把模型實(shí)例存下來”。這是誤區(qū)大模型服務(wù)本身是無狀態(tài)的你根本存不下“模型的思考狀態(tài)”。能存下的只有執(zhí)行環(huán)境里那些可以被回放和重建的數(shù)據(jù)。2.1 核心認(rèn)知Agent 是狀態(tài)機(jī)不是函數(shù)我踩過最大的坑就是把 Agent 當(dāng)成一個(gè)大函數(shù)覺得“調(diào)用它、等結(jié)果”就行了。實(shí)際上一個(gè)負(fù)責(zé)多步驟任務(wù)的 Agent 是一個(gè)狀態(tài)機(jī)每執(zhí)行完一步狀態(tài)就向前推進(jìn)一截每調(diào)用一次工具外部世界就產(chǎn)生了一處變化。狀態(tài)機(jī)的好處是任何一步執(zhí)行完只要把當(dāng)前狀態(tài)落盤就算后面全部崩潰也能回到落盤點(diǎn)重新往下走。壞處是狀態(tài)機(jī)里每個(gè)步驟都不是純粹的它夾著模型推理和工具副作用所以恢復(fù)起來比普通重試要復(fù)雜得多。用游戲存檔來類比就很容易理解。你玩一個(gè)長流程游戲每過一個(gè)關(guān)卡系統(tǒng)幫你存檔下次進(jìn)入游戲讀檔你不需要把整個(gè)關(guān)卡重新打一遍。Agent 也一樣每個(gè)“關(guān)卡”就是一次模型調(diào)用加一次工具執(zhí)行存檔就是狀態(tài)快照。但 Agent 比游戲存檔麻煩的地方在于游戲存檔只需要記錄角色位置、血量、物品欄而 Agent 要記錄的不僅有“當(dāng)前走到哪一步了”還有“之前調(diào)用過哪些工具、產(chǎn)生了什么結(jié)果、哪些副作用已經(jīng)生效”。這些信息散落在代碼里、數(shù)據(jù)庫里、外部 API 里收集起來比想象中麻煩。2.2 事件溯源與狀態(tài)快照兩種持久化策略的取舍做狀態(tài)持久化我實(shí)際嘗試過兩條路事件溯源和定期快照。事件溯源的做法是把每一步的執(zhí)行過程追加寫入一條不可變事件記錄。比如“模型生成了計(jì)劃”“工具 A 被調(diào)用參數(shù)是 X返回 Y”“步驟 2 完成”?；謴?fù)的時(shí)候從頭把事件重放一遍就能把狀態(tài)重建到最后一條事件對應(yīng)的位置。定期快照的做法是每隔幾個(gè)步驟或者每個(gè)步驟結(jié)束時(shí)把完整狀態(tài)對象一次性序列化保存下來?；謴?fù)的時(shí)候直接加載最近的快照不需要重放。兩條路各有適用場景。事件溯源的優(yōu)點(diǎn)是粒度細(xì)、可審計(jì)、能精確恢復(fù)到最后一步缺點(diǎn)是重放成本高事件多了以后很慢?？煺盏膬?yōu)點(diǎn)是恢復(fù)快、實(shí)現(xiàn)簡單缺點(diǎn)是丟失兩次快照之間的狀態(tài)變化而且如果狀態(tài)對象里有不可序列化的內(nèi)容快照就存不了。我在生產(chǎn)環(huán)境用的是混合方案每個(gè)步驟完成時(shí)打一個(gè)輕量快照同時(shí)把關(guān)鍵事件按日志形式追加?；謴?fù)時(shí)先加載最近的快照再用事件日志把進(jìn)度推進(jìn)到中斷點(diǎn)之前的最后一個(gè)有效狀態(tài)。這樣既有兜底又有精度。2.3 保存時(shí)機(jī)不是每次調(diào)用都要存但不是每次都能偷懶什么時(shí)候落盤一次這個(gè)問題我見過很多種答案。有人只在任務(wù)開始時(shí)存一次有人等任務(wù)完成后存一次有人每一步都存。我的建議是模型調(diào)用發(fā)出去之前存一次工具調(diào)用發(fā)出之前存一次這兩個(gè)時(shí)機(jī)是必須打點(diǎn)的。理由很簡單模型調(diào)用之前存的狀態(tài)是“這一步還沒開始”的干凈狀態(tài)如果調(diào)用超時(shí)或模型輸出無法解析從這個(gè)狀態(tài)重試毫無壓力。工具調(diào)用之前存的狀態(tài)則是“副作用尚未發(fā)生”的狀態(tài)一旦工具調(diào)用失敗可以判斷副作用到底產(chǎn)生了沒有再決定是重試還是清理。至于工具返回之后、進(jìn)入下一個(gè)步驟之前建議也存一次因?yàn)檫@時(shí)候工具的結(jié)果已經(jīng)進(jìn)入了上下文下一步要基于這個(gè)結(jié)果繼續(xù)推理。錯過這個(gè)點(diǎn)恢復(fù)后就得多一次推理才能重建同樣的上下文。存太頻繁也有代價(jià)。每一步都全量序列化遇到大上下文時(shí)序列化時(shí)間和存儲開銷都會上漲。我后來把序列化拆成了兩層高頻輕量層只存步驟 ID、步驟狀態(tài)、關(guān)鍵變量低頻全量層才存完整上下文。這樣崩潰后先拿輕量層快速定位需要時(shí)再加載全量上下文。3. 檢查點(diǎn)方案的落地設(shè)計(jì)狀態(tài)結(jié)構(gòu)、保存流程與恢復(fù)算法思路理清之后最重要的就是把檢查點(diǎn)機(jī)制落進(jìn)代碼里。下面是一套我在實(shí)際項(xiàng)目里驗(yàn)證過的設(shè)計(jì)可以直接照搬微調(diào)。3.1 三類狀態(tài)表結(jié)構(gòu)任務(wù)、步驟、工具調(diào)用賬本狀態(tài)持久化用關(guān)系數(shù)據(jù)庫或者文檔數(shù)據(jù)庫都行關(guān)鍵是表結(jié)構(gòu)要能表達(dá)任務(wù)執(zhí)行的層次關(guān)系。我設(shè)計(jì)過三張核心表結(jié)構(gòu)如下。任務(wù)表記錄任務(wù)的全局信息{ task_id: task_20250101_001, goal: 處理售后工單需要完成退換貨流程, status: in_progress, current_step_id: step_7, plan: [step_1: 調(diào)用戶訂單接口, step_2: 校驗(yàn)售后條件, ...], attempt_count: 3, max_attempts: 5, created_at: 2025-01-01 10:00:00, updated_at: 2025-01-01 10:25:30 }步驟表記錄每個(gè)步驟的執(zhí)行狀態(tài){ step_id: step_7, task_id: task_20250101_001, step_desc: 調(diào)用物流接口獲取最新軌跡, status: failed, depends_on: [step_6], retry_count: 1, input_snapshot: {\order_id\: \PO20250101\}, output_snapshot: null, error_info: api_rate_limit_exceeded, started_at: 2025-01-01 10:20:00, finished_at: null }工具調(diào)用賬本表專門記錄帶副作用的調(diào)用{ call_id: toolcall_1042, task_id: task_20250101_001, step_id: step_7, tool_name: logistics_track, arguments: {\order_id\: \PO20250101\}, status: executed_unknown, idempotency_key: task_20250101_001_step_7_logistics_track, response_summary: null, created_at: 2025-01-01 10:20:05 }需要注意的關(guān)鍵字段是工具調(diào)用表里的idempotency_key它保證了即使在網(wǎng)絡(luò)超時(shí)的情況下也能識別“這個(gè)調(diào)用我是不是已經(jīng)發(fā)出過”后面講副作用處理時(shí)再展開。3.2 保存流程每個(gè)關(guān)鍵節(jié)點(diǎn)都寫一次“狀態(tài)照片”檢查點(diǎn)保存的代碼邏輯我推薦寫成一個(gè)裝飾器或者執(zhí)行器內(nèi)部的回調(diào)函數(shù)而不是散落在業(yè)務(wù)代碼里。偽代碼如下。async def run_agent_step(task_state, step): # 1. 在模型調(diào)用前保存狀態(tài) checkpoint(task_state, phasebefore_model_call) # 2. 調(diào)用模型生成回復(fù) response await call_model(task_state.messages) if not is_valid(response): # 模型輸出無效從 before_model_call 檢查點(diǎn)恢復(fù) raise RecoverableCheckpointError(model output invalid) # 3. 如果模型要求調(diào)用工具則在調(diào)用前記錄賬本 if response.tool_calls: for tool_call in response.tool_calls: record_tool_call(task_state, tool_call) # 在工具調(diào)用發(fā)出前保存狀態(tài) checkpoint(task_state, phasebefore_tool_call) # 4. 執(zhí)行工具調(diào)用 tool_results await execute_tool_calls(response.tool_calls) # 5. 把結(jié)果寫回上下文并保存狀態(tài) task_state.messages.append(tool_result_message) checkpoint(task_state, phaseafter_tool_call) # 6. 更新步驟狀態(tài) mark_step_complete(task_state, step) checkpoint(task_state, phasestep_complete)這段代碼看起來簡單實(shí)際運(yùn)行起來你會發(fā)現(xiàn)真正讓恢復(fù)變得可靠的不是哪一次單獨(dú)的保存而是“模型前、工具前、工具后、步驟后”這四個(gè)點(diǎn)的組合。3.3 恢復(fù)算法定位最后一個(gè)干凈狀態(tài)沿步驟續(xù)跑恢復(fù)算法不需要多高深核心就三條找到最近的干凈檢查點(diǎn)、確認(rèn)哪些步驟已經(jīng)完成、從失敗步驟的下一個(gè)可執(zhí)行步驟繼續(xù)往下走。async def recover_task(task_id): # 1. 讀取任務(wù)狀態(tài)和檢查點(diǎn) task_state load_latest_checkpoint(task_id) # 2. 找出所有未完成且可執(zhí)行的步驟 pending_steps get_pending_steps(task_state) # 3. 如果不依賴已完成步驟且不是重試陷阱就繼續(xù)執(zhí)行 for step in pending_steps: if step.status completed: continue if not dependencies_satisfied(task_state, step): continue task_state.current_step_id step.step_id step.retry_count 1 # 4. 如果該步驟已經(jīng)產(chǎn)生過副作用先做冪等校驗(yàn) if has_side_effect_record(step): side_effect check_side_effect_status(step) if side_effect confirmed_success: mark_step_complete(task_state, step) continue elif side_effect unknown: # 需要人工或自動確認(rèn) await confirm_or_cleanup(step) # 5. 重新執(zhí)行當(dāng)前步驟 await run_agent_step(task_state, step) # 6. 所有步驟完成后匯總輸出 return task_state這里有個(gè)容易被忽略的細(xì)節(jié)恢復(fù)時(shí)的上下文消息列表不能簡單地把所有歷史消息全部塞回模型輸入。因?yàn)?Agent 執(zhí)行到一半失敗時(shí)上下文里可能已經(jīng)積累了很長一大段對話其中很多內(nèi)容在規(guī)劃決策中已經(jīng)沒有價(jià)值了。恢復(fù)時(shí)應(yīng)該基于“最近 N 輪有效交互 任務(wù)初始目標(biāo) 已完成步驟摘要”來重建上下文既節(jié)省 Token又讓模型更快進(jìn)入狀態(tài)。4. 最難的坑工具調(diào)用的副作用怎么避免重復(fù)和漏處理如果說狀態(tài)保存是斷點(diǎn)繼續(xù)的地基那工具調(diào)用的冪等性處理就是地基里最容易塌的那塊磚。恢復(fù)做得再好只要工具被執(zhí)行了兩次業(yè)務(wù)上的賬就亂了。4.1 為什么“執(zhí)行失敗”不等于“沒有執(zhí)行”最常見的場景是第三方 API 調(diào)用超時(shí)。你的 Agent 調(diào)用了支付接口請求發(fā)出去了但等待響應(yīng)時(shí)連接斷了代碼這邊認(rèn)為調(diào)用失敗。實(shí)際上服務(wù)端那邊可能已經(jīng)扣款成功、已經(jīng)發(fā)了消息、已經(jīng)改了訂單狀態(tài)。這種情況下如果你在恢復(fù)時(shí)直接重試這個(gè)工具調(diào)用就會導(dǎo)致重復(fù)扣款、重復(fù)發(fā)消息。更麻煩的是如果你不重試又可能錯過真正還沒執(zhí)行的那個(gè)操作。這是分布式系統(tǒng)里經(jīng)典的“at-least-once vs at-most-once”問題。對 Agent 來說大部分步驟我們都能接受“至少執(zhí)行一次”但帶財(cái)務(wù)性質(zhì)、通知性質(zhì)、寫操作性質(zhì)的工具調(diào)用必須做到“最多執(zhí)行一次”或者“精確識別已執(zhí)行”。4.2 冪等鍵與“先記賬后執(zhí)行”模式我的做法是規(guī)定所有可能產(chǎn)生副作用的工具調(diào)用在真正發(fā)出去之前先在工具調(diào)用賬本里寫入一條status pending的記錄并生成一個(gè)冪等鍵。這個(gè)冪等鍵通常由任務(wù) ID 步驟 ID 工具名 參數(shù)哈希組成。然后調(diào)用第三方接口時(shí)把冪等鍵作為請求頭或者請求體字段一起傳過去。凡是支持冪等鍵的服務(wù)端都會對相同冪等鍵的請求自動去重。async def execute_tool_with_idempotency(task_state, tool_call): key build_idempotency_key(task_state, tool_call) # 1. 先記賬 record create_tool_call_record( task_idtask_state.task_id, step_idtool_call.step_id, tool_nametool_call.name, argumentstool_call.args, idempotency_keykey, statuspending ) # 2. 再執(zhí)行 try: result await call_tool_api(tool_call, idempotency_keykey) mark_tool_call_success(record.id, result) return result except Exception as e: # 3. 失敗時(shí)不能直接標(biāo)失敗要檢查服務(wù)端狀態(tài) actual_status await probe_tool_execution_status(key) if actual_status success: # 實(shí)際已執(zhí)行成功只是響應(yīng)丟了返回緩存的成功結(jié)果 mark_tool_call_success(record.id, None) return retrieve_cached_result(key) else: mark_tool_call_failed(record.id, e) raise注意這里的probe_tool_execution_status它的作用是主動查詢服務(wù)端確認(rèn)這筆操作到底發(fā)生了沒有。如果服務(wù)端提供查詢接口這招最保險(xiǎn)。如果查不了就只好把這種“未知狀態(tài)”的調(diào)用交給下一節(jié)的人工確認(rèn)流程。4.3 無法確認(rèn)的工具調(diào)用標(biāo)記為“未知”而不是“失敗”很多第三方 API 根本不提供冪等鍵也不提供查詢接口。這時(shí)我們要做的是誠實(shí)——把工具調(diào)用的狀態(tài)標(biāo)記為executed_unknown而不是直接標(biāo)記為失敗。executed_unknown狀態(tài)在恢復(fù)算法里是個(gè)特殊分支。遇到這種分支我不自動重試也不直接跳過而是把這個(gè)異常情況拋給一個(gè)人工確認(rèn)隊(duì)列。操作人員看一遍調(diào)用參數(shù)和上下文手動確認(rèn)這筆操作是否已生效然后決定是跳過還是補(bǔ)做還是回滾。這在自動化體系里看似笨拙但卻是業(yè)務(wù)安全的關(guān)鍵一環(huán)。我寧可讓人工確認(rèn)一次模糊狀態(tài)也不愿意讓系統(tǒng)在無感知的情況下重復(fù)扣費(fèi)。5. 不是所有斷點(diǎn)都值得救恢復(fù)決策與人工介入機(jī)制做斷點(diǎn)恢復(fù)做到后面你會遇到一個(gè)更深層的問題這個(gè)斷點(diǎn)該不該恢復(fù)恢復(fù)的成本可能比重跑還高甚至恢復(fù)本身就是錯的。5.1 用三個(gè)維度判斷“是否值得從斷點(diǎn)繼續(xù)”我總結(jié)了一個(gè)簡單的判斷框架三個(gè)維度分別是失敗類型、副作用風(fēng)險(xiǎn)、剩余工作量。失敗類型決定了恢復(fù)策略的可行性。如果是限流、超時(shí)這類臨時(shí)性故障恢復(fù)的把握很大。如果是模型上下文溢出、規(guī)劃死循環(huán)這類邏輯性故障光恢復(fù)沒用還得調(diào)整策略。如果是外部 API 返回結(jié)構(gòu)徹底變化那就要先改代碼再恢復(fù)。副作用風(fēng)險(xiǎn)決定了恢復(fù)是否需要額外確認(rèn)。帶資金、通知、寫庫性質(zhì)的操作恢復(fù)前的確認(rèn)成本很高純讀取類的工具調(diào)用隨便重試。剩余工作量決定了恢復(fù)的性價(jià)比。如果已經(jīng)執(zhí)行了 80% 的步驟恢復(fù)是明智的。如果才跑到第二步就掛了直接整個(gè)任務(wù)重跑反而簡單。我把這些規(guī)則做成了一張決策表每次恢復(fù)前自動過一遍。場景失敗原因舉例副作用風(fēng)險(xiǎn)建議動作模型調(diào)用限流429 或超時(shí)低重試當(dāng)前步驟等待退避模型輸出解析失敗JSON 破損、字段缺失低截?cái)嘀卦嚮蚋挠酶鼘捤山馕銎鞴ぞ哒{(diào)用超時(shí)第三方接口無響應(yīng)高先查詢狀態(tài)真失敗再重試上下文溢出context 超限中摘要?dú)v史后重試或切換規(guī)劃策略規(guī)劃死循環(huán)同一操作循環(huán)執(zhí)行中中斷并人工介入修改計(jì)劃外部接口結(jié)構(gòu)變更API schema 不匹配中人工介入升級適配層5.2 設(shè)置恢復(fù)上限別讓斷點(diǎn)續(xù)跑變成無限循環(huán)斷點(diǎn)恢復(fù)最危險(xiǎn)的情況是同一個(gè)步驟失敗后反復(fù)恢復(fù)、反復(fù)執(zhí)行形成一個(gè)看不見的循環(huán)。尤其當(dāng)工具調(diào)用是冪等的、返回結(jié)果總是失敗時(shí)這個(gè)循環(huán)會白白消耗大量 Token還會拖慢整個(gè)任務(wù)隊(duì)列。我設(shè)置了兩層上限。第一層是單步重試上限。同一步驟的連續(xù)失敗次數(shù)達(dá)到上限后不再自動重試而是進(jìn)入人工隊(duì)列。第二層是任務(wù)級恢復(fù)上限。整個(gè)任務(wù)從斷點(diǎn)恢復(fù)的總次數(shù)也設(shè)上限比如一個(gè)任務(wù)最多恢復(fù) 5 次超過之后強(qiáng)制進(jìn)入人工處理。上層邏輯簡單但極有效。我見過一個(gè)真實(shí)的線上事故某個(gè)數(shù)據(jù)處理 Agent 在調(diào)用日期解析工具時(shí)因?yàn)闀r(shí)區(qū)參數(shù)傳錯了每次恢復(fù)都得到一樣的結(jié)果任務(wù)在幾個(gè)小時(shí)內(nèi)反復(fù)自動重試了一百多次。設(shè)置恢復(fù)上限之后這種問題最多浪費(fèi)到第 5 次就會被人工發(fā)現(xiàn)。5.3 人工介入通道給恢復(fù)系統(tǒng)留一個(gè)“人肉出口”無論自動化做得多么完善總有一些斷點(diǎn)是需要人來判斷的。我把人工介入設(shè)計(jì)成恢復(fù)流程里的一等公民而不是最后兜底。具體做法是給每個(gè)“待人工確認(rèn)”的任務(wù)生成一個(gè)結(jié)構(gòu)化面板面板里包含目標(biāo)描述、當(dāng)前步驟、失敗原因、最近幾次工具調(diào)用的參數(shù)與結(jié)果、恢復(fù)建議選項(xiàng)重試/跳過/回滾/終止。操作者點(diǎn)一下就能選擇后續(xù)動作。這里有個(gè)經(jīng)驗(yàn)之談人工介入面板的信息要少而精。當(dāng)初我把大量日志全塞進(jìn)面板操作者反而找不到重點(diǎn)。后來精簡成“目標(biāo)、斷點(diǎn)位置、失敗原因、推薦動作”四塊信息處理效率高了很多。6. 生產(chǎn)環(huán)境里的隱藏細(xì)節(jié)上下文重建、反序列化與并發(fā)隔離前面幾節(jié)已經(jīng)把斷點(diǎn)恢復(fù)的主體方案講清楚了但真正投入生產(chǎn)后還會有三個(gè)細(xì)節(jié)問題每一個(gè)都能讓你的恢復(fù)機(jī)制在關(guān)鍵時(shí)刻崩掉。6.1 上下文重建恢復(fù)時(shí)如何不把 Token 撐爆長任務(wù)的 Agent 執(zhí)行到一半上下文里可能攢了幾百條消息?；謴?fù)時(shí)如果把這些原封不動全塞回去有兩個(gè)后果一是 Context Window 可能直接溢出二是模型注意力被大量歷史噪音分散決策質(zhì)量下降。我的做法是分層重建上下文核心層系統(tǒng)提示、用戶原始目標(biāo)、當(dāng)前步驟描述、最近 5 輪關(guān)鍵交互。摘要層更早的歷史消息壓縮成一段結(jié)構(gòu)化摘要包含已完成步驟、重要工具結(jié)果、關(guān)鍵決策。工具層最近一次工具調(diào)用原文確保模型能基于最新的觀測結(jié)果繼續(xù)推理。摘要的生成可以用模型來做也可以用規(guī)則抽取。規(guī)則抽取更可控模型摘要更自然我目前用的是“規(guī)則抽取 模型潤色”的混合方式。6.2 反序列化的坑狀態(tài)里別放模型實(shí)例和臨時(shí)對象寫檢查點(diǎn)時(shí)狀態(tài)對象里哪些字段會被序列化直接影響恢復(fù)的可靠性。我在早期犯過的錯是把pandas.DataFrame、PIL.Image、requests.Session、不穩(wěn)定的模型實(shí)例等對象直接放進(jìn)了狀態(tài)里。結(jié)果序列化時(shí)要么報(bào)錯要么存了一個(gè)巨大的二進(jìn)制塊恢復(fù)時(shí)還得重新初始化。后來我定了一個(gè)規(guī)則狀態(tài)里只允許放基本類型、JSON 可序列化的字典和列表。所有重對象一律在恢復(fù)后重建。比如數(shù)據(jù)庫連接、HTTP 客戶端、模型實(shí)例都由恢復(fù)函數(shù)重新創(chuàng)建。這條規(guī)則想起來容易執(zhí)行時(shí)容易漏。建議在檢查點(diǎn)保存函數(shù)里加一個(gè)校驗(yàn)序列化之前遞歸檢查一遍發(fā)現(xiàn)不可序列化對象直接報(bào)錯而不是等到恢復(fù)時(shí)才發(fā)現(xiàn)壞了。6.3 并發(fā)與文件鎖多任務(wù)同時(shí)恢復(fù)時(shí)的隔離問題最后一個(gè)坑是并發(fā)恢復(fù)。當(dāng) Agent 框架部署成多副本多個(gè)任務(wù)同時(shí)崩潰、同時(shí)恢復(fù)時(shí)很容易出現(xiàn)兩個(gè)恢復(fù)流程同時(shí)操作同一個(gè)任務(wù)的狀態(tài)導(dǎo)致數(shù)據(jù)互相覆蓋。我的解決方案是引入任務(wù)級鎖。每個(gè)任務(wù)的恢復(fù)流程開始前先嘗試獲取分布式鎖拿到鎖的才能繼續(xù)恢復(fù)拿不到鎖的等待或者放棄。同時(shí)檢查點(diǎn)事務(wù)要保證原子性讀取和寫入之間不能用非原子操作。實(shí)現(xiàn)鎖的方式很多數(shù)據(jù)庫唯一索引、Redis 鎖、或者文件鎖都可以。關(guān)鍵在于鎖一定要在“讀取檢查點(diǎn)”之前獲取否則你讀到的可能正是另一個(gè)流程正在寫入的中間狀態(tài)。7. 我踩過幾次坑之后的最終經(jīng)驗(yàn)做完這套斷點(diǎn)恢復(fù)機(jī)制最大的感悟是斷點(diǎn)繼續(xù)不是附加功能而是 Agent 系統(tǒng)的剛需。哪怕你現(xiàn)在的 Agent 任務(wù)很短、很穩(wěn)定也建議從一開始就把狀態(tài)持久化做上否則任務(wù)一旦變長你會被重跑成本和教育用戶重新等待的時(shí)間拖住。幾個(gè)實(shí)戰(zhàn)建議供參考。第一保存時(shí)機(jī)寧可多不要少。模型調(diào)用前、工具調(diào)用前、工具調(diào)用后三步打點(diǎn)是底線多打幾次不會錯少打一次恢復(fù)時(shí)就可能亂。第二恢復(fù)時(shí)在系統(tǒng)提示詞里明確告訴模型“這是一個(gè)從斷點(diǎn)恢復(fù)的任務(wù)”。實(shí)測下來模型知道自己在續(xù)跑時(shí)會更多參考已完成步驟的信息減少重新規(guī)劃的沖動。第三用故障注入測試恢復(fù)邏輯。人為制造模型超時(shí)、工具亂序返回、進(jìn)程殺死的場景驗(yàn)證檢查點(diǎn)和恢復(fù)鏈路是否真的可靠別等到線上出問題才后悔。這套方案上線之后我們的長任務(wù)成功率提升了一大截最有價(jià)值的地方還不是省 Token而是讓運(yùn)營和開發(fā)不再恐懼“長任務(wù)跑了一半失敗”這種事故。要是你的 Agent 也在為同樣的痛點(diǎn)頭疼按這個(gè)思路落地一遍應(yīng)該能少走不少彎路。