怎麼查你的 AI agent 是不是在偷偷燒錢
幾個月前我在《AI Agent 省 Token 實戰》裡，說我們審計過、把四隻 agent 的浪費砍掉 40%，還把 context 稱作最大的隱形成本。結果這一章就是打臉那篇：主 gateway 一週燒 $17，其中 98.8% 的錢，就花在我當初宣稱已經治好的那個病，讓 agent 一遍遍重讀對話歷史。
《Agentic Design Patterns》第 16 章講資源感知優化。核心一句話：agent 的每一筆成本都要能被看見，模型的選擇要跟著任務難度走，不是愈大愈好。
我們讀完，點頭，在腦裡打勾：這個我們有做。有成本告警、有三層模型 fallback、有花費監控腳本。資源感知，實作完成。然後我們對自己做了一次對抗式稽核。這一章的真相，是整個系列裡最痛的一刀。
帳本攤開來的樣子
遷移到 OpenRouter 之後，主 gateway 一週燒掉 $17。聽起來不多，直到你翻開它自己記的帳：702K 輸入 token，只換來 8K 輸出。
98.8% 的錢，花在一遍遍重讀對話歷史。真正產出內容的，佔 1.2%。
你打一個字「蛤」，這個 agent 會打包 5,600 個 token 送出去，同一段歷史最多重讀 60 遍。它不是在思考，是在反芻。這還不是第一次。六月我們吃過一張 NT$1,954 的 Gemini 帳單，同一個病：量沒人看著，就自己長。
先花三分鐘查你自己的 agent
01 查空轉比：輸入 token 對輸出 token 健康的比例大約在 1:1 到 3:1。如果像我們一樣衝到 88:1，就是在反芻歷史。OpenRouter 後台的 Activity 頁直接看得到；自己記帳的話，log 每次呼叫的 prompt_tokens 和 completion_tokens 加總比一比。
# 從自己的成本 log 抓最近一天的 in/out 總和
grep '"usage"' cost.log | jq -s 'map(.prompt_tokens)|add', 'map(.completion_tokens)|add'
紅旗：輸入是輸出的 10 倍以上，你在為重讀歷史付錢。
02 查 max_tokens 有沒有設上限 翻你的 agent 設定，找 max_tokens。沒設、或設成模型極限（幾萬），就是給模型一張空白支票，每次請求都預約最大額度。它該設成你真正需要的輸出長度：聊天 bot 500 到 1000 夠用，寫長文 2000 到 4000。
grep -niE 'max_tokens|max_output' config.yaml .env
紅旗：查不到、是 null、或大於 8192。
03 查有沒有崩潰重啟迴圈 一直崩、一直被系統救活的服務，每次復活都重跑一輪、重燒一次。看你的服務被重啟過幾次，數字大得離譜就是有東西在無聲地崩。
systemctl --user show 你的服務名 -p NRestarts
# 或翻 journal 找 crash loop
journalctl --user -u 你的服務名 | grep -c 'Started'
紅旗：一兩天內重啟數十上百次。
我們翻 log 翻出來的
三個檢查我們自己跑了一遍，結果全中。OpenRouter 回的是 HTTP 402，訊息很直白：
HTTP 402 This request requires more credits, or fewer max_tokens.
You requested up to 65535 tokens, but can only afford 15650.
問題就在那個 65,535，是 max_tokens 沒設上限時的模型極限。每送一次請求都先預約 6.5 萬 token 的額度，餘額歸零後每個請求被 402 打回，gateway 當場崩潰。而它跑在 systemd 底下、設了自動重啟，一崩就被救活。十二天裡復活了 403 次，每次都重連重載重跑。
值得講清楚它「不是」什麼：cron 排程空的、看板任務空的，沒有失控的定時炸彈。就是一行沒設上限的 max_tokens，配上按量計費，加一個自我復活的崩潰迴圈。便宜的模型也架不住這種燒法。
照著改：三刀砍下去
對照你剛查到的問題，設定這樣改。這是我們實際動的三刀，你可以直接照抄再依自己的需求調數字。
# 改前：空白支票
max_tokens: null # 等於模型極限 65535
max_turns: 60 # 單一任務來回上限
history_limit: 400 # 每次帶進的歷史則數
# 改後：設成你真正需要的量
max_tokens: 4096 # 聊天 bot 這樣就夠
max_turns: 20
history_limit: 80
然後做這件事，不然等於沒改： 改完重啟，翻 log 確認新值真的生效。我們就踩了這個坑。config 裡 max_turns 明明改成 20，log 卻顯示 agent 實際跑 90 輪。那個上限被 .env 的環境變數蓋掉了，config 根本沒被讀進去。
# 重啟後從 log 撈實際生效的值，別相信 config 檔
grep -iE 'max_iterations|max_turns|budget' gateway.log | tail -3
最後一刀，也是最狠的
不是調參數，是直接關掉主 agent。一個花的比產出還多的 agent，留著它每天反芻、每次崩潰復活，不如關掉。資源感知優化到最後，不是把每個 agent 都調到最省，是承認有些 agent 現在不值得開。
資源感知體檢清單
對你自己的系統跑一遍：
- 每次 API 呼叫的 input / output token，有記進 log 嗎
- max_tokens 設了嗎，是需要的長度還是模型極限
- 對話輪數、歷史長度，各有上限嗎
- 成本告警的門檻夠低嗎（我們一週 $17 就從 $20 的門檻底下溜過去了，後來收到 $5）
- 改完設定，有回 log 確認真的生效，不是只信 config 檔嗎
- 有沒有一個花的比產出多、其實該關掉的 agent
這一章的四句話
- 看不見的成本，就是還沒爆的帳單。每筆呼叫的花費都要能被看見。
- 萬事設上限。max_tokens、輪數、歷史，任何一個不設，就是空白支票。
- 改完要驗證生效。config 改了、log 沒吃到，等於沒改。
- 花的比產出多的 agent，關掉不丟臉。那才是資源感知。
原始碼位置：~/.openclaw/scripts/ollama-helper.sh（成本紀錄）、llm-cost-report.sh、openrouter-spend-watch.sh（監控門檻已從 $20/週 收到 $5/週）、~/hermes-bench/data/config.yaml（三刀所在）。
這是《Agentic Design Patterns》× 龍蝦艦隊系列。我們照書把一人公司的 AI agent 艦隊系統化，然後對自己做對抗式稽核。宣稱做到的每一章，都被重新驗證過一次，也把查法和改法整理成你能照著跑的步驟。這個系列的可信度，來自我們願意公開自己打臉自己。