研究解读 · 小互解读
重开会话，还是压缩历史？Pi 是如何解决模型上下文自动压缩问题的
一次长任务不会因为模型“记性好”而持续。它只是不断把过去重新塞进下一次请求；装不下时，Pi 会重写自己的工作记忆。
一分钟速览
- Compacting context 是把较早工作改写成更短的状态摘要，为长任务腾出上下文空间。
- Pi 默认保留最近约 20k tokens，给下一次回答预留 16384 tokens；这些数值是 Pi 的实现，不是行业通则。
- Compaction 是有损迁移：它保住工作连续性，却会丢细节，并让旧 prompt cache 暂时失效。
如果你让 Pi、Claude Code 或 Codex 连续改代码、查日志、跑测试，任务足够长时，多半见过类似 compacting context 的提示。
它不是在压缩代码，也不是在删除文件。它表示当前会话快要装满模型一次能够读取的信息空间，coding agent 正在把较早的工作记录改写成更短的版本，好让任务继续。
这个有限空间叫 context window，也就是上下文窗口。模型每次回答时，只能参考被放进这个窗口里的内容。长任务不断加入新消息、代码、日志、工具调用和执行结果，窗口便会越来越满。compacting context 出现，是因为 agent 必须在撞上容量上限之前，为后续工作腾出空间。
Earendil Engineering 专门写了一篇《How Compaction Works in Pi》，拆开 Pi 的处理方式。Pi 是一款运行在终端里的 coding agent。下面讲的是它的具体实现；其他 coding agent 也面对同一个通用问题，但触发阈值、保留量与摘要方法未必相同。
模型没记忆，只重放上下文
假设你让 agent 修一个支付故障，第一句只说“查一下 checkout 为什么返回 502”。模型真正收到的却不止这句话：还有 system prompt、工具定义、项目里的规则文件。它调用日志工具后，工具结果也会进入历史；你再补一条线索，下一次请求又会带上此前全部内容。