当对话太长、裁剪也不够用时：Compaction 深度解析与 OpenClaw 的实战策略

1. 引言：当“工作台”被彻底塞满

在上一篇文章中，我们讨论了工具返回超大结果带来的挑战以及应对策略。但有一个更棘手的问题：当整个对话历史本身已经长得无法裁剪时，该怎么办？

想象一个场景：你和 Agent 进行了一个长达 50 轮的复杂项目讨论，中间穿插了大量文件读取、代码搜索、命令执行。即使你启用了会话剪除（Pruning），每次只保留最近几轮的工具输出，对话的“骨架”——用户和助手的交替消息——本身已经累积到了一个可怕的 Token 数。在某个时刻，你发送一条新消息，模型直接返回context length exceeded。

裁剪（Pruning）只是“清理桌面”，而压缩（Compaction）是“把旧文件归档到仓库”。

2. 什么是 Compaction？

2.1 核心定义

Compaction（压缩）是将较早的对话轮次摘要成一条精简条目，从而释放上下文窗口空间的过程。

它的核心思想与人类处理信息的方式一致：对于过去发生的事情，你不需要记住每一个细节，只需要记住“发生了什么”和“关键结论”。Compaction 正是为 Agent 提供这种“记笔记”的能力——把早期对话浓缩成一段摘要，让模型在后续推理中仍然知道“之前讨论过什么”，但不再被原始的长文本占用空间。

关键区别：Pruning（剪除）只针对工具输出，在内存中临时处理；Compaction 针对整个对话，会持久化保存摘要到会话转录中。

2.2 工作原理

当对话接近上下文限制时，Compaction 会介入：

1. 识别压缩边界：系统扫描对话历史，确定从哪里开始压缩
2. 生成摘要：用 LLM 将较早的对话轮次提炼为一段精简文本
3. 保留尾部：最近的消息保持完整，确保当前任务不受影响
4. 持久化存储：摘要作为compaction条目写入会话转录（.jsonl 文件）

完整对话历史仍保留在磁盘上——压缩只改变模型在下一轮“看到”的内容，不删除任何原始数据。

2.3 一个精妙的细节：工具调用的配对保护

Compaction 有一个容易被忽视但至关重要的设计：它会确保工具调用（assistant tool call）与对应的工具结果（toolResult）永远不被拆散。

如果拆分点恰好落在工具调用和结果之间，OpenClaw 会自动移动边界，让这对条目保持在一起。这意味着即使在压缩后，工具调用的上下文完整性依然得到保证——模型不会看到一个“调用了工具但没有结果”或者“有结果但没有对应调用”的碎片化历史。

3. OpenClaw 的 Compaction 策略

3.1 触发机制：自动 + 手动

OpenClaw 支持两种触发方式：

自动压缩（默认开启）会在两种情况下触发：

• 阈值维护：当已用 Token > 上下文窗口 - reserveTokens时，在一个成功轮次之后触发
• 溢出恢复：当模型返回上下文溢出错误时，自动压缩并重试

OpenClaw 能够识别多种溢出错误模式：

• request_too_large
• context length exceeded
• input exceeds the maximum number of tokens
• ollama error: context length exceeded

手动压缩通过/compact命令触发。还可以带聚焦指令：

/compact Focus on API design and configuration

这让摘要更精准地保留你关心的信息。如果设置了keepRecentTokens，手动压缩会保留最近尾部；否则是“硬检查点”——从新摘要继续，尾部会被截断。

3.2 核心配置参数

以下配置在openclaw.json的agents.defaults.compaction下设定：

3.3 “记忆刷写”：压缩前的关键一步

这是 OpenClaw 压缩机制中最具前瞻性的设计。在自动压缩发生之前，OpenClaw 可以运行一次静默的“记忆刷写”轮次，将当前对话中的关键信息写入memory/YYYY-MM-DD.md等持久化文件。

配置如下：

"memoryFlush":{"enabled":true,"model":"ollama/qwen3:8b","softThresholdTokens":4000}

这解决了压缩的核心风险：摘要可能丢失你关心的细节。通过刷写，关键事实被保存到长期记忆中，即使压缩把原始对话“归档”了，这些信息依然可以在后续会话中被检索到。

3.4 “后继转录”：压缩后的文件管理

开启truncateAfterCompaction后，OpenClaw 不会就地重写现有转录，而是创建一个新的“后继转录”（后续 JSONL），包含压缩摘要 + 保留状态 + 未摘要尾部。之前的转录作为归档检查点保留。

好处：

• 压缩不会破坏原始记录
• 压缩前的检查点可用于调试
• 重复的冗长用户轮次（如渠道重试风暴）会被丢弃，避免污染新转录

3.5 可插拔压缩提供商

插件可以通过registerCompactionProvider()注册自定义压缩提供商。当设置provider时，摘要生成被委托给该提供商，而不是内置的summarizeInStages流水线。

设置provider会自动强制mode: "safeguard"。如果提供商失败，OpenClaw 会自动回退到内置 LLM 摘要。

4. Compaction 的最新前沿

关于上下文压缩，2026 年的学术界和工业界有一些值得关注的进展。

4.1 PAACE：计划感知的自动化上下文工程

2025 年 12 月发布的 PAACE 框架提出了一个核心观点：上下文压缩应该“感知计划”——根据任务的计划结构来决定何时、如何压缩。

PAACE 包含两个核心组件：

• PAACE-Syn：大规模合成 Agent 工作流生成器，带有逐步骤压缩监督
• PAACE-FT：从成功教师演示中训练的轻量级压缩器

在 AppWorld、OfficeBench 等多任务基准测试中，PAACE 在提升准确率的同时降低了峰值上下文和累积依赖。

4.2 Focus Agent：自主压缩的智能体

卡内基梅隆大学等机构提出的 Focus Agent 采用了一种更激进的思路：让 Agent 自主决定何时压缩。

• 引入start_focus和complete_focus两个工具
• Agent 在探索完成后自主调用complete_focus，生成摘要并删除原始探索日志
• 上下文呈现“锯齿形”：增长 → 压缩 → 再增长

在 SWE-bench Lite 测试中，Focus 实现了 22.7% 的 Token 减少（14.9M → 11.5M），同时保持与 Baseline 相同的准确率（3/5，60%）。最高单实例节约达 57%。

4.3 ACCP：标准化压缩协议

IETF 的互联网草案 ACCP（Agent Context Compression Protocol）提出了一种跨 Agent 通信的标准化压缩协议。

核心设计包括：

• 三级状态模型：Hot（上下文中）→ Warm（压缩摘要）→ Cold（外部存储）
• 检查点机制：任务完成或 Hot 状态超过 400 Token 时触发压缩
• 增量编码：检查点后只传输变更的增量

目标是实现 60-90% 的 Token 消耗降低。

5. 一张图看懂 Compaction 的完整流程

6. 日常实践建议

基于 OpenClaw 的官方文档和社区经验：

1. 保持自动压缩默认开启——它是最核心的防线
2. 压缩太频繁？尝试启用会话剪除（Pruning）——工具输出可能是元凶
3. 压缩后上下文感觉“过时”？使用/compact Focus on <topic>引导摘要方向，或启用记忆刷写
4. 需要彻底清理？/new启动全新会话，跳过压缩
5. 用轻量模型做摘要：设置agents.defaults.compaction.model为本地小模型（如ollama/qwen3:8b），节省主模型成本
6. 关注/status：查看🧹 Compactions: <count>了解压缩频率

7. 结语

Compaction 是 Agent 应对“超长对话”的最后一道防线。当剪除（Pruning）不足以解决上下文膨胀时，Compaction 通过摘要早期对话释放空间，让 Agent 能够持续工作。

OpenClaw 的 Compaction 策略体现了几个重要的工程智慧：

• 配对保护：确保工具调用的完整性
• 记忆刷写：压缩前把关键信息存入长期记忆
• 后继转录：不破坏原始历史，建立检查点
• 可插拔设计：允许自定义压缩提供商

这三个机制——Pruning（剪除）、Compaction（压缩）和Memory（记忆）——共同构成了 OpenClaw 上下文管理生态的完整拼图。理解它们各自的作用和边界，是构建可靠、长生命周期的 AI Agent 系统的必修课。