Hello，Lena 嚟啦。舊年有段時間，我望住一個跑咗兩個禮拜都好正常嘅 workflow，然後佢突然就……停咗。冇有用嘅 error，冇明顯原因。任務完成咗 80%，個 agent 就噉靜晒落嚟。
之後幾個鐘，我一路以為係自己嘅 code 有問題。唔係。嗰個係一個 Claude usage limit（使用限制）——但唔係我以為會觸發嘅嗰個。
呢段經歷令我開始諗。之前睇到嘅大多數 troubleshooting 都將"Claude 冧咗"當作一個單一問題嚟處理。但翻住啲 logs，我逐漸留意到三種完全唔同嘅狀況俾人搞混埋一齊咗。而一旦我分得清佢哋，修復方案就變得清晰好多。
呢個就係嗰份拆解——我希望自己喺開始之前就有嘅嗰份。
當 Claude 觸發限制或宕機嗰陣，到底發生咗咩
第一件值得慢落嚟諗清楚嘅事：唔係所有 Claude 故障都係同一種故障。
Rate Limits（速率限制） vs Usage Caps（用量上限） vs Outages（服務中斷）
呢三種係唔同嘅問題，有唔同嘅成因、唔同嘅錯誤特徵同唔同嘅修復方式。搞混佢哋會嘥時間。
Rate limits（速率限制） 係對 requests 同 tokens 嘅每分鐘約束。你嘅 rate limit 取決於你所屬嘅 usage tier（使用層級），透過三個關鍵指標嚟衡量：requests per minute (RPM)、tokens per minute (TPM)，有時仲有 daily token quotas（每日 token 配額）。當你超出呢啲限制嗰陣，你會收到一個 HTTP 429 Too Many Requests。呢個係一個 throughput（吞吐量）問題——你喺一個短時間窗口內請求得太多、太快。
Usage caps（用量上限） 就唔同。Claude Code rate limits 作為一個由三個獨立、重疊嘅約束組成嘅系統運行，而 dashboard 上面顯示嘅百分比只反映咗其中一個。你可能望住 Anthropic console 顯示日用量仲剩 6%，以為一切都冇問題，結果仍然撞咗牆——因為你消耗完嘅係 per-minute token ceiling（每分鐘 token 上限），唔係 daily 嗰個。呢個係一個微妙但重要嘅區別。
Outages（服務中斷） 係完全唔同嘅另一類。529 Service Unavailable 意味住 Anthropic 嘅伺服器喺系統層面承受緊壓力。529 error 唔係你嘅問題——佢發生喺 Anthropic 嘅伺服器承受跨所有用戶嘅高流量嗰陣，而俾拒絕嘅 529 requests 唔會計入你嘅賬單。你冇辦法透過 code optimization 嚟修復 529。你等，你 back off（退避），你檢查 Anthropic 狀態頁 攞 incident 更新。
呢個區分點解咁重要：錯誤嘅診斷會導向錯誤嘅修復。我見過有人升級佢哋嘅 API tier 嚟修復實際上只係一個 transient outage（瞬時中斷）。亦見過有人耐心等一個 429 "自行恢復"，而佢哋真正需要嘅係換一種 request pattern。
每種故障模式點樣影響 Agent 工作流
Chat interface 喺 Claude 撞到限制嗰陣都算寬容。你睇到一條訊息，等一陣，再試一次。
Agent workflows 就唔寬容喇。Claude Code 唔係向 API 發一個 prompt 然後等 response 咁簡單——每次交互都係一段 multi-turn conversation（多輪對話），包含 system prompt、累積嘅對話歷史、拉入 context 嘅檔案內容，同埋 tool-use tokens。一個睇落好簡單嘅"edit 呢個檔案"命令，喺完整 context 組裝之後，可能喺單次 API call 入面消耗 50,000–150,000 tokens。
Rate limit hit 喺呢種環境下會引發 retry loops（重試循環）——agent 不斷發送 requests，每一個都失敗，每一個都喺消耗計入你 quota 嘅 tokens。Usage cap hit 可能喺任務執行到一半嗰陣中斷執行，有時仲冇明確信號話你知呢個係 cap 問題。而 outages 就造成我所講嘅 silent failures（靜默失敗）：tool call 掛住、timeout，視乎你嘅設定，可能唔會記錄任何有用嘅資訊。
呢個就係我喺嗰個卡住嘅 workflow 上面花咗幾個鐘好唔舒服嘅原因。Agent 觸發咗 rate limit，入咗一個冇 backoff 嘅 retry loop，喺我留意到之前就燒晒我剩餘嘅 token budget。
針對每種故障模式嘅即時修復
Rate Limit Hit：先止血
最有效嘅即時修復方案係 exponential backoff with jitter（指數退避加抖動）。原理係咁嘅：每次 retry 等待嘅時間係上一次嘅兩倍，加一個細嘅隨機偏移量（jitter），用嚟分散嚟自多個 client 嘅 burst retries（突發重試）。
Jitter 呢部分好容易俾人忽略，但佢好重要。冇佢嘅話，當多個 worker 或者平行嘅 agent thread 同時觸發咗同一個 rate limit，然後全部喺完全一樣嘅間隔之後重試，你就喺每個 retry cycle 重新製造咗 burst 問題。你唔係喺解決問題——你只係將佢推遲咗一個固定偏移。
一個簡單嘅 Python 模式，一直都好好用：
import time, random
from anthropic import Anthropic, RateLimitError
def call_with_backoff(client, messages, max_retries=5):
for attempt in range(max_retries):
try:
return client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
messages=messages
)
except RateLimitError as e:
if attempt == max_retries - 1:
raise
base_wait = min(2 ** attempt, 60)
wait_time = base_wait + (random.random() * base_wait * 0.1)
time.sleep(wait_time)
值得一提：Anthropic 官方 Python SDK 預設包含內建嘅 retry logic。佢會對 429 errors 自動重試最多 2 次，用 exponential backoff。對於生產環境入面容錯要求更高嘅 agent workflows，你通常需要配置更高嘅 max_retries 值同加入你自己嘅 jitter 邏輯。
除咗 retry 之外，降低並行度。如果你有 5 個 agent threads 同時發起 Claude API calls，而你嘅 rate limit 係 50 RPM 加共享 token pool，你幾乎肯定會碰撞。錯開 requests、盡量 batch，唔好假設並行執行可以線性提升 throughput。
Usage Cap Hit：唔好由零開始
任務做到一半撞到 cap 係最令人抓狂嘅故障模式之一，因為喺 cap hit 之前完成嘅工作通常仍然有效。修復方案唔係重啟——而係保存狀態然後恢復。
如果你喺 subscription plan 上面，而且喺生產 workflows 入面頻繁撞到 caps，Batch API 允許異步處理大量 requests，喺 input 同 output tokens 上面都有 50% 折扣——對於唔趕時間嘅任務，呢個能顯著擴展你嘅有效容量。如果你有比較大嘅 system prompt 或者重複嘅 context，Prompt caching 值得做：cached tokens 嘅費用只係標準 input tokens 嘅一小部分，喺長時間嘅 agent session 入面，相同 context 俾人反覆發送，呢筆節省會好快累積起嚟。
如果 usage cap 係結構性嘅唔匹配——你確實需要比當前 tier 更多嘅 throughput——喺做升級決定之前，請去 docs.anthropic.com/en/api/rate-limits 核實當前嘅 plan limits，因為呢啲數字會喺冇通知嘅情況下變。
Outage 處理：優雅降級
對於 outages，核心模式係 circuit breakers（熔斷器）同 graceful degradation（優雅降級）。
Circuit breaker 模式有三種狀態：Closed（正常運行）、Open（偵測到故障——停止嘗試）同 Half-Open（測試服務係咪已經恢復）。應用到 Claude API 集成入面：喺連續 N 次失敗之後，circuit 打開並停止發送 requests。經過一段 timeout period 之後，佢允許發送一個 probe request（探測請求）。如果成功，circuit 再次關閉。
同 retry 嘅關鍵行為差異在於：retries 處理單個 request 失敗，circuit breakers 處理系統性故障。如果 Claude 宕機 20 分鐘，你唔會想你嘅 agent 喺呢段窗口入面發出 400 個失敗嘅 API calls。你想佢偵測到呢個模式，停止嘗試，排隊等待，喺服務恢復之後再繼續。
為你嘅 Agent 工作流構建彈性
呢啲模式先係有趣嘅部分——至少對我嚟講係。上面嘅即時修復能止住血。呢一節要講嘅係點樣一開始就唔流血。
Fallback Model Routing（備選模型路由）
當 Claude 唔可用嗰陣，有一個 fallback model endpoint 意味住你嘅 agent 可以喺功能降級嘅情況下繼續運行，而唔係完全停擺。實際做法係噉嘅：你嘅主 workflow 路由到 Claude；如果你收到一個 529 或者 circuit breaker 觸發，你將低風險嘅子任務路由到一個 secondary model，而 critical-path 嘅工作排隊等 Claude 恢復。
呢個唔係簡單嘅即插即用——唔同 models 有唔同嘅 tool call 行為、context 格式同輸出一致性。我嘅建議係由窄範圍嘅 fallback 開始：搵出你嘅 agent workflow 入面真正同模型無關嘅部分（summarization、simple classification、format conversion），先將呢啲路由到 fallback。將複雜推理同 tool-heavy 嘅步驟留喺 queue 入面。
關於 multi-provider routing 同完善嘅 fallback 邏輯，Portkey 嘅 LLM gateway 詳細介紹咗相關模式——retries、fallbacks 同 circuit breakers 作為分層系統嘅組合方式，如果你要為生產可靠性嚟構建，好值得一讀。
Checkpoint and Resume Patterns（檢查點同恢復模式）
講真，呢部分我仲未完全諗清楚。但方向係明確嘅：agent state 需要喺 task boundaries（任務邊界）處係可序列化嘅。
基本做法：喺發起 Claude API call 之前，將你當前嘅 agent state——任務進度、已完成步驟、中間輸出——序列化到持久化儲存入面。如果調用失敗且 circuit breaker 打開，你就有一個 checkpoint 嚟恢復，而唔係由頭開始。
更難嘅部分係喺步驟之間存在依賴嘅 agentic workflows 入面定義"task boundaries"。我發現最乾淨嘅做法係將每次 tool call 都當作一個潛在嘅 checkpoint，即使呢個感覺粒度太細。合併 checkpoints 比拆解一個冇恢復點嘅、部分完成嘅多步驟任務容易得多。
分離關鍵路徑同後台任務
唔係所有 agent task 都需要同樣嘅可用性保證。後台任務——日誌記錄、摘要生成、低優先級分析——可以承受 Claude 幾分鐘甚至幾個鐘唔可用。 關鍵路徑任務就唔得。
顯式噉建模呢一點，令你可以為唔同場景設計唔同嘅彈性策略：關鍵路徑獲得積極嘅 retry 邏輯、fallback models 同 circuit breaker 監控；後台任務俾人耐心排隊，唔承受 retry 壓力。淨係呢一點就能顯著降低 Claude usage limits 帶嚟嘅噪音，因為你唔再將每一個失敗嘅 API call 都視為同等緊急。
更深層嘅問題：每個 Workaround 都喺度俾人重新發明
有件事一直困擾住我。
我同足夠多正在構建 Claude-based workflows 嘅人傾過之後，留意到一個模式。有人解決咗 exponential backoff 嘅問題。佢哋做得好好。佢跑得起。然後三個月之後，一個隊友開咗新 project，撞到同樣嘅 429 errors，然後再次解決咗佢——稍微唔同嘅方式，稍微唔同嘅檔案，稍微唔同嘅做法。第一個解決方案從來冇傳遞過去。
Checkpoint patterns、circuit breaker configurations、fallback routing logic 都係噉。一個全局嘅 retry counter 將所有 tools 當作單一故障域嚟處理——當一個 tool 降級嗰陣，佢耗盡咗所有其他 tool 嘅 budget。有人發現咗呢個問題，構建咗 per-tool circuit breakers，然後佢就留喺一個 project 嘅 codebase 入面，冇文檔，亦冇俾下一個遇到完全一樣問題嘅 project 所參考。
呢個唔係一個 code 問題——呢個係一個 knowledge structure（知識結構）問題。一個經過驗證嘅 fallback strategy 應該以可複用嘅形式存在，跟住 agent capability 一齊傳遞，而唔係留喺一段 chat log 或者某個俾人遺忘嘅一次性 script 入面。
對此我仲未有一個完整嘅答案。我一直喺度諗。
FAQ
Claude 目前對 API 用戶嘅 rate limits 係幾多？
呢啲數字會變，所以喺做架構決策之前請查閱官方 Anthropic rate limits 文檔。大致參考：limits 基於 tier（Tier 1 到 Tier 4），以 RPM、ITPM 同 OTPM 嚟衡量，更高嘅 tier 喺達到消費門檻之後解鎖。Tier 1 起步保守；Tier 4 慷慨好多。2025 年文章入面嘅數字而家可能已經過時。
點樣喺生產 agent workflow 入面處理 Claude outages？
Circuit breakers 係正確嘅模式。喺連續失敗達到閾值之後打開 circuit，喺 open 狀態下排隊等待，timeout 之後探測，服務恢復之後關閉。喺你嘅監控入面檢查 status.anthropic.com 嚟區分局部問題同平台級別嘅 incident。
Claude 唔可用嗰陣最佳嘅 fallback model 係咩？
呢度冇通用答案——取決於你嘅 agent 做緊咩。對於 structured output 任務，大多數主流 models 都處理得仲算得。對於複雜嘅 tool-use chains 同多步推理，fallback 質素下降更為明顯。先搵出你 workflow 入面真正同模型無關嘅嗰個窄切面，先將嗰部分路由到 fallback。
點樣保存 agent state 令到 Claude 故障唔會令任務由零開始？
喺每次 Claude API call 之前，喺 task boundaries 處序列化 agent state。至少包括：已完成步驟、中間輸出、當前喺 task graph 入面嘅位置。粒度問題更難——傾向於更頻繁嘅 checkpoints。儲存好平；重跑一個兩個鐘嘅 agent task 就唔平喇。
點樣阻止 agent 喺失敗嘅 retries 上面燒 tokens？
兩點：exponential backoff with jitter（令 retries 唔會產生同步嘅 burst），同 circuit breakers（令系統性故障唔會持續消耗 retry budget）。Anthropic Python SDK 內建咗基本嘅 retry logic——明確配置佢，而唔好靠預設值。對於有並行嘅生產系統，加入 per-tool 或者 per-operation 嘅 circuit breakers，噉一個降級嘅 endpoint 就唔會耗盡你全部嘅 retry budget。
我大概會繼續關注呢個領域嘅發展。Limit 同 resilience patterns 感覺仲喺度俾人公開噉探索同完善，我亦唔肯定自己已經搵到適用於長時間運行 agentic workflows 嘅最乾淨版本。但三種故障模式之間嘅區分——至少呢部分已經比較確定。
