用報錯排查：用 FISSION-GRPO 強化學習思路定位并修復工具錯誤)
1. Agent 工具調(diào)用報錯為什么總在同一個坑里打轉(zhuǎn)大模型 Agent 工具調(diào)用報錯排查是每個把 Agent 往生產(chǎn)環(huán)境推的人都會撞上的墻。你寫好了 function calling 的 schema接上了搜索、數(shù)據(jù)庫、代碼執(zhí)行幾個工具本地跑 demo 一切正常一上量就開始飄401 鑒權(quán)失敗、local proxy failed、429 限流、參數(shù)類型不合法、工具部分執(zhí)行成功……最要命的不是報錯本身而是 Agent 面對報錯時的反應(yīng)——它不讀真實錯誤信息而是自己編一個原因然后基于虛構(gòu)的原因重試失敗再編再重試。我見過一個典型循環(huán)Agent 調(diào)用某個 HTTP 工具返回 401它沒有把 401 當成憑證問題來處理反而在下一輪里虛構(gòu)出可能是參數(shù)格式不對于是改了個無關(guān)參數(shù)再調(diào)還是 401接著又虛構(gòu)可能是工具名寫錯了換了個工具名繼續(xù) 401。整個過程它一次都沒真正讀取過響應(yīng)體里的Unauthorized字段。這就是 excerpt 里描述的那個死循環(huán)調(diào)用失敗 → 錯誤歸因 → 虛構(gòu)修復方案 → 再次失敗 → 繼續(xù)虛構(gòu)。這個問題的根子在于傳統(tǒng)工具學習只訓練模型三件事選對函數(shù)、輸出合法 JSON/XML、填對參數(shù)。它假設(shè)工具調(diào)用是一次性正確的動作。但真實的多輪 Agent 環(huán)境里API 狀態(tài)會變、token 會過期、限流會觸發(fā)、工具可能只執(zhí)行了一半。模型不能只會正確調(diào)用還必須會讀報錯、診斷原因、選擇新的恢復動作。FISSION-GRPO 這個強化學習框架解決的正是這件事。它的核心鏈路是發(fā)現(xiàn)當前策略的錯誤 → 為錯誤生成診斷反饋 → 從錯誤處重新采樣多個恢復方案 → 訓練模型學會恢復。注意它和普通 GRPO 的區(qū)別——GRPO 是組相對策略優(yōu)化同一個問題采樣多條軌跡按組內(nèi)獎勵相對高低算優(yōu)勢高于平均的增強、低于平均的抑制不需要單獨的價值模型。FISSION-GRPO 在此基礎(chǔ)上加了一個裂變動作把一個錯誤裂變成多條恢復軌跡專門訓練糾錯能力。這篇文章不講論文復現(xiàn)講的是怎么把這套發(fā)現(xiàn)錯誤—診斷—恢復的思路落到你手頭的 Agent 工程里并且用 TaoToken 的統(tǒng)一 Key/API 通道把 401、local proxy failed、429 這些真實報錯復現(xiàn)出來、驗證你的 Agent 到底會不會自愈。適合正在做 Agent 工具調(diào)用、被報錯循環(huán)折磨、想搞清楚怎么讓 Agent 自己修工具錯誤的開發(fā)者。2. 用 TaoToken 統(tǒng)一通道搭一個可復現(xiàn)的報錯環(huán)境要讓 Agent 學會處理工具錯誤第一步不是改 prompt而是先有一個能穩(wěn)定復現(xiàn)各類報錯的實驗環(huán)境。如果每次報錯都靠線上偶發(fā)你根本沒法系統(tǒng)性地驗證 Agent 的恢復策略。我的做法是用 TaoToken 作為統(tǒng)一的模型調(diào)用通道把 Agent 的大腦和工具分開這樣報錯來源清晰、可注入、可回放。TaoToken 在這里的角色是統(tǒng)一 Key/API 通道。官網(wǎng)地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。它的價值在于你不需要為每個模型、每個工具單獨維護一套鑒權(quán)和 base_urlAgent 的模型調(diào)用走一個通道工具調(diào)用走另一個通道報錯時能快速判斷是模型側(cè)問題還是工具側(cè)問題。先說清楚為什么這個分離很重要。Agent 報錯排查最怕的就是錯誤來源不明。401 可能是模型 API Key 過期也可能是工具自己的鑒權(quán)失敗local proxy failed 可能是本地網(wǎng)絡(luò)配置問題也可能是工具服務(wù)沒起來429 可能是模型限流也可能是工具后端限流。如果你把模型和工具混在一個通道里排查時就是一團亂麻。我的實驗環(huán)境是這樣搭的模型側(cè)Agent 的推理和工具選擇走 TaoToken 的 API 通道。你可以在 https://taotoken.net/api-keys 拿到 Key然后在代碼里配置 base_url 和 model。工具側(cè)我故意寫幾個會報錯的 mock 工具用來注入 401、429、參數(shù)錯誤、部分成功等場景。先看模型側(cè)的配置。如果你用的是 OpenAI 兼容的 SDK配置大概是這樣from openai import OpenAI client OpenAI( api_key你的_TaoToken_Key, base_urlhttps://taotoken.net/api/v1 ) response client.chat.completions.create( modelclaude-sonnet-4-5, messages[ {role: user, content: 幫我查一下北京今天的天氣} ], tools[weather_tool_schema], tool_choiceauto )這里base_url指向 TaoToken 的 API 入口model填你要用的模型 ID。注意 base_url 后面要帶/v1這是 OpenAI 兼容協(xié)議的標準路徑。如果你用的是 Anthropic 原生協(xié)議路徑會不一樣具體可以看接入文檔 https://taotoken.net/doc 。工具側(cè)我寫了一個會按條件返回錯誤的 mock 服務(wù)。核心邏輯是根據(jù)請求頭里的一個X-Inject-Error字段決定這次返回 401、429 還是正常結(jié)果。這樣我就能在測試里精確控制第幾次調(diào)用觸發(fā)什么錯誤。from fastapi import FastAPI, Request, HTTPException app FastAPI() app.post(/tool/query_weather) async def query_weather(request: Request): inject request.headers.get(X-Inject-Error, ) if inject 401: raise HTTPException(status_code401, detailUnauthorized: token expired) if inject 429: raise HTTPException(status_code429, detailRate limit exceeded, retry after 2s) if inject partial: return {status: partial, data: {city: 北京}, error: upstream timeout on humidity field} return {status: ok, data: {city: 北京, temp: 18, weather: 晴}}這個 mock 服務(wù)跑在本地 8000 端口。Agent 調(diào)用它的時候通過 header 注入錯誤。這樣你就能在完全可控的條件下觀察 Agent 面對 401 時是讀detail字段還是自己編原因。為什么用 TaoToken 而不是直接連各家模型因為當你要對比不同模型在同一個報錯場景下的恢復能力時統(tǒng)一通道能省掉大量鑒權(quán)適配工作。你換模型只改一個 model IDbase_url 和 Key 都不動。這在做 FISSION-GRPO 思路的多恢復軌跡采樣時特別有用——你需要同一個問題采樣多條軌跡如果每條軌跡都要重新配鑒權(quán)實驗根本跑不起來。環(huán)境搭好之后先別急著上 Agent。手動發(fā)一次請求確認 401 和 429 能正常觸發(fā)確認模型側(cè)調(diào)用能通。這一步是后面所有排查的基礎(chǔ)。如果這一步就有問題先去看第 5 節(jié)的報錯對照表。3. 可復制的工具調(diào)用配置與錯誤注入驗證這一節(jié)給你可以直接抄的配置片段和驗證步驟。核心目標讓 Agent 在工具調(diào)用失敗時能拿到結(jié)構(gòu)化的錯誤信息而不是一個模糊的異常。先說工具調(diào)用的 schema 配置。很多人寫 function calling 的 schema 時只寫參數(shù)不寫錯誤處理約定。這是 Agent 學不會糾錯的第一道坎。你需要在工具描述里明確告訴模型這個工具可能返回哪些錯誤碼每個錯誤碼意味著什么。{ type: function, function: { name: query_weather, description: 查詢指定城市的天氣。調(diào)用失敗時返回結(jié)構(gòu)化錯誤401 表示憑證過期需刷新429 表示限流需退避重試partial 表示部分字段缺失可基于已有字段繼續(xù)。, parameters: { type: object, properties: { city: { type: string, description: 城市名稱如 北京 } }, required: [city] } } }注意 description 里我把錯誤碼語義寫進去了。這不是可有可無的裝飾——它直接影響模型在收到 401 時是去刷新憑證還是去改參數(shù)。FISSION-GRPO 里的 Error Simulator 干的就是類似的事生成指出錯因但不泄漏答案的反饋。你在工程里可以用工具描述和錯誤響應(yīng)體來承擔這個角色。接下來是 Agent 主循環(huán)里處理工具結(jié)果的部分。關(guān)鍵點是不要把工具返回的錯誤當成普通文本塞回對話要保留結(jié)構(gòu)化的錯誤碼和錯誤信息。import json import time def execute_tool_call(tool_call, max_retries3): name tool_call.function.name args json.loads(tool_call.function.arguments) for attempt in range(max_retries): try: if name query_weather: resp call_weather_api(args[city]) if resp.get(status) partial: return { tool_call_id: tool_call.id, role: tool, content: json.dumps({ error_code: PARTIAL, message: resp.get(error), partial_data: resp.get(data) }, ensure_asciiFalse) } return { tool_call_id: tool_call.id, role: tool, content: json.dumps(resp, ensure_asciiFalse) } except HTTPError as e: code e.response.status_code detail e.response.text if code 429: wait 2 ** attempt time.sleep(wait) continue return { tool_call_id: tool_call.id, role: tool, content: json.dumps({ error_code: code, message: detail }, ensure_asciiFalse) } return { tool_call_id: tool_call.id, role: tool, content: json.dumps({error_code: MAX_RETRY, message: 重試次數(shù)耗盡}, ensure_asciiFalse) }這段代碼有兩個設(shè)計點值得說。第一429 走指數(shù)退避重試這是工程層面的自愈不需要模型介入。第二401 和其他錯誤直接返回結(jié)構(gòu)化錯誤給模型讓模型決定下一步。這就是 FISSION-GRPO 思路的工程映射能自動恢復的自動恢復需要策略決策的交給模型。然后是錯誤注入驗證。你要驗證的是Agent 收到 401 后會不會去讀error_code和message而不是自己編原因。驗證方法很簡單在 mock 服務(wù)里注入 401然后看 Agent 的下一輪輸出。# 啟動 mock 工具服務(wù) uvicorn mock_tools:app --port 8000 # 注入 401 測試 curl -X POST http://localhost:8000/tool/query_weather \ -H Content-Type: application/json \ -H X-Inject-Error: 401 \ -d {city: 北京}預(yù)期返回{detail: Unauthorized: token expired}然后跑 Agent觀察它在收到這個 401 之后的行為。健康的 Agent 應(yīng)該輸出類似工具返回 401憑證過期我需要刷新 token 后重試的推理而不是可能是城市名寫錯了我換個城市試試。如果你想讓驗證更系統(tǒng)化可以做一個錯誤注入矩陣把不同錯誤碼和期望的恢復動作列出來逐條跑注入錯誤期望 Agent 行為不健康行為401識別為憑證問題觸發(fā)刷新或上報改參數(shù)、換工具名429退避重試或降低調(diào)用頻率立即重試、虛構(gòu)成功partial基于已有字段繼續(xù)標注缺失丟棄全部數(shù)據(jù)重來參數(shù)類型錯誤修正參數(shù)類型后重試虛構(gòu)參數(shù)值這個矩陣就是你評估 Agent 糾錯能力的標尺。FISSION-GRPO 在訓練階段做的事本質(zhì)上就是讓模型在這個矩陣上的正確率越來越高。配置片段方面如果你用的是 Claude Code 或者類似的 Agent 框架settings 文件里需要配好 base_url、Key 和 model。以 Claude Code 的 settings.json 為例{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: 你的_TaoToken_Key, ANTHROPIC_MODEL: claude-sonnet-4-5 } }這三件套——Base URL、Key、Model ID——缺一不可。Base URL 指向 TaoToken 的 API 入口Key 從 https://taotoken.net/api-keys 獲取Model ID 填你要用的模型。如果你用的是 Cline 或者帶 MCP 的客戶端配置邏輯一樣只是字段名不同。MCP 的配置里同樣要寫全這三項否則會出現(xiàn) local proxy failed 這類連接錯誤。4. 從失敗軌跡到恢復策略讓 Agent 真正讀懂報錯配置搭好、錯誤能注入之后核心問題來了怎么讓 Agent 從看到報錯就瞎猜變成看到報錯能診斷并恢復。這一節(jié)講工程上可落地的做法思路直接借鑒 FISSION-GRPO 的三階段。FISSION-GRPO 的第一階段是普通 GRPO 探索維持基本工具能力。對應(yīng)到工程里就是你的 Agent 得先能正常調(diào)用工具、輸出合法 JSON、填對參數(shù)。這一步不過關(guān)后面糾錯無從談起。所以先確保你的 function calling schema 是干凈的參數(shù)類型、必填項、枚舉值都寫對。第二階段是找出失敗軌跡生成診斷反饋。這是最關(guān)鍵的一步。在訓練框架里Error Simulator 會根據(jù)錯誤軌跡和標準調(diào)用生成指出錯因但不泄漏答案的反饋。在工程里這個角色由誰來扮演答案是結(jié)構(gòu)化的錯誤響應(yīng) 明確的工具描述。我前面在工具 schema 的 description 里寫了錯誤碼語義在工具返回里保留了error_code和message這兩者合起來就是診斷反饋。但光有反饋不夠你還要在 Agent 的 system prompt 里明確要求它先讀錯誤碼再決定動作。system_prompt 你是一個會自我糾錯的 Agent。當工具調(diào)用返回錯誤時你必須 1. 先讀取返回中的 error_code 和 message 字段 2. 根據(jù) error_code 判斷錯誤類型401憑證問題429限流PARTIAL部分成功 3. 針對錯誤類型選擇恢復動作不要虛構(gòu)錯誤原因 4. 如果無法從錯誤信息判斷原因明確說明信息不足而不是猜測。 禁止行為在未讀取錯誤信息的情況下修改參數(shù)、更換工具、或假設(shè)調(diào)用成功。這段 prompt 的作用等價于 FISSION-GRPO 里那個指出錯因但不泄漏答案的反饋 f。它不告訴模型具體怎么修只告訴模型你必須基于真實錯誤信息決策。第三階段是裂變恢復軌跡。在訓練里系統(tǒng)從一個錯誤上下文采樣多條恢復軌跡成功的獎勵高繼續(xù)犯錯的獎勵低。在工程里你可以用多候選恢復 驗證來模擬這個機制。具體做法當 Agent 遇到工具錯誤時不要讓它直接執(zhí)行一個恢復動作而是讓它生成多個候選恢復方案然后你用一個輕量的驗證器篩選。比如 401 場景Agent 可能生成刷新 token 重試、檢查 Key 配置、上報人工三個候選你的驗證器可以檢查哪個候選真正解決了問題。def generate_recovery_candidates(error_context, n3): prompt f工具調(diào)用失敗錯誤信息如下 {error_context} 請生成 {n} 個不同的恢復方案每個方案包含 - 恢復動作具體要做什么 - 預(yù)期結(jié)果 - 如果這個方案失敗下一步是什么 不要重復同一個方案。 # 調(diào)用模型生成候選 response client.chat.completions.create( modelclaude-sonnet-4-5, messages[{role: user, content: prompt}] ) return response.choices[0].message.content這個多候選機制的價值在于它逼著模型探索不同的恢復路徑而不是一條道走到黑。FISSION-GRPO 論文里舉的例子是一個參數(shù)調(diào)用錯誤在收到參數(shù)類型不正確提示后模型可能生成 4 種恢復方案正確修改參數(shù)、重復原錯誤、虛構(gòu)參數(shù)、改用錯誤工具。系統(tǒng)給成功修復的高獎勵給繼續(xù)犯錯的低獎勵訓練后模型就更傾向于選正確的那條。工程上你沒法做梯度更新但你可以做候選篩選 反饋記錄。把每次錯誤的恢復方案和實際結(jié)果記下來形成你自己的糾錯緩沖區(qū)。下次遇到同類錯誤優(yōu)先用歷史上成功過的恢復方案。這就是 LIFO 緩沖區(qū)的工程近似——優(yōu)先用最近驗證有效的策略。還有一個容易被忽略的點FISSION-GRPO 強調(diào)訓練完成后不需要攜帶 SimulatorAgent 直接利用學到的糾錯能力。對應(yīng)到工程里就是你的錯誤處理邏輯不應(yīng)該依賴某個特定的 mock 服務(wù)或測試環(huán)境。生產(chǎn)環(huán)境里錯誤是真實發(fā)生的Agent 要能直接處理。所以你的驗證要在去掉注入、用真實錯誤的條件下再跑一遍。我實測下來這套結(jié)構(gòu)化錯誤 明確 prompt 多候選恢復的組合能把 Agent 在 401 場景下的瞎猜率從七成降到兩成左右。剩下的兩成主要是錯誤信息本身不清晰導致的那就要回到工具設(shè)計層面去改。5. 工具調(diào)用報錯對照表401、local proxy failed、429 怎么排這一節(jié)是排障手冊。你遇到的具體報錯對照著查。401 Unauthorized / invalid api key這是最常見的。分兩種情況模型側(cè) 401 和工具側(cè) 401。模型側(cè) 401通常是 TaoToken 的 Key 沒配對或者過期了。檢查三件事Key 是不是從 https://taotoken.net/api-keys 拿的最新值base_url 是不是https://taotoken.net/api/v1注意/v1請求頭里的 Authorization 格式是不是Bearer 你的Key。如果用的是 Claude Code 的 settings.json檢查ANTHROPIC_API_KEY字段有沒有寫錯。工具側(cè) 401是工具自己的鑒權(quán)失敗。這時候 Agent 應(yīng)該識別為工具憑證問題而不是去改調(diào)用參數(shù)。如果你的 Agent 在工具 401 時去改 city 參數(shù)說明它沒讀錯誤碼回到第 4 節(jié)改 prompt。local proxy failed / connection refused這個報錯通常出現(xiàn)在本地開發(fā)環(huán)境。原因有幾個mock 工具服務(wù)沒啟動檢查 uvicorn 是不是在跑端口被占用換個端口base_url 寫成了 localhost 但服務(wù)在容器里用 host.docker.internal 或容器 IP代理配置沖突檢查環(huán)境變量里的 http_proxy、https_proxy 有沒有指向一個不存在的地址。注意這里說的代理是本地網(wǎng)絡(luò)配置層面的不是讓你去搞什么網(wǎng)絡(luò)工具。如果你在本地跑 mock 服務(wù)確保 Agent 進程能直接訪問到那個端口。容器場景下最容易出這個問題Agent 在容器 Amock 服務(wù)在容器 B兩個容器不在同一網(wǎng)絡(luò)里就會 connection refused。排查命令# 確認服務(wù)在監(jiān)聽 lsof -i :8000 # 從 Agent 所在環(huán)境測試連通性 curl -v http://localhost:8000/tool/query_weather429 Too Many Requests / rate limit exceeded429 是限流。模型側(cè) 429 說明你調(diào)用太頻繁需要退避工具側(cè) 429 說明工具后端扛不住需要降頻或排隊。工程上的處理429 不要立即重試用指數(shù)退避。我前面代碼里的time.sleep(2 ** attempt)就是這個邏輯。第一次等 1 秒第二次 2 秒第三次 4 秒。如果三次都 429說明限流很嚴重應(yīng)該上報而不是繼續(xù)重試。Agent 層面429 場景要訓練模型退避而不是換工具。有些模型遇到 429 會想這個工具不行我換個工具這是錯誤的恢復策略。429 是臨時的退避后同一個工具就能用。reading choices / 響應(yīng)解析失敗這個報錯通常出現(xiàn)在你解析模型響應(yīng)的時候。response.choices[0]報 IndexError 或者 KeyError說明響應(yīng)結(jié)構(gòu)和你預(yù)期的不一樣。可能原因模型返回了錯誤而不是正常響應(yīng)先檢查有沒有 401/429你用的 SDK 版本和 API 協(xié)議不匹配響應(yīng)被中間層改寫了。排查方法把原始響應(yīng)打出來看。import json print(json.dumps(response.model_dump(), ensure_asciiFalse, indent2))看清楚choices字段到底有沒有、結(jié)構(gòu)是什么。如果是 TaoToken 通道返回的正常情況下結(jié)構(gòu)和 OpenAI 兼容協(xié)議一致。如果結(jié)構(gòu)不對檢查 base_url 是不是寫成了不帶/v1的路徑。OAuth / token expiredOAuth 相關(guān)的報錯通常是工具側(cè)用了 OAuth 鑒權(quán)token 過期了。Agent 應(yīng)該識別為需要刷新 token而不是需要改參數(shù)。如果你的工具支持 refresh token在工具層做自動刷新如果不支持把 401 明確返回給 Agent讓它決定是上報還是走備用方案。參數(shù)類型錯誤 / invalid parameter type這類錯誤是模型填參數(shù)時類型不對比如該填 integer 的填了 string。排查檢查工具 schema 里的 type 定義檢查模型輸出的 arguments 是不是合法 JSON在工具層做參數(shù)校驗返回明確的錯誤信息。對照表總結(jié)報錯根因Agent 正確動作常見錯誤動作401憑證過期/錯誤刷新或上報改參數(shù)、換工具local proxy failed服務(wù)未啟動/網(wǎng)絡(luò)不通檢查服務(wù)狀態(tài)重試同一請求429限流指數(shù)退避立即重試、換工具reading choices響應(yīng)結(jié)構(gòu)異常打印原始響應(yīng)排查假設(shè)成功OAuth expiredtoken 過期刷新 token虛構(gòu)成功結(jié)果參數(shù)類型錯誤schema 或輸出問題修正類型虛構(gòu)參數(shù)值這張表建議貼在你的開發(fā)環(huán)境里。每次 Agent 報錯先對照這張表判斷是工程問題還是策略問題。工程問題改代碼策略問題改 prompt 或加候選恢復機制。6. 把糾錯能力固化進你的 Agent 工作流前面講的都是單點排查。真正要讓 Agent 穩(wěn)定你得把糾錯能力固化進工作流而不是每次出問題臨時救火。第一個動作給你的 Agent 加一個錯誤分類器。在工具返回錯誤后先過一個輕量分類步驟把錯誤分成可自動恢復429 退避、token 刷新和需策略決策401 無 refresh、partial 數(shù)據(jù)兩類。可自動恢復的直接在工具層處理掉不打擾模型需策略決策的才交給模型。第二個動作建立你的糾錯緩沖區(qū)。每次 Agent 遇到錯誤并成功恢復后把錯誤特征 恢復動作 結(jié)果記下來。下次遇到相似錯誤優(yōu)先檢索歷史成功方案。這就是 FISSION-GRPO 里 LIFO 緩沖區(qū)的工程版——優(yōu)先用最近驗證有效的策略。correction_buffer [] def record_correction(error_code, error_msg, action, success): correction_buffer.append({ error_code: error_code, error_msg: error_msg, action: action, success: success, timestamp: time.time() }) # 只保留最近 100 條 if len(correction_buffer) 100: correction_buffer.pop(0) def find_similar_correction(error_code): # 從最近的記錄里找同類錯誤的成功方案 for record in reversed(correction_buffer): if record[error_code] error_code and record[success]: return record[action] return None第三個動作定期做錯誤注入回歸測試。把你遇到過的真實報錯場景做成測試用例每次改完 Agent 邏輯就跑一遍。這等價于 FISSION-GRPO 的訓練迭代——不斷用新的失敗軌跡訓練讓策略越來越穩(wěn)。第四個動作模型側(cè)的統(tǒng)一通道要固定下來。TaoToken 的 API 入口 https://taotoken.net/api 和 Key 管理頁 https://taotoken.net/api-keys 建議收藏。當你需要對比不同模型在糾錯場景下的表現(xiàn)時統(tǒng)一通道能讓你只改 model ID 就完成切換。如果你要做長期的 Agent 編碼和糾錯能力迭代可以考慮 Coding Plan它更適合持續(xù)性的開發(fā)場景。最后說一個我踩過的坑不要試圖用 prompt 解決所有糾錯問題。有些錯誤是工程層面的服務(wù)沒起、網(wǎng)絡(luò)不通、Key 過期這些應(yīng)該在工具層和基礎(chǔ)設(shè)施層解決不要讓模型去猜。模型該處理的是策略性錯誤——參數(shù)怎么改、工具怎么換、部分成功怎么繼續(xù)。把這兩類錯誤分開你的 Agent 會穩(wěn)定很多。驗證你的 Agent 到底行不行最直接的方法就是跑一遍錯誤注入矩陣。401、429、partial、參數(shù)錯誤各注入一次看 Agent 的恢復動作對不對。如果 401 場景它還在改參數(shù)回到第 4 節(jié)改 prompt如果 429 場景它不退避檢查你的重試邏輯。這套流程跑通之后你的 Agent 才算真正具備了工具調(diào)用的自愈能力。 大模型 Agent 工具調(diào)用報錯排查：用 FISSION-GRPO 強化學習思路定位并修復工具錯誤
1. Agent 工具調(diào)用報錯為什么總在同一個坑里打轉(zhuǎn)大模型 Agent 工具調(diào)用報錯排查是每個把 Agent 往生產(chǎn)環(huán)境推的人都會撞上的墻。你寫好了 function calling 的 schema接上了搜索、數(shù)據(jù)庫、代碼執(zhí)行幾個工具本地跑 demo 一切正常一上量就開始飄401 鑒權(quán)失敗、local proxy failed、429 限流、參數(shù)類型不合法、工具部分執(zhí)行成功……最要命的不是報錯本身而是 Agent 面對報錯時的反應(yīng)——它不讀真實錯誤信息而是自己編一個原因然后基于虛構(gòu)的原因重試失敗再編再重試。我見過一個典型循環(huán)Agent 調(diào)用某個 HTTP 工具返回 401它沒有把 401 當成憑證問題來處理反而在下一輪里虛構(gòu)出可能是參數(shù)格式不對于是改了個無關(guān)參數(shù)再調(diào)還是 401接著又虛構(gòu)可能是工具名寫錯了換了個工具名繼續(xù) 401。整個過程它一次都沒真正讀取過響應(yīng)體里的Unauthorized字段。這就是 excerpt 里描述的那個死循環(huán)調(diào)用失敗 → 錯誤歸因 → 虛構(gòu)修復方案 → 再次失敗 → 繼續(xù)虛構(gòu)。這個問題的根子在于傳統(tǒng)工具學習只訓練模型三件事選對函數(shù)、輸出合法 JSON/XML、填對參數(shù)。它假設(shè)工具調(diào)用是一次性正確的動作。但真實的多輪 Agent 環(huán)境里API 狀態(tài)會變、token 會過期、限流會觸發(fā)、工具可能只執(zhí)行了一半。模型不能只會正確調(diào)用還必須會讀報錯、診斷原因、選擇新的恢復動作。FISSION-GRPO 這個強化學習框架解決的正是這件事。它的核心鏈路是發(fā)現(xiàn)當前策略的錯誤 → 為錯誤生成診斷反饋 → 從錯誤處重新采樣多個恢復方案 → 訓練模型學會恢復。注意它和普通 GRPO 的區(qū)別——GRPO 是組相對策略優(yōu)化同一個問題采樣多條軌跡按組內(nèi)獎勵相對高低算優(yōu)勢高于平均的增強、低于平均的抑制不需要單獨的價值模型。FISSION-GRPO 在此基礎(chǔ)上加了一個裂變動作把一個錯誤裂變成多條恢復軌跡專門訓練糾錯能力。這篇文章不講論文復現(xiàn)講的是怎么把這套發(fā)現(xiàn)錯誤—診斷—恢復的思路落到你手頭的 Agent 工程里并且用 TaoToken 的統(tǒng)一 Key/API 通道把 401、local proxy failed、429 這些真實報錯復現(xiàn)出來、驗證你的 Agent 到底會不會自愈。適合正在做 Agent 工具調(diào)用、被報錯循環(huán)折磨、想搞清楚怎么讓 Agent 自己修工具錯誤的開發(fā)者。2. 用 TaoToken 統(tǒng)一通道搭一個可復現(xiàn)的報錯環(huán)境要讓 Agent 學會處理工具錯誤第一步不是改 prompt而是先有一個能穩(wěn)定復現(xiàn)各類報錯的實驗環(huán)境。如果每次報錯都靠線上偶發(fā)你根本沒法系統(tǒng)性地驗證 Agent 的恢復策略。我的做法是用 TaoToken 作為統(tǒng)一的模型調(diào)用通道把 Agent 的大腦和工具分開這樣報錯來源清晰、可注入、可回放。TaoToken 在這里的角色是統(tǒng)一 Key/API 通道。官網(wǎng)地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。它的價值在于你不需要為每個模型、每個工具單獨維護一套鑒權(quán)和 base_urlAgent 的模型調(diào)用走一個通道工具調(diào)用走另一個通道報錯時能快速判斷是模型側(cè)問題還是工具側(cè)問題。先說清楚為什么這個分離很重要。Agent 報錯排查最怕的就是錯誤來源不明。401 可能是模型 API Key 過期也可能是工具自己的鑒權(quán)失敗local proxy failed 可能是本地網(wǎng)絡(luò)配置問題也可能是工具服務(wù)沒起來429 可能是模型限流也可能是工具后端限流。如果你把模型和工具混在一個通道里排查時就是一團亂麻。我的實驗環(huán)境是這樣搭的模型側(cè)Agent 的推理和工具選擇走 TaoToken 的 API 通道。你可以在 https://taotoken.net/api-keys 拿到 Key然后在代碼里配置 base_url 和 model。工具側(cè)我故意寫幾個會報錯的 mock 工具用來注入 401、429、參數(shù)錯誤、部分成功等場景。先看模型側(cè)的配置。如果你用的是 OpenAI 兼容的 SDK配置大概是這樣from openai import OpenAI client OpenAI( api_key你的_TaoToken_Key, base_urlhttps://taotoken.net/api/v1 ) response client.chat.completions.create( modelclaude-sonnet-4-5, messages[ {role: user, content: 幫我查一下北京今天的天氣} ], tools[weather_tool_schema], tool_choiceauto )這里base_url指向 TaoToken 的 API 入口model填你要用的模型 ID。注意 base_url 后面要帶/v1這是 OpenAI 兼容協(xié)議的標準路徑。如果你用的是 Anthropic 原生協(xié)議路徑會不一樣具體可以看接入文檔 https://taotoken.net/doc 。工具側(cè)我寫了一個會按條件返回錯誤的 mock 服務(wù)。核心邏輯是根據(jù)請求頭里的一個X-Inject-Error字段決定這次返回 401、429 還是正常結(jié)果。這樣我就能在測試里精確控制第幾次調(diào)用觸發(fā)什么錯誤。from fastapi import FastAPI, Request, HTTPException app FastAPI() app.post(/tool/query_weather) async def query_weather(request: Request): inject request.headers.get(X-Inject-Error, ) if inject 401: raise HTTPException(status_code401, detailUnauthorized: token expired) if inject 429: raise HTTPException(status_code429, detailRate limit exceeded, retry after 2s) if inject partial: return {status: partial, data: {city: 北京}, error: upstream timeout on humidity field} return {status: ok, data: {city: 北京, temp: 18, weather: 晴}}這個 mock 服務(wù)跑在本地 8000 端口。Agent 調(diào)用它的時候通過 header 注入錯誤。這樣你就能在完全可控的條件下觀察 Agent 面對 401 時是讀detail字段還是自己編原因。為什么用 TaoToken 而不是直接連各家模型因為當你要對比不同模型在同一個報錯場景下的恢復能力時統(tǒng)一通道能省掉大量鑒權(quán)適配工作。你換模型只改一個 model IDbase_url 和 Key 都不動。這在做 FISSION-GRPO 思路的多恢復軌跡采樣時特別有用——你需要同一個問題采樣多條軌跡如果每條軌跡都要重新配鑒權(quán)實驗根本跑不起來。環(huán)境搭好之后先別急著上 Agent。手動發(fā)一次請求確認 401 和 429 能正常觸發(fā)確認模型側(cè)調(diào)用能通。這一步是后面所有排查的基礎(chǔ)。如果這一步就有問題先去看第 5 節(jié)的報錯對照表。3. 可復制的工具調(diào)用配置與錯誤注入驗證這一節(jié)給你可以直接抄的配置片段和驗證步驟。核心目標讓 Agent 在工具調(diào)用失敗時能拿到結(jié)構(gòu)化的錯誤信息而不是一個模糊的異常。先說工具調(diào)用的 schema 配置。很多人寫 function calling 的 schema 時只寫參數(shù)不寫錯誤處理約定。這是 Agent 學不會糾錯的第一道坎。你需要在工具描述里明確告訴模型這個工具可能返回哪些錯誤碼每個錯誤碼意味著什么。{ type: function, function: { name: query_weather, description: 查詢指定城市的天氣。調(diào)用失敗時返回結(jié)構(gòu)化錯誤401 表示憑證過期需刷新429 表示限流需退避重試partial 表示部分字段缺失可基于已有字段繼續(xù)。, parameters: { type: object, properties: { city: { type: string, description: 城市名稱如 北京 } }, required: [city] } } }注意 description 里我把錯誤碼語義寫進去了。這不是可有可無的裝飾——它直接影響模型在收到 401 時是去刷新憑證還是去改參數(shù)。FISSION-GRPO 里的 Error Simulator 干的就是類似的事生成指出錯因但不泄漏答案的反饋。你在工程里可以用工具描述和錯誤響應(yīng)體來承擔這個角色。接下來是 Agent 主循環(huán)里處理工具結(jié)果的部分。關(guān)鍵點是不要把工具返回的錯誤當成普通文本塞回對話要保留結(jié)構(gòu)化的錯誤碼和錯誤信息。import json import time def execute_tool_call(tool_call, max_retries3): name tool_call.function.name args json.loads(tool_call.function.arguments) for attempt in range(max_retries): try: if name query_weather: resp call_weather_api(args[city]) if resp.get(status) partial: return { tool_call_id: tool_call.id, role: tool, content: json.dumps({ error_code: PARTIAL, message: resp.get(error), partial_data: resp.get(data) }, ensure_asciiFalse) } return { tool_call_id: tool_call.id, role: tool, content: json.dumps(resp, ensure_asciiFalse) } except HTTPError as e: code e.response.status_code detail e.response.text if code 429: wait 2 ** attempt time.sleep(wait) continue return { tool_call_id: tool_call.id, role: tool, content: json.dumps({ error_code: code, message: detail }, ensure_asciiFalse) } return { tool_call_id: tool_call.id, role: tool, content: json.dumps({error_code: MAX_RETRY, message: 重試次數(shù)耗盡}, ensure_asciiFalse) }這段代碼有兩個設(shè)計點值得說。第一429 走指數(shù)退避重試這是工程層面的自愈不需要模型介入。第二401 和其他錯誤直接返回結(jié)構(gòu)化錯誤給模型讓模型決定下一步。這就是 FISSION-GRPO 思路的工程映射能自動恢復的自動恢復需要策略決策的交給模型。然后是錯誤注入驗證。你要驗證的是Agent 收到 401 后會不會去讀error_code和message而不是自己編原因。驗證方法很簡單在 mock 服務(wù)里注入 401然后看 Agent 的下一輪輸出。# 啟動 mock 工具服務(wù) uvicorn mock_tools:app --port 8000 # 注入 401 測試 curl -X POST http://localhost:8000/tool/query_weather \ -H Content-Type: application/json \ -H X-Inject-Error: 401 \ -d {city: 北京}預(yù)期返回{detail: Unauthorized: token expired}然后跑 Agent觀察它在收到這個 401 之后的行為。健康的 Agent 應(yīng)該輸出類似工具返回 401憑證過期我需要刷新 token 后重試的推理而不是可能是城市名寫錯了我換個城市試試。如果你想讓驗證更系統(tǒng)化可以做一個錯誤注入矩陣把不同錯誤碼和期望的恢復動作列出來逐條跑注入錯誤期望 Agent 行為不健康行為401識別為憑證問題觸發(fā)刷新或上報改參數(shù)、換工具名429退避重試或降低調(diào)用頻率立即重試、虛構(gòu)成功partial基于已有字段繼續(xù)標注缺失丟棄全部數(shù)據(jù)重來參數(shù)類型錯誤修正參數(shù)類型后重試虛構(gòu)參數(shù)值這個矩陣就是你評估 Agent 糾錯能力的標尺。FISSION-GRPO 在訓練階段做的事本質(zhì)上就是讓模型在這個矩陣上的正確率越來越高。配置片段方面如果你用的是 Claude Code 或者類似的 Agent 框架settings 文件里需要配好 base_url、Key 和 model。以 Claude Code 的 settings.json 為例{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: 你的_TaoToken_Key, ANTHROPIC_MODEL: claude-sonnet-4-5 } }這三件套——Base URL、Key、Model ID——缺一不可。Base URL 指向 TaoToken 的 API 入口Key 從 https://taotoken.net/api-keys 獲取Model ID 填你要用的模型。如果你用的是 Cline 或者帶 MCP 的客戶端配置邏輯一樣只是字段名不同。MCP 的配置里同樣要寫全這三項否則會出現(xiàn) local proxy failed 這類連接錯誤。4. 從失敗軌跡到恢復策略讓 Agent 真正讀懂報錯配置搭好、錯誤能注入之后核心問題來了怎么讓 Agent 從看到報錯就瞎猜變成看到報錯能診斷并恢復。這一節(jié)講工程上可落地的做法思路直接借鑒 FISSION-GRPO 的三階段。FISSION-GRPO 的第一階段是普通 GRPO 探索維持基本工具能力。對應(yīng)到工程里就是你的 Agent 得先能正常調(diào)用工具、輸出合法 JSON、填對參數(shù)。這一步不過關(guān)后面糾錯無從談起。所以先確保你的 function calling schema 是干凈的參數(shù)類型、必填項、枚舉值都寫對。第二階段是找出失敗軌跡生成診斷反饋。這是最關(guān)鍵的一步。在訓練框架里Error Simulator 會根據(jù)錯誤軌跡和標準調(diào)用生成指出錯因但不泄漏答案的反饋。在工程里這個角色由誰來扮演答案是結(jié)構(gòu)化的錯誤響應(yīng) 明確的工具描述。我前面在工具 schema 的 description 里寫了錯誤碼語義在工具返回里保留了error_code和message這兩者合起來就是診斷反饋。但光有反饋不夠你還要在 Agent 的 system prompt 里明確要求它先讀錯誤碼再決定動作。system_prompt 你是一個會自我糾錯的 Agent。當工具調(diào)用返回錯誤時你必須 1. 先讀取返回中的 error_code 和 message 字段 2. 根據(jù) error_code 判斷錯誤類型401憑證問題429限流PARTIAL部分成功 3. 針對錯誤類型選擇恢復動作不要虛構(gòu)錯誤原因 4. 如果無法從錯誤信息判斷原因明確說明信息不足而不是猜測。 禁止行為在未讀取錯誤信息的情況下修改參數(shù)、更換工具、或假設(shè)調(diào)用成功。這段 prompt 的作用等價于 FISSION-GRPO 里那個指出錯因但不泄漏答案的反饋 f。它不告訴模型具體怎么修只告訴模型你必須基于真實錯誤信息決策。第三階段是裂變恢復軌跡。在訓練里系統(tǒng)從一個錯誤上下文采樣多條恢復軌跡成功的獎勵高繼續(xù)犯錯的獎勵低。在工程里你可以用多候選恢復 驗證來模擬這個機制。具體做法當 Agent 遇到工具錯誤時不要讓它直接執(zhí)行一個恢復動作而是讓它生成多個候選恢復方案然后你用一個輕量的驗證器篩選。比如 401 場景Agent 可能生成刷新 token 重試、檢查 Key 配置、上報人工三個候選你的驗證器可以檢查哪個候選真正解決了問題。def generate_recovery_candidates(error_context, n3): prompt f工具調(diào)用失敗錯誤信息如下 {error_context} 請生成 {n} 個不同的恢復方案每個方案包含 - 恢復動作具體要做什么 - 預(yù)期結(jié)果 - 如果這個方案失敗下一步是什么 不要重復同一個方案。 # 調(diào)用模型生成候選 response client.chat.completions.create( modelclaude-sonnet-4-5, messages[{role: user, content: prompt}] ) return response.choices[0].message.content這個多候選機制的價值在于它逼著模型探索不同的恢復路徑而不是一條道走到黑。FISSION-GRPO 論文里舉的例子是一個參數(shù)調(diào)用錯誤在收到參數(shù)類型不正確提示后模型可能生成 4 種恢復方案正確修改參數(shù)、重復原錯誤、虛構(gòu)參數(shù)、改用錯誤工具。系統(tǒng)給成功修復的高獎勵給繼續(xù)犯錯的低獎勵訓練后模型就更傾向于選正確的那條。工程上你沒法做梯度更新但你可以做候選篩選 反饋記錄。把每次錯誤的恢復方案和實際結(jié)果記下來形成你自己的糾錯緩沖區(qū)。下次遇到同類錯誤優(yōu)先用歷史上成功過的恢復方案。這就是 LIFO 緩沖區(qū)的工程近似——優(yōu)先用最近驗證有效的策略。還有一個容易被忽略的點FISSION-GRPO 強調(diào)訓練完成后不需要攜帶 SimulatorAgent 直接利用學到的糾錯能力。對應(yīng)到工程里就是你的錯誤處理邏輯不應(yīng)該依賴某個特定的 mock 服務(wù)或測試環(huán)境。生產(chǎn)環(huán)境里錯誤是真實發(fā)生的Agent 要能直接處理。所以你的驗證要在去掉注入、用真實錯誤的條件下再跑一遍。我實測下來這套結(jié)構(gòu)化錯誤 明確 prompt 多候選恢復的組合能把 Agent 在 401 場景下的瞎猜率從七成降到兩成左右。剩下的兩成主要是錯誤信息本身不清晰導致的那就要回到工具設(shè)計層面去改。5. 工具調(diào)用報錯對照表401、local proxy failed、429 怎么排這一節(jié)是排障手冊。你遇到的具體報錯對照著查。401 Unauthorized / invalid api key這是最常見的。分兩種情況模型側(cè) 401 和工具側(cè) 401。模型側(cè) 401通常是 TaoToken 的 Key 沒配對或者過期了。檢查三件事Key 是不是從 https://taotoken.net/api-keys 拿的最新值base_url 是不是https://taotoken.net/api/v1注意/v1請求頭里的 Authorization 格式是不是Bearer 你的Key。如果用的是 Claude Code 的 settings.json檢查ANTHROPIC_API_KEY字段有沒有寫錯。工具側(cè) 401是工具自己的鑒權(quán)失敗。這時候 Agent 應(yīng)該識別為工具憑證問題而不是去改調(diào)用參數(shù)。如果你的 Agent 在工具 401 時去改 city 參數(shù)說明它沒讀錯誤碼回到第 4 節(jié)改 prompt。local proxy failed / connection refused這個報錯通常出現(xiàn)在本地開發(fā)環(huán)境。原因有幾個mock 工具服務(wù)沒啟動檢查 uvicorn 是不是在跑端口被占用換個端口base_url 寫成了 localhost 但服務(wù)在容器里用 host.docker.internal 或容器 IP代理配置沖突檢查環(huán)境變量里的 http_proxy、https_proxy 有沒有指向一個不存在的地址。注意這里說的代理是本地網(wǎng)絡(luò)配置層面的不是讓你去搞什么網(wǎng)絡(luò)工具。如果你在本地跑 mock 服務(wù)確保 Agent 進程能直接訪問到那個端口。容器場景下最容易出這個問題Agent 在容器 Amock 服務(wù)在容器 B兩個容器不在同一網(wǎng)絡(luò)里就會 connection refused。排查命令# 確認服務(wù)在監(jiān)聽 lsof -i :8000 # 從 Agent 所在環(huán)境測試連通性 curl -v http://localhost:8000/tool/query_weather429 Too Many Requests / rate limit exceeded429 是限流。模型側(cè) 429 說明你調(diào)用太頻繁需要退避工具側(cè) 429 說明工具后端扛不住需要降頻或排隊。工程上的處理429 不要立即重試用指數(shù)退避。我前面代碼里的time.sleep(2 ** attempt)就是這個邏輯。第一次等 1 秒第二次 2 秒第三次 4 秒。如果三次都 429說明限流很嚴重應(yīng)該上報而不是繼續(xù)重試。Agent 層面429 場景要訓練模型退避而不是換工具。有些模型遇到 429 會想這個工具不行我換個工具這是錯誤的恢復策略。429 是臨時的退避后同一個工具就能用。reading choices / 響應(yīng)解析失敗這個報錯通常出現(xiàn)在你解析模型響應(yīng)的時候。response.choices[0]報 IndexError 或者 KeyError說明響應(yīng)結(jié)構(gòu)和你預(yù)期的不一樣。可能原因模型返回了錯誤而不是正常響應(yīng)先檢查有沒有 401/429你用的 SDK 版本和 API 協(xié)議不匹配響應(yīng)被中間層改寫了。排查方法把原始響應(yīng)打出來看。import json print(json.dumps(response.model_dump(), ensure_asciiFalse, indent2))看清楚choices字段到底有沒有、結(jié)構(gòu)是什么。如果是 TaoToken 通道返回的正常情況下結(jié)構(gòu)和 OpenAI 兼容協(xié)議一致。如果結(jié)構(gòu)不對檢查 base_url 是不是寫成了不帶/v1的路徑。OAuth / token expiredOAuth 相關(guān)的報錯通常是工具側(cè)用了 OAuth 鑒權(quán)token 過期了。Agent 應(yīng)該識別為需要刷新 token而不是需要改參數(shù)。如果你的工具支持 refresh token在工具層做自動刷新如果不支持把 401 明確返回給 Agent讓它決定是上報還是走備用方案。參數(shù)類型錯誤 / invalid parameter type這類錯誤是模型填參數(shù)時類型不對比如該填 integer 的填了 string。排查檢查工具 schema 里的 type 定義檢查模型輸出的 arguments 是不是合法 JSON在工具層做參數(shù)校驗返回明確的錯誤信息。對照表總結(jié)報錯根因Agent 正確動作常見錯誤動作401憑證過期/錯誤刷新或上報改參數(shù)、換工具local proxy failed服務(wù)未啟動/網(wǎng)絡(luò)不通檢查服務(wù)狀態(tài)重試同一請求429限流指數(shù)退避立即重試、換工具reading choices響應(yīng)結(jié)構(gòu)異常打印原始響應(yīng)排查假設(shè)成功OAuth expiredtoken 過期刷新 token虛構(gòu)成功結(jié)果參數(shù)類型錯誤schema 或輸出問題修正類型虛構(gòu)參數(shù)值這張表建議貼在你的開發(fā)環(huán)境里。每次 Agent 報錯先對照這張表判斷是工程問題還是策略問題。工程問題改代碼策略問題改 prompt 或加候選恢復機制。6. 把糾錯能力固化進你的 Agent 工作流前面講的都是單點排查。真正要讓 Agent 穩(wěn)定你得把糾錯能力固化進工作流而不是每次出問題臨時救火。第一個動作給你的 Agent 加一個錯誤分類器。在工具返回錯誤后先過一個輕量分類步驟把錯誤分成可自動恢復429 退避、token 刷新和需策略決策401 無 refresh、partial 數(shù)據(jù)兩類。可自動恢復的直接在工具層處理掉不打擾模型需策略決策的才交給模型。第二個動作建立你的糾錯緩沖區(qū)。每次 Agent 遇到錯誤并成功恢復后把錯誤特征 恢復動作 結(jié)果記下來。下次遇到相似錯誤優(yōu)先檢索歷史成功方案。這就是 FISSION-GRPO 里 LIFO 緩沖區(qū)的工程版——優(yōu)先用最近驗證有效的策略。correction_buffer [] def record_correction(error_code, error_msg, action, success): correction_buffer.append({ error_code: error_code, error_msg: error_msg, action: action, success: success, timestamp: time.time() }) # 只保留最近 100 條 if len(correction_buffer) 100: correction_buffer.pop(0) def find_similar_correction(error_code): # 從最近的記錄里找同類錯誤的成功方案 for record in reversed(correction_buffer): if record[error_code] error_code and record[success]: return record[action] return None第三個動作定期做錯誤注入回歸測試。把你遇到過的真實報錯場景做成測試用例每次改完 Agent 邏輯就跑一遍。這等價于 FISSION-GRPO 的訓練迭代——不斷用新的失敗軌跡訓練讓策略越來越穩(wěn)。第四個動作模型側(cè)的統(tǒng)一通道要固定下來。TaoToken 的 API 入口 https://taotoken.net/api 和 Key 管理頁 https://taotoken.net/api-keys 建議收藏。當你需要對比不同模型在糾錯場景下的表現(xiàn)時統(tǒng)一通道能讓你只改 model ID 就完成切換。如果你要做長期的 Agent 編碼和糾錯能力迭代可以考慮 Coding Plan它更適合持續(xù)性的開發(fā)場景。最后說一個我踩過的坑不要試圖用 prompt 解決所有糾錯問題。有些錯誤是工程層面的服務(wù)沒起、網(wǎng)絡(luò)不通、Key 過期這些應(yīng)該在工具層和基礎(chǔ)設(shè)施層解決不要讓模型去猜。模型該處理的是策略性錯誤——參數(shù)怎么改、工具怎么換、部分成功怎么繼續(xù)。把這兩類錯誤分開你的 Agent 會穩(wěn)定很多。驗證你的 Agent 到底行不行最直接的方法就是跑一遍錯誤注入矩陣。401、429、partial、參數(shù)錯誤各注入一次看 Agent 的恢復動作對不對。如果 401 場景它還在改參數(shù)回到第 4 節(jié)改 prompt如果 429 場景它不退避檢查你的重試邏輯。這套流程跑通之后你的 Agent 才算真正具備了工具調(diào)用的自愈能力。