# Context Compression

> 当智能体会话历史膨胀到逼近上下文窗口、需要压缩对话或巨型代码库时使用；产出以「锚定式增量摘要」为主的结构化压缩方案（含触发时机、结构化摘要分区、探针评估）；不适用于短会话或重抓取成本极低的场景；触发词：上下文压缩、对话摘要、context window 超限

- Skill: `findscripter/context-compression` (Agent Skill)
- Install (CLI): `npx skillmds@latest add findscripter/context-compression`
- Raw SKILL.md: https://api.skillmd.com/api/skills/findscripter/context-compression/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: findscripter (https://skillmd.com/u/findscripter)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/findscripter/context-compression

---

## 何时使用

在以下情况启用本技能：

- 智能体会话历史超出上下文窗口限制（动辄百万 token）。
- 代码库本身超出窗口（5M+ token 级系统）。
- 设计对话摘要 / 会话压缩策略。
- 排查智能体「忘记自己改过哪些文件」一类问题。
- 构建压缩质量的评估框架。

**核心目标不是「每次请求最少 token」，而是「每个任务最少 token」**：从任务开始到完成消耗的总 token，包括压缩丢信息后被迫重新抓取的成本。一个只多省 0.5% token、却引发 20% 重抓取的策略，总账更亏。

**不该用的边界**：
- 会话很短、或重抓取成本极低时，直接用最激进的不透明压缩即可，无需本技能的结构化开销。
- 本技能产出的摘要不能替代环境内的实测、验证与专家复核。
- 缺少必要输入、权限、安全边界或成功标准时，先停下来澄清，不要硬压。

## 步骤

锚定式增量摘要（Anchored Iterative Summarization，首选）的落地流程：

1. 按智能体需求定义固定的摘要分区（见下方模板）。
2. 首次触发压缩时，把被截断的历史归纳进各分区。
3. 后续每次压缩，只归纳新截断的内容。
4. 把新摘要**增量合并**进已有分区，而不是整体重新生成（重生成会在多轮压缩中丢细节）。
5. 记录每条信息来自哪一轮压缩，便于排查。

**触发时机**同样关键：

| 策略 | 触发点 | 权衡 |
|------|--------|------|
| 固定阈值 | 上下文利用率 70-80% | 简单，但可能压得过早 |
| 滑动窗口 | 保留最近 N 轮 + 摘要 | 上下文大小可预测 |
| 重要性优先 | 先压低相关度片段 | 复杂但保信号 |
| 任务边界 | 在逻辑任务完成处压缩 | 摘要干净但时机不定 |

对多数编码智能体，**滑动窗口 + 结构化摘要**在可预测性与质量上最平衡。

## 指令

- 永远优化 tokens-per-task，而非 tokens-per-request。
- 用带显式分区的结构化摘要做文件追踪；分区即清单，强制摘要器逐项填写，防止信息「静默漂移」。
- 在上下文利用率 70-80% 时触发压缩。
- 用增量合并替代整体重生成。
- 用探针式评估检验压缩质量。
- 若文件追踪至关重要，单独维护工件索引（artifact index）/ 文件状态表。
- 接受略低的压缩率以换取更高的信息保留度。
- 把重抓取频率当作压缩质量的监控信号。

三种方案对比（可据此选型）：

| 方法 | 压缩率 | 质量分 | 权衡 |
|------|--------|--------|------|
| 锚定增量 | 98.6% | 3.70 | 质量最佳，压缩略低 |
| 重生成 | 98.7% | 3.44 | 质量尚可，可读性好 |
| 不透明 | 99.3% | 3.35 | 压缩最高，质量受损 |

多保留 0.7% 的 token 换来 0.35 质量分；凡重抓取有成本的任务，都该倾向结构化方案。选型口径：长会话 / 需文件追踪 / 要可验证 → 锚定增量；要极限省 token 且会话短 → 不透明；要摘要可读、阶段边界清晰 → 重生成。

**巨型代码库**（超窗口）走三阶段压缩：研究阶段产出一份结构化研究文档 → 规划阶段转成含函数签名、类型定义、数据流的实现规格（5M token 代码库≈2000 词规格）→ 实现阶段对着规格执行。若有手工迁移示例 / 参考 PR，用作模板，它能揭示静态分析看不到的约束与「本质复杂度 vs 偶然复杂度」的区分。

## 示例

**结构化摘要模板**：

```markdown
## 会话意图
[用户想完成什么]

## 文件改动
- auth.controller.ts: 修复 JWT token 生成
- config/redis.ts: 更新连接池
- tests/auth.test.ts: 为新配置补 mock

## 关键决策
- 用 Redis 连接池替代每请求一连接
- 瞬时失败采用指数退避重试

## 当前状态
- 14 个测试通过，2 个失败

## 下一步
1. 修复剩余失败用例
2. 跑全量测试
3. 更新文档
```

**探针式评估**：压缩后直接提问来量化功能质量（ROUGE / 向量相似度抓不到这点——摘要词面重合度高，却可能丢了智能体唯一需要的那个文件路径）。

| 探针类型 | 测什么 | 示例问题 |
|----------|--------|----------|
| 召回 | 事实保留 | "原始报错信息是什么？" |
| 工件 | 文件追踪 | "我们改过哪些文件？" |
| 续接 | 任务规划 | "下一步该做什么？" |
| 决策 | 推理链 | "关于 Redis 问题我们定了什么？" |

**好坏对比**——问「最初的报错是什么」：
- 好（结构化）："/api/auth/login 返回 401 Unauthorized，凭据有效仍失败，根因是会话存储中 Redis 连接陈旧。"——端点、错误码、根因俱全。
- 差（激进压缩）："我们在调一个认证问题，登录失败了，修了些配置。"——技术细节全丢。

## 注意事项

- **工件追踪是普遍最弱项**（评估中仅 2.2-2.5/5.0）：即便带显式文件分区，长会话里也难保完整。编码智能体需要知道哪些文件被创建 / 被改且改了什么 / 只读未改，以及函数名、变量名、报错信息——必要时用独立的工件索引或脚手架里的显式文件状态追踪来补强。
- 评估覆盖六维：准确性、上下文感知、工件追踪、完整性、连续性、指令遵循。准确性在各方法间差异最大（0.6 分差距），工件追踪普遍偏弱。
- 不透明压缩压缩率最高（99%+）但不可解释，无法验证保留了什么——慎用于需要审计的场景。

## 互见

- context-degradation：压缩是对抗上下文退化的缓解手段。
- context-optimization：压缩只是众多优化技术之一。
- evaluation：探针式评估同样适用于压缩测试。
- memory-systems：压缩与暂存区 / 摘要记忆模式相关。

---

采编自 sickn33/antigravity-awesome-skills（MIT 许可）。原文外部参考：Factory Research《Evaluating Context Compression for AI Agents》(2025-12)、LLM-as-judge 评估方法（Zheng et al., 2023）、Netflix Engineering《The Infinite Software Crisis》(AI Summit 2025)。