介绍
# Context Compression Strategies
当 Agent 会话产生数百万 Token 的对话历史时，压缩变得势在必行。一种朴素的方法是激进压缩以最小化每次请求的 Token 数量。正确的优化目标是“每个任务的 Token 数”：完成任务所消耗的总 Token 数，包括当压缩丢失关键信息时重新获取信息的成本。
## 何时激活
在以下情况激活此技能： - Agent 会话超出上下文窗口限制 - 代码库超出上下文窗口（500 万+ Token 系统） - 设计对话摘要策略 - 调试 Agent “忘记”修改了哪些文件的情况 - 构建压缩质量的评估框架
## 核心概念
上下文压缩在 Token 节省与信息丢失之间进行权衡。存在三种生产就绪的方法：
1. **锚定迭代摘要**：维护结构化的持久摘要，包含会话意图、文件修改、决策和后续步骤等显式部分。当触发压缩时，仅对新截断的跨度进行摘要，并与现有摘要合并。结构通过为特定信息类型指定部分来强制保留信息。
2. **不透明压缩**：生成针对重建保真度优化的压缩表示。实现最高的压缩比（99%+），但牺牲了可解释性。无法验证保留了什么。
3. **再生式全量摘要**：在每次压缩时生成详细的结构化摘要。生成可读的输出，但由于完全重新生成而非增量合并，可能会在重复压缩周期中丢失细节。
关键见解：结构强制保留。专用部分充当检查清单，摘要器必须填充这些部分，从而防止静默信息漂移。
## 详细主题
### 为什么每个任务的 Token 数很重要
传统的压缩指标针对每个请求的 Token 数。这是错误的优化。当压缩丢失关键细节（如文件路径或错误消息）时，Agent 必须重新获取信息、重新探索方法，并浪费 Token 来恢复上下文。
正确的指标是每个任务的 Token 数：从任务开始到完成所消耗的总 Token 数。一种虽然节省了 0.5% 更多 Token 但导致 20% 更多重新获取的压缩策略，总体成本更高。
### 工件轨迹问题
工件轨迹的完整性是所有压缩方法中最薄弱的维度，在评估中得分为 2.2-2.5（满分 5.0）。即使是带有显式文件部分的结构化摘要，也难以在长会话中维护完整的文件跟踪。
编码 Agent 需要知道： - 创建了哪些文件 - 修改了哪些文件以及更改了什么 - 读取了哪些文件但未更改 - 函数名、变量名、错误消息
这个问题可能需要超越一般摘要的专门处理：独立的工件索引或 Agent 脚手架中的显式文件状态跟踪。
### 结构化摘要部分
有效的结构化摘要包括显式部分：
```markdown ## Session Intent [What the user is trying to accomplish]
## Files Modified - auth.controller.ts: Fixed JWT token generation - config/redis.ts: Updated connection pooling - tests/auth.test.ts: Added mock setup for new config
## Decisions Made - Using Redis connection pool instead of per-request connections - Retry logic with exponential backoff for transient failures
## Current State - 14 tests passing, 2 failing - Remaining: mock setup for session service tests
## Next Steps 1. Fix remaining test failures 2. Run full test suite 3. Update documentation ```
这种结构防止文件路径或决策的静默丢失，因为必须明确处理每个部分。
### 压缩触发策略
何时触发压缩与如何压缩同样重要：
| 策略 | 触发点 | 权衡 | |----------|---------------|-----------| | 固定阈值 | 70-80% 上下文利用率 | 简单但可能压缩过早 | | 滑动窗口 | 保留最后 N 轮 + 摘要 | 可预测的上下文大小 | | 基于重要性 | 首先压缩低相关性部分 | 复杂但保留信号 | | 任务边界 | 在逻辑任务完成时压缩 | 摘要清晰但时机不可预测 |
对于大多数编码 Agent 用例，带有结构化摘要的滑动窗口方法提供了可预测性和质量的最佳平衡。
### 基于探针的评估
像 ROUGE 或嵌入相似度这样的传统指标无法捕捉功能性的压缩质量。摘要可能在词汇重叠方面得分很高，但错过了 Agent 需要的文件路径。
基于探针的评估通过在压缩后提出问题来直接测量功能质量：
| 探针类型 | 测试内容 | 示例问题 | |------------|---------------|------------------| | 回忆 | 事实保留 | “原始错误消息是什么？” | | 工件 | 文件跟踪 | “我们修改了哪些文件？” | | 连续性 | 任务规划 | “我们接下来应该做什么？” | | 决策 | 推理链 | “关于 Redis 问题我们决定了什么？” |
如果压缩保留了正确的信息，Agent 将正确回答。如果没有，它会猜测或产生幻觉。
### 评估维度
六个维度捕捉了编码 Agent 的压缩质量：
1. **准确性**：技术细节是否正确？文件路径、函数名、错误代码。 2. **上下文感知**：响应是否反映当前的对话状态？ 3. **工件轨迹**：Agent 是否知道读取或修改了哪些文件？ 4. **完整性**：响应是否处理问题的所有部分？ 5. **连续性**：能否在不重新获取信息的情况下继续工作？ 6. **指令遵循**：响应是否遵守声明的约束？
准确性在压缩方法之间显示出最大的差异（0.6 分差距）。工件轨迹普遍较弱（2.2-2.5 范围）。
## 实践指南
### 三阶段压缩工作流
对于大型代码库或超出上下文窗口的 Agent 系统，通过三个阶段应用压缩：
1. **研究阶段**：从架构图、文档和关键接口生成研究文档。将探索压缩为组件和依赖关系的结构化分析。输出：单个研究文档。
2. **规划阶段**：将研究转换为包含函数签名、类型定义和数据流的实现规范。500 万 Token 的代码库压缩为大约 2,000 字的规范。
3. **实施阶段**：根据规范执行。上下文保持专注于规范，而不是原始代码库探索。
### 使用示例工件作为种子
当提供手动迁移示例或参考 PR 时，将其用作理解目标模式的模板。该示例揭示了静态分析无法显示的约束：哪些不变量必须保持，哪些服务会在更改时中断，以及干净的迁移是什么样的。
当 Agent 无法区分本质复杂性（业务需求）和偶然复杂性（遗留变通方案）时，这尤其重要。示例工件编码了这种区别。
### 实施锚定迭代摘要
1. 定义符合 Agent 需求的显式摘要部分 2. 在首次压缩触发时，将截断的历史记录摘要到各部分中 3. 在随后的压缩中，仅摘要新截断的内容 4. 将新摘要合并到现有部分中，而不是重新生成 5. 跟踪哪些信息来自哪个压缩周期以便调试
### 何时使用每种方法
**在以下情况使用锚定迭代摘要：** - 会话是长时间运行的（100+ 条消息） - 文件跟踪很重要（编码、调试） - 您需要验证保留了什么
**在以下情况使用不透明压缩：** - 需要最大的 Token 节省 - 会话相对较短 - 重新获取成本较低
**在以下情况使用再生式摘要：** - 摘要可解释性至关重要 - 会话具有明确的阶段边界 - 每次压缩时可以接受完整的上下文审查
### 压缩比考虑因素
| 方法 | 压缩比 | 质量得分 | 权衡 | |--------|-------------------|---------------|-----------| | 锚定迭代 | 98.6% | 3.70 | 最佳质量，压缩略低 | | 再生式 | 98.7% | 3.44 | 良好质量，中等压缩 | | 不透明 | 99.3% | 3.35 | 最佳压缩，质量损失 |
结构化摘要保留的额外 0.7% Token 换来了 0.35 个质量点。对于任何重新获取成本都很重要的任务，这种权衡有利于结构化方法。
## 示例
**示例 1：调试会话压缩**
原始上下文（89,000 Token，178 条消息）： - /api/auth/login 端点上的 401 错误 - 通过 auth 控制器、中间件、会话存储进行追踪 - 发现 Redis 连接过期 - 修复了连接池，添加了重试逻辑 - 14 个测试通过，2 个失败
压缩后的结构化摘要：
```markdown ## Session Intent Debug 401 Unauthorized error on /api/auth/login despite valid credentials.
## Root Cause Stale Redis connection in session store. JWT generated correctly but session could not be persisted.
## Files Modified - auth.controller.ts: No changes (read only) - middleware/cors.ts: No changes (examined) - config/redis.ts: Fixed connection pooling configuration - services/session.service.ts: Added retry logic for transient failures - tests/auth.test.ts: Updated mock setup
## Test Status 14 passing, 2 failing (mock setup issues)
## Next Steps 1. Fix remaining test failures (mock session service) 2. Run full test suite 3. Deploy to staging ```
**示例 2：探针响应质量**
压缩后，询问“原始错误是什么？”：
良好响应（结构化摘要）： > “原始错误是来自 /api/auth/login 端点的 401 Unauthorized 响应。用户使用有效凭据收到此错误。根本原因是会话存储中的 Redis 连接过期。”
糟糕响应（激进压缩）： > “我们正在调试身份验证问题。登录失败了。我们修复了一些配置问题。”
结构化响应保留了端点、错误代码和根本原因。激进响应丢失了所有技术细节。
## 指南
1. 优化每个任务的 Token 数，而不是每个请求的 Token 数 2. 使用带有显式文件跟踪部分的结构化摘要 3. 在 70-80% 上下文利用率时触发压缩 4. 实施增量合并而不是完全重新生成 5. 使用基于探针的评估测试压缩质量 6. 如果文件跟踪至关重要，请单独跟踪工件轨迹 7. 接受略低的压缩比以获得更好的质量保留 8. 监控重新获取频率作为压缩质量的信号
## 集成
此技能连接到集合中的其他几个技能：
- context-degradation（上下文退化）- 压缩是退化的一种缓解策略 - context-optimization（上下文优化）- 压缩是众多优化技术中的一种 - evaluation（评估）- 基于探针的评估适用于压缩测试 - memory-systems（内存系统）- 压缩与便笺簿和摘要内存模式有关
## 参考文献
内部参考： - [评估框架参考](./references/evaluation-framework.md) - 详细的探测类型和评分标准
本集合中的相关技能： - context-degradation - 了解压缩能防止什么 - context-optimization - 更广泛的优化策略 - evaluation - 构建评估框架
外部资源： - Factory Research: Evaluating Context Compression for AI Agents (2025年12月) - 关于 LLM-as-judge 评估方法论的研究 - Netflix Engineering: "The Infinite Software Crisis" - 三阶段工作流程和大规模上下文压缩 (AI Summit 2025)
---
## 技能元数据
**创建时间**：2025-12-22 **最后更新**：2025-12-26 **作者**：Agent Skills for Context Engineering 贡献者 **版本**：1.1.0