上下文压缩策略

当智能体会话生成了数百万令牌的对话历史时，压缩就变得势在必行。一种简单粗暴的方法是进行激进压缩，以最小化每次请求的令牌数。但正确的优化目标应是每个任务的令牌数：即完成一个任务所消耗的总令牌数，包括因压缩丢失关键信息而导致的重新获取成本。

何时启用

在以下情况下启用此技能：

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

核心概念

上下文压缩是在节省令牌数与信息损失之间进行权衡。现有三种可用于生产环境的方法：

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

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

3. 再生式完整摘要：对每次压缩生成详细的结构化摘要。产生可读输出，但由于采用完全再生而非增量合并的方式，在多次压缩循环中可能会丢失细节。

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

详细主题

为何"每任务令牌数"至关重要

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

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

工件轨迹问题

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

编码代理需要了解：

• 哪些文件被创建
• 哪些文件被修改及其具体变化
• 哪些文件被读取但未更改
• 函数名、变量名、错误信息

这个问题可能需要超越通用摘要的专业处理：在代理框架中建立独立的工件索引或明确的状态跟踪机制。

结构化摘要章节

有效的结构化摘要应包含明确章节：

## 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

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

压缩触发策略

触发压缩的时机与压缩方式同等重要：

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

基于探针的评估

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

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

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

评估维度

六个维度用于衡量编码代理的压缩质量：

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

准确性在不同压缩方法之间显示出最大的差异（0.6分的差距）。人为痕迹普遍较弱（在2.2-2.5的范围内）。

实践指导

三阶段压缩工作流程

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

1. 研究阶段：从架构图、文档和关键接口中生成一份研究文档。将探索过程压缩为对组件和依赖关系的结构化分析。输出：一份研究文档。

2. 规划阶段：将研究转化为包含函数签名、类型定义和数据流的实现规范。一个500万token的代码库可以压缩到大约2000字的规范。

3. 实施阶段：根据规范执行。上下文保持专注于规范，而不是原始的代码库探索。

使用示例工件作为种子

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

这一点在智能体无法区分本质复杂性（业务需求）和偶然复杂性（遗留解决方案）时尤为重要。示例工件编码了这种区别。

实施锚定迭代式摘要

1. 定义与智能体需求匹配的明确摘要板块
2. 首次触发压缩时，将截断的历史记录汇总到各板块中
3. 后续压缩时，仅汇总新增的截断内容
4. 将新摘要合并到现有板块中而非重新生成
5. 追踪各轮压缩的信息来源以便调试

各类方法的适用场景

在以下情况使用锚定迭代式摘要：

• 会话持续时间较长（100+条消息）
• 需要跟踪文件状态（编码、调试场景）
• 需要验证信息保留完整性

何时使用不透明压缩：

• 需要最大程度节省令牌数
• 会话相对较短
• 重新获取成本较低

何时使用再生式摘要：

• 摘要的可解释性至关重要
• 会话具有清晰的阶段边界
• 每次压缩时允许完整上下文回顾

压缩率考量

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

示例

示例1：调试会话压缩

原始上下文（89,000个标记，178条消息）：

• /api/auth/login端点出现401错误
• 追踪了身份验证控制器、中间件、会话存储
• 发现Redis连接陈旧
• 修复了连接池，添加了重试逻辑
• 14项测试通过，2项失败

压缩后的结构化摘要：

## 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未授权响应。用户在使用有效凭据时收到此错误。根本原因是会话存储中的Redis连接陈旧。”

较差响应（激进压缩）：

"我们当时在调试一个认证问题。登录功能失效了。我们修复了一些配置问题。"

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

指导原则

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

集成

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

• 上下文降级 - 压缩是应对降级的一种缓解策略
• 上下文优化 - 压缩是众多优化技术中的一种
• 评估 - 基于探针的评估适用于压缩测试
• memory-systems - 压缩技术与便笺式和摘要式内存模式相关

参考文献

内部参考：

• 评估框架参考- 详细的探测类型与评分标准

本集合中的相关技能：

• context-degradation - 理解压缩技术所防止的问题
• context-optimization - 更广泛的优化策略
• evaluation - 构建评估框架

外部资源：

• Factory Research：评估AI代理的上下文压缩（2025年12月）
• 关于LLM作为评判者的评估方法研究（Zheng等，2023年）
• Netflix工程："无限的软件危机" - 大规模的三阶段工作流与上下文压缩（AI峰会 2025年）

技能元数据

创建时间：2025年12月22日最后更新：2025年12月26日作者语境工程贡献者所需技能版本: 1.1.0