AI agent 部署 6 個月「成本飆 3 倍」真相：token、infra、人工監控 3 段隱形帳完整拆解 + 4 個降本訊號——中小企業老闆 60 天止血行動清單

最近我們在追蹤 Anthropic 6/4 那篇呼籲暫停 AI 開發的聲明，順手翻了我們自己內部 20+ 個 AI 流程的 token 帳單——結果讓人頗不舒服。六個月前每月大約 $380 美元，現在爬到 $1,140，接近三倍。沒有哪一天特別異常，沒有哪個流程明顯出錯，帳單就這樣靜靜地漲上去了。

這件事讓我們開始系統性地拆帳。發現問題不在模型單價，而在三段隱形帳的疊加：token 用量悄悄膨脹、infra 的 minimum capacity 在你以為 idle 的時候繼續跑、以及一個你可能從來沒算過的人工監控成本。這篇文章把這三段帳完整拆給你看，並且給出 4 個降本訊號與 60 天止血行動清單——如果你正在評估 AI agent 的 TCO，或者帳單已經開始讓你皺眉，這篇值得從頭讀完。

PoC 跑得好，上線 6 個月帳單翻 3 倍——這個落差怎麼發生的

幾乎每個導入 AI agent 的中小企業都會經歷同一個弧線：PoC 階段一切美好，真實數字讓採購主管點頭，上線後三個月帳單開始爬坡，六個月後財務部門開始問「這筆錢到底買了什麼」。

PoC 的成本之所以漂亮，原因很結構性。測試環境的 prompt 是手工精修的，context 短、retry 少、流量低、沒有真實用戶行為的邊界情境。上線之後這四個條件全部失效：prompt 因為要處理更複雜的業務需求開始膨脹，context window 因為上下文累積開始漂移，retry 因為生產環境的不穩定開始激增，agent loop 因為真實任務的不確定性開始無限展開。

這四個問題任何一個單獨出現，帳單大約漲 20-40%。四個同時發生，300% 不是意外，是必然。

根據 Gartner 2025 AI Infrastructure Cost Report，超過 60% 的企業在部署 AI workload 後 6 個月內遭遇實際成本超出預測 50% 以上的情況，其中中小企業比例更高，因為他們缺乏專職的 FinOps 角色做持續監控。

如果你現在正在評估 AI agent 的六個月預算，可以先看看這篇關於 Microsoft 2026 capex $190B 與記憶體儲存價格飆升對中小企業 TCO 的影響——廠商側的成本壓力會直接傳導到你的帳單。

token 用量爆量的 4 個源頭：prompt 通膨、context window 漂移、retry 浪費、agent loop

我們的判斷是——大部分中小企業 AI 成本飆 3 倍，根本原因是「沒有人在管 prompt 長度」。這不是技術問題，是流程與責任歸屬問題。

以下是 token 用量爆量最常見的 4 個源頭，以及每個源頭的典型數字：

prompt 通膨最容易被忽略，因為它發生得很自然。開發團隊為了讓模型處理更多邊界案例，不斷在 system prompt 裡追加 examples 和 instructions。六個月內 system prompt 從 800 tokens 長到 2,400 tokens 是常態，但很少有人注意到這件事讓每一次 API call 的基礎成本直接乘以三倍。

context window 漂移則更隱蔽。很多 agent 框架預設會把完整的對話歷史塞入 context，PoC 階段對話短所以沒問題，但上線後用戶的真實對話動輒 20-30 輪，每輪都帶著前面的完整記錄，token 數以指數上升。解法是實作 sliding window 或 summary compression，但這需要工程時間投入。

retry 浪費最容易量化但也最容易被合理化。18% 的 retry rate 意味著每 100 次 API call 裡有 18 次是多付的，而且通常是在任務失敗後的全量重試，成本比首次 call 更高因為帶著錯誤訊息的 context。

agent loop 是最危險的。當 agent 的 termination 條件不清晰，它會繼續呼叫工具直到 max_steps 觸發或 timeout。我們曾見過一個任務跑 47 步才停下來，而 PoC 預估是 5 步——那一個任務的 token 成本超過整個 PoC 月均的 10%。

想了解不同 AI 詞彙背後的成本邏輯，可以參考這篇 老闆級 AI 詞彙對照表：RAG、MCP、context window、embedding 完整解釋，context window 與 token 的關係在那裡有完整說明。

雲端 infra autoscaling 陷阱：你以為 idle 不收錢，其實 minimum capacity 在跑

token 帳單只是第一段。第二段隱形帳藏在 infra 裡，而且它在你睡覺的時候也在燒錢。

大部分 AI agent 部署在雲端容器或 serverless 環境上，工程師為了保證響應速度會設定 minimum capacity——也就是「最少保持幾個 instance 活著」。這個設定在 PoC 通常是 0 或 1，上線後因為擔心冷啟動延遲被拉高到 3-5。但這意味著即使凌晨三點完全沒有流量，你仍然在付 3-5 個 instance 的費用。

更隱蔽的是記憶體和向量資料庫的存儲費用。根據公開報導，AI 記憶體與向量存儲價格在 2025-2026 年出現明顯漲幅，這與 Microsoft $190B capex 投入 AI 基礎設施直接相關——規模化投資帶來的折舊攤銷會反映在雲端服務定價上。

一個 PoC 月成本 $50 的 infra，上線 6 個月後爬到 $380 純屬正常——即使你的流量沒有增長。解法是設定業務低峰期的 scale-to-zero 策略，以及對 log retention 設置嚴格的 TTL（7-14 天往往就夠），這兩個動作通常可以把 infra 成本壓低 40%。

你在決定自架還是 SaaS 時，infra 的隱形帳是最容易被算漏的部分。這篇 AI 預算拆解：100K / 500K / 200 萬台灣中小企業 2026 版 有三個預算規模的完整 infra 配置建議，可以對照參考。

人工監控配比：誰在看 logs、誰在改 prompt、誰在跑 evals

第三段帳是最常被完全遺漏的：人工監控成本。這不是工資表上的新增人員，而是分散在現有員工時間上的隱形稅。

一個運行中的 AI agent 系統通常需要三種人工干預：

一、log 審查員，每天花 1-2 小時翻看 agent 的輸出，找異常案例。很多時候這個角色落在業務主管身上，因為他最懂「什麼答案是對的」，但沒有人把這個時間計入 AI 系統的 TCO。

二、prompt 工程師，每週花 3-8 小時調整 prompt 以應對新的失敗案例。PoC 階段可能是開發者順手做，上線後這個工作量呈週期性爆發——通常在新功能上線後、用戶投訴高峰期或模型版本更新後。

三、eval 執行者，每月花 8-20 小時跑評估，確認系統品質沒有退化。這個角色在大部分中小企業完全缺席，直到客戶投訴才發現品質已經悄悄下滑好幾個月。

這 TWD 35,000 的隱形人力成本從來不會出現在 AI 系統的採購發票上，但它實實在在地佔用了你的員工時間。如果換算成全職當量，大約是 0.4 個 FTE——幾乎是半個人在維護這個系統。CTO 或技術主管在評估 AI agent 的 ROI 時，如果沒有把這段帳算進去，回報數字會系統性地虛高。

想了解完整的 AI agent 評估方法，包含 KPI 設定與驗收清單，可以參考這篇 AI agent 評估方法論：6 個 KPI、3 個陷阱、90 天驗收清單。

4 個降本訊號：什麼時候該砍、什麼時候該續、什麼時候該重新 PoC

帳單漲了不等於該砍掉這個 AI agent。重點是判斷成本增長是「健康的業務擴張」還是「效率惡化的警訊」。以下 4 個訊號幫你做這個判斷：

訊號一：token per task 在增長，但 task 數量沒增長。這是最清晰的效率惡化訊號。如果你每個月處理的任務數相同，但每個任務用的 token 越來越多，代表 prompt 在通膨或 context 管理出了問題，需要立即介入。目標是把 token per task 控制在 PoC 基準的 ±20% 以內。

訊號二：retry rate 超過 10%。低於 5% 是健康，5-10% 需要關注，超過 10% 代表系統在做大量無效 API 呼叫。通常原因是 output 格式要求太嚴格、timeout 設定太短，或上游資料品質下降。這個問題每修復 1 個百分點的 retry rate，平均可以省下約 1% 的 token 帳單。

訊號三：人工監控時數超過 AI 節省工時的 30%。如果 AI agent 幫你省了 100 小時的人工，但你每個月花 35 小時在監控這個 agent，這個 ROI 已經開始鬆動。一旦監控時數超過節省時數的 50%，就要認真評估這個 agent 是否值得繼續維護。

訊號四：infra 成本佔 token 成本的比例超過 80%。正常的比例是 infra 佔總 AI 成本的 20-35%。如果 infra 成本已經和 token 成本相當，代表你的 infra 嚴重過度配置，或者你的 token 用量其實非常低——後者意味著這個 agent 的使用率可能遠低於預期。

這 4 個訊號對應三種決策：只有訊號一時重構 prompt，只有訊號三時重組監控流程，四個訊號同時出現時重新 PoC 或退出。最糟糕的決定是「再觀察一個季度」——每觀察一個月，虧損就多一個月。

關於 AI 採購合約的保護機制，這篇 中小企業 AI 採購 3 道防線：PoC 合約、退出機制、KPI 賭注、60 天治理 有完整的合約保護建議。

廠商議價的 3 個時點：合約週年、模型退役、用量超約 50%

很多中小企業老闆不知道 AI API 費用是可以議價的，或者知道但不知道在哪個時間點議價最有效。以下是 3 個黃金時點：

時點一：合約週年前 60 天。這是你唯一有籌碼轉換供應商的時間窗口。在這個時點，你應該同時拿到 Claude、GPT-4o 和 Gemini 的最新報價，以及你過去 12 個月的實際用量數據。用這份數據去談量級折扣或 committed use discount，通常可以拿到 15-25% 的降價空間。

時點二：模型退役公告後 30 天內。Anthropic 官方聲明中每次模型更新都是重新議價的機會。新模型通常有更好的 token 效率，但也可能帶來遷移成本。這個時點要做的是：讓供應商保證遷移支援，或者用遷移成本作為談判籌碼換取折扣。

時點三：月用量超過合約量 50% 時。超出合約量的部分通常是 on-demand 定價，比 committed price 貴 30-50%。在用量持續超標三個月後主動找供應商升級 tier，而不是繼續付 on-demand 溢價，這是最直接的降本動作，通常一個電話就能解決，但大部分採購主管不知道可以這樣做。

這裡延伸一個老闆常問的問題：「等 AI 降價再導入是不是更划算？」這篇 等 AI 跌價的真實成本：6 個場景、4 個進場時機 有完整的機會成本分析。

60 天止血行動清單：第 0-15 天盤點、15-30 天 prompt 重構、30-60 天 infra 重算

如果你的 AI agent 帳單已經開始讓你皺眉，以下是一份可以立即執行的 60 天行動清單。不需要砍掉重練，只需要系統性地找漏洞。

第 0-15 天：帳單盤點。拉出過去 6 個月的 token 用量明細（按 model、按流程、按時段），計算每個流程的 token per task，找出增長最快的 3 個流程。同時盤點 infra 帳單，記錄 minimum capacity 設定值和實際流量的比例。把人工監控時數找業務主管和工程師各問一遍，加總後乘以時薪。這個盤點本身不需要改任何東西，只需要讓數字可見。

第 15-30 天：prompt 重構。針對 token per task 增長最快的前 3 個流程，做 prompt 審計。具體做法：把現有 prompt 的每個段落標記「必要 / 可移除 / 可壓縮」，目標是把 system prompt 壓回 PoC 基準的 110% 以內。同時設定 context window 截斷策略：超過 8,000 tokens 的 session 強制啟動 summary compression，只保留最後 3 輪對話的原文。這兩個動作通常可以在 30 天內把 token 月帳壓低 20-35%。

第 30-60 天：infra 重算。把業務低峰期（通常是凌晨 0-6 點和週末）的 minimum capacity 降到 1 或 0（搭配 warm-up 機制），設定 log retention TTL 為 14 天，關閉非必要的 per-request tracing。同時把人工監控流程結構化：建立異常 case 的標準格式、設定每週 prompt review 排程、每月跑一次 eval 的日曆邀請發出去。這個階段結束後，你應該有一份清楚的 AI 系統月度 TCO 報表，包含 token、infra、人力三段。

FAQ

AI agent 的 TCO 管理，最終是一個持續的流程，不是一次性的優化。如果你還在評估導入 AI agent 的預算規模，這篇 AI 預算拆解：台灣中小企業 2026 完整版 可以作為起點。如果你的帳單已經開始讓你不舒服，歡迎到 AI 顧問服務頁 預約一次免費的 30 分鐘成本健檢——帶著你的 token 帳單明細來，我們幫你拆解這三段帳，討論你的系統怎麼長、怎麼控。