最近我又被一個很典型、但也很現實的問題教育了一次：AI 自動化流程真正會讓你痛的，通常不是模型不夠聰明，而是外部世界根本不穩。
事情很簡單。我有一套會定時跑的 AI 報告流程，平常看起來很順：到點觸發、抓資料、整理內容、輸出摘要。聽起來很合理對吧？但只要其中兩個外部依賴同時出狀況，整套流程就會瞬間從「自動化助手」變成「凌晨把你叫起來的告警機器」。
這次的組合拳是這樣：模型端碰到額度或 credit 問題，搜尋端又撞到 rate limit。然後災難就開始了。
問題從來不是單點故障，而是連鎖故障
很多人設計 AI workflow 時，會先假設主模型可用、搜尋 API 穩定、抓回來的內容格式正常。這種設計在 demo 階段沒什麼問題，但一旦進入排程環境，事情完全不是這樣。
排程系統的特性是：
- 它會固定時間跑
- 它會跟其他 job 搶同一批外部資源
- 它發生錯誤時，通常不是你坐在旁邊即時救火
所以真正麻煩的不是「某個 API 壞掉」，而是：
- 主模型剛好沒額度
- 備援模型能用，但輸出風格不同
- 搜尋 API 同時因為短時間請求太多回 429
- 你後面還有其他 cron 也排在差不多的時段
這時候如果流程只寫成「失敗就重試」，通常只會更慘。
因為你其實不是在處理一個短暫失敗，而是在放大整體壅塞。
我後來接受一件事：AI pipeline 一定要預設會失敗
以前我會把 fallback 當成加分題，現在我比較像把它當成必考題。
也就是說，設計流程時就先問自己：
- 主模型失敗了怎麼辦？
- 搜尋拿不到結果怎麼辦？
- 只拿到半套資料時，可不可以先產出一個品質尚可的版本？
- 如果今天真的不能產出，是不是至少要「清楚失敗」，而不是默默死掉？
這個心態差很多。
因為你一旦接受「失敗是常態」，設計就會從追求完美輸出，轉成追求可恢復、可退化、可觀測。
我現在比較偏好的做法：三層 fallback
我後來把這類 AI 排程流程，盡量拆成三層。
第一層是模型 fallback。
主模型不通，就切到備援模型。這很基本，但實作時要注意一件事：不要假設所有模型輸出格式完全一致。你最好在後面加一層標準化，否則前面只是換模型，後面 parsing 一樣炸。
第二層是資料來源 fallback。
如果搜尋 API 回 429，不代表整篇報告就不能做。有些內容可以用較少的搜尋請求完成，有些可以改成直接抓已知來源，有些則可以降低覆蓋範圍，先產出「夠用版」。
第三層是結果等級 fallback。
不是所有任務都非得輸出完整版。很多時候，
- 完整版
- 精簡版
- 失敗摘要版
這三種層級，比單純的成功 / 失敗二分法實用很多。
flowchart TD
A[cron 觸發] --> B{主模型可用?}
B -- 是 --> C[主流程生成]
B -- 否 --> D[切換備援模型]
D --> E{搜尋可用?}
C --> E
E -- 是 --> F[完整資料整理]
E -- 否 --> G[縮減搜尋範圍 / 直接抓既有來源]
F --> H[輸出完整版]
G --> I{資料是否足夠?}
I -- 是 --> J[輸出精簡版]
I -- 否 --> K[輸出失敗摘要與原因]
Rate limit 不是 bug，是系統設計邊界
我以前看到 429，第一反應常常是：「靠，又被擋了。」
現在比較像是：「好，這代表我對外部服務的使用方式，已經碰到它的制度邊界了。」
這不是 bug，比較像是你系統設計時沒有把現實世界算進去。
尤其多個 cron 在相近時間一起跑時，最容易出現這種問題。你以為每個任務都只打幾次 API，很節制；但當它們同時發生，總量就完全不是那回事。
所以我現在會優先做幾件事：
- 減少不必要搜尋，先問「這次真的需要幾個來源？」
- 把能共用的資料抽成一次抓取，而不是每個 job 各抓一次
- 降低同時併發數，寧可慢一點，也不要一起炸
- 遇到 429 時尊重節流，不做情緒化狂重試
說穿了，rate limit 其實在提醒你：你的系統現在太貪心了。
真正有用的不是「永不失敗」，而是「失敗時還像個系統」
我現在越來越不相信那種宣稱自己全自動、全穩定、全智能的 AI 工作流。
不是因為 AI 沒用，而是因為真實世界根本不是實驗室。模型會變、供應商會限流、網站會改版、排程會碰撞、外部資料會缺漏。這些都不是例外，是日常。
所以我對一套 AI 自動化流程的評價標準，慢慢變成下面這幾個：
- 失敗時有沒有清楚的原因
- 有沒有備援路徑
- 可不可以降級輸出
- 出問題時，下一次修正會不會很容易
如果答案是 yes，那這套系統就算還不完美，我也會覺得它已經夠成熟。
CTO 的私心總結
做 AI 系統久了，我反而越來越少迷信模型本身，越來越重視整體工程設計。
模型當然重要，但真正決定體驗的，常常是那些很不 glamorous 的東西：排程、重試、節流、fallback、觀測性、錯誤訊息。
這些東西平常沒人在意，直到某天它們一起出事，你才會發現：原來 AI 系統最難的地方，從來不是讓它「看起來很聰明」，而是讓它在不順的時候，仍然表現得像一個可靠的系統。
如果你最近也在做 AI 自動化，而且偶爾被 429、配額、超時、外部服務不穩搞到懷疑人生，那我真心建議：先別急著改 prompt，先回頭檢查你的 fallback。很多時候，救你的不是更強的模型，而是更老實的系統設計。