经验压缩谱：为什么 AI 记忆系统不能只停在“存得更多”

来源说明

本文基于 2026-05-01 检索到的可复核材料写成，核心来源是 2026-04-17 提交到 arXiv 的论文《Experience Compression Spectrum: Unifying Memory, Skills, and Rules in LLM Agents》。论文由 Xing Zhang、Guanghui Wang、Yanwei Cui、Wei Qiu、Ziyuan Li、Bing Zhu、Peiyang He 撰写，arXiv 页面显示版本为 2604.15877v1。本文只把该论文作为一个架构框架和研究线索分析，不把它描述成已验证的生产系统或基准冠军。

稳定 slug：2026-05-01-experience-compression-spectrum-agent-memory。

参考来源：

• arXiv abstract: Experience Compression Spectrum: Unifying Memory, Skills, and Rules in LLM Agents
• arXiv PDF: 2604.15877v1

先给结论

这篇论文最有价值的地方，不是又给 agent memory 起了一个新名字，而是把一个工程团队迟早会遇到的问题说清楚了：长期运行的 agent 不能只积累 memory，它还必须把经验压缩成更高层的技能和规则；否则存储会增长，检索会变慢，召回会被陈旧片段污染，系统最后变成“记得很多但用不好”。

论文提出的 Experience Compression Spectrum 可以粗略理解为四层：

• L0 raw trace：完整对话、工具调用、执行轨迹，压缩比 1:1。
• L1 episodic memory：一次事件或偏好的结构化摘要，约 5-20 倍压缩。
• L2 procedural skill：从多次相似经历中抽出的操作流程，约 50-500 倍压缩。
• L3 declarative rule：跨场景原则或约束，约 1000 倍以上压缩。

这个框架对 AI 记忆系统的启发是：memory、skill、rule 不应该被设计成三个互不通信的仓库。它们更像同一份经验在不同压缩层级上的副本。系统需要决定一条新经验先放在哪一层，什么时候上升成技能，什么时候再抽象成规则，什么时候因为规则失效而降级回具体 episode 重新收集证据。

我的判断是：这篇论文不适合被当作“新算法已经解决长期记忆”的证据。它没有发布完整实现，也没有给出跨层系统的实证结果。但它非常适合作为架构审查清单。凡是声称自己有 long-term memory 的 agent 系统，都应该被追问：你只是在 L1 存片段，还是有能力把重复经验变成可验证、可废弃、可回滚的 L2/L3 知识？

技术问题：为什么只做 L1 记忆会失控

大多数工程里的 agent memory 先从 L1 开始：把用户偏好、历史决策、工具报错、项目约定抽取成短文本，配上时间戳、用户 ID、项目 ID、embedding 或 BM25 索引。这个阶段很自然，因为实现成本低，也容易演示：下一轮对话能想起“用户喜欢表格”或“这个仓库用 pnpm”。

问题在长期运行后出现。L1 memory 的单位是事件，不是规律。一个 coding agent 可能在三周内保存几十条与测试、构建、部署、权限、分支策略相关的经验。单条看都合理，放在一起就会出现四类压力。

第一是检索预算压力。记忆越多，候选召回越多，rerank 成本、prompt 注入 token 和延迟都会上升。即使索引本身很快，真正进入上下文的片段仍然有限，系统必须在噪声中选择。

第二是语义重复压力。同一条工程规律会以不同表述反复出现：npm run build 要跑、部署前要检查 git status、某个 API 的参数名不能写错。重复片段会互相竞争，压低更具体、更近期的证据。

第三是冲突压力。用户偏好会变，项目约定会变，工具行为会变。L1 记忆如果只会追加，不会版本化和废弃，就会同时召回旧规则和新规则，让 agent 在关键时刻选择错误事实。

第四是泛化缺失。一个 agent 反复遇到“报告前要核对源数据”的失败，如果每次只保存“某次报表错了”，它不会自然得到“展示计算结果前必须回查来源”的规则。没有向上压缩，系统只能记住事故，不能形成工作方式。

论文用“缺失的对角线”描述这个问题：现有系统大多固定在某一个压缩层级上，memory 系统偏 L1，skill 系统偏 L2，规则系统偏 L3，少数系统跨层但仍缺少自适应层级选择。这个判断对工程落地很重要。真正的问题不是有没有记忆，而是记忆是否能沿着价值密度和泛化程度移动。

机制拆解：经验应该如何晋升和降级

把论文转成工程设计，可以得到一个三段式流程：写入、晋升、降级。

1. 写入：不是所有 trace 都值得进 memory

L0 raw trace 应该尽量完整保留在日志或会话库里，但不应该全部变成可召回 memory。写入 L1 的条件至少要包含三个信号：

• 未来可复用：这条信息会影响后续决策，而不只是当轮过程记录。
• 来源可追溯：能回到原始对话、工具结果、文件路径或外部来源。
• 作用域明确：知道它属于某个用户、项目、组织、工具还是全局行为。

这一步失败，后面的压缩都会被污染。如果系统把所有句子都抽成 memory，L1 会迅速膨胀；如果系统把来源不明的模型猜测写入 L1，后续技能和规则就会继承错误。

2. 晋升：重复出现不等于自动成为规则

从 L1 到 L2 的晋升，应该看“同类问题是否多次出现，并且同一处理流程是否稳定有效”。例如客服 agent 多次遇到导出超时，发现批量大小超过阈值时拆分请求能解决问题，这可以晋升成一个 procedural skill：识别超时、检查批量大小、拆分、重试、记录结果。

从 L2 到 L3 的晋升更严格。L3 不是操作步骤，而是原则或约束。比如“展示计算结果前必须回查源数据”适合作为 L3，因为它跨任务成立；“导出超时时把 batch size 降到 1000”更像 L2，因为它依赖具体系统。

工程上不能只靠出现次数晋升。更可靠的晋升条件应该包括：

• 多个 episode 支持同一模式。
• 至少有一部分反例检查，确认它不是偶然相关。
• 晋升后的 skill/rule 能在 held-out 任务或后续真实任务中减少失败。
• 原始 L1 证据没有被立即删除，至少保留可回溯窗口。

这也是论文里“promotion/demotion”思路最值得落地的地方。记忆系统不该只有 add、update、delete，还应该有 promote、validate、deprecate、demote 这类生命周期动作。

3. 降级：规则失效时回到 episode

许多 memory 系统只讨论“如何记住”，很少讨论“如何承认自己记错了”。但长期 agent 最危险的不是遗忘，而是旧知识继续被自信地调用。

如果一个 L3 规则在新环境里多次触发失败，系统不应该简单删除它。更好的做法是降级：把规则标记为过期或受限，重新收集 L1 evidence，并把失败上下文挂到原规则下面。这样可以区分两种情况：

• 规则本身错了，需要废弃。
• 规则仍然成立，但适用条件太宽，需要拆成更窄的 L2 skill 或带条件的 L3 约束。

这对 personalization 尤其重要。用户偏好不是永恒事实。一个用户过去喜欢详细解释，现在要求简短输出，如果系统没有 last validated time、confidence、scope 和 supersession 链，记忆越多，个性化越像过期画像。

工程判断：记忆系统要从“存储层”升级为“知识生命周期层”

这篇论文让我重新审视 memory infra 的边界。向量库、SQLite FTS、Postgres、知识图谱、Markdown 文件都只是承载方式。真正决定系统质量的是知识生命周期。

一个可用的 agent memory 系统至少应该把知识对象设计成带元数据的 artifact，而不是裸文本片段。关键字段包括：

• level：L1 episode、L2 skill、L3 rule，或更细的本地枚举。
• scope：用户、项目、组织、工具、全局。
• source_refs：原始对话、文件、工具调用、URL 或 commit。
• confidence：基于重复次数、验证结果和冲突情况更新。
• last_used_at 与 last_validated_at：区分被召回和被证明有效。
• supersedes / superseded_by：处理更新和废弃。
• failure_refs：记录该知识导致错误或不适用的案例。

没有这些字段，所谓长期记忆很容易退化成文本缓存。系统也许能召回片段，但不能回答更重要的问题：这条知识从哪来？被谁验证过？适用于谁？是否已经被新事实覆盖？如果它错了，应该删除、降级，还是限制作用域？

这里可以给一个简单架构：

• L0 存在审计日志或会话库，尽量完整，不直接注入 prompt。
• L1 memory 由抽取器产生，带来源和作用域，用于近期和个性化召回。
• L2 skill 由周期性 consolidation 产生，必须绑定验证任务或成功案例。
• L3 rule 由高置信模式压缩而来，作为约束或审查清单使用，而不是无条件指令。
• lifecycle manager 负责冲突检测、过期、晋升、降级和回滚。

这个架构的关键不是一次写出完美规则，而是让知识能移动。长期 agent 需要类似版本控制的能力：新知识可以进入 staging，经过验证后再影响行为；旧知识可以保留证据但降低权重；冲突知识可以并存但必须有作用域解释。

适用场景

经验压缩谱最适合分析三类系统。

第一类是长期个人助手。它们需要保留用户偏好、长期项目、沟通风格和历史决策。单纯 L1 会过度个性化，单纯 L3 又会失去用户细节。更合理的是：偏好先作为 L1 保存，反复稳定后变成带作用域的 L3 约束；一旦用户行为变化，规则降级回新的观察期。

第二类是 coding agent。代码任务里的可复用经验很多：构建命令、测试策略、仓库约定、常见错误、部署流程。这里 L2 skill 的价值很高，因为“怎么做”往往比“某次发生了什么”更可迁移。但 coding agent 也最容易被错误规则伤害，所以每个 L2/L3 都应该绑定具体仓库、文件路径或验证命令。

第三类是企业工作流 agent。客服、销售、运维、数据分析这类场景会积累大量操作经验和业务例外。它们需要从工单、工具调用和审批结果中抽取 L1，再把重复处理模式压缩成 L2 runbook，最后把合规、权限、审计要求上升为 L3 约束。

不太适合的场景也要说清楚。如果 agent 只是短会话问答，或者数据主要来自外部文档 RAG，经验压缩谱的收益有限。它解决的是“agent 自己经历过什么、如何从经历中形成可复用知识”，不是普通知识库检索。

失败模式

这套框架落地时最常见的失败模式有六个。

第一，过早压缩。一次偶然成功被抽成规则，后续在不相似场景里反复误用。表现是 L3 规则数量增长很快，但失败追踪为空。

第二，永不压缩。系统持续追加 L1 episode，检索结果越来越长，重复事实越来越多。表现是召回 recall 看似不错，但回答质量和延迟变差。

第三，来源断裂。L2 skill 或 L3 rule 不能追溯到原始 episode。系统出错时，人无法判断是抽取错误、泛化错误，还是源数据本身错误。

第四，作用域泄漏。某个用户、项目或客户环境下的规律被提升成全局规则，影响其他上下文。个性化记忆系统尤其容易犯这个错误。

第五，只会晋升不会降级。规则被证明不适用后仍然保留高权重，agent 用“长期记忆”抵抗新证据。

第六，指标错配。L1 用问答准确率评估，L2 用任务成功率评估，L3 没有指标，最后系统优化的是局部 benchmark，而不是长期部署效用。

可验证指标

如果要把经验压缩谱变成工程评测，我会优先看这些指标。

• Value per token：每 1000 个注入 token 带来的任务成功率或用户满意度提升。
• Promotion precision：被晋升为 L2/L3 的知识，在后续任务中实际有效的比例。
• Demotion latency：一条错误或过期知识从首次失败到降权/废弃需要多久。
• Source coverage：L2/L3 artifact 中能追溯到原始 episode 的比例。
• Conflict resolution rate：检测到冲突后，系统能给出作用域、时间或优先级解释的比例。
• Retrieval pollution：召回内容中未被最终使用、过期或无关的比例。
• Cross-level ablation：只开 L1、只开 L2、L1+L2、L1+L2+L3 时的长期任务表现差异。
• Scope leakage rate：用户级或项目级知识错误影响其他作用域的比例。

其中最关键的是 cross-level ablation。没有这个实验，就很难证明多层记忆真的比一个更大的 L1 memory store 有价值。论文提出的预测也应该这样被验证：在相同原始经验下，不同压缩层级是否带来不同迁移性、特异性、成本和失败模式。

局限分析

这篇论文的局限很明确。它是概念框架，不是完整系统；它提出了压缩层级和设计原则，但没有实现一个自适应跨层 agent，也没有给出生产部署数据。论文里的压缩比和系统映射适合作为分析起点，不应被当作所有场景里的定量定律。

另一个局限是 L3 rule 的边界仍然模糊。规则既可能是有用约束，也可能变成过度泛化的 prompt 指令。工程上更稳妥的做法，是把 L3 先当审查条件或 ranking feature，而不是让它直接覆盖具体证据。

第三个局限是安全和权限问题没有被充分展开。经验压缩会放大错误来源：一条被 prompt injection 污染的 L1 memory，如果晋升成 L3 规则，影响范围比原始片段大得多。因此跨层压缩必须和来源验证、权限隔离、人工审批或至少高风险变更审计绑定。

对 Memory Systems Notes 的后续观察

接下来值得观察的不是谁声称“有长期记忆”，而是谁开始真正实现跨层生命周期：

• 是否有 memory 到 skill 的自动晋升机制。
• 是否有 skill 到 rule 的验证流程。
• 是否能在规则失效时降级回 episode。
• 是否把 provenance、confidence、scope、validation time 作为一等字段。
• 是否提供跨层 ablation，而不只是 LongMemEval 或 LoCoMo 的单点分数。

如果没有这些机制，很多 agent memory 产品仍然停留在“更会存、更会搜”的阶段。那当然有价值，但还不是长期 agent 学习系统。长期记忆的下一步，不是无限扩大记忆库，而是让经验在正确的粒度上存在，并且允许它被验证、晋升、废弃和重新解释。