本系列拆解企業導入 AI／Agent 時，工具明明做完了，工作卻沒有因此變好的決策現場。
Day 07：取得資料不等於已經幫使用者完成判斷。

Demo 開始後第六秒，螢幕右上角跳出綠色提示。

Log retrieval completed

Services searched: 11
Time range: 14:00–14:30
Log entries found: 3,184
Execution time: 5.8 seconds

結果視窗開始往下捲。ERROR、WARN、連線逾時、重試、健康檢查失敗與服務回應時間接連出現，整個投影畫面很快被紅黃兩色填滿。

專案經理指著數字說明。

「以前工程師要登入五、六個系統，自己猜時間區間、查相關服務、再把 Log 拼起來。現在輸入 Incident ID，Agent 會把這些事先做完。」

架構師補了一句。

「這次連 Trace ID 都串起來了。三千多行，人工找資料至少二十分鐘。」

維運主管點頭，看了一會兒畫面。

「所以它知道這次為什麼 Fail 嗎？」

「這一版先驗證 Log Retrieval。」專案經理說。

「那它至少知道哪幾行和事故有關？」

工程師切到摘要畫面。

Detected patterns:
- timeout: 127 occurrences
- connection reset: 43 occurrences
- retry failed: 38 occurrences
- health check failed: 16 occurrences

「主要錯誤類型都整理出來了。」

主管看著那四行統計。

「第一個錯誤是什麼？」

這次沒有人先回去看 Dashboard。

三千行裡，真正需要先看的那一行

負責當天 Incident 的值班工程師坐到電腦前。他先搜尋 timeout，得到一百二十七筆結果，其中大部分是同一個服務重試時留下的訊息。

再搜尋 connection reset，有些發生在事故後；下游服務被重啟時會留下同樣的紀錄。還有一些是每天健康檢查本來就會出現的雜訊。

「先按時間排序。」開發者說。

最早一筆是資料庫連線逾時。工程師展開前後紀錄，確認它平常每天都會出現幾次，和這次事故沒有直接關係。

「用 Trace ID 呢？」

「客戶回報的 Request 沒有完整 Trace ID。」

「那讓模型從上下文猜相關 Log？」

值班工程師沒有回答。他把時間範圍收斂到異常出現前兩分鐘，先排掉已知的健康檢查和重試訊息，畫面從三千多行剩下四十幾行。

他順著服務的啟動順序往前看，停在這段紀錄：

Config version mismatch
expected: 2026.08.04-3
loaded: 2026.07.29-1

「先查這個。」他說。「後面的 Timeout 是服務沒有正常啟動後才開始出現。」

從縮小範圍到找到第一個可驗證的假設，不到三分鐘。

Agent 沒有漏掉任何 Log。它完成的事情是把資料搬回來，卻沒有決定哪一段資料應該先讓人看。

而對 Incident triage 來說，後面這段才是工作真正開始的地方。

Retrieve 完成了，Incident triage 還沒有

這場 Demo 不是假的。Agent 確實自動完成了跨系統查詢、時間對齊、服務關聯與錯誤類型整理。

問題在於，它驗收的是一個步驟，不是使用者要完成的工作。

原本的工作不是把所有可能相關的 Log 集中到同一頁，而是從雜訊和後續反應中，找出一個值得優先驗證的故障假設。

這兩者中間，至少還有四段：

Retrieve
取得可能相關的資料
↓
Filter
排除已知雜訊、重複紀錄與後續反應
↓
Interpret
還原事件順序與服務關係
↓
Decide
選擇最值得先驗證的原因與下一步

第一步做得很快，並不會自動帶來後三步。

尤其 Log 的問題不在於它缺，而在於每一行出現的意義要放回當下的系統狀態裡才看得出來。一次性抓回更多資料，可能省掉登入和查詢的時間；也可能把原本分散進行的篩選、比對和縮小範圍，集中成一份更大的閱讀工作。

工程師以前會在查第一個服務後調整下一個方向。現在他先得到三千行結果，再自己重建同一套篩選順序。

從平台的角度，檢索效率提高了；從值班工程師的角度，他只是更早收到一份待處理清單。

大量 Output 最容易被當成完成證據

這類 Demo 很容易成功，因為它展示的是最容易看見、也最容易計數的能力。

• 搜尋十一個服務，比搜尋一個服務有說服力。
• 抓回三千行，比抓回三十行看起來完整。
• 整理四種 Pattern，比原始 Log 更像分析結果。

但這些都只能回答「系統做了多少事」，無法回答「使用者少做了什麼」。

對 Incident triage 來說，至少應追這幾個結果：

• 使用者實際閱讀的 Log 行數是否下降？
• 形成第一個可驗證假設的時間是否縮短？
• 是否減少了人工追加查詢和錯誤方向？
• Agent 輸出後，下一個行動是否明確？

若 Agent 把取得資料的時間從二十分鐘壓到六秒，但使用者接著花三十分鐘重新篩選和理解，整體工作不一定變快。它只把等待時間換成了閱讀時間。

更麻煩的是，大量資料會給團隊一種「已經很接近答案」的感覺。實際上，資料搬回來後才要開始做最需要經驗的事：排掉不重要的訊號、區分原因與結果、決定該往哪個方向驗證。

因此，Output Count 不能直接當成 User Value。

驗收要接回下一個決策

下一輪設計時，團隊沒有先換模型或擴大 Context Window。他們先改掉驗收問題。

原本問的是：

是否成功取得指定時間範圍內的相關 Log？

這只驗證了 Retrieve。

新版改成：

值班工程師是否能在輸出後五分鐘內，
得到一個附帶證據、可立即驗證的初步故障假設？

主畫面也不再預設顯示所有 Log，而是先放：

1. 最早出現的異常事件
2. 已排除的已知雜訊與排除理由
3. 事件的可能順序
4. 支持與反對目前假設的紀錄
5. 缺少的資料與下一個查詢

完整 Log 仍保留，因為工程師需要追查與推翻假設的能力。但它改成證據來源，不再是主要交付物。

這個調整也把 Agent 的責任範圍講清楚：它不必假裝替人做最後的 RCA；但它至少要幫使用者縮小到一個可負責驗證的起點。

第二版的主畫面只留七行

第二次 Demo，Agent 搜尋九個服務，共取得兩千六百多行紀錄。

主畫面沒有再讓資料往下捲。它只留下七行：前三行是設定載入失敗，後四行是服務啟動後立即停止。

下方寫著：

初步假設：部署後載入舊版設定，導致服務啟動失敗。
尚缺資料：本次部署實際使用的設定版本。
建議下一步：查詢 Deployment Record，確認載入版本。

值班工程師直接點開建議查詢，沒有先切回終端機，也沒有展開完整 Log。

這次畫面不像第一次那麼壯觀。沒有三千行資料飛快捲動，也沒有大片紅色錯誤訊息。

Agent 還是找到了所有 Log。

只是它終於知道，哪些內容不該先丟回給使用者。