58
0这一章深入解析了 Claude Code 在面对 200K Token 上下文窗口限制时，如何通过精密的阈值判定、摘要生成和失败恢复机制来管理长会话的记忆。
以下是该章节的核心内容概括：
1. 自动压缩的触发阈值（何时压缩）
自动压缩并非在窗口完全填满时触发，而是留有三层防线：
核心公式：
自动压缩阈值 = (原始窗口 - 20,000 预留) - 13,000 缓冲区。触发比例：以 Claude 3.5 Sonnet (200K) 为例，实际阈值约为 167,000 tokens。这意味着当对话消耗约 83.5% 的空间时，压缩就会启动。
环境变量覆盖：用户可以通过
CLAUDE_CODE_AUTO_COMPACT_WINDOW缩小窗口值或通过百分比覆盖来强制更早触发压缩。
2. 压缩提示词的 9 段式模板（如何压缩）
为了保证压缩后的摘要不丢失关键信息，系统使用了包含 9 个结构化段落的提示词模板：
涵盖内容：包括显式请求、技术概念、代码片段（要求全量保留而非摘要）、调试历史、所有用户消息、待办任务及当前工作状态。
草稿块 ：利用“思维链”技术，要求模型在生成正式摘要前先按时间顺序进行分析，该草稿块在完成后会被剥离以节省 token。严禁工具调用：提示词首尾都有强硬指令禁止模型在压缩过程中调用工具，以防止因模型尝试工具调用而导致输出为空（该错误率在 Sonnet 4.6 上曾达 2.79%）。
3. 熔断器机制（失败保护）
为了防止系统陷入“压缩失败 → 下一轮继续压缩”的死循环（源码记录曾有会话因此连续失败 3,272 次，造成巨大资源浪费），系统设计了 10 行代码的熔断器：
如果连续 3 次 自动压缩失败，系统会停止尝试。
哲学原则：宁可让用户手动执行
/compact，也不要用注定失败的重试浪费 API 预算。
4. 极致的 PTL（Prompt Too Long）重试
当对话过长导致“压缩请求本身”都超过 API 限制时，系统会启动 truncateHeadForPTLRetry 机制：
按轮次分组：确保不会拆散工具调用与其结果。
头部截断：精确丢弃最旧的内容（通常是 20% 的消息组）以腾出空间。
修复序列：确保截断后的消息仍以
user角色开头（通过插入PTL_RETRY_MARKER）。
5. 压缩后的状态恢复
先忘后记：压缩完成后会清空旧的文件状态缓存，但会立即触发 createPostCompactFileAttachments，重新读取最重要的 5 个文件（约 50,000 tokens）注入上下文。这确保了模型虽然丢失了对话细节，但依然拥有最新的生产文件上下文。
6. v2.1.100 的版本演进
冷压缩 (Cold Compact)：引入了 Feature Flag 驱动的延迟压缩策略，允许在更合适的断点执行压缩。
快速回填熔断器：如果压缩后 3 回合内上下文又迅速填满，系统会触发熔断以防止“压缩-回填”的系统震荡。
主动权下放：新增了用户可手动触发的
/compact命令和确认对话框。
总结原则：自动压缩的设计体现了 “多层缓冲、渐进降级、可观测性与用户可控” 的工程哲学，旨在实现一种“用户永远察觉不到”的无缝上下文管理体验。
