你有沒有過那個瞬間——專心 vibe code 兩三個小時，螢幕角落突然跳出一行字：
▣ DCP | -350.1K removed, +35.3K summary
▣ Compression #25 -13.7K removed, +35.3K summary
→ Items: 18 messages and 18 tools compressed第一次看到大概會覺得「喔 Claude Code 在自動整理 context，乾的真貼心」。但同一個 session 看到第 25 次的時候，你應該開始有點不對勁——它越來越聽不懂你的需求、開始重讀剛剛改完的檔案、甚至忘記 5 分鐘前才下的明確指令。
很多人這時候會去網路上找答案，然後得到一個老掉牙的建議：「你要常常用 /clear 或 /compact 喔。」
我先講結論：這個建議在 2026 年已經過時了。
問題不是壓縮工具不夠好，也不是你太懶得手動清。真正的兇手是 — agent 自己會不停生 context，你根本來不及 clear。要根治這件事，得從「session 管理」的思維跳出來，改用 sub-agent 結構性隔離 的架構去思考。
夭壽，這篇要講的就是這個。
Compression #25 到底在跟你說什麼
先講機制。Claude Code 不是隨便壓的，它的 context 管理是一條 5 層 pipeline。根據 HarrisonSec 對 Claude Code 壓縮機制的逆向工程 ，autocompact 是這條 pipeline 的最後一站，採用 兩階段 Chain-of-Thought Scratchpad：
第一段先逐訊息走過 user intent、檔案、決策、錯誤、修復；第二段才產出 9 個欄位的結構化摘要——Primary Request、Key Technical Concepts、Files and Code、Errors and Fixes、Problem Solving、All User Messages、Pending Tasks、Current Work、Optional Next Step。
關鍵設計：思考過程本身會被丟掉，只保留 summary。
這代表 Anthropic 工程師非常認真在做「壓縮一次的品質最大化」——但他們沒有打算鼓勵你壓很多次。事實上 Anthropic 官方 context engineering 文章 自己用詞就很保守：
"Compaction... at its core, distills the contents of a context window in a high-fidelity manner, enabling the agent to continue with minimal performance degradation."
注意是 minimal degradation（盡量少劣化），不是 improvement（提升）。Anthropic 自己都沒說壓縮會讓你更聰明，只說會讓你劣化得慢一點。
那為什麼 Compression #25 會讓品質崩盤？因為每次壓縮都是 lossy operation（有損操作）。第 2 次壓的是第 1 次的摘要、第 3 次壓的是第 2 次的摘要……到第 25 次的時候，你 context 裡裝的早就不是「對話歷史」了，是「摘要的摘要的摘要的摘要……」這個套娃結構連 Claude 自己都搞不清楚原始意圖長什麼樣。
更慘的是，Claude Code 工程團隊很清楚這個副作用。他們在 formatCompactSummary() 後面跟著一個 runPostCompactCleanup() 步驟，專門善後「模型壓縮後忘記剛 edit 過的檔案」這種典型 bug。你看到的 #25，本質上是這個 cleanup 已經補救了 24 次的失敗 trace。
/clear 和 /compact 為什麼已經救不了你
社群早期的處方很單純：早點壓、別等到 95%。所謂的「60% 規則」就是這個邏輯——MindStudio 在這篇文章 大力推銷：在 context 還乾淨的時候主動 /compact，產出的摘要品質會遠優於等 context 已腐爛才壓。
這套說法不算錯，但有效時間越來越短。
Albert Sikkema 在 2026 年 4 月那篇被瘋傳的文章 講得很直白：他乾脆把 1M context 關掉，強制回到 200K，搭配 CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=70 讓壓縮提早觸發。理由是「常壓縮但每次都是乾淨素材」勝過「不壓縮但 context 已腐爛」。
更激進的是 Amp 工程團隊的資深工程師 Dan Mac，據 Albert Sikkema 同篇文章 轉述，他放過一句被瘋傳的話：
"You should basically never use compaction."
靠杯，這話是設計 production agent harness 的人講出來的。為什麼？因為 Amp 整個架構放棄 compaction，改成 短 thread + 乾淨 handoff：每個任務開新 thread，做完把結論寫到外部記憶，下一個任務再開新 thread 讀取結論。
這個觀察接上了 2025 年 7 月 Chroma Research 那篇炸鍋的 Context Rot 報告 （作者：Kelly Hong、Anton Troynikov、Jeff Huber）。他們對 18 個前沿模型（含 GPT-4.1、Claude Opus 4、Gemini 2.5 Pro、Qwen3-235B）做了系統測試，結論很尖銳：
| 觀察 | 數據 |
|---|---|
| 全部 18 個模型 | 隨 token 增長都會劣化，零例外 |
| 200K window 的模型 | 在 50K token 時就出現明顯劣化 |
| 「focused」vs「full」context | 只塞相關資訊，準確率有時翻倍 |
| 反直覺發現 | shuffled 文本比 coherent 文本表現更好（連貫敘事增加干擾選項可信度） |
換句話說，短 context 才是真正的解藥，壓縮只是手段。但在 agent 時代，問題是你根本控制不了 context 長度——
真正的兇手：Agent 會自己一直生 context
這才是 2026 年的核心問題。你用 Claude Code 不是在跟一個聊天機器人對話——你是在啟動一個 autonomous loop，它會自己決定要讀哪些檔案、跑哪些 bash、思考多久、呼叫哪些 sub-task。每一個動作都在往 context 裡塞東西。
主要膨脹來源有三條：
| 來源 | 例子 | 占用 |
|---|---|---|
| Tool result | Read 一個 5000 行檔案、Bash 跑 git log、MCP server 回 JSON | 最大宗（50-70%） |
| Reasoning / thinking | extended thinking、chain-of-thought scratchpad | 中等（10-20%） |
| Plan & sub-task 結果 | TaskCreate、計畫文件、TODO 累積 | 小但持續累積 |
Victor Dibia 在 Context Engineering 101 描述了一個 agent 領域特有的失敗模式叫 thrashing：
"the agent that compacts its context, drops critical information, then re-reads the same files."
壓縮丟掉某些必要資訊後，agent 反覆重新讀同樣的檔案、重跑同樣的工具呼叫。不只更慢更貴，連推理路徑都會被弄亂。這就是為什麼你在 Compression #15 之後，會看到 Claude 突然又開始 Read 它在 #3 就讀過的檔案——它真的不記得自己讀過了。
而且這個過程完全由 agent 自己決定。你想 /clear 嗎？等你發現的時候它已經自己塞 100K token 進去了。手動干預在 autonomous loop 面前完全失效。
Anthropic 自己在 Effective harnesses for long-running agents 也直接認帳：
"Out of the box, even a frontier coding model like Opus 4.5 running on the Claude Agent SDK in a loop... will fall short of building a production-quality web app... This happens even with compaction."
連 Anthropic 自家都說光靠 compaction 撐不住 production 級任務，這時候你還在嫌 /compact 太晚觸發？方向錯了，乾。
Sub-Agent：把 context 膨脹關進獨立沙盒
正確的心智模型不是「控制 context」，是「設計讓 context 自己保持乾淨的架構」。
具體做法：把每個會大量膨脹 context 的子任務，丟給一個 sub-agent 去做。它在自己獨立的拋棄式 context 裡爆肝、讀檔、思考、跑 tool，做完只把結論回傳給主 agent。膨脹過的 context 隨著 sub-agent 結束就被銷毀，主 agent 永遠在乾淨的小 context 上推理。
主 agent context: 2K (任務 brief + 摘要結果)
├─ sub-agent 1: 100K (research API) → 回傳 500 token 結論
├─ sub-agent 2: 80K (security review) → 回傳 800 token 結論
└─ sub-agent 3: 120K (testing & debug) → 回傳 300 token 結論這就是 Claude Code 的 Task 工具與 Agent 工具設計初衷，也是為什麼 Anthropic 在 2025 後半年強推 Workflow / fan-out 模式——它把「context 自我膨脹」這個動作關進獨立沙盒，膨脹完就丟。
一位在 production 跑 6 個 agent 的 Reddit 使用者 ultrathink-art 講過一段被多次引用的話：
"1M tokens isn't actually the fix. The fix is task scoping. When our orchestrator spawns a sub-agent, it only passes the task brief + relevant memory, not the full session. The sub-agent starts fresh with ~2K tokens of context and does its job cleanly. Compact + narrow task scope outperforms 1M context + kitchen sink in our experience."
注意他用的字：kitchen sink。把所有東西丟進同一個 context 等於水槽，什麼都洗、什麼都泡，最後一團糟。而 sub-agent 是「每個盤子用獨立水槽洗完直接擦乾收櫃」——這才是 production 架構。
三層分工：tool clearing + sub-agent + memory
Sub-agent 隔離只是其中一層。完整的 production agent 架構長這樣：
第一層：Tool Result Clearing（自動、零成本）
最輕的「壓縮」，根本不需要 LLM 介入。Claude API 的 context editing 文件 描述得很清楚：
- 把舊的
tool_resultblock 直接換成[cleared to save context] - 保留
tool_userecord（agent 還知道呼叫過） - 只丟掉 bulky payload（檔案內容、API 回應）—— 這些可以重新取回
啟用方式（API 用戶）：在 request 加上 beta header context-management-2025-06-27，並設定 clear_tool_uses_20250919 策略。
JetBrains 拿這招在 Qwen3-Coder 480B 上做了實測，Tianpan 整理在這篇文章 ：52% 成本降低 + 2.6% solve rate 提升。零品質損失，且不用使用者介入。是目前最划算的單一機制。
第二層：Sub-Agent Isolation（結構性切斷）
上面講過了。重點再講一次：不是把 context 變短，而是讓會膨脹的子任務在拋棄式環境完成。
實務操作：用 Task 工具 fan out、用 Claude Code Workflow 做 pipeline、自己組 orchestrator 模式。每個 sub-agent 自帶 system prompt 與工具，做完只回傳精煉結論。
第三層：Memory Tool / NOTES.md（持久化外接）
最容易被忽略的一層。讓 agent 主動把該長期記的東西寫到 context 外（檔案系統），需要時再 just-in-time 拉回。
Anthropic 在 memory tool 文件 推的範例：Claude 玩寶可夢——跨數千步維持「我在 Route 1 訓練皮卡丘到 8 級」這種狀態，不是靠 context，是靠它一邊玩一邊寫筆記，需要時 just-in-time 拉回。
實務操作：
- 在 repo 根目錄維護
CLAUDE.md（每個 session 自動載入） - 每完成一個重要決策，主動寫進
NOTES.md - 任務切換時
/clear，下個 session 從NOTES.md重新讀回
這三層是正交的——必須組合使用，不是擇一。Anthropic Cookbook 的 context engineering 範例專案 把這三層的分工講得最清楚。
踩坑紀錄：那些看似常識但其實會害你的事
坑一：以為 1M context window 就能解決問題
很多人看到 Sonnet 4.6 / Opus 4.8 有 1M context 就以為從此解脫。實測社群的回饋是 「1M 是 capacity 增加，不是 quality 增加」 。
具體症狀：1M window 在 400K+ 位置塞的 instruction 經常被忽略（lost in the middle 加劇）、成本是 200K + compact 的數倍（一次 prompt £200 vs £20）、回應速度慢到讓 interactive workflow 變痛苦。
結論：1M 是「我寧可貴」的安全網，不是優化方向。
坑二：以為早點 /compact 就沒事
60% 規則在「靠人類盯」的情境有用，但對 autonomous loop 完全失效。等你發現該壓的時候，agent 已經跑完三輪 tool call 把 context 撐到 80%。
結論：把 CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=70 設好讓系統早觸發，不要靠人類視覺巡邏。
坑三：以為 sub-agent 越多越好
不是。每個 sub-agent 都有自己的 startup cost（讀 CLAUDE.md、載入 tool schema），切太細會把成本拉高且 latency 變糟。
結論：以「單一明確子目標」為單位切，不要為了切而切。我的經驗是同一個 session 拉 3-5 個 sub-agent 是甜蜜點。
坑四：用 CLAUDE.md 塞所有規則
JD Fiscus 在 LinkedIn 上分享過一個經典踩坑 ：他的 CLAUDE.md 撐到 55KB，結果 session 越來越短、auto-compact 一直觸發。後來才發現 Claude Code 的 system prompt 會自動 deprioritize 過大的 context 檔案，他精心整理的 242 條規則被部分忽略。
解法：拆成 learnings/ 資料夾，每個工具一個檔案。Claude 用 ls learnings/ 看清單、grep -r "webhook" learnings/ 搜尋、cat learnings/stripe.md 讀具體規則。整個 CLAUDE.md 從 55KB 砍到 24KB，所有 learnings 都保留，session 變更長。
這個「filesystem + bash 架構」的 pattern，Victor Dibia 在 2026 年 3 月的 Context Engineering 101 整理得最清楚，並提到 Vercel 也發過類似主張的文章 validate 同樣方向。核心邏輯一致：讓 agent just-in-time 從檔案系統取資料，而不是預先把所有規則塞進 context。
你今天就能做的 4 件事
講了一堆理論，給點可立刻執行的：
1. 設環境變數讓系統早觸發壓縮
export CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=70
export CLAUDE_CODE_DISABLE_1M_CONTEXT=1 # 如果你不需要 1M2. 看到 Compression #2 就考慮 /clear
把當前狀態寫到 NOTES.md，新開 session。不要等 #25。
3. 大型子任務一律用 Task 工具丟給 sub-agent
研究、安全審查、跨檔案重構、深度測試——這些容易膨脹 context 的任務都該 fan out。
4. 把 CLAUDE.md 拆成 learnings/ 資料夾
讓 agent 用 grep/cat 去 just-in-time 取，而不是預先載入。
一句話帶走
「常壓縮」是症狀，「agent 沒有結構性分工」才是病因。Compression #25 不是壓縮工具設計失敗，是這個 session 從一開始就用「一個 agent 包山包海」的姿勢在跑。
真正的 2026 心智模型：不是控制 context，是設計讓 context 自己保持乾淨的架構。
下次看到 Compression #25 跳出來——不要急著找 /clear 按鈕，停下來想想：這個任務該不該拆成 3 個 sub-agent？這個檔案讀完之後 tool result 是不是該 clear？這個決策是不是該寫進 NOTES.md？
答對這三題，#25 永遠不會發生。
延伸閱讀
- Effective context engineering for AI agents — Anthropic ：Anthropic 官方對 compaction、structured note-taking、sub-agent 三大策略的完整論述
- Effective harnesses for long-running agents — Anthropic ：自家工程師承認光靠 compaction 撐不住 production
- Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma Research ：原始研究報告（Kelly Hong / Anton Troynikov / Jeff Huber，2025 年 7 月），對 18 個前沿模型的硬數據
- Context Rot 完整解讀 — Morph LLM ：2026 年 3 月對 Chroma 報告的延伸整理，含 coding agent 場景的影響分析
- Context editing — Claude Platform Docs ：tool result clearing 與 thinking block clearing 的 API 設定
- Context engineering: memory, compaction, and tool clearing — Anthropic Cookbook ：三層分工架構的官方範例
- How Claude Code Compresses Context — HarrisonSec ：5-level pipeline 逆向工程的完整解析
- Why I Shrunk Claude Code's Context Window Back to 200k — Albert Sikkema ：實戰派對 1M context 的批判
- Context Engineering 101 — Victor Dibia ：thrashing 概念與 filesystem + bash 架構
- The 60% Rule for /compact — MindStudio ：早觸發 compaction 的實務派觀點
- Context Engineering: Memory, Compaction, and Tool Clearing — Tianpan ：JetBrains observation masking 實測數據
