[{"data":1,"prerenderedAt":2009},["ShallowReactive",2],{"post-\u002Fposts\u002Fclaude-code-context-management":3,"all-posts-nav":1722},{"id":4,"title":5,"body":6,"categories":1705,"date":1707,"description":12,"draft":1708,"extension":1709,"hidden":1708,"meta":1710,"navigation":1711,"path":1712,"published":1708,"seo":1713,"stem":1714,"tags":1715,"__hash__":1721},"posts\u002Fposts\u002Fclaude-code-context-management.md","Claude Code 上下文管理机制：从 Microcompact 到 Auto Compact",{"type":7,"value":8,"toc":1639},"minimark",[9,13,16,39,45,48,59,62,66,69,73,78,81,84,87,102,106,108,111,114,130,133,147,154,158,160,163,169,172,176,178,181,184,198,202,204,207,210,214,217,224,244,255,259,262,265,280,283,294,300,303,307,310,313,345,352,356,359,362,365,424,427,431,433,436,438,497,500,506,524,527,531,533,536,539,571,574,580,583,587,589,592,595,611,614,620,623,627,629,632,655,658,662,664,670,674,676,679,683,685,688,700,703,707,711,714,717,747,757,760,766,769,773,776,779,815,824,826,832,835,839,841,843,871,877,879,885,887,890,893,897,900,906,909,912,916,919,922,936,939,943,949,966,969,973,976,979,982,999,1002,1005,1032,1035,1039,1042,1045,1048,1051,1055,1058,1061,1081,1084,1090,1093,1096,1100,1103,1106,1109,1129,1132,1138,1141,1145,1148,1151,1157,1160,1164,1167,1170,1194,1199,1203,1206,1209,1226,1229,1231,1235,1238,1244,1247,1250,1256,1259,1262,1265,1267,1271,1274,1277,1283,1286,1292,1295,1315,1318,1320,1323,1326,1330,1333,1347,1350,1354,1357,1371,1374,1377,1380,1394,1398,1401,1407,1410,1414,1417,1428,1430,1433,1436,1440,1443,1446,1463,1466,1472,1476,1479,1481,1501,1503,1509,1513,1516,1518,1532,1534,1540,1542,1545,1549,1552,1555,1559,1561,1564,1568,1570,1573,1577,1579,1582,1586,1588,1591,1595,1597,1603,1605,1608,1614,1616,1619,1622,1625],[10,11,12],"p",{},"这篇文章整理的是 Claude Code 上下文管理机制的源码阅读笔记。先给结论：",[10,14,15],{},"Claude Code 的上下文管理不是一个固定的“60% 用 A、70% 用 B、80% 用 C”的十层阶梯。更准确地说，它是三部分组合：",[17,18,19,27,33],"ol",{},[20,21,22,26],"li",{},[23,24,25],"strong",{},"请求前的轻量优化链路","：在每次请求发给模型之前，先尽量减少重复内容和旧工具结果。",[20,28,29,32],{},[23,30,31],{},"Auto Compact 高水位兜底","：当上下文接近上限时，自动触发 Session Memory Compact；如果不适用，再触发 Full Compact。",[20,34,35,38],{},[23,36,37],{},"API 报错后的应急恢复","：如果真正调用模型时出现 prompt too long \u002F media-size 类可恢复错误，尝试 Context Collapse \u002F Reactive Compact 等恢复路径；如果恢复不了，再把错误展示给用户。",[40,41,42],"blockquote",{},[10,43,44],{},"说明：本文区分“源码中已经能完整确认的机制”和“只有接入点、但核心实现不在当前仓库中的机制”。后者只讨论接入位置、触发关系和可观察行为，不把未确认的内部算法写死。",[10,46,47],{},"所以更准确的关系是：",[49,50,56],"pre",{"className":51,"code":53,"language":54,"meta":55},[52],"language-text","Microcompact \u002F Snip \u002F Context Collapse\n  = 请求前或请求中的上下文优化机制\n\nAuto Compact\n  = 高水位自动压缩调度器\n  = 主要调度 Session Memory Compact 和 Full Compact\n\nFull Compact\n  = 最强的“创建新上下文基线”的兜底压缩\n\nReactive Compact\n  = 主请求循环中 API 已经拒绝请求后才介入的应急恢复路径\n  = 手动 \u002Fcompact 的 reactive-only 模式也会复用这套机制\n","text","",[57,58,53],"code",{"__ignoreMap":55},[60,61],"hr",{},[63,64,65],"h2",{"id":65},"哪些机制已经实现",[10,67,68],{},"下面按“当前源码可见程度”分类。",[70,71,72],"h3",{"id":72},"源码中可确认完整实现的机制",[74,75,77],"h4",{"id":76},"token-usage-estimated-tail","Token Usage \u002F Estimated Tail",[10,79,80],{},"已实现。",[10,82,83],{},"它负责估算当前上下文有多满。Claude Code 会优先使用最近一次真实 API 返回的 token usage，再加上之后新增消息的粗略估算，而不是简单把所有历史 token 累加一遍。",[10,85,86],{},"关键点：",[88,89,90,93,96,99],"ul",{},[20,91,92],{},"真实 API usage 包括 input tokens、cache creation tokens、cache read tokens、output tokens。",[20,94,95],{},"如果最近一次 assistant 响应被拆成多个流式消息块，会往前找到同一个 API response 的第一个 assistant 块，避免漏算中间插入的 tool result。",[20,97,98],{},"Auto Compact、blocking limit、session memory extraction 等路径依赖这个带 tail 估算的 token 计数。",[20,100,101],{},"TUI 里的 Token Warning 组件主要使用最近一次真实 API usage，再交给同一个 warning state 计算函数判断；它不总是把最后一次 API 调用之后新增的 tail 再估进去。",[74,103,105],{"id":104},"token-warning-blocking-state","Token Warning \u002F Blocking State",[10,107,80],{},[10,109,110],{},"它负责告诉 UI \u002F query loop：现在是否接近上下文上限，是否应该显示警告，是否已经到了不能继续普通请求的硬限制。",[10,112,113],{},"注意这里有两个取数入口：",[88,115,116,123],{},[20,117,118,119,122],{},"Auto Compact 和 blocking limit 用 ",[57,120,121],{},"tokenCountWithEstimation(messages)","，会在最近一次 API usage 基础上估算 tail。",[20,124,125,126,129],{},"TUI 的 Token Warning 当前主要用最近一次真实 API usage 作为显示依据，然后调用同一套 ",[57,127,128],{},"calculateTokenWarningState"," 判断。",[10,131,132],{},"真实逻辑不是百分比阶梯，而是基于几个 buffer：",[88,134,135,138,141,144],{},[20,136,137],{},"effective context window = 模型上下文窗口（可被环境变量覆盖）- 为 compact summary 预留的输出 token。",[20,139,140],{},"auto compact threshold = effective context window - 13,000 tokens。",[20,142,143],{},"warning\u002Ferror threshold = 当前阈值 - 20,000 tokens。",[20,145,146],{},"blocking limit = effective context window - 3,000 tokens。",[10,148,149,150,153],{},"如果 Auto Compact 关闭，blocking limit 会让用户还能手动 ",[57,151,152],{},"\u002Fcompact","，而不是直接把上下文塞满。",[74,155,157],{"id":156},"read-去重","Read 去重",[10,159,80],{},[10,161,162],{},"当模型再次读取同一个文本\u002FNotebook 文件、同一个范围，并且文件没有变化时，Read 工具不会再次把完整文件内容塞进上下文，而是返回一个 stub。图片\u002FPDF 等媒体读取不走这条 dedup 路径。stub 的真实内容类似：",[49,164,167],{"className":165,"code":166,"language":54,"meta":55},[52],"File unchanged since last read. The content from the earlier Read tool_result in this conversation is still current — refer to that instead of re-reading.\n",[57,168,166],{"__ignoreMap":55},[10,170,171],{},"这不是压缩摘要，而是“前一次完整 Read 仍然有效，请引用前面的内容”。",[74,173,175],{"id":174},"大型-tool-result-持久化与预算替换","大型 Tool Result 持久化与预算替换",[10,177,80],{},[10,179,180],{},"工具输出很大时，Claude Code 可以把完整输出保存到会话目录下的 tool-results 文件里，然后在上下文中只保留一个带预览和文件路径的替代文本。",[10,182,183],{},"另外还有“每条消息的工具结果总量预算”：",[88,185,186,189,192,195],{},[20,187,188],{},"对某个 user message 内过大的 tool_result 做预算检查。",[20,190,191],{},"选择较大的新 tool_result 持久化到磁盘。",[20,193,194],{},"上下文里替换为固定的预览文本。",[20,196,197],{},"替换决策会记录下来，resume 后能复现同样的替换，避免 prompt cache 因内容不一致而失效。",[74,199,201],{"id":200},"prompt-caching-api-cache-control","Prompt Caching \u002F API Cache Control",[10,203,80],{},[10,205,206],{},"Claude Code 会在 API 请求里放置 cache control，让系统提示词、工具定义、历史前缀等内容尽可能命中 prompt cache。",[10,208,209],{},"这不是“把上下文变短”，也通常不是让客户端请求体少发历史内容；更准确地说，它让重复前缀在服务端缓存里复用，从而减少重复计算、计费和延迟成本，并在 usage 中体现为 cache read \u002F cache creation tokens。",[74,211,213],{"id":212},"api-context-management","API Context Management",[10,215,216],{},"已实现，但有开关和条件。",[10,218,219,220,223],{},"这里指 API 原生的 ",[57,221,222],{},"context_management"," 参数。源码里可见的策略包括：",[88,225,226,237],{},[20,227,228,229,232,233,236],{},"通过 ",[57,230,231],{},"clear_thinking_20251015"," 管理 thinking blocks。默认并不是一律清旧 thinking；通常是 ",[57,234,235],{},"keep: all","，只有在特定冷缓存条件下才只保留最近 1 个 thinking turn。",[20,238,239,240,243],{},"在特定 ant \u002F 环境变量配置下，使用 API 的 ",[57,241,242],{},"clear_tool_uses_20250919"," 策略清理工具内容。",[10,245,246,247,250,251,254],{},"注意：这和 Cached Microcompact 的 ",[57,248,249],{},"cache_reference"," \u002F ",[57,252,253],{},"cache_edits"," 是两条不同机制，不要混在一起讲。",[74,256,258],{"id":257},"time-based-microcompact","Time-based Microcompact",[10,260,261],{},"已实现，但默认配置是关闭的。",[10,263,264],{},"它的真实触发不是“5 分钟或 20 条消息”，而是配置驱动：",[88,266,267,274,277],{},[20,268,269,270,273],{},"默认 ",[57,271,272],{},"enabled: false","。",[20,275,276],{},"默认时间间隔阈值是 60 分钟。",[20,278,279],{},"默认保留最近 5 个 compactable tool results。",[10,281,282],{},"它触发时做的事情也不是生成自然语言摘要，而是：",[88,284,285,288,291],{},[20,286,287],{},"找到可 compact 的工具结果。",[20,289,290],{},"保留最近 N 个。",[20,292,293],{},"把更旧的 tool_result 内容替换为固定文本：",[49,295,298],{"className":296,"code":297,"language":54,"meta":55},[52],"[Old tool result content cleared]\n",[57,299,297],{"__ignoreMap":55},[10,301,302],{},"它主要利用一个事实：如果距离上次 assistant 响应已经超过一段时间，服务端 prompt cache 大概率已经冷了。既然下一次请求本来就要重写前缀，不如在发送前清掉旧工具结果，减少重写成本。",[74,304,306],{"id":305},"cached-microcompact-接入","Cached Microcompact 接入",[10,308,309],{},"接入逻辑已实现，核心模块在当前源码中不可见。",[10,311,312],{},"当前源码可确认：",[88,314,315,318,321,326,329,338],{},[20,316,317],{},"它只在 feature gate 开启、模型支持、主线程请求等条件满足时运行。",[20,319,320],{},"它会登记可 compact 的 tool_result。",[20,322,323,324,273],{},"如果决定删除某些工具结果，会生成 pending ",[57,325,253],{},[20,327,328],{},"它不会修改本地消息内容。",[20,330,331,332,334,335,337],{},"API 层会给旧 tool_result 加 ",[57,333,249],{},"，再插入 ",[57,336,253],{}," 删除指定引用。",[20,339,340,341,344],{},"API 返回后，会用真实的 ",[57,342,343],{},"cache_deleted_input_tokens"," 生成 microcompact boundary。",[10,346,347,348,351],{},"但真正决定“删哪些 tool result”的 ",[57,349,350],{},"cachedMicrocompact.js"," 核心文件在当前仓库中不可见，所以不能把它内部策略讲得过于确定。",[74,353,355],{"id":354},"session-memory-compact","Session Memory Compact",[10,357,358],{},"已实现，但需要 feature \u002F env 开关，并且依赖已有 session memory。",[10,360,361],{},"它不是在 compact 当下把早期对话重新发给 Claude 生成摘要。它使用已经异步抽取好的 session memory 内容作为摘要基础。",[10,363,364],{},"真实流程：",[17,366,367,370,373,376,379,386,389,403,406,409,412,415,418,421],{},[20,368,369],{},"检查 Session Memory Compact 是否启用。",[20,371,372],{},"等待正在进行的 session memory extraction 完成。",[20,374,375],{},"读取 session memory 文件。",[20,377,378],{},"如果没有 session memory 或只是空模板，则放弃，回退到 Full Compact。",[20,380,381,382,385],{},"根据 ",[57,383,384],{},"lastSummarizedMessageId"," 找到已经被 memory 覆盖到哪里。",[20,387,388],{},"从这个位置之后开始保留最近消息。",[20,390,391,392],{},"如果保留的消息太少，就向前扩展，直到满足：\n",[88,393,394,397,400],{},[20,395,396],{},"默认至少保留约 10,000 tokens。",[20,398,399],{},"默认至少保留 5 条带文本块的消息。",[20,401,402],{},"默认最多扩展到约 40,000 tokens。",[20,404,405],{},"调整保留起点，避免切断 tool_use \u002F tool_result 配对，也避免切断同一个 assistant response 的 thinking\u002Ftool 块。",[20,407,408],{},"创建 compact boundary。",[20,410,411],{},"插入 session memory summary。",[20,413,414],{},"保留最近一段完整消息尾巴。",[20,416,417],{},"恢复 plan 文件附件（如果有）。",[20,419,420],{},"执行 session start hooks。",[20,422,423],{},"如果压缩后的 token 仍然超过 Auto Compact 阈值，则放弃这条路径，改走 Full Compact。",[10,425,426],{},"Session Memory Compact 的价值是：比 Full Compact 更便宜、更快，因为它复用已经维护好的 session memory，并保留最近上下文原文。",[74,428,430],{"id":429},"full-compact","Full Compact",[10,432,80],{},[10,434,435],{},"这是最强的上下文重置机制，也就是通常意义上的“压缩成 boundary + summary，开启新的上下文基线”。",[10,437,364],{},[17,439,440,443,446,449,452,455,465,468,471,474,477,480,483,485,488,491,494],{},[20,441,442],{},"记录压缩前 token 数。",[20,444,445],{},"执行 PreCompact hooks。",[20,447,448],{},"构造 compact prompt。",[20,450,451],{},"把当前 active conversation 发给一个 compact summary 请求。",[20,453,454],{},"默认会先尝试 prompt-cache-sharing 的 forked-agent summary 路径；这条路径主要为了复用主会话缓存。",[20,456,457,458,250,461,464],{},"如果 forked-agent 路径失败，会走 regular streaming fallback summarizer 路径；这条路径在发送前会移除图片\u002F文档，替换成 ",[57,459,460],{},"[image]",[57,462,463],{},"[document]","，避免 compact 请求自己爆上下文。",[20,466,467],{},"regular streaming fallback 路径还会去掉一些 compact 后会重新注入的附件，避免摘要被过时附件污染。",[20,469,470],{},"如果 compact 请求本身 prompt too long，会最多重试 3 次。",[20,472,473],{},"每次重试会从最老的 API round group 开始丢弃一部分历史，再尝试生成摘要。",[20,475,476],{},"摘要成功后，清理 read file state 等缓存。",[20,478,479],{},"恢复最近读取过的文件，默认最多 5 个，并受 token budget 限制。",[20,481,482],{},"恢复 async agent、plan、plan mode、已调用 skills、deferred tools、agent listing、MCP instructions 等必要上下文。",[20,484,420],{},[20,486,487],{},"插入 compact boundary。",[20,489,490],{},"插入 compact summary message。",[20,492,493],{},"执行 PostCompact hooks。",[20,495,496],{},"做 post compact cleanup。",[10,498,499],{},"普通 Full Compact 压缩后的消息顺序是：",[49,501,504],{"className":502,"code":503,"language":54,"meta":55},[52],"compact boundary\nsummary message\n恢复附件\nhook results\n",[57,505,503],{"__ignoreMap":55},[10,507,508,509,512,513,516,517,250,520,523],{},"通用 ",[57,510,511],{},"CompactionResult"," 支持 ",[57,514,515],{},"messagesToKeep","。Session Memory Compact 和 Reactive Compact 这类 suffix-preserving 路径可以在 summary 后保留一段原文尾巴；Partial Compact 则会根据 ",[57,518,519],{},"from",[57,521,522],{},"up_to"," 保留前缀或后缀。普通 Full Compact 路径通常不保留最近消息原文尾巴。",[10,525,526],{},"Full Compact 是最彻底的压缩方式。它会丢失部分细节，但会最大幅度降低上下文占用。",[74,528,530],{"id":529},"auto-compact","Auto Compact",[10,532,80],{},[10,534,535],{},"但它不是“多档百分比策略选择器”。源码里的 Auto Compact 更像一个高水位兜底调度器。",[10,537,538],{},"它的真实判断：",[17,540,541,544,547,550,553,556,559,562,565,568],{},[20,542,543],{},"如果 compact 被整体禁用，直接不做。",[20,545,546],{},"如果 Auto Compact 被禁用，直接不做。",[20,548,549],{},"如果当前 query source 是 compact 或 session_memory，直接不做，避免递归死锁。",[20,551,552],{},"如果 Context Collapse 正在接管上下文管理，Auto Compact 会被抑制。",[20,554,555],{},"如果 Reactive-only 模式开启，主动 Auto Compact 会被抑制，让 API 的 prompt-too-long \u002F media-size 等可恢复错误来触发 Reactive Compact。",[20,557,558],{},"如果连续 Auto Compact 失败次数达到 3 次，熔断，不再反复尝试。",[20,560,561],{},"计算 token usage。",[20,563,564],{},"如果 token usage 没到 Auto Compact 阈值，不做。",[20,566,567],{},"到阈值后，先尝试 Session Memory Compact。",[20,569,570],{},"Session Memory Compact 不可用、不满足条件、或压缩后仍超阈值，则走 Full Compact。",[10,572,573],{},"所以正确说法是：",[49,575,578],{"className":576,"code":577,"language":54,"meta":55},[52],"Auto Compact\n  ├─ 先尝试 Session Memory Compact\n  └─ 不行再 Full Compact\n",[57,579,577],{"__ignoreMap":55},[10,581,582],{},"Microcompact 并不是 Auto Compact 内部按百分比选择出来的策略。它在 Auto Compact 之前已经作为请求前优化跑过了。",[74,584,586],{"id":585},"compact-boundary-active-context-view","Compact Boundary \u002F Active Context View",[10,588,80],{},[10,590,591],{},"Compact Boundary 是压缩后的分界线。代码层面的 active slice 会从最后一个 compact boundary 开始取，并包含 boundary 本身；但 boundary 是系统元消息，后续 API 归一化时不会作为普通对话内容直接喂给模型。因此从模型可见内容角度，可以近似理解为使用以最后一个 compact boundary 为基线的上下文。",[10,593,594],{},"它的作用：",[88,596,597,600,603,605,608],{},[20,598,599],{},"标记发生过 compact。",[20,601,602],{},"记录触发方式：manual 或 auto。",[20,604,442],{},[20,606,607],{},"记录 logical parent，保持会话链路。",[20,609,610],{},"在部分压缩或保留尾巴的场景中，记录 preserved segment，方便恢复消息链。",[10,612,613],{},"Active Context View 的真实含义是：",[49,615,618],{"className":616,"code":617,"language":54,"meta":55},[52],"从最后一个 compact boundary 开始的消息 slice（包含 boundary 元消息）\n+ 如果 Snip 开启，则过滤掉 snipped messages\n+ 如果 Context Collapse 开启，则投影成 collapsed view\n+ 请求前再经过 tool result budget \u002F microcompact 等处理\n",[57,619,617],{"__ignoreMap":55},[10,621,622],{},"它不是简单的“UI 上能展开折叠的完整历史”。UI 可能仍保留滚动历史，但模型看到的是投影后的 active context。",[74,624,626],{"id":625},"post-compact-cleanup","Post Compact Cleanup",[10,628,80],{},[10,630,631],{},"压缩后会清理一些已经失效的缓存和状态，例如：",[88,633,634,637,640,643,646,649,652],{},[20,635,636],{},"microcompact state。",[20,638,639],{},"context collapse state，主线程 compact 时才清。",[20,641,642],{},"user context \u002F memory file cache。",[20,644,645],{},"system prompt sections。",[20,647,648],{},"classifier approvals。",[20,650,651],{},"speculative bash checks。",[20,653,654],{},"session message cache。",[10,656,657],{},"这样做是为了避免压缩前的缓存污染压缩后的新上下文基线。",[74,659,661],{"id":660},"compact-warning-state","Compact Warning State",[10,663,80],{},[10,665,666,667,669],{},"压缩或 microcompact 刚成功后，token usage 可能还没等到下一次真实 API usage 校准。源码里已有 compact warning suppression 状态；当前可见调用点主要包括手动 ",[57,668,152],{}," 成功、reactive-only 手动 compact 成功，以及 cached\u002Ftime-based microcompact 成功。不要笼统理解为每一条 proactive Auto Compact 成功路径都会直接调用 suppress。",[74,671,673],{"id":672},"message-grouping","Message Grouping",[10,675,80],{},[10,677,678],{},"源码里按 API round 对消息分组，而不是只按用户回合分组。这主要服务于 prompt-too-long retry：如果 compact summary 请求自己太长，就按 API round 从头丢弃旧分组，避免切断工具调用配对。",[74,680,682],{"id":681},"partial-compact","Partial Compact",[10,684,80],{},[10,686,687],{},"这是手动局部 compact，不等同于 Snip。它可以围绕用户选择的消息做局部摘要：",[88,689,690,695],{},[20,691,692,694],{},[57,693,522],{},"：摘要选中点之前的消息（不含选中消息），保留选中消息及其后面的消息。",[20,696,697,699],{},[57,698,519],{},"：摘要选中消息及其之后的消息，保留前面的消息。",[10,701,702],{},"它会生成 summary 和 boundary，并尽量保持 prompt cache 或消息链路。",[70,704,706],{"id":705},"有接入点但当前仓库缺少核心实现的机制","有接入点，但当前仓库缺少核心实现的机制",[74,708,710],{"id":709},"snip-compact","Snip Compact",[10,712,713],{},"有接入点，但当前仓库缺少核心实现文件。",[10,715,716],{},"源码中可以看到：",[88,718,719,725,731,738,741],{},[20,720,721,724],{},[57,722,723],{},"HISTORY_SNIP"," feature gate。",[20,726,727,728,273],{},"query 前会调用 ",[57,729,730],{},"snipCompactIfNeeded",[20,732,733,734,737],{},"active context 会通过 ",[57,735,736],{},"projectSnippedView"," 过滤 snipped messages。",[20,739,740],{},"UI 保留 scrollback 时可以 include snipped messages。",[20,742,743,746],{},[57,744,745],{},"\u002Fforce-snip"," 等入口存在。",[10,748,749,750,250,753,756],{},"但 ",[57,751,752],{},"snipCompact.js",[57,754,755],{},"snipProjection.js"," 在当前源码树里不可见，所以不能确认具体算法。",[10,758,759],{},"可安全讲法：",[49,761,764],{"className":762,"code":763,"language":54,"meta":55},[52],"Snip 是一个 feature-gated 的历史裁剪机制。它会在 microcompact 之前运行，可能从模型可见上下文中移除一部分历史，并返回 tokensFreed 供 Auto Compact 的阈值判断参考。但核心裁剪策略在当前源码中不可见。\n",[57,765,763],{"__ignoreMap":55},[10,767,768],{},"不要讲成“用户手动选择任意片段压缩成摘要”这样的确定功能，除非你能看到对应核心源码。",[74,770,772],{"id":771},"context-collapse","Context Collapse",[10,774,775],{},"有大量接入点，但当前仓库缺少核心实现文件。",[10,777,778],{},"源码中可见：",[88,780,781,786,792,802,805,812],{},[20,782,783,724],{},[57,784,785],{},"CONTEXT_COLLAPSE",[20,787,788,789,273],{},"query 中在 Auto Compact 之前调用 ",[57,790,791],{},"applyCollapsesIfNeeded",[20,793,794,797,798,801],{},[57,795,796],{},"\u002Fcontext"," 会通过 ",[57,799,800],{},"projectView"," 统计 collapse 后的上下文。",[20,803,804],{},"UI 会显示多少 span summarized \u002F staged。",[20,806,807,808,811],{},"prompt too long 后会先尝试 ",[57,809,810],{},"recoverFromOverflow","，也就是 drain staged collapses。",[20,813,814],{},"Context Collapse 开启时，会抑制 proactive Auto Compact，让 Collapse 自己接管 headroom 管理。",[10,816,749,817,250,820,823],{},[57,818,819],{},"services\u002FcontextCollapse\u002Findex.js",[57,821,822],{},"operations.js"," 等核心文件不在当前仓库中。",[10,825,759],{},[49,827,830],{"className":828,"code":829,"language":54,"meta":55},[52],"Context Collapse 是一个 feature-gated 的上下文折叠系统。它在 Auto Compact 之前投影一个更小的上下文视图，并在 prompt too long 时优先尝试提交\u002F排空 staged collapse。当前仓库只能验证接入点和整体位置，不能完整验证内部折叠算法。\n",[57,831,829],{"__ignoreMap":55},[10,833,834],{},"不要讲成“用户可以像 IDE 折叠代码一样展开\u002F折叠查看详情”，源码里当前可见部分不足以支持这个说法。",[74,836,838],{"id":837},"reactive-compact","Reactive Compact",[10,840,713],{},[10,842,778],{},[88,844,845,850,853,859,868],{},[20,846,847,724],{},[57,848,849],{},"REACTIVE_COMPACT",[20,851,852],{},"query 中会把可恢复的 prompt-too-long \u002F media-size error 暂时 withheld，不立刻展示给用户。",[20,854,855,856,273],{},"请求失败后会调用 ",[57,857,858],{},"tryReactiveCompact",[20,860,861,862,864,865,273],{},"手动 ",[57,863,152],{}," 在 reactive-only 模式下会走 ",[57,866,867],{},"reactiveCompactOnPromptTooLong",[20,869,870],{},"Reactive-only 模式会抑制 proactive Auto Compact，让真实 API 的 prompt-too-long 等可恢复错误触发恢复。",[10,872,749,873,876],{},[57,874,875],{},"reactiveCompact.js"," 当前不可见。",[10,878,759],{},[49,880,883],{"className":881,"code":882,"language":54,"meta":55},[52],"Reactive Compact 在主请求循环里是 API 已经拒绝请求后的应急恢复机制。它不是常规请求前优化，也不是 Auto Compact 的普通分支；另外，手动 `\u002Fcompact` 在 reactive-only 模式下也会复用 reactive compact 路径。当前仓库只能验证它的调用位置和错误恢复框架，不能完整验证内部压缩策略。\n",[57,884,882],{"__ignoreMap":55},[60,886],{},[63,888,889],{"id":889},"正确的请求流程",[10,891,892],{},"下面是一次普通用户请求在上下文管理上的真实顺序。",[70,894,896],{"id":895},"step-1构造-active-context","Step 1：构造 active context",[10,898,899],{},"先从当前消息历史里取以最后一次 compact boundary 为基线的 active slice。代码层面这个 slice 包含 boundary 元消息；模型可见内容可近似理解为以这个 boundary 为新基线的上下文。",[49,901,904],{"className":902,"code":903,"language":54,"meta":55},[52],"all messages\n  -> slice from last compact boundary\n  -> boundary is metadata, not ordinary model-visible dialogue\n",[57,905,903],{"__ignoreMap":55},[10,907,908],{},"如果 Snip 开启，还会把 snipped messages 从模型可见视图中投影掉。",[10,910,911],{},"结果是：UI 里也许还能看到更早的滚动历史；模型真正收到的是以最后一次 compact boundary 为基线投影出来的 active context。",[70,913,915],{"id":914},"step-2应用工具结果预算替换","Step 2：应用工具结果预算替换",[10,917,918],{},"在 microcompact 之前，先检查 tool_result 是否过大。",[10,920,921],{},"如果某条 user message 里的工具结果总量超过预算：",[88,923,924,927,930,933],{},[20,925,926],{},"选择较大的新 tool_result。",[20,928,929],{},"持久化到磁盘。",[20,931,932],{},"上下文里替换成带预览的 persisted-output 文本。",[20,934,935],{},"记录这次替换，保证后续 resume 还能复现。",[10,937,938],{},"这一步通常对用户透明。",[70,940,942],{"id":941},"step-3snip如果开启","Step 3：Snip，如果开启",[10,944,945,946,948],{},"如果 ",[57,947,723],{}," feature 开启：",[88,950,951,954,957,963],{},[20,952,953],{},"在 microcompact 前运行。",[20,955,956],{},"可能移除一部分模型可见历史。",[20,958,959,960,273],{},"返回 ",[57,961,962],{},"tokensFreed",[20,964,965],{},"Auto Compact 后面判断阈值时，会把这部分 freed tokens 扣掉，避免刚被 Snip 降下来的上下文又被误判为超阈值。",[10,967,968],{},"当前仓库缺少核心实现，所以教学时只讲它的位置和作用，不讲具体算法。",[70,970,972],{"id":971},"step-4microcompact","Step 4：Microcompact",[10,974,975],{},"Microcompact 在 Auto Compact 之前执行。",[10,977,978],{},"它先尝试 Time-based Microcompact。",[10,980,981],{},"如果触发：",[88,983,984,987,990,993,996],{},[20,985,986],{},"说明距离上一次主线程 assistant 消息已经超过配置阈值。",[20,988,989],{},"清理旧 tool_result 内容。",[20,991,992],{},"保留最近 N 个可 compact 的工具结果。",[20,994,995],{},"返回修改后的 messages。",[20,997,998],{},"不再继续 cached microcompact。",[10,1000,1001],{},"如果 Time-based 没触发，再尝试 Cached Microcompact。",[10,1003,1004],{},"如果 Cached Microcompact 可用：",[88,1006,1007,1010,1013,1018,1021,1029],{},[20,1008,1009],{},"登记可 compact 的 tool_result。",[20,1011,1012],{},"判断是否有需要从 cache 中删除的 tool_result。",[20,1014,1015,1016,273],{},"如果有，生成 ",[57,1017,253],{},[20,1019,1020],{},"本地消息不变。",[20,1022,1023,1024,1026,1027,273],{},"API 层负责插入 ",[57,1025,249],{}," 和 ",[57,1028,253],{},[20,1030,1031],{},"API 返回后，用真实删除 token 数生成 microcompact boundary。",[10,1033,1034],{},"如果这些都不可用，Microcompact 直接返回原 messages。",[70,1036,1038],{"id":1037},"step-5context-collapse如果开启","Step 5：Context Collapse，如果开启",[10,1040,1041],{},"Context Collapse 在 Auto Compact 之前执行。",[10,1043,1044],{},"它的设计意图是：如果能通过 collapse 投影把上下文降下来，就不要急着 Full Compact 成一个大摘要。",[10,1046,1047],{},"如果 Context Collapse 开启，它会接管 headroom 管理，所以 proactive Auto Compact 会被抑制，避免两套系统互相抢控制权。",[10,1049,1050],{},"当前仓库能验证这个顺序和互斥关系，但不能验证具体 collapse 算法。",[70,1052,1054],{"id":1053},"step-6auto-compact-高水位判断","Step 6：Auto Compact 高水位判断",[10,1056,1057],{},"Auto Compact 这时才开始判断。",[10,1059,1060],{},"它先做一堆保护：",[88,1062,1063,1066,1069,1072,1075,1078],{},[20,1064,1065],{},"compact 整体禁用则退出。",[20,1067,1068],{},"Auto Compact 禁用则退出。",[20,1070,1071],{},"当前就是 compact\u002Fsession_memory query 则退出。",[20,1073,1074],{},"Context Collapse 接管则退出。",[20,1076,1077],{},"Reactive-only 模式则退出。",[20,1079,1080],{},"连续失败次数达到 3 次则退出。",[10,1082,1083],{},"然后计算：",[49,1085,1088],{"className":1086,"code":1087,"language":54,"meta":55},[52],"tokenCountWithEstimation(messages) - snipTokensFreed\n",[57,1089,1087],{"__ignoreMap":55},[10,1091,1092],{},"如果没到 auto compact threshold，则继续正常请求。",[10,1094,1095],{},"如果到了阈值，进入真正压缩。",[70,1097,1099],{"id":1098},"step-7auto-compact-先尝试-session-memory-compact","Step 7：Auto Compact 先尝试 Session Memory Compact",[10,1101,1102],{},"Auto Compact 到阈值后，不是先做 microcompact，因为 microcompact 已经做过了。",[10,1104,1105],{},"它第一选择是 Session Memory Compact。",[10,1107,1108],{},"Session Memory Compact 成功的条件比较多：",[88,1110,1111,1114,1117,1120,1123,1126],{},[20,1112,1113],{},"feature\u002Fenv 允许。",[20,1115,1116],{},"session memory 文件存在。",[20,1118,1119],{},"session memory 不是空模板。",[20,1121,1122],{},"能找到 last summarized message 或符合 resumed session 情况。",[20,1124,1125],{},"保留尾巴后不会切断工具调用配对。",[20,1127,1128],{},"压缩后的整体 token 低于 Auto Compact 阈值。",[10,1130,1131],{},"成功后，新的上下文形态是：",[49,1133,1136],{"className":1134,"code":1135,"language":54,"meta":55},[52],"compact boundary\nsession memory summary\nrecent messages kept verbatim\nplan attachment, if any\nsession start hook results\n",[57,1137,1135],{"__ignoreMap":55},[10,1139,1140],{},"如果失败或不适用，回退到 Full Compact。",[70,1142,1144],{"id":1143},"step-8auto-compact-回退到-full-compact","Step 8：Auto Compact 回退到 Full Compact",[10,1146,1147],{},"Full Compact 会调用模型生成完整摘要。",[10,1149,1150],{},"它会把当前 active conversation 总结成一个 summary，然后建立新的上下文基线：",[49,1152,1155],{"className":1153,"code":1154,"language":54,"meta":55},[52],"compact boundary\ncompact summary\npost-compact restored file attachments\nplan \u002F plan mode \u002F skills\ntool \u002F agent \u002F MCP delta attachments\nhook results\n",[57,1156,1154],{"__ignoreMap":55},[10,1158,1159],{},"Full Compact 是 Auto Compact 的最强兜底。它牺牲更多细节，但能最大幅度释放上下文。",[70,1161,1163],{"id":1162},"step-9调用模型-api","Step 9：调用模型 API",[10,1165,1166],{},"如果没有 compact，或者 compact 后构造好了新上下文，就进入真实 API 调用。",[10,1168,1169],{},"API 层还会做几件事：",[88,1171,1172,1175,1178,1183,1188],{},[20,1173,1174],{},"加 prompt cache breakpoints。",[20,1176,1177],{},"插入 cache control。",[20,1179,1180,1181,273],{},"如果 Cached Microcompact 有 pending edits，插入 ",[57,1182,253],{},[20,1184,1185,1186,273],{},"给旧 tool_result 添加 ",[57,1187,249],{},[20,1189,1190,1191,1193],{},"如果启用了 API context management，把 ",[57,1192,222],{}," 参数传给 API。",[10,1195,1196,1197,344],{},"模型返回后，如果 Cached Microcompact 刚删了缓存内容，会根据 API usage 里的 ",[57,1198,343],{},[70,1200,1202],{"id":1201},"step-10如果-api-返回-prompt-too-long-media-size-类错误","Step 10：如果 API 返回 prompt too long \u002F media-size 类错误",[10,1204,1205],{},"如果真实 API 请求被拒绝，错误不会立刻全部显示给用户。部分可恢复错误会先被 withheld。",[10,1207,1208],{},"恢复顺序大致是：",[17,1210,1211,1214,1217,1220,1223],{},[20,1212,1213],{},"对 prompt-too-long：如果 Context Collapse 开启，先尝试 drain staged collapses。",[20,1215,1216],{},"如果 Reactive Compact 可用，再尝试 Reactive Compact。",[20,1218,1219],{},"对 media-size 类错误：Context Collapse 不会 strip 图片\u002F文档，通常直接进入 Reactive Compact 的恢复路径。",[20,1221,1222],{},"如果恢复成功，构造压缩后的 messages，然后重新进入请求循环。",[20,1224,1225],{},"如果恢复失败，才把 prompt too long 或 media-size error 显示给用户。",[10,1227,1228],{},"这就是 Reactive Compact 的位置：它是失败后的恢复机制，不是请求前的常规压缩层。",[60,1230],{},[63,1232,1234],{"id":1233},"auto-compact-的正确理解","Auto Compact 的正确理解",[10,1236,1237],{},"错误理解：",[49,1239,1242],{"className":1240,"code":1241,"language":54,"meta":55},[52],"60% -> Microcompact\n70% -> Session Memory Compact\n85% -> Full Compact\n90% -> Emergency Compact\n",[57,1243,1241],{"__ignoreMap":55},[10,1245,1246],{},"这个说法不符合当前源码。",[10,1248,1249],{},"正确理解：",[49,1251,1254],{"className":1252,"code":1253,"language":54,"meta":55},[52],"每次请求前：\n  先跑请求前优化：\n    - tool result budget\n    - Snip, if enabled\n    - Microcompact\n    - Context Collapse, if enabled\n\n然后 Auto Compact 只在高水位触发：\n  if token usage >= auto compact threshold:\n    try Session Memory Compact\n    if not usable:\n      run Full Compact\n",[57,1255,1253],{"__ignoreMap":55},[10,1257,1258],{},"Auto Compact 是“高水位自动压缩调度器”，不是“所有压缩策略的总容器”。",[10,1260,1261],{},"Microcompact 是 Auto Compact 前面的轻量优化。",[10,1263,1264],{},"Session Memory Compact 和 Full Compact 才是 Auto Compact 直接调度的两个主要压缩执行路径。",[60,1266],{},[63,1268,1270],{"id":1269},"full-compact-为什么是终极上下文基线","Full Compact 为什么是终极上下文基线",[10,1272,1273],{},"Full Compact 的本质不是简单删历史，而是重新建立上下文基线。",[10,1275,1276],{},"压缩前：",[49,1278,1281],{"className":1279,"code":1280,"language":54,"meta":55},[52],"大量历史对话\n大量工具调用\n大量文件读取\n多轮计划和修改\n",[57,1282,1280],{"__ignoreMap":55},[10,1284,1285],{},"压缩后：",[49,1287,1290],{"className":1288,"code":1289,"language":54,"meta":55},[52],"Conversation compacted boundary\n一段结构化 summary\n少量必要附件\n最近文件\u002F计划\u002F技能\u002F工具上下文\n",[57,1291,1289],{"__ignoreMap":55},[10,1293,1294],{},"这相当于把“整本施工日志”整理成“当前项目交接文档”。模型不再逐字看到所有旧消息，但能看到：",[88,1296,1297,1300,1303,1306,1309,1312],{},[20,1298,1299],{},"当前目标是什么。",[20,1301,1302],{},"已经完成了什么。",[20,1304,1305],{},"修改过哪些文件。",[20,1307,1308],{},"关键决策是什么。",[20,1310,1311],{},"当前还在做什么。",[20,1313,1314],{},"接下来应该怎么继续。",[10,1316,1317],{},"所以 Full Compact 是最强兜底，但不是最优先使用的方式。因为它会损失细节，也需要额外模型调用。",[60,1319],{},[63,1321,1322],{"id":1322},"一个真实长会话示例",[10,1324,1325],{},"假设用户进行 2 小时编程会话。",[70,1327,1329],{"id":1328},"_0-30-分钟","0-30 分钟",[10,1331,1332],{},"主要发生的是透明优化：",[88,1334,1335,1338,1341,1344],{},[20,1336,1337],{},"Read 同文件去重。",[20,1339,1340],{},"大工具输出持久化到磁盘。",[20,1342,1343],{},"prompt caching 复用系统提示词、工具定义、历史前缀。",[20,1345,1346],{},"token warning 持续监控。",[10,1348,1349],{},"用户通常无感。",[70,1351,1353],{"id":1352},"_30-90-分钟","30-90 分钟",[10,1355,1356],{},"如果工具输出很多：",[88,1358,1359,1362,1365],{},[20,1360,1361],{},"tool result budget 会把过大的结果替换成 persisted-output 预览。",[20,1363,1364],{},"如果 Cached Microcompact 开启，可能通过 cache_edits 删除旧 cached tool_result。",[20,1366,1367,1368,273],{},"如果会话中断很久再回来，并且 Time-based Microcompact 开启，旧 tool_result 可能被替换为 ",[57,1369,1370],{},"[Old tool result content cleared]",[10,1372,1373],{},"注意，这些都不是 Auto Compact 的分档策略，而是 Auto Compact 之前的轻量优化链路。",[70,1375,1376],{"id":1376},"接近上下文上限",[10,1378,1379],{},"当 token usage 达到 Auto Compact 阈值：",[17,1381,1382,1385,1388,1391],{},[20,1383,1384],{},"Auto Compact 触发。",[20,1386,1387],{},"先尝试 Session Memory Compact。",[20,1389,1390],{},"如果 session memory 可用，并且压缩后低于阈值，就保留 session memory summary + 最近消息尾巴。",[20,1392,1393],{},"如果不可用或压缩效果不够，就触发 Full Compact。",[70,1395,1397],{"id":1396},"full-compact-后","Full Compact 后",[10,1399,1400],{},"上下文会变成：",[49,1402,1405],{"className":1403,"code":1404,"language":54,"meta":55},[52],"compact boundary\nconversation summary\nrecent restored files\nplan \u002F skills \u002F hooks \u002F tool context\n",[57,1406,1404],{"__ignoreMap":55},[10,1408,1409],{},"token 使用大幅下降，用户可以继续工作。",[70,1411,1413],{"id":1412},"如果-api-仍然报-prompt-too-long","如果 API 仍然报 prompt too long",[10,1415,1416],{},"这是应急阶段：",[88,1418,1419,1422,1425],{},[20,1420,1421],{},"Context Collapse 可能先尝试恢复。",[20,1423,1424],{},"Reactive Compact 如果启用，尝试对失败请求做恢复压缩。",[20,1426,1427],{},"如果都不行，错误才会显示给用户。",[60,1429],{},[63,1431,1432],{"id":1432},"教学视频推荐讲法",[10,1434,1435],{},"建议不要按“十层楼”讲。更推荐按“三段式”讲。",[70,1437,1439],{"id":1438},"第一段日常省-token","第一段：日常省 token",[10,1441,1442],{},"主题：大多数时候，Claude Code 不需要大压缩，而是在悄悄减少浪费。",[10,1444,1445],{},"包括：",[88,1447,1448,1451,1454,1457,1460],{},[20,1449,1450],{},"Read 去重。",[20,1452,1453],{},"大工具输出持久化。",[20,1455,1456],{},"prompt caching。",[20,1458,1459],{},"tool result budget。",[20,1461,1462],{},"time-based \u002F cached microcompact。",[10,1464,1465],{},"一句话：",[49,1467,1470],{"className":1468,"code":1469,"language":54,"meta":55},[52],"这一层不是总结对话，而是减少重复内容和旧工具输出。\n",[57,1471,1469],{"__ignoreMap":55},[70,1473,1475],{"id":1474},"第二段接近上限时自动建新基线","第二段：接近上限时自动建新基线",[10,1477,1478],{},"主题：Auto Compact 是高水位兜底。",[10,1480,1445],{},[88,1482,1483,1486,1489,1492,1495,1498],{},[20,1484,1485],{},"token usage 估算。",[20,1487,1488],{},"auto compact threshold。",[20,1490,1491],{},"circuit breaker。",[20,1493,1494],{},"先 Session Memory Compact。",[20,1496,1497],{},"再 Full Compact。",[20,1499,1500],{},"compact boundary + summary。",[10,1502,1465],{},[49,1504,1507],{"className":1505,"code":1506,"language":54,"meta":55},[52],"Auto Compact 不是每个百分比切换一个策略，而是在快满时自动选择“能否用 session memory”，不行就完整 compact。\n",[57,1508,1506],{"__ignoreMap":55},[70,1510,1512],{"id":1511},"第三段已经爆了怎么办","第三段：已经爆了怎么办",[10,1514,1515],{},"主题：API 拒绝请求后的恢复。",[10,1517,1445],{},[88,1519,1520,1523,1526,1529],{},[20,1521,1522],{},"prompt too long withheld。",[20,1524,1525],{},"Prompt-too-long 时的 Context Collapse recovery。",[20,1527,1528],{},"Reactive Compact recovery（prompt-too-long \u002F media-size 等）。",[20,1530,1531],{},"恢复失败后错误浮出。",[10,1533,1465],{},[49,1535,1538],{"className":1536,"code":1537,"language":54,"meta":55},[52],"Reactive Compact 在主请求循环里是错误后的救援队，不是平时主动跑的清理器；手动 \u002Fcompact 的 reactive-only 复用路径是例外入口。\n",[57,1539,1537],{"__ignoreMap":55},[60,1541],{},[63,1543,1544],{"id":1544},"最容易讲错的点",[70,1546,1548],{"id":1547},"错误点-1auto-compact-包含所有压缩策略","错误点 1：Auto Compact 包含所有压缩策略",[10,1550,1551],{},"更正：",[10,1553,1554],{},"Auto Compact 直接调度的是 Session Memory Compact 和 Full Compact。Microcompact 在它之前运行，Context Collapse 开启时甚至会抑制 Auto Compact。",[70,1556,1558],{"id":1557},"错误点-2microcompact-会总结旧对话","错误点 2：Microcompact 会总结旧对话",[10,1560,1551],{},[10,1562,1563],{},"当前可见源码里的 Time-based Microcompact 是清空旧 tool_result 内容，不生成摘要。Cached Microcompact 是通过 API cache editing 删除 cached tool_result，也不是自然语言摘要。",[70,1565,1567],{"id":1566},"错误点-3session-memory-compact-现场生成摘要","错误点 3：Session Memory Compact 现场生成摘要",[10,1569,1551],{},[10,1571,1572],{},"它使用已经存在的 session memory 内容，并保留最近消息尾巴。现场生成完整摘要的是 Full Compact。",[70,1574,1576],{"id":1575},"错误点-4full-compact-只剩-summary","错误点 4：Full Compact 只剩 summary",[10,1578,1551],{},[10,1580,1581],{},"Full Compact 后不只是 summary。它还会恢复最近文件、plan、plan mode、skills、工具\u002Fagent\u002FMCP 附件、hook results 等必要上下文。",[70,1583,1585],{"id":1584},"错误点-5context-collapse-已能完整确认算法","错误点 5：Context Collapse 已能完整确认算法",[10,1587,1551],{},[10,1589,1590],{},"当前源码只能确认 Context Collapse 的接入位置、统计\u002F恢复路径和对 Auto Compact 的抑制关系。核心实现文件不在当前仓库中，不能完整讲算法细节。",[70,1592,1594],{"id":1593},"错误点-6reactive-compact-是主动压缩层","错误点 6：Reactive Compact 是主动压缩层",[10,1596,1551],{},[10,1598,1599,1600,1602],{},"在主请求循环中，Reactive Compact 是 API 返回 prompt too long \u002F media-size 类错误后的恢复路径。Reactive-only 模式下，它会故意抑制 proactive Auto Compact，等待真实 API 错误触发恢复；手动 ",[57,1601,152],{}," 在 reactive-only 模式下也会复用 reactive compact 机制。",[60,1604],{},[63,1606,1607],{"id":1607},"最终版总流程图",[49,1609,1612],{"className":1610,"code":1611,"language":54,"meta":55},[52],"用户输入\n  |\n  v\n取以最后一个 compact boundary 为基线的 active context\n  |\n  v\n应用 tool result budget \u002F 大结果持久化\n  |\n  v\nSnip Compact, if feature enabled\n  |\n  v\nMicrocompact\n  |-- Time-based: 清空旧 tool_result 内容\n  |-- Cached: 生成 cache_edits, 本地消息不变\n  |\n  v\nContext Collapse, if feature enabled\n  |\n  v\nAuto Compact 高水位判断\n  |-- 未到阈值：继续\n  |-- 到阈值：\n        |-- 尝试 Session Memory Compact\n        |-- 不适用则 Full Compact\n  |\n  v\n构造 API 请求\n  |-- cache_control\n  |-- cache_reference \u002F cache_edits, if cached MC\n  |-- context_management, if enabled\n  |\n  v\n模型响应\n  |\n  |-- 成功：正常继续\n  |\n  |-- prompt too long:\n        |-- Context Collapse recovery, if available\n        |-- Reactive Compact, if available\n        |-- 仍失败则显示错误\n\n  |-- media size error:\n        |-- Reactive Compact, if available\n        |-- 仍失败则显示错误\n",[57,1613,1611],{"__ignoreMap":55},[60,1615],{},[63,1617,1618],{"id":1618},"一句话总结",[10,1620,1621],{},"Claude Code 的上下文管理不是单一 compact，也不是固定百分比阶梯；它是“请求前轻量减负 + 高水位 Auto Compact + 错误后 Reactive Recovery”的组合系统。",[10,1623,1624],{},"其中：",[88,1626,1627,1630,1633,1636],{},[20,1628,1629],{},"Microcompact 负责清理旧工具结果。",[20,1631,1632],{},"Session Memory Compact 负责用已有 session memory 替换早期历史，同时保留最近尾巴。",[20,1634,1635],{},"Full Compact 负责生成 summary 并创建新的 compact boundary 基线。",[20,1637,1638],{},"Context Collapse 和 Reactive Compact 是 feature-gated 的高级\u002F实验路径，当前仓库只能确认接入点，不能完整确认内部算法。",{"title":55,"searchDepth":1640,"depth":1641,"links":1642},2,3,[1643,1669,1681,1682,1683,1690,1695,1703,1704],{"id":65,"depth":1640,"text":65,"children":1644},[1645,1664],{"id":72,"depth":1641,"text":72,"children":1646},[1647,1649,1650,1651,1652,1653,1654,1655,1656,1657,1658,1659,1660,1661,1662,1663],{"id":76,"depth":1648,"text":77},4,{"id":104,"depth":1648,"text":105},{"id":156,"depth":1648,"text":157},{"id":174,"depth":1648,"text":175},{"id":200,"depth":1648,"text":201},{"id":212,"depth":1648,"text":213},{"id":257,"depth":1648,"text":258},{"id":305,"depth":1648,"text":306},{"id":354,"depth":1648,"text":355},{"id":429,"depth":1648,"text":430},{"id":529,"depth":1648,"text":530},{"id":585,"depth":1648,"text":586},{"id":625,"depth":1648,"text":626},{"id":660,"depth":1648,"text":661},{"id":672,"depth":1648,"text":673},{"id":681,"depth":1648,"text":682},{"id":705,"depth":1641,"text":706,"children":1665},[1666,1667,1668],{"id":709,"depth":1648,"text":710},{"id":771,"depth":1648,"text":772},{"id":837,"depth":1648,"text":838},{"id":889,"depth":1640,"text":889,"children":1670},[1671,1672,1673,1674,1675,1676,1677,1678,1679,1680],{"id":895,"depth":1641,"text":896},{"id":914,"depth":1641,"text":915},{"id":941,"depth":1641,"text":942},{"id":971,"depth":1641,"text":972},{"id":1037,"depth":1641,"text":1038},{"id":1053,"depth":1641,"text":1054},{"id":1098,"depth":1641,"text":1099},{"id":1143,"depth":1641,"text":1144},{"id":1162,"depth":1641,"text":1163},{"id":1201,"depth":1641,"text":1202},{"id":1233,"depth":1640,"text":1234},{"id":1269,"depth":1640,"text":1270},{"id":1322,"depth":1640,"text":1322,"children":1684},[1685,1686,1687,1688,1689],{"id":1328,"depth":1641,"text":1329},{"id":1352,"depth":1641,"text":1353},{"id":1376,"depth":1641,"text":1376},{"id":1396,"depth":1641,"text":1397},{"id":1412,"depth":1641,"text":1413},{"id":1432,"depth":1640,"text":1432,"children":1691},[1692,1693,1694],{"id":1438,"depth":1641,"text":1439},{"id":1474,"depth":1641,"text":1475},{"id":1511,"depth":1641,"text":1512},{"id":1544,"depth":1640,"text":1544,"children":1696},[1697,1698,1699,1700,1701,1702],{"id":1547,"depth":1641,"text":1548},{"id":1557,"depth":1641,"text":1558},{"id":1566,"depth":1641,"text":1567},{"id":1575,"depth":1641,"text":1576},{"id":1584,"depth":1641,"text":1585},{"id":1593,"depth":1641,"text":1594},{"id":1607,"depth":1640,"text":1607},{"id":1618,"depth":1640,"text":1618},[1706],"技术","2026-05-19 10:00:00",false,"md",{},true,"\u002Fposts\u002Fclaude-code-context-management",{"title":5,"description":12},"posts\u002Fclaude-code-context-management",[1716,1717,1718,1719,1720],"Claude Code","Agent","LLM","AI Infra","上下文工程","4n-j7iYYDxqZ7Ni0FfE_p4-QWC2__zgroZ_88PGcYyg",[1723,1736,1748,1755,1768,1778,1788,1799,1810,1819,1823,1835,1848,1860,1869,1879,1892,1903,1913,1921,1932,1939,1945,1951,1960,1970,1978,1984,1992,2000],{"slug":1724,"path":1725,"title":1726,"date":1727,"tags":1728,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1735},"multimodal-rag-from-scratch","\u002Fposts\u002Fmultimodal-rag-from-scratch","从零实现多模态 RAG：BM25、Dense 检索、RRF 融合、MMR 重排全部手写","2026-06-30 18:00:00",[1729,1730,1719,1731,1732,1733,1734],"RAG","多模态","BM25","向量检索","混合检索","实习求职",9,{"slug":1737,"path":1738,"title":1739,"date":1740,"tags":1741,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1747},"mini-llm-engine-deep-dive","\u002Fposts\u002Fmini-llm-engine-deep-dive","讲透 mini-llm-engine：从显存碎片到六大推理优化","2026-06-30 14:00:00",[1718,1719,1742,1743,1744,1745,1746,1734],"vLLM","PagedAttention","KV Cache","推理优化","投机解码",11,{"slug":1749,"path":1750,"title":1751,"date":1752,"tags":1753,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1754},"mini-llm-engine-from-scratch","\u002Fposts\u002Fmini-llm-engine-from-scratch","从零实现 LLM 推理引擎：深挖 vLLM 的六大核心优化","2026-06-30 10:00:00",[1718,1719,1742,1743,1745,1746,1734],10,{"slug":1756,"path":1757,"title":1758,"date":1759,"tags":1760,"description":1766,"draft":1708,"hidden":1708,"published":1711,"readingTime":1767},"bytedance-recommendation-architecture-intern-interview","\u002Fposts\u002Fbytedance-recommendation-architecture-intern-interview","字节推荐架构实习生 Data 面试准备：推荐系统、实时特征与高并发八股","2026-06-09",[1761,1762,1763,1764,1765],"面试","推荐系统","后端架构","实时计算","字节跳动","面向字节跳动推荐架构团队实习岗位的八股准备清单，覆盖推荐系统链路、实时数据、特征服务、高并发后端、分布式系统与项目包装。",18,{"slug":1769,"path":1770,"title":1771,"date":1759,"tags":1772,"description":1776,"draft":1708,"hidden":1708,"published":1711,"readingTime":1777},"high-concurrency-rate-limiting-algorithms","\u002Fposts\u002Fhigh-concurrency-rate-limiting-algorithms","高并发限流算法：固定窗口、滑动窗口、漏桶与令牌桶",[1773,1774,1763,1775,1761],"高并发","限流","系统设计","面试和工程都常见的限流算法总结，讲清楚固定窗口、滑动窗口、漏桶、令牌桶、并发数限制以及分布式限流如何落地。",12,{"slug":1779,"path":1780,"title":1781,"date":1759,"tags":1782,"description":1786,"draft":1708,"hidden":1708,"published":1711,"readingTime":1787},"kafka-producer-broker-consumer","\u002Fposts\u002Fkafka-producer-broker-consumer","Kafka 入门：生产者、Broker、消费者和“消费”到底是什么意思",[1783,1784,1785,1761,1762],"Kafka","消息队列","后端","用推荐系统里的用户行为日志为例，讲清楚 Kafka 的作用、Producer、Broker、Consumer、Topic、Partition、Offset 和消费语义。",8,{"slug":1789,"path":1790,"title":1791,"date":1759,"tags":1792,"description":1797,"draft":1708,"hidden":1708,"published":1711,"readingTime":1798},"leetcode-lru-merge-k-reverse-list","\u002Fposts\u002Fleetcode-lru-merge-k-reverse-list","链表与缓存高频题：LRU Cache、合并 K 个有序链表、反转链表",[1793,1794,1795,1796,1761],"算法","链表","LRU","LeetCode","面试高频算法题速记，整理 LRU Cache、合并 K 个有序链表、反转链表的核心思路、复杂度和 C++ 代码。",6,{"slug":1800,"path":1801,"title":1802,"date":1803,"tags":1804,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1809},"meddococr-interpreter-source-analysis","\u002Fposts\u002Fmeddococr-interpreter-source-analysis","MedDocOCR-Interpreter 源码导读：医疗文档 OCR、结构化抽取与报告解读原型","2026-05-22 10:30:00",[1805,1730,1806,1729,1807,1808],"OCR","医疗 AI","Python","源码分析",16,{"slug":1811,"path":1812,"title":1813,"date":1814,"tags":1815,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1754},"cet6-writing-model-essays","\u002Fposts\u002Fcet6-writing-model-essays","六级写作范文背诵包：10 个高频话题","2026-05-20 09:00:00",[1816,1817,1818],"English","CET6","Writing",{"slug":1820,"path":1712,"title":5,"date":1707,"tags":1821,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1822},"claude-code-context-management",[1716,1717,1718,1719,1720],27,{"slug":1824,"path":1825,"title":1826,"date":1827,"tags":1828,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1834},"nanotron-llm-pretraining-framework-analysis","\u002Fposts\u002Fnanotron-llm-pretraining-framework-analysis","Nanotron 项目详解：Hugging Face 的大模型预训练框架怎么做分布式训练","2026-05-10 12:10:00",[1718,1829,1830,1831,1832,1719,1833],"大模型训练","分布式训练","Nanotron","Hugging Face","PyTorch",19,{"slug":1836,"path":1837,"title":1838,"date":1839,"tags":1840,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1847},"gofoundry-go-backend-foundation-framework","\u002Fposts\u002Fgofoundry-go-backend-foundation-framework","GoFoundry 项目详解：基于 Go 的后端基础框架套件设计","2026-05-10 11:20:00",[1841,1842,1843,1844,1845,1784,1846],"Go","后端框架","ORM","分布式缓存","分布式锁","项目架构",25,{"slug":1849,"path":1850,"title":1851,"date":1852,"tags":1853,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1822},"cloudvault-go-cloud-storage-system","\u002Fposts\u002Fcloudvault-go-cloud-storage-system","CloudVault 项目详解：基于 Go 的云端存储与网盘系统架构设计","2026-05-10 10:30:00",[1841,1854,1855,1856,1846,1857,1858,1859],"云存储","网盘系统","分布式系统","Redis","RabbitMQ","Elasticsearch",{"slug":1861,"path":1862,"title":1863,"date":1864,"tags":1865,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1868},"openclaw-source-code-analysis","\u002Fposts\u002Fopenclaw-source-code-analysis","OpenClaw 源码导读：个人 AI 助手的网关、通道、插件与运行时架构","2026-05-08 16:30:00",[1866,1717,1719,1867,1808],"OpenClaw","TypeScript",20,{"slug":1870,"path":1871,"title":1872,"date":1873,"tags":1874,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1754},"flow-matching-generative-models","\u002Fposts\u002Fflow-matching-generative-models","Flow Matching：从噪声到数据的连续流生成模型","2026-05-07 00:00:00",[1875,1876,1877,1878],"生成模型","Diffusion","Flow Matching","深度学习",{"slug":1880,"path":1881,"title":1882,"date":1883,"tags":1884,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1891},"database-ai-week4","\u002Fposts\u002Fdatabase-ai-week4","Week 4：数据库速成——从 Storage、Index、Query Optimization 到 Vector DB 与 RAG","2026-05-05 12:00:00",[1885,1886,1887,1729,1888,1889,1890],"数据库","CMU 15-445","Vector DB","LLM Memory","Query Optimization","Caching",15,{"slug":1893,"path":1894,"title":1895,"date":1896,"tags":1897,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1809},"distributed-systems-week3","\u002Fposts\u002Fdistributed-systems-week3","Week 3：分布式系统速成——MapReduce、Raft、容错与 Distributed KV Store","2026-05-05 11:00:00",[1856,1898,1899,1900,1901,1902,1717],"MIT 6.824","MapReduce","Raft","KV Store","Ray",{"slug":1904,"path":1905,"title":1906,"date":1907,"tags":1908,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1891},"gpu-inference-acceleration-week2","\u002Fposts\u002Fgpu-inference-acceleration-week2","Week 2：GPU 与推理加速——从 Kernel、算子融合到 LLM Serving","2026-05-05 10:00:00",[1878,1909,1910,1718,1911,1742,1912],"GPU","推理加速","CMU 10-414","TensorRT",{"slug":1914,"path":1915,"title":1916,"date":1917,"tags":1918,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1767},"dl-framework-autograd-mini","\u002Fposts\u002Fdl-framework-autograd-mini","Week 1：DL 框架与 Autograd——从计算图、反向传播到 Mini Autograd 实现","2026-05-05 09:00:00",[1878,1919,1833,1911,1920],"Autograd","Mini Framework",{"slug":1922,"path":1923,"title":1924,"date":1925,"tags":1926,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1777},"lock-free-concurrency-notes","\u002Fposts\u002Flock-free-concurrency-notes","无锁并发入门：从 CAS 到 Atomic Ring Buffer","2026-04-25",[1927,1928,1929,1930,1931],"C++","并发","无锁编程","性能优化","量化开发",{"slug":1933,"path":1934,"title":1935,"date":1936,"tags":1937,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1938},"agent-memory","\u002Fposts\u002Fagent-memory","Agent 对话记忆化：从原理到实现","2026-04-24",[1718,1717,1729,1761],5,{"slug":1940,"path":1941,"title":1942,"date":1936,"tags":1943,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1798},"llm-context-compression","\u002Fposts\u002Fllm-context-compression","LLM 上下文五层压缩机制详解",[1718,1717,1944,1761],"上下文压缩",{"slug":1946,"path":1947,"title":1948,"date":1949,"tags":1950,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1735},"cpp-concurrency-basics","\u002Fposts\u002Fcpp-concurrency-basics","C++ 并发编程入门：从数据竞争到线程池","2026-04-15",[1927,1928,1761,1931],{"slug":1952,"path":1953,"title":1954,"date":1955,"tags":1956,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1959},"travel-in-shenzhen","\u002Fposts\u002Ftravel-in-shenzhen","XCPC 深圳游记","2026-04-13",[1957,1927,1958],"XCPC","比赛",1,{"slug":1961,"path":1962,"title":1963,"date":1964,"tags":1965,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1969},"backend-stack-deep-dive","\u002Fposts\u002Fbackend-stack-deep-dive","后端五件套：FastAPI \u002F Node.js \u002F SQLAlchemy async \u002F PostgreSQL \u002F Docker 面试速通","2026-04-07",[1785,1966,1967,1968,1761],"FastAPI","PostgreSQL","Docker",7,{"slug":1971,"path":1972,"title":1973,"date":1974,"tags":1975,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1798},"deepscientist-tech-stack","\u002Fposts\u002Fdeepscientist-tech-stack","DeepScientist 技术栈全解析：一个 AI 科研平台的架构设计","2026-04-06",[1976,1966,1977,1967,1761],"全栈","Next.js",{"slug":1979,"path":1980,"title":1981,"date":1974,"tags":1982,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1787},"minicode-source-analysis","\u002Fposts\u002Fminicode-source-analysis","MiniCode 源码解析：用 5000 行 TypeScript 实现一个 AI 编程助手",[1867,1983,1718,1808,1761],"CLI",{"slug":1985,"path":1986,"title":1987,"date":1974,"tags":1988,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1938},"nova-theme-implementation","\u002Fposts\u002Fnova-theme-implementation","我是怎么从零实现 Nova 主题的",[1989,1990,1991],"Hexo","前端","开源",{"slug":1993,"path":1994,"title":1995,"date":1996,"tags":1997,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1640},"git-cheatsheet","\u002Fposts\u002Fgit-cheatsheet","Git 常用操作备忘","2026-04-05 14:00:00",[1998,1999],"Git","工具",{"slug":2001,"path":2002,"title":2003,"date":2004,"tags":2005,"description":55,"draft":1708,"hidden":1708,"published":1711,"readingTime":1641},"github-actions-intro","\u002Fposts\u002Fgithub-actions-intro","GitHub Actions 入门：自动化你的工作流","2026-04-04 09:00:00",[2006,2007,2008],"GitHub Actions","CI\u002FCD","自动化",1782796011452]