# 上下文压缩调度：工具裁剪与历史记录压缩
> 🌵 本文重点在**压缩调度**的讲解、解决的是要将哪些上下文传递给大模型进行压缩到场景问题？是偏向于代码层面设计处理，和上下文压缩指令的篇幅是压缩节点一前一后的关系，压缩调度是前，压缩指令是在后

Excalidraw 文件链接：[https://ai.feishu.cn/file/SZkgbujE4oal40xyyu4c9YMvnJc](https://ai.feishu.cn/file/SZkgbujE4oal40xyyu4c9YMvnJc)


![Reason-cli的上下文压缩机制的设计](./image/image%20(81).png)

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

> 也就是说目前的压缩机制主要操作的上下文类型就是
>
> + 工具输入输出的上下文
> + 会话历史记录的上下文
>

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

1. 预检查的处理：对于工具的输出尽可能的保留关键的部分，工具的输出不要冗余，实现的方式如下：
    1. **限制工具的最大内容数量**，例如：读取工具限制最大读取行数，最大字符数
    2. **分层读取**：当超过最大读取行数的话，可以使用分层读取策略，也就是文件前面读取多少，中间读取多少，最后读取多少，这种策略在处理日志文件会非常有用
    3. **大模型总结摘要**：当文件超过 2000 字符的时候（最大内容限制，可以自定义），这个时候使用大模型进行总结，只返回大模型总结摘要
    4. **渐进式读取**：参考 Skill 的设计思路，对于要读取的文件列表先“粗”读、再“细”读，先读取文件的前 50 行内容和 LLM 的总结摘要（100-300 字左右），随着工具和 LLM 的推理进行，发现有一些文件需要深度读取，这个时候在完整的将文件内容加载进来
2. 检查之后的处理：当 Agent 不断的循环执行，工具的调用已经被裁剪压缩到很“健康”的状态了，这个时候上下文窗口依旧很多，无法通过检查，那么可以考虑对于历史记录进行压缩：
    1. 简单的实现：使用 LLM 进行压缩处理+保留最近的 30%的完整记录
    2. 使用压缩指令：[上下文压缩指令：ClaudeCode与Gemini的压缩指令](../上下文管理/上下文压缩指令：ClaudeCode与Gemini的压缩提示词解析.md)
    3. 如果历史记录中存在工具调用，可以考虑先清理工具调用

## 一、前置处理 - 工具输出裁剪和压缩
Excalidraw 文件链接：[https://ai.feishu.cn/file/Tgg1bAAwdonZemxrl8ycqORpnDr](https://ai.feishu.cn/file/Tgg1bAAwdonZemxrl8ycqORpnDr)

![工具输出裁剪和压缩](./image/image%20(82).png)

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

1. **第一层判断**：这一层的判断只有部分工具会有，一般情况下都是读取工具会有这个判断，**判断工具的输出是否大于 100000 个字符**，如果大于的话要进行截断，
    1. 这个是为了第二层进行大模型总结的时候，把模型的上下文也撑爆了
    2. 同时也做一个文件大小的极限控制，而不是无限制的读取传递
2. **第二层判断**：这一层的判断是全部工具都会进行，**这里才是限制上下文的关键**，**每一个工具的输出不超过 2000 个字符**，这样工具在上下文中的 Token 占比就可以控制，不至于读取几个文件就爆掉了
    1. 当判断字符超过 2000 个的时候，就会让大模型总结摘要
    2. 👀 当然这里要注意大模型的总结的输出不要太多，否则就不是总结摘要了，而是内容扩写的情况，就本末倒置的了



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

1. 直接输出大模型的总结摘要，这个时候内容可能会稀释很多，有可能会漏掉一些细节
2. 输出前 2000 个字符+大模型的总结摘要：这个会稳健一些，能保留一些存在前面的关键细节，同时大模型总结摘要又可以保留关键的信息
3. 不使用大模型进行总结，可以根据文件类型进行截断，保留前面一些，保留后面一些这种方式



## 二、兜底处理 - 会话历史记录压缩
Excalidraw 文件链接：[https://ai.feishu.cn/file/LdUVbTLFeoMg6ExNZ0bczZwin8d](https://ai.feishu.cn/file/LdUVbTLFeoMg6ExNZ0bczZwin8d)

![会话历史记录压缩](./image/image%20(83).png)

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

1. **大模型压缩**：这种方式是非常方便和快速的，这种情况下提示词很关键，如何保证大模型生成的摘要不会丢失上下文的关键信息
2. **工具裁剪：**在上下文中，为工具类型的消息，Token 占比是最大的，又是工具的输出，所以优先考虑裁剪前百分之 70 的历史记录中的工具消息可能会更加合适



:::warning
🚀 采用 Cusor 的做法就是，在摘要总结提供给 Agent 的时候，在提供一个历史文件位置或者索引

2、在摘要的过程中引用对话历史

当模型的上下文窗口被填满时，Cursor 会触发一次摘要步骤，为 Agent 提供一个全新的上下文窗口，其中包含它迄今为止工作的摘要。

但由于这是对上下文的有损压缩，Agent 的掌握情况在摘要之后可能会变差，可能会忘记任务中的关键细节。在 Cursor 中，我们将对话历史作为文件提供，以提升摘要的质量。

在达到上下文窗口上限后，或者用户决定手动进行摘要时，**我们会给 Agent 一个指向历史文件的引用。如果 Agent 发现自己需要的更多细节没有包含在摘要中，它可以在历史中搜索以找回这些信息**。

:::