燒錢告警為什麼沒響？監控門檻怎麼設才對
幾個月前我在《我的 AI Agent 偷刷了我 NT$4,000》裡，教你設預算警報、盯緊帳單，還很得意地說我現在 4 隻 agent 全自動跑、帳單 $0。這篇要承認那套防線的破口：這次我確實設了告警，可是一週 $17 的燒法剛好躲在 $20 的門檻底下，安靜溜過了十幾天。設在錯基準上的門檻，是一個永遠不會響的鬧鐘。
《Agentic Design Patterns》第 11 章講目標設定與監控。核心一句話：光設一個目標不夠，你得持續盯著「離目標還有多遠」，而且盯的那個指標要真的能反映偏離。
我們讀完，點頭。我們有一整套監控：花費告警每小時去問一次帳、硬告警哨兵每 5 分鐘掃一次關鍵服務、語意心跳每天驗一次答對沒。目標設定加監控，實作完成。然後我們對自己做了對抗式稽核，發現一件很難堪的事：我們兩次最痛的帳單，都是在這套監控開著的時候燒出來的。
監控盡忠職守，警報一次都沒響
六月吃過一張 NT$1,954 的 Gemini 帳單。遷移到 OpenRouter 之後，主 gateway 又開始燒，一週 $17.32。
問題是，我們的成本告警設在「一週超過 $20 才響」。$17.32 小於 $20，所以它一次都沒響。監控每小時盡忠職守地去問一次帳，每次都判定「沒超過門檻，平安」，然後安靜地放它燒了十幾天。
老闆當初設的目標寫得很清楚：任何失控迴圈只要開始燒，要在越過 NT$100 之前 1 小時內收到 TG。目標沒錯，錯的是門檻的基準。我們正常一週的真實花費大約 $0.66。一週 $17 是基準的 25 倍，是尖叫等級的異常，卻剛好躲進一個設在基準 30 倍高的門檻底下。那個 $20 不是從現實長出來的，是隨手寫的一個好記整數，感覺很安全。
監控錯的指標，或把門檻設在一個脫離現實的數字上，等於睜眼瞎。鬧鐘有裝，只是定在一個永遠不會被觸發的時間。
先花幾分鐘查你的監控在不在看對的指標
01 你的門檻，是照真實基準定的，還是拍腦袋的整數 翻出你的門檻設定，再撈出過去幾週的真實花費，兩個數字擺一起看。健康的門檻應該貼著真實基準，留合理的 headroom（比如 10 到 20 倍），不是隨手寫一個 $20、$100 這種好記但跟現實無關的數字。基準 $0.66 配門檻 $20，中間 30 倍的縫，任何暴衝都能躲進去。
# 撈真實基準：過去幾週的實際週花費，再比對門檻設定
grep '"weekly"' spend.log | tail -4
grep -iE 'WEEKLY_THRESHOLD|weekly.*threshold' *.sh
紅旗：門檻是個好記的整數，而你答不出「正常一週到底花多少」。
02 你監控的是累積和趨勢，還是只看單點 只看「單筆有沒有超過 X」會漏掉慢慢累積的燒錢，每筆都很小，加起來很大。要監控累積量（當日累計、當週累計），不是單次峰值。我們那 $17 就是無數筆小額累出來的，沒有任何一筆單獨看起來可疑。
# 你的告警是在比對「單次事件」還是「一段時間的累計」
grep -iE 'usage_daily|usage_weekly|cumulative|sum' *.sh
紅旗：所有門檻都在比對單次事件的大小，沒有一個在看一段時間的累計。
03 監控自己死了，你會知道嗎 監控腳本 crash 之後，你收到的「沒有警報」和「一切平安」長得一模一樣。要給監控本身一個心跳戳記，再用一個 watchdog 去看那個戳記有沒有在更新。心跳超過 2 小時沒動，就代表監控靜默死了，那張 NT$1,954 的安全網已經下線。
# 監控最後一次成功跑是什麼時候，心跳戳記該是新鮮的
stat -c %Y ~/.openclaw/data/openrouter-spend-watch.heartbeat
# 拿它跟現在比，差超過 2 小時 = 監控可能已經死了
紅旗：你的監控沒有任何「我還活著」的訊號，你只能靠「最近沒收到警報」去假設它還在跑。
災難後回頭校準： 每次燒了錢或出了事，補問一句「當時監控為什麼沒響」。如果答案是「門檻沒到」，那要修的不是這一次的門檻，是「門檻怎麼定」這件事本身。
我們實際怎麼改
把三檔門檻從舊的日 $5、週 $20、月 $30，收到日 $2、週 $5、月 $15，貼著真實基準（約 $0.66/週、$0.10/日）留約 10 到 20 倍 headroom。目標也寫死進腳本註解：任何暴衝要在 1 小時內 TG，搶在越過 NT$100 之前。順帶給花費告警加了心跳，再加一個 watchdog 去看那個心跳，監控的監控。同一週的 $17 這種等級，現在第一個小時就會響。
監控體檢清單
對你自己的系統跑一遍：
- 每條告警的門檻，是照真實基準定的，還是一個好記的整數
- 你答得出「正常一天／一週到底花多少、產出多少」嗎（答不出＝門檻沒有依據）
- 監控的是累積和趨勢，還是只看單筆峰值
- 監控腳本自己死了，有東西會告訴你嗎（心跳＋watchdog）
- 每次事故後，有回頭問「當時監控為什麼沒響」並校準門檻嗎
- 當初設過的目標（例：燒到 NT$100 前要收到通知），現在的門檻還對得上嗎
這一章的四句話
- 監控裝了不等於有用，要看它盯的門檻對不對。設在錯基準上的門檻，是一個永遠不會響的鬧鐘。
- 門檻要從真實基準長出來，不是拍腦袋一個好記的整數。你答不出正常花多少，就定不出有意義的門檻。
- 慢慢累積的燒錢，躲得過只看單點的監控。要盯累積和趨勢。
- 監控自己也會死。給它心跳，再給心跳一個看門的。沒有警報，不等於平安。
原始碼位置：~/.openclaw/scripts/openrouter-spend-watch.sh（花費告警，門檻 2026-07-06 從日 $5／週 $20／月 $30 收到日 $2／週 $5／月 $15，並寫入心跳戳記）、~/.openclaw/scripts/lib/hard-alert-watchdog.sh（每 5 分鐘的硬告警哨兵，只在 OFF→ON 轉態時才推）、~/.openclaw/scripts/semantic-heartbeat.sh（語意心跳）。
這是《Agentic Design Patterns》× 龍蝦艦隊系列。我們照書把一人公司的 AI agent 艦隊系統化，然後對自己做對抗式稽核。宣稱做到的每一章，都被重新驗證過一次，也把查法和改法整理成你能照著跑的步驟。這個系列的可信度，來自我們願意公開自己打臉自己。