症狀：快取命中率很高，但長會話的 Token、回應時間和帳單仍然持續上升。
最快解法：先從 usage 拆出輸入、輸出、快取命中與未命中，再按結果選擇 Compaction、工具結果裁剪或新建會話，不要直接把所有歷史壓成摘要。
這篇適合三類讀者：發現長會話 Token 持續增加的個人開發者；需要控制持續 Agent 成本與回應時間的工程團隊；正在評估模型呼叫、執行環境和人工恢復成本的技術負責人。
最後更新於 2026 年 8 月 18 日；模型欄位、快取規則與計費資料核實自官方 API 用量欄位文件、官方上下文快取文件與官方定價頁面。
SECTION 01為什麼快取命中高，Token 消耗仍然增加？
DeepSeek Harness 的長會話不會只傳送你這一輪新增的問題。每次模型呼叫通常都可能包含：
- 本輪新增的使用者輸入；
- 尚未被移除的會話歷史；
- 系統指令、工作區規則與 Agent 狀態；
- 工具呼叫及其回傳內容；
- 模型本輪輸出，包含需要計費的輸出 Token。
因此，單一請求的輸入規模會隨任務推進而改變。官方 usage 欄位將 prompt_tokens 定義為輸入 Token，並拆成 prompt_cache_hit_tokens 與 prompt_cache_miss_tokens；total_tokens 則是輸入與輸出的總和。換句話說，快取命中只改變輸入 Token 的計費路徑，沒有把不斷變長的會話歷史從請求中消除。
你應先把每次回應記錄成：
prompt_tokens
prompt_cache_hit_tokens
prompt_cache_miss_tokens
completion_tokens
total_tokens
並檢查這個關係是否成立：
prompt_tokens = prompt_cache_hit_tokens + prompt_cache_miss_tokens
total_tokens = prompt_tokens + completion_tokens
如果 prompt_tokens 每輪上升，而命中率也維持高位，問題通常不是快取失效，而是「被快取的前綴本身越來越長」。官方快取只比對輸入前綴，且採取盡力而為策略，不保證每次都命中；輸出仍然需要模型推理，並不會因為輸入命中快取而免費消失。可參考官方快取命中欄位與前綴規則說明。
第一個排查動作：不要只看介面上的命中率
Harness 介面、日誌檢視器與第三方解析器可能以不同方式呈現 Token。你要以 API 回應內的 usage 為主，再把同一請求的會話長度、工具輸出長度和回應時間放在同一筆記錄中。
不要使用社群截圖推導普遍成本，也不要把某個 wrapper 的測試結果當成官方 DeepSeek Harness 行為。官方目前公開確認的是 Compaction 服務、摘要後端、工具結果裁剪元件和人工壓縮命令；觸發條件、事件欄位與預設組合仍可能隨開發者預覽版本改變。版本狀態應以官方 DeepSeek Harness 儲存庫當日內容為準。
SECTION 02工具結果太長，如何減少上下文佔用？
長會話最容易被低估的來源不是使用者問題，而是工具回傳。以下內容都可能在每一輪重新被帶入：
- 建置或測試命令產生的大量輸出；
- 搜尋工具列出的整批結果；
- 讀取大型程式碼檔案或設定檔；
- 重複出現的錯誤日誌；
- MCP 工具回傳的完整 JSON、診斷資料或二進位檔案描述。
工具結果裁剪和摘要壓縮不是同一件事。
工具結果裁剪是在結果進入後續上下文前，先移除重複行、無關欄位、冗長堆疊追蹤或已經被確認的內容。它適合處理「模型不需要再次逐字閱讀」的資料。
Compaction 摘要則是重新整理較早的會話內容，把目標、決策、已完成工作和未完成事項濃縮成較短狀態。它需要保留任務語義，不能只做字元截斷。
你可以按以下規則處理工具結果：
- 可重建的建置輸出：保留命令、退出狀態、關鍵錯誤行，完整輸出另存為外部日誌。
- 重複的搜尋結果：保留查詢條件、最終採用的來源和排除理由，其餘裁剪。
- 大型檔案：保留路徑、修改區段、介面定義和行號；完整檔案留在工作區，不要每輪重新貼入。
- 測試失敗：保留測試名稱、錯誤訊息、重現命令和最後一次結果；不要只留下「測試失敗」。
- 安全、權限和使用者硬性要求：不可只保留摘要，應寫入固定的任務狀態或外部產物。
這樣做的代價是，你必須確保 Agent 仍能在需要時重新取得原始證據。若某項資料是審計、合規或回溯所需，就應保存完整日誌，並只把索引和結論放入上下文；不要把「減少上下文」誤解成「刪除證據」。
SECTION 03Compaction 會不會丟失程式任務的重要上下文？
會，尤其是在摘要沒有明確列出工作狀態時。壓縮後最常見的失真不是模型忘記某句對話，而是它不再知道：
- 哪些檔案已經修改，以及修改尚未提交；
- 哪些測試曾經失敗，失敗是否已修正；
- 使用者要求不能改動的介面、版本或檔案；
- 下一個應執行的待辦事項；
- 某個工具結果是證據、暫時推測，還是已經被否決的方案。
因此，壓縮不能只以「摘要後 Token 變少」作為成功條件。對程式任務，你至少要在壓縮前後執行同一組驗證：
- 要求 Agent 說出目前任務目標與不可違反的限制。
- 要求列出已修改檔案、每個檔案的變更目的。
- 要求列出尚未完成的待辦事項和下一個動作。
- 重新詢問最近一次測試失敗的原因與重現命令。
- 讓 Agent 繼續執行一個低風險、可回溯的任務動作。
若壓縮後答案與壓縮前的可驗證狀態不一致，先回退到壓縮前會話，或建立一個只載入正式狀態的新會話。不要讓 Agent 在狀態已經不完整的情況下繼續修改程式碼。
可勾選的壓縮前驗收清單
- [ ] 已保存原始會話日誌，而不是只保留摘要。
- [ ] 已記錄目前工作區路徑、分支或版本識別。
- [ ] 已列出所有已修改檔案及未提交變更。
- [ ] 已保存最近一次測試命令、結果和失敗原因。
- [ ] 已把使用者硬性限制寫入固定狀態區。
- [ ] 已指定壓縮後要重問的目標、待辦和測試問題。
- [ ] 已確認重要工具結果仍可從外部產物重新取得。
- [ ] 已為壓縮失敗準備回退會話或唯讀備份。
這份清單的用途不是增加流程，而是避免你為了節省輸入 Token，最後支付更高的人工恢復成本。
SECTION 04什麼時候應該壓縮會話，而不是新建會話？
判斷重點不是會話有多長，而是「舊上下文對下一步是否仍然有用」。
適合 Compaction 的情況：
- 任務目標沒有改變，只是歷史訊息和工具輸出變多；
- 工作區邊界仍相同，Agent 需要延續同一組檔案；
- 目前的決策、測試狀態和待辦事項可以被明確驗證；
- 你仍需要保留同一條推理脈絡，而不是重新介紹專案。
適合新建會話的情況：
- 使用者目標已經從除錯改成重構、審查或部署；
- 工作區、分支、權限或專案邊界已經改變；
- 舊會話累積大量互相矛盾的嘗試和錯誤假設；
- 任務需要審計，完整日誌必須獨立保存；
- Agent 在壓縮後反覆重做已完成工作，或無法正確描述當前狀態。
你可以用以下決策順序，而不是固定每隔某個 Token 數就壓縮：
- 目標相同、證據可保存：先裁剪工具結果，再 Compaction。
- 目標相同、但狀態不完整：暫停任務，補齊外部狀態後再壓縮。
- 目標或工作區改變：新建會話，載入必要摘要和產物索引。
- 需要完整審計：原始日誌與模型上下文分離保存，不能以摘要取代原始記錄。
- 壓縮後驗證失敗：立即回退，不要在錯誤狀態上繼續消耗 Token。
這也回答了「上下文壓縮是否一定降低成本」：它通常能減少後續請求攜帶的歷史，但如果摘要本身需要額外模型呼叫，或壓縮後遺失狀態而導致 Agent 重做，總成本可能反而增加。
SECTION 05長會話成本估算的資料框架
不要先問「一個任務平均需要多少 Token」。沒有任務規模、工具數量、輸出上限和重試次數，任何平均數都沒有決策價值。
你應以同一個基準任務記錄以下資料：
- 每次請求的
prompt_tokens； prompt_cache_hit_tokens與prompt_cache_miss_tokens；completion_tokens，必要時拆出推理 Token；- Compaction 次數、摘要輸入和摘要輸出；
- 工具結果原始大小與裁剪後大小；
- 首 Token 時間、完整回應時間和失敗重試次數；
- 本地伺服器或雲端 Mac 的處理器使用率、記憶體壓力、硬碟增長；
- 人工檢查、回退和恢復所花的時間。
成本可先用變數表示：
輸入成本
= 快取命中 Token × 當日快取命中單價
+ 快取未命中 Token × 當日快取未命中單價
輸出成本
= completion_tokens × 當日輸出單價
總模型成本
= 輸入成本 + 輸出成本 + Compaction 額外呼叫成本
以寫作當日官方定價頁為準，官方頁面目前將 deepseek-v4-flash 和 deepseek-v4-pro 的輸入快取命中、輸入未命中及輸出分開列價；頁面同時提醒價格可能調整，因此不要把本文的任何金額當成長期固定值。請直接核對官方模型與定價資料。
判斷優化是否有效時，至少比較同一任務的兩次完整執行：一次使用原始歷史，一次使用工具裁剪、Compaction 或會話拆分。若只看到某一輪帳單下降，卻沒有比較回應時間、重試次數、記憶體、硬碟和人工恢復成本，你得到的只是單次低費用，不是穩定的成本結論。
三種策略的優缺點
只保留單一長會話
- 優點：上下文連續，較少重新交代背景。
- 缺點：歷史、工具結果和錯誤假設持續膨脹，壓縮失敗時影響範圍最大。
定期 Compaction
- 優點：可保留同一任務脈絡，控制後續輸入規模。
- 缺點：摘要品質決定恢復品質，且壓縮本身可能增加一次模型呼叫。
按階段拆分會話
- 優點：工作區邊界清楚，錯誤上下文不容易污染下一階段。
- 缺點：需要建立狀態文件、測試結果和產物索引，否則新會話會重複探索。
當長會話同時佔用本機工具鏈、記憶體和硬碟，並且多個 Agent 任務互相爭用工作區時，問題就不再只是 Token。你可以先閱讀DeepSeek Harness 執行環境與 Mac 方案，再按並發數、佔用窗口和任務隔離需求評估是否要拆分環境；若你正在計算租用週期，也可參考MACNOX 的方案與價格資訊。
如果你目前的方案是讓多個長會話長期共用一台本機，常見缺點是工作區互相干擾、記憶體和硬碟增長難以預測，以及任務中斷後需要人工清理狀態。改用雲端 Mac 並不會自動降低 API Token 費用，但能把執行環境、隔離和佔用時間拆開管理；對需要臨時算力、測試環境或並行 Agent 的任務，租用 MACNOX 的 Mac 往往比持續佔用你的主力電腦更容易核算。若任務是長期穩定重負載、必須接觸實體介面，或已有固定本地設備，則自購 Mac 或保留現有環境可能更合理。
需要開始規劃隔離環境時，可先查看MACNOX 的 Mac 租用入口，再把會話拆分、Token 預算和本地資源佔用放在同一份 runbook 中管理。