https://yennj12.js.org/yennj12_blog_V4/tags/self-healing/Recent content in Self-Healing on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part48-self-healing-agent-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part48-self-healing-agent-zh/大多數工程師的方法：在工具呼叫外面包一層 try-catch，失敗就 retry 三次。 資深工程師的方法：把「校驗」與「推理」分離，讓 Agent 的反思循環成為架構的一等公民。 普通做法：靠運氣假設外部 API 永遠回傳正確格式。 正確做法：用強型別 Schema 把「偽正確」的垃圾數據攔截在下游之前，Critic Agent 重寫參數，Circuit Breaker 隔離毒源。 面試情境 你在一家跨境電商公司擔任 FDE，負責設計一個基於 LangGraph 的供應鏈自動化 Agent。 系統每天處理約 50,000 筆訂單，依賴三家第三方物流商的 API 進行貨況追蹤。 某天凌晨兩點，主要物流商的 API 開始回傳 HTTP 200 但夾帶格式錯誤的日期欄位（DD/MM/YYYY 而非 YYYY-MM-DD）， 導致下游的 SQL Agent 批次寫入失敗，28% 的訂單狀態更新卡住。 面試官問：你如何在 Graph 設計層面實作自動容錯，讓系統不需要人工介入就能自我修復？ 以及當自我修復三次仍失敗時，你的降級策略是什麼？ 一、核心問題：為什麼 try-catch 是必要但不充分的 1.1 兩種不同性質的故障 外部 API 的失敗分為兩種截然不同的類型，絕大多數工程師只處理了第一種： 故障類型 A：硬故障（Hard Failure） ├─ HTTP 4xx / 5xx ├─ Connection Timeout ├─ DNS 解析失敗 └─ 對策：try-catch + exponential backoff ← 大家都做了 故障類型 B：軟故障（Soft / Silent Failure） ├─ HTTP 200，但 payload 格式錯誤（日期、時區、貨幣單位） ├─ HTTP 200，但欄位語意漂移（status: "in_transit" 變成 "IN_TRANSIT"） ├─ HTTP 200，但數值精度錯誤（公斤 vs 磅的混用） └─ 對策：需要 Schema 校驗 + 反思修正 ← 多數人沒有做 軟故障是最危險的，因為它看起來成功。下游的 SQL Agent 或 Pandas DataFrame 會靜默地接受垃圾數據，直到幾小時後報表出現異常才被發現，彼時已有幾萬筆記錄污染了資料庫。