跳转到主要内容

OpenClaw v2026.4.11 内置记忆系统 vs OpenClaw memory-system 插件

全面技术对比分析

作者：乔巴 🦌
日期：2026-04-13
版本：OpenClaw v2026.4.11 | memory-system v4.0.0

一、背景与概述

1.1 问题的由来

OpenClaw 在 2026.4.11 版本中大幅增强了内置记忆系统，新增了 active-memory、memory-wiki、Honcho、QMD 等一系列记忆相关插件。与此同时，团队自研的 memory-system 插件（v4.0.0）已经在生产环境中运行了相当长的时间，承担着 WAL 协议、多层记忆管理、自动提取、评分晋升等核心功能。

核心问题是：新版内置插件与现有的自定义插件之间，是否存在功能重叠？性能效率差异有多大？未来的技术路线应该如何规划？

1.2 我们的记忆架构现状

Copy


┌─────────────────────────────────────────────────────────┐
│                    用户对话                               │
└──────────────────────┬──────────────────────────────────┘
                       │
         ┌─────────────▼──────────────┐
         │    memory-system v4.0.0    │ ← 自定义插件
         │  ┌─────────────────────┐    │
         │  │ • WAL 协议          │    │
         │  │ • autoExtract       │    │
         │  │ • 评分/晋升/维护    │    │
         │  │ • 主动预判          │    │
         │  │ • 矛盾检测          │    │
         │  └─────────────────────┘    │
         └─────────────┬────────────────┘
                       │ 建立在之上
       ┌───────────────┼───────────────┐
       ▼               ▼               ▼
┌─────────────┐ ┌─────────────┐ ┌──────────────┐
│memory-core  │ │lossless-    │ │ builtin      │
│(内置slot)   │ │claw         │ │ active-memory│
│ • SQLite    │ │(contextEng) │ │ (当前禁用)   │
│ • FTS5+向量 │ │ • LCM压缩   │ │              │
│ • memory_   │ │ • 摘要管理  │ │              │
│   search    │ │ • lcm_grep  │ │              │
└─────────────┘ └─────────────┘ └──────────────┘

核心认识：memory-system 并不是替代品，而是建立在内置系统之上的编排层。

二、系统架构对比

2.1 OpenClaw v2026.4.11 内置记忆体系

2.1.1 memory-core（内置默认 / 记忆插槽）

属性

说明

定位

OpenClaw 默认的记忆后端，分配在

 plugins.slots.memory 

插槽

存储介质

SQLite 数据库（

~/.openclaw/memory/<agentId>.sqlite

）+ Markdown 文件

检索方式

FTS5 全文搜索（BM25 评分）+ Ollama 向量搜索（nomic-embed-text）的混合检索

索引对象

MEMORY.md 

+

 memory/*.md 

文件

提供工具

memory_search

、

memory_get

配置

agents.defaults.memorySearch.provider: "ollama"

特殊功能

文件监视自动重建索引（1.5s 防抖）、Temporal Decay、MMR 多样性重排

索引流程：


Markdown 文件 → Chunking (~400 tokens, 80 overlap)
            → Ollama nomic-embed-text 向量化
            → SQLite 存储（向量 + FTS5）
            → 用户查询时：向量检索 ∪ BM25 → Weighted Merge → Top Results

2.1.2 active-memory（内置可选插件 / v2026.4.11 新增）

属性

说明

定位

阻塞式记忆子代理，在主模型生成回复

之前

执行

工作方式

启动一个受限制的子代理（只允许

 memory_search 

+

 memory_get

）

查询模式

message

（仅最新消息）/

 recent

（用户+助手最近几轮）/

 full

（完整上下文）

Prompt 风格

strict / balanced / contextual / recall-heavy / precision-heavy / preference-only

默认超时

15000ms

摘要长度

默认 220 字符，最大 1000 字符

结果格式

"NONE" 或 1 条紧凑纯文本摘要

注入方式

<active_memory_plugin>...</active_memory_plugin> 

标签注入 prompt

缓存机制

15 秒 TTL，相同查询直接返回缓存

当前状态

未启用

（

plugins.entries 

中无配置）

执行流程：

Copy


用户发消息
  → 启动 blocking 子代理（15s 超时）
    → 根据 queryMode 组装上下文（message/recent/full）
    → 子代理调用 memory_search → memory_get
    → LLM 生成 "NONE" 或 <220 字符摘要
  → <active_memory_plugin>标签注入主 prompt
  → 主模型生成回复

2.1.3 lossless-claw（内置上下文管理 / v2026.4.11）

属性

说明

定位

LCM（Lossless Context Management）会话压缩与上下文管理

插槽

plugins.slots.contextEngine

版本

v0.8.0

摘要模型

Ollama qwen3.5:9b（本地）

提供工具

lcm_grep

、

lcm_expand

、

lcm_expand_query

、

lcm_describe

核心功能

会话压缩摘要、增量深度展开、 DAG 遍历式召回

2.1.4 其他内置插件（未安装）

插件

功能

未安装原因

memory-wiki

知识保险库、provenance、claims、dashboards

尚未探索

Honcho

跨会话记忆、用户建模

尚未探索

QMD

本地搜索侧车、reranking、query expansion

尚未探索

2.2 memory-system 自定义插件架构

2.2.1 核心定位


┌──────────────────────────────────────────────────────────┐
│              memory-system v4.0.0                        │
│  Multi-layer memory optimizer for OpenClaw agents        │
│  WAL + SelfReflection + Proactive                        │
└──────────────────────────────────────────────────────────┘

属性

说明

定位

建立在 memory-core + lossless-claw 之上的

多层记忆编排层

核心功能

WAL 协议、autoExtract、记忆评分/晋升/维护、主动预判、矛盾检测

数据目录

~/.openclaw/workspace/memory/agents/main/{hot,warm,daily,cold}

存储模式

文件系统 Markdown（hot/warm/daily/cold 四层）

LLM 调用

Ollama qwen3.5:9b（仅用于提取，其他纯 CPU）

触发方式

心跳 cron（默认每 30 分钟）

autoExtract

Node.js 脚本，直接读

 lcm.db 

原始消息，pattern matching 提取事实

2.2.2 核心子系统

WAL 协议（Write-Ahead Logging Protocol）

  • 核心思想：会话状态变更先写 WAL，再原子性提交
  • 纠正 3 次自动写入 learnings.md
  • Session 级隔离：session:all / session:<id> 双轨制
  • P0-SEC 路径安全：防止路径遍历攻击

autoExtract（自动提取）

  • 直接读 lcm.db SQLite 原始消息（绕过 memory-core 索引）
  • Pattern matching 提取四类事实：
    • 💡 决策：包含决定/选用/新建/修复/配置等关键词
    • 🔧 教训：包含教训/经验/踩坑等关键词
    • ✅ 完成：包含已完成/已创建/已修复等关键词
    • 📋 信息：版本号/error 报错/编译构建等
  • 循环引用修复：检查 proactive-tracker.md 的 resolved 状态
  • 文件系统验证：检查项目目录是否存在，避免过时信息
  • 写入 memory/agents/main/daily/YYYY-MM-DD.md

Consolidator（记忆合并）

  • 跨日记忆合并
  • 重复检测与去重
  • 事实一致性校验

CorrectionTracker（矛盾检测）

  • 检测记忆文件中的矛盾内容
  • 版本变更、端口变更、决策反转、路径变更等多种矛盾模式

ProactiveTracker（主动预判）

  • 维护 proactive-tracker.md
  • 逾期提醒、待回答问题追踪
  • 自动晋升机制

三、功能逐项对比

3.1 功能矩阵

功能项

builtin memory-core

builtin active-memory

builtin lossless-claw

memory-system

FTS5 全文搜索

✅

-

-

-

向量语义搜索

✅

-

-

-

Hybrid 混合搜索

✅

-

-

-

记忆文件索引

✅

-

-

-

memory_search/get 工具

✅

-

-

-

Pre-reply 阻塞注入

-

✅

-

-

子代理记忆检索

-

✅

-

-

6 种 Prompt 风格

-

✅

-

-

Session 级 on/off

-

✅

-

-

LCM 会话压缩

-

-

✅

-

lcm_grep/expand 工具

-

-

✅

-

增量 DAG 展开

-

-

✅

-

autoExtract 原消息提取

-

-

-

✅

WAL 协议

-

-

-

✅

纠正 3 次自动晋升

-

-

-

✅

多层记忆（hot/warm/daily/cold）

-

-

-

✅

记忆评分

-

-

-

✅

Consolidator 合并

-

-

-

✅

CorrectionTracker 矛盾检测

-

-

-

✅

ProactiveTracker 主动预判

-

-

-

✅

心跳 Cron 调度

-

-

-

✅

每日简报生成

-

-

-

✅

备份与恢复

-

-

-

✅

3.2 检索链路对比

Builtin active-memory 的检索链路：


对话消息
  → 组装 query（message/recent/full）
  → memory_search (SQLite FTS5 + Ollama 向量)
  → LLM 子代理生成摘要（15s timeout）
  → <active_memory_plugin> 注入 prompt
  → 主模型回复

memory-system 的检索链路：


lcm.db 原始消息（每 30 分钟）
  → autoExtract pattern matching
  → 写入 daily/*.md 文件
  → memory-core 监视文件变化（1.5s 防抖）
  → 自动重新索引
  → memory_search 可检索
  → 未来任何会话调用 memory_search 时召回

关键差异：

  • active-memory 是实时检索 → 注入当前回复
  • memory-system 是批量提取 → 写入文件 → 索引 → 供未来检索

四、性能对比

4.1 延迟分析

active-memory 延迟分解

阶段

耗时（典型）

备注

子代理启动 + 模型加载

500-2000ms

冷启动更慢

memory_search（Ollama 向量）

100-500ms

本地，但需网络到 Ollama

LLM 生成摘要

500-2000ms

MiniMax-M2.7

结果注入 + 主模型回复

额外 ~500ms

-

总用户感知延迟

1.6-5 秒/次

每次消息必发生

⚠️ 重要：这是用户必须等待的阻塞时间。每次用户发消息，系统额外等待 1.6-5 秒。

memory-system autoExtract 延迟分解

阶段

耗时（典型）

备注

心跳触发调度

<1ms

后台 cron

SQLite 读最近消息

50-200ms

本地 lcm.db

Pattern matching 提取

100-300ms

纯 CPU 正则

写 daily 文件

10-50ms

磁盘 IO

文件监视触发索引

1500ms（防抖）+ ~500ms

memory-core 自动

总耗时

~1.7-2.5 秒/次

用户零感知

✅ 关键：所有处理都在后台完成，用户完全无感知。

4.2 量化对比表

性能指标

active-memory

memory-system

胜者

单次触发用户延迟

1.6-5 秒

0ms（后台）

memory-system

每小时最大触发次数

~60 次（每小时 60 条消息）

2 次（每 30 分钟）

memory-system

LLM 调用次数/小时

~60 次

0 次

memory-system

Token 消耗/小时

高（子代理 prompt + 摘要）

0

memory-system

内存占用

子代理进程 + 模型上下文

脚本临时进程

memory-system

冷启动开销

高（每次 spawn 新 agent）

无

memory-system

4.3 资源消耗对比（假设每小时 30 条消息）

资源

active-memory

memory-system

LLM API 调用次数

30 次/小时

0 次/小时

Token 消耗

~2000 token/次 × 30 =

 6 万 token/小时

0

预估 API 费用（MiniMax）

¥2.16/小时

¥0

用户额外等待时间

60 秒/小时

0 秒

五、效率深度分析

5.1 信息流效率

active-memory 的信息流：


现有记忆文件（索引过的）
  → memory_search 检索
  → LLM 总结
  → 注入当前 prompt
  → 影响 1 次当前回复
  → 记忆本身不增加

memory-system 的信息流：


原始对话消息（lcm.db）
  → autoExtract 提取
  → 写入 daily/*.md
  → memory-core 自动索引
  → memory_search 可检索
  → 影响当前及**所有未来**回复

结论：从信息利用率角度，memory-system 的效率远高于 active-memory：

  • active-memory 提取的知识只服务 1 次当前对话
  • memory-system 提取的知识服务无限次未来对话

5.2 系统复杂度对比

维度

active-memory

memory-system

代码行数

~960 行（TypeScript）

~数千行（多模块）

进程模型

子代理（spawn）

Node.js 脚本

配置复杂度

高（6 种 prompt 风格，3 种 query mode）

中（pattern + cron）

Session 管理

完整（toggle、persistTranscripts）

通过 WAL 协议

Bug 修复

社区维护

自主维护（更快响应）

功能定制

受插件 API 限制

完全自主可控

六、场景适用性分析

6.1 何时使用 active-memory（ builtin）

场景

推荐理由

单会话质量优先

需要在

当前对话

中立即体现记忆效果

短时一次性咨询

用户问一个具体问题，需要快速调用相关记忆

实验性功能探索

评估内置能力，作为是否自研的参考

不适合：长时间多会话、注重 token 成本、需要多轮次累积记忆的场景。

6.2 何时使用 memory-system（自定义）

场景

推荐理由

长期记忆建设

提取的事实写入文件，供无数未来会话使用

多会话上下文连续性

跨越几十条消息的工程决策、教训、进度跟踪

低延迟对话体验

用户发消息立即响应，不等任何记忆处理

LLM 成本控制

零 token 消耗的记忆提取

深度定制需求

WAL 协议、矛盾检测、主动预判等自研能力

6.3 两者并存的可能性

技术上可行，但效率低下，不建议同时启用：

  • 延迟叠加：开 active-memory 会让每次消息变慢 1.6-5 秒
  • 信息重复：同一段对话被两个系统同时处理
  • 收益递减：active-memory 搜到的新记忆，恰好是 memory-system 刚写的

七、核心结论与建议

7.1 关键发现

  1. 架构层面无冲突：memory-system 是建立在 memory-core + lossless-claw 之上的编排层，不是替代品。
  2. active-memory 的核心代价：每次消息增加 1.6-5 秒用户延迟 + 高 Token 消耗，换来当前 1 次回复更好。
  3. memory-system 的核心优势：零用户延迟、零 LLM 成本、知识复用率极高（一次提取服务无数次未来会话）。
  4. 信息流效率差距巨大：active-memory 只服务 1 次当前对话；memory-system 服务无限次未来对话。

7.2 建议（当前状态）

组件

建议

理由

memory-core

✅ 保持启用

内置记忆后端，无可替代

lossless-claw

✅ 保持启用

LLM 压缩，摘要管理

memory-system

✅ 保持启用

核心记忆编排层

active-memory

❌ 保持禁用

延迟高、Token 消耗大、收益有限

memory-wiki

🔍 探索

知识保险库可能有价值

Honcho

🔍 探索

跨会话建模可能有价值

7.3 长期路线建议

  1. 继续深化 memory-system：WAL 协议、矛盾检测、主动预判是内置系统不具备的差异化能力
  2. 探索 memory-wiki：如果未来需要知识保险库功能，可以评估
  3. 保持 lossless-claw：会话压缩和上下文管理的最佳方案
  4. 不依赖 active-memory：除非产品方向转向即时咨询场景

八、附录

8.1 版本信息

组件

版本

备注

OpenClaw

v2026.4.11

2026-04-12 升级

memory-system

v4.0.0

自定义插件

lossless-claw

v0.8.0

内置 contextEngine

memory-core

stock v2026.4.11

内置 memory slot

active-memory

stock v2026.4.11

当前禁用

Ollama

本地部署

qwen3.5:9b / nomic-embed-text

向量模型

nomic-embed-text:latest

461MB，本地

8.2 配置参考

当前 memory-core 配置：

{
  "plugins": {
    "slots": { "memory": "memory-core" },
    "entries": {
      "memory-core": {
        "enabled": true,
        "config": { "dreaming": { "enabled": false } }
      }
    }
  },
  "agents": {
    "defaults": {
      "memorySearch": {
        "enabled": true,
        "provider": "ollama",
        "model": "nomic-embed-text:latest"
      }
    }
  }
}

当前 lossless-claw 配置：

{
  "plugins": {
    "slots": { "contextEngine": "lossless-claw" },
    "entries": {
      "lossless-claw": {
        "enabled": true,
        "config": {
          "summaryModel": "ollama/qwen3.5:9b",
          "summaryProvider": "ollama",
          "expansionModel": "ollama/qwen3.5:9b",
          "expansionProvider": "ollama",
          "freshTailCount": 64,
          "contextThreshold": 0.5,
          "incrementalMaxDepth": 1
        }
      }
    }
  }
}

没有要显示的评论

回到顶部