一文帶你徹底搞懂claude code中的上下文壓縮
我要評論上下文壓縮是什么，為什么要做？
在 Claude Code 這類 Agent 里，它不是簡單把歷史消息砍短，也不是讓模型選擇性失憶，而是在上下文快裝不下時，重新整理信息：哪些必須繼續(xù)給模型看，哪些可以挪到磁盤，哪些可以總結(jié)成 summary，哪些運(yùn)行狀態(tài)需要壓縮后再補(bǔ)回來。
為什么要這么麻煩？因?yàn)榫幋a Agent 的上下文增長太兇了。普通聊天可能是一句一句往上加，Claude Code 則經(jīng)常是 Read 一個大文件、Bash 跑出幾萬行日志、Grep 搜出一堆匹配、多個工具還可能并發(fā)返回。工具結(jié)果剛出來時很重要，但過了幾輪以后，它的價(jià)值往往下降。如果還把幾千行舊文件內(nèi)容、幾萬行舊日志一直塞在上下文里，就像開完會還背著投影儀繼續(xù)趕地鐵，精神可嘉，肩膀遭罪。
所以，上下文壓縮的核心不是“忘掉過去”，而是“帶著必要信息繼續(xù)干活”。Claude Code 的做法也不是等爆窗后原地?fù)尵?，而是分層處理?/p>
大工具輸出：先落盤，只留預(yù)覽和路徑 舊工具結(jié)果：能清就清，別長期占座 上下文壓力：用閾值判斷是否需要完整 compact 舊對話語義：必要時總結(jié)成可交接的 summary 運(yùn)行現(xiàn)場：壓縮后補(bǔ)回文件、計(jì)劃、工具、hooks 等狀態(tài)
一句話概括：上下文壓縮不是把聊天記錄變短，而是把“模型繼續(xù)工作真正需要的東西”重新打包。 如果壓縮完模型還要問“所以我接下來做什么？”，那就不是壓縮，是交接事故。
第一部分：局部減負(fù)
前面我們說過，Claude Code 的上下文壓縮不是一上來就把整段歷史總結(jié)成 summary。真正進(jìn)入完整 compact 之前，它會先做一層更輕量的處理：局部減負(fù)。
局部減負(fù)要解決的問題很具體：
工具剛剛返回了一大段結(jié)果， 這段結(jié)果可能有用， 但不能不加控制地完整塞進(jìn)模型上下文。
這里的重點(diǎn)是“剛剛返回”。它和后面要講的 Microcompact 不一樣：
局部減負(fù)：處理新產(chǎn)生的大工具輸出。 Microcompact：清理歷史里已經(jīng)變舊的 tool_result。
所以局部減負(fù)不是總結(jié)對話，也不是刪除歷史語義。它只是改變“大工具輸出”在上下文里的呈現(xiàn)方式：完整內(nèi)容保留下來，但模型當(dāng)前上下文里只放一個更輕的引用和預(yù)覽。
為什么工具結(jié)果要單獨(dú)處理？
在編碼 Agent 里，上下文膨脹最快的往往不是用戶消息，也不是 assistant 的普通回復(fù)，而是工具結(jié)果。
比如：
Read -> 返回文件內(nèi)容 Bash -> 返回測試日志、構(gòu)建日志、命令輸出 Grep -> 返回大量匹配結(jié)果 Glob -> 返回大量文件路徑 WebFetch -> 返回網(wǎng)頁正文 Edit/Write -> 返回修改結(jié)果或校驗(yàn)信息
這些內(nèi)容有兩個特點(diǎn)：
1. 體積大：很容易一次返回幾萬甚至幾十萬字符。 2. 時效強(qiáng)：剛返回時很重要，但不一定需要每一輪都完整攜帶。
如果工具結(jié)果每次都原樣進(jìn)入上下文，會帶來幾個直接后果：
請求 token 增加 prompt cache 更容易被破壞 下一輪更接近上下文窗口上限 后續(xù)真正重要的近期消息被工具輸出擠占空間
因此 Claude Code 先做一件低成本的事：不急著壓縮整段對話，先把工具結(jié)果這類高體積內(nèi)容處理掉。
第一層：單個工具結(jié)果過大，先持久化到磁盤
源碼里這一層主要在 src/utils/toolResultStorage.ts。
當(dāng)某個工具返回結(jié)果后，Claude Code 會把它映射成 API 能識別的 tool_result block。隨后會進(jìn)入類似 maybePersistLargeToolResult 的處理邏輯，判斷這個結(jié)果是否過大。
整體流程可以簡化為：
工具執(zhí)行完成 -> 生成 tool_result -> 判斷結(jié)果大小是否超過閾值 -> 如果超過閾值，把完整內(nèi)容寫入 tool-results 文件 -> 上下文里只放 persisted-output 預(yù)覽消息
也就是說，模型上下文里看到的不是完整大輸出，而是類似這樣的內(nèi)容：
<persisted-output> Output too large (...). Full output saved to: .../tool-results/toolu_xxx.txt Preview (first 2KB): 這里是前面一小段輸出內(nèi)容 ... </persisted-output>
這里有幾個細(xì)節(jié)值得注意。
第一，完整內(nèi)容沒有丟。它被保存到了當(dāng)前 session 目錄下的 tool-results 子目錄里，文件名通常和 tool_use_id 相關(guān)。
projectDir/sessionId/tool-results/{tool_use_id}.txt
projectDir/sessionId/tool-results/{tool_use_id}.json
如果后續(xù)模型確實(shí)需要完整結(jié)果，它至少知道完整內(nèi)容在哪里，可以通過路徑重新讀取。
第二，預(yù)覽不是隨便截一刀。源碼里有 PREVIEW_SIZE_BYTES = 2000，并且生成預(yù)覽時會盡量在換行處截?cái)啵苊獍岩恍袃?nèi)容切到一半。
第三，輸出外面包了一層 <persisted-output> 標(biāo)簽。這個標(biāo)簽的作用是讓模型明確知道：
這是一個被持久化的大輸出 當(dāng)前只展示預(yù)覽 完整內(nèi)容在某個文件路徑里
這比直接寫一句“輸出太長省略了”更可靠。因?yàn)槟Ｐ筒粌H知道內(nèi)容被省略，還知道去哪里找。
第二層：不同工具有不同的結(jié)果上限
不是所有工具都用同一個策略。
源碼里有一個全局默認(rèn)上限：
DEFAULT_MAX_RESULT_SIZE_CHARS = 50_000
同時，不同工具會聲明自己的 maxResultSizeChars。例如：
Bash: 30_000 Grep: 20_000 Glob: 100_000 WebFetch: 100_000 Edit: 100_000 Write: 100_000 Read: Infinity
實(shí)際判斷時，會把工具自己的上限和全局默認(rèn)上限結(jié)合起來。通?？梢岳斫鉃椋?/p>
工具聲明一個上限 系統(tǒng)再用全局默認(rèn)上限做保護(hù) 最終得到這個工具的持久化閾值
例如 Bash 很容易產(chǎn)生大量日志，所以它的上限比默認(rèn)值更低：
Bash maxResultSizeChars = 30_000
Grep 也類似，因?yàn)橐淮嗡阉骺赡芊祷卮罅科ヅ湫校?/p>
Grep maxResultSizeChars = 20_000
而 Read 比較特殊：
Read maxResultSizeChars = Infinity
這表示它不會走普通的“輸出過大就持久化成 tool-results 預(yù)覽”邏輯。原因也很直接：Read 自身已經(jīng)有讀取范圍控制，例如 offset、limit、maxTokens 等。把 Read 的結(jié)果再保存成一個文件，然后讓模型再 Read 這個保存文件，會讓鏈路變得繞，而且收益不明顯。
所以這里不是“所有工具一刀切”，而是按工具特性分開處理：
Bash / Grep：容易產(chǎn)生巨量文本，更積極限制。 WebFetch / Glob / Edit / Write：也可能很大，需要系統(tǒng)默認(rèn)保護(hù)。 Read：讀取階段本身就受控，不走普通持久化回讀。
第三層：單個結(jié)果沒超限，但一輪結(jié)果合起來可能超限
上面講的是“單個工具結(jié)果過大”的情況。但真實(shí) Agent 執(zhí)行時，還有一個更隱蔽的問題：單個結(jié)果都不大，但一輪并發(fā)工具結(jié)果加起來很大。
例如一輪里并發(fā)跑了多個工具：
tool_result A: 40K tool_result B: 40K tool_result C: 40K tool_result D: 40K tool_result E: 40K tool_result F: 40K
每個結(jié)果單看都沒超過 50K，但這一輪合起來就是：
40K × 6 = 240K
這時如果全部塞進(jìn)一個 user message，仍然會給上下文造成很大壓力。
所以 Claude Code 還有一層“單輪聚合預(yù)算”。源碼里對應(yīng)的常量是：
MAX_TOOL_RESULTS_PER_MESSAGE_CHARS = 200_000
這個預(yù)算的單位是“一條 user message 里的所有 tool_result”。它不是統(tǒng)計(jì)整段歷史，也不是統(tǒng)計(jì)整個會話，而是看這一輪工具返回結(jié)果的合計(jì)大小。
源碼注釋里也強(qiáng)調(diào)了這一點(diǎn)：
Messages are evaluated independently.
也就是說：
第 1 輪有 150K tool_result：不處理 第 2 輪又有 150K tool_result：也不處理 同一輪里合計(jì)超過 200K：才觸發(fā)這一層預(yù)算
這樣設(shè)計(jì)的原因是，問題主要出現(xiàn)在“同一輪并發(fā)工具結(jié)果過多”。如果每輪都只有一個中等大小結(jié)果，系統(tǒng)不一定要強(qiáng)行替換；但如果一輪里多個工具同時返回，就需要避免這一輪直接把上下文撐得過大。
第四層：超過單輪預(yù)算后，優(yōu)先替換最大的 fresh 結(jié)果
當(dāng)某條 user message 里的多個 tool_result 合計(jì)超過預(yù)算時，Claude Code 不會把所有結(jié)果都替換掉，而是會優(yōu)先選擇最大的、剛出現(xiàn)的結(jié)果。
可以簡化理解為：
1. 收集當(dāng)前 user message 里的 tool_result 2. 計(jì)算合計(jì)大小 3. 如果超過 200K，就從最大的 fresh tool_result 開始替換 4. 每替換一個，就把完整內(nèi)容落盤，上下文里放預(yù)覽 5. 直到這一組結(jié)果回到預(yù)算以內(nèi)
這里有兩個關(guān)鍵詞：最大 和 fresh。
“最大”很好理解。要降低上下文壓力，優(yōu)先處理體積最大的結(jié)果收益最高。
“fresh”更關(guān)鍵。它表示這個工具結(jié)果以前沒有被預(yù)算機(jī)制處理過。如果某個結(jié)果之前已經(jīng)被系統(tǒng)決定“保留原文”或“替換成預(yù)覽”，后續(xù)就不會隨便改變決定。
這就引出下一點(diǎn)：穩(wěn)定性。
第五層：替換決策必須穩(wěn)定，不能每輪變化
Claude Code 對上下文穩(wěn)定性非常敏感。原因是 prompt cache。
如果同一個 tool_result 第一輪是完整內(nèi)容，第二輪突然變成預(yù)覽，第三輪又因?yàn)槟承l件變化變回完整內(nèi)容，那么模型看到的歷史前綴就會不斷變化。這樣會影響 prompt cache，也會讓上下文表現(xiàn)變得不穩(wěn)定。
所以源碼里維護(hù)了一個 ContentReplacementState：
type ContentReplacementState = {
seenIds: Set<string>
replacements: Map<string, string>
}
它的含義可以這樣理解：
seenIds: 這個 tool_result 是否已經(jīng)被預(yù)算機(jī)制看過。 replacements: 如果它被替換過，這里保存模型當(dāng)時看到的那份預(yù)覽文本。
一旦某個工具結(jié)果被處理過，它的命運(yùn)就固定了：
之前保留原文的：后面繼續(xù)保留原文。 之前替換成預(yù)覽的：后面繼續(xù)用完全相同的預(yù)覽文本。
注意，是完全相同。
不是重新生成一份看起來差不多的預(yù)覽，而是直接從 replacements 里取出之前保存的字符串，原樣應(yīng)用。這樣可以保證后續(xù)請求里的 prompt 前綴保持穩(wěn)定。
源碼里還會把新的替換記錄寫入 transcript，方便 resume 后重建相同的替換狀態(tài)。否則用戶恢復(fù)會話后，同一個工具結(jié)果可能因?yàn)榇a版本、路徑格式、預(yù)覽模板變化而生成不同文本，導(dǎo)致上下文前綴發(fā)生變化。
這一點(diǎn)是這套機(jī)制能長期穩(wěn)定運(yùn)行的關(guān)鍵：
局部減負(fù)不只是減少 token。 它還要保證減少 token 的方式是可重復(fù)、可恢復(fù)、可緩存的。
小結(jié)
局部減負(fù)是 Claude Code 上下文壓縮鏈路里的第一道輕量處理。
它的核心邏輯可以概括為：
單個工具結(jié)果過大： 完整內(nèi)容保存到 tool-results 上下文里只保留 persisted-output 預(yù)覽和路徑 一輪工具結(jié)果合計(jì)過大： 按 user message 聚合 tool_result 超過預(yù)算后優(yōu)先替換最大的 fresh 結(jié)果 替換決策： 用 seenIds 和 replacements 固定下來 保證后續(xù)請求和 resume 后都能穩(wěn)定復(fù)現(xiàn)
所以，局部減負(fù)不是“壓縮整段上下文”，而是先處理最容易膨脹的工具輸出。它用很低的語義損耗換來明顯的 token 減壓，并且為后面的 Microcompact 和 Auto Compact 判斷爭取空間。
第二部分：Microcompact
講完“局部減負(fù)”以后，我們再看 Claude Code 上下文壓縮鏈路里的第二層：Microcompact。
局部減負(fù)處理的是“工具結(jié)果剛產(chǎn)生時太大怎么辦”。Microcompact 處理的是另一個問題：
工具結(jié)果已經(jīng)進(jìn)入歷史上下文了， 后面又經(jīng)過了很多輪對話， 這些舊 tool_result 是否還需要繼續(xù)完整保留？
所以 Microcompact 的核心不是總結(jié)對話，而是清理舊工具結(jié)果。它不負(fù)責(zé)理解用戶需求，也不負(fù)責(zé)把歷史對話改寫成 summary。它只針對一類內(nèi)容：歷史里的可清理工具結(jié)果。
可以先用一句話理解：
Microcompact = 在不重寫對話語義的前提下，減少舊 tool_result 占用的上下文空間。
它和局部減負(fù)有什么區(qū)別？
這兩個機(jī)制都和 tool_result 有關(guān)，所以容易混在一起。但它們處理的時間點(diǎn)不一樣。
局部減負(fù)： 工具結(jié)果剛返回時，如果單個結(jié)果過大，或同一輪結(jié)果合計(jì)過大， 就把完整結(jié)果落盤，只在上下文里放預(yù)覽和路徑。 Microcompact： 工具結(jié)果已經(jīng)進(jìn)入歷史，后續(xù)上下文繼續(xù)增長， 系統(tǒng)再判斷哪些舊 tool_result 可以從當(dāng)前上下文里清理。
換成執(zhí)行順序看，大致是：
工具剛返回 -> 局部減負(fù)先判斷它是否太大 -> 結(jié)果進(jìn)入歷史上下文 -> 后續(xù)多輪請求繼續(xù)攜帶這些歷史 -> Microcompact 再清理較舊的工具結(jié)果
也就是說，局部減負(fù)是“入口處理”，Microcompact 是“歷史維護(hù)”。
為什么 Microcompact 主要盯著 tool_result？
因?yàn)樵?Claude Code 這類編碼 Agent 里，tool_result 通常同時滿足兩個條件：
1. 體積大 2. 信息價(jià)值會隨時間下降
比如模型讀過一個文件：
assistant: 調(diào)用 Read tool_result(Read): 返回 src/main.ts 的完整內(nèi)容 assistant: 根據(jù)文件內(nèi)容定位問題 assistant: 修改代碼 assistant: 跑測試 assistant: 總結(jié)修復(fù)結(jié)果
剛讀完文件時，完整 tool_result 很重要。但經(jīng)過幾輪分析和修改后，模型可能已經(jīng)把關(guān)鍵結(jié)論寫進(jìn)了后續(xù)回復(fù)，或者已經(jīng)通過編輯結(jié)果體現(xiàn)了這些信息。此時舊的完整文件內(nèi)容繼續(xù)留在上下文里，價(jià)值就不一定匹配它占用的 token。
但用戶消息和 assistant 消息不一樣。
用戶消息可能包含真實(shí)需求、約束、糾正意見。assistant 消息可能包含已經(jīng)形成的任務(wù)判斷、計(jì)劃和下一步意圖。如果 Microcompact 隨便清這些內(nèi)容，就會直接影響對話語義。
所以它只選擇相對可控的一類目標(biāo)：
舊 tool_result
這也是為什么它叫 Microcompact，而不是 full compact。它只做局部清理，不做語義總結(jié)。
哪些工具結(jié)果可以被 Microcompact 處理？
源碼里有一個集合叫 COMPACTABLE_TOOLS，用來限定 Microcompact 可以處理哪些工具的結(jié)果。
它主要包括：
Read Shell / Bash 類工具 Grep Glob WebSearch WebFetch Edit Write
源碼邏輯不是直接掃描所有 tool_result，而是先從 assistant 消息里收集可壓縮工具的 tool_use id：
assistant message -> 找 tool_use -> 如果 tool name 在 COMPACTABLE_TOOLS 中 -> 記錄這個 tool_use.id
隨后再去 user 消息里找對應(yīng)的 tool_result：
user message -> 找 tool_result -> 如果 tool_result.tool_use_id 在可壓縮 id 集合里 -> 這個結(jié)果才有資格被 Microcompact 處理
這點(diǎn)很重要。Microcompact 不是只看 tool_result 本身，它會通過 tool_use_id 把工具調(diào)用和工具結(jié)果對應(yīng)起來。這樣系統(tǒng)就知道：
這個結(jié)果來自哪個工具 這個工具是否屬于允許清理的類型
Microcompact 有兩條主要路徑
Microcompact 的兩條路徑，核心區(qū)別在于：當(dāng)前還要不要盡量保護(hù) prompt cache。
如果 prompt cache 仍然可用，直接修改本地歷史消息會破壞緩存前綴。更穩(wěn)的做法是：本地 messages 不動，只在請求層告訴服務(wù)端，哪些舊工具結(jié)果對應(yīng)的緩存內(nèi)容可以刪除。這就是 Cached Microcompact 的思路。
如果會話已經(jīng)空閑較久，服務(wù)端緩存大概率已經(jīng)失效，那么繼續(xù)保護(hù)緩存前綴的意義就變小了。這時可以更直接地修改本地上下文，把更早的舊 tool_result 正文替換成占位符。這就是 Time-based Microcompact 的思路。
可以這樣對比：
Cached Microcompact： 本地 messages 不變 通過 cache_edits 刪除服務(wù)端緩存里的舊 tool_result 重點(diǎn)是盡量不破壞已有緩存前綴 Time-based Microcompact： 直接修改本地 messages 把舊 tool_result 正文替換成固定占位符 重點(diǎn)是減少下一次請求實(shí)際發(fā)送的內(nèi)容
這兩個路徑都不是語義壓縮。它們不會生成 summary，也不會重新整理用戶需求。
第一條路徑：Cached Microcompact
Cached Microcompact 的處理對象不是本地消息正文，而是服務(wù)端緩存中的舊工具結(jié)果。
它的大致過程是：
1. 記錄歷史里有哪些可壓縮 tool_result 2. 判斷哪些舊工具結(jié)果可以刪除緩存 3. 生成 cache_edits 刪除指令 4. 在下一次 API 請求里帶上這些刪除指令
這樣做的結(jié)果是：
本地對話歷史仍然完整 模型請求里的消息結(jié)構(gòu)不被重寫 服務(wù)端可以釋放部分舊工具結(jié)果的緩存內(nèi)容
這里有一個細(xì)節(jié)：cache_edits 本身也要放在穩(wěn)定的位置。
如果這次把刪除指令放在某個 user message 后面，下次又換到另一個位置，那么請求前綴仍然會變化。為了避免這種情況，系統(tǒng)會把這些刪除指令固定在原來的插入位置，后續(xù)請求繼續(xù)按相同位置發(fā)送。
所以 Cached Microcompact 的關(guān)鍵點(diǎn)是：
不改本地 messages 刪除動作通過 cache_edits 表達(dá) cache_edits 的位置也要穩(wěn)定
不過要注意：在 pengchengneo/Claude-Code 這份源碼里，Cached Microcompact 屬于 feature-gated 的內(nèi)部路徑，相關(guān)模塊沒有完整展開。這里重點(diǎn)看它的機(jī)制設(shè)計(jì)，不把它當(dāng)成所有構(gòu)建默認(rèn)啟用的能力。
第二條路徑：Time-based Microcompact
Time-based Microcompact 的判斷依據(jù)是會話空閑時間。
如果距離上一次主循環(huán) assistant 消息已經(jīng)超過閾值，例如 60 分鐘，那么服務(wù)端 prompt cache 大概率已經(jīng)過期。下一次請求本來就需要重新建立緩存前綴，這時繼續(xù)保留大量舊工具結(jié)果的收益就不高。
這條路徑會直接處理本地消息：
1. 收集所有可壓縮工具的 tool_use_id 2. 保留較新的工具結(jié)果 3. 把更早的舊 tool_result 正文替換成占位符
占位符是固定字符串：
[Old tool result content cleared]
替換前后可以理解為：
替換前： tool_result(Read): 很長的文件內(nèi)容…… 替換后： tool_result(Read): [Old tool result content cleared]
注意，這里仍然保留了 tool_result 這個 block 本身，也保留了它的 tool_use_id。被替換的是內(nèi)容正文。
這樣做是為了保留工具調(diào)用結(jié)構(gòu)的合法性。Claude 的工具調(diào)用通常是：
assistant: tool_use(id = xxx) user: tool_result(tool_use_id = xxx)
如果直接刪除整個 tool_result，就可能破壞 tool_use / tool_result 的對應(yīng)關(guān)系。Time-based Microcompact 選擇替換正文，而不是刪除消息，就是為了在減少 token 的同時保留結(jié)構(gòu)完整性。
小結(jié)
Microcompact 是 Claude Code 上下文管理里的輕量清理機(jī)制。
它的核心邏輯可以概括為：
處理對象： 歷史里的可壓縮 tool_result 不處理： 用戶消息 assistant 普通回復(fù) 對話語義 summary 兩條路徑： Cached Microcompact：通過 cache_edits 清理服務(wù)端緩存，不改本地 messages Time-based Microcompact：緩存大概率失效后，直接把舊 tool_result 正文替換成占位符 核心價(jià)值： 清理舊工具結(jié)果占用 保持消息結(jié)構(gòu)合法 盡量避免直接重寫對話語義
所以，Microcompact 不是“把對話壓縮成摘要”。它更準(zhǔn)確的定位是：在完整語義壓縮之前，先清理歷史里低時效、高體積的工具結(jié)果。
第三部分：閾值判斷
前面兩層已經(jīng)做了輕量減負(fù)：
局部減負(fù)：處理剛產(chǎn)生的大工具輸出。 Microcompact：清理歷史里的舊 tool_result。
但清理完以后，還要判斷一個問題：
當(dāng)前上下文是否已經(jīng)接近模型窗口上限？ 如果繼續(xù)正常請求，會不會沒有足夠空間完成下一輪？
這就是閾值判斷的作用。
它本身不壓縮內(nèi)容，只負(fù)責(zé)決定是否觸發(fā)完整 Auto Compact。
核心判斷公式
Claude Code 不會等上下文窗口真正用滿才 compact，因?yàn)?compact 本身也需要輸出空間。完整 compact 要讓模型生成 summary，如果窗口已經(jīng)被輸入占滿，summary 就沒有足夠空間輸出。
所以它會先預(yù)留一段 summary 輸出空間：
MAX_OUTPUT_TOKENS_FOR_SUMMARY = 20_000
然后得到一個有效窗口：
effectiveWindow = contextWindow - reservedSummaryOutputTokens
接著還要再扣一段安全 buffer：
AUTOCOMPACT_BUFFER_TOKENS = 13_000
這個 buffer 和前面的 summary 輸出預(yù)留不是一回事。
summary 輸出預(yù)留，是給 compact 之后模型生成摘要用的；這里的 13k buffer，是給“當(dāng)前請求繼續(xù)膨脹”留的余量。因?yàn)樵谡嬲l(fā)起下一次模型請求前，上下文里可能還會追加系統(tǒng)提示、附件、工具說明、hook 結(jié)果，token 估算本身也可能有誤差。如果等到剛好貼著 effectiveWindow 才 compact，就很容易在實(shí)際請求時超過窗口。
最終觸發(fā)線可以簡化成：
autoCompactThreshold = effectiveWindow - 13_000 shouldCompact = currentTokenCount >= autoCompactThreshold
舉個數(shù)字例子：
模型總窗口：200k summary 輸出預(yù)留：20k effectiveWindow：180k Auto Compact buffer：13k 觸發(fā)線：167k
也就是說：
當(dāng)前上下文 >= 167k tokens => 先 Auto Compact 當(dāng)前上下文 < 167k tokens => 繼續(xù)正常請求
小結(jié)
閾值判斷是 Auto Compact 前的一層決策邏輯。
它的核心就是：
先扣 summary 輸出預(yù)留 再扣安全 buffer 得到 Auto Compact 觸發(fā)線 再用當(dāng)前上下文 token 數(shù)和觸發(fā)線比較
如果沒到觸發(fā)線，繼續(xù)正常請求；如果到了觸發(fā)線，就先進(jìn)入完整 compact。它不負(fù)責(zé)壓縮內(nèi)容，只負(fù)責(zé)決定什么時候必須壓縮。
第四部分：語義壓縮
前面的幾層都還屬于輕量處理：
局部減負(fù)：把大工具輸出換成預(yù)覽和路徑。 Microcompact：清理歷史里的舊 tool_result。 閾值判斷：判斷是否已經(jīng)需要完整 compact。
如果閾值判斷發(fā)現(xiàn)上下文已經(jīng)接近上限，Claude Code 就會進(jìn)入完整 compact。這個階段才是真正的語義壓縮。
語義壓縮要解決的問題是：
舊對話太長，不能繼續(xù)完整塞進(jìn)上下文； 但舊對話里有任務(wù)目標(biāo)、技術(shù)結(jié)論、修改記錄、錯誤處理、當(dāng)前進(jìn)度， 這些信息不能直接丟。
所以它不是簡單刪歷史，而是把舊歷史改寫成一份 compact summary，讓模型能繼續(xù)理解當(dāng)前任務(wù)。
一句話概括：
語義壓縮 = 用一份更短的 summary 承接舊對話里的任務(wù)語義。
語義壓縮的兩條來源
Claude Code 生成 compact summary 主要有兩條來源：
1. 優(yōu)先嘗試使用 session memory 2. 如果不可用，再調(diào)用模型生成 summary
1. 使用 session memory
session memory 可以理解成會話過程中沉淀下來的任務(wù)記憶。它不是等到 compact 觸發(fā)時才臨時生成，而是在會話推進(jìn)過程中就可能記錄一些長期信息。
它通常會包含：
用戶目標(biāo) 當(dāng)前任務(wù)進(jìn)度 關(guān)鍵文件 重要技術(shù)決策 已經(jīng)解決的問題 后續(xù)要繼續(xù)做的事情
如果 session memory 存在、不是空模板，并且用它壓縮后上下文仍然足夠短，系統(tǒng)就可以直接把它包裝成 compact summary。
這條路徑的優(yōu)勢是：
不需要再調(diào)用模型重新總結(jié)整段歷史 速度更快 成本更低 失敗概率更小
但它不是無條件使用。系統(tǒng)會檢查：
session memory 是否存在 內(nèi)容是否為空 是否能確定哪些消息已經(jīng)被總結(jié)過 壓縮后的上下文是否仍然超過閾值
如果這些條件不滿足，就會進(jìn)入傳統(tǒng) compact。
2. 調(diào)用模型生成 compact summary
如果 session memory 不可用，Claude Code 會發(fā)起一次專門的 compact 調(diào)用，讓模型總結(jié)舊對話。
這次調(diào)用和普通對話不同。它的任務(wù)非常明確：
只生成總結(jié) 不繼續(xù)執(zhí)行用戶任務(wù) 不調(diào)用工具
compact prompt 會要求模型重點(diǎn)保留這些內(nèi)容：
1. 用戶的主要請求和真實(shí)意圖 2. 關(guān)鍵技術(shù)概念 3. 看過、改過、創(chuàng)建過的文件和代碼片段 4. 遇到的錯誤以及修復(fù)方式 5. 已解決的問題和仍在處理的問題 6. 所有非工具類用戶消息 7. 待辦任務(wù) 8. 當(dāng)前正在做什么 9. 下一步應(yīng)該做什么
這說明 compact summary 不是普通摘要。
普通摘要可能只寫：
用戶在討論上下文壓縮，并要求寫文章。
這類摘要對 Agent 繼續(xù)工作幫助很小。
Claude Code 需要的是能繼續(xù)執(zhí)行的 summary，例如：
用戶正在寫一篇關(guān)于 Claude Code 上下文壓縮的技術(shù)文章。 文章拆成局部減負(fù)、Microcompact、閾值判斷、語義壓縮、狀態(tài)恢復(fù)五部分。 已完成前三部分的講解，要求整體風(fēng)格專業(yè)、直觀，并盡量貼近源碼機(jī)制。 當(dāng)前正在撰寫語義壓縮部分，下一步應(yīng)解釋 full compact 如何把舊歷史變成 summary。
這種 summary 才能承接任務(wù)狀態(tài)。
為什么還要保留最近消息？
完整 compact 并不是把所有舊消息都替換成 summary。
原因是 summary 適合承接較早的歷史，但最近幾輪通常包含更具體的現(xiàn)場信息，例如：
用戶剛剛提出的修正意見 剛剛生成或修改的內(nèi)容 剛剛執(zhí)行的工具結(jié)果 最后一步卡在哪里
這些內(nèi)容如果全部進(jìn)入 summary，可能會丟失細(xì)節(jié)。
所以 Claude Code 會保留一段最近原始消息，并且在保留時注意消息結(jié)構(gòu)合法性，尤其不能拆開工具調(diào)用關(guān)系：
assistant: tool_use(id = xxx) user: tool_result(tool_use_id = xxx)
如果只保留 tool_result，卻刪掉對應(yīng)的 tool_use，API 會認(rèn)為這個工具結(jié)果沒有來源。因此保留最近消息時，需要確保 tool_use / tool_result 成對存在。
這一步的目的不是保存更多歷史，而是避免 compact 后的上下文結(jié)構(gòu)出錯，同時保留最近現(xiàn)場。
compact summary 會被包裝成一條繼續(xù)執(zhí)行指令
模型生成 summary 之后，Claude Code 不會直接把原始 summary 原封不動塞回上下文。
它會把 summary 包裝成一條新的用戶消息，大意是：
這個會話是從之前一個上下文不足的會話繼續(xù)來的。 下面是舊會話的摘要。 請直接從斷點(diǎn)繼續(xù)，不要重新問用戶，不要復(fù)述摘要。
這個包裝很關(guān)鍵。
因?yàn)?compact 后，模型看到的是一個新的上下文。如果只給它一段 summary，而不告訴它“繼續(xù)執(zhí)行”，模型可能會把 summary 當(dāng)成普通資料閱讀，然后重新詢問用戶下一步。
Claude Code 希望的是：
模型讀完 summary 后，直接接著之前的任務(wù)繼續(xù)。
所以 compact summary 不只是信息壓縮結(jié)果，也帶有繼續(xù)執(zhí)行的指令。
compact boundary 的作用
完整 compact 后，系統(tǒng)會創(chuàng)建一個 compact_boundary。
它的作用是標(biāo)記：
舊歷史到這里已經(jīng)被壓縮。 后續(xù)恢復(fù)會話時，從這個邊界之后重建上下文。
壓縮后的上下文大致是：
舊消息 舊消息 舊消息 compact boundary compact summary 最近保留的原始消息 必要的附件和 hook 結(jié)果
這里先只關(guān)注前兩項(xiàng)：
boundary：標(biāo)記舊歷史已經(jīng)壓縮 summary：承接舊歷史語義
后面的附件、hook、文件狀態(tài)、計(jì)劃狀態(tài)等內(nèi)容，會在“狀態(tài)恢復(fù)”部分單獨(dú)講。
小結(jié)
語義壓縮是完整 compact 的核心。
它不是清理某個工具結(jié)果，也不是簡單截?cái)鄽v史，而是把舊對話里的任務(wù)語義轉(zhuǎn)換成 compact summary。
核心流程可以概括為：
1. 觸發(fā)完整 compact 2. 優(yōu)先嘗試使用 session memory 3. 如果不可用，調(diào)用模型生成 compact summary 4. 保留必要的最近原始消息 5. 創(chuàng)建 compact boundary 6. 把 summary 包裝成“繼續(xù)執(zhí)行”的上下文消息
最終目標(biāo)是：
舊歷史不再完整占用上下文， 但模型仍然知道任務(wù)目標(biāo)、當(dāng)前進(jìn)度和下一步方向。
第五部分：狀態(tài)恢復(fù)
語義壓縮完成之后，上下文并不是只剩下一段 summary 就結(jié)束了。
summary 解決的是“歷史發(fā)生過什么”的問題，但 Claude Code 繼續(xù)執(zhí)行任務(wù)時，還需要很多更具體的運(yùn)行信息：
最近讀過哪些文件？ 這些文件當(dāng)前內(nèi)容是什么？ 當(dāng)前有沒有 plan？ 是否仍然處于 plan mode？ 之前調(diào)用過哪些 skills？ 當(dāng)前有哪些工具、Agent、MCP 說明需要重新告訴模型？ 有沒有后臺 agent 還在運(yùn)行，或者結(jié)果還沒取回？ 項(xiàng)目規(guī)則、環(huán)境說明、hooks 注入內(nèi)容是否還需要補(bǔ)回來？
這些內(nèi)容不完全屬于“對話歷史”。它們更接近任務(wù)運(yùn)行時的狀態(tài)。如果壓縮后只保留 summary，模型可能知道任務(wù)大方向，卻缺少繼續(xù)執(zhí)行所需的文件、計(jì)劃、工具和規(guī)則。
所以 Claude Code 在 compact 之后還會做一層狀態(tài)恢復(fù)：把繼續(xù)工作必需的運(yùn)行狀態(tài)重新拼回壓縮后的上下文。
壓縮后的上下文長什么樣？
源碼里，壓縮結(jié)果最后會通過 buildPostCompactMessages 重新組裝成一組消息，順序是：
boundaryMarker summaryMessages messagesToKeep attachments hookResults
也就是：
flowchart TD A["compact boundary<br/>標(biāo)記舊上下文已壓縮"] --> B["compact summary<br/>壓縮后的歷史摘要"] B --> C["messagesToKeep<br/>保留的最近原始消息"] C --> D["attachments<br/>文件 / 計(jì)劃 / skills / 工具說明 / agent 狀態(tài)"] D --> E["hookResults<br/>hooks 重新注入的上下文"] E --> F["模型基于新上下文繼續(xù)工作"]
這里可以把它拆成兩層理解：
summaryMessages：負(fù)責(zé)承接舊歷史 attachments / hookResults：負(fù)責(zé)補(bǔ)回繼續(xù)執(zhí)行所需的運(yùn)行狀態(tài)
狀態(tài)恢復(fù)主要發(fā)生在后半部分，也就是把各種 attachments 和 hookResults 補(bǔ)回去。
第一類：恢復(fù)最近文件內(nèi)容
Claude Code 在 compact 前會記錄 readFileState。這個狀態(tài)里保存了模型最近讀過的文件，以及這些文件的訪問時間。
compact 成功后，它不會把所有讀過的文件都重新塞回上下文，而是按最近訪問時間排序，優(yōu)先恢復(fù)最可能繼續(xù)用到的文件。
恢復(fù)文件時有幾個限制：
最多恢復(fù) 5 個文件 每個文件最多約 5k tokens 文件恢復(fù)總預(yù)算約 50k tokens
這個設(shè)計(jì)很關(guān)鍵。因?yàn)?summary 里寫“正在修改 app.ts”，并不等于模型真的看得見 app.ts 的當(dāng)前內(nèi)容。
如果不恢復(fù)最近文件，壓縮后的模型可能只能依賴摘要判斷代碼狀態(tài)。這樣一來，要么它需要重新讀取文件，要么它會基于不完整信息繼續(xù)寫代碼。狀態(tài)恢復(fù)就是為了減少這種斷層：壓縮歷史可以變短，但關(guān)鍵文件內(nèi)容要盡量重新放回模型眼前。
另外，源碼里還會跳過已經(jīng)包含在保留消息里的 Read 結(jié)果。也就是說，如果某個文件讀取結(jié)果已經(jīng)在 messagesToKeep 里，就沒必要再通過 file attachment 重復(fù)注入一次。
第二類：恢復(fù)計(jì)劃和 plan mode
如果當(dāng)前會話里存在 plan，Claude Code 會生成一個 plan_file_reference attachment，把計(jì)劃文件路徑和計(jì)劃內(nèi)容一起放回上下文。
這一步解決的是任務(wù)進(jìn)度問題。
summary 可能會寫“接下來繼續(xù)做狀態(tài)恢復(fù)章節(jié)”，但 plan 通常包含更結(jié)構(gòu)化的任務(wù)分解、完成狀態(tài)和下一步安排。把 plan 恢復(fù)回來，可以讓模型壓縮后繼續(xù)沿著原來的任務(wù)計(jì)劃推進(jìn)，而不是只靠 summary 里的幾句話重新判斷。
如果當(dāng)前仍然處于 plan mode，Claude Code 還會額外生成 plan_mode attachment。
這個 attachment 的意義是告訴模型：
壓縮發(fā)生了，但當(dāng)前權(quán)限/工作模式?jīng)]有變 如果壓縮前還在 plan mode，壓縮后仍然要按 plan mode 的規(guī)則工作
否則模型可能在 compact 后丟失模式信息，把“只能規(guī)劃，不能直接改文件”的階段誤當(dāng)成普通執(zhí)行階段。
第三類：恢復(fù)已經(jīng)調(diào)用過的 skills
如果壓縮前調(diào)用過 skill，Claude Code 會把這些已經(jīng)使用過的 skill 內(nèi)容重新注入為 invoked_skills attachment。
這不是簡單記錄一句“之前用過某個 skill”，而是把 skill 的具體規(guī)則重新提供給模型。原因很直接：summary 可以概括事實(shí)，但不能保證完整保留 skill 里的操作要求、約束和檢查流程。
例如，壓縮前如果使用過某個文檔處理或前端設(shè)計(jì) skill，后續(xù)繼續(xù)工作時，模型仍然需要遵守那個 skill 的具體規(guī)則。只在 summary 里寫一句“使用了某某 skill”，約束力度是不夠的。
不過這部分同樣有預(yù)算控制：
每個 skill 最多約 5k tokens skills 總預(yù)算約 25k tokens 最近調(diào)用的 skill 優(yōu)先保留
這里的邏輯是：壓縮后最應(yīng)該恢復(fù)的，是近期仍可能影響當(dāng)前任務(wù)的規(guī)則，而不是把所有歷史 skill 無限追加回來。
第四類：恢復(fù)工具、Agent、MCP 說明
壓縮會移除大量舊消息，其中可能包含工具說明、Agent 列表變化、MCP 服務(wù)說明等上下文。
所以 compact 后，Claude Code 會重新生成幾類說明：
deferred_tools_delta：當(dāng)前有哪些延遲加載工具可通過 ToolSearch 使用 agent_listing_delta：當(dāng)前有哪些 Agent 類型可用 mcp_instructions_delta：當(dāng)前連接的 MCP 服務(wù)有哪些使用說明
這部分恢復(fù)的不是任務(wù)內(nèi)容，而是“模型現(xiàn)在能調(diào)用什么能力，以及這些能力應(yīng)該怎么用”。
如果缺少這一步，模型可能還記得用戶要做什么，但不知道當(dāng)前工具環(huán)境是什么。例如它可能不知道某些 deferred tools 已經(jīng)可用，也可能不知道某個 MCP server 提供了額外規(guī)則。
源碼里在 compact 后會把這些 delta attachment 重新加回去，相當(dāng)于對壓縮后的模型重新聲明當(dāng)前可用能力。
第五類：恢復(fù)后臺 agent 狀態(tài)
Claude Code 還會檢查當(dāng)前是否存在異步 agent 任務(wù)。
如果某個后臺 agent 還在運(yùn)行，或者已經(jīng)結(jié)束但結(jié)果還沒有被取回，compact 后會生成 task_status attachment。它會告訴模型：
后臺任務(wù)的 taskId 任務(wù)描述 當(dāng)前狀態(tài) 進(jìn)度摘要或錯誤信息 輸出文件路徑
這一步主要是為了避免壓縮后丟失后臺任務(wù)狀態(tài)。
否則模型可能不知道已經(jīng)有一個 agent 在處理同類任務(wù)，于是重復(fù)啟動新的 agent；或者它不知道某個 agent 已經(jīng)完成，從而沒有去讀取已有結(jié)果。
對于壓縮后的連續(xù)執(zhí)行來說，后臺任務(wù)不是普通聊天記錄，而是仍然影響后續(xù)決策的運(yùn)行狀態(tài)。
第六類：執(zhí)行 hooks
compact 前后還會涉及 hooks。
這部分可以分成三類：
PreCompact hooks：壓縮前執(zhí)行，可以補(bǔ)充壓縮相關(guān)指令 SessionStart hooks：壓縮成功后執(zhí)行，用 compact 作為觸發(fā)來源 PostCompact hooks：壓縮完成后執(zhí)行，用于額外處理或展示
其中最影響“狀態(tài)恢復(fù)”的，是 compact 后重新執(zhí)行的 SessionStart hooks。
因?yàn)?compact 后的上下文在某種意義上是一個新的起點(diǎn)，Claude Code 需要重新注入一些會話啟動時才會出現(xiàn)的上下文，例如項(xiàng)目規(guī)則、環(huán)境說明、團(tuán)隊(duì)約定、安全限制等。
如果這些內(nèi)容不補(bǔ)回來，模型可能保留了任務(wù)摘要，卻丟掉了項(xiàng)目級約束。對于代碼任務(wù)來說，這類約束往往比歷史閑聊更重要。
小結(jié)
狀態(tài)恢復(fù)不是再次總結(jié)歷史，而是解決 compact 之后“還能不能繼續(xù)正常工作”的問題。
語義壓縮關(guān)心的是：
舊上下文太長，能不能壓成一段可繼續(xù)理解的 summary？
狀態(tài)恢復(fù)關(guān)心的是：
壓縮之后，模型是否仍然擁有繼續(xù)執(zhí)行任務(wù)所需的文件、計(jì)劃、工具、規(guī)則和后臺任務(wù)狀態(tài)？
所以完整的 compact 不能只看 summary 生成得好不好，還要看 summary 后面有沒有把關(guān)鍵運(yùn)行狀態(tài)補(bǔ)回來。
最終總結(jié)：上下文壓縮到底在壓什么？
看到這里，我們可以把 Claude Code 的上下文壓縮重新拉回到一條主線上。
它并不是等上下文快到上限了，再直接把前面的聊天記錄截掉；也不是把所有內(nèi)容丟給模型，讓模型生成一段 summary 就完事。真正的上下文壓縮，其實(shí)是一套分層處理機(jī)制。
這套機(jī)制大概可以這樣理解：
先處理最容易膨脹的工具結(jié)果 再清理歷史里低時效的大塊 tool_result 然后判斷當(dāng)前 token 是否真的接近危險(xiǎn)線 如果必須完整壓縮，再生成 compact summary 最后把繼續(xù)工作所需的運(yùn)行狀態(tài)補(bǔ)回來
也就是說，Claude Code 不是一上來就做“完整壓縮”。它會先用更便宜、更局部的方式減輕上下文壓力，只有當(dāng)上下文真的接近上限時，才進(jìn)入完整 compact。
五個部分串起來看
前面講的五個部分，其實(shí)分別承擔(dān)了不同職責(zé)：
局部減負(fù)： 處理當(dāng)前鏈路里過大的工具輸出。 重點(diǎn)是別讓某一次工具結(jié)果直接把上下文撐大。 Microcompact： 清理歷史中已經(jīng)不那么新鮮、但體積很大的 tool_result。 重點(diǎn)是減少舊工具結(jié)果長期占用上下文。 閾值判斷： 判斷現(xiàn)在是不是必須進(jìn)入完整 compact。 重點(diǎn)是給 summary 輸出和后續(xù)請求預(yù)留安全空間。 語義壓縮： 把舊對話歷史壓成 compact summary。 重點(diǎn)是保留任務(wù)目標(biāo)、關(guān)鍵進(jìn)展、用戶要求和下一步方向。 狀態(tài)恢復(fù)： 在 summary 之外，把文件、計(jì)劃、skills、工具說明、后臺任務(wù)和 hooks 補(bǔ)回來。 重點(diǎn)是讓模型壓縮后還能繼續(xù)正常工作。
如果畫成一條鏈路，就是：
flowchart LR A["局部減負(fù)<br/>控制當(dāng)前工具輸出"] --> B["Microcompact<br/>清理歷史工具結(jié)果"] B --> C["閾值判斷<br/>決定是否完整 compact"] C --> D["語義壓縮<br/>生成 compact summary"] D --> E["狀態(tài)恢復(fù)<br/>補(bǔ)回運(yùn)行狀態(tài)"] E --> F["新上下文<br/>繼續(xù)執(zhí)行任務(wù)"]
這條鏈路里，每一層都不是重復(fù)工作，而是在解決不同問題。
關(guān)鍵點(diǎn)一：壓縮不是越早越好
上下文壓縮的目標(biāo)不是“看到大上下文就壓”，而是在信息完整性和 token 成本之間做平衡。
如果壓得太早，模型會丟掉本來還能直接利用的細(xì)節(jié)；如果壓得太晚，又可能在下一次請求時直接撞到上下文窗口上限。
所以 Claude Code 需要閾值判斷。
它會先扣掉 summary 輸出預(yù)留，再扣掉安全 buffer，最后得到 Auto Compact 的觸發(fā)線。只有當(dāng)前上下文 token 數(shù)真正接近這條線，才會觸發(fā)完整 compact。
這也是為什么上下文壓縮不是一個單純的“文本處理問題”，它首先是一個預(yù)算管理問題。token 不會因?yàn)槲覀儗懙谜J(rèn)真就自動變多，必要的預(yù)留和閾值必須算清楚。
關(guān)鍵點(diǎn)二：工具結(jié)果是最需要治理的對象
在 Agent 類應(yīng)用里，真正容易把上下文撐大的，往往不是用戶說了多少話，而是工具返回了多少東西。
一次搜索、一段日志、一個大文件讀取結(jié)果、一批 shell 輸出，都可能比普通對話大得多。
所以 Claude Code 的上下文壓縮鏈路里，前兩層都在處理工具結(jié)果：
局部減負(fù)：處理當(dāng)前這輪過大的工具結(jié)果 Microcompact：處理歷史里舊的大塊工具結(jié)果
這說明一個很重要的設(shè)計(jì)思路：不要等所有內(nèi)容都積累到難以處理時再統(tǒng)一壓縮，而是先把最容易失控的部分管起來。
工具結(jié)果通常有一個特點(diǎn)：它們對當(dāng)前任務(wù)很重要，但并不是所有原文都需要長期留在上下文里。該保留路徑就保留路徑，該替換占位符就替換占位符，該清理緩存就清理緩存。
關(guān)鍵點(diǎn)三：summary 不是壓縮的終點(diǎn)
很多人一提到上下文壓縮，第一反應(yīng)就是“生成摘要”。
但在 Claude Code 里，summary 只是完整 compact 的核心之一，不是全部。
因?yàn)槟Ｐ屠^續(xù)工作時，不只需要知道“之前發(fā)生了什么”，還需要知道“現(xiàn)在手上有什么”。
比如：
最近關(guān)鍵文件的真實(shí)內(nèi)容 當(dāng)前 plan 和 plan mode 已經(jīng)調(diào)用過的 skills 規(guī)則 當(dāng)前可用工具、Agent、MCP 說明 后臺 agent 的運(yùn)行狀態(tài) hooks 注入的項(xiàng)目規(guī)則和環(huán)境說明
這些東西不適合全都塞進(jìn) summary。summary 應(yīng)該承接歷史語義，而運(yùn)行狀態(tài)應(yīng)該通過 attachments 和 hookResults 重新補(bǔ)回來。
所以完整 compact 的重點(diǎn)不是“生成一段看起來不錯的摘要”，而是：
舊歷史能被 summary 接住， 新上下文還能支撐模型繼續(xù)執(zhí)行。
最后再收束一下
如果只用一句話總結(jié) Claude Code 的上下文壓縮：
它不是簡單縮短聊天記錄，而是在有限 token 窗口里，盡量保留繼續(xù)完成任務(wù)所需的信息。
這里的“信息”分成兩類：
語義信息： 用戶目標(biāo)是什么？ 已經(jīng)做了什么？ 當(dāng)前進(jìn)展到哪里？ 下一步應(yīng)該做什么？ 運(yùn)行狀態(tài)： 關(guān)鍵文件在哪里？ 文件內(nèi)容是什么？ 當(dāng)前計(jì)劃是什么？ 有哪些工具和規(guī)則可用？ 后臺任務(wù)有沒有結(jié)果？
理解了這兩類信息，也就理解了為什么 Claude Code 要把上下文壓縮拆成這么多層。
局部減負(fù)和 Microcompact 負(fù)責(zé)先把工具輸出的壓力降下來；閾值判斷負(fù)責(zé)決定什么時候不能再拖；語義壓縮負(fù)責(zé)把舊歷史變成 summary；狀態(tài)恢復(fù)負(fù)責(zé)讓壓縮后的模型還能接著干活。
上下文壓縮真正難的地方，不是“少放點(diǎn)內(nèi)容”，而是知道哪些內(nèi)容可以少放，哪些內(nèi)容必須換一種形式繼續(xù)保留。
這也是 Agent 工程里很核心的一點(diǎn)：上下文窗口再大，也不應(yīng)該被隨意消耗；窗口再有限，也不能壓到模型失去工作能力。好的上下文壓縮，應(yīng)該讓模型變輕，但不能讓模型變糊涂。
到此這篇關(guān)于一文帶你徹底搞懂claude code中的上下文壓縮的文章就介紹到這了,更多相關(guān)claude code 上下文壓縮內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持腳本之家！
相關(guān)文章
上下文壓縮是ClaudeCode處理模型上下文膨脹的關(guān)鍵機(jī)制,涉及局部減負(fù)、Microcompact、閾值判斷;語義壓縮和狀態(tài)恢復(fù)五層處理,它不是簡單壓縮聊天記錄,而是通過多層處理,確保2026-06-28
