# 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. **分层设计**：采用递进式多层策略，每层预防下一层触发，可显著降低成本与延迟


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET 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?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.