级联压缩不是长期记忆：项目知识该留在上下文里，还是合进权重里

来源说明

本文基于 2026-06-01 的每日 AI 记忆系统研究发布流程写成。今天同日 arXiv 批次尚未形成足够稳定的新材料；检索到的可复核主线来自过去一周尚未在站内单独处理的近期论文：Beyond Inference-Only Deployment 在 2026-05-23 提交，直接比较了软件开发场景里的级联上下文压缩和基于 LoRA 的夜间知识合并。它的问题很具体：长期使用 coding agent 时，用户反复纠正的项目规则、偏好和程序性知识，究竟应该继续靠上下文摘要携带，还是应该进入一个可更新的个体化模型状态。

为了避免把单篇论文扩写成摘要，本文同时使用 How LoRA Remembers? 作为参数化记忆容量的机制参照，并把 Memory-R2 作为训练时信用分配的对照材料。今天还发现了 MEMDRIFT 相关研究简报，但它与本站 2026-05-31 的工具劫持/记忆投毒文章相邻，本文只把它放入后续观察清单，不作为主线证据。

稳定 slug：2026-06-01-cascading-compaction-parametric-memory。

参考来源：

Simon Dennis, Kevin Shabahang, Hao Guo, Rivaan Patil: Beyond Inference-Only Deployment: Comparing Weight-Based Consolidation Against Cascading Compaction, arXiv:2605.24657
Ziwen Xu, Haiwen Hong, Linsong Yu, Benglei Cui, Longtao Huang, Hui Xue, Ningyu Zhang: How LoRA Remembers? A Parametric Memory Law for LLM Finetuning, arXiv:2605.30260
Sikuan Yan, Ahmed Bahloul, Ercong Nie, Susanna Schwarzmann, Riccardo Trivisonno, Volker Tresp, Yunpu Ma: Memory-R2: Fair Credit Assignment for Long-Horizon Memory-Augmented LLM Agents, arXiv:2605.21768
Mahavir Dabas, Jihyun Jeong, Ming Jin, Ruoxi Jia: Memory-Induced Tool-Drift in LLM Agents, arXiv:2605.24941

先给结论

Agent 长期记忆不能继续被简化成“把上下文压短一点”。

级联压缩的问题不是摘要写得不够漂亮，而是每压一次都会重采样一次历史。模型会保留看起来重要、语义上顺滑、最容易概括的内容；但软件开发任务里最有价值的记忆，常常是很不顺滑的：某个测试命令必须加环境变量，某个库版本不能升级，用户纠正过一次命名约定，某个失败修复路径已经被证伪。这些内容在三轮摘要后很容易从“可执行约束”退化成“项目大致背景”。

Beyond Inference-Only Deployment 的报告数字很直接：在十段真实感软件开发对话、1,146 个测试问题、三类记忆上，三轮级联压缩保留 36.8% 左右的知识；基于反思、合成和 LoRA 微调的合并流程保留 80.4% 左右。提升最大的位置不是泛泛的用户偏好，而是程序性纠错和项目事实。

这不等于“长期记忆应该全部写进权重”。权重合并会带来新的工程债：适配器版本、回滚、隐私、删除、错误写入、跨项目污染、评测成本和线上分发。更合理的判断是：长期 agent memory 需要分层。短期上下文负责当前任务，外部 memory store 负责可审计事实，结构化状态负责当次执行，用户或项目级适配器只应该承载稳定、反复验证、低敏感、可回滚的程序性知识。

技术问题：inference-only memory 的上限

现在很多 agent 产品实际是 inference-only 部署。模型权重不变，每次请求通过系统提示、历史摘要、向量检索、项目文件、memory 注入和工具结果来恢复上下文。这样做有明显好处：部署简单、每次调用可控、不需要用户级模型分叉，也更容易满足删除和审计要求。

但长期使用后，它会遇到一个保真度问题。用户并不是只需要 agent 记住一条偏好，而是需要它不断吸收项目里的细小修正：

这个仓库测试必须先启动本地服务。
这个团队不接受某种重构风格。
上次某个修复方向失败了，原因是兼容旧数据。
发布脚本有一个非显式前置条件。
用户说“以后不要再把这类问题归因于缓存”。

这些知识可以写进外部记忆，也可以在上下文压缩时保留。但如果每次长会话结束都只生成下一轮摘要，系统就会进入级联压缩。第一轮摘要丢掉细节，第二轮摘要又从第一轮摘要中抽象，第三轮继续抽象。最终得到的内容更短、更像项目介绍，也更不像可操作记忆。

这和本站 2026-05-21 的 faulty consolidation 文章相邻，但不是同一个问题。那篇文章讨论的是 LLM 持续改写文字 memory bank 时如何把有用经验写坏；本文讨论的是另一个边界：如果完全不更新模型，只靠压缩上下文和外部注入，长期项目知识的保真度也可能不够。

机制拆解

1. 级联压缩会优先牺牲低频约束

摘要模型通常按主题、显著性和连贯性取舍。它很擅长保留“项目在做什么”“用户想要什么”“当前进展到哪里”。但程序性纠错经常不是主题中心，而是未来失败的防线。

例如，用户纠正 agent：“这个仓库不要运行全量测试，先跑 unit:fast，因为集成环境会污染本地数据库。”这句话如果在当前任务里只出现一次，摘要器可能把它压成“用户偏好先运行快速测试”。再经过两次压缩，它可能变成“优先快速验证”。到下一次真正需要决策时，最关键的约束已经丢了：不是为了省时间，而是为了避免污染数据库；不是所有快速验证都可以，而是特定脚本。

论文报告的分类结果与这个直觉一致：程序性纠错和 episodic project facts 是级联压缩损失最大的部分。它们不是自然语言摘要里的主角，却是 agent 后续执行能否少踩坑的关键。

2. 权重合并把记忆从提示预算里移出去

论文对照的另一条路径是 nightly consolidation：把交互知识经过反思和合成后，使用 LoRA 在单张消费级 GPU 上合入模型适配器。它不再依赖每次请求都把旧摘要塞进 prompt，而是让模型参数本身吸收一部分长期知识。

这有两个直接收益。

第一，减少上下文预算竞争。外部 memory 注入会和当前用户请求、代码片段、工具结果、测试输出争 token。权重合并后，部分项目习惯不再需要显式注入，给当前证据留出空间。

第二，降低压缩链长度。知识不是反复从摘要中再摘要，而是周期性从交互证据中合成训练样本，再更新适配器。它仍然有合成误差，但错误路径不同：问题从“摘要是否保留了细节”变成“训练样本是否正确、适配器是否学会且可控”。

这也是为什么它不能被简单理解成“更好的摘要”。它改变的是记忆载体：从上下文文本转到参数化状态。

3. 参数化记忆也有容量和阈值

How LoRA Remembers? 对这个方向给了一个必要提醒：LoRA 可以作为参数化记忆载体，但不是无限记忆袋。论文把 LoRA 当作受控 probe，研究 exact parametric memory 的容量边界，提出 loss reduction、effective parameters 和 sequence length 之间的 power-law 关系，并指出 token 级预测概率超过某个阈值后，贪心解码下的逐字召回会出现确定性相变。

工程含义是：如果要把项目记忆写进适配器，不能只看最终任务分数。还要知道每条记忆有没有真的被学进去，哪些 token 仍低于可靠召回阈值，新增记忆是否挤掉了旧记忆，长答案和短答案的容量成本是否不同。

这给 Beyond Inference-Only Deployment 的结论加了边界：权重合并在该实验里显著优于级联压缩，但它的长期可扩展性取决于适配器容量、训练样本质量、冲突处理、遗忘机制和验证指标。把所有 raw episode 都硬塞进 LoRA，只是把 memory bloat 从向量库搬进参数空间。

4. 训练时还有信用分配问题

Memory-R2 讨论的是另一个角度：当 memory agent 通过强化学习跨多会话写入、更新、删除记忆时，不同 rollout 会产生不同中间记忆状态，导致 GRPO 一类组相对比较不再公平。它提出 LoGo-GRPO，用局部 rerollout 从相同中间记忆状态出发比较不同 memory operation，同时保留全局轨迹目标。

这和权重合并的关系在于：长期记忆不是单次写入结果，而是很多操作叠加出的未来环境。无论记忆存放在外部 store、上下文摘要，还是 LoRA 适配器里，一旦它影响后续任务，就改变了训练和评估分布。只看终局成功率，很难知道收益来自正确记忆、错误捷径、过拟合样本，还是当前测试集刚好偏向某些项目规则。

所以，长期记忆评测至少要拆开三件事：知识是否被保留，知识是否在正确场景被使用，知识使用后是否真的改善行动。

工程判断：三层记忆边界

我会把生产 agent 的项目记忆分成三层，而不是在“上下文摘要”和“权重微调”之间二选一。

第一层是可见上下文。它适合当前任务状态、最近工具结果、用户刚刚给出的约束和短期计划。它的优势是透明、即时、容易覆盖；缺点是 token 贵、压缩损失大、跨会话保真度差。

第二层是外部可审计记忆。它适合项目事实、用户确认过的偏好、历史修复、失败尝试、命令清单和来源链接。它必须有 source id、时间、作用域、置信度、失效条件和删除路径。它的优势是可查、可改、可回滚；缺点是每次使用都要选择、排序、注入，并且模型可能看见但不用。

第三层是参数化适配器。它只适合稳定、反复验证、低敏感、低冲突、可通过回归测试覆盖的程序性知识。比如固定代码风格、常用项目命令、特定框架下的修复偏好、长期协作约定。它的优势是减少注入成本，弱化级联压缩损失；缺点是难解释、难删除、难审计，也更容易跨边界污染。

这三层之间应该有晋升和降级。一次性事实先留在上下文；多次出现且有来源的事实进入外部记忆；经过回归验证的稳定程序性知识才进入适配器。反过来，用户撤销、项目迁移、测试失败或安全策略变化时，适配器里的知识必须能降级为外部记忆重新验证，甚至整体回滚。

适用场景

第一类是 coding agent。它们最容易从权重合并中受益，因为项目知识高度程序化：构建命令、测试习惯、代码风格、历史失败路径和 review 偏好经常重复出现。风险也同样明显：如果旧项目规则写进全局模型，跨仓库污染会非常严重。因此更合理的是项目级或用户-项目级 adapter，而不是全局 adapter。

第二类是企业内部流程 agent。采购、客服、运维、法务和财务都有大量重复流程，但这些流程受部门、权限、时间和政策版本约束。适配器可以承载低风险操作习惯，但政策事实仍应留在外部权威系统，并在每次执行前检索最新版本。

第三类是个人生产力 assistant。它可以学习用户长期写作、沟通、排程和代码偏好。但健康、财务、身份、家庭和工作敏感信息不适合轻易进入参数化记忆。个人偏好还会变化，过度稳定化会把旧习惯变成模型的默认行为。

第四类是研究 agent。长期研究会积累术语、引用风格、数据处理习惯和已排除假设。这里的适配器可以学习工作方式，但事实性结论必须保留来源，不能只靠模型“记得”。

第五类是本地优先 agent。它们更容易尝试 per-user adapter，因为训练和推理可在用户设备或私有环境里完成。但本地并不自动解决删除、审计和回滚问题，只是降低了外泄面。

失败模式

第一，摘要顺滑化。级联压缩把低频但关键的约束改写成流畅背景，后续 agent 读到了“感觉相关”的摘要，却失去可执行细节。

第二，程序性纠错丢失。用户纠正过的错误路径没有被保留，agent 在几天后重复同样失败。

第三，适配器过拟合。LoRA 学会了某组对话里的表面表达，而不是可迁移的项目规则，在近邻任务中反而更差。

第四，跨项目污染。一个仓库、客户或团队的规则被合入用户级适配器，影响另一个完全不同的环境。

第五，删除困难。用户删除外部 memory 后，适配器仍保留行为倾向，系统表面上“忘了”，实际仍在用。

第六，来源消失。权重里的知识无法回答“这条规则来自哪次对话、哪次测试、哪个文件、哪个用户确认”。

第七，验证错位。团队只看通用 benchmark 或平均准确率，没有构造项目级回归集，导致适配器上线后才发现某些关键流程退化。

第八，训练窗口投毒。恶意或错误输入进入 nightly consolidation，第二天变成模型默认行为。这个风险与昨天讨论的 memory poisoning 相通，但攻击面从外部 store 扩展到了 adapter 更新链路。

第九，参数容量幻觉。系统以为 LoRA 写入了所有知识，实际只有高频或短答案被稳定记住，长尾约束处于不可靠边界。

第十，评测统计误导。论文提醒 mean per-token validation cross-entropy 可能被重尾样本带偏，而 median 更贴近 LLM judge accuracy。工程上如果只看平均 loss，可能误判适配器是否真的改善记忆。

可验证指标

Cascading retention curve：同一会话经过 1、2、3、N 轮压缩后，三类知识保留率如何变化：用户偏好、程序性纠错、项目事实。

Procedural correction replay accuracy：历史纠错在新任务中是否被正确执行，而不是只在问答里被复述。

Project fact exactness：文件路径、命令、版本、环境变量、数据约束等项目事实是否逐项保持准确。

Adapter vs context ablation：仅上下文、仅外部 memory、仅 adapter、三者组合分别对任务成功率、延迟和 token 成本的影响。

Memory source traceability：模型做出某个项目决策时，系统能否追溯到原始对话、工具结果、测试输出或人工确认。

Deletion residual behavior：删除某条记忆或撤销某个偏好后，adapter 行为是否仍表现出残留倾向。

Cross-scope contamination rate：一个项目适配器对其他项目任务造成错误迁移的比例。

Adapter rollback recovery：发现写入错误后，回滚上一版 adapter 能否恢复旧任务表现。

Parametric recall threshold coverage：计划写入 adapter 的关键 token 中，有多少达到可靠召回阈值；未达阈值的记忆是否仍保留在外部 store。

Median-loss tracking：训练监控中同时记录 mean 和 median per-token cross-entropy，检查是否存在重尾样本导致的评测错觉。

Human correction recurrence：用户对同一类问题重复纠正的频率。这个指标下降，才说明长期记忆真的减少了协作摩擦。

Cost-normalized memory utility：每节省 1,000 个注入 token、每增加一次 adapter 训练、每增加一版存储，换来多少任务成功率或纠错率改善。

局限分析

第一，Beyond Inference-Only Deployment 是预印本，实验规模是十段软件开发对话和 1,146 个问题。它足以提出一个强工程假设，但不能证明所有长期 agent 都应该采用权重合并。

第二，论文里的 LoRA consolidation 是特定流程：反思、合成、微调和评估。换成更差的样本生成、更短训练、更复杂项目或更敏感数据，结果可能不同。

第三，coding agent 的程序性知识比很多领域更适合参数化。医疗、法律、金融和合规场景里的事实应优先留在可审计来源系统中，不能因为上下文压缩损失就写进权重。

第四，参数化记忆会增加治理成本。外部 memory 可以展示、编辑、删除；adapter 的行为只能通过探针和回归测试间接观察。生产系统必须把 adapter 版本、训练数据、评测报告和回滚记录纳入发布流程。

第五，本文没有把 MEMDRIFT 作为核心证据，是因为今天的主线已经足够明确，并且 MEMDRIFT 与站内上一天的工具选择安全文章相邻。它值得后续单独观察的点是：个性化记忆即使不是恶意写入，也可能在工具参数上造成不适用的行为漂移。

自审

事实可靠性：Beyond Inference-Only Deployment 的提交日期、研究问题、十段软件开发对话、1,146 个测试问题、三轮级联压缩 36.8% 保留率、LoRA consolidation 80.4% 保留率、程序性纠错和项目事实收益、mean/median cross-entropy 观察均来自 arXiv 摘要。How LoRA Remembers? 的参数化记忆法则、LoRA probe、token 阈值和 MemFT 只作为机制参照。Memory-R2 只用于说明长期记忆训练的信用分配问题。

来源完整性：核心依赖原始 arXiv 来源；二级简报只用于发现候选线索，没有作为核心事实来源。

原创性：本文主线是“inference-only 级联压缩与参数化适配器之间的记忆边界”，不是复述 2026-05-21 的 faulty textual consolidation，也不是复述 2026-05-01 的经验压缩谱。

标题党检查：标题没有声称上下文压缩无用，也没有声称 LoRA 解决长期记忆，只提出工程边界问题。

薄内容检查：正文包含来源说明、技术问题、机制拆解、工程判断、适用场景、失败模式、可验证指标、局限和自审。

猜测边界：三层记忆边界、指标和适用场景属于本文工程判断，已与论文报告事实区分。

站内重复：仓库已有经验压缩、ContextWeaver、ZipAct、faulty consolidation 和 memory injection 文章；本文新增的是级联压缩保真度与权重合并/适配器记忆的取舍，不重复近期安全投毒或工作上下文注入主题。