如果我的 Agent 系統已經上線一段時間，怎麼回頭檢查現有的重試邏輯是不是已經在悄悄燒錢，而不是等出事才發現？
最直接的方法是做一次「重試成本審計」，具體步驟如下。
先從日誌或計費記錄裡拉出過去 30 天所有觸發過重試的任務，計算每個任務的「重試次數」和「該任務的總成本」，畫出這兩者的散佈圖。正常情況下，大多數任務應該落在「重試 0-1 次、成本接近典型任務成本」的區域；如果你看到一群任務落在「重試次數偏高（例如 5 次以上）但每次重試成本也偏高」的區域，這群任務極可能是循環性失敗或結構性失敗被誤判成暫時性失敗、用了不適合的重試策略。
接著針對這群「高重試 + 高成本」的任務，抽樣檢查它們的實際執行日誌，看重試之間的請求內容和錯誤訊息是否高度相似（循環信號）、或者每次重試的錯誤原因是否相同（結構性失敗信號）。如果確認是這兩種情況，代表現有系統把不該重試的失敗當成了該重試的失敗，這是最直接需要修正的漏洞。
最後計算這群任務的總成本佔比——如果只佔全部任務成本的 1-2%，代表問題存在但影響有限，可以按優先順序排入開發排程；如果佔比超過 10%，代表這是一個已經在實質性侵蝕利潤的問題,應該立即修正,不用等到排程空出來。多數團隊第一次做這個審計時,都會對「循環性失敗佔的成本比例」感到意外——因為這類失敗在單一任務層面往往不起眼(可能只多花幾美分),但累積起來的規模常常被低估。
指數退避（exponential backoff）重試策略聽起來很標準，但在 Agent 場景裡有沒有需要特別調整的地方？
指數退避在傳統系統裡的設計目標是「給暫時性壅塞一點時間消散」，這個邏輯本身沒有問題，但直接套用到 Agent 場景時，有兩個地方需要調整。
第一，退避時間要考慮用戶體感延遲，不能只考慮系統負載。傳統系統的重試發生在後端，用戶通常感覺不到；但很多 Agent 場景是同步等待結果的（用戶送出指令後在等 Agent 回覆），如果退避時間設計成標準的 1 秒、2 秒、4 秒、8 秒（4 次重試總共等 15 秒），用戶會覺得系統反應遲鈍。對於同步等待場景，建議把重試上限壓低（例如只重試 2 次，總等待時間控制在 5 秒內），超過這個時間就直接回報「處理中，稍後查看結果」，把長時間等待轉為非同步通知，而不是讓用戶一直盯著轉圈圈。
第二，退避邏輯必須排除結構性失敗和循環性失敗，只對真正的暫時性失敗生效。這是最容易被忽略的一點——很多框架的預設實作是「任何錯誤都套用同一套指數退避重試」，沒有先判斷這個錯誤是不是暫時性的。正確做法是在重試邏輯前面加一層錯誤分類：先判斷這次失敗屬於暫時性、結構性還是循環性，只有判定為暫時性失敗才進入指數退避重試流程,結構性失敗直接走「改變請求策略」的路徑,循環性失敗直接中斷任務。
如果不做這層分類,指數退避重試會對所有類型的失敗一視同仁,對結構性失敗和循環性失敗白白浪費退避等待時間和重試次數,卻沒有解決真正的問題根源。
如果一個任務對用戶來說很重要（例如涉及金額較大的交易決策），是不是應該放寬重試上限和成本上限，確保它一定能成功？
直覺上「重要任務應該不計代價確保成功」聽起來合理，但這個想法混淆了「任務重要性」和「重試上限該設多寬」這兩件事，實務上容易造成反效果。
關鍵洞察是:任務越重要,越應該在早期失敗時就轉向人工介入,而不是讓 Agent 用更多次數、更高成本去「硬解」。理由是,如果一個高重要性任務,Agent 在合理的重試次數內(例如 3 次)都沒能成功完成,這通常代表這個任務本身超出了 Agent 目前的能力範圍,或者遇到了需要人類判斷的邊界情況——這時候繼續加碼重試,不會提升成功率,只會用更高的成本得到同樣「失敗」或「品質存疑」的結果。
更好的設計是:重要任務的重試上限不應該設得比一般任務更寬,而應該設定得更保守(例如 2 次而非 5 次),但降級路徑的觸發門檻要設計成「直接轉人工」而非「降級成簡化版本自動完成」。也就是說,重要任務的資源分配邏輯應該是「早點放棄自動化嘗試,把資源(和用戶的耐心)留給人工處理」,而不是「讓 Agent 不斷嘗試,直到用光所有預算」。
這個設計反而符合直覺想達成的目標:確保重要任務被妥善處理。只是「妥善處理」在多數情況下意味著及早交給人類判斷,而不是讓機器不計成本地反覆嘗試——後者除了燒錢,還會拖延真正需要人工介入的時機,對真正重要的任務反而是一種傷害。
在多 Agent 系統裡，如果 Orchestrator 呼叫的某個 Sub-agent 一直失敗，重試邏輯應該在 Orchestrator 層還是 Sub-agent 層處理？
應該分層處理，而且分清楚哪一層負責什麼，是避免「重試次數被意外放大」這個常見陷阱的關鍵。
Sub-agent 內部的重試：只處理該 Sub-agent 自己任務範圍內的暫時性失敗（例如它呼叫的某個外部工具逾時）。這一層的重試邏輯是「局部的」，Sub-agent 應該對自己內部的重試次數和成本負責，重試失敗達到上限後，Sub-agent 回傳一個明確的失敗狀態給 Orchestrator（如前面提到的 status: failed），而不是無限重試到「總有一天會成功」。
Orchestrator 層的重試：面對的是「這個 Sub-agent 回傳了失敗狀態，我該怎麼辦」這個更高層次的決策，而不是簡單地「再呼叫一次同一個 Sub-agent」。如果 Orchestrator 對 Sub-agent 的失敗狀態，也套用和 Sub-agent 內部一樣的「重試」邏輯,會出現一個容易被忽略的陷阱:Sub-agent 內部已經重試了 3 次才回報失敗,Orchestrator 收到失敗後又重新呼叫 Sub-agent 重試 3 次,而 Orchestrator 本身如果也在一個更上層的循環裡被重試,實際發生的總重試次數會是三層次數的乘積,而不是三層次數的加總——這是多 Agent 系統裡「重試次數被意外放大」最常見的成因,也是最容易在成本審計時被嚴重低估的風險。
正確做法是,每一層都要能看到「這是不是已經重試過的失敗」這個資訊,而不是把下層的失敗當成一個全新的、還沒被嘗試過的請求。具體實作上,可以在 trace context 裡帶一個「已消耗重試次數」的欄位,層層傳遞,Orchestrator 收到 Sub-agent 的失敗狀態時,先檢查這個欄位,如果已經達到某個全域上限(不只是單層上限),直接中止整個任務鏈,而不是重新開始計算重試次數。
幾乎每個 Agent 框架的預設行為都是：工具調用失敗，就重試。這個邏輯在傳統程式設計裡合理——網路請求偶爾逾時，重試一次通常就解決了。但把這個邏輯原封不動搬到 Agent 系統裡，會製造出一個開發者最容易忽略、後果卻可能最嚴重的財務風險：失控的重試循環。
差別在於失敗的性質。傳統系統的失敗通常是暫時性的（網路抖動、伺服器瞬間過載），重試幾乎不花額外的有意義成本。Agent 系統的「失敗」很多時候不是暫時性的，而是結構性的——例如工具回傳的資料格式模型無法正確解析、任務本身超出模型能力範圍、或者陷入邏輯循環（模型每次都做出同樣的錯誤判斷）。這類失敗重試 10 次，得到的結果和重試 1 次幾乎一樣，但成本是 10 倍。
設計重試邏輯之前，必須先把「失敗」拆解成不同類型，因為每種類型該用的策略完全不同。
暫時性失敗：網路逾時、API 限流、第三方服務短暫不可用。這類失敗的特徵是「同樣的請求，稍後再試通常會成功」，適合用指數退避（exponential backoff）重試——第一次失敗等 1 秒重試，第二次等 2 秒，第三次等 4 秒，通常設定 3-5 次上限。這是唯一一種「單純重試」策略真正適用的失敗類型。
結構性失敗：工具回傳的資料格式不符合預期、模型對任務的理解方式本身有偏差。這類失敗的特徵是「同樣的請求重試，大概率還是會失敗」，因為問題不在「這次運氣不好」，而在「這個請求本身有問題」。對結構性失敗使用單純重試,只會反覆燒錢卻不會提升成功率——正確的處理方式是偵測到這類失敗後,改變請求的內容或策略(例如簡化任務描述、換一種提示詞框架、或直接標記為需要人工介入),而不是原封不動地重複同一個請求。
循環性失敗：模型陷入「嘗試 A 失敗 → 嘗試 B 失敗 → 又回頭嘗試 A」的推理循環，每一輪都消耗 token 和工具調用，但沒有實質進展。這是最危險的失敗類型，因為它在監控儀表板上可能看起來像「系統很忙碌、正在努力工作」，實際上是在原地打轉燒錢。偵測循環性失敗需要追蹤 Agent 的狀態歷史，如果連續幾輪的狀態高度相似（同樣的工具調用、同樣的參數、同樣的錯誤訊息），這是循環的明確信號，必須立即中斷，而不是繼續讓它「再試試看」。
多數開發者知道要設重試上限（例如最多重試 3 次），但只設定次數上限,仍然可能在成本上失控。原因是重試次數上限沒有考慮「每次重試的成本可能不一樣」——如果第一次嘗試消耗了 500 個 token，但因為模型在重試時加入了更多上下文（例如把前一次失敗的錯誤訊息也放進提示詞），第三次重試可能消耗 3000 個 token。單純限制「重試 3 次」，沒有限制「這個任務總共花了多少」，仍然可能讓一個任務的總成本遠超預期。
更完整的設計應該同時設定兩個上限：重試次數上限（避免無限循環）和單一任務的總成本上限（避免即使次數不多，但每次都很貴，總和依然爆表）。一旦任一上限被觸及，任務應該立即終止並標記為失敗，而不是「反正還有次數額度,再試一次看看」。
很多 Agent 系統設計時預設「失敗就要想辦法解決,直到成功為止」，但這個假設本身有問題——不是所有任務都值得為了「成功」付出無限的重試成本，尤其當任務本身的價值有限時。
更務實的設計是分層降級：第一層失敗，嘗試原策略重試（暫時性失敗適用）；第二層失敗，切換到簡化版本的任務（例如原本要求模型做複雜的多步驟分析，降級成只回傳最基本的結論，犧牲深度換取成功率）；第三層失敗，直接放棄自動化，回傳「無法自動完成，需要人工處理」的明確狀態，而不是繼續燒成本硬撐。這個降級鏈條的設計，讓系統在遇到困難任務時「優雅地失敗」，而不是「昂貴地失敗」。
如果你正在開發或營運一個 Agent 產品，沒有把重試邏輯的成本控制設計好，是最容易被忽略、卻可能造成最大財務黑洞的技術債之一——一個陷入循環性失敗的 Agent，可能在你毫無察覺的情況下，一天內燒掉相當於一千個正常任務的成本。在上線任何 Agent 功能之前，先確認三件事：重試邏輯是否區分了暫時性、結構性、循環性三種失敗類型並用不同策略處理；是否同時設定了重試次數上限和單一任務總成本上限；是否有明確的降級鏈條，讓系統在無法解決問題時「優雅失敗」而不是無限硬撐。這三件事沒做好，你的 Agent 成本結構裡永遠藏著一個你看不見、但隨時可能引爆的風險。