你让一个 AI 助手连续工作几小时，它读过的对话、文件和工具结果会越积越多。空间快满时，常见做法是暂停，把旧内容压成摘要，再让模型重新读一遍保留下来的部分。就像会议开到一半，先散会整理纪要，再把人叫回来重温重点。Spomin 想省掉这次“散会”：会话继续运行，同时直接把模型内部的旧记忆换成摘要。
这项工作目前只是作者 wgaca2 面向 Qwen 发布的实验方案。所有实现与测试信息均来自作者在 r/LocalLLaMA 的发布帖，尚无正式论文、第三方复现或独立基准。
它改的不只是聊天记录
理解 Spomin，先要认识 KV cache——模型为已经读过的 token（文本被切分后的基本单位）保存的注意力中间状态。它像模型手边的工作底稿，可以避免每生成一个新词都从头计算。
问题在于，只改外部保存的聊天记录并不够。模型实际继续使用的是 KV cache。旧对话被换成摘要后，缓存也必须同步；否则，文字记录和模型内部状态会对不上。传统压缩往往需要重新预填充，也就是让模型再次读取保留的提示词，并重建相应缓存。这会带来等待和计算开销。
Spomin 是一个路由器——位于 Agent 框架与模型运行时之间，负责转交请求、上下文和工具结果。它依赖作者维护的 llama.cpp 分支 llama.cpp-kv-surgical-fork，以便在模型运行期间直接编辑 KV cache。
边聊，边整理旧账
路由器把原始对话分块保存在外部，并分别给 system prompt（规定模型角色和规则的系统指令）、近期上下文、摘要、正在生成的内容和临时召回留出空间。一个独立 worker，也就是专门做摘要的模型进程，会提前压缩旧块。它既可在另一套硬件上并行运行，也可在共享 GPU 时利用主模型两次生成之间的空档工作。
当上下文空间不足，Spomin 会挑出符合条件的旧块，用摘要替换，并调整主缓存以及受支持的 draft cache 中的 RoPE positions。RoPE 是模型记录 token 相对位置的一种机制；内容缩短后，后续内容的位置也要随之对齐。
关键之处是：压缩后只处理新插入的摘要，不重新刷新或 prefill 已保留的后半段上下文。路由器还能识别 Agent 框架重复发送的历史，只接收新增部分；滚动维护缓存时，原生生成可以暂停并恢复。这不等于零成本，摘要 worker、摘要插入和位置调整仍然需要计算。
被压掉的原文并没有消失
摘要必然会丢细节。Spomin 的处理方式不是假装这些细节还在缓存里，而是把原文继续保存在外部。模型需要时，可以按 context ID 临时召回某段原文，用完再回到摘要，也可以搜索更早的历史。
作者给出的示例是：按平均约 10:1 压缩，40 万 source tokens 可变成 4 万 summary tokens。再加上 2 万 token 的 system prompt 和 12 万 token 的近期上下文，18 万 resident tokens——真正驻留在当前缓存里的内容——可以代表超过 50 万 token 的源材料。这是容量换算示例，不表示信息被等价保留，也不是模型原生上下文长度或稳定上限。
为什么值得关注
Spomin 击中的不是“让模型记住无限内容”，而是长时间 Agent 更现实的连续性问题。Agent 若要持续编程、研究或调用工具，频繁停下来压缩并重读上下文，会让等待和成本不断累积。直接维护正在使用的推理状态，提供了另一条工程路线：旧内容平时以摘要驻留，需要细节时再从外部取回。
作者公开的早期测试也显示，这是一场尚未算清的交换。在 Tetris 编程测试重跑中，Spomin 得到 16/16 加 11/12 项检查，对照组为 16/16 加 12/12；耗时分别为 69.8 和 149.6 分钟。但作者提醒，温度、推理模式和工具调用都会造成波动，不能把差异全部归功于缓存压缩。研究任务中，更大的摘要 worker 把受管方案从 31 分提高到 37/100，仍低于未压缩方案的 57 分。
局限与未知
- 效果取决于摘要质量。原文虽可召回，却不再始终存在于 KV cache，遗漏的关键细节可能影响后续判断。
- 现有基准只是作者所称的探索性测试。Game repair 还受到每个 prompt 三小时上限干扰，无法比较完整任务的完成速度。
- 目前只说明方案面向 Qwen，并提到支持部分 draft cache；具体兼容型号、限制和额外摘要成本尚未交代清楚。