你正在和一个 Coding Agent 合作一个复杂的项目。已经聊了三个小时，改了几十个文件，跑了无数个测试。然后突然，它卡住了。不是因为它不知道答案，而是因为它“记不住”了。
这是每一个重度 AI 编程用户都经历过的场景。但大多数人把它归咎于模型不够好，或者上下文窗口不够大。他们错了。
真正的问题不是容量，而是注意力。
上下文窗口是一个谎言
2025 年，Chroma 发布了一份名为“Context Rot”的研究报告，测试了 18 个前沿模型——包括 GPT-4.1、Claude Opus 4、Gemini 2.5。结论令人不安：上下文越长，模型表现越差，而且这种退化不是线性的，它在每个长度增量上都存在。早先 Liu 等人 2023 年的论文“Lost in the Middle”（arXiv:2307.03172）已经揭示了一个更具体的现象：当相关信息被埋在长上下文的中间时，LLM 的准确率会骤降 15 到 25 个百分点。
这意味着什么？即使一个模型宣称支持 200K 甚至 1M Token 的上下文窗口，实际可用的上下文远比这个数字小。上下文窗口不是容量，而是预算。
这种矛盾在 Coding Agent 的场景中被急剧放大。一个典型的编码会话会包含：系统提示词、工具定义、加载的文件内容、持续扩大的对话历史、工具调用及其结果。每一次用户消息、每一次助手回复、每一次文件读写，都在消耗这个预算。一个 128K Token 的上下文窗口，在活跃的编码会话中可能撑不过几十分钟。
当预算耗尽，LLM 会直接返回错误：Request exceeds the maximum size。会话被迫中断。
面对这个困境，业界的普遍做法是“加大窗口”——从 4K 到 32K，从 128K 到 1M，再到号称“无限”的上下文。但 Chroma 的研究已经证明，更大的窗口只是给模型提供了一个更长的跑道来“腐烂”。加大窗口没有解决注意力的问题，只是把问题推迟了。
Earendil 团队在开发开源 Coding Agent Pi 时，选择了一条不同的路。
遗忘是一种能力
Pi 没有试图把所有内容塞进上下文窗口。它选择了一个更反直觉的方向：在适当的时候，主动遗忘。
这个机制叫做 Compaction。它的核心逻辑极其简单：当对话上下文接近窗口限制时，Pi 用一次独立的 LLM 请求，对历史会话生成一个结构化摘要，然后用这个摘要替换掉大部分旧内容，保留最近的消息不变。
但简单逻辑背后的工程实现，藏着精妙的设计。
Pi 的 Compaction 触发条件是一个简洁的公式：contextTokens > contextWindow - reserveTokens。默认的 reserveTokens 是 16384 个 Token，意味着 Pi 会在上下文达到窗口容量减去 16384 时触发压缩，这 16384 个 Token 被预留给模型输出，而不是让整个窗口被输入占满。Pi 同时默认保留最近的 20000 个 Token（约 5 到 20 轮对话），这些内容原封不动地保留在上下文中。20000 这个数字不是随意选的，它代表了一个平衡点：足够新近的对话不出现在摘要中，保证模型能准确理解当前正在进行的操作。
用户也可以手动触发——在 Pi 中键入 /compact 命令，甚至可以附带自定义指令来引导摘要的焦点。
两次独立的对话
Compaction 最有趣的设计在于，它本质上是 LLM 与自己的一次对话。
Pi 在触发 Compaction 时，发送的不是普通的编码助手请求。它使用了一个专门的系统提示词：“你是一个上下文摘要助手”，而不是“你是一个专业的编码助手”。用户消息也完全不同，它要求生成“一个结构化的会话分支摘要，用于后续返回时理解上下文”，并明确指定了摘要需要包含的段落：目标、进展和关键决策。
这个请求是独立的，不携带任何已有对话历史。这意味着两件事。第一，它可以使用不同的模型，比如说用更便宜的模型做摘要，用更强大的模型做编码，各自承担最合适的成本。第二，摘要本身不会被上下文污染，保持客观性。
生成的摘要被存储为纯文本的 CompactionEntry，附加到会话中。由于是纯文本格式，它可以在不同模型之间自由切换。你可以在 Pi 中从 GPT-4 切换到 Claude，再切换回来，Compaction 摘要仍然有效。Earendil 团队将这种设计称为“可移植性”（portability），这也是 Pi 与闭源 Coding Agent 的重要区别。
切割的艺术
一个好的摘要替代了什么？Pi 的切割策略值得仔细审视。
一个“turn”从用户消息开始，包含所有助手响应和工具调用，直到下一个用户消息。Pi 的切割点必须落在 assistant 消息上，而不能在 tool result 中间切割，因为工具结果必须和它的工具调用保持在一起。如果单个 turn 超出了 keepRecentTokens 的预算，就变成了“split turn”：Pi 将该 turn 的前缀消息单独提取，生成两份摘要，然后合并成一份。
Pi 的 Compaction 还支持多次压缩。在第二次压缩时，摘要的起始点不是从最早的对话开始，而是从上一次压缩的保留边界（firstKeptEntryId）开始。这意味着上一次压缩中幸存下来的消息，仍然会被纳入下一次的摘要范围，不会因为“刚被压缩过”就被永久豁免。
这种精细的边界管理，确保了 Compaction 后的上下文仍然是连贯的、可用的，而不是简单的“一刀切”。
代价：缓存被打破
Compaction 不是没有代价的。
LLM 提供商广泛使用 Prompt Caching 来加速重复请求。当同一个会话中的请求前缀完全相同时，缓存部分可以直接复用，大幅降低延迟和成本。但 Compaction 改变了前缀：[system][tools][older history][recent turns] 变成了 [system][tools][summary][recent turns]。从第一个改变的 Token 开始，所有缓存全部失效。
这意味着 Compaction 后的第一个请求需要重新计算全部上下文。但随后的请求会重新建立缓存，并从新的缓存中受益。
这是一个合理的权衡：你牺牲一次请求的完整计算，换来了几十轮对话的持续可用性。
行业中的对位
Pi 不是唯一意识到这个问题的团队。
Anthropic 的 Claude Code 采用了类似的“会话交接”模式，通过一个标准化的进度文件，在上下文窗口填满后在会话之间传递关键上下文。开发者社区也广泛使用“handoff”提示词模式，让新会话从旧会话的摘要和进度文件处继续工作。JetBrains 的研究团队明确提出了“context quality over context size”的论断。OpenAI 的 Codex CLI 同样有上下文管理机制。
但 Pi 的不同之处在于，它将 Compaction 设计为扩展体系中的一等公民。通过 session_before_compact 和 session_before_tree 两个钩子，开发者可以完全替换 Pi 的 Compaction 实现，用自己的模型、自己的提示词、自己的摘要策略。这意味着 Compaction 本身可以被优化、被定制、被迭代，而不是一个黑盒。
在学术界，MIT 的研究团队在 2025 年提出了 Attention Matching（arXiv:2602.16284），一种能实现 50x KV Cache 压缩的技术，在数秒内完成压缩且几乎没有质量损失。相比之下，此前最强的 Cartridges 方法需要数小时的 GPU 计算。但 Attention Matching 这类基于权重的方法需要修改模型内部，而 Pi 的 Compaction 在应用层工作，不依赖具体模型、不修改架构、不增加推理成本。对于实际部署的 Agent 系统来说，这种“纯工程”方案和“纯算法”方案不是竞争关系，而是互补的：算法层压缩 KV Cache，工程层管理上下文生命周期。
上下文窗口越大，并不越聪明
现在我们回到开头的问题。
为什么说“上下文窗口是最大的谎言”？因为整个行业都在用“更大窗口”来掩盖一个更根本的问题：LLM 的注意力机制本质上是有限的。窗口越大，噪声越多，信号密度越低。Chroma 的 Context Rot 研究已经证明，上下文从 1K 增长到 128K，模型表现持续下降，而不是保持在同一个水平线上。把窗口从 128K 扩大到 1M，并不会让模型变得更聪明，它只会让模型在更长的序列中寻找更稀疏的信号。
Pi 的 Compaction 给出了一个截然不同的答案：不要让模型在噪声中找信号，而是主动把噪声过滤掉，只留下信号。这是从“被动存储”到“主动管理”的范式转变。
当上下文窗口的竞赛在数字上不断刷新纪录时，真正决定 Agent 能力的，不是它一次能“看到”多少，而是它在看到之后，能记住和运用多少。
Compaction 不是缓存，是 Agent 的呼吸
Compaction 揭示了一个被忽视的真相：在 Agent 架构中，上下文管理不是辅助功能，而是核心基础设施。
当 Agent 从“单次问答”进化到“持续工作”，从几分钟的对话到几小时、几天的协作，上下文窗口就不再是技术规格，而是稀缺资源。谁能更高效地管理这个资源，谁就能构建更持久的 Agent。
Pi 的 Compaction 只是一个开始。随着 Agent 使用时间的延长，我们可能需要多层次的上下文管理策略：实时压缩（像 Pi 的 Compaction）、分层存储（热、温、冷上下文）、以及跨会话的长期记忆。这些能力将决定 Agent 能否真正成为“数字同事”，而不是用完即弃的对话机器人。
下一个问题不是“上下文窗口有多大”，而是“你如何决定什么该被记住”。
在信息过载的时代，遗忘不是缺陷。它是智慧。
快报