上下文装不下时，怎么办？¶

🧭 综合·决策框架 | 信源 4 篇

上下文窗口永远是稀缺资源。本章与第五章的信源给出了四种互斥的处理路线，各有明确的代价——综合成一棵决策树，代价全部引自条目实测数字。

决策树¶

第一问：丢得起细节吗？

├─ 丢得起 → 阶梯式压缩。 按语义分数分级删除：关键信息保留，低分内容逐步折叠。实测 token 消耗降低 52%，且提供可预测的成本上限。代价：压缩是有损的——信息在一轮轮总结中丢失，如果后面又需要这些细节，Agent 可能会"编"而不是承认不知道。适用：20–30 轮以上的长对话。

├─ 丢不起、任务可交接 → Context Reset。 与 Compaction（压缩历史继续跑）不同，Reset 直接换一个干净上下文的新 Agent，通过工作交接实现"清空包袱、重新出发"。代价：交接文档的质量决定一切——写得不好的交接等于从零开始。适用：阶段明确的工程任务。

├─ 跨会话还要用 → 外置记忆 + QA 编译。 见本章演进页：自由文本记忆经知识编译（转成 QA 对）后幻觉率从 30% 压至 5% 以下，准确率 95%+。代价：写入与编译是持续的治理成本——记什么、何时过期、谁来审计，这些纪律比选型难得多。

└─ 知识在别处（实时/权限）→ 检索。 知识有截止日期、企业数据不能进上下文时，这是唯一合法路线。代价：检索质量成为新的工程面——分块、重排、引用、拒答，见第十章。

两条常见错误：一、在"丢得起"的场景上外置记忆——治理成本全付了，复利没拿到（对比页《Claude Code vs OpenClaw》对同一陷阱有更完整的讨论）；二、在"权限敏感"的场景上压缩——压缩解决的是"放不下"，解决不了"不该让它看见"。