OpenClaw 记忆管理系统架构示意图,展示 MEMORY.md、memory 目录和混合搜索引擎的关系

OpenClaw 记忆管理原理:从文件结构到语义搜索的深度解析

🎧 收听播客版本

⏱️ 时长约 3 分 54 秒 | 📥 也可以在通勤、运动时收听


🧠 为什么 AI 需要记忆?

想象一下,如果你每天醒来都忘记昨天发生的一切——那会是什么体验?

大多数 AI 助手就是这样:无状态的。每次对话都是全新的开始,它们不记得你说过的话、做过的事、偏好什么。

OpenClaw 改变了这一点。

记忆的价值

有了记忆,AI 助手能够:

  • 记住你的偏好:你知道我不喜欢表格,喜欢用列表
  • 理解上下文:知道”Rod”是你的同事,“evolver”是你在运行的自进化引擎
  • 避免重复劳动:不需要反复解释同一个概念
  • 提供个性化服务:根据你的历史行为给出更精准的建议

记忆让 AI 从”工具”变成”伙伴”


📁 OpenClaw 记忆系统的文件结构

OpenClaw 的记忆系统基于文件系统,设计简洁但功能强大。

核心文件

~/.openclaw/workspace/
├── MEMORY.md                    # 长期记忆(curated memory)
└── memory/
    ├── 2026-02-28.md            # 每日记忆(raw logs)
    ├── 2026-02-28-1419.md       # 会话记忆(session transcript)
    ├── 2026-02-28-evolver-loop.md
    └── 2026-03-01.md            # 今天的记忆

MEMORY.md vs memory 目录

这是很多人困惑的地方:MEMORY.md 和 memory 目录里的文件有什么区别?

维度MEMORY.mdmemory/YYYY-MM-DD.md
定位长期记忆(Long-term Memory)短期记忆/工作记忆(Working Memory)
内容精选的、重要的、值得长期保留的信息原始的、详细的对话日志
更新频率定期整理、手动或自动更新每次会话自动创建
类比人类的”长期记忆”——经验、教训、重要事实人类的”日记”——每天发生了什么
加载时机仅在主会话(direct chat)加载所有会话都加载当天和昨天的
安全性包含个人隐私,不在群聊中加载相对安全,可以跨会话共享

关键区别

MEMORY.md 是精选的记忆,是你希望 AI 长期记住的东西。 memory 目录是原始日志,记录了每天发生的细节。

实际例子

MEMORY.md 可能包含

## 重要关系
- Rod:同事,工作时间 14:15 standup
- Leap:我的创造者,偏好简洁的列表而非表格

## 项目上下文
- evolver:自进化引擎,运行在--loop 模式,策略 innovate
- EvoMap:去中心化 AI 市场,节点 ID node_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

## 技术偏好
- 喜欢本地部署,注重隐私
- 偏好 GGUF 格式的本地模型

memory/2026-02-28.md 可能包含

# Session: 2026-02-28 14:19:16 UTC

user: 局域网已经配置了 ollama,地址是 http://192.168.x.x:11434/v1
assistant: 收到!配置局域网 Ollama...
user: 配置一下本地 memory-search 使用模型
assistant: OpenClaw 的 memory-search 工具默认使用当前会话模型...

最佳实践

  • 每天结束时,回顾当天的 memory 文件
  • 将重要的信息提炼到 MEMORY.md
  • 定期清理 MEMORY.md 中过时的内容

🔍 Memory-Search:记忆检索系统

有了记忆文件,下一个问题是:如何快速找到需要的记忆?

这就是 memory_search 工具的作用。

双引擎混合搜索

OpenClaw 的记忆搜索不是简单的关键词匹配,而是混合搜索

用户查询

┌─────────────────────────────┐
│      查询理解层              │
│  - 关键词提取                │
│  - 语义分析                  │
└──────────────┬──────────────┘

    ┌──────────┴──────────┐
    ↓                     ↓
┌─────────┐         ┌─────────┐
│ BM25    │         │ 向量    │
│ 全文检索 │         │ 语义检索 │
│ (FTS5)  │         │ (Embedding)│
└────┬────┘         └────┬────┘
     │                   │
     │ top 24 results    │ top 24 results
     ↓                   ↓
┌────┴───────────────────┴────┐
│      Weighted Merge          │
│  finalScore =                │
│  0.7 × vectorScore +         │
│  0.3 × textScore             │
└────────────┬─────────────────┘

      Top 6 Results

BM25 全文检索

技术基础:SQLite FTS5 引擎

工作原理

  • 基于词频(TF)和逆文档频率(IDF)计算相关性
  • 擅长精确匹配高价值 token
  • 速度极快,基于倒排索引

优势

  • ✅ 无需额外配置,始终可用
  • ✅ 精确匹配 ID、代码、错误字符串
  • ✅ 性能稳定

局限

  • ❌ 无法理解”配置”和”设置”是同一概念
  • ❌ 无法处理”路由器”和”router”的同义关系

向量语义检索

技术基础:嵌入模型 + 余弦相似度

工作原理

  • 通过嵌入模型将文本转化为高维向量(如 768 维)
  • 基于余弦相似度计算向量距离
  • 语义相近的文本在向量空间中距离相近

优势

  • ✅ 理解语义关联
  • ✅ 处理同义词、多语言表达
  • ✅ 支持模糊查询

局限

  • ❌ 需要 embedding 模型(本地或远程 API)
  • ❌ 对精确 ID、代码符号匹配较弱

混合搜索的优势

查询类型BM25 表现向量搜索表现混合搜索
”evolver loop 配置”✅ 精确匹配✅ 语义理解✅ 最佳
”自进化引擎怎么设置”❌ 无关键词✅ 语义匹配✅ 找到
”node_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”✅ 精确匹配⚠️ 可能偏离✅ 平衡

默认权重

  • vectorWeight: 0.7 - 语义相似度 70%
  • textWeight: 0.3 - 关键词匹配 30%

⚙️ Embedding Provider 配置

要实现向量语义检索,需要配置 embedding provider。

支持的 Provider

Provider类型模型示例维度成本推荐场景
local本地 GGUFembeddinggemma-300m768免费⭐ 个人使用
openai远程 APItext-embedding-3-small1536$0.02/1M企业/专业
gemini远程 APIgemini-embedding-001768免费额度多语言
voyage远程 APIvoyage-31024$0.06/1M专业需求
mistral远程 APImistral-embed1024€0.10/1M欧洲用户

推荐配置:Local (GGUF)

为什么推荐本地方案?

  • ✅ 完全本地 - 数据不出本地,隐私保护
  • ✅ 零成本 - 一次性下载,无后续费用
  • ✅ 开箱即用 - 无需 API Key 配置
  • ✅ 官方默认 - OpenClaw 默认推荐

配置示例

{
  "agents": {
    "defaults": {
      "memorySearch": {
        "enabled": true,
        "provider": "local",
        "local": {
          "modelPath": "hf:ggml-org/embeddinggemma-300m-qat-q8_0-GGUF/embeddinggemma-300m-qat-Q8_0.gguf"
        },
        "sync": {
          "watch": true
        },
        "query": {
          "hybrid": {
            "enabled": true,
            "vectorWeight": 0.7,
            "textWeight": 0.3
          }
        }
      }
    }
  }
}

🔄 记忆的生命周期

记忆不是一成不变的,它有生命周期。

记忆创建流程

用户对话

会话结束

自动生成 memory/YYYY-MM-DD-HHMM.md

记录对话内容、工具调用、决策

等待整理

记忆整理流程

定期(如每周)

阅读 memory 文件

识别重要信息

提炼到 MEMORY.md

删除过时内容

记忆衰减

OpenClaw 支持时间衰减功能:

{
  "query": {
    "hybrid": {
      "temporalDecay": {
        "enabled": true,
        "halfLifeDays": 30
      }
    }
  }
}

含义

  • 30 天前的记忆,权重减半
  • 90 天前的记忆,权重降至 12.5%
  • 但重要记忆(MEMORY.md)不受衰减影响

为什么需要衰减?

  • 模拟人类记忆的遗忘曲线
  • 优先返回近期相关信息
  • 避免过时信息干扰

🛡️ 安全与隐私

记忆系统涉及隐私保护,OpenClaw 设计了多层安全机制。

会话隔离

会话类型加载 MEMORY.md加载 memory 文件
主会话(direct chat)✅ 是✅ 是
群聊(group chat)❌ 否✅ 是(当天 + 昨天)
子 agent❌ 否✅ 是(有限)

原因:MEMORY.md 包含个人隐私,不应在群聊中泄露给陌生人。


💡 最佳实践

1. 定期整理记忆

每周例行

# 查看本周记忆
ls -la ~/.openclaw/workspace/memory/2026-*.md

# 阅读并提炼
cat ~/.openclaw/workspace/memory/2026-02-28-1419.md

# 更新 MEMORY.md
nano ~/.openclaw/workspace/MEMORY.md

2. 使用标签组织记忆

在 memory 文件中使用标签:

## 标签
#evolver #eomap #配置 #决策

## 关键决策
- 选择 local embedding provider(隐私优先)
- evolver 使用--loop 模式(自动化)

3. 避免记忆污染

不要做

  • ❌ 把所有对话都当作重要记忆
  • ❌ 在 MEMORY.md 中存储临时信息
  • ❌ 从不清理过时的记忆

应该做

  • ✅ 只保留真正重要的信息
  • ✅ 定期审查和更新
  • ✅ 保持 MEMORY.md 简洁

📊 实际效果对比

有记忆 vs 无记忆

场景无记忆有记忆
第二次询问配置❌ 需要重新解释✅ 直接引用历史配置
跨会话上下文❌ 丢失✅ 保持连续
个性化建议❌ 通用建议✅ 基于历史偏好
错误排查❌ 从头开始✅ 参考历史错误和解决方案

配置 embedding vs 不配置

维度未配置(仅 BM25)已配置(混合搜索)
同义词理解❌ “配置”≠“设置”✅ “配置”=“设置”
多语言❌ “network”≠“网络”✅ 语义匹配
模糊查询❌ 必须精确✅ 支持语义关联
搜索质量⚠️ 基础可用✅ 优秀

🔮 未来展望

OpenClaw 的记忆系统还在演进中。

计划中的功能

  1. 记忆图谱:可视化的记忆关联网络
  2. 自动摘要:AI 自动提炼每日记忆到 MEMORY.md
  3. 记忆检索优化:更好的混合搜索算法
  4. 跨 agent 记忆共享:在安全前提下共享记忆

终极目标

让 AI 真正理解你——不仅是记住你说过的话,更是理解你的意图、偏好、价值观。

当 AI 拥有记忆,它就不再只是一个被动响应指令的工具,而是一个能够理解你的上下文、记住你的偏好、随着时间推移越来越懂你的伙伴。

这或许就是个人 AI 助手最迷人的前景。


📎 参考来源

官方文档

技术背景


如果这篇文章对你有帮助,欢迎分享给同样在使用 OpenClaw 的朋友! 🤖


Related Posts

OpenClaw 多 Agent Blog Generator 配置方案

记录 blog-generator 技能从单 Agent 到多 Agent 配置的演进过程,包括问题来源、解决方案和实践总结

多 Agent 协作实战:从理论到实践的深度对比分析

通过五子棋游戏开发对比 Multi-Agent 与单 Agent 的工作流程,分析各自优劣势、适用场景,并探讨 OpenClaw 多 Agent 架构在实际应用中的技术挑战与解决方案。