【导语在与 AI 编程助手对话时常因对话历史过长使 token 超过限制而报错。Earendil 编码助手 Pi 通过「compaction」机制处理这一问题本文详细解析其原理、优势及与竞品的差异。】对话超限困境与 Pi 的应对之策在使用 LLM 编程助手时当对话历史过长token 超过上下文窗口限制就会报错。此时通常有两条路一是扔掉所有历史重新开始但会丢失之前的决策、修复记录和未完成工作且存在「context rot」问题二是压缩对话历史Pi 选择了这条路。Pi 的「compaction」机制运作细节Pi 的「compaction」触发时机有三种每次对话回合结束后自动检查上下文是否接近 token 限制用户手动/compact遇到上下文溢出错误时紧急压缩。其关键设计是保留最近约 5 - 20 个回合默认 20,000 token 的「最近消息」阈值可配置的对话不动只压缩更早部分。压缩是一个独立的 LLM 请求使用专门的 prompt要求输出按「目标、进展、关键决策」三段组织的结构化摘要。这种设计可使用不同模型进行压缩不增加主对话模型成本且摘要以纯文本存储跨模型迁移无格式兼容问题。「compaction」的副作用与优势Compaction 会破坏 prompt cache因为它改变了上下文前缀使缓存失效。但压缩之后的请求又会重新享受缓存加速因为前缀再次稳定。与 Claude Code 对比不同策略各有优劣Claude Code 的 compaction 是将整个对话包括工具调用结果压缩成一段摘要继续。而 Pi 保留最近 N 轮对话只压缩更早部分更细粒度。Pi 的方案在「保留上下文连续性」和「释放 token 空间」间折中Claude Code 的方案更激进但可能丢失工具调用细节。可扩展设计定制化的编程助手Earendil 强调 Pi 设计原则是「extensible and malleable」用户可替换 compaction 机制若觉得默认摘要 prompt 不好可写扩展用自己的 prompt 生成摘要这体现了 Pi 作为可修改和定制工具的定位。编辑观点Pi 的「compaction」机制为解决对话历史过长问题提供了有效方案其可扩展设计也增加了灵活性。与竞品对比各有特点未来有望在市场中占据一席之地。