https://yennj12.js.org/yennj12_blog_V4/tags/reliability/Recent content in Reliability on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSat, 04 Jul 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part41-troubleshooting-zh/Mon, 08 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part41-troubleshooting-zh/「AI 系統出問題了」不是問題描述，是症狀描述。 在沒有找到根因之前，任何修復都是猜測。 結構化的故障排查不是把所有可能都試一遍， 而是用最少的資訊快速縮小到一個節點。 面試情境 面試官：「你們的 AI 客服系統，今天早上 9 點開始，客戶回報：系統變慢了，有時候會給出奇怪的答案。你不在現場，只能遠端處理。請一步一步說明你的排查思路，以及你平時會怎麼設計可觀測性來讓這類問題更快被找到。」 一、AI 系統故障排查的特殊性 傳統系統 vs AI 系統的故障特性對比： 維度 傳統系統 AI 系統 ────────────────────────────────────────────────────────────── 確定性 相同輸入 = 相同輸出 LLM 輸出有隨機性，問題可能間歇出現 錯誤信號 明確 Error Code（500/404） 品質問題沒有 Error Code，只有「感覺不對」 根因數量 通常在代碼或配置 分佈在：模型、Retrieval、Tool、基礎設施 「正確」定義 有明確的正確答案 需要評估，不是二元對錯 ────────────────────────────────────────────────────────────── 最重要的 AI 特有洞察： ┌──────────────────────────────────────────────────────────────┐ │ Retrieval 失敗 → 「奇怪的答案」 │ │ │ │ Vector Search 返回 0 個結果 │ │ ↓ │ │ LLM Context 是空的 │ │ ↓ │ │ LLM 沒有 Context，靠「自己的知識」猜測 │ │ ↓ │ │ 症狀：「答非所問」「答案不基於我們的資料」 │ │ Error Log：沒有任何錯誤 ← 這就是難以發現的原因 │ │ │ │ 只有 Trace 才能發現： │ │ vector_search Span → result_count=0（返回 0 結果） │ └──────────────────────────────────────────────────────────────┘ 三個常見的排查誤區： 誤區 1：「LLM 模型一定有問題」 → 不一定。延遲問題通常是基礎設施；品質問題可能是 Retrieval 失敗 誤區 2：「昨天還好，一定是昨晚的部署造成的」 → 不一定。流量模式改變（如特定類型查詢增多）也能觸發潛在問題 誤區 3：「重啟一下試試」 → 可能暫時緩解（Cold Start 問題除外），但根因沒找到必定再發 二、三個可觀測性成熟度階段 ╔══════════════════════════════════════════════════════════════╗ ║ Phase 1：基礎可觀測性（POC / 初期上線） ║ ║ 「能知道系統壞了」 ║ ╚══════════════════════════════════════════════════════════════╝ 元件： ├── 結構化日誌（JSON 格式，帶 timestamp、level、service 欄位） ├── 基本 Metrics（Error Rate、P50 Latency、Uptime） └── 簡單 Alert（Error Rate > 5% → 發 Email） 能解決的問題： ├── 「系統是不是掛了？」（Uptime 告警） └── 「有沒有大量錯誤？」（Error Rate 告警） 無法解決的問題： ├── 「哪個 Step 慢？」（沒有 Trace） └── 「品質退化了嗎？」（沒有 Eval 指標） ╔══════════════════════════════════════════════════════════════╗ ║ Phase 2：生產級可觀測性（正式上線後） ║ ║ 「能知道系統為什麼慢，慢在哪裡」 ║ ╚══════════════════════════════════════════════════════════════╝ 新增元件（在 Phase 1 基礎上）： ├── Distributed Tracing（OTel + Cloud Trace） │ 每個 LLM 呼叫、Tool 呼叫、Vector Search 都有獨立 Span ├── 完整 Metrics 儀表板 │ P50/P95/P99 延遲、Token 消耗趨勢、快取命中率、Error Rate by type ├── 告警精細化 │ P95 > 5s 持續 5 分鐘 → PagerDuty │ Error Rate > 1% 持續 2 分鐘 → Slack └── 日誌結構化增強（加入 trace_id，可與 Trace 關聯） 能解決的問題： ├── 「哪個 Span 是延遲瓶頸？」（瀑布圖） ├── 「哪個 Tool 最常失敗？」（tool.https://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 會靜默地接受垃圾數據，直到幾小時後報表出現異常才被發現，彼時已有幾萬筆記錄污染了資料庫。https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part2-harness-engine-zh/Sat, 04 Jul 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part2-harness-engine-zh/Demo 版的 AI:json.loads(resp.content)——今天能跑。 上線版的 AI:模型回了 ```json {...} ```、或回 429、或一本正經編造欄位——明天就炸。 差別不在模型多強,而在你有沒有一層「挽具」接住這些意外。 這一篇就是拆解 agent_auto_system 的 Harness 引擎——它如何把不可靠的 LLM,變成可預測的服務。 Part 1 我們鳥瞰了整個系統,並指出 executor.py 和 harness/ 是心臟。這一篇我們把它剖開,順著這個專案的 merged PR 歷史,看它是如何一步步長出「可靠性」的。 Harness 層有五個元件: src/automation/harness/ ├── provider.py 選模型、算 fallback 順序 ├── validator.py 每個任務的結果驗證規則 ├── evaluator.py 獨立的 LLM 評審,0–100 打分 ├── costs.py token 用量與美元成本估算 └── langfuse_tracer.py 可觀測性(Part 4 深入) 我們一個一個看,並穿插它們背後的 PR。 一、最不起眼卻最致命的第一個坑:被 markdown 包住的 JSON 對應 PR #1:fix: parse markdown-fenced JSON from LLM flow output 任何做過 LLM 結構化輸出的人都遇過這件事。你在 prompt 裡明明白白寫「只回 JSON」,結果模型很貼心地回你:https://yennj12.js.org/yennj12_blog_V4/posts/building-resilient-systems/Sun, 10 Aug 2025 15:28:17 +0800https://yennj12.js.org/yennj12_blog_V4/posts/building-resilient-systems/How we built systems that gracefully handle failures and maintain service availability even when components fail.