2026 年 5 月 4 日，早上七點多。我半睜著眼滑手機，看到一封 API 服務商的費用通知。

過去 24 小時：約 $40 USD。

$40 是我平常好幾個月的量，在一夜之間燒完。而這一夜我在睡覺，沒有下任何指令、沒有部署任何新功能、沒有跑任何大任務。

第一反應是「被盜用了？」。查了 log 之後發現更難堪的事實：沒有入侵、沒有 bug、每一分錢都是我的系統「按照設定」花掉的。它做的每件事都符合設定——問題是那套設定本身就是一台碎鈔機，只是之前一直沒被觸發。

而那套設定是我拍板的。程式碼誰打的不重要，規則是我定的、我沒審過、我按下部署——這筆帳只能算在我頭上。

這篇是整個系列我最想寫的一篇。不是因為 $40 很多（它就是一頓聚餐的錢），而是因為這次事故完美示範了 LLM 系統一種獨有的故障型態：成本故障。服務沒掛、資料沒錯、功能全部正常——只是每一步都在燒錢。

事故時間軸

拼湊 log 之後，那一夜大概是這樣：

注意：沒有任何一個環節「壞掉」。fallback 忠實地 fallback 了，重試忠實地重試了，排程忠實地排程了。三個各自合理的機制，串起來變成一台自動印鈔機——印給 API 服務商。

根因鏈：三個「預設值」的共謀

**根因①：預設值偏貴。**建 job 時如果沒明確指定模型，系統會用一個「品質優先」的預設——Claude 旗艦。我建了三十幾個 job，好幾個是隨手建的，根本沒寫 model 欄位。平常它們用 Gemini 跑得好好的？不，平常它們就在用 Claude，只是單次費用小到我沒注意。

而且要誠實說，這個「偏貴的預設」有一半是我自己的心態，不全是框架的鍋：那陣子我剛開始玩 OpenClaw，什麼都不熟，想法很直覺——Sonnet 比較聰明，用好一點的模型，遇到問題說不定它自己就解掉了。等於拿模型的智力，當新手期的保險。後來回頭看，這份保險買錯了地方：**聰明模型解決不了錯的設定——它只會用更貴的方式，把錯的設定忠實跑完。**新手期真正需要的是更保守的預設，不是更聰明的執行者。

根因②：fallback 是升級鏈，不是降級鏈。這裡要講清楚一件事：fallback 不是我寫的功能，是框架控制介面上的一個設定——每個排程任務都能挑一顆「備援模型」，主要模型失敗時自動改用。我當初在那個下拉選單裡的想法很天真：「Gemini 掛了，換 Claude 頂上，服務不中斷。」而那個畫面上只有模型名稱，沒有價格。聽起來像高可用設計，實際上是把『故障』和『花大錢』用自動化焊死在一起。深夜 Gemini 的 API 一抖，所有任務齊刷刷升級到 Claude——而深夜正是我的排程最密集的時段（記憶整合、快取更新、各種巡檢）。

**根因③：重試無上限。**部分任務失敗後重試，重試又遇到不穩定，再重試。每一次重試都是完整的 LLM 呼叫，都是錢。timeout 又設得寬鬆，單次呼叫可以掛著跑好幾分鐘、吞掉大量 token 才失敗。

三個根因有一個共同點：**沒有一個是經過計算的決策。**最接近「決策」的那個——用聰明模型當保險——也是憑感覺買的保險，從沒算過保費。這就是這次事故最大的教訓——在 LLM 系統裡，預設值不是無害的出廠設定，預設值就是你的風險邊界。傳統系統的錯誤設定頂多讓服務變慢變爛；LLM 系統的錯誤設定直接連著你的信用卡。

止血三刀＋系統外的第四刀

當天早上我做了四件事，順序很重要——先斷血，再究因：

**第一刀：fallbacks 全部清空。**所有排程任務的 fallback 一律改成空陣列。任務失敗就失敗，發告警等人看。這一刀砍掉的是「故障自動變貴」的通路。有人會問：那可用性呢？答案回到 Day 21 的可靠性曲線——晨報失敗一次的代價是我晚點看到，fallback 失控一次的代價是這一夜。這不是取捨，是碾壓。

第二刀：全面降到便宜模型。逐一盤點所有 job：純文字生成的一律改 Gemini（免費額度）；需要執行工具的用 Claude Haiku（低價位）；Claude 旗艦在排程系統裡全面禁用，只保留給我本人的互動側（Claude Code／Cowork）。這一步順便發現了好幾個「不知道自己在用 Claude 旗艦」的 job。

**第三刀：timeout 全面加蓋。**一般任務 ≤ 120 秒，重試次數明確設限。跑不完的任務不是調大 timeout，是回去檢討任務設計。

還有第四刀，砍在系統外面：API key 平台端本來就能控管費用。供應商後台可以直接對 key 設消費上限——打到就停，不商量。那天早上我把上限壓到很低，寧可誤傷也不再讓它無界。這一刀最容易被忘記，因為它不在你的程式碼裡、不在你的設定檔裡，是別人網站上的一個表單欄位；但它恰好是四刀裡唯一一道不依賴你自己系統還活著的閘——前三刀防的是我再犯錯，第四刀防的是「我防不到的那種」。

四刀下去，費用當天就回到地板。而且有趣的是：**降級之後，沒有任何一個排程任務的產出品質讓我覺得變差。**每日晨報和提醒類的文字，Gemini 寫得跟 Claude 旗艦沒有可感知的差別——我之前付的是十倍價差，買的是我根本用不到的智力餘裕。

我踩過的坑（就是本篇全部）

再補一個結構性反省：為什麼一夜之後我才知道？因為我的監控全部在看「服務健康」，沒有任何一雙眼睛在看「成本」。事故後的常設防線有兩道。第一道是上面那第四刀的完整版：平台端消費上限＋費用告警（門檻壓到很低，寧可被吵），後來又補上自動儲值湊成一對——上限擋住失控的上緣（打到就斷，$40 那種夜晚頂多燒到上限）、自動儲值保住正常運作的下緣（額度歸零自動回填，不會平白斷糧）。兩個都設，才既不會爆錶、也不會哪天醒來發現系統因為餘額見底而安靜地死了一夜。這裡容易誤會成互相抵銷，講清楚：兩個機制活在不同層——自動儲值管的是「餘額」（見底就回填，服務不斷炊），消費上限管的是「月累計」（不管餘額還剩多少，當月花到線就是停）。儲值回填得了餘額，回填不了上限。第二道，在月度品質報告裡把用量趨勢列為一級指標。**成本是 LLM 系統的核心健康指標，和 uptime 同級。**這句話我用 $40 買的，送給你。

止血之後：錢平常到底燒在哪？

那三刀處理的是異常。但事故過後我才去問一個更基本的問題：沒有異常的日子，錢是怎麼花掉的？

答案完全不是我以為的。

一次呼叫的花費可以拆成四塊：送進去的問題（Input）、它回你的答案（Output）、把身分設定寫進快取（Cache Write）、以及命中快取後的讀取（Cache Read）。

直覺會以為大頭是 Output——它「講了那麼多話」。實際上壓倒性的大頭是 Cache Write，而且不是多一點，是高出一個量級。用一句話講這件事的荒謬之處：

我為「讓它記得自己是誰」付的錢，遠多於為「它到底說了什麼」付的錢。

原因不難懂：一次回答頂多幾百個 token，而人格設定 + 記憶 + 工具定義動輒幾萬個——而且每一次冷啟動都要重寫一遍。快取有效期內再呼叫會便宜一個數量級，但排程任務彼此隔了幾十分鐘，幾乎每一次都是冷的。

所以省錢的最高 ROI 不是縮短輸出，而是降低冷啟動次數。這個結論跟金額無關，也跟你用哪家模型無關——只要你的 Agent 有一份很長的身分設定，它就成立。

而「是誰在冷啟動」，我整個猜錯

知道「冷啟動最貴」之後，下一題是：那到底是誰在冷啟動？

我當時的診斷是：六個角色 Agent 各有一套設定、各付各的；再加上每晚的記憶整合要吃大量上下文。聽起來很合理——多個 Agent、多套設定、多次寫入。

後來真的去逐筆拆帳，這個診斷兩半都不對：

• 不是六個平均分攤，是一隻吃掉絕大部分。
• **記憶整合根本沒有花錢。**它早就被搬到 Gemini 的免費額度上跑了。我把一個零成本的東西列為成本大戶，只因為它「看起來很重」。

而第一點還有一個更難堪的細節：吃掉絕大部分的那一隻，不在「六個」裡面。

我整個系列都說「六個 Agent」，但這套系統實際上跑著七隻。第七隻是框架預設的那一個——所有沒有指定角色的排程都由它執行。它沒有自己的資料夾、沒有專屬的人格檔，所以我畫架構圖時從來沒把它畫進去。

而它正好是最貴的那一隻，原因也很合理：六個角色各自讀自己資料夾裡那份精簡的設定，**而預設那隻讀的是 workspace 根目錄——那裡放的是全系統共用的規則與長期記憶，是整包設定裡最大的一份。**它上下文最長，又整天被喚醒，兩個條件疊在一起。

這一段的教訓比省下來的錢有價值得多，而且有兩層：

1. **「多個東西」聽起來永遠比「一個東西」貴，但成本幾乎從來不是平均分佈的。**照著「六個 Agent」那個直覺，我本來會去做「減少 Agent 數量」——那會拆掉一個運作良好的架構，然後省下最小的那一塊。
2. **你數得出來的東西，通常不是問題所在。**六個角色是我設計的，所以我數得出來、畫得出來、也第一個懷疑它們。那隻預設的是框架給的，我從來沒把它當成一個「東西」——直到帳單指著它。

這也是為什麼下一節那四個問題有順序：先確認錢花在哪一塊，再確認是誰花的。倒過來做，你會很有信心地優化錯的東西。

那到底要怎麼看成本？兩份匯出檔就夠了

上面那句「沒有任何一雙眼睛在看成本」，後來變成我每隔一陣子就會做一次的事。這一節把方法寫出來，你可以直接照做——而且不用寫程式，把檔案丟給 AI 幫你拆就好。

你需要兩份匯出檔，缺一不可：

第一份：供應商後台的用量匯出。多數 API 供應商的 Console 都能匯出逐日用量。關鍵是欄位要夠細——至少要有輸入、輸出、快取寫入、快取讀取的分項，只有一個總數是沒得分析的。這是唯一的權威來源，帳單就是照它算的。

第二份：OpenClaw（我的 Agent 框架）自己的 usage 匯出。供應商只知道「有人用了多少」，不知道是哪個 Agent、哪個排程用的。歸屬只有框架這一側有。⚠️ 但它多半只給 token、不給金額——因為它沒有牌價表，金額欄位常常一路是零。

拿到之後，問 AI 這四個問題，順序有意義：

1. 「把成本拆成快取寫入／快取讀取／輸出／輸入四塊，各佔多少？」
   → 這題決定你接下來要優化什麼。如果輸出佔比很低，所有「叫它講短一點」的努力都是白費的。
2. 「逐個 Agent、逐個排程排序，誰花最多？」
   → 答案十之八九跟直覺不一樣。我自己就猜錯過——以為是「Agent 太多」，實際是其中一隻獨大。
3. 「快取寫入是短期還是長期 TTL？平均每寫一次被讀幾次？」
   → 如果幾乎每次都是冷寫入，換更長的快取期限可能比改架構有效得多。
4. 「一次冷啟動實際寫進去的內容，組成是什麼？」
   → 最容易被跳過，但可能最有價值。很多人（包括我）以為大宗是自己寫的那些人格與規則檔，實際上它們可能只佔零頭——真正的重量常常在工具定義上，而工具是可以按 Agent 裁剪的。

三個一定會踩到的坑，先講在前面：

• **時區。**供應商多半以 UTC 分日，你的系統可能用本地時區。逐日對不上是正常的，不代表你的成本模型壞了——要比就比總量。我第一次對帳時逐日差到七成，總量卻只差百分之一，差點以為自己算錯。
• **金額欄位可能是空的。別把「成本顯示 0」當成「沒花錢」。**框架端給 token 不給錢很常見，那只代表它不知道價格。
• **資料留存比你以為的短。**等你想查的時候才發現只剩最近兩週，那就永遠查不了了。今天就去看一眼你的用量資料能回溯多久——這件事成本是零，但它決定你未來還能不能回答問題。

說到底，這一節存在的理由就是本篇的事故：**我不是不會查，是從來沒想過要查。**等到帳單自己來提醒你，那筆錢已經花掉了。

小結＋明日預告

$40 事故的三行總結：LLM 系統的預設值就是風險邊界；fallback 升級鏈是把故障和花錢焊在一起；成本監控和可用性監控同等重要。

止血只是應急。接下來兩天講制度化的解法：明天先講「三層模型路由」——不是每個任務都配得上最聰明的模型，用旗艦模型跑「每天提醒喝水」，就像開超跑去倒垃圾。

🔑 這篇的關鍵字
LLM 系統獨有的故障型態：成本故障（服務全綠、資料正確、只是一直在燒錢）
根因三件套：預設值偏貴（沒指定 model 就用 Claude 旗艦）· fallback 升級鏈（Gemini 故障自動升級成 Claude）· 重試沒有上限
止血：fallbacks: [] · 排程模型鎖死（文字歸 Gemini、工具歸 Haiku、旗艦只留互動）· timeout 上限 · API key 平台端消費上限（第四刀，系統外，唯一不依賴自己系統的那道）
provider 後台設消費上限＋自動儲值＋費用告警——上限擋爆錶、儲值擋斷糧，且這是唯一一道不依賴你自己系統還活著的防線
平常的成本形狀：大頭是 Cache Write 不是 Output——為「讓它記得自己是誰」付的錢遠多於「它說了什麼」 · 所以省錢的最高 ROI 是減少冷啟動次數，不是縮短輸出
成本幾乎從不平均分佈：以為六個 Agent 分攤，實際是一隻不在架構圖上的預設 Agent 獨大（它讀 workspace 根目錄那份最大的設定）· 記憶整合零成本（早就搬去 Gemini 免費額度）· 你數得出來的東西，通常不是問題所在
自己查的方法：兩份匯出檔（供應商後台 = 權威金額；框架端 = 歸屬但常常只有 token 沒有金額）→ 問 AI 四題（成本四塊佔比 → 誰花最多 → 快取 TTL → 冷啟動組成）· 三個坑：時區導致逐日對不上（要比總量）、金額欄位為 0 不等於沒花錢、資料留存比你以為的短

我是一名金融業資訊工程師，這是我半年來在家自架 AI Agent 系統的實錄。