上下文压缩策略

当代理会话生成数百万令牌的对话历史时，压缩变得强制性。简单的方法是积极压缩以最小化每个请求的令牌数。正确的优化目标是每个任务的令牌数：完成一个任务所消耗的总令牌数，包括压缩丢失关键信息时重新获取的成本。

何时激活

在以下情况下激活此技能：

代理会话超出上下文窗口限制
代码库超出上下文窗口（5M+令牌系统）
设计对话摘要策略
调试代理“忘记”它们修改了哪些文件的情况
构建压缩质量评估框架

核心概念

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

锚定迭代摘要：维护具有明确部分的结构化、持久摘要，用于会话意图、文件修改、决策和下一步操作。当触发压缩时，仅摘要新截断的范围并与现有摘要合并。结构通过将部分专用于特定信息类型来强制保存。
不透明压缩：生成优化重建保真度的压缩表示。实现了最高的压缩比率（99%+），但牺牲了可解释性。无法验证保留了什么。
再生性完整摘要：在每次压缩时生成详细的结构化摘要。产生可读的输出，但由于每次压缩周期都是全面再生而不是增量合并，可能会丢失细节。

关键见解：结构强制保存。专用部分充当检查表，摘要器必须填充，防止信息静默漂移。

详细主题

为什么每个任务的令牌数很重要

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

正确的指标是每个任务的令牌数：从任务开始到完成所消耗的总令牌数。节省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. 更新文档

这个结构防止了文件路径或决策的静默丢失，因为每个部分必须明确解决。

压缩触发策略

触发压缩的时间和如何压缩同样重要：

策略	触发点	权衡
固定阈值	上下文利用率的70-80%	简单但可能过早压缩
滑动窗口	保留最后的N个回合+摘要	可预测的上下文大小
基于重要性	首先压缩低相关性部分	复杂但保留信号
任务边界	在逻辑任务完成时压缩	干净的摘要但不可预测的时间

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

基于探针的评估

传统的指标如ROUGE或嵌入相似性未能捕捉到功能性压缩质量。摘要可能在词汇重叠上得分很高，但错过了代理需要的一个文件路径。

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

探针类型	它测试什么	示例问题
回忆	事实保留	“原始错误消息是什么？”
工件	文件跟踪	“我们修改了哪些文件？”
继续	任务规划	“我们接下来应该做什么？”
决策	推理链	“我们对Redis问题做出了什么决定？”

如果压缩保留了正确的信息，代理回答正确。如果没有，它猜测或幻想。

评估维度

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

准确性：技术细节正确吗？文件路径、函数名称、错误代码。
上下文意识：响应是否反映了当前对话状态？
工件轨迹：代理是否知道哪些文件被读取或修改？
完整性：响应是否涵盖了问题的所有部分？
连续性：不重新获取信息可以继续工作吗？
指令遵循：响应是否尊重声明的约束？

准确性显示了压缩方法之间最大的变化（0.6点差距）。工件轨迹普遍薄弱（2.2-2.5范围）。

实际指导

三阶段压缩工作流程

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

研究阶段：从架构图、文档和关键接口中制作研究文件。将探索压缩成组件和依赖关系的分析。输出：单个研究文件。
规划阶段：将研究转换为实现规范，包括函数签名、类型定义和数据流。一个5M令牌的代码库压缩到大约2000字的规范。
实施阶段：根据规范执行。上下文保持集中在规范上而不是原始代码库探索。

使用示例工件作为种子

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

这在代理无法区分基本复杂性（业务需求）和偶然复杂性（遗留工作）时特别重要。示例工件编码了这种区别。

实施锚定迭代摘要

定义与代理需求匹配的明确摘要部分
在第一次压缩触发时，将截断的历史摘要到部分
在后续压缩中，仅摘要新截断的内容
将新摘要合并到现有部分中，而不是重新生成
跟踪哪些信息来自哪个压缩周期以进行调试

何时使用每种方法

当会话长时运行（100+消息）时，使用锚定迭代摘要：

文件跟踪很重要（编码、调试）
需要验证保留了什么

当需要最大令牌节省时，使用不透明压缩：

会话相对较短
重新获取成本较低

当摘要可解释性至关重要时，使用再生性摘要：

会话有明确的阶段边界
每个压缩上的完整上下文审查是可以接受的

压缩比率考虑

方法	压缩比率	质量评分	权衡
锚定迭代	98.6%	3.70	最佳质量，稍微较少的压缩
再生性	98.7%	3.44	质量良好，中等压缩
不透明	99.3%	3.35	最佳压缩，质量损失

结构化摘要保留的额外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连接陈旧。”

较差响应（积极压缩）：

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

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

指南

优化每个任务的令牌数，而不是每个请求的令牌数
使用具有明确部分的结构化摘要进行文件跟踪
在上下文利用率达到70-80%时触发压缩
实施增量合并而不是全面再生
使用基于探针的评估测试压缩质量
如果文件跟踪至关重要，则单独跟踪工件轨迹
接受稍微较低的压缩比率以获得更好的质量保留
将重新获取频率作为压缩质量信号进行监控

集成

这项技能与集合中的其他技能相连：

context-degradation - 压缩是退化的缓解策略
context-optimization - 压缩是众多优化技术之一
evaluation - 基于探针的评估适用于压缩测试
memory-systems - 压缩与草稿本和摘要记忆模式相关

参考资料

内部参考：

评估框架参考 - 详细的探针类型和评分标准

技能元数据

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