Agent 跑到一半掛了是做 Agent 落地的人遲早要撞上的事。我維護(hù)某客服工單處理系統(tǒng)時(shí)一個(gè)多步驟 Agent 任務(wù)跑了半個(gè)多小時(shí)調(diào)用了二十多次模型結(jié)果倒數(shù)第二步因?yàn)榈谌轿锪鹘涌谙蘖髦苯訏佸e(cuò)。整個(gè)任務(wù)從頭重跑Token 花了兩倍用戶還在那多等了十分鐘。那之后我下定決心把“斷點(diǎn)繼續(xù)”做進(jìn) Agent 的底層框架這篇就講我在實(shí)戰(zhàn)里總結(jié)出來的完整方案失敗到底長(zhǎng)什么樣、檢查點(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. 先搞清楚失敗長(zhǎng)什么樣Agent 中斷的常見形態(tài)與根因做斷點(diǎn)恢復(fù)之前必須先把你遇到的“失敗”分類。我見過太多人一上來就寫恢復(fù)邏輯結(jié)果恢復(fù)邏輯本身就是個(gè)脆弱的玩具因?yàn)檫B失敗發(fā)生在哪個(gè)階段都沒搞清楚。1.1 進(jìn)程級(jí)失敗與邏輯級(jí)失敗兩種不同的恢復(fù)思路Agent 跑掛了從表象上看是“任務(wù)沒完成”“報(bào)錯(cuò)了”但底層原因可以分成兩大類。進(jìn)程級(jí)失敗是指運(yùn)行環(huán)境出了問題內(nèi)存溢出、容器被殺、部署重啟、依賴服務(wù)崩潰、進(jìn)程被 OOM Killer 干掉。這類失敗的特點(diǎn)是Agent 的整個(gè)狀態(tài)包括保存在內(nèi)存里的聊天記錄、任務(wù)隊(duì)列、中間變量全部沒了。邏輯級(jí)失敗則是指 Agent 自身在“規(guī)劃—執(zhí)行—觀察”循環(huán)中走入了死胡同上下文溢出、模型輸出格式不符合解析要求、工具調(diào)用返回了意外結(jié)構(gòu)、規(guī)劃步驟形成了死循環(huán)或者某一步拋出了沒有兜底的異常。這兩類的恢復(fù)策略完全不同。進(jìn)程級(jí)失敗只要能拿回外部持久化的狀態(tài)原地重建執(zhí)行環(huán)境就可以續(xù)跑。邏輯級(jí)失敗單純續(xù)跑往往沒用因?yàn)閷?dǎo)致失敗的條件還在你得先修正計(jì)劃、截?cái)嗌舷挛幕蛘咔袚Q策略。我在最初設(shè)計(jì)恢復(fù)機(jī)制時(shí)犯過的一個(gè)錯(cuò)誤就是把所有失敗都當(dāng)成“拋異?！碧幚怼：髞戆l(fā)現(xiàn)上下文溢出根本不會(huì)拋異常就是模型輸出忽然變得亂七八糟解析器報(bào)錯(cuò)然后整個(gè)循環(huán)結(jié)束。這類失敗如果只做“重試”只會(huì)把同樣的錯(cuò)誤再來一遍。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)變化、限流限頻都會(huì)導(dǎo)致 Agent 拿不到可用觀測(cè)結(jié)果。更麻煩的是工具調(diào)用可能有副作用——扣費(fèi)、發(fā)消息、寫數(shù)據(jù)庫、調(diào)外部系統(tǒng)。這類失敗不能簡(jiǎn)單重試因?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)用那樣有明確的錯(cuò)誤碼往往需要翻日志才能定位。有一個(gè)很反直覺的事實(shí)真正讓 Agent 任務(wù)全盤崩潰的往往不是模型而是我們對(duì)工具返回值的處理太草率。模型偶爾偷個(gè)懶、格式飄一下只要解析層做了容錯(cuò)都能救回來。但工具調(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ù)級(jí)元數(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í)候就會(huì)出問題。比如只保存消息歷史不保存步驟進(jìn)度那恢復(fù)時(shí)就得從第一條消息重新推理雖然模型能“回憶”出之前干了什么但工具已經(jīng)帶副作用執(zhí)行過了重推的時(shí)候很可能重復(fù)調(diào)用。我在實(shí)際項(xiàng)目里習(xí)慣把所有狀態(tài)統(tǒng)一存在一個(gè)可持久化的狀態(tài)對(duì)象里每個(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è)長(zhǎng)流程游戲每過一個(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)重建到最后一條事件對(duì)應(yīng)的位置。定期快照的做法是每隔幾個(gè)步驟或者每個(gè)步驟結(jié)束時(shí)把完整狀態(tài)對(duì)象一次性序列化保存下來?；謴?fù)的時(shí)候直接加載最近的快照不需要重放。兩條路各有適用場(chǎng)景。事件溯源的優(yōu)點(diǎn)是粒度細(xì)、可審計(jì)、能精確恢復(fù)到最后一步缺點(diǎn)是重放成本高事件多了以后很慢?？煺盏膬?yōu)點(diǎn)是恢復(fù)快、實(shí)現(xiàn)簡(jiǎn)單缺點(diǎn)是丟失兩次快照之間的狀態(tài)變化而且如果狀態(tài)對(duì)象里有不可序列化的內(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)的。理由很簡(jiǎn)單模型調(diào)用之前存的狀態(tài)是“這一步還沒開始”的干凈狀態(tài)如果調(diào)用超時(shí)或模型輸出無法解析從這個(gè)狀態(tài)重試毫無壓力。工具調(diào)用之前存的狀態(tài)則是“副作用尚未發(fā)生”的狀態(tài)一旦工具調(diào)用失敗可以判斷副作用到底產(chǎn)生了沒有再?zèng)Q定是重試還是清理。至于工具返回之后、進(jìn)入下一個(gè)步驟之前建議也存一次因?yàn)檫@時(shí)候工具的結(jié)果已經(jīng)進(jìn)入了上下文下一步要基于這個(gè)結(jié)果繼續(xù)推理。錯(cuò)過這個(gè)點(diǎn)恢復(fù)后就得多一次推理才能重建同樣的上下文。存太頻繁也有代價(jià)。每一步都全量序列化遇到大上下文時(shí)序列化時(shí)間和存儲(chǔ)開銷都會(huì)上漲。我后來把序列化拆成了兩層高頻輕量層只存步驟 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í)的情況下也能識(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)這段代碼看起來簡(jiǎn)單實(shí)際運(yùn)行起來你會(huì)發(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: # 需要人工或自動(dòng)確認(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í)的上下文消息列表不能簡(jiǎn)單地把所有歷史消息全部塞回模型輸入。因?yàn)?Agent 執(zhí)行到一半失敗時(shí)上下文里可能已經(jīng)積累了很長(zhǎng)一大段對(duì)話其中很多內(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í)行”最常見的場(chǎng)景是第三方 API 調(diào)用超時(shí)。你的 Agent 調(diào)用了支付接口請(qǐng)求發(fā)出去了但等待響應(yīng)時(shí)連接斷了代碼這邊認(rèn)為調(diào)用失敗。實(shí)際上服務(wù)端那邊可能已經(jīng)扣款成功、已經(jīng)發(fā)了消息、已經(jīng)改了訂單狀態(tài)。這種情況下如果你在恢復(fù)時(shí)直接重試這個(gè)工具調(diào)用就會(huì)導(dǎo)致重復(fù)扣款、重復(fù)發(fā)消息。更麻煩的是如果你不重試又可能錯(cuò)過真正還沒執(zhí)行的那個(gè)操作。這是分布式系統(tǒng)里經(jīng)典的“at-least-once vs at-most-once”問題。對(duì) Agent 來說大部分步驟我們都能接受“至少執(zhí)行一次”但帶財(cái)務(wù)性質(zhì)、通知性質(zhì)、寫操作性質(zhì)的工具調(diào)用必須做到“最多執(zhí)行一次”或者“精確識(shí)別已執(zhí)行”。4.2 冪等鍵與“先記賬后執(zhí)行”模式我的做法是規(guī)定所有可能產(chǎn)生副作用的工具調(diào)用在真正發(fā)出去之前先在工具調(diào)用賬本里寫入一條status pending的記錄并生成一個(gè)冪等鍵。這個(gè)冪等鍵通常由任務(wù) ID 步驟 ID 工具名 參數(shù)哈希組成。然后調(diào)用第三方接口時(shí)把冪等鍵作為請(qǐng)求頭或者請(qǐng)求體字段一起傳過去。凡是支持冪等鍵的服務(wù)端都會(huì)對(duì)相同冪等鍵的請(qǐng)求自動(dòng)去重。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它的作用是主動(dòng)查詢服務(wù)端確認(rèn)這筆操作到底發(fā)生了沒有。如果服務(wù)端提供查詢接口這招最保險(xiǎn)。如果查不了就只好把這種“未知狀態(tài)”的調(diào)用交給下一節(jié)的人工確認(rèn)流程。4.3 無法確認(rèn)的工具調(diào)用標(biāo)記為“未知”而不是“失敗”很多第三方 API 根本不提供冪等鍵也不提供查詢接口。這時(shí)我們要做的是誠(chéng)實(shí)——把工具調(diào)用的狀態(tài)標(biāo)記為executed_unknown而不是直接標(biāo)記為失敗。executed_unknown狀態(tài)在恢復(fù)算法里是個(gè)特殊分支。遇到這種分支我不自動(dòng)重試也不直接跳過而是把這個(gè)異常情況拋給一個(gè)人工確認(rèn)隊(duì)列。操作人員看一遍調(diào)用參數(shù)和上下文手動(dòng)確認(rèn)這筆操作是否已生效然后決定是跳過還是補(bǔ)做還是回滾。這在自動(dòng)化體系里看似笨拙但卻是業(yè)務(wù)安全的關(guān)鍵一環(huán)。我寧可讓人工確認(rèn)一次模糊狀態(tài)也不愿意讓系統(tǒng)在無感知的情況下重復(fù)扣費(fèi)。5. 不是所有斷點(diǎn)都值得救恢復(fù)決策與人工介入機(jī)制做斷點(diǎn)恢復(fù)做到后面你會(huì)遇到一個(gè)更深層的問題這個(gè)斷點(diǎn)該不該恢復(fù)恢復(fù)的成本可能比重跑還高甚至恢復(fù)本身就是錯(cuò)的。5.1 用三個(gè)維度判斷“是否值得從斷點(diǎn)繼續(xù)”我總結(jié)了一個(gè)簡(jiǎn)單的判斷框架三個(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ù)重跑反而簡(jiǎn)單。我把這些規(guī)則做成了一張決策表每次恢復(fù)前自動(dòng)過一遍。場(chǎng)景失敗原因舉例副作用風(fēng)險(xiǎn)建議動(dòng)作模型調(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 不匹配中人工介入升級(jí)適配層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)會(huì)白白消耗大量 Token還會(huì)拖慢整個(gè)任務(wù)隊(duì)列。我設(shè)置了兩層上限。第一層是單步重試上限。同一步驟的連續(xù)失敗次數(shù)達(dá)到上限后不再自動(dòng)重試而是進(jìn)入人工隊(duì)列。第二層是任務(wù)級(jí)恢復(fù)上限。整個(gè)任務(wù)從斷點(diǎn)恢復(fù)的總次數(shù)也設(shè)上限比如一個(gè)任務(wù)最多恢復(fù) 5 次超過之后強(qiáng)制進(jìn)入人工處理。上層邏輯簡(jiǎn)單但極有效。我見過一個(gè)真實(shí)的線上事故某個(gè)數(shù)據(jù)處理 Agent 在調(diào)用日期解析工具時(shí)因?yàn)闀r(shí)區(qū)參數(shù)傳錯(cuò)了每次恢復(fù)都得到一樣的結(jié)果任務(wù)在幾個(gè)小時(shí)內(nèi)反復(fù)自動(dòng)重試了一百多次。設(shè)置恢復(fù)上限之后這種問題最多浪費(fèi)到第 5 次就會(huì)被人工發(fā)現(xiàn)。5.3 人工介入通道給恢復(fù)系統(tǒng)留一個(gè)“人肉出口”無論自動(dòng)化做得多么完善總有一些斷點(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ù)動(dòng)作。這里有個(gè)經(jīng)驗(yàn)之談人工介入面板的信息要少而精。當(dāng)初我把大量日志全塞進(jìn)面板操作者反而找不到重點(diǎn)。后來精簡(jiǎn)成“目標(biāo)、斷點(diǎn)位置、失敗原因、推薦動(dòng)作”四塊信息處理效率高了很多。6. 生產(chǎn)環(huán)境里的隱藏細(xì)節(jié)上下文重建、反序列化與并發(fā)隔離前面幾節(jié)已經(jīng)把斷點(diǎn)恢復(fù)的主體方案講清楚了但真正投入生產(chǎn)后還會(huì)有三個(gè)細(xì)節(jié)問題每一個(gè)都能讓你的恢復(fù)機(jī)制在關(guān)鍵時(shí)刻崩掉。6.1 上下文重建恢復(fù)時(shí)如何不把 Token 撐爆長(zhǎng)任務(wù)的 Agent 執(zhí)行到一半上下文里可能攢了幾百條消息?；謴?fù)時(shí)如果把這些原封不動(dòng)全塞回去有兩個(gè)后果一是 Context Window 可能直接溢出二是模型注意力被大量歷史噪音分散決策質(zhì)量下降。我的做法是分層重建上下文核心層系統(tǒng)提示、用戶原始目標(biāo)、當(dāng)前步驟描述、最近 5 輪關(guān)鍵交互。摘要層更早的歷史消息壓縮成一段結(jié)構(gòu)化摘要包含已完成步驟、重要工具結(jié)果、關(guān)鍵決策。工具層最近一次工具調(diào)用原文確保模型能基于最新的觀測(cè)結(jié)果繼續(xù)推理。摘要的生成可以用模型來做也可以用規(guī)則抽取。規(guī)則抽取更可控模型摘要更自然我目前用的是“規(guī)則抽取 模型潤(rùn)色”的混合方式。6.2 反序列化的坑狀態(tài)里別放模型實(shí)例和臨時(shí)對(duì)象寫檢查點(diǎn)時(shí)狀態(tài)對(duì)象里哪些字段會(huì)被序列化直接影響恢復(fù)的可靠性。我在早期犯過的錯(cuò)是把pandas.DataFrame、PIL.Image、requests.Session、不穩(wěn)定的模型實(shí)例等對(duì)象直接放進(jìn)了狀態(tài)里。結(jié)果序列化時(shí)要么報(bào)錯(cuò)要么存了一個(gè)巨大的二進(jìn)制塊恢復(fù)時(shí)還得重新初始化。后來我定了一個(gè)規(guī)則狀態(tài)里只允許放基本類型、JSON 可序列化的字典和列表。所有重對(duì)象一律在恢復(fù)后重建。比如數(shù)據(jù)庫連接、HTTP 客戶端、模型實(shí)例都由恢復(fù)函數(shù)重新創(chuàng)建。這條規(guī)則想起來容易執(zhí)行時(shí)容易漏。建議在檢查點(diǎn)保存函數(shù)里加一個(gè)校驗(yàn)序列化之前遞歸檢查一遍發(fā)現(xiàn)不可序列化對(duì)象直接報(bào)錯(cuò)而不是等到恢復(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ù)級(jí)鎖。每個(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ù)一旦變長(zhǎng)你會(huì)被重跑成本和教育用戶重新等待的時(shí)間拖住。幾個(gè)實(shí)戰(zhàn)建議供參考。第一保存時(shí)機(jī)寧可多不要少。模型調(diào)用前、工具調(diào)用前、工具調(diào)用后三步打點(diǎn)是底線多打幾次不會(huì)錯(cuò)少打一次恢復(fù)時(shí)就可能亂。第二恢復(fù)時(shí)在系統(tǒng)提示詞里明確告訴模型“這是一個(gè)從斷點(diǎn)恢復(fù)的任務(wù)”。實(shí)測(cè)下來模型知道自己在續(xù)跑時(shí)會(huì)更多參考已完成步驟的信息減少重新規(guī)劃的沖動(dòng)。第三用故障注入測(cè)試恢復(fù)邏輯。人為制造模型超時(shí)、工具亂序返回、進(jìn)程殺死的場(chǎng)景驗(yàn)證檢查點(diǎn)和恢復(fù)鏈路是否真的可靠別等到線上出問題才后悔。這套方案上線之后我們的長(zhǎng)任務(wù)成功率提升了一大截最有價(jià)值的地方還不是省 Token而是讓運(yùn)營(yíng)和開發(fā)不再恐懼“長(zhǎng)任務(wù)跑了一半失敗”這種事故。要是你的 Agent 也在為同樣的痛點(diǎn)頭疼按這個(gè)思路落地一遍應(yīng)該能少走不少?gòu)澛贰?