後台任務的 Token 成本會被低估十倍
後台自動化任務的 Token 成本會因為 Session Context 累積而被低估十倍，需要在架構設計階段就考慮 Context 清理策略。
看得見的成本往往不是最大的
估算 AI Agent 系統的成本時，大多數人會關注對話輪數、API 呼叫次數這些「可見」的操作。但真正的成本炸彈，往往來自那些看起來無害的後台任務。
有個開發者分享了一個案例：一個簡單的 cron job，每天自動巡查 Instagram 留言。任務本身很輕——就是定期檢查、分類、回應。但運行幾週後，他發現這個任務的 token 消耗已經超過所有用戶交互的總和。原因是什麼？Session context 從最初的 856 字，膨脹到了 3,570 萬字。
這不是 bug，這是架構問題。
Session Context 的隱形累積
長時間運行的 session 會自動累積歷史記錄。每次任務執行，新的對話、決策、觀察都被加入 context。對於交互式應用，這通常不是問題——用戶結束對話，session 就結束了。但對於 cron job，session 可能連續運行數週甚至數月。
結果是什麼？同樣的任務邏輯，每次執行的 token 成本都在指數增長。第一週可能花 $10，第二週 $50，第三週 $200。不是因為任務變複雜了，而是純粹的 context 堆積。
這意味著「監控和定期清理 session context」不應該是事後優化，而是部署時的必做項。
視覺輸入的隱藏成本
多模態 AI 時代，開發者容易假設「截圖會帶來更準確的結果」。但現實是：每張截圖消耗 15-80KB 的 token。在自動化任務中，這些「輔助信息」會快速累積。
對於定期執行的巡查任務，決定「何時用截圖、何時用文本」變成了關鍵的成本/效果權衡。不是「更多信息更好」，而是「這張截圖值不值這個成本」。
後台任務需要不同的成本模型
交互式 Agent 和 cron job 的成本特性完全不同，但很少人分開設計。
常見的成本估算方法是：「月活用戶 × 平均對話輪數」。這對聊天應用有效。但對於後台自動化任務，這個公式會嚴重低估成本。一個看似輕量的監控任務，可能在三個月後成為整個系統的最大開銷。
如果你在設計需要長期運行的監控、巡查、定期更新類任務，應該採用不同的架構策略：
- 短生命週期的 session——每次執行後立即清理，而不是連續累積
- 定期 context 清理——保留必要的狀態，丟棄歷史記錄
- 輕量級的非 LLM 篩選——用簡單的規則先過濾，只把需要判斷的部分交給 LLM
- 分層成本設計——區分「每次執行必須用 LLM」和「可以用更便宜方案」的邏輯
這不只是優化問題
我見過不少團隊，在成本爆炸後才開始考慮這些問題。那時候往往已經積累了一堆技術債。
關鍵是前期的架構決策。當你決定用 LLM 驅動一個後台任務時，同時要決定：session 的生命週期是多長？什麼時候清理 context？哪些信息必須用視覺，哪些可以用文本？
這不是效率問題，這是一個選擇。而選擇的時間點，決定了後續的成本軌跡。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。
