文章摘要
Pi等编码代理在长时间会话中会触发压缩机制，因为LLM的上下文窗口有限。每次请求包含系统提示、文件、工具定义和对话历史，随着会话增长会超出窗口限制，导致LLM拒绝请求，因此需要压缩来管理上下文。
文章总结
文章核心内容重述
标题：Pi 中的压缩机制是如何工作的
核心问题： 大型语言模型（LLM）的上下文窗口有限。在编程代理（如 Pi）的长时间对话中，每次交互都会累积系统提示、工具调用和对话历史，当总长度超过上下文窗口时，LLM 会拒绝请求。
解决方案：压缩（Compaction） 当对话接近上下文限制时，有两种选择： 1. 开启新对话：丢弃所有历史记录，但会丢失之前的决策和未完成的工作。 2. 压缩上下文：将历史内容压缩成更小的表示，保留关键信息，使对话得以继续。
Pi 的具体实现：
- 触发条件：当上下文接近限制时自动触发，也可通过 /compact 命令手动触发。压缩通常在对话轮次结束后进行，若遇到上下文溢出错误，也会在轮次中触发。
- 保留机制：压缩时，Pi 会保留最近的一些消息（默认约 20,000 个 token，相当于 5-20 轮对话），而将更早的消息提取出来进行总结。
- 压缩提示词：Pi 使用独立的压缩请求，其系统提示词改为“你是一个上下文总结助手”，用户消息要求生成“结构化的对话分支摘要”，包含目标、进展和关键决策等部分。这个独立请求可以使用不同的 LLM 模型，避免不必要的成本。
- 结果存储：压缩结果以纯文本形式存储在会话中，保持可读性和可移植性，允许在 Pi 中切换模型后继续使用。
压缩与提示缓存的关系： - 压缩会破坏原有的提示缓存，因为压缩后的上下文前缀发生了变化（旧历史被替换为摘要）。 - 但压缩后的新请求会重新建立提示缓存，从而降低后续请求的成本。
实验性功能： 由于 Pi 具有可扩展性，用户可以创建自定义扩展来替换其压缩机制，例如通过自定义压缩提示词来测试不同的压缩方式。
评论总结
根据评论内容，总结如下：
主要观点与论据：
压缩（Compaction）的痛点：多数评论者认为压缩是本地LLM使用中的主要瓶颈。例如，评论3指出“压缩一直是个痛苦的过程”，需要解析近128k上下文并生成5-10k token，耗时较长（10-45t/s）。评论6建议“保持上下文尽可能小”以避免压缩。
替代方案与优化：
- 动态上下文修剪：评论4提到OpenCode通过标记工具、聊天等部分，让代理折叠和展开摘要，实现1M+上下文操作。
- 推理时压缩：评论5提出在GPU上直接操作token，暂停推理、替换旧工具调用为摘要，重建KV缓存，可处理1000个50k长的markdown文件。
- 双KV缓存乒乓：评论6描述了一种方法，一个缓存生成token时，另一个立即摘要，交替使用以节省时间。
- 选择性压缩：评论8希望“只压缩噪声MCP工具调用、测试运行等”，保留其余内容。
对现有方案的不满：
- 压缩破坏KV缓存：评论13批评压缩“丢弃整个KV缓存”，导致缓存未命中，浪费时间和金钱。
- 摘要丢失意图：评论10认为摘要对话会导致“LLM丢失意图或上下文”，更倾向于修剪低价值消息而非压缩。
- 缺乏深度：评论9指出文章未深入讨论摘要链过长时的处理。
其他建议：
- 使用专用压缩端点：评论7建议Pi与OpenAI计划配合时，使用其专用压缩端点。
- 图像压缩：评论11提到OMP将默认压缩改为图像，将上下文以微小文本写入图像，节省生成成本。
- 提示缓存限制：评论12认为提示缓存机制“抑制了更创意的压缩技术”，如渐进式压缩可能打破缓存。
平衡性总结：评论对压缩技术普遍持批评态度，认为其耗时、破坏缓存、丢失意图。但部分评论者提出了替代方案（动态修剪、推理时压缩、双缓存、选择性压缩），并指出本地模型与API服务的不同优化路径。整体上，用户更倾向于保留原始对话历史，而非摘要。