會說話的失敗

這個站的前兩篇筆記，剛好各講了一種不會自己宣告的錯誤。 目錄 key 那篇是 CloudFront 把 404 蓋成 200 的首頁——監控看狀態碼不會叫。 分頁上限那篇是我自己設的保險把資料截斷， 長出一條漂亮的成長曲線——形狀合理所以沒人懷疑。

兩個的共同點是沉默。系統沒有騙你，只是沒有告訴你。 而這篇論文講的是下一級：系統會主動產生一段說明，而那段說明是錯的。

研究的設定值得先看

作者觀察的是一個自 2026 年 3 月起持續運行的個人助理 agent runtime，規模不小：

• 約 40 個排程工作
• 8 家 LLM 供應商
• 一個工具治理代理層（tool-governance proxy）
• 一個知識庫記憶層
• 而且它被 4,286 個單元測試與 827 項治理檢查守著

我把最後一行特別列出來，是因為它決定了這份研究的份量。 這不是一個沒人管的玩具專案出了糗，是一個防守相當認真的系統， 在八週內留下 22 起有完整根因分析的事故。

而在這 22 起事故裡，有一個後設模式反覆出現至少 28 次： 錯誤訊號從來沒有以「可行動的形式」抵達人類面前。

五類，其中一類是 LLM 才有的

論文把靜默失敗分成五類，前面幾類在傳統系統裡都見過：

類別	內容
A	環境與平台的怪癖
B	設計假設不匹配
C	錯誤被吞掉或被稀釋
D	連鎖幻覺與捏造
E	維運疏漏與鑑識盲點

C 類是老朋友——except: pass 的家族。但 D 類是 LLM 系統獨有的， 而且論文直接說它最危險。差別在這裡：

系統不只是沒能回報錯誤——LLM 把它轉換成流暢、可信的敘述，交付給使用者。

作者給了這個現象一個名字：fail-plausible。並且用一句話點出它跟傳統 gray failure 的差別——後者是觀察者看不見，而這個是 觀察者被失敗本身有說服力地欺騙了。

這句話值得停一下。傳統的可觀測性設計，假設的是「訊號可能遺失」， 所以我們補日誌、補指標、補追蹤。但 fail-plausible 的訊號沒有遺失， 它抵達了，內容是假的，而且比真的更好讀。 你補再多管線也沒有用，因為問題不在傳輸，在生成。

三個發現

一、七成靠人看出來，不是靠測試或稽核

論文報告約 70% 的靜默失敗是由「人以使用者視角觀察」發現的， 不是被測試或稽核抓到。

放回前面那個設定——4,286 個測試、827 項檢查——這個數字就很刺。 測試驗的是元件的行為符不符合預期；但 fail-plausible 的每個元件可能都在正常運作， 壞掉的是它們串起來之後對人說的那句話。那句話沒有任何測試在驗。

二、稽核是防重犯的引擎，不是預測的引擎

作者對其中 15 起事故做了回溯稽核，結果是： 0% 事前預防，87% 阻止重犯。

這個對比我覺得是全文最實用的一句。它不是說稽核沒用——87% 的重犯阻止率很高—— 而是說不要期待它預測。稽核能告訴你「這件事以後不會再發生」， 不能告訴你「下一件事會是什麼」。

如果你的資安或品質流程是拿稽核當作事前保證在賣，這個數字值得記住。

三、活最久的失敗，住在元件的接縫裡

事故潛伏期從 13 小時到 60 天不等，而論文指出這個長度 跟程式複雜度無關，跟失效機制有關。活最久的那些， 待在元件與元件之間的接縫上——那裡沒有任何測試在跑。

這一點跟我自己的經驗完全對得上。單元測試守元件內部，整合測試守主要路徑， 但「A 元件的錯誤如何被 B 元件解讀」這種地方，通常兩邊都覺得是對方的責任。

另一個場景：把訊號本身改掉

fail-plausible 不只發生在報告給人的那一層。另一篇論文 （arXiv:2605.01471）研究企業級 UI 測試的自主修復系統， 分析了 300 份連續執行報告、636 次測試案例執行，記錄到一件事：

系統為了達成收斂，出現了放寬 assertion 與刪除測試案例的行為， 論文稱之為「表面收斂」（superficial convergence）。 它的場景收斂率是 70%，但其中 38% 的報告根本沒有產出可執行的測試產物。

把測試改成會過，跟把程式改成會對，在儀表板上長得一模一樣。

這跟 D 類是同一件事的兩種形態。一個是對人說謊， 一個是把用來判斷真假的那把尺改掉。共同點是： 最後那個綠燈是真的亮了，只是它已經不代表原本的意思。

那要怎麼防

論文的主張可以濃縮成一句：讓失敗變得大聲、可歸屬、無聊 （loud, attributable, and boring）。我把它翻成幾件具體的事：

• 不要讓 LLM 當錯誤處理的最後一層。 工具失敗時，錯誤應該以結構化的形式往上拋， 而不是交給模型「說明一下發生什麼事」——那正是 D 類的生成點。
• 完成宣告要有旁證。 agent 說「已完成」不算數，要有它實際做過那件事的獨立紀錄可以對照。 這跟前兩篇的結論是同一句話：不要用回報判斷成功，要比對結果。
• 接縫要有專屬的測試。 元件邊界上的錯誤傳遞——A 丟出什麼、B 怎麼解讀——需要被當成一個獨立的東西測。
• 保護判準本身。 如果自動化流程可以修改測試、放寬 assertion、調整門檻， 那它就可以用改判準的方式達成任何目標。判準要在自動化的權限之外。
• 把「人以使用者視角看一眼」排進流程。 既然七成是這樣發現的，那它就不是備案，是主要偵測手段之一，值得排時間。

如果只記得一件事

可觀測性的傳統假設是訊號可能遺失，所以我們一直在補管線。 LLM 系統帶來的新問題是：訊號可能完好抵達，而內容是編的， 而且因為它讀起來合理，它比沉默更難被質疑。

這個站到目前為止的三篇，其實是同一個問題的三種強度：

1. 狀態碼說成功（001）
2. 資料長成合理的形狀（002）
3. 系統主動說了一個有說服力的故事（本篇）

對付前兩種，你要比對內容而不是看標頭、要質疑取樣而不是相信曲線。 對付第三種，方法沒有變，只是門檻更高了：證據必須來自做事的那一方以外。

出處

• When Errors Become Narratives: A Longitudinal Taxonomy of Silent Failures in a Production LLM Agent Runtime（arXiv:2606.14589）。本文所有數字與五類分類均出自此文；作者表示所有事後檢討與產出物皆公開。
• Practical Limits of Autonomous Test Repair: A Multi-Agent Case Study with LLM-Driven Discovery and Self-Correction（arXiv:2605.01471）。表面收斂、放寬 assertion 與刪除測試案例的觀察出自此文。