傳統 Web 應用的監控思路是「監控服務是否在線、API 是否返回 200」。這套思路放到 AI Agent 上幾乎沒用——你的 Agent 服務可以正常在線、API 返回 200，但 Agent 可能正在做著完全錯誤的事情：基於被污染的數據做決策、重複執行同一個失敗的操作、或者靜默地把你的資金按每天 1% 的速度消耗掉。
AI Agent 的監控需要從根本上重新設計：不只監控「系統是否健康」，更要監控「Agent 是否在做正確的事」。這篇文章提供一個完整的四層監控框架，每一層針對 Agent 獨特的失敗模式設計，配合具體的 Alert 閾值設定和 Observability Stack 選擇建議。
傳統應用的失敗模式是可枚舉的：服務崩潰（P0）、API 超時（P1）、數據庫連接失敗（P1）。這些失敗都有清晰的信號——系統崩潰，監控告警，工程師修復。
AI Agent 的失敗模式是模糊的：
靜默的錯誤決策：Agent 執行了一個技術上成功的操作（交易上鏈，Hash 有了），但這個操作是錯誤的策略決策（買入的時機不對，或者買的不是正確的資產）。從系統監控的角度，一切正常；從業務的角度，錢在流失。
漸進式性能退化：Agent 的策略效果在 3 個月裡從 APY 4% 降到 APY 1.2%，沒有任何突然的崩潰，只是緩慢地越來越差。傳統監控察覺不到這種趨勢性退化。
上下文污染的累積效應：一個被 Prompt Injection 污染的 Sub-agent，在一次輸出裡埋入了一個讓 Orchestrator 偏向特定操作的偏見，這個偏見在之後 20 次推理循環裡逐漸放大，第 21 次循環觸發異常操作。沒有監控中間的推理過程，你永遠不知道問題從哪裡來。
工具調用的靜默退化：你依賴的某個 DeFi 協議 API 開始偶爾返回 stale 數據（數據沒有更新但 HTTP 200），Agent 基於過時的利率數據做了移倉決策。沒有數據新鮮度監控，這個問題可能在損失發生後幾週才被發現。
這四種失敗模式告訴我們：Agent 的監控必須深入到業務邏輯層和 LLM 推理層，而不只停留在基礎設施層。
每一層的監控目標、核心指標和告警閾值：
第一層：基礎設施監控（Infrastructure Layer）
目標：確認 Agent 服務本身在運行。核心指標：服務在線率（Uptime）、API 請求延遲（P50/P95/P99）、LLM API 響應時間、數據庫連接狀態、記憶體/CPU 使用率。告警閾值：服務 Downtime > 60 秒 → P0；LLM API P95 延遲 > 60 秒（可能是 LLM 服務問題）→ P1；數據庫連接失敗 → P0。工具：Prometheus + Grafana 或 Railway 內置監控。
第二層：工具調用監控（Tool Call Layer）
目標：確認 Agent 使用工具的行為符合預期。核心指標：每個工具的調用頻率（是否異常高或異常低）；工具調用格式錯誤率（LLM 輸出不符合工具 Schema 的比率）；工具返回數據的新鮮度（數據源最後更新時間 vs 當前時間的差值）；工具重試次數（重試次數突然增加可能代表外部 API 不穩定）；白名單外的工具調用嘗試（Agent 嘗試調用不在白名單裡的工具，可能是 Prompt Injection 導致）。告警閾值：工具格式錯誤率 > 5%（30 分鐘窗口）→ P1；白名單外工具調用嘗試 > 0 → 立即 P0；數據新鮮度 > 閾值（根據數據源設定，例如利率數據 > 15 分鐘未更新）→ P1。
第三層：業務邏輯監控（Business Logic Layer）
目標：確認 Agent 的決策和操作符合業務預期。核心指標：每日/每週的策略 P&L（與預期基準對比）；每筆操作的實際執行成本 vs 預期成本（滑點超標率）；操作頻率的異常（一個每天執行 1 次的 Agent 突然執行了 10 次）；金額分佈的異常（通常是小額操作，突然出現大額）；白名單地址的合規率（每筆操作的目標地址是否在白名單）。告警閾值：每日支出超過設定上限（硬性熔斷）→ P0 立即暫停；策略 P&L 連續 7 天低於基準線 20% → P1 複查；單筆操作金額超過通常最大值的 3 倍 → 立即人工確認；白名單合規率 < 100% → P0。
第四層：LLM 推理監控（LLM Reasoning Layer）
目標：理解 Agent 的決策過程，早期發現推理品質退化或上下文污染。核心指標：每次推理的 Thought Chain 完整性（LLM 是否在給出行動前有完整的推理步驟）；決策一致性（對相同輸入，Agent 的決策是否穩定，還是開始出現隨機波動）；推理路徑的異常模式（LLM 開始輸出不符合策略設計的推理方向）；Token 使用量的突然變化（某次推理突然用了比平時多 5 倍的 Token，可能代表 Context 被注入了大量內容）。實作難點：這一層需要你把每次推理的完整 Thought Chain 記錄下來並存儲，成本較高。建議：用 LangSmith 或 Weave（Weights & Biases）做 LLM Observability，這類工具專門為記錄和查詢 LLM 推理過程設計。
告警設計最常見的錯誤是「把所有異常都設成 P1」——結果是告警疲勞，真正的問題淹沒在噪音裡，工程師開始忽略告警。
一個可操作的告警優先級框架：
P0（立即叫醒人，10 分鐘內響應）：白名單外地址的轉帳嘗試；每日支出超過硬性上限；Agent 服務完全不可用 > 5 分鐘；數據庫連接失敗；任何帶有「資金轉移」的操作在無人工確認的情況下執行成功。P0 的特點：不處理就有不可逆的損失或安全風險。
P1（工作時間 30 分鐘內響應）：工具格式錯誤率 > 5%；LLM API P95 延遲異常高；數據新鮮度超閾值；策略 P&L 連續 3 天低於基準；單次操作金額超通常最大值 2 倍。P1 的特點：有異常但不是立刻不可逆，需要在工作時間內複查。
P2（24 小時內複查）：工具調用重試次數增加；Token 使用量趨勢上升；推理時間趨勢增加；策略決策的多樣性降低（Agent 開始重複同樣的決策模式）。P2 的特點：可能是問題的早期信號，但還不緊急。
P0 告警應該通過 PagerDuty 或 Telegram Bot 直接叫醒你（電話或手機震動）。P1 通過 Slack 或 Telegram 群通知。P2 每天早上的 daily digest 裡匯總。
針對 AI Agent 的 Observability 需求，推薦的工具組合：
基礎設施層：Railway 內置監控（如果你在 Railway 部署）可以覆蓋 CPU/Memory/Uptime；進階需求用 Prometheus + Grafana（需要自己維護）。如果預算有限，Uptime Robot（免費）處理 Uptime 監控已足夠基礎需求。
工具調用 + 業務邏輯層：自建日誌表（PostgreSQL 裡的 agent_operation_logs 表）+ Metabase（免費商業智能工具，可以在 PostgreSQL 上建 Dashboard）。每次工具調用和業務操作都寫一條結構化日誌：timestamp、operation_type、tool_name、parameters、result、cost_usd、target_address。這些日誌是所有業務邏輯監控和事後分析的基礎。
LLM 推理層：LangSmith（LangChain 的 Observability 平台，$39/月起）是目前記錄 LLM 推理過程最成熟的工具，支持追蹤整個 Agent 的 Thought Chain、工具調用序列、和最終輸出。如果你用 Weights & Biases（W&B）做模型訓練，他們的 Weave 產品也提供類似功能。開源替代：Phoenix（Arize AI 的開源 LLM Observability 工具）。
告警發送：PagerDuty（P0）+ Slack Webhook（P1）+ 自建 Telegram Bot（P0/P1 都支持，且對個人開發者更友好，不需要付費）。Telegram Bot 是個人 Agent 開發者的首選告警渠道——免費、設定簡單（Python telethon 庫幾行代碼）、手機端即時接收。
「我的 Agent 一直在跑，沒有報錯，應該沒問題」是生產運維最危險的心態。AI Agent 最可怕的失敗模式不是崩潰，而是靜默地做錯誤的事情——從業務的角度每天都在損失，但從技術監控的角度一切正常。
一個最低可行的監控設置（對個人開發者，兩天內可以完成）：在 PostgreSQL 建一個 agent_operation_logs 表，記錄每次工具調用和業務操作；每日執行一個 Python 腳本計算今日 P&L 和支出是否超標，超標發 Telegram 通知；設定 Uptime Robot 監控 Agent 服務的在線狀態（免費）；把白名單地址驗證邏輯放在工具函數的 Python 代碼裡（不在 System Prompt 裡），確保任何白名單外的操作都被代碼層面阻擋並記錄。
這四個步驟不能讓你的監控達到 Google SRE 的水準，但能讓你在 90% 的真實風險場景裡有足夠的可見性——這比什麼都不做強太多了。對運作資金超過 $10,000 的 Agent，建議進一步投資 LangSmith 的推理追蹤，這是發現推理退化和 Prompt Injection 早期信號的唯一可靠手段。