只删不改，让AI在长程对话中不偏航

1问题

想象你正在让一个AI助手帮你写一个完整的操作系统内核驱动程序。这不像让它写个“打印Hello World”那样简单，而是需要它记住几百万字的技术细节、之前的报错记录和你的一步步指令。现在的模型就像有个容量固定的笔记本，写满了就得擦掉旧的才能写新的。如果它把重要的代码片段或逻辑推理记混了、漏掉了，或者为了省地方瞎编乱造，整个项目就会在一千行之后彻底崩溃。更糟糕的是，每当你试图保留更多历史以维持连贯性时，计算成本和等待时间就会呈指数级上升，直到这笔账算不过来为止。

2翻译

这个故事里的主角叫 CliffCompaction（悬崖压缩）。它解决的核心困境是：当对话历史长得超过模型的“短期记忆”极限时，怎么把旧内容塞进新空间，既不丢失关键信息，又不产生幻觉？

让我们回到那个写内核驱动器的场景。传统方法是怎么做的？它们通常使用一种叫做“摘要”或“重写”的策略。这就好比你在整理笔记时，不仅要把重点挑出来，还要用自己的话重新组织一遍语言。这种方法有两个致命伤：一是会丢失细节（比如具体的变量名、错误代码），二是容易引入偏差（你的“改写”可能偏离了原意）。而且，如果每一轮都基于上一轮的摘要再改写，误差就会像滚雪球一样越滚越大，这就是所谓的“上下文漂移”。最终，AI开始说一些听起来合理但完全错误的废话。

CliffCompaction 的转折点在于它发现了一个反直觉的事实：不要改写。作者团队观察到，在处理这种超长编程任务时，原始文本的忠实度比流畅度重要得多。于是，他们设计了一套机制，只在原有内容进行截断或丢弃，绝不进行任何重述或生成式压缩。这就好比你不是在整理笔记，而是在剪胶片——只剪掉废片，保留原始底片。

具体怎么做呢？1. 单向操作：每一轮压缩只针对“原始输入”和“当前状态”，而不是对“之前的压缩结果”进行二次加工。一旦某轮压缩完成，旧的状态就彻底扔掉，不会叠加。2. 忠实截断：它不尝试概括“用户说了什么意图”，而是判断哪些部分对于后续推理是“必须保留的硬约束”（如代码片段、特定错误日志），哪些是可以丢弃的“噪音”（如闲聊、已解决的无关错误）。3. 成本可控：通过这种简单的裁剪，大幅减少了需要发送给模型处理的 token 数量。

数据来看，这种做法有多强？

• 在 Terminal-Bench（一个测试AI命令行操作能力的基准）上，CliffCompaction 在保持性能不变甚至提升的情况下，将成本降低了多达 50%。
• 在 KernelBench（测试编写和优化CUDA内核的能力）上，经过200步后，它能达到 2.23倍 的速度提升；400步后达到 3.58倍 速度提升，超越了那些专门为此训练的专用算法。
• 在并行测试时间缩放（即花费更多算力换取更好结果）的场景下，使用 ClifCompaction 的小模型 Kimi K2.6 能够以更低的成本匹敌甚至超越最顶级的闭源大模型 Opus 4.7 和 GPT-5.3 Codex。

这里有一个反直觉的发现：通常人们认为“压缩”意味着“提炼精华”，但在超长期编程代理中，“提炼”反而有害。保持原始内容的绝对保真，即使这意味着保留了一些看起来冗余的字符，也比冒着失真风险去追求简洁要好得多。这篇论文没有复杂的数学推导，它的洞见纯粹来自对工程实践中“误差累积”现象的敏锐捕捉。

3核心概念

为了让外行听懂，我们拆解三个不可少的组件：

1. CliffCompaction（悬崖压缩）：这不是一个训练好的小模型，而是一种策略/协议。它不是一个独立的AI模块，而是嵌入在代理循环中的一套规则。你可以把它想象成一个严格的图书管理员，他的工作不是重新编写书籍，而是决定哪本书该从书架上移除，以便腾出空间给新书。他的原则是“只移走，不修改”。

2. 非递归压缩（Non-recursive Compaction）：这是该方法区别于所有前人工作的关键设计选择。大多数压缩方法是链式的：Step 1 压缩历史 -> Step 2 用压缩后的历史 + 新内容再压缩 -> Step 3 继续...。这意味着误差会在 Step 1, 2, 3... 中层层传递。CliffCompaction 打破了这个链条。它规定：每一轮压缩都是独立发生的，且只作用于最初的原始交互流。前一轮压缩产生的输出，在这一轮会被当作普通的新增内容对待，而不会被再次作为被压缩的对象。这样就切断了误差积累的路径。

3. 忠实性截断（Faithful Truncation）：这是一种特定的筛选机制。它不评估信息的“语义重要性”（因为这很难量化且易错），而是基于结构性和功能性的硬性指标。例如，任何包含错误堆栈跟踪、未闭合的代码块、或者显式引用的变量定义，都被标记为“高优先级保留”。而那些重复的问候语、已经确认无效的调试路径、或者与当前焦点无关的背景描述，则被直接丢弃。这个过程是确定性的，不包含任何概率性的生成过程。

4洞见

在长程任务中，保真度优于压缩率。试图通过生成式手段优化上下文只会加速遗忘和扭曲，而机械地截断原始数据却能维持长期的稳定性。这句话脱离了这篇论文依然成立：在很多涉及长期记忆的系统设计中，减少信息的变形比精简信息本身更重要。

5博导审稿

来，坐。我看完这篇了。

首先，选题眼光不错。现在大家都在卷 Agent 的长度，谁能让模型活得久、记得牢，谁就有优势。这个问题是真的，痛点也很痛。你们没去搞那些花哨的重头训练，而是从工程角度切入，这点我很欣赏。

但是，我有几个疑问你得想清楚。第一，预设隐忧。你们假设“原始内容”总是比“摘要”更有价值。这在编程领域可能成立，因为代码是精确的语言。但如果扩展到科学发现或多学科推理呢？有时候，人类的直觉总结（虽然可能有误）比逐字记录的实验日志更能指引方向。你们的策略是否过于依赖“结构化数据”这一前提？这一点文中讨论不足。第二，实验诚意。你们提到了 KernelBench 上的巨大提升，但这主要靠的是节省出的资源去做更多的探索步骤（test-time scaling）。也就是说，你们是用更多的计算量（虽然单次便宜了，但跑的次数多了）换来了成绩。这跟纯算法效率的提升要区分开。你需要明确告诉读者，这 50% 的成本节约，有多少是来自算法本身的精简，有多少是来自你能跑更多轮的奖励？第三，写作功力。整体逻辑清晰，但关于“为什么放弃改写”的论证略显单薄。如果能加一个对比实验，展示“改写式压缩”在极端长度下的具体失败案例（比如某个变量名被改错导致运行失败），说服力会更强。

综上，这是一个 strong accept。虽然理论深度一般，但工程价值极高，且解决了实际部署中的一个大麻烦。只要补充好关于计算预算权衡的解释，这就是一篇好文章。

6启发

这意味着你可以 ___

1. 迁移：如果你的系统也在处理超长文档或连续日志（比如客服对话记录、法律案卷分析），别急着上向量数据库做语义搜索试试。先试试这种“只删不改”的滑动窗口截断策略，看看能不能先稳住基本盘，防止噪声污染核心上下文。2. 混搭：把你的 RAG（检索增强生成）系统中的“重排序”环节借鉴过来。既然 CliffCompaction 证明了保留原文片段比生成摘要好，那你可以在检索到相关片段后，直接拼接原文，而不是让 LLM 去总结片段含义。这样可以构建一个“原文优先”的混合架构。3. 反转：通常我们认为“智能”体现在能归纳总结。但在这里，我们可以反向思考：在某些高精度任务中，降低模型的“创造力”（即减少改写和生成），反而能提升其“可靠性”。在你的工作中，有没有哪个环节是因为 AI “自作聪明”地解释了数据而导致出错的？那里也许就需要一个 CliffCompaction 式的刹车。