让 AI 记住一切:OpenClaw 自我进化实录

> 从 70% Token 自动压缩到"每日三省吾身",打造一个真正会学习的 AI 助手

---

## 背景

用 OpenClaw 一段时间后,发现两个痛点:

1. **会话太长,Token 爆满** — 聊着聊着就忘了前面的内容

2. **每次重启都是白纸** — 知识没有沉淀,重复问同样的问题

能不能让 AI 自己管理记忆,像人一样"三省吾身"?

折腾了一天,终于搞定了。

---

## 一、Token 自动压缩:70% 就动手

### 问题

OpenClaw 默认的 auto-compaction 是在 context window 接近满载时才触发。但这时候已经太晚了——对话质量下降,响应变慢。

### 解决方案

在 `~/.openclaw/openclaw.json` 中配置:

```json5

compaction: {

  mode: "safeguard",

  reserveTokensFloor: 38400,  // 30% 剩余时强制压缩

  memoryFlush: {

    enabled: true,

    softThresholdTokens: 89600,  // 70% 时先存储记忆

    prompt: "Summarize the conversation history..."

  }

}

```

### 触发顺序

| 阶段 | Token 使用率 | 行为 |

|------|-------------|------|

| 1 | 70% (89600 tokens) | memoryFlush 静默存储重要信息 |

| 2 | 70% 剩余 (38400 tokens) | auto-compaction 强制压缩 |

配合 Heartbeat 每 30 分钟检查,超过 70% 会主动提醒:

```json5

heartbeat: {

  every: "30m",

  prompt: "Read HEARTBEAT.md if it exists..."

}

```

---

## 二、双层记忆体系:快 + 深

### 架构设计

```

┌─────────────────────────────────────────────────┐

│                   用户查询                        │

└─────────────────────┬───────────────────────────┘

                      ▼

┌─────────────────────────────────────────────────┐

│     QMD(短期记忆)                              │

│     • 本地 BM25 关键词搜索                       │

│     • 毫秒级响应                                │

│     • 工作区文件索引                            │

└─────────────────────┬───────────────────────────┘

                      │ 无结果/需语义理解

                      ▼

┌─────────────────────────────────────────────────┐

│     Mem0(长期记忆)                             │

│     • 云端语义向量搜索                           │

│     • 跨会话知识沉淀                            │

│     • 重要决策、经验教训                        │

└─────────────────────────────────────────────────┘

```

### QMD 安装

```bash

# 安装 Bun(如果没装)

powershell -c "irm bun.sh/install.ps1|iex"

# 安装 QMD

bun install -g qmd

# 加入 PATH

# Windows: 添加 C:\Users\{用户}\.bun\bin 到环境变量

```

### 使用方式

```bash

# 更新索引

qmd update "C:\Users\fly\.openclaw\workspace-magic"

# BM25 搜索(无需语义向量)

qmd search "关键词" -c "C:\Users\fly\.openclaw\workspace-magic"

# 查看已索引文件

qmd ls "C:\Users\fly\.openclaw\workspace-magic"

```

### 记忆分类

| 类型 | QMD(短期) | Mem0(长期) |

|------|-----------|-------------|

| 工作区文档 | ✅ 自动索引 | ❌ |

| 临时信息 | ✅ | ❌ |

| 技术知识 | ❌ | ✅ |

| 用户偏好 | ❌ | ✅ |

| 重要决策 | ❌ | ✅ |

| 经验教训 | ✅ 可选 | ✅ |

---

## 三、每日三省吾身:AI 也会反思

### 设计思路

既然 AI 每次会话都是"新"的,那就让它定时"醒过来"检查一下自己。

仿照古人的"三省吾身":

- **晨省**:检查今日计划

- **午省**:进度回顾

- **晚省**:今日总结,存入长期记忆

### 实现

创建 `scripts/self-reflection.py`:

```python

# 三省时间窗口

MORNING_START, MORNING_END = time(6, 0), time(10, 0)   # 晨省

NOON_START, NOON_END = time(12, 0), time(15, 0)       # 午省

EVENING_START, EVENING_END = time(20, 0), time(23, 0) # 晚省

# 检查当前时段,决定是否触发反思

def get_current_period(now):

    current_time = now.time()

    if MORNING_START <= current_time <= MORNING_END:

        return "morning"

    # ...

```

在 `HEARTBEAT.md` 中配置检查流程:

```markdown

## Check Procedure

### Step 1: Check Token Usage

- If usage >= 70%: 提醒用户 /compact

### Step 2: Self-Reflection Check

运行 self-reflection.py,按时段执行反思

### Step 3: Run Task Checker

执行定时任务(QMD更新、每日总结、每周维护)

```

### 工作流程

```

Heartbeat (每30分钟)

    │

    ├── 检查 Token 使用率 >= 70%? → 提醒压缩

    │

    ├── 检查时段

    │   ├── 06:00-10:00 → 晨省(今日计划)

    │   ├── 12:00-15:00 → 午省(进度回顾)

    │   └── 20:00-23:00 → 晚省(总结 + Mem0)

    │

    └── 执行定时任务

        ├── QMD 索引更新(>20h)

        ├── 每日总结(>20h)

        └── 每周维护(~6天)

```

---

## 四、文件结构

```

workspace-magic/

├── AGENTS.md              # 工作区规则

├── SOUL.md                # AI 人格定义

├── USER.md                # 用户信息

├── MEMORY.md              # 长期记忆核心(手动维护)

├── HEARTBEAT.md           # Heartbeat 任务定义

├── scripts/

│   ├── check-tasks.py     # 定时任务检查

│   └── self-reflection.py # 三省系统

└── memory/

    ├── 2026-02-25.md      # 每日日志

    ├── reflection-state.json  # 三省状态

    └── cron-state.json    # 任务状态

```

---

## 五、效果

### 配置生效确认

```bash

$ openclaw config get agents.defaults.compaction

{

  "mode": "safeguard",

  "reserveTokensFloor": 38400,

  "memoryFlush": {

    "enabled": true,

    "softThresholdTokens": 89600

  }

}

$ openclaw config get agents.defaults.heartbeat

{

  "every": "30m",

  "prompt": "Read HEARTBEAT.md if it exists..."

}

```

### 记忆系统状态

| 系统 | 状态 | 数量 |

|------|------|------|

| QMD | ✅ 正常 | 17 个文件索引 |

| Mem0 | ✅ 正常 | 26 条记忆 |

### 三省系统

当前时段会自动检查,在对应时间窗口触发反思任务。

---

## 六、下一步

- [ ] 观察晚省自动总结效果

- [ ] 优化 Mem0 存储质量(自动提取关键信息)

- [ ] 探索更智能的记忆召回策略

---

## 总结

这套系统的核心思想:

1. **Token 管理**:主动出击,70% 就压缩,不要等爆了再救

2. **双层记忆**:快的负责日常,深的负责沉淀

3. **自我进化**:定时反思,让 AI 越用越聪明

OpenClaw 的配置灵活度很高,配合 Heartbeat 和自定义脚本,可以做出很多有趣的东西。

---

*2026-02-25 by Fly @ flys161*

Read more

企业管理系统前端组件化设计实战:OA、CRM、ERP 表单为什么不能直接用 Element UI / Ant Design?

企业管理系统前端组件化设计实战:OA、CRM、ERP 表单为什么不能直接用 Element UI / Ant Design?

企业管理系统前端组件化设计实战:OA、CRM、ERP 表单为什么不能直接用 Element UI / Ant Design? 🌐 文档地址:http://ruoyioffice.com | 📦 源码1:https://gitee.com/yqzy1688/ruoyi-office-vben.git |📦 源码2:https://gitee.com/yqzy1688/ruoyi-office.git |📦 源码3:https://github.com/yuqing2026/ruoyi-office.git | 💬 :17156169080(备注「RuoYi Office」) 做过企业管理系统的前端开发者都有一个共同痛点:每做一个新模块,就要重复写一堆表单、表格、状态标签、操作按钮的代码。 更糟糕的是,无论你用 Element UI(Element Plus)

【Linux篇章】穿越网络迷雾:揭开 HTTP 应用层协议的终极奥秘!从请求响应到实战编程,从静态网页到动态交互,一文带你全面吃透并征服 HTTP 协议,打造属于你的 Web 通信利刃!

【Linux篇章】穿越网络迷雾:揭开 HTTP 应用层协议的终极奥秘!从请求响应到实战编程,从静态网页到动态交互,一文带你全面吃透并征服 HTTP 协议,打造属于你的 Web 通信利刃!

本篇摘要 本篇将介绍何为HTTP协议,以及它的请求与答复信息的格式(请求行,请求包头,正文等),对一些比较重要的部分来展开讲解,其他不常用的即一概而过,从静态网页到动态网页的过渡,最后底层基于TCP实现简单的HTTP服务器的代码编写构建一个简单的网页(包含对应的跳转,重定向,动态交互等功能),采取边讲解http结构边用代码形成效果展示的形式进行讲解,望有助! 欢迎拜访:点击进入博主主页 本篇主题:探秘HTTP应用层那些事儿! 制作日期:2025.07.21 隶属专栏:点击进入所属Linux专栏 本文将要介绍的内容的大致流程图如下: 一· 认识HTTP * 在互联网世界中, HTTP(HyperText Transfer Protocol, 超文本传输协议) 是一个至关重要的协议。 它定义了客户端(如浏览器) 与服务器之间如何通信, 以交换或传输超文本(如 HTML 文档) 。 * HTTP 协议是客户端与服务器之间通信的基础。 * 客户端通过 HTTP 协议向服务器发送请求, 服务器收到请求后处理并返回响应。 HTTP 协议是一个无连接、

前端虚拟列表实现:别再渲染10000个DOM节点了

前端虚拟列表实现:别再渲染10000个DOM节点了

前端虚拟列表实现:别再渲染10000个DOM节点了 毒舌时刻 这代码写得跟网红滤镜似的——仅供参考。 各位前端同行,咱们今天聊聊前端虚拟列表。别告诉我你还在一次性渲染10000个列表项,那感觉就像把10000本书全部摆在桌面上——既占地方又难找。 为什么你需要虚拟列表 最近看到一个项目,一个下拉列表有5000个选项,全部渲染导致页面卡死,我差点当场去世。我就想问:你是在做列表还是在做性能杀手? 反面教材 // 反面教材:一次性渲染所有数据 function BigList({ items }) { return ( <ul style={{ height: '400px', overflow: 'auto' }}> {items.map(item => ( <li key={item.id} style={{ height: '50px'