Context Length Optimization

Context 長度優化是管理 Claude API 呼叫的輸入 Token 數量的工程實踐。它的目標不只是「省錢」——雖然這是主要動機——而是在成本、速度、輸出品質之間找到最好的平衡。

為什麼這很重要：Claude API 按 Token 計費，輸入 Token（你送進去的文字）和輸出 Token 分別收費。在一個真實的生產應用裡，輸入 Token 通常佔了 60-80% 的費用，其中很大比例是可以優化掉的「低價值 Token」——例如 System Prompt 裡的冗餘說明、對話歷史裡的過時輪次、或者 Context 裡已不再相關的背景資訊。

更重要的是「Lost in the Middle」效應：Claude 對 Context 開頭和結尾的注意力最高，中間的資訊容易被稀釋。過長的 Context 不只更貴，有時候實際上讓輸出品質下降，因為 Claude 沒辦法有效利用中間的重要資訊。

Context 長度優化的四個主要技術，按照實施優先順序：

技術一：System Prompt 精簡（最高 ROI） System Prompt 每次 API 呼叫都要計費。把冗餘的說明、重複的格式指令壓縮掉，能立刻降低每次呼叫的基礎費用。目標是用最少的 Token 傳達最多的約束資訊。

技術二：Prompt Caching（如果 System Prompt > 1,024 Token） Anthropic 的 Prompt Caching 功能讓 System Prompt 的靜態部分能被緩存，後續請求只付 10% 的費用來讀取緩存。對 System Prompt 超過 2,000 Token 的應用，這個功能能立刻節省 20-30%。

技術三：對話歷史截斷 不保留全部對話歷史，只保留最近 N 輪（N 取決於任務需要的記憶深度，通常 5-10 輪夠用）。

技術四：摘要壓縮 比截斷更精緻的方法——用便宜的 Haiku 模型把舊的對話歷史壓縮成一份摘要，用摘要取代原始的舊輪次。保留了重要的上下文，但大幅減少了 Token 數量。

Context 長度優化對系統設計的影響最直接體現在「對話記憶架構」的設計決策上。很多初學者會直接把整個對話歷史傳給 Claude（最簡單的實作），但這在長對話下會導致 Token 爆炸。生產級的系統通常採用「分層記憶架構」：最近幾輪的完整記錄（短期記憶）+ 較早期的壓縮摘要（中期記憶）+ 任務的關鍵決策和事實（長期記憶，通過 RAG 或直接注入）。這個架構能在任意長度的對話裡保持接近固定的 Token 消耗，讓系統的費用可預測、延遲可控制。

Context 長度優化的實施路徑建議：

第一步：先做 Token 消耗審計。在 console.Anthropic.com/settings/usage 查看你的每日 Token 消耗分布。理解你的費用結構，才能知道優化哪裡效益最大。

第二步：System Prompt 精簡。把你的 System Prompt 拿出來，逐句問「這句話如果刪掉，Claude 的行為會有什麼變化？」保留真正影響行為的部分，刪掉冗餘說明。

第三步：實作滑動窗口對話歷史。從保留最近 8 輪開始，觀察輸出品質是否有變化。大多數任務 8 輪已經夠用；特別需要長期記憶的任務才考慮增加輪數或實作摘要壓縮。

第四步：評估 Prompt Caching。如果你的 System Prompt 超過 1,024 Token 且在連續請求裡保持不變，啟用 Caching 能立刻降低費用。