Circuit Breaker 和前面重試策略文章提到的「單一任務總成本上限」，聽起來都是在限制損失，兩者具體怎麼分工？
兩者的分工核心是「作用範圍不同」,單一任務總成本上限是任務層級的邊界,Circuit Breaker 是 Agent 或服務層級的邊界,兩者疊加使用,而不是互相替代。
單一任務總成本上限的作用範圍:只針對「這一次任務」設限——例如一個任務的重試次數加總成本不能超過 $5,一旦這個任務達到上限,這個任務被中止,標記為失敗,但下一個新任務,是全新的計數,不受這次任務觸發上限的影響,系統整體(這個 Agent、這個服務)依然被視為正常運作。
Circuit Breaker 的作用範圍:不是針對單一任務,而是針對「這個 Agent 過去一段時間內,整體任務的失敗模式」——如果連續多個任務都因為同樣的原因觸發了成本上限或重試上限,這代表問題不是「這一次任務運氣不好」,而是這個 Agent 本身、或它依賴的某個底層服務(例如某個 MCP Server、某個外部 API)出現了系統性的異常。Circuit Breaker 監控的是這種跨任務的模式,一旦偵測到,不是只中止當下這一個任務,而是暫停這個 Agent 接下來所有的執行能力,直到人工介入確認問題已經解決。
具體的分工邏輯:單一任務成本上限,負責攔截「這一次任務本身的異常消耗」,防止單一任務燒光不合理的成本；Circuit Breaker,負責偵測「多次任務失敗模式所反映出的系統性問題」,防止一個已經壞掉的 Agent,持續不斷地產生一連串各自都被成本上限攔截、但加總起來依然造成大量損失和大量無效嘗試的失敗任務。可以把單一任務成本上限想成是第一層防護(擋住單次任務的異常),Circuit Breaker 是第二層防護(擋住「單次防護持續失效」這個更大的系統性問題)——兩者疊加,才能同時處理「單次意外」和「系統性故障」這兩種不同尺度的風險。
Circuit Breaker 進入 Open 狀態、暫停 Agent 執行之後，「人工介入確認問題已經解決」這個環節，具體要做什麼？不能只是等一段時間就自動恢復嗎？
單純「等一段時間就自動恢復」(不需要人工介入),對應的其實是 Circuit Breaker 的 Half-Open 狀態設計,但 Half-Open 的自動恢復,適用的是「問題可能是暫時性的,值得自動試探」這種情境,不是所有觸發 Open 狀態的情境都適合完全依賴自動恢復,原因如下。
Half-Open 自動恢復適用的情境:如果 Open 狀態的觸發原因,是類似「某個外部 API 短暫不穩定,導致錯誤率飆升」這種本質上是暫時性、外部因素造成的問題,用 Half-Open 狀態做自動化的小規模試探(等待一段冷卻時間,送出少量測試請求,如果成功就自動轉回 Closed)是合理的,因為這類問題確實有很高機率會在等待後自行恢復,不需要每次都等人工確認。
必須要有人工介入,不能只靠自動恢復的情境:如果 Open 狀態的觸發原因,牽涉到可能是程式邏輯本身的 bug、或者是資金安全相關的異常(例如前面文章討論過的,某個 Sub-agent 出現了不尋常的資金流動模式),這類問題不會因為「等一段時間」就自動消失,如果只依賴 Half-Open 的自動試探機制,反而可能讓一個真正有問題的系統,反覆進出 Open 和 Half-Open 狀態,持續不斷地嘗試恢復,卻始終沒有真正解決根本問題,這種情況下必須要有人工介入才能真正修復。
具體的人工介入該做什麼:查看觸發 Circuit Breaker 的具體日誌和數據(前面重試策略文章討論過的,狀態物件要保留足夠的除錯欄位,在這裡就是關鍵的診斷依據)，判斷觸發原因屬於暫時性(可以直接手動恢復或啟用 Half-Open 自動試探)還是結構性(需要先修復程式碼或調整策略,才能安全恢復)；如果判斷是結構性問題,在實際部署修復之前,不應該恢復 Agent 的執行能力,即使等待的時間比預期長。
實務上常見的分層設計:多數成熟系統的做法是,把觸發原因分類——「已知的、歷史上證實通常是暫時性的錯誤類型」(例如網路逾時),允許 Half-Open 自動試探；「未知的、或歷史上證實通常需要人工診斷的錯誤類型」(例如資金流動異常、大量格式錯誤的輸出),強制要求人工介入才能從 Open 狀態恢復,不允許 Half-Open 自動嘗試。這個分類本身,也是根據 Circuit Breaker 觸發歷史,持續累積經驗、動態調整的過程。
如果我的 Agent 系統同時服務多個不同的用戶（例如一個 SaaS 化的 Agent 產品），Circuit Breaker 該是全域共用一個，還是每個用戶各自獨立一個？
應該是每個用戶(或至少每個獨立的執行環境)各自獨立一個 Circuit Breaker,而不是全域共用,原因是全域共用會製造出一個嚴重的「連坐」問題,讓一個用戶的異常拖累所有其他用戶。
全域共用 Circuit Breaker 的問題:如果 Circuit Breaker 監控的是「整個系統的錯誤率」,而不是分別監控「每個用戶各自的錯誤率」,一種常見的失效情境是——某一個用戶的使用場景剛好觸發了一個邊界 bug(例如這個用戶連接了一個有問題的自訂 MCP Server),導致這個用戶的任務持續失敗,如果 Circuit Breaker 是全域共用的,這個單一用戶的異常錯誤率,可能會拉高整個系統的平均錯誤率,觸發全域斷路,結果是所有其他原本運作正常的用戶,也被迫一起停止服務——這是一個典型的「一個人生病,全部人一起隔離」的過度懲罰情境,對其他無辜用戶造成不必要的服務中斷。
每個用戶獨立 Circuit Breaker 的設計:每個用戶(或者更精確地說,每個獨立的執行環境或每個獨立的資源連接)各自維護一組獨立的錯誤率、成本消耗統計,只有這個用戶自己的統計超過門檻,才會觸發只影響這個用戶的斷路,不會波及到其他用戶。這個設計呼應了前面最小權限詞條討論過的「傷害範圍要有明確上限」原則——只是這裡限制的不是單次操作的資金傷害範圍,而是「一個異常用戶的影響範圍」,同樣是用隔離設計把傷害限制在最小範圍。
額外疊加的系統層級 Circuit Breaker:每個用戶各自獨立的斷路器之外,通常還會疊加一層系統層級的斷路器,監控的是「整個系統的底層基礎設施」(例如資料庫連接、核心 LLM API 呼叫)是否出現異常,如果是底層基礎設施本身出問題(不是單一用戶的個別情境造成),這種情況確實影響到所有用戶,系統層級的斷路器觸發,暫停整個系統是合理的反應——這一層和用戶層級的斷路器,監控的對象和觸發的範圍完全不同,兩者疊加,才能同時處理「個別用戶的局部異常」和「整個系統的全域異常」這兩種不同尺度的問題。
具體實作提醒:用戶層級的 Circuit Breaker,狀態(Closed/Open/Half-Open)必須依照用戶 ID 或執行環境 ID 分別儲存和追蹤,不能用一個全域變數記錄整體狀態,這是實作上容易被忽略、但直接決定「連坐問題會不會發生」的關鍵細節。
在多 Agent 系統裡，如果 Orchestrator 呼叫的多個 Sub-agent 各自有獨立的 Circuit Breaker，其中一個 Sub-agent 的斷路器觸發了 Open 狀態，Orchestrator 該怎麼處理這個情況？
這個情況延伸了前面 Handoff 詞條和多 Agent 錯誤處理討論過的原則,Orchestrator 面對某個 Sub-agent 斷路的處理邏輯,不該是「整個任務直接失敗」,而應該根據這個 Sub-agent 在整體任務裡的角色,做分層判斷。
第一步:判斷這個 Sub-agent 是否有可替代的路徑。如果觸發斷路的 Sub-agent,它負責的功能有其他替代來源(例如前面 MCP Server 詞條提到的情境,如果查詢市場數據的功能,原本連接了主要和備援兩個不同的 MCP Server),Orchestrator 可以先嘗試切換到備援路徑,而不是直接判定整個任務失敗——這需要架構設計時,就已經預先為關鍵功能準備好替代路徑,而不是事到臨頭才發現沒有備援。
第二步:如果沒有替代路徑,判斷這個 Sub-agent 的角色是否是任務的必要環節。如果斷路的 Sub-agent,負責的是任務裡「錦上添花」的附加功能(例如「額外的情緒分析參考」,不是核心決策依據),Orchestrator 可以選擇跳過這個環節,標記「這部分資訊暫時無法取得」，繼續完成任務的其他核心部分；如果斷路的 Sub-agent,負責的是任務裡的核心環節(例如前面 Handoff 詞條案例裡的「風險評估」或「執行交易」這類 Sub-agent),Orchestrator 不該跳過,而應該中止整個任務,標記為「因為關鍵環節不可用,任務暫停,需要人工介入」。
第三步:Orchestrator 自己的狀態記錄,要清楚反映「是哪個 Sub-agent 觸發了斷路,導致了這個結果」。呼應前面文章討論過的除錯欄位設計原則,Orchestrator 收到 Sub-agent 斷路訊息後,應該把這個資訊完整記錄下來(哪個 Sub-agent、什麼時候觸發、觸發原因),而不是只留下一個籠統的「任務失敗」記錄——這樣人工介入時,能直接定位到問題出在哪個 Sub-agent,不需要重新從頭排查。
這個設計呼應的核心原則:多 Agent 系統裡,單一 Sub-agent 的斷路,不該自動等同於整個系統的斷路,Orchestrator 的角色正是要做這一層「這個局部異常,對整體任務造成多大影響」的判斷和決策——這也是為什麼前面文章反覆強調「Orchestrator 不該持有執行型權限」但「應該持有協調決策的權限」,面對 Sub-agent 斷路這種異常情境,正是 Orchestrator 這個協調角色該發揮價值的地方。
一個多鏈套利 Agent 系統的 Circuit Breaker 分層設計案例
某個在多條鏈上尋找套利機會的多 Agent 系統，Circuit Breaker 設計如下：
Sub-agent 層級的斷路器：每條鏈的執行 Sub-agent 各自維護獨立的斷路器，觸發條件是「連續 5 次交易失敗」或「單一小時內累積 Gas 成本超過 $20」，任一條件達標就進入 Open 狀態，暫停該鏈的執行能力，其他鏈的 Sub-agent 不受影響。
用戶層級的斷路器（因為這是服務多用戶的平台）：每個用戶各自維護獨立的斷路器統計，避免單一用戶的異常（例如連接了有問題的自訂 MCP Server）拖累其他用戶的服務。
系統層級的斷路器：監控核心 LLM API 的整體呼叫成功率，如果短時間內成功率大幅下降（代表可能是 LLM 供應商本身出問題，而非個別 Agent 或用戶的問題），觸發系統層級的斷路，暫停整個平台的自動化執行能力，這是唯一會影響所有用戶的斷路器層級，因為底層依賴出問題時，確實所有用戶都會受到影響。
Half-Open 的差異化設計：Sub-agent 層級的斷路器，觸發原因如果被歸類為「網路或 Gas 價格波動這類已知的暫時性因素」，允許 Half-Open 自動試探（冷卻 10 分鐘後，嘗試一筆小額測試交易，成功則恢復）；如果觸發原因是「重複出現的、格式異常的交易回應」（可能代表某個協議的介面有變化，需要程式碼調整），強制要求人工介入，不允許 Half-Open 自動嘗試。
實際運作中發現的問題：工程團隊在上線初期，用了單一、全域共用的斷路器設計，某次一個用戶連接了一個回應速度異常慢的自訂 RPC 節點，導致這個用戶的請求持續逾時失敗，把整個平台的全域錯誤率拉高，觸發了影響所有用戶的斷路，造成大量無辜用戶的服務中斷。這個事故直接推動了團隊重新設計成前面提到的三層獨立斷路器架構，這個案例具體印證了 Q3 討論過的「全域共用斷路器會製造連坐問題」這個原則。
Circuit Breaker 設計的核心取捨是「敏感度 vs 誤觸發成本」。門檻設得越敏感（越低），越能在傷害擴大前及早攔截真正的問題，但也越容易對正常的偶發波動做出過度反應，觸發不必要的服務中斷，影響用戶體驗；門檻設得越寬鬆，誤觸發的機率越低，但真正的問題可能要累積更久、造成更多損失才會被攔截。另一個取捨是「Half-Open 自動恢復的便利性 vs 系統性問題被掩蓋的風險」：允許更多情境用 Half-Open 自動試探恢復，能減少人工介入的負擔，系統可用性看起來更高，但如果把不該自動恢復的結構性問題也放進 Half-Open 自動試探的範圍，可能導致問題反覆觸發卻始終沒被真正修復，只是在 Open 和 Half-Open 之間循環。建議：門檻設定應該根據歷史數據動態校準（觀察正常波動的統計分佈，門檻設在明顯偏離正常範圍的位置），而不是憑感覺設一個數字；Half-Open 自動恢復只套用在有歷史證據支持「這類問題通常是暫時性」的錯誤類型，涉及資金安全或未知錯誤類型的一律要求人工介入，不因為想減少人工負擔而犧牲安全邊界。