1. 引言：当 AI 的“工作台”被塞满

想象一下，你和一位极其聪明的助手合作处理一个复杂的项目。最初几轮沟通顺畅无比，但随着讨论深入、文件越传越多，助手突然变得迟钝——他开始忘记最开始讨论的需求，回答开始出错。不是你变笨了，而是你给他的“工作台”（Context Window）被堆满了，最早的材料被挤掉了。

在 AI Agent 系统中，这个问题被放大了无数倍。一个完整的 Agent 运行，其上下文承载着系统提示词、对话历史、工具调用结果、读取的文件内容等一切信息。当总 Token 数超过模型上下文窗口上限时，API 直接返回 400 错误，会话彻底卡死。

OpenClaw 如何应对这一核心约束？它的答案是一套组合拳：自动压缩（Compaction）、会话剪除（Pruning）与记忆持久化（Memory）。

2. 为什么上下文会溢出？—— 先看清“箱子”里装了什么

在拆解解决方案之前，必须先理解“箱子”为什么会被塞满。

2.1 Context Window 里到底装了些什么

OpenClaw 每轮请求都会把以下内容全部拼在一起发送给模型：

• 系统提示：包含AGENTS.md、SOUL.md、IDENTITY.md等引导文件，定义了 Agent 的人格、规则和工具列表
• 对话历史：多轮对话越长，占用的 Token 越多
• 工具调用与结果：exec、read、web_search等工具的输入和输出，尤其是日志、表格等返回内容
• 读取的文件内容：用户通过工作区引用的文件内容
• 附件转写：图片、音频等媒体的文本转写结果

典型触发场景：

• 上传或粘贴大代码、长文本文件
• 连续对话超过 20 轮且未清理
• 工具返回超长结果（如目录列表、日志）
• 一次性读取多个大文件

2.2 溢出后的表现

当上下文超出模型最大限制时：

• API 返回明确的错误码，如request_too_large、context length exceeded、input token count exceeds the maximum等
• OpenClaw 日志中会出现400 错误，会话彻底卡死，后续消息无法继续

3. 方案一：自动压缩（Compaction）—— 主动给上下文“瘦身”

压缩是 OpenClaw 应对上下文溢出的核心机制。它是一种有损压缩——用摘要替代早期对话，保留核心信息、释放空间。

3.1 工作原理

当对话接近上下文限制时，OpenClaw 会自动触发压缩：

1. 早期的对话轮次被摘要成一条精简条目
2. 摘要会保存在会话转录中（.jsonl文件）
3. 最近的消息保持完整，确保即时任务不受影响

OpenClaw 在处理压缩时，会确保工具调用与结果的配对不被打断。如果拆分点落在工具块内部，会自动移动边界让配对保持在一起。完整的对话历史仍保留在磁盘上——压缩只改变模型在下一轮看到的内容，不删除任何原始数据。

3.2 自动压缩与手动压缩

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

• 会话接近上下文限制时
• 模型返回上下文溢出错误时（此时 OpenClaw 会压缩并重试）

在 Gateway 日志中，你会看到embedded run auto-compaction start / complete，或详细模式中的🧹 Auto-compaction complete。

手动压缩通过/compact命令触发，适合需要主动释放空间的场景。还可以带聚焦指令，例如：

/compact Focus on API design and configuration

这让摘要更精准地保留你关心的信息。

3.3 压缩配置优化

OpenClaw 提供了丰富的配置参数，以下是一套推荐的“最优配置”：

{"agents":{"defaults":{"compaction":{"mode":"safeguard","timeoutSeconds":900,"reserveTokensFloor":24000,"model":"aliyun-bailian/qwen-turbo"}}}}

关键参数说明：

• mode:safeguard：分块摘要模式，长对话更稳定，相比default单次摘要更可靠
• reserveTokensFloor: 24000：为新消息和模型输出预留足够空间
• model：可以用轻量模型做摘要，节省主模型成本
• timeoutSeconds：防止压缩过程卡死

3.4 压缩 vs 剪除：两种不同的“瘦身”策略

剪除是一种更轻量的补充方式，可以在不摘要的情况下修剪单个工具的输出。当压缩过于频繁时，可以考虑启用剪除。

4. 方案二：会话剪除（Session Pruning）—— 轻量级“清理”

剪除专注于一个更细粒度的目标：修剪旧的工具结果。

工具调用（如exec执行命令、read读取文件）的返回内容往往非常庞大——一个目录列表、一段日志、一个 JSON 输出。这些信息在历史中堆叠起来，会迅速吞噬上下文空间。

剪除按请求在内存中处理，不会保存到磁盘上的会话转录中。这意味着它只对当前请求生效，不会影响会话的长期记录。

推荐做法：如果压缩过于频繁，说明工具输出可能较大，尝试启用剪除作为补充。

5. 方案三：记忆持久化（Memory）—— 让关键信息“跨会话”存活

压缩和剪除解决的是当前会话内的上下文管理问题。但如果会话过于庞大，或者用户希望跨会话保留关键信息，就需要依赖记忆持久化。

5.1 工作区记忆文件

OpenClaw 支持通过memory/目录和MEMORY.md文件实现持久化。用户可以将关键信息写入这些文件：

把今天的架构决策保存到 memory/ 目录

新会话启动时，会自动加载这些记忆文件（默认前 200 行），从而实现跨会话的信息延续。这与长期记忆的存储与检索机制一脉相承。

5.2 长期记忆插件（Honcho / 阿里云百炼）

对于更高级的跨会话记忆需求，OpenClaw 支持通过插件扩展记忆能力。

以阿里云百炼记忆插件为例，它通过两个生命周期钩子工作：

• before_agent_start：对话开始前自动检索相关记忆，注入上下文
• agent_end：对话结束后自动提取关键信息并存储

效果对比：用户说“我在做一个 Python 项目，用的是 FastAPI 框架”。下一次对话时，Agent 能检索到这一信息，回答“您上次提到正在做 FastAPI 项目……”

Honcho 则提供了更丰富的功能：跨会话记忆、用户建模、语义搜索、多智能体感知等。Honcho 与内置记忆可以协同工作，各有侧重。

6. 一张图看懂 OpenClaw 的上下文管理生态

7. 日常预防：永不超限的 6 个习惯

根据社区实践，以下习惯可以从源头防止上下文溢出：

1. 大文件必用文件引用，不粘贴：将文件放入 workspace，让 AI 按需读取。文件内容不常驻上下文，用时读取、读完释放
2. 常看/status监控当前 Token 用量：及早发现危险信号
3. 长对话每 20 轮主动/compact：主动瘦身而非被动等待溢出
4. 重要信息即时存入memory/：跨会话保存，新会话自动加载
5. 优先选大窗口模型：如qwen3.5-plus（100 万 Token）或qwen-long（1000 万 Token）
6. 保持自动 Compaction 开启（默认开启）

8. 结语

Context Window 是 AI Agent 最核心的硬约束之一。OpenClaw 的解决思路不是“对抗”这个约束，而是通过一套精细的工程组合来在约束内最大化有效信息的密度：

• Compaction是主力——用摘要替代早期历史，释放空间
• Pruning是轻骑兵——精准修剪工具输出，不伤及对话结构
• Memory是长期储备——让关键信息跨会话存活，减少重复加载

理解这套机制，不仅是理解 OpenClaw 工程智慧的关键，也是构建任何规模化 AI Agent 系统的必修课。