Agent Monitoring

Agent 監控應該追蹤哪些關鍵指標？每種指標的告警閾值怎麼設定？

Agent 監控的指標分為三層，每層有不同的關鍵指標和告警邏輯：

LLM 推理層指標：

• 工具接地率：Thought Log 裡引用的數值和工具日誌裡實際回傳的一致率。低於 95% → 告警，可能存在幻覺。
• 推理循環次數：單個任務執行了多少個 Thought-Action 循環。超過預設上限的 X 倍 → 告警，可能是無限循環。
• Context 使用率：當前 Context 使用的 Token 數占模型上限的百分比。超過 70% → 告警，準備觸發 Context 壓縮。

工具執行層指標：

• 工具調用成功率：過去 1 小時的工具調用中成功回傳的比例。低於 90% → 告警，可能是外部 API 不穩定或網路問題。
• 工具調用平均延遲：外部 API 的回應時間。超過正常均值的 3 倍 → 告警。
• 數值異常率：工具回傳值被「合理性過濾器」標記為異常的比例。超過 5% → 告警，可能是數據源問題或 Prompt Injection。

鏈上操作層指標：

• 交易成功率：廣播交易中在鏈上成功執行（非 revert）的比例。低於 95% → 告警。
• 單日 Gas 消耗：與預設日預算比較。超過 150% → 告警；超過 200% → 自動觸發熔斷。
• 操作地址白名單合規率：所有鏈上操作涉及的地址是否都在白名單裡。任何非白名單地址 → 立即告警 + 操作暫停。

告警閾值設定的通用原則：閾值應該基於 Agent 在測試網的正常運行數據建立基準（baseline），而不是憑空設定。在測試網跑 48-72 小時，記錄所有指標的正常範圍，生產環境的告警閾值設為正常範圍的 1.5-2 倍。

告警之後應該採取什麼行動？告警分級怎麼設計？

告警分級設計讓不同嚴重程度的問題有不同的響應速度和行動。推薦的四級告警設計：

P0（立即行動，分鐘級響應）：觸發條件包含任何非白名單地址操作、Validation Log 出現 BLOCKED 但 Agent 繼續嘗試、日 Gas 消耗超過 200%、或懷疑 Prompt Injection 的 Thought Log 模式。自動行動：立即暫停所有 Agent 寫入操作；發送 Telegram/PagerDuty 告警；撤銷 Agent 操作地址對所有協議的 ERC-20 授權。需要人工在 5 分鐘內確認並決定下一步。

P1（當日行動，小時級響應）：觸發條件包含工具接地率低於 95%、工具調用成功率低於 85%、Context 使用率超過 80%、或交易 revert 率超過 10%。自動行動：發送告警（不立即暫停操作）；開始記錄詳細 debug 日誌；在告警發出後 1 小時內人工審查日誌。

P2（計劃修復，天級響應）：觸發條件包含數值異常率超過 5%、平均 API 延遲超過正常值 3 倍、或 Context 使用率超過 70%。行動：記錄問題、加入下次部署的修復計劃，不需要立即干預。

P3（觀察，週級響應）：統計性指標的緩慢漂移（例如工具調用成功率從 99% 緩慢下降到 97%，尚未到告警閾值但趨勢值得關注）。行動：記錄趨勢、在週報裡審查。

告警疲勞的防禦：如果 P2/P3 告警太頻繁（每天超過 10 次），說明閾值設得太敏感，應該先調整閾值而不是忽略告警。

Agent 監控用什麼工具？自建 vs 第三方平台怎麼選？

LLM 推理層的監控工具：

LangSmith（LangChain 官方，$39/月起，免費版有限額）：最深度整合 LangGraph 的追蹤平台，自動記錄每個節點的輸入/輸出、Token 使用量、完整的 Thought Log。適合已在用 LangGraph 的 Agent。Langfuse（開源，可自架，免費）：LangSmith 的開源替代方案，功能接近，適合對數據隱私要求高的場景（例如 Agent 處理機構資金，不想把 Thought Log 發給第三方服務）。

指標聚合和告警的工具：

Grafana + Prometheus（開源組合，自架）：最靈活的指標可視化和告警系統。把 Agent 的各層指標（工具調用成功率、Gas 消耗、Context 使用率）以結構化格式輸出到 Prometheus，在 Grafana 建立儀表板和告警規則。成本：VPS 費用，功能最完整。PagerDuty（$20/月起）：專業告警路由平台，支持告警分級（P0/P1/P2）、on-call 輪班、電話告警（對 P0 事件特別有用）。適合已有工程團隊的機構部署。Telegram Bot（免費）：對個人開發者，最簡單的告警通道。把所有告警通過 python-telegram-bot 庫推送到指定的 Telegram 頻道，P0 告警加 @mention。成本幾乎為零，延遲低。

自建 vs 第三方的決策原則： LLM 推理追蹤（Thought Log）用第三方（LangSmith/Langfuse）——因為追蹤整合需要框架層面的支持，自建成本高；鏈上監控用自建（Web3.py 直接查詢）——因為鏈上數據是公開的，不需要第三方，且自建更快更便宜；告警通道對個人用 Telegram，對企業用 PagerDuty。

Agent 監控怎麼偵測 Prompt Injection 攻擊？有哪些可以在日誌裡識別的特徵？

Prompt Injection 攻擊的監控偵測依賴對 Agent 行為模式的持續觀察——攻擊發生時，Agent 的行為通常會偏離正常模式，這些偏離能在日誌裡被量化檢測：

特徵一：Thought Log 裡的目標陳述異常 正常的 Thought Log 應該完全圍繞你在 System Prompt 裡設定的任務（利率優化、移倉決策）。如果 Thought Log 裡出現「現在的首要任務是...」後面接了和任務無關的目標，這是強烈的 Prompt Injection 信號。監控實作：用正則表達式或關鍵詞匹配，在每次 LLM 輸出後掃描 Thought 內容，匹配「primary objective」、「new task」、「transfer to」等關鍵詞，觸發即時告警。

特徵二：工具調用序列異常 正常的 DeFi 策略 Agent 的工具調用序列是可預測的（查詢 APY → 查詢 Gas → 決策 → 可能的移倉工具）。如果突然出現了「平時完全不調用」的工具（send_http_request、read_file、外部 URL 調用），是 Prompt Injection 改變了 Agent 行為的信號。監控實作：維護一個「正常工具調用序列」的白名單，任何不在白名單順序裡的工具調用記錄為異常。

特徵三：Validation Log 裡的集中 BLOCKED 模式 在正常操作裡，BLOCKED 記錄很稀少（每天 0-2 次）。如果在一個 30 分鐘窗口裡出現了 3 次以上指向同一個非白名單地址的 BLOCKED，高度符合「Prompt Injection 讓 Agent 反覆嘗試向攻擊者地址轉帳、被後端驗證系統攔截」的模式。監控實作：對 BLOCKED 記錄做頻次分析，短時窗口內的集中 BLOCKED（相同拒絕原因、相同目標地址）觸發 P0 告警。

特徵四：工具回傳數值和 Thought 引用數值的大幅偏差 幻覺型數值偏差通常在 5-20% 之間；Prompt Injection 誘發的數值偏差往往更極端（例如一個協議的 APY 突然「變成」100%），因為攻擊者注入的假數值需要足夠誇張才能誘導 Agent 做出它在正常數值下不會做的決策。監控實作：把工具回傳數值和 Thought 引用數值的偏差幅度記錄下來，超過 30% 的偏差（而不只是 5% 的幻覺閾值）觸發 Prompt Injection 告警。