Context Compression（上下文压缩）
Context Compression
Context Compression — compressing conversation history when the window runs out
Compressed context may lose critical details, causing the next session to misread state — compression is a double-edged sword. The three strategies each trade quality, compression rate, and interpretability differently.
Context Compression（上下文压缩）
定义
Context compression 是指在 agent session 中对话历史超出 context window 容量时，将已有 context 压缩为更短表示的技术。它是 context management 的核心机制之一，直接影响 长时运行 agent 能否在压缩后继续有效工作。
压缩策略谱系
Factory 的评估研究 在 36,000+ 条真实开发 session 消息上对比了三种生产级策略：
结构化摘要（Structured Summarization）
以 Factory 的锚定式迭代摘要（Anchored Iterative Summarization）为代表。核心设计：
- 维护持久的结构化摘要，显式 section 覆盖 session intent、file modifications、decisions、next steps
- 压缩触发时仅总结新截断部分，增量合并到已有摘要
- 结构迫使保留——每个 section 是检查清单，防止信息静默丢失
优势：质量最高（总分 3.70/5.0），尤其在 Accuracy（4.04）和 Context Awareness（4.01）上领先。劣势：需要预定义摘要结构，对不同任务类型可能需要不同的 section 设计。
不透明压缩（Opaque Compression）
以 OpenAI 的 /responses/compact 端点为代表。产生加密的压缩表示，优化模型重建能力。
优势：压缩率最高（99.3%）。劣势：不可解释——无法阅读或验证压缩内容；质量最低（3.35/5.0），技术细节（文件路径、错误信息）丢失严重。
全量重生成摘要（Full Regeneration Summary）
以 Anthropic Claude SDK 的内建压缩为代表。每次压缩时从头生成完整的结构化摘要（7-12k 字符）。
优势：摘要结构清晰，包含 analysis、files、pending tasks、current state。劣势：每次重新生成可能导致细节在多次压缩周期中漂移或消失（3.44/5.0）。
评估维度
传统的文本相似度指标（ROUGE、embedding similarity）不能衡量 agent 能否继续工作。Factory 提出的 probe-based 功能质量评估直接测试压缩后的任务继续能力：
| 探针类型 | 测试目标 |
|---|---|
| Recall | 具体事实是否存活（错误信息、配置值） |
| Artifact | agent 是否知道自己操作过哪些文件 |
| Continuation | agent 能否从中断处继续 |
| Decision | 过去决策的推理链是否保留 |
六个评分维度：Accuracy、Context Awareness、Artifact Trail、Completeness、Continuity、Instruction Following。
Artifact Tracking：未解决的难题
所有压缩方法在文件追踪上的得分都很低（2.19-2.45/5.0）。即使结构化摘要的显式文件 section 也只达到 2.45。这暗示 artifact 保留可能需要超越摘要的专门机制：
- 独立的 artifact 索引（文件路径 + 操作类型 + 变更摘要）
- Agent scaffolding 层的显式文件状态追踪
- 与 feature tracking 类似的外部化状态
这一发现与 长时运行 agent 的”状态断裂”失败模式直接相关——当 agent 忘记自己修改过哪些文件，就会产生不一致的编辑或重复工作。
优化目标的重定向
Factory 的研究揭示了一个关键认知转换：
正确的优化目标不是 tokens per request，而是 tokens per task。
高压缩率（如 OpenAI 的 99.3%）看似节省 token，但丢失的细节最终需要 agent 重新获取文件、重新探索已尝试的方案。这些重新获取的成本可能超过压缩节省的 token。
这与 context engineering 的核心原则——“找到最小的高信号 token 集合”——形成呼应：压缩的目标不是最小化 token 数，而是最大化保留的信号密度。
Manus 的”可恢复才可压缩”原则
Manus 为 context compression 引入了一个生产级约束：压缩必须是可逆的。具体规则：
- 网页内容可从 context 中移除，但 URL 必须保留
- 文档内容可省略，但文件路径必须保留
- 不可恢复的压缩（无法通过指针重新获取原始内容）等同于数据销毁，被明确禁止
这将压缩的优化目标从”最小化 context 长度”转移到”最大化可逆性”。与 Factory 研究中”tokens per task 优于 tokens per request”的量化发现互相印证：被压缩丢失的信息最终需要 agent 重新获取，总成本可能更高。
Claude Code 的 AutoCompact 实现
Claude Code 源码分析揭示了生产级 compaction 的具体实现：
AutoCompact（autoCompact.ts）：接近 token 限制时触发，派遣次级 Claude 实例对历史进行摘要。摘要器在 <analysis> 标签内进行思维链推理，然后剥除推理过程，仅将压缩摘要插入 context。与 Factory 评估中”全量重生成摘要”策略（Anthropic SDK 内建）类似，但增加了思维链辅助。
Microcompaction：比 AutoCompact 更轻量的分层策略：
- 触发时机：空闲期（与 cache TTL 过期挂钩）
- 保留：
tool_use调用块（函数调用本身） - 替换：实际工具输出 →
[Old tool result content cleared] - 保证：始终保留最近 5 条工具结果完整内容
这种分层策略体现了”不同老化程度的内容适用不同压缩力度”的思路——最近结果完整保留，深层历史仅保留结构元数据。
与 Context Rot 的互补关系
Context rot 研究的是”context 太长导致性能退化”；context compression 研究的是”压缩 context 时丢失关键信息”。两者共同定义了 context 管理的双重约束：
- 不压缩：context 过长 → context rot 导致性能下降
- 过度压缩：关键信息丢失 → agent 需要重新获取，浪费 token 和时间
- 最优策略：在保留功能性信息和控制 context 长度之间找到平衡
相关概念
- Context management — compression 是 context management 的核心机制
- Context engineering — 压缩是 context 策展的一环
- Context rot — 压缩的动机之一是对抗 context rot
- Long-running agents — 压缩对长时 agent 至关重要
- Feature tracking — 外部化状态可弥补压缩的 artifact 丢失
- Harness engineering — harness 层的设计决定压缩策略的选择
References
sources/factory-evaluating-context-compression.mdsources/manus-context-engineering.mdsources/claude-code-source-leak-2026.md