上下文压缩调度：工具裁剪与历史记录压缩

IMPORTANT

本文重点在压缩调度的讲解，解决的是要将哪些上下文传递给大模型进行压缩的场景问题，是偏向于代码层面设计处理，和上下文压缩指令的篇幅是压缩节点一前一后的关系，压缩调度是前，压缩指令是在后

目前的压缩机制主要是两种策略：工具输出的结果裁剪和压缩、会话历史记录的压缩

NOTE

也就是说目前的压缩机制主要操作的上下文类型就是

• 工具输入输出的上下文
• 会话历史记录的上下文

在每一次将上下文输入给 LLM 之前都会进行上下文的检查，检查目前的上下文是否超过 LLM 的最大上下文长度的 (90%-95%)，我的理解是分为预检查处理和检查之后的处理

1. 预检查的处理：对于工具的输出尽可能的保留关键的部分，工具的输出不要冗余，实现的方式如下：
   1. 限制工具的最大内容数量，例如：读取工具限制最大读取行数，最大字符数
   2. 分层读取：当超过最大读取行数的话，可以使用分层读取策略，也就是文件前面读取多少，中间读取多少，最后读取多少
   3. 大模型总结摘要：当文件超过 2000 字符的时候，使用大模型进行总结，只返回大模型总结摘要
   4. 渐进式读取：参考 Skill 的设计思路，对于要读取的文件列表先”粗”读、再”细”读
2. 检查之后的处理：当 Agent 不断的循环执行，工具的调用已经被裁剪压缩到很”健康”的状态了，这个时候上下文窗口依旧很多，无法通过检查，那么可以考虑对于历史记录进行压缩

一、前置处理 - 工具输出裁剪和压缩

对于工具的输出是有两层判断的，第一层是某些工具才会有，第二层是全部的工具都会有

1. 第一层判断：判断工具的输出是否大于 100000 个字符，如果大于的话要进行截断
2. 第二层判断：每一个工具的输出不超过 2000 个字符，当判断字符超过 2000 个的时候，就会让大模型总结摘要

对于第二层的判断还有总结，我觉得有以下几种情况可以考虑

1. 直接输出大模型的总结摘要
2. 输出前 2000 个字符 + 大模型的总结摘要
3. 不使用大模型进行总结，可以根据文件类型进行截断

二、兜底处理 - 会话历史记录压缩

对会话历史记录进行压缩，有两种方案进行考虑：

1. 大模型压缩：这种方式非常方便和快速，提示词很关键
2. **工具裁剪：**在上下文中，工具类型的消息 Token 占比最大，优先考虑裁剪前百分之 70 的历史记录中的工具消息

TIP

采用 Cursor 的做法就是，在摘要总结提供给 Agent 的时候，再提供一个历史文件位置或者索引。如果 Agent 发现自己需要的更多细节没有包含在摘要中，它可以在历史中搜索以找回这些信息。