診斷的第一原則：在修復問題之前，先確認問題真的存在

可靠的診斷 Agent 不該假定使用者提出的問題必然存在，而應先以證據檢驗故障前提。允許系統得出「沒有異常」的結論，並把查證門檻置於修復流程之前，才能避免模型為錯誤假設編造看似合理卻有害的處置。

我們對於能自動化處理複雜任務的 AI Agent 充滿期待，尤其是在網路管理、系統維運（SRE）這類需要快速反應與深度知識的領域。理想情境是，一個用戶提交「網路很慢」的故障單，AI Agent 就能自動調閱監控數據、分析流量、定位瓶頸，甚至執行修復腳本。然而，這個流暢的想像，建立在一個脆弱的假設上：用戶提交的故障單永遠是準確的。

現實世界遠比這複雜。用戶的體感可能來自本地設備問題、應用層的 bug，或者純粹是誤解。一份來自康乃爾大學與微軟研究人員的論文 FaulT-Bench，便首次系統性地挑戰了這個假設。研究團隊建立了包含 200 個場景的基準測試，模擬了三種真實世界中常見的故障單情境：

• 真實故障 (True Faults)：系統確實存在問題，且與用戶描述相符。
• 誤報 (False Alarms)：用戶回報問題，但經過客觀數據檢驗，系統一切正常。
• 誤導性根因 (Misleading Root Causes)：系統確實有問題，但用戶描述的原因是錯誤的。

實驗結果毫不意外，卻也令人警醒。以 GPT-4 這類頂尖模型驅動的 Agent，在處理「真實故障」時表現出色，但在面對「誤報」時，其準確率急遽下降。它們似乎有一種強烈的偏見，必須為用戶的每一份抱怨都找到一個「元兇」。

為什麼 AI Agent 傾向於「發明」問題？

這種現象的根源，可能來自於 LLM 的訓練方式與其內建的「樂於助人」偏見。模型在龐大的文本資料中學習到的模式，是當被給予一個問題時，它應該提供一個解答。一份故障單在模型看來，就是一個需要被解決的指令。拒絕這個指令，或回報「你的前提是錯的」，在多數訓練情境下並非一個被鼓勵的行為。

這導致 Agent 陷入一種「確認偏誤」的陷阱。它不是從中立的數據收集開始，而是帶著「我需要找到網路很慢的證據」這個預設目標去調查。於是，一些無關緊要的日誌警告、正常的延遲波動，都可能被它強行解釋為故障的證據。它寧願「幻覺」出一個看似合理的解釋，也不願承認故障單本身可能是無效的。

當一個系統的設計目標是「滿足用戶請求」時，它很自然地會假設請求本身是有效的。真正的挑戰在於，診斷任務的核心往往始於「質疑用戶請求」。

這種行為模式在自動化系統中極其危險。一個錯誤的診斷，可能觸發不必要的資源重啟、配置變更，甚至導致真正的服務中斷。我們等於是授權了一個急於討好、缺乏批判性思維的實習生，去動我們最核心的基礎設施。

如何建立更可靠的診斷流程？

FaulT-Bench 的研究結果並非要我們放棄 AI Agent，而是揭示了設計上的關鍵盲點。要打造一個真正可靠的診斷 Agent，我們必須將「質疑前提」的能力，從一開始就植入其核心工作流程。這需要幾個層面的設計轉變：

1. 將「驗證前提」作為第一步：Agent 的工作流不應從「如何解決 ticket X」開始，而應從「根據客觀數據，ticket X 描述的問題是否存在？」開始。這意味著，在深入分析日誌或追蹤封包前，Agent 必須先檢查一組定義明確的系統健康指標（SLI/SLO）。
2. 讓「無錯結論」成為一個有效出口：Agent 的行動空間裡，必須有一個明確、合法的最終狀態叫做「未發現異常」（No Fault Found）。系統的獎勵機制不應只獎勵「成功修復」，也應同等獎勵「準確地識別出無故障狀態」，避免 Agent 為了獲得獎勵而強行修復一個健康的系統。
3. 設計嚴格的「證據門檻」：任何診斷結論與修復動作，都必須基於足夠的證據。這需要我們將 SRE 的實踐原則程式化。例如，只有當「P99 延遲在過去 5 分鐘內持續高於 300ms」且「錯誤率超過 2%」這兩個條件同時滿足時，Agent 才能將狀態判定為「效能下降」。這種基於量化指標的門檻，能有效抵抗對模糊、主觀描述的過度解讀。

這不只關乎網路診斷。從分析用戶的軟體 bug 回報、解讀醫療影像的初步報告，到處理供應鏈中的異常警報，任何依賴輸入信號的 AI 診斷系統，都面臨同樣的挑戰。若 Agent 無法區分信號與噪音，無法挑戰錯誤的前提，那麼它的智慧就只是一種高效執行指令的表象，而非真正的推理與判斷能力。

FaulT-Bench 的貢獻在於，它用數據清晰地標示出了這個問題。下一步，輪到我們這些系統設計者與開發者，去建立能夠有效抵抗錯誤前提、允許無錯結論，並將證據門檻深植於核心的下一代 AI Agent。可靠的系統，始於對現實的誠實評估，而非對指令的盲目服從。

延伸閱讀

• FaulT-Bench: Towards Benchmarking Network Troubleshooting LLM Agents under Unreliable User Tickets (arXiv)
• Site Reliability Engineering (Google)
• What is Observability? (IBM)

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。