名称： context-compression
描述： 当用户要求“压缩上下文”、“总结对话历史”、“实施压缩”、“减少令牌使用”，或提及上下文压缩、结构化摘要、任务令牌优化、或超出上下文限制的长时间运行代理会话时，应使用此技能。

上下文压缩策略

当代理会话生成数百万令牌的对话历史时，压缩变得必不可少。简单粗暴的方法是进行激进压缩以最小化每次请求的令牌数。正确的优化目标是任务令牌数：完成一个任务所消耗的总令牌数，包括因压缩丢失关键信息而重新获取所产生的成本。

何时激活

在以下情况下激活此技能：
- 代理会话超出上下文窗口限制
- 代码库超出上下文窗口（500万+令牌的系统）
- 设计对话摘要策略
- 调试代理“忘记”修改了哪些文件的情况
- 构建压缩质量评估框架

核心概念

上下文压缩在节省令牌和丢失信息之间进行权衡。存在三种可用于生产环境的方法：

1. 锚定迭代摘要：维护结构化的、持久的摘要，明确包含会话意图、文件修改、决策和后续步骤等部分。触发压缩时，仅总结新截断的片段，并与现有摘要合并。通过为特定类型信息分配专门部分，这种结构强制保留信息。

2. 不透明压缩：生成优化重建保真度的压缩表示。实现最高的压缩率（99%以上），但牺牲了可解释性。无法验证保留了哪些内容。

3. 再生式完整摘要：每次压缩时生成详细的结构化摘要。产生可读的输出，但由于完全重新生成而非增量合并，可能在多次压缩周期中丢失细节。

关键洞见：结构强制保留。专用部分充当摘要器必须填写的检查清单，防止信息无声漂移。

详细主题

为何任务令牌数至关重要

传统的压缩指标针对每次请求的令牌数。这是错误的优化方向。当压缩丢失了文件路径或错误消息等关键细节时，代理必须重新获取信息、重新探索方法，并浪费令牌来恢复上下文。

正确的指标是任务令牌数：从任务开始到完成所消耗的总令牌数。一个节省0.5%更多令牌但导致重新获取成本增加20%的压缩策略，总体成本反而更高。

工件追踪问题

在所有压缩方法中，工件追踪完整性是最薄弱的维度，在评估中得分仅为2.2-2.5（满分5.0）。即使具有明确文件部分的结构化摘要，也难以在长时间会话中保持完整的文件跟踪。

编码代理需要知道：
- 创建了哪些文件
- 修改了哪些文件以及更改了什么
- 读取了哪些文件但未更改
- 函数名、变量名、错误消息

这个问题可能需要超越通用摘要的特殊处理：在代理脚手架中使用单独的工件索引或显式的文件状态跟踪。

结构化摘要部分

有效的结构化摘要包含明确的部分：

## 会话意图
[用户试图实现的目标]

## 已修改文件
- auth.controller.ts: 修复了JWT令牌生成
- config/redis.ts: 更新了连接池配置
- tests/auth.test.ts: 为新配置添加了模拟设置

## 已做决策
- 使用Redis连接池而非每次请求连接
- 为瞬时故障添加指数退避重试逻辑

## 当前状态
- 14个测试通过，2个失败
- 剩余：会话服务测试的模拟设置

## 后续步骤
1.  修复剩余的测试失败
2.  运行完整测试套件
3.  更新文档

这种结构防止了文件路径或决策的无声丢失，因为每个部分都必须被明确处理。

压缩触发策略

何时触发压缩与如何压缩同样重要：

对于大多数编码代理用例，结合结构化摘要的滑动窗口方法在可预测性和质量之间提供了最佳平衡。

基于探针的评估

ROUGE或嵌入相似度等传统指标无法捕捉功能性压缩质量。一个摘要可能在词汇重叠上得分很高，却遗漏了代理需要的那一个文件路径。

基于探针的评估通过压缩后提问直接衡量功能性质量：

如果压缩保留了正确的信息，代理就能正确回答。否则，它会猜测或产生幻觉。

评估维度

六个维度捕捉了编码代理的压缩质量：

1. 准确性：技术细节是否正确？文件路径、函数名、错误码。
2. 上下文感知：响应是否反映当前对话状态？
3. 工件追踪：代理是否知道读取或修改了哪些文件？
4. 完整性：响应是否回答了问题的所有部分？
5. 连续性：工作能否在不重新获取信息的情况下继续？
6. 指令遵循：响应是否尊重了规定的约束？

不同压缩方法之间，准确性差异最大（0.6分差距）。工件追踪普遍较弱（2.2-2.5分范围）。

实践指导

三阶段压缩工作流

对于超出上下文窗口的大型代码库或代理系统，通过三个阶段应用压缩：

1. 研究阶段：从架构图、文档和关键接口生成研究文档。将探索过程压缩为组件和依赖关系的结构化分析。输出：单一研究文档。
2. 规划阶段：将研究转化为实现规范，包含函数签名、类型定义和数据流。一个500万令牌的代码库可压缩为约2000字的规范。
3. 实施阶段：根据规范执行。上下文保持专注于规范，而非原始的代码库探索。

使用示例工件作为种子

当提供手动迁移示例或参考PR时，将其用作模板来理解目标模式。该示例揭示了静态分析无法呈现的约束：哪些不变量必须保持、哪些服务会在更改时中断，以及干净的迁移是什么样子。

当代理无法区分本质复杂性（业务需求）和偶然复杂性（遗留变通方法）时，这一点尤其重要。示例工件编码了这种区别。

实施锚定迭代摘要

1. 定义与代理需求匹配的明确摘要部分
2. 首次触发压缩时，将截断的历史总结到各部分中
3. 后续压缩时，仅总结新截断的内容
4. 将新摘要合并到现有部分，而非重新生成
5. 为调试目的，跟踪哪些信息来自哪个压缩周期

何时使用每种方法

在以下情况下使用锚定迭代摘要：
- 会话是长时间运行的（100+条消息）
- 文件跟踪很重要（编码、调试）
- 需要验证保留了哪些内容

在以下情况下使用不透明压缩：
- 需要最大限度的令牌节省
- 会话相对较短
- 重新获取成本较低

在以下情况下使用再生式摘要：
- 摘要可解释性至关重要
- 会话有清晰的阶段边界
- 每次压缩时允许完整上下文审查

压缩率考量

结构化摘要保留的额外0.7%令牌换来了0.35的质量分。对于任何重新获取成本重要的任务，这种权衡倾向于结构化方法。

示例

示例1：调试会话压缩

原始上下文（89,000令牌，178条消息）：
- /api/auth/login 端点出现401错误
- 追踪了认证控制器、中间件、会话存储
- 发现Redis连接陈旧
- 修复了连接池，添加了重试逻辑
- 14个测试通过，2个失败

压缩后的结构化摘要：

## 会话意图
调试 /api/auth/login 端点在使用有效凭据时仍返回401未授权错误。

## 根本原因
会话存储中的Redis连接陈旧。JWT生成正确，但会话无法持久化。

## 已修改文件
- auth.controller.ts: 无更改（仅读取）
- middleware/cors.ts: 无更改（已检查）
- config/redis.ts: 修复了连接池配置
- services/session.service.ts: 为瞬时故障添加了重试逻辑
- tests/auth.test.ts: 更新了模拟设置

## 测试状态
14个通过，2个失败（模拟设置问题）

## 后续步骤
1.  修复剩余的测试失败（模拟会话服务）
2.  运行完整测试套件
3.  部署到预发布环境

示例2：探针响应质量

压缩后，询问“原始错误是什么？”：

良好响应（结构化摘要）：

“原始错误是来自 /api/auth/login 端点的401未授权响应。用户在使用有效凭据时收到此错误。根本原因是会话存储中的Redis连接陈旧。”

较差响应（激进压缩）：

“我们正在调试一个认证问题。登录失败。我们修复了一些配置问题。”

结构化响应保留了端点、错误码和根本原因。激进响应丢失了所有技术细节。

指导原则

1. 优化任务令牌数，而非每次请求的令牌数
2. 使用具有明确文件跟踪部分的结构化摘要
3. 在上下文利用率达到70-80%时触发压缩
4. 实施增量合并，而非完全重新生成
5. 使用基于探针的评估测试压缩质量
6. 如果文件跟踪至关重要，单独跟踪工件路径
7. 为获得更好的质量保留，接受稍低的压缩率
8. 监控重新获取频率，作为压缩质量的信号

集成

此技能与集合中的其他几个技能相关联：

• context-degradation - 压缩是应对性能下降的缓解策略
• context-optimization - 压缩是众多优化技术之一
• evaluation - 基于探针的评估适用于压缩测试
• memory-systems - 压缩与便笺和摘要内存模式相关

参考文献

内部参考：
- 评估框架参考 - 详细的探针类型和评分细则

本集合中的相关技能：
- context-degradation - 理解压缩能防止什么
- context-optimization - 更广泛的优化策略
- evaluation - 构建评估框架

外部资源：
- Factory Research: Evaluating Context Compression for AI Agents (December 2025)
- Research on LLM-as-judge evaluation methodology (Zheng et al., 2023)
- Netflix Engineering: "The Infinite Software Crisis" - 三阶段工作流和大规模上下文压缩 (AI Summit 2025)

技能元数据

创建日期：2025-12-22
最后更新：2025-12-26
作者：上下文工程代理技能贡献者
版本：1.1.0