10% 的對話在編答案：Retriever 靜默失敗的排查紀錄
AI 助理平台約 10% 的對話隨機沒有知識庫工具，agent 直接用訓練資料編答案。根因是 retriever 初始化時的 except Exception 吞掉了 Elasticsearch 連線失敗，導致工具註冊靜默跳過。修法：加 retry + 把失敗 surface 到 system prompt + metadata 追蹤。
#error-handling
3 篇文章跟成熟 coding agent 學設計（6）：ModelProvider 抽象——為什麼不能直接包 SDK 就好
直接包 SDK 三個月就會後悔：每家的 usage 欄位、tool call 格式、錯誤語意都不一樣，換模型等於重寫迴圈。五家參考專案都把「wire protocol」從「provider 身分」裡拆出來當獨立維度；looplane 更進一步，用 pydantic canonical contract（Message/ToolCall/Usage/ModelTurn）加六種 protocol adapter，把 OpenAI SDK 的內建 retry 關到 0，所有錯誤先分類成 ProviderErrorKind 再交給統一的重試政策。provider 表本身是跟 pi 的 packages/ai 對著抄的——這是血統，不是巧合。
跟成熟 coding agent 學設計（7）：Provider retry policy——從單次 5xx 到有界 retry 與 fallback
NVIDIA NIM 間歇 500 暴露了 looplane 早期只有錯誤分類、沒有重試消費者的缺口。現在 SDK retry 關閉，harness 對每個候選最多嘗試 5 次，使用帶 jitter 的指數退避並尊重有上限的 Retry-After；耗盡後可依明確設定切到 fallback model，model.retry 與 model.fallback 都進 event log。