> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/context_engineering_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/context_engineering_guide/di-er-bu-fen-he-xin-ji-shu-yu-ce-le/06_compress/6.5_compression_cases.md).

# 6.5 压缩策略案例分析

本节通过具体案例展示压缩策略的实际应用，帮助读者深入理解不同压缩技术的适用场景和效果。

## 6.5.1 案例一：长文档会议纪要生成

### 场景描述：长文档会议纪要

用户上传一份长达 5 万字的行业研报，希望生成一份结构化的摘要，包含关键数据、主要观点和未来趋势。

### 挑战：长文档会议纪要

* **长度限制**：5 万字远超大多数模型的上下文窗口。
* **信息分散**：关键数据散落在文档各处。
* **结构要求**：输出需要严格遵循特定格式。

### 解决方案：递进式压缩 + 对话历史管理

1. **分块（Chunking）**：将 5 万字按章节切分为 10 个部分，每部分约 5000 字。
2. **并行摘要（Map）**：对每个部分并行调用 LLM，要求提取关键数据和观点。
   * *提示词策略*：明确要求输出 JSON 格式，包含 `key_points`, `data`, `trends` 字段。
3. **聚合（Reduce）**：将 10 个部分的摘要合并，再次调用 LLM 进行整合与去重。
4. **最终生成**：基于整合后的信息，生成符合用户要求的结构化报告。

### 效果对比

| 指标        | 直接输入（截断）    | 递进式压缩         |
| --------- | ----------- | ------------- |
| **信息覆盖率** | 低（仅覆盖截断范围）  | 高（覆盖范围更完整）    |
| **幻觉率**   | 较高风险（因信息缺失） | 较低风险（基于提取的事实） |
| **处理时间**  | 快（单次调用）     | 中（多次调用，可并行）   |

## 6.5.2 案例二：多轮对话中的长期记忆

### 场景描述：多轮对话记忆

一个陪伴型 AI 角色，需要记住用户几天前提到喜欢的电影，并在后续对话中自然引用。

### 挑战：多轮对话记忆

* **上下文膨胀**：随着对话进行，历史记录越来越长，迅速消耗 Token。
* **遗忘**：简单的滑动窗口会丢弃早期的重要信息（如用户喜好）。

### 解决方案：关键信息提取 + 摘要总结

1. **短期记忆（Short-term Memory）**：保留最近 10 轮对话的完整内容。
2. **长期记忆（Long-term Memory）**：
   * **实体提取**：每天结束时，使用专门的 Prompt 扫描当天对话，提取用户画像信息（如“喜欢《星际穿越》”）。
   * **摘要归档**：将当天的非关键闲聊压缩为一句话摘要（“周二聊了关于电影的话题”）。
3. **检索增强**：当用户再次聊到电影时，检索长期记忆中的相关实体。

### 代码实现示意（伪代码）

```python
def compress_history(history):
    # 提取实体
    user_profile_updates = extract_entities(history)
    update_user_profile(user_profile_updates)

    # 生成摘要
    summary = summarize_conversation(history)

    # 存入长期记忆库
    save_to_long_term(summary)

    return [] # 清空当前历史（或保留最后几轮）

# 在每轮对话前
context = get_recent_history() + retrieve_relevant_long_term_memory(current_query)
```

## 6.5.3 案例三：代码库理解与问答

### 场景描述：代码库理解

开发者询问关于整个项目架构的问题，项目包含数百个文件。

### 挑战：代码库理解

* **代码量巨大**：无法将所有代码放入 Context。
* **依赖关系复杂**：文件之间存在引用关系，单看一个文件难以理解全局。

### 解决方案：结构化压缩（骨架提取）

1. **生成骨架（Skeleton）**：为每个源代码文件生成“骨架”版本。
   * 保留：Class 定义、函数签名、关键注释、Import 语句。
   * 移除：函数体具体实现、内部逻辑。
2. **构建全景图**：将所有文件的骨架拼接，形成项目的“高层地图”。
3. **按需展开**：
   * LLM 先阅读骨架，定位到具体负责相关逻辑的文件。
   * 工具调用读取这些具体文件的完整内容。

### 压缩效果（示意）

* **原始大小**：可能达到 MB 级源码
* **骨架大小**：通常可显著缩小到原来的一个小比例（取决于代码风格与注释量）
* **效果**：更易让模型先建立项目结构，再按需展开细节，避免一次性加载全量代码。

## 6.5.4 案例四：长时程编程助手的渐进式上下文管理（示意）

### 场景描述：长时程编程助手

以 Claude Code 这类长时程编程助手为例，系统需要支持用户进行数小时甚至数天的开发任务，包括代码编写、文件修改、工具调用等。同时要在有限的上下文窗口内维持任务连续性，并控制成本。

### 挑战：长时程编程助手

* **任务跨度长**：一个任务可能涉及数十个 API 调用和文件操作
* **信息多层级**：既需要即时的工具结果，也需要跨会话的长期记忆
* **成本敏感**：每次 API 调用都有成本，频繁的上下文扩展会迅速积累
* **无缝体验**：用户期望在新会话中无缝继续工作，无需重新提供上下文

### 解决方案：递进式上下文策略

下面是教学示意，不代表任何特定产品的完整官方实现细节。设计哲学是“预防胜于治疗”，每一层设计目标都是减少下一层被触发的频率：

| 层级 | 技术                    | 成本       | TTL   | 用途          |
| -- | --------------------- | -------- | ----- | ----------- |
| 1  | 工具结果持久化               | 最低       | 永久    | 冷存储，2KB 预览  |
| 2  | 微压缩（Micro-compaction） | 极低       | 60 分钟 | 清理临时工具输出    |
| 3  | 会话记忆（Session Notes）   | 零 API 成本 | 永久    | 结构化摘要，预构建   |
| 4  | 完全压缩（Full Compaction） | 低        | 永久    | 9 部分总结，删除思考 |

**第 1 层：工具结果持久化（Disk + 2KB Preview，冻结状态缓存命中）**

每次工具执行（如 grep、read file）的结果不仅回传给模型，也同时写入磁盘。当上下文接近限制时，工具结果从上下文中移除，仅保留 2KB 的摘要预览。若模型在后续步骤中需要再次引用该结果，系统检测缓存命中情况：

* **缓存命中**：直接返回之前的完整结果，无需重新执行
* **缓存未命中**：重新执行工具并缓存

**第 2 层：微压缩（Micro-compaction，60 分钟 TTL）**

与提示词缓存 TTL 对齐，每 60 分钟自动对旧的工具输出进行一次轻量级压缩。不调用 LLM，而是采用启发式规则：

* 删除重复的执行结果
* 保留首次和最后一次执行的完整结果
* 中间结果聚合为一句话摘要

**第 3 层：会话记忆（Session Memory，结构化笔记，零 API 成本）**

在每个关键里程碑（如完成一个功能、解决一个问题），系统引导用户（或自动）生成结构化笔记 `MEMORY.md`：

* **容量限制**：最多 200 行或 25KB
* **条目格式**：每条约 150 字符，包含类别标签（项目模式、用户偏好、工具配置、领域知识）
* **成本**：零 API 调用，完全本地存储
* **效果**：新会话加载时，这份预构建的摘要能快速恢复关键上下文

**第 4 层：完全压缩（Full Compaction，9 部分总结）**

当会话记忆仍不足以处理新的查询时，触发完全压缩。调用 LLM 对整个会话进行总结，生成 9 个部分：

1. 任务目标与原始需求
2. 整体架构与设计决策
3. 已完成的步骤
4. 当前进度与活跃文件
5. 遇到的问题与解决方案
6. 用户偏好与特殊约束
7. 待解决的问题
8. 下一步计划
9. 关键代码片段与路径

* **处理**：去除详细的思考过程、冗余工具输出，保留结构化信息
* **存储**：压缩摘要保存为 COMPACTION.md，成为新会话的起点

### 工作流示意

```
会话开始
  ↓
加载 MEMORY.md（如存在）
  ↓
执行任务，记录工具结果到磁盘
  ↓
上下文接近 75%？
  ├─ 否：继续执行
  └─ 是：
      ├─ 距离上次压缩 < 60 分钟？
      │   ├─ 是：执行第 2 层微压缩
      │   └─ 否：检查 MEMORY.md 是否需要更新
      └─ 上下文仍接近限制？
          ├─ 是：执行第 4 层完全压缩，生成 COMPACTION.md
          └─ 否：继续工作
```

### 效果评估

* **成本削减**：需要用真实任务日志对比“无压缩”和“递进式压缩”的 token 使用量，不能直接套用固定节省比例
* **用户体验**：通过结构化记忆和缓存命中，新会话可更快恢复上下文；具体首 Token 延迟取决于模型、网络、缓存和检索实现
* **信息保留**：压缩质量应通过回放测试验证，重点观察关键决策、未解决问题和用户约束是否丢失

## 6.5.5 经验总结

1. **压缩不是目的，保留价值才是**：不仅要看压缩后省了多少 Token，更要看任务完成率是否下降。
2. **结构化优于非结构化**：在压缩代码或数据时，保留结构（如 JSON, XML, 代码签名）比纯文本摘要更有效。
3. **动态调整**：根据当前任务的复杂度动态调整压缩率。简单问答可以高压缩，复杂推理需要保留更多细节。
4. **分层设计**：采用递进式多层策略，每层预防下一层触发，可显著降低成本与延迟