压缩存活系统

压缩会抹除具体信息：文件路径、精确数值、配置细节、推理链条。本机制确保关键状态在压缩中得以保留。

问题所在：当上下文窗口填满时，OpenClaw 会将较早的消息压缩为摘要。而摘要必然损失精度——精确数字变为“大约”，文件路径消失，决策失去依据。每次压缩后，你的 agent 都会“变笨”一点。

解决方案：三套协同机制，在压缩发生前捕获关键状态，并在压缩后完整恢复。

三大机制

1. WAL 协议（预写式日志，Write-Ahead Logging）

对每一条输入消息，均需扫描以下内容：

• ✏️ 修正类语句 —— “是 X，不是 Y” / “实际上……”
• 📍 专有名词 —— 人名、地名、公司名、产品名
• 🎨 偏好表达 —— 风格倾向、方法偏好、“我喜欢/不喜欢……”
• 📋 决策声明 —— “我们做 X 吧” / “采用 Y 方案”
• 📝 草稿变更 —— 对当前工作的编辑内容
• 🔢 具体数值 —— 数字、日期、ID、URL、路径

若发现任一上述内容：

1. 暂停 —— 暂不生成响应
2. 写入 —— 将该细节更新至 SESSION-STATE.md
3. 再响应 —— 完成更新后，再向用户作答

触发时机基于用户的输入，而非你的记忆。请如实记录用户所说内容，而非你自己的理解。

2. 工作缓冲区（危险区）

当上下文使用率达 60%（通过 session_status 查看）时：

1. 创建或清空 memory/working-buffer.md，并写入如下头部：

   # Working Buffer (Danger Zone)
   **Status:** ACTIVE
   **Started:** [timestamp]
   

2. 此后每一次对话（含 60% 后的所有轮次）：将用户的输入 + 你的响应摘要追加至该文件
3. 缓冲区以文件形式存在 —— 可在压缩中完整保留
4. 保持该缓冲区内容不变，直至新会话再次达到 60% 阈值

存储位置： memory/working-buffer.md

3. 压缩恢复机制

自动触发条件（满足任一即触发）：

• 会话启动时，上下文中包含
  标签
• 你本应知晓某信息，但实际缺失
• 用户提问：“我们刚才聊到哪儿了？” / “继续” / “我们之前在做什么？”

恢复步骤（严格按顺序执行）：

1. 读取 memory/working-buffer.md —— 获取原始的“危险区”对话记录
2. 读取 SESSION-STATE.md —— 获取当前活跃任务状态
3. 读取今日及昨日的 memory/YYYY-MM-DD.md
4. 若仍缺少上下文，调用 memory_search
5. 从缓冲区中提取关键上下文 → 更新 SESSION-STATE.md
6. 向用户报告：“已恢复上下文。上一个任务是 X。正在继续。”

切勿主动询问“我们刚才在讨论什么？” —— 缓冲区中已有全部答案。

SESSION-STATE.md 格式规范

# Session State — Active Working Memory

## Current Task
[当前正在执行的任务]

## Key Details
- [通过 WAL 捕获的具体数值、路径、配置等]

## Decisions Made
- [附带依据的决策记录]

## Pending
- [待处理项 / 当前阻塞点]

## Last Updated
[timestamp]

请高频更新此文件。它是你的 RAM —— 唯一能在两次压缩事件之间完整保留具体信息的位置。

协同工作流程

                    ┌──────────────────────────┐
                    │    用户发送消息            │
                    └────────────┬─────────────┘
                                 │
                    ┌────────────▼─────────────┐
                    │  WAL：扫描具体信息        │
                    │  若命中，优先写入         │
                    └────────────┬─────────────┘
                                 │
               ┌─────────────────▼─────────────────┐
               │  上下文使用率 > 60%？全部写入缓冲区 │
               └─────────────────┬─────────────────┘
                                 │
                    ┌────────────▼─────────────┐
                    │    向用户返回响应          │
                    └────────────┬─────────────┘
                                 │
                        ┌────────▼────────┐
                        │   触发压缩（COMPACTION HIT） │
                        └────────┬────────┘
                                 │
                    ┌────────────▼─────────────┐
                    │  恢复阶段：读取缓冲区、     │
                    │  SESSION-STATE、当日/昨日日志 │
                    │  → 全量上下文恢复完成       │
                    └──────────────────────────┘

集成说明

• 与 MEMORY.md（长期记忆）和 memory/YYYY-MM-DD.md（每日日志）协同工作
• SESSION-STATE.md = 当前任务的工作记忆
• 工作缓冲区 = 危险区场景下的应急捕获机制
• 三层机制叠加运作：WAL → 缓冲区 → 恢复
• 无外部依赖。无需 API Key。纯行为模式实现。

为何有效

多数“记忆”方案试图永久保存一切内容 —— 这是错误的问题定义。真正的问题是压缩过程中的精度丢失。你不需要记住所有事，而只需在正确的时间记住正确的事。

WAL 在具体信息出现的瞬间即完成捕获；缓冲区覆盖整个危险区；恢复机制在压缩重置后重建上下文。三层设计，零依赖，零数据泄露。

由 @rustyorb + S1nthetta ⚡ 构建 —— 已在 30+ 次压缩事件中实战验证。