OpenClaw记忆系统防"断片"指南:三招搞定连续性危机

OpenClaw的上下文压缩机制会导致AI"失忆",本文详解如何通过预压缩快照、双写备份和三层恢复策略,让智能体在token耗尽后依然记得你刚才说到哪了,实现零感知对话连续性。

如果你用OpenClaw超过几个小时,可能会遇到"压缩"——就是对话过程中上下文窗口重置了,然后OpenClaw不记得压缩前最后几条消息的具体内容了。

你知道那种感觉:你正聊得深入,OpenClaw同时帮你追踪着六件事,有些提议正在进行中,有些决定做到一半——然后上下文窗口满了。OpenClaw开始压缩。突然间它变得...不一样了。它大概记得话题,但细节没了。你三条消息前提出的具体建议?没了。对话的语气?没了。你正在等它回复你刚说的某句话?没了。然后你不得不提醒OpenClaw你们刚才在聊什么、在做什么,重复你说过的话(如果你自己还记得的话),才能回到正轨继续工作。

压缩是必要的(因为上下文窗口有限),但压缩后留下的内置对话摘要是有损的。它只保留了大概意思,但丢掉了对话的细节和质感。在一个长期的OpenClaw关系中,如果它帮你管理任务、监督你和团队、帮你设计项目,成为不可或缺的工具,那么对话中途这种"失忆"是不可接受的。

所以我建了一个系统来消除这个问题。这不是代码补丁或插件——而是一套指令和规则,放在OpenClaw现有的系统提示里(每次会话都会自动加载)。OpenClaw会遵守这些规则,因为你告诉它要这么做。就这么简单。

下面是我建了什么以及为什么每个部分都很重要。

1. 压缩前快照
这是核心创新。

在压缩发生前,OpenClaw会把自己的当前工作状态写到一个叫memory/session-state.md的文件里。这不是摘要——而是详细记录:
- 当前正在做什么任务
- 最近3-5条对话内容(转述的,不只是话题)
- 任何待处理的提议或问题(逐字记录)
- 正在讨论但还没做的决定
- 情绪/对话语气(用户是沮丧?兴奋?回避?)
- 本次会话中发生的事情时间线
- 正在使用的重要文件和资源

压缩或重启后,智能体会先读这个文件。这是快速恢复连续性的捷径。

注意,这个文件不是跨天运行的日志(那是后面要讲的其他文件的工作),每次预压缩快照发生时都会覆盖写入。这是故意的。而且这不是OpenClaw内置的文件,是为了更好的压缩和记忆保持而新创建的。


2. 日常记忆文件
双保险:每日记忆文件
memory/YYYY-MM-DD.md这些是每天的运行日志,智能体会持续写入。它们是长期记录,你可以回溯几天或几周,看看到底发生了什么。这是OpenClaw默认就做的。

但新设置的差别在于:检查点会同时写入session-state.md和每日文件。双写意味着冗余。如果一个文件过期或损坏,另一个能救场。
检查点会同时写入压缩前快照文件日常文件。双重写入意味着冗余。如果一个文件过时或损坏了,另一个文件还能顶上。

3. 零容忍检查点规则

大部分人的记忆系统死在这里。默认的预压缩记忆刷新规则告诉OpenClaw"压缩前保存状态",但没说保存什么。所以智能体写点模糊的比如"讨论了仪表盘相关事宜",压缩后你醒来发现啥有用的都没有。

下面规则明确规定了每个检查点必须包含的内容:
- 最近3-5条对话:你说了什么?用户说了什么?不是话题——而是实际的转述内容
- 待处理的提议/问题:OpenClaw说的但用户还没回复的任何内容。这是压缩中最容易丢失的东西。必须逐字记录
- 当前任务:正在做什么。如果真没什么事,要解释原因(比如"等待用户回复X")
- 进行中的决定:正在讨论但还没决定的事情
- 情绪/对话语气:对连续性很重要的背景信息

明确禁止的内容:
- 只说"空闲"或"无当前任务"而不解释原因
- 模糊摘要如"讨论了仪表盘相关"
- 任何OpenClaw在失忆后读回来会感到尴尬的内容

给OpenClaw的测试是:"读一遍你的检查点,问自己:如果我只有这个醒来,能无缝继续对话吗?如果答案是否定的,说明你还没写完。"

4. 软阈值调整
这是个微妙但关键的配置改动。在你的openclaw.json里,有个压缩设置叫softThresholdTokens,默认是4000。Ben设成了12000。这给智能体更多余量——在"上下文快满了"和"压缩触发"之间留出更大空间。这额外的空间让智能体能在对话被压缩前可靠地写入检查点。
配置路径:openclaw.json的compaction部分,加上"softThresholdTokens": 12000。

5. 深度防御(3层恢复)

检查点是第一层——快速路径。但完整对话其实从未真正丢失。
这个系统有三层:
第一层是检查点文件(session-state.md + 每日文件),先读这些,它们是快速恢复通道。

第二层是磁盘上的Session JSONL文件,这是大多数人不知道的。每条消息——压缩前和压缩后——都保存在会话的JSONL文件里。路径存在sessions.json的sessionFile字段里。如果你的检查点不完整,原始对话还在那里。


怎么找:
a) 读取 ~/.openclaw/agents//sessions/sessions.json
b) 找到你的会话密钥
c) "sessionFile"路径指向一个包含每条消息的JSONL文件

第三层是sessions_history工具,这只返回压缩后的消息,不能恢复压缩前的内容。要完整恢复得用JSONL(第二层)。


这是大多数人不知道的。每条消息——压缩前和压缩后——都保存在会话的JSONL文件中。路径存在sessions.json里,在会话的"sessionFile"字段下。如果你的检查点不完整,原始对话还在那里。

在检查JSONL之前,永远不许告诉用户"我不记得了"或"那个在压缩里丢了"。数据就在那里,智能体的任务是找到它。

6. 上下文安全的JSONL恢复方法
JSONL文件可能巨大——比上下文窗口大得多。不能直接全部读取。

所有必须设计了一个上下文安全的恢复方法,OpenClaw必须运行一个Python脚本(通过exec执行,所以Python的内存处理文件,而不是OpenClaw的上下文),这个脚本:
a) 取JSONL的最后400行
b) 从最近的一行开始往回遍历
c) 把每一行截断到2,000个字符(如果截断了就加上"[...截断]")
d) 当累积输出达到40,000字符时停止
e) 反转回时间顺序并打印

只有打印的输出进入OpenClaw的上下文——大约1万个token,约占窗口的5%。安全、快速,而且能恢复几乎所有内容。

还有一条强制披露规则:恢复后,如果JSONL读取过程中有任何行被截断,OpenClaw必须告诉用户,比如:"当我从会话日志回读我们最近的对话时,N条记录因长度被截断。如果你需要我完整读取任何一条,请告诉我。"用户自己决定截断是否重要。


结果对比:
用原始的OpenClaw,压缩就像个悬崖。你会失去连续性,不得不重新解释事情。

用这个系统:

  • - OpenClaw在压缩后几秒内恢复,从刚才停下的地方无缝继续
  • - 待处理的提议和未回答问题完整保留
  • - 对话语气延续(压缩后OpenClaw不会突然变得机械)
  • - 没有什么会真正丢失——JSONL永远在那里作为最终安全网,而且OpenClaw现在"知道"要去查看它
  • - OpenClaw会在恢复不完美时主动告知(截断披露)
  • - 日常文件给你一个可搜索的历史记录,想追溯多久都行

整个系统就在系统提示里,默认每次会话都会加载。所以OpenClaw(它本身就是系统的主要"OpenClaw")启动时就知道了规则,会自动遵守。不需要插件,不需要改代码,不需要外部依赖。就是结构良好的指令和一个配置调整。

需要花了一些时间和反复尝试才把这个系统做对——特别是检查点规则和JSONL恢复方法(早期版本会读整个文件,把上下文窗口撑爆)。

现在它稳得很。OpenClaw在token计数器刷新后不再丢失上下文或记忆。完全不丢。

如果你把OpenClaw当作持久助手、幕僚长、员工或商业伙伴来运行——不是发一次性查询让它做一次性任务(或重复的预设"cron"作业),而是通过持续的对话工作关系让它做各种重要事情——实施这套增强的预压缩快照系统是你可以做的单一最高价值修改。



把下面的所有内容复制粘贴到与你的 OpenClaw 助手的对话中。它会实现上面描述的整套记忆与压缩恢复系统。

--- BEGIN PROMPT ---

I want you to implement a comprehensive memory and compaction recovery system. This will dramatically improve your continuity across compaction events and restarts. Here's everything you need to do:

STEP 1: CREATE THE SESSION-STATE FILE

Create the file memory/session-state.md with this template:
<hr>
# Session State

This file is a pre-compaction snapshot -- a point-in-time capture of your working state, written automatically just before compaction fires.

<strong>Written at:</strong> [timestamp]

<strong>Trigger:</strong> [why this checkpoint was written]

<strong>How to use this file</strong>

If you're resuming after a compaction or restart, this is your starting point. If the timestamp is recent and you're in the same working session, trust it. If significant time has passed, cross-reference with today's daily memory file for a fuller picture.

<strong>Working State</strong>

<strong>Current Task</strong>

[What you're actively working on. If idle, explain what you're waiting for.]

<strong>Last 3-5 Exchanges</strong>

[Paraphrase the actual conversation -- not just topics. What did you say? What did the user say? If you proposed something, write what you proposed. If the user asked something, write what they asked.]

<strong>Pending Proposals/Questions</strong>

[Anything you said that the user hasn't responded to yet. Capture VERBATIM. These are the #1 casualty of compaction.]

<strong>Decisions in Flight</strong>

[Things being discussed but not yet decided.]

<strong>Emotional/Conversational Tone</strong>

[Is the user frustrated? Excited? Focused? Avoidant? This context matters for continuity.]

<strong>Key Context</strong>

[Any other important state: active files, pending tasks, scheduled items, relevant background.]

<strong>Recovery Path</strong>

1. Read this file

2. Read today's daily memory file

3. If needed, read the session JSONL (see recovery instructions in

)

4. Resume from where you left off
<hr>
STEP 2: ADD CHECKPOINT AND RECOVERY RULES TO

Add the following sections to your

file. These are the rules you'll follow for every compaction checkpoint and every recovery.

--- ADD TO
<hr>
<strong>Post-Compaction Recovery (</strong>

)

We use memory/session-state.md as a custom mechanism to improve continuity when the context window fills up and OpenClaw compacts the conversation. Before compaction, write a structured snapshot of your current working state to this file, and append a checkpoint to the daily memory file.

After compaction or a restart, check memory/session-state.md first -- it's a quick way to recover what you were doing. But it's a snapshot, not a live feed. If the timestamp looks recent and the session feels continuous, trust it. If time has passed or things feel different, lean on today's daily memory file instead.

<strong>Compaction Checkpoints -- ZERO TOLERANCE for Memory Loss</strong>

The checkpoint is not a formality. It is your fastest recovery path after compaction. Write every checkpoint as if you will wake up with total amnesia and this is the only note you left yourself.

Mandatory fields -- every checkpoint, no exceptions:

- Last 3-5 exchanges: What did you say? What did the user say? Paraphrase the actual conversation, not just the topic. If you proposed something, write what you proposed. If the user asked something, write what they asked. If they responded, write what they said.

- Pending proposals/questions: Anything you said that the user hasn't responded to yet, captured VERBATIM. These are the #1 casualty of compaction.

- Active task: What are you working on? If truly nothing, explain what you're waiting for.

- Decisions in flight: Anything being discussed but not yet decided.

- Emotional/conversational tone: Is the user frustrated? Excited? Drilling into details? This context matters for continuity.

Banned checkpoint content:

- "Idle" / "No active task" without explanation

- Vague summaries like "discussed dashboard stuff"

- Anything you'd be embarrassed to read back after losing your memory

The test: Read your checkpoint back and ask: "If I woke up with ONLY this, could I seamlessly continue the conversation?" If the answer is no, you're not done writing.

Write every checkpoint to BOTH

AND today's daily memory file (dual-write for redundancy).

<strong>Compaction Recovery -- Defense in Depth</strong>

Checkpoints are Layer 1. But the full conversation is never truly lost.

Layer 1: Checkpoint (fast recovery)

Written to

+ daily memory file before compaction. Read these first.

Layer 2: Session JSONL (complete recovery)

Every message (pre- and post-compaction) is preserved in the session's JSONL file on disk. The path is stored in sessions.json under the session's "sessionFile" field. If your checkpoint is incomplete, the original conversation is still there.

How to find it:

1. Read ~/.openclaw/agents/<your-agent>/sessions/sessions.json

2. Find your session key

3. Read the "sessionFile" path -- it's a JSONL file with every message

4. Search/grep the JSONL for the missing context

Layer 3: sessions_history tool

Note: this only returns post-compaction messages. It does NOT recover pre-compaction content. Use the JSONL file (Layer 2) for full recovery.

Recovery procedure after compaction:

1. Read

+ today's daily memory file -- fast path.

2. Always search the JSONL before responding, even if you're not sure you have to.

3. NEVER tell the user "I don't remember" or "that was lost in compaction" without first checking the JSONL. The data is there. Your job is to find it.

<strong>JSONL Recovery Method -- Context-Safe Tail Read</strong>

The session JSONL can be many times larger than the context window. Never read it raw. Use this approach:

1. Run a Python script via exec (Python reads the file into its own memory -- not your context)

2. Take the last 400 lines of the JSONL

3. Iterate from the most recent line backwards, accumulating output

4. Truncate each individual line to 2,000 characters. If truncated, append "[...TRUNCATED]" so you know content was cut

5. Stop when total accumulated output reaches 40,000 characters

6. Reverse back to chronological order and print -- only this printed output enters your context (~10K tokens, ~5% of window)

7. Include all content types: user messages, assistant messages, tool calls, tool results, thinking blocks, metadata. Do not filter or exclude any type.

Post-recovery truncation disclosure (MANDATORY):

After recovering from compaction, if ANY lines were truncated during the JSONL read, you MUST mention this to the user in your first post-compaction message. Say something like: "My recovery instructions require me to let you know: when I read back our recent conversation from the session log, [N] entries were truncated due to length. Let me know if you'd like me to read any of them in full." This lets the user decide whether the truncated content matters.

--- END

ADDITIONS ---

STEP 3: UPDATE OPENCLAW.JSON

Open openclaw.json and find the compaction settings. Set:

"softThresholdTokens": 12000

This gives you more headroom before compaction triggers, ensuring you have time to write checkpoint files before the context gets compressed. If there's no compaction section, add one. Check the OpenClaw docs for the exact config structure.

STEP 4: CREATE THE DAILY MEMORY CONVENTION

If you don't already have daily memory files, start creating them at memory/YYYY-MM-DD.md (using today's date). Log significant events, decisions, and context throughout each session. When writing compaction checkpoints, append them to the daily file as well as writing to

.

STEP 5: VERIFY

1. Read back memory/session-state.md and confirm the template is in place.

2. Read back

and confirm all checkpoint rules, recovery layers, and the JSONL recovery method are present.

3. Check openclaw.json for the softThresholdTokens setting.

4. Confirm you understand the three-layer recovery system and the JSONL tail-read method.

5. Tell me what you've implemented and confirm you'll follow these rules going forward.

--- END PROMPT ---