OpenClaw 101|09|Compaction and Pruning

长对话一定会撞上上下文窗口。OpenClaw 用 compaction、pruning、memory flush 和 context engine 把历史变成可继续运行的状态。

OpenClaw 101|09|Compaction and Pruning

OpenClaw 101 是一组面向 Agent Engineering 的系统拆解文章。它不把 OpenClaw 当成单一聊天产品,而是把它当作一个长期运行的 Personal Agent OS 来观察。

这一篇讲 Compaction and Pruning。长 session 最大的问题不是保存不下历史,而是下一轮模型装不下历史。Compaction 是把过去变成可继续使用的摘要状态。

Compaction and Pruning diagram

读完本文,你应该能回答

  • compaction 和 pruning 分别解决什么问题?
  • 压缩时哪些信息必须保留,哪些应该丢弃?
  • 为什么压缩不是简单摘要?
  • 压缩失败会怎样破坏后续任务?

本篇在系列中的位置

上下文续命篇,解释长会话如何在有限窗口中保留任务连续性。OpenClaw 101 的主线是:先看控制面,再看执行面和状态边界,再进入上下文、能力系统、长期记忆、自动化、真实设备、扩展和 QA。下一篇进入 Multi-Agent and Delegation,看复杂任务如何从一个 loop 拆成多个工作流。

贯穿案例

后文会反复使用同一个任务来落地抽象机制:用户在手机上对 OpenClaw 说:“帮我看一下这个 repo 的测试为什么失败;如果需要跑命令就先做,修好后在聊天里提醒我。”

在本篇中,重点观察这个任务在 Compaction and Pruning 这一层会遇到的边界:谁接收它,谁拥有状态,谁能触发工具,谁记录结果,以及失败后从哪里恢复。

压缩保留表

环节 读者应该抓住的问题
Must keep 目标、约束、已做决策、未完成步骤、关键文件/对象引用
Can drop 重复寒暄、低价值日志、已验证且不再需要的中间输出
Rebuild 压缩后仍要能恢复下一步行动
Audit 保留压缩来源和时间,便于排错
Fallback 压缩失败时避免覆盖有效上下文

核心判断

Compaction 改写“模型将看到的历史形态”,pruning 控制“哪些重型工具结果进入当前 prompt”。

如果只看表面,很多 Agent 框架都像是“模型 + 工具 + UI”。但真正决定系统稳定性的,是这些边界如何被拆开:谁拥有状态,谁能触发副作用,谁负责恢复,谁暴露观察面,谁承担长期维护成本。

在 OpenClaw 里,Compaction and Pruning 不是一个孤立模块,而是 Gateway、Session、Context、Tools、Plugins、Memory 之间的连接点。理解这个连接点,比记住某个命令或配置项更重要。

运行路径

一条真实消息进入系统后,大致会经过这些步骤:

  • 检测 session tokens 或工具结果压力。
  • 在 compaction 前执行 memory flush,保存重要事实。
  • 把早期对话压缩为 summary artifact。
  • 保留近期消息,避免刚发生的上下文丢失。
  • 对旧工具结果做 prompt 层 pruning,而不一定删除 transcript。
  • compaction 后 retry 当前 run,避免用户感知为失败。
  • context engine 插件可以接管 assembly 和 compact 行为。

这些步骤看起来很多,但它们解决的是同一个问题:让 Agent 的行为从“模型临场发挥”变成“系统可控制、可观察、可恢复的运行过程”。

可迁移伪实现:Compaction and Pruning

下面的伪代码是机制抽象,不对应 OpenClaw 的真实 API 或文件结构。

async function maybeCompact(session) {
  if (!overBudget(session)) return session
  await flushImportantFactsToMemory(session)
  const summary = await summarizeOlderHistory(session)
  return rewritePromptView({
    summary,
    recent: keepRecentMessages(session),
    prunedTools: pruneOldToolResults(session),
  })
}

这段伪代码的重点不是函数名,而是边界:输入先被标准化,状态通过明确的 store 或 lane 管理,副作用通过 runtime 或 policy 执行,结果再回到 transcript、event stream 或 delivery target。

设计取舍

  • summary 会丢细节,所以要结合 memory flush。
  • pruning 不等于删除历史,它只是减少本轮 prompt 负担。
  • 自动 compaction 必须可观察,否则用户会以为模型“突然忘了”。

这些取舍解释了 OpenClaw 为什么不像一个最小 demo。最小 demo 追求路径短,长期系统追求边界清晰。路径短会让第一个 demo 很快跑起来;边界清晰才会让系统在多渠道、长会话、多人入口、插件扩展和自动化场景下不崩。

评估清单

评估任何 Agent 框架的 Compaction and Pruning 设计,可以看这几个问题:

  • 这个层级是否有明确 owner,还是散落在多个客户端或插件里?
  • 它是否把状态、权限、运行时副作用和展示逻辑分开?
  • 它是否能被观测、被调试、被回放?
  • 它失败时是否有恢复路径,而不是只给用户一个模型错误?
  • 它是否避免把 provider/channel/tool 的私有细节写死进 core?

如果这些问题没有答案,系统一旦从单用户 demo 走向真实使用,很快就会在上下文污染、重复副作用、权限失控、长任务丢失和调试困难中付出代价。

下一篇

下一篇继续拆 Multi-Agent and Delegation。OpenClaw 101 的主线会继续沿着 Personal Agent OS 的边界往下走:从运行时,到状态,到能力系统,再到安全、扩展和 QA。

References

  • Compaction
  • Session pruning
  • Context engine
  • Memory overview