面经策

当对话历史实在太长、裁剪也不够用时，还有什么办法？什么是 Compaction？OpenClaw 的 Compaction 策略是怎样的？ ​

  • 标签：AI、OpenClaw、大模型应用开发、AI应用开发、Agent开发

🏛 业务架构师 ​

裁剪也不够用时，终极手段是Compaction（上下文整体压缩）：把全部对话历史用 LLM 重写成一份高密度摘要，替代原始历史继续对话——用"有损压缩"换取继续工作的能力。

OpenClaw 的 Compaction 策略要点：

  1. 触发条件：上下文逼近窗口阈值（如 80%）自动触发，或 Agent 主动请求（判断接下来还需要长任务空间）；
  2. 分级保留：压缩不是一刀切——System Prompt、业务红线指令、用户明确确认的关键数据（订单号、决策结论）原样保留；过程性讨论压缩为纪要；寒暄与冗余丢弃；
  3. 结构化纪要：摘要不是散文，而是固定结构（任务目标、已完成的步骤与结论、待办事项、关键数据、用户偏好），保证压缩后 Agent 仍能无缝续跑；
  4. 原始留档：压缩前的完整历史归档持久化，审计可回溯，必要时可"解压"恢复。

除 Compaction 外的补充手段：重要状态外置到结构化存储（任务清单、工单状态），Agent 靠"查状态"而非"记上下文"工作——外置状态几乎不占窗口，是长任务的更优解。

业务视角：Compaction 是"内存换磁盘"的经典权衡在 LLM 时代的翻版。要向业务方明确：压缩后细节可能有损，涉及合规承诺的内容必须结构化外置而不能依赖摘要——这是产品设计里的风险声明点。

🏗 系统架构师 ​

裁剪不够用时的终极手段是 Compaction（上下文压缩整理）——不是删消息，而是把整个会话状态重构为高密度摘要快照。

Compaction 的定义：将"完整对话历史 + 已有摘要"通过 LLM 重组为一份结构化状态文档，替换原始历史作为新的上下文基座。类比：把日志文件归档为数据库记录——信息换形态不换本质。

OpenClaw 的 Compaction 策略要点：

  • 触发条件：窗口水位（如 85%）触发，留出安全余量——不能等满了才压（压缩本身也要消耗一次大上下文调用）；
  • 保留优先级：不可压缩项（System Prompt、当前任务目标、活跃的工具定义）全保；高价值项（用户明确要求、已确认的事实与决策、错误与教训、未完成的待办）结构化提取；低价值项（寒暄、已完成的中间过程、被后续修正的旧结论）丢弃或降级；
  • 输出形态：结构化快照（任务状态 / 关键事实 / 决策记录 / 待办 / 资源引用），而不是流水账摘要——结构化让模型后续检索定位更准；
  • 原史外置：压缩前的完整历史落盘归档，模型可通过工具回查（可逆性保障），压缩是有损但可回溯的；
  • 一致性校验：压缩后抽查关键事实是否保留，丢关键信息比爆窗更糟。

进一步手段：多 Agent 分治（子 Agent 各自持上下文，父级只收结论）、状态外置到数据库让 Agent 无状态化。核心思想：上下文是易失性工作内存，重要状态必须尽早物化到持久层。

💻 全栈开发专家 ​

裁剪不够用时的进阶手段依次是：记忆外置 → Compaction（摘要重组）→ 会话切分。

Compaction 是什么：把对话历史整体（或旧区段）用 LLM 压缩成结构化摘要，替换原文继续对话。与简单截断的区别：截断丢信息，Compaction 转存信息。

OpenClaw 风格的 Compaction 策略（我在自研系统里也用类似的）：

  1. 触发条件：上下文占用超过窗口 70%，或单轮工具结果异常大；预测「下一轮可能溢出」提前触发；
  2. 分区压缩：System Prompt 和最近 2 轮永不压缩；中间区段（旧对话+工具结果）送 LLM 压缩；
  3. 结构化摘要模板（关键，不是一段流水账）：
text
## 任务目标：<原文保留>
## 已确认事实：- xxx（来自文件A） - yyy（用户第3轮确认）
## 已完成步骤：1. ... 2. ...
## 未决问题：...
## 用户偏好：中文回复 / 简洁风格
  1. 增量压缩：二次压缩时把「旧摘要+新增对话」再压缩，控制摘要长度上限（如 2k token）；
  2. 保底落盘：压缩前的完整历史写归档存储，用户追问细节时可检索回来。

验证方法：压缩前后各跑一次评测任务集，观察任务完成率变化。经验数字：好的结构化摘要能保住 95% 的任务连续性，纯一段式摘要只有 70% 左右——模板化产出是关键，别让压缩模型自由发挥。