AI Agent 的隱形成本：問題不在生成，而在 Context 治理
AI Agent 真正持續燒錢的，常不是生成本身，而是長上下文、快取與狀態維護。當成本重心從 token 轉向 context lifecycle，系統設計就成了能否規模化的關鍵。
當我們評估 AI Agent 的營運成本時，直覺上總認為「生成」內容是最昂貴的環節。然而，這可能讓我們錯失了真正的成本黑洞。一份針對 Anthropic Claude Code 的開發者實測數據揭示，高達 95% 的 Token 消耗來自於「快取讀取」（cache read），而生成 Token 僅佔微不足道的 0.4%。這項發現點出關鍵事實：AI Agent 持續燃燒的成本，往往不是單次生成，而是對話歷史、狀態維護與長上下文的重複讀取。問題核心，已從單純的 Token 經濟學，轉移到更複雜的「Context 治理」（Context Governance）架構挑戰上。
被低估的雪球：為什麼快取讀取會成為成本黑洞？
當我們與一個 AI Agent 進行多輪對話時，為了讓它「記得」之前的內容，系統必須在每一次請求中，將累積的對話歷史重新載入。即使是使用了像 Anthropic 的快取機制，能以較低的單價處理這些重複的上下文，但其總量會隨著對話長度呈雪球式增長。
想像一個長達數十輪的程式碼協作場景。一開始，上下文可能只有幾百個 Token。但在對話進行到第 30 輪時，整個歷史可能已經膨脹到數萬甚至數十萬 Token。此時，即便使用者只輸入了一個 10 Token 的新指令，系統為了維持對話的連貫性，仍需重新讀取並處理前面那龐大的上下文。前述實測中，95% 的消耗量正源於此。
這不是單價問題，而是總量問題。當業界還在為 Gemini 1.5 Pro 的 100 萬 Token 或 Claude 3 的 200K Token 長上下文視窗歡呼時，我們卻很少討論如何有效率、有節制地「使用」這些容量。
長上下文視窗給了我們巨大的潛力，但也帶來了對等的治理責任。將整個對話歷史當作無限的暫存記憶體，是通往成本失控最快的路徑。
這種模式的危險在於它的隱蔽性。開發者在初期測試時，對話短、上下文少，成本看似可控。但一旦應用上線，使用者進行了長期、複雜的互動，成本便會以非線性的方式急劇攀升。這使得許多雄心勃勃的 Agent 專案，最終從一個潛力無窮的工具，變成了一個無法持續營運的昂貴玩具。
如何從 Token 經濟學轉向 Context 治理的思維？
意識到問題根源後，我們需要將視角從單純計算輸入／輸出 Token 的「Token 經濟學」，拉高到管理整個資訊流動週期的「Context 治理」。這不僅是成本優化，更是建立穩健、可擴展 AI 系統的基礎。長上下文不該被視為一個無限大的垃圾桶，隨意傾倒所有歷史紀錄，而應被當作一個需要精密管理的「工作記憶體」。
傳統的作法是將所有歷史都餵給模型，期待它能自行在龐大的資訊中找到關聯。這種「大海撈針」式的做法，不僅成本高昂，也容易受到「Lost in the Middle」問題的影響，即模型在處理長文本時，容易忽略中間部分的資訊。更有效的方法，是建立一套機制來主動管理 Context 的生命週期。
例如，檢索增強生成（Retrieval-Augmented Generation, RAG）就是朝這個方向邁出的一步。它將龐大的知識庫或對話歷史儲存在外部，只在需要時，才精準地檢索出最相關的片段，注入到當前的上下文中。如此一來，模型處理的 Context 就能保持精簡，同時又不失對話的連貫性與深度。
如何實踐有效的 Context Lifecycle Management？
要將 Agent 從昂貴玩具變成可持續的系統，我們必須實踐有效的 Context 生命週期管理。這意味著我們需要設計一套策略，決定哪些資訊應該被保留、哪些應該被遺忘、哪些又該被壓縮。以下是一些具體的方向：
分層記憶體架構（Tiered Memory）：我們可以借鏡電腦系統的記憶體層級結構，為 Agent 設計分層記憶體架構。例如，建立一個用於即時互動的「短期工作記憶體」、一個儲存關鍵事實與對話摘要的「中期記憶體」，以及一個用於長期知識儲存的「外部向量資料庫」。這樣能確保不同類型的資訊，在最合適的層級被管理與存取。
主動式摘要與壓縮（Proactive Summarization）：與其被動累積對話歷史，不如導入主動式摘要與壓縮機制。當對話達到特定長度或關鍵節點時，可觸發一個 meta-agent 自動生成精簡摘要，並用其取代冗長的原始對話紀錄，大幅減少上下文負載。
狀態機管理（State Machine Management）：針對任務導向的 Agent，透過明確的狀態機管理能有效控制上下文。系統無需回顧所有歷史，只需掌握當前狀態及從前一狀態轉移的關鍵資訊，便能大幅削減不必要的 Context 負載，提升效率。
動態 Context 預算（Dynamic Context Budgeting）：此外，為每一次 API 呼叫設定動態 Context 預算上限，能迫使系統在預算內，透過智慧化的檢索與篩選，組合出最高效益的上下文。這代表我們必須從「盡量給」轉變為「給得巧」，精準分配資源。
總結來說，AI Agent 的未來，不在於誰能提供更長的上下文視窗，而在於誰能建立最有效率的 Context 治理框架。當我們不再將成本的焦點只放在可見的生成費用，而是開始系統性地管理隱藏在每一次互動背後的上下文生命週期時，我們才能真正地將 AI Agent 從概念驗證，推向大規模、可持續的商業應用。這是一場關於架構智慧的競賽，而非單純的算力比拼。
延伸閱讀
- Claude Code を1日回して消費トークン量の95%が cache read だった話 (Zenn.dev)
- Anthropic Caching API FAQ (Official Documentation)
- Lost in the Middle: How Language Models Use Long Contexts (arXiv)
- Building a Production-Ready RAG Application (LlamaIndex Blog)
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。