6 OpenClaw如何处理上下文压缩
系列进度
龙虾OpenClaw · 第 7 / 7 篇
很多人第一次理解 OpenClaw 的时候，会把“记忆”和“上下文”混在一起：既然它是长期运行的个人 AI 助手，是不是每次都把过去所有对话、所有工具调用、所有文件结果全部塞回模型？
答案是否定的。
真正可用的 Agent 系统，不能一直背着完整历史往前跑。OpenClaw 处理上下文压缩的核心，不是简单把旧聊天记录砍掉，而是把长历史压缩成“可继续执行的短状态”。
查看大图你可以把它理解成一句话：
长历史不是全部丢掉，而是沉淀成任务状态；最近消息保留原文，保证细节不丢。
这就是 OpenClaw 这类个人 Agent 能够长期工作的关键。它既要省 token、降成本、提速度，又不能在压缩后忘记用户目标、当前进度和下一步动作。
查看大图1. 为什么不能一直保留完整 history
OpenClaw 的每次任务，都会产生一串历史信息：
- 用户发来的消息。
- Agent 的回复。
- 工具调用参数。
- 工具返回结果。
- 读到的文件内容。
- 执行过的命令。
- 失败过的尝试。
- 用户临时补充的约束。
这些内容都会先进入 history。
问题是，history 会不断变长。如果每次模型调用都把完整历史塞进去，会遇到三个问题。
第一，token 会超限。模型上下文窗口再大，也不适合无限堆历史。
第二，推理会变慢。旧内容越多，模型每次都要重新消化一遍，响应速度和成本都会变差。
第三，注意力会被干扰。很多旧消息已经不重要了，但它们还占着上下文位置，反而会冲淡当前任务。
所以，长期运行的 OpenClaw 不能只依赖“完整对话回放”。它需要一种机制，把旧历史整理成更短、更稳定、更适合继续执行的状态。
2. 压缩后的内容不是普通摘要
这里最容易误解。
普通摘要可能写成：
用户讨论了 OpenClaw 的部署、域名绑定、SSH 安全设置和上下文压缩。
这句话看起来没错，但对 Agent 继续干活帮助很小。因为它没有回答几个关键问题：
- 用户最终目标是什么？
- 已经完成了哪些步骤？
- 哪一步失败过？
- 现在阻塞在哪里？
- 哪些事情不能做？
- 下一步应该先做什么？
OpenClaw 更需要的是状态摘要，而不是文章摘要。
查看大图例如，一个更有用的压缩结果应该像这样：
用户目标：部署 OpenClaw，并把域名绑定到新加坡服务器。
已完成：
- Docker 已安装。
- OpenClaw 镜像已拉取。
- 端口 18789 已暴露。
当前问题：
- 域名 ai-jupyter.com 需要解析到 43.160.250.49。
- 还需要检查 Nginx 和 HTTPS 配置。
重要约束：
- 用户使用 key-only ssh。
- 不要开启密码登录。
- 不要把服务器凭据写进日志或仓库。
下一步：
- 检查 DNS 解析。
- 检查反向代理。
- 确认 HTTPS 证书状态。
这类 summary 的价值在于：下一轮模型看到它，就能接着任务往下做，而不是重新问一遍“我们刚才做到哪了”。
3. 真正送进模型的是 summary 加 recent messages
压缩不是把所有内容都变成 summary。
更合理的结构是：
System Prompt
+ Tool Definitions
+ Compact State Summary
+ Recent Messages
+ Current User Message
也就是说：
- 老历史，压缩成状态摘要。
- 新历史，保留最近几轮原文。
- 当前问题，完整放入窗口。
这样做有一个好处：既保住了任务主线，又保住了最近几轮的精确细节。
比如用户刚刚说“不要部署，只本地构建”，这句话不能被粗糙压缩掉，因为它直接影响下一步动作。最近消息保留原文，就是为了避免这种关键细节丢失。
4. 压缩应该发生在模型运行前
上下文压缩最关键的时机，是模型运行前。
不是模型输出结束后，随手写一段总结。而是在下一次构建 prompt 之前，先判断当前历史是否太长。如果太长，就把旧内容和已有 summary 合并成新的 summary，然后再构建模型输入。
查看大图一个比较稳的流程是：
- 用户发来新消息。
- 消息追加到
history。 - 系统估算当前上下文长度。
- 如果超过阈值，就拆分旧消息和最近消息。
- 用 summarizer 把
old_summary + old_messages压成new_summary。 - 构建本轮模型输入：系统提示词、工具定义、状态摘要、最近消息、当前问题。
- 模型运行，必要时调用工具。
- 输出和工具结果再保存回
history。
这套流程的重点是：模型每次运行时看到的是“当前最有用的上下文”，而不是越积越厚的聊天记录。
5. 上下文压缩要保留哪些信息
压缩时，最应该保留的是和“继续执行”有关的信息。
建议至少保留 7 类：
- 用户目标：用户到底想完成什么。
- 当前进度：哪些步骤已经做完。
- 工具结果：关键命令、接口、文件检查的结论。
- 失败方法：哪些路走过但不可行，避免重复踩坑。
- 明确要求：用户说过的偏好、禁止项和确认条件。
- 环境信息：操作系统、项目路径、端口、分支、服务名等。
- 下一步计划：下一轮最应该先做什么。
不重要的信息可以弱化，比如寒暄、重复解释、临时跑偏的讨论、已经被新结论覆盖的旧判断。
但有一类信息不能随便进 summary：敏感信息。
密码、API Key、私钥、验证码、生产数据库凭据，不应该被总结进长期状态里。压缩不是“把秘密换个位置保存”，而是要明确过滤风险内容。
6. 两种常见实现方式
上下文压缩通常有两条路线。
查看大图6.1 滚动摘要
滚动摘要最简单。
系统维护一个 conversation_summary 字段。当历史超过阈值时，把旧 summary 和旧消息交给 summarizer：
old_summary + old_messages -> new_summary
然后只保留最近 N 轮完整消息。
这种方式适合大多数聊天和普通任务，成本低，实现简单，也容易接入现有系统。
但它有一个问题：如果 summarizer 写得不够稳定，重要约束可能会在多轮压缩后越来越模糊。比如一开始 summary 里有“不要部署”，压缩几次后变成“讨论了部署”，含义就变危险了。
所以滚动摘要一定要用任务状态格式约束输出。
6.2 结构化状态
结构化状态更适合长期任务。
它不让 summary 自由发挥，而是固定成字段：
{
"user_goal": "Deploy OpenClaw and connect domain",
"completed_steps": [
"SSH key-only login confirmed",
"PasswordAuthentication disabled",
"PermitRootLogin disabled"
],
"current_issue": "Bind ai-jupyter.com to Singapore server",
"environment": {
"server": "43.160.250.49",
"openclaw_port": 18789
},
"constraints": [
"Do not enable password SSH",
"Use Docker deployment",
"Do not store credentials in files"
],
"next_actions": [
"Check DNS A record",
"Configure reverse proxy",
"Issue or verify HTTPS certificate"
]
}
这种方式对 Agent 更友好，因为字段稳定，后续也更容易校验。
比如系统可以检查 constraints 是否为空，可以检查 next_actions 是否过期，也可以在执行高风险操作前读取 constraints 做二次拦截。
7. 一个实用的压缩提示词模板
如果你要自己实现 OpenClaw 风格的上下文压缩，可以给 summarizer 一个更明确的提示词：
你是一个 Agent 上下文压缩器。
请把旧对话压缩成可继续执行的任务状态，而不是普通文章摘要。
必须保留：
1. 用户最终目标；
2. 已完成步骤；
3. 当前阻塞或待确认事项；
4. 重要工具结果；
5. 失败过的方法；
6. 用户明确要求和禁止项；
7. 环境信息；
8. 下一步建议。
必须删除：
1. 寒暄和重复解释；
2. 已被新结论覆盖的旧猜测；
3. 密码、私钥、API Key、验证码等敏感信息。
输出要短，但不能丢失继续执行所需的信息。
这段提示词的关键不是“总结得漂亮”，而是“保证下一轮能接着做”。
8. 判断压缩是否合格
一个 summary 写完后，可以用 5 个问题检查：
- 看不到旧消息时，模型还能知道用户目标吗？
- 模型能知道哪些事情已经做完了吗？
- 模型能知道哪些操作禁止执行吗？
- 模型能避免重复尝试失败方法吗？
- 模型能说出下一步应该做什么吗？
如果答案是否定的，说明压缩太像普通摘要，还没有变成任务状态。
对 OpenClaw 这类会调用工具的 Agent 来说，压缩质量直接影响安全性。忘记一个约束，可能就会误执行；忘记一个失败记录，可能就会重复浪费时间；忘记当前目标，可能就会把任务带偏。
9. 不要把上下文压缩当成长期记忆
最后要分清一个边界：上下文压缩不等于长期记忆。
上下文压缩解决的是“当前这条任务线怎么继续”。它通常和会话、线程、任务有关。
长期记忆解决的是“跨任务反复有用的信息”。比如你的写作风格、常用项目路径、默认语言偏好、常用发布流程。
两者都重要，但不能混用。
如果把所有临时任务细节都写进长期记忆，记忆会越来越脏。如果把长期偏好只放在一次上下文 summary 里，换一个任务就可能丢失。
比较稳的做法是：
- 任务状态放在 compact summary。
- 长期偏好放在 memory。
- 最近对话保留原文。
- 敏感信息哪里都不要长期保存。
10. 本节小结
OpenClaw 的上下文压缩，本质是把长对话历史压缩成“可恢复任务状态”，再和最近几轮完整消息一起交给模型。
它不是为了让历史变短而变短，而是为了让 Agent 在有限上下文里继续保持目标、进度、约束和下一步动作。
你只要记住这个公式就够了：
Context Compression = State Summary + Recent Detail
好的上下文压缩，会让 OpenClaw 像一个真正能持续工作的助手：不会被旧历史拖慢，也不会因为压缩丢掉主线。
下一步，如果你要把 OpenClaw 用在长期项目、服务器运维或内容生产里，建议先把自己的 summary 模板写出来。模板越清楚，Agent 越不容易在长任务里迷路。
相关教程
相关入口
分享文章
转发到常用平台
微信/朋友圈可先复制链接
相关教程
从相近问题继续读
相关内容