"你了解 Claude Code 的上下文窗口和 Auto-Compact 吗？它是怎么做上下文管理的？"
"上下文窗口本质上是模型一次推理能看到的 token 空间，不是长期记忆。Claude Code 作为编程 Agent，比普通聊天更容易消耗上下文，因为它不仅有用户消息和模型回复，还会持续累积工具定义、文件读取内容、命令输出、测试日志、diff、错误重试和中间决策。
真正把窗口撑爆的，往往不是用户说了多少，而是工具调用轨迹太重。
常见方案比如滑动窗口、摘要、RAG、长期记忆和子 Agent 都有价值，但单独用都不够。滑动窗口容易丢任务背景，普通摘要容易丢约束，RAG 更适合找知识，不适合保存执行轨迹，长期记忆适合稳定规则，不适合当前任务状态，子 Agent 能隔离探索噪音，但主 Agent 仍然需要拿到可执行结论。
所以 Claude Code 更像是分层做上下文治理。前面先通过 Glob、Grep、Read 精准取上下文，减少无关文件；
再对工具结果做裁剪，避免日志淹没任务；
复杂探索交给子 Agent，用独立窗口跑，主 Agent 只接收摘要；
稳定规则放到 CLAUDE.md 和 memory；最后当上下文接近上限时，由 Auto-Compact 把旧对话和工具轨迹压成结构化任务状态。
Auto-Compact 不是简单总结聊天记录，而是保留用户目标、约束、关键决策、已修改文件、当前进度、未完成事项和风险，把重复日志、无关搜索、已被结论覆盖的中间过程丢掉。
压缩后，系统提示词、根 CLAUDE.md、memory 等稳定规则会重新进入上下文，compact 摘要作为当前任务状态，后续文件和规则再按需加载，所以 Agent 能继续执行。核心思想是：保留状态，丢弃噪音。"
这个回答已经够用了。
如果想再加分，可以补一句：
Claude Code 的上下文管理不是为了让模型看见更多，而是为了让模型在每一步都看见更有价值的信息。
追问 1：为什么不直接把上下文窗口做大？
窗口变大能缓解问题，但不能解决问题。
因为上下文越大，成本越高，延迟越高，注意力稀释也更明显。
Agent 真正需要的是高质量上下文，不是无限长上下文。
大窗口适合兜底，不能替代上下文治理。
追问 2：RAG 能不能替代 Auto-Compact？
不能。
RAG 解决的是外部知识召回，Auto-Compact 解决的是会话执行状态压缩。
RAG 适合问"相关代码在哪里"，Auto-Compact 适合保留"当前任务做到哪一步"。
一个偏检索，一个偏状态延续。
追问 3：压缩会不会导致幻觉？
会有风险。
如果摘要把不确定信息写成确定结论，后续 Agent 就会沿着错误状态继续执行。
所以压缩摘要里要区分：
- 已确认事实
- 推测判断
- 未验证事项
- 已排除路径
好的 compact 摘要必须保留不确定性，不能把所有中间过程都写成结论。
追问 4：项目规则应该放对话里，还是 CLAUDE.md 里？
稳定规则放 CLAUDE.md。
临时任务要求放当前对话。
如果某条规则跨任务都重要，比如"不要改数据库 schema"，就不应该只靠一次聊天告诉模型，应该写进项目级记忆。
因为早期对话可能被压缩，但项目根 CLAUDE.md这类稳定规则会在压缩后重新注入。
追问 5：如果你自己设计 Agent 的上下文压缩，会怎么做？
我会分三步。
第一步，先做上下文预算统计，知道 token 花在哪：系统提示词、工具定义、文件内容、命令输出、历史对话分别占多少。
第二步，按信息价值压缩：工具原文优先裁剪，任务目标和约束必须保留，文件状态和未完成事项必须保留。
第三步，用结构化摘要接续任务，而不是自然语言闲聊摘要。摘要里明确写目标、进度、已改文件、关键决策、未完成事项和风险。
最后再配合子 Agent 隔离大范围探索，避免主上下文被噪音污染。
十三、普通开发者怎么用得更稳？
理解原理之后，使用建议也就很清楚了。
第一，一次会话只做一个主任务。
不要在同一个会话里又修 bug、又重构、又加功能、又讨论方案。
任务越杂，compact 摘要越难保留正确状态。
第二，稳定规则写进 CLAUDE.md。
比如技术栈、测试命令、禁止改动范围、代码风格，不要只在聊天里说。
第三，长日志不要无脑贴。
能让工具跑就让工具跑，能截关键报错就截关键报错。
第四，压缩前主动说清楚保留重点。
如果当前任务复杂，可以手动 /compact focus on ...，明确让它保留某个模块、某个 bug、某个改动方向。
第五，换任务就 /clear。
不要让旧任务的上下文污染新任务。
很多 Agent 漂移，不是模型能力不行，而是上下文太脏。
