The Compaction Cliff in Long-Running AI Agent Memory：长程 Agent 上下文压缩的安全悬崖与 Knowledge Triage

  • 关联论文：2608.22752
  • 作者：flyP
  • 更新：2026-08-26

⚠️ 数字核验备注：本文所有数字来自 arXiv abstract 公开版（v1, 2026-08-24）。如与正文 §X 主表不一致，以原文 PDF 为准。期刊信息为 CIKM 2026（DOI 10.1145/3799682.3840567），会议接收状态以 DOI 注册记录为准。

一句话结论

论文把 Claude Code 这类长跑 Agent 的"context window 满了就压缩一次"的失败模式命名为 Compaction Cliff，并提出 Knowledge Triage 框架：按"安全规则 vs. 事件日志 vs. 普通知识"等类型分流，对每类施加不同的保真压缩策略（TypeCompact / TypeDecompose / TypeRetrieve），在公开语料上把安全规则的保留率从基线的 10%（5 轮压缩后）拉回到 96%。

解决什么真问题

Agent 一旦跑长任务，就会撞到 context window 上限，常见做法是 summarize everything uniformly——把所有历史统一成更短的摘要。论文揭示了一个被忽视的事实：

安全规则（"禁给医疗建议"、"不要执行删库命令"）和事件日志（"用户 3 分钟前给了订单 ID"）在压缩器眼里只是"待压缩内容"，但前者的字面措辞决定是否还能被执行，后者被摘要掉顶多丢细节。

在 20 个生产级 Agent 配置 + Claude Code 的 /compact 提示词 + Sonnet 4.6 这个组合下，跑一轮压缩后 53% 的安全规则被破坏；跑五轮后只剩 10%。这是"悬崖"（Cliff）的来源——多轮压缩之间不是线性退化，而是断崖式崩溃。下游表现：医疗合规任务上的安全规则保留率用配对 McNemar 检验 p<10⁻⁸（N=200）显著低于生产版压缩器；零售任务通过率和航空领域任务也都显著低于分层基线。

这个问题和"长 context / agent memory / compaction"研究主线高度对齐：之前大家优化的是"压缩多少 token / 怎么还找得到"，但安全规则一旦被改写就再也不是同一条规则——这是规则可执行性层面而非检索层面的问题。

核心方法

Knowledge Triage 的核心思想一句话：别把所有行都丢进同一个压缩器。它把 Agent 的 knowledge base（提示词 + memory + 检索上下文 + 工具描述）按类型分类，每类走自己的 retention policy。具体落成三个确定性算子，覆盖 context 管理的三个基本动作：

1. TypeCompact：原位改写，按类型施加密保真

传统 compact 是 summary = LLM.summarize(blocks)，单次把所有块塞给 LLM 自由发挥。TypeCompact 的做法是：

for block in context_window:
    type = classifier.classify(block)         # rule / log / tool_desc / domain_knowledge
    if type == "rule":
        # 安全规则：保字面，允许删冗余但禁止改写条件动词（must / shall / never）
        rewritten = conservative_rewrite(block, fidelity=exact_on_modal)
    elif type == "log":
        # 事件日志：允许概括 + 计数
        rewritten = log_compress(block)
    elif type == "tool_desc":
        # 工具描述：原样保留或只截断示例
        rewritten = truncate_examples(block)
    else:
        rewritten = normal_summarize(block)
new_context = concat(rewritten)

classifier 是离线训练好的轻量分类器（abstract 说"the classifier"开源），按行级粒度判定。

2. TypeDecompose：当主题太大、整体压缩不安全时，按"在域规则"切分

如果一个主题（比如"金融交易合规"）包含 N 条规则，整体压一次会破坏规则间的引用关系。TypeDecompose 的做法是把主题切成多个 partition，先识别"哪些规则必须跨分区被引用"（in-scope safety rules），再把这些规则在每个分区里都复制一份，保证任何分区被独立处理时都不会丢失"必须先看 A 才能做 B"这种依赖。

效果：locality violations（同一规则在不同分区被解释成不同含义）从均匀划分的 93% 降到 0%。

3. TypeRetrieve：外部存储 + 规则前置

当上下文真的装不下时，把内容放到外部存储，检索时只把"在域规则"pin 在最前面，再按相关性拉取细节。这相当于把"先 recall 规则、再 recall 内容"的执行顺序硬编码到检索协议里。

效果：recall@50 = 100%，对比最强单次 LLM retriever 的 73%。

关键实验与数据

论文给出了三层证据：

层一：Compaction Cliff 的存在性（20 个生产 Agent 配置） - Claude Code /compact on Sonnet 4.6：第 1 轮后 53% 安全规则保留；第 5 轮后 10%。 - 这是"问题真实存在"的最小证据，验证了"压缩是按 token 数均匀化"的直觉。

层二：Knowledge Triage 的算子效果（5 个公开语料） - TypeCompact：在每个压缩比下都比最强单次 LLM compactor 多保留 2–4× 安全规则；5 轮累积后保留率 96%。 - TypeDecompose：locality violations 93% → 0%。 - TypeRetrieve：recall@50 73% → 100%。

层三：下游行为（3 个行为基准） - 医疗合规：配对 McNemar 检验 p<10⁻⁸（N=200），显著优于生产 Sonnet 压缩器。 - 零售任务通过率：p<0.01（N=115），显著优于 full-policy 与 hierarchical 基线。 - 航空领域：p=0.024（N 原文未明确），显著优于 hierarchical compaction。

⚠️ 数字核验备注：以上 N 与 p 值均出自 abstract，未与 PDF §X 主表交叉验证。"strongest single-shot LLM compactor"具体指哪个模型 abstract 未列；"hierarchical compaction"是不是 Llama-Index / LangChain 的某标准实现 abstract 未列。

论文同时开源了 AgentArtifactCorpus：396,934 个 Agent 配置，来自 54,628 个公开 GitHub 仓库。这意味着可以离线训练 classifier、也可以在自有 Agent 上做回归测试。

亮点与局限

亮点

  1. 问题命名价值高：Compaction Cliff 把一个"大家都在默默承受"的退化现象变成了可测量、可讨论的术语。这种命名能力在 AI 工程论文里很稀缺。
  2. 机制 + 工程双轨：type-classifier → 三算子映射 → 5 个语料回归 → 3 个行为基准 → 大规模 corpus 开源，论文同时讲了"为什么有效"和"如何复现"。
  3. 公开语料 + 公开 N + 配对统计：N=200 / 115 与 p 值都给到了，这是 4 分稿的核验标准（vs. "准确率 +5%" 无锚模式）。
  4. 可执行的 retrieval 协议：TypeRetrieve 的"规则 pin 在前"非常容易迁移到现有 RAG 框架，不需要重训模型。
  5. 跨主线合流：同时打通了 agent memory、compaction、RAG、retrieval、safety alignment 五条主线，对个人助理类 / Studio 类 Agent（OpenClaw / Cursor 类）有直接借鉴价值。

局限

  1. compaction 次数上限：实验最远跑到 5 轮；超长跑（>100 轮）下 TypeCompact 的 96% 保留率是否仍然成立，abstract 未给。
  2. classifier 训练数据偏差：AgentArtifactCorpus 来自 54K 个 GitHub 仓库，但都是公开仓库；企业内部 Agent、私域规则的分布漂移 abstract 未量化。
  3. 三个算子解耦验证：每个算子单独给指标，但没有测"三算子全开"的端到端组合效果（虽然 §3 行为基准是组合，但 abstract 没拆出组合 vs. 单算子的边际贡献）。
  4. 与 SOTA 压缩器对比的覆盖度：对比对象是"strongest single-shot LLM compactor"——具体哪一个、版本号、训练数据 abstract 没说清楚，需要查 PDF §X 主表。
  5. Safety rule 的"可执行性"定义：以"措辞是否被改写"为保留判据，没考虑"语义保持但措辞改了"的语义级破坏。
  6. 闭源模型依赖：评估用了 Sonnet 4.6，结果对闭源模型行为变化的鲁棒性 abstract 未讨论。

对工程落地的启发

  1. 马上能抄的做法：把所有"必须字面执行"的规则（safety rule / system prompt 硬约束 / schema 限制）放进一类，对它们走 conservative_rewrite 而不是 summarize；其他内容照常。这是 1 行配置 + 1 个 classifier 的改动。
  2. 检索层 pin 规则：RAG 系统里如果同时返回"规则"和"证据"，让规则永远在证据前面；这种排序硬约束比"靠 LLM 自律"靠谱得多。
  3. 多 partition 复制规则：当 prompt 太大需要切分（比如按任务、按工具）时，先识别"必须跨分区可见的规则"，再复制到每个分区。论文 0% locality violations 的结果很硬。
  4. compaction 测得起就测得起：基于 AgentArtifactCorpus 可以在自家 Agent 上回归——跑 5 轮 /compact 看 safety rule 保留率。这是工程团队可立即建立的"compaction 健康度"指标。
  5. 不要相信统一 summarizer：单 LLM summarizer 对 system prompt 与事件日志是无差别压缩的，这是结构性脆弱，不是模型能力问题。

与同方向工作的关系

  • vs. MemGPT / Letta 等分层 memory 工作：MemGPT 解决的是"用什么结构组织记忆"，本文解决的是"压缩时不破坏哪部分"，两者互补而非替代。
  • vs. RAG 经典工作：TypeRetrieve 把"规则先于内容"的硬约束写进 retrieval，比 instruction-tuned retriever 更可解释。
  • vs. Context window 扩展研究（长 context LLM）：本文承认"模型 context 更大 ≠ 安全规则保留率更高"，因为压缩仍发生，且压缩是 LLM 行为。
  • vs. Agent safety alignment 工作：传统 safety alignment 关注训练阶段；本文是 inference-time 的"安全规则可执行性"问题，给运行时多一道保险。

适合谁读

  • Agent 平台工程师：关心 compaction 策略、system prompt 持久化、工具调用规则的实现层。
  • AI Safety 工程师：关心 inference-time safety enforcement、规则可执行性的形式化方法。
  • RAG 架构师：想给现有 RAG 系统加"规则 pin 前"的硬约束。
  • CIKM / IR 方向研究者：本文被 CIKM 2026 接收，做长程检索 / memory 管理的论文可作为参考。
  • 个人助理类 Agent 团队（OpenClaw / Cursor / Devin 类）：直接对应"用户私有规则如何在长跑中不丢失"的实际痛点。

适合度自评：机制 + 工程双轨 ✅、数字可溯源（N=200/115 与 p 值）✅、反方与边界（局限性段 6 条）✅、CIKM 2026 接收状态有 DOI 锚 ✅。

附录：与 OpenClaw / 个人助理 Agent 的对应映射

把论文的三个算子翻译到个人助理 Agent 场景：

论文算子 个人助理 Agent 中的对应物 可立刻落地的代码改动
TypeCompact user rules / preferences / persona rules 与 chat log / tool output 分流压缩 compact(blocks, classifier) 替代 compact(blocks)
TypeDecompose 当 user 同时开 N 个项目，每个项目的硬约束（"项目 A 不允许写产品文档以外的内容"）跨项目可见 在每个 partition 注入"in-scope rule 副本"
TypeRetrieve 长期记忆检索时把"用户硬规则"pin 在返回内容前面 retriever 强制排序：rules_first_then_relevant_docs

这一映射的工程意义在于：OpenClaw 类系统的"用户私有规则如何在长跑中不丢失"恰好是本文的核心 case study；把 AgentArtifactCorpus 中的 396,934 个公开 Agent 配置作为回归测试集，可以快速建立"compaction 健康度"指标。

对 Compact 健康度指标的最小实现

论文没有给一个完全 ready-to-use 的代码，但结合 abstract 与三个算子的描述，可以最小化为以下步骤：

  1. 离线 step：在自家 Agent 的 memory dump 上跑一次论文开源的 classifier，得到每行的 type label（rule / log / tool_desc / knowledge）。
  2. 离线 step：固定 LLM compactor 与 prompt 模板，构造 baseline summarize(all) 与 TypeCompact(classifier-aware) 两个版本。
  3. 回归 step：跑 5 轮 compact，每轮后用精确匹配 + 规则模板（must / shall / never / 不得 / 禁止 / 一定要）抽取剩余规则字面，对比两组的安全规则保留率。
  4. 行为 step：挑 1–2 个高风险领域任务（医疗建议 / 金融合规 / 删库类），对两个版本各跑 N≥100 次，统计违规率。

第 3、4 步的指标就是论文 §3 行为基准的最小复现，可以先在内部 Agent 上拿到"我们的 Claude Code /compact 实际保留率"这条基线，再决定是否引入 Knowledge Triage。

关键术语速查

  • Compaction Cliff：长跑 Agent 中"压缩多轮后安全规则断崖式丢失"的现象，本文命名。
  • Knowledge Triage：把知识按类型分类、对每类施加不同 retention policy 的框架，本文提出。
  • TypeCompact / TypeDecompose / TypeRetrieve：Knowledge Triage 的三个算子，分别对应原位改写、跨分区复制规则、外部存储 + 规则前置检索。
  • AgentArtifactCorpus：396,934 个公开 GitHub 仓库的 Agent 配置集合，本文开源。
  • Locality violation：同一规则在不同分区被解释为不同含义的现象，本文作为 TypeDecompose 的失败判据。

工程落地与核查（Jay）

落地核查清单

  • [ ] classifier 下载方式未知：abstract 说"the classifier is open source"但未给链接；需查 PDF §X 或 GitHub README 获取 classifier 的训练数据格式、推理接口和精度报告。
  • [ ] conservative_rewrite 的 modal 动词表：TypeCompact 中"禁止改写 modal 动词"（must / shall / never / 不得 / 禁止 / 一定要）是关键保真机制；但这个动词表是否覆盖中文 / 多语言 system prompt abstract 未确认；非英语规则的保真压缩需要自行扩展。
  • [ ] TypeDecompose 的 partition 切分算法：当主题太大时，partition 的切分依据是什么？按工具 / 按时间段 / 按功能模块？论文未给；落地前需要自行设计 partition heuristic 并验证 locality violations。
  • [ ] recall@50 = 100% 的检索实现：TypeRetrieve 的"规则 pin 前 + 细节按相关性召回"需要一个两阶段检索 pipeline（rule retriever + content retriever）；abstract 未给出具体实现代码，需要查 PDF §X。
  • [ ] AgentArtifactCorpus 的使用许可：396,934 个 GitHub 仓库配置用于训练 classifier；这些配置的许可（MIT / Apache 2 / GPL / 无明确许可）未确认；用于商业产品前需确认合规性。

已在正文覆盖的内容

  • ✅ classifier 的行级分类粒度
  • ✅ conservative_rewrite(block, fidelity=exact_on_modal) 的保真级别
  • ✅ "规则必须跨分区可见"的复制策略
  • ✅ "先 recall 规则、再 recall 内容"的 retrieval 协议
  • ✅ Compact 健康度的 4 步最小实现路径

坑位与常见误区

  1. TypeCompact 对中文 system prompt 失效：论文的 conservative_rewrite 针对英文 modal 动词（must / shall / never）设计；如果 system prompt 是中文，"必须 / 禁止 / 不得 / 绝对不能"等词的保真需要单独验证；建议先在中文 system prompt 上跑一遍保留率测试。
  2. compaction 轮次超过 5 轮后 TypeCompact 退化：论文最远测到 5 轮；实际长跑 Agent 可能跑 20–100 轮；需要验证 96% 保留率在更多轮次下是否维持；如果退化，需在每 N 轮后加一次"安全规则全量刷新"。
  3. classifier 的域偏移：AgentArtifactCorpus 全是公开 GitHub 仓库；如果自家 Agent 的 rule 写法和公开配置不同（更口语化 / 更结构化 / 更分散），classifier 的分类准确率可能低于论文报告值；建议用自家 memory dump 做一次 few-shot validation。
  4. TypeRetrieve 的 pin 机制在 token 预算紧张时被截断：如果上下文非常满（只剩 100 token），即使规则被 pin 在最前面也可能被截断；需要在 pipeline 里加一个"hard floor"——安全规则永远不被截断，即使牺牲其他内容。

立刻可测的 5 轮 Compact 健康度

不需要论文的 classifier，不需要 LongWoF-Bench，以下步骤可以直接在任意 Agent 上做：

  1. 取出自家 Agent 当前的 system prompt + memory dump。
  2. 跑一轮 LLM summarize（用自己现有的 compactor prompt）。
  3. 用正则 grep -E "must|shall|never|不得|禁止|必须|一定不能" 提取压缩前后的 safety rule 字面。
  4. 对比保留率：保留率 < 80% → 说明 compaction 正在悄悄破坏安全规则；保留率 < 50% → 说明 Compaction Cliff 已经在自家 Agent 上发生。
  5. 把 system prompt 里的 safety rule 分离出来单独处理（不发到 summarizer），其余内容正常压缩——这是 0 classifier 的 TypeCompact 近似。

三分钟得到第一条基线。