hero

Ben Congdon 在 2026 年 10 月 19 日發表〈Agentic Monitoring〉。這裡的 monitoring 不是檢查 AI 代理有沒有偏離任務，而是讓代理協助監控正式環境中的軟體服務。本文先整理他的原型主張，再用 Google SRE 的既有監控原則，拆解一個可供工程團隊評估的實作分工；後面的部署情境是本站設計示例，並非作者公布的產品，也沒有聲稱已在本站實測。

原文摘要

Congdon 提出的原型，把工作拆成三段：代理讀服務程式碼並提出監控計畫；程式框架執行計畫；訊號觸發後，再由代理調查並視需要交給人。他特別指出，讓模型持續自由行動，不如讓它產出監控規格、交給確定性系統執行，能減少雜訊與 token 使用。他的重點案例是版本發布、設定更新等變更點，而不是再做一個全年不休、反覆詢問「有沒有異常」的聊天機器人。原文描述的是作者的原型經驗與方向判斷，沒有提供足以重現精確率、召回率及成本的完整測試資料。

把「是否故障」和「為何故障」分開

要理解這個分工，可以先看 Google SRE〈Monitoring Distributed Systems〉提出的兩個問題：系統哪裡壞了，以及為什麼壞。前者是症狀，後者是原因。付款請求大量失敗是使用者正在遭受的症狀；資料庫連線被耗盡則可能是其中一個原因。兩件事不能只靠一段流暢解釋就視為已經證實。

SRE 章節主張，呼叫值班人的關鍵路徑應簡單、可靠、容易理解，並以延遲、流量、錯誤、飽和程度等訊號觀察使用者服務。同章也提醒，高頻率但低價值的通知會耗損人的注意力。這些要求不會因為加了 LLM 就失效：如果每一輪都讓模型自行選資料、解讀圖表，再決定要不要通知，事後便難以分辨這次沒有告警，到底是服務正常、資料漏取，還是代理這次換了判斷標準。

因此，這裡有一種合理的工程解讀：把不固定、需要讀懂變更內容的工作交給代理，把固定頻率取樣、檢查執行是否成功，以及何時觸發的規則留在可重跑的程式裡。這是依原型與 SRE 原則提出的設計分析，不是作者已交付的標準實作。

一個設定發布的例子：先產出可審核的觀測計畫

以下假設某個 API 要改快取設定。規劃代理可以讀變更差異、設定的使用位置，以及已有的儀表板，提出「這次應觀察哪個端點、哪個版本，以及哪些依賴」的計畫。若設定只影響特定請求，監控整台機器的平均 CPU，很可能沒有對準變更本身。

計畫的交付物不該只有「注意延遲和錯誤」。團隊需要看得到實際指標名稱、查詢條件、觀測區間、比較基準、樣本不足時怎麼辦，以及這份臨時監控何時結束。對照組可以是仍使用舊設定的實例，也可以是發布前的基準；但若流量時段、請求組成不一致，就不能把兩張圖的差距直接認定為版本造成的退步。

這些欄位是本站示例的驗收要求，不是 Congdon 公布的規格格式。作者沒有提供可直接複製的 schema、門檻或查詢，不能替他編一份再稱為官方設定。真正落地時，還得先確認指標有被採集、標籤確實能區分新舊版本，且代理提出的查詢在現有觀測平台上可以執行。

執行器：沒有查到資料，不等於一切正常

計畫通過檢查後，排程、查詢與條件判斷可以由固定程式執行。執行器除了記錄指標結果，也要記錄查詢本身是否成功：權限過期、資料延遲、標籤拼錯或樣本為空，應留下明確的「無法判斷」，不能被折算為綠燈。否則再好的分析代理，也只是在不存在的觀測結果上推理。

同時保留傳統的關鍵告警，是為了讓代理故障不會連帶取消基本保護。Google SRE 強調監控路徑的簡單性，對這裡的啟示並不是拒絕模型，而是別把最重要的故障訊號，綁在一個本身可能逾時、超出預算或缺少上下文的調查流程後面。相關原則也區分內部指標與外部可見行為；前者有助除錯，後者才能回答使用者此刻是否真的拿到正確結果。

調查代理：交證據，不只交一個原因

當快取命中率改變、延遲或錯誤訊號觸發後，代理才進入較昂貴的查證階段。它可以讀取相同時間區間的日誌、比對版本差異、檢查依賴服務，並列出支持及不支持各個假說的資料。模型提出「新設定使後端負載上升」，應該附得出查詢、時間範圍、受影響版本與仍缺少的觀測，而不是只產生一段看似完整的事故故事。

在這個示例裡，最初可以只授予唯讀權限，讓代理產出調查報告與回復建議。若要進一步允許回滾、擴容或重新部署，則需要另一條明確授權的動作路徑：可操作的資源、允許的變更、停止條件，以及如何確認動作沒有使其他服務惡化。這些是本站提出的實作邊界，不能把它們當成原文已驗證安全的功能。

怎麼驗收：便宜且會解釋，不等於偵測可靠

第一種可做的驗證，是回放已標記的歷史變更：把已知有退步、已知正常，以及資料不完整的情境分開，觀察計畫是否選對訊號、執行器是否忠實執行，以及調查報告是否能指出證據。歷史事件可以用於調整流程，但調整後仍應另留未參與調整的事件做檢查，避免只記熟幾次事故。

第二種是與原有告警並行、暫不授權代理操作正式環境。除了記錄抓到多少問題，也要看漏報、誤報、通知延遲、人工覆核時間與查詢負擔。若代理抓到更多異常，卻把值班人的工作變成逐條否決低品質報告，就不能只以「偵測數增加」宣布改善。這是本文依監控目的提出的驗收方案，不是作者已完成的對照實驗。

Congdon 的文章提供了一個值得研究的分工：模型負責產生和調查監控假說，確定性程式負責穩定地執行觀測。公開材料尚不足以判斷它在哪些服務、流量與事故類型上優於既有系統；要跨過這條界線，需要的是可回放紀錄、失敗分類與同條件比較，而非把「代理一直在線」當成可靠性的代名詞。