claude-mem — 最受欢迎的 Claude Code 持久记忆插件
来源: https://github.com/thedotmack/claude-mem
日期: 持续开发中(当前 v5.x)
评分: ⭐⭐⭐⭐⭐ (5/5 — 46K+ stars,Agent 记忆层最热门的开源方案,原生支持 OpenClaw)
官方文档: https://docs.claude-mem.ai/
OpenClaw 集成: https://docs.claude-mem.ai/openclaw-integration
关联报告
本报告与以下报告形成完整对照(建议一起阅读):
- Zilliz Memsearch — Zilliz 开源的 Markdown + Milvus 方案
- OpenClaw + QMD 记忆搜索引擎配置指南 — QMD 方案
一句话版本
Claude Code 最流行的记忆插件(46K+ GitHub Stars)——自动记录你每次编码会话中 Claude 做了什么、学到了什么,用 AI(Claude Agent SDK)压缩成结构化的"观察记录",下次启动时自动注入上下文。同时也支持 OpenClaw 和 Gemini CLI,安装只需一行命令。
核心架构
设计哲学
关键区别:claude-mem 在写入路径上使用 LLM 压缩。 这是它与 memsearch 和 QMD 最大的不同。
Claude Code 每次工具调用 → 钩子捕获原始数据 → 发送给 Worker 服务
↓
Claude Agent SDK 压缩
(提取结构化学习成果)
↓
SQLite 数据库存储
(sessions + observations + summaries)
↓
下一会话启动 → 从 SQLite 读取 → 注入系统提示词
技术栈
| 层 | 技术 |
|---|---|
| 语言 | TypeScript (ES2022) |
| 运行时 | Node.js 20+ / Bun |
| 数据库 | SQLite 3 + FTS5 |
| 向量搜索 | Chroma(可选,用于语义搜索) |
| AI 压缩 | @anthropic-ai/claude-agent-sdk(或 Gemini/OpenRouter) |
| HTTP 服务 | Express.js 5 |
| 实时推送 | Server-Sent Events (SSE) |
| Web UI | React + TypeScript |
存储结构
存储在 ~/.claude-mem/claude-mem.db(SQLite),不是 Markdown 文件。这也是一个关键区别——不可直接编辑。
OpenClaw 集成(最相关)
安装: 一行命令
curl -fsSL https://install.cmem.ai/openclaw.sh | bash
事件生命周期
| OpenClaw 事件 | claude-mem 动作 |
|---|---|
| `before_agent_start` | 初始化 session,发送到 `POST /api/sessions/init` |
| `before_prompt_build` | 从 Worker 获取观察时间线,注入到系统提示词(缓存 60s) |
| `tool_result_persist` | 记录工具调用(跳过 `memory_` 前缀的工具,防递归) |
| `agent_end` | 提取最后一条回复,摘要 + 完成 session |
| `gateway_start` | 清空 session 跟踪和上下文缓存 |
系统提示词注入
关键设计选择: claude-mem 不写入 MEMORY.md 文件,而是通过 before_prompt_build 钩子将观察时间线以 appendSystemContext 形式注入系统提示词。MEMORY.md 仍然由 agent 自主管理用于长期记忆(决策、偏好、持久事实),观察时间线通过系统提示词送达。
Observation Feed(观察流)
可以将 agent 的学习过程实时推送到 Telegram / Discord / Slack / Signal / WhatsApp / LINE 等通道。每条消息格式:
🧠 Claude-Mem Observation
**Implemented retry logic for API client**
Added exponential backoff with configurable max retries...
与 memsearch 和 QMD 的核心对比
| 维度 | claude-mem | memsearch | QMD |
|---|---|---|---|
| Stars | **46K+** ⭐ | 新项目 | 个人项目 |
| 开发者 | thedotmack(个人) | Zilliz(公司) | tobi(个人) |
| 写入路径 | **LLM 压缩**写入 SQLite | 纯追加 Markdown | 纯追加 Markdown |
| 存储格式 | SQLite(不透明) | **Markdown**(人类可读) | **Markdown** |
| 搜索方式 | FTS5 + Chroma(可选) | Dense + BM25 + RRF | BM25 + Dense + LLM rerank |
| 向量后端 | Chroma(可选) | Milvus(Lite→Cloud) | sqlite-vec |
| 注入方式 | 系统提示词 `appendSystemContext` | memory_search 工具(按需) | MCP 工具(按需) |
| OpenClaw 集成 | OpenClaw 事件系统插件 | 原生 TS 插件 `kind: memory` | MCP 协议 |
| Web UI | 有(localhost:37777) | 无 | 无 |
| 跨平台 | Claude Code + Gemini + OpenCode + OpenClaw | Claude Code + OpenClaw + Codex + OpenCode | 通用 MCP |
| 许可证 | 专有(查看 LICENSE) | MIT | MIT |
claude-mem vs lossless-claw
claude-mem 和我们现有的 lossless-claw 在理念上有根本区别:
| claude-mem | lossless-claw | |
|---|---|---|
| **写入时机** | 每次工具调用后立即发送给 Worker 压缩 | 会话结束时或心跳触发时摘要 |
| **写入内容** | LLM 压缩的观察记录(可能丢失细节) | 原始消息 + 分层摘要 DAG(无损) |
| **读取方式** | 系统提示词注入(被动接收) | 按需工具调用(主动检索) |
| **所有权** | 闭源(SQLite 不可编辑) | 开源(Markdown + 摘要 DAG,完全可控) |
关键权衡: claude-mem 牺牲了读写的精确控制换取自动化便利性——Agent 启动时自动注入上下文,但你不确定它注入了什么。lossless-claw 给了你完整的控制权和可审计性。
v5 关键特性
- mem-search Skill(v5.4+):10 种搜索操作,比 MCP 节省 ~2,250 tokens/session
- Progressive Disclosure:三层(Search → Timeline → Get Observations)
- Endless Mode(实验性):beta 通道,无限上下文模式
- Citations:每个 Observation 有 ID,可通过 Worker API 获取原始内容
- Observation Feed:实时推送到消息通道
- Context 缓存:每项目 60 秒缓存,避免每次 LLM 轮次重新获取
与我们项目的关联
1. 最高的社区认可是最大优势 — 46K+ stars 意味着这是很多人的默认记忆方案。我们做 Agent 记忆层,必须理解 claude-mem 为什么这么受欢迎。
2. 他们的核心假设和我们相反 — claude-mem 认为"LLM 压缩写入"是好的(用 AI 提取结构化学习成果),而我们认为 append-only + 无损摘要 DAG 才是正确的方向。这可以看作"便利"vs"精确"的哲学分歧。
3. 值得参考的设计:
- Observation Feed 推送到消息通道——将 Agent 学习过程透明化的好思路
- 系统提示词注入(vs MCP/工具调用)——更主动的上下文注入,但代价是不可控的 token 消耗
- 分层渐进披露的设计思路和我们一致
4. 风险:闭源 SQLite 格式意味着一旦大量依赖,数据可移植性受限。
评分
| 维度 | 评分 | 说明 |
|---|---|---|
| 社区热度 | ⭐⭐⭐⭐⭐ | 46K+ stars,生态最大 |
| 实用性 | ⭐⭐⭐⭐⭐ | 安装即用,一行命令 |
| 文档质量 | ⭐⭐⭐⭐⭐ | Mintlify 文档极完善 |
| OpenClaw 集成 | ⭐⭐⭐⭐⭐ | 原生支持,一行安装 |
| 与控制权 | ⭐⭐⭐ | 闭源 SQLite,LLM 压缩可能丢失细节 |
| 与我们关联 | ⭐⭐⭐⭐⭐ | 最重要的竞品/参考方案 |
综合:5/5 — 作为"即插即用型"Agent 记忆方案,claude-mem 是目前的最优解。但它的设计哲学(LLM 压缩写入 + 闭源 SQLite)与我们(无损 + 开源 Markdown)有根本分歧。建议继续走我们的路线,但吸收它的自动化便利性设计。