claudemem 记忆机制

2026-03-25

4

作者编辑

下面基于该项目 **claude-mem** 的公开设计与常见实现模式，给你做一个**结构化拆解**。  
由于你给的是仓库链接、没有附带仓库文档正文，我这里会基于该项目的功能定位和这类“给 Claude/LLM 增加长期记忆”的典型架构来说明它的**记忆机制是怎么做的**。如果你愿意，我后面也可以继续帮你**逐文件读 repo**，把真实代码实现细化到函数级别。

---

# 一句话总结

**claude-mem 的核心思路通常是：把对话中的“可长期保留信息”提炼出来，存到外部记忆存储里；在后续对话时，再按相关性把这些记忆检索回来，拼进 prompt，让模型看起来像“记住了你”。**

也就是说，它不是模型参数真的更新了，而是：

> **对话提取 → 结构化存储 → 检索召回 → 注入上下文**

---

# 记忆机制的本质

大模型本身在 API 调用里默认是**没有跨会话长期记忆**的。  
像 `claude-mem` 这种项目，本质上是在模型外面包了一层“记忆系统”。

它一般分成两类记忆：

| 记忆类型 | 作用 | 典型内容 |
|---|---|---|
| 短期记忆 | 当前会话上下文 | 最近几轮聊天、当前任务状态 |
| 长期记忆 | 跨会话保留用户信息 | 用户偏好、身份信息、长期项目、习惯、约束 |

---

# 它通常是怎么工作的

可以把它理解成 5 个步骤：

## 1. 从对话里判断“什么值得记住”

不是每句话都要存。  
系统通常会从用户输入或对话中提炼出以下类型的信息：

- **用户画像**
  - 比如：用户是后端工程师
  - 用户在北京
  - 用户喜欢简洁回答
- **偏好**
  - 喜欢中文
  - 讨厌太长的解释
  - 默认用 TypeScript 示例
- **长期任务 / 项目**
  - 正在做一个 AI Agent 项目
  - 正在准备面试
- **事实性约束**
  - 公司技术栈是 Python + PostgreSQL
  - 不使用云服务
- **关系型信息**
  - 同事、团队、产品名称、仓库名称等

这一步一般有两种实现方式：

### 方式 A：规则提取
比如匹配：

- “我喜欢……”
- “请以后……”
- “我目前在做……”
- “记住……”

### 方式 B：让模型自己总结
给 Claude 一个 prompt：

> 请从这段对话中提取值得长期记忆的信息，输出 JSON。

例如输出：

```json
[
  {
    "type": "preference",
    "content": "用户偏好中文回答",
    "confidence": 0.95
  },
  {
    "type": "project",
    "content": "用户正在开发一个AI agent项目",
    "confidence": 0.88
  }
]
```

**claude-mem 这类项目通常更偏向这种做法**：  
让模型扮演“记忆提取器”，把自然语言压缩成结构化 memory。

---

## 2. 把记忆存到外部存储

提取出来的内容不会只存在当前 prompt，而是写到一个持久层。  
常见存储方式有：

| 存储方式 | 用途 |
|---|---|
| SQLite / JSON 文件 | 简单本地持久化 |
| PostgreSQL | 结构化管理 |
| 向量数据库 | 做语义检索 |
| 混合存储 | 元数据存在 DB，embedding 存在向量库 |

如果这个项目比较轻量，常见实现会是：

- 本地文件
- SQLite
- 可能加 embedding 索引

记忆对象通常会长这样：

```json
{
  "id": "mem_001",
  "user_id": "user_123",
  "type": "preference",
  "content": "用户喜欢用中文交流",
  "created_at": "2025-03-24T10:00:00Z",
  "updated_at": "2025-03-24T10:00:00Z",
  "source": "chat",
  "importance": 0.9
}
```

---

## 3. 为记忆建立检索能力

如果只是“存起来”，其实没什么用。关键是**下次能找回来**。

通常会有两种检索方式：

## 3.1 关键词 / 标签检索
比如记忆有类型、标签：

- preference
- project
- profile
- instruction

用户问到“继续昨天的项目”，系统就优先找 `project` 类记忆。

## 3.2 向量检索（语义搜索）
这是更常见、更像现代记忆系统的方式。

做法：

1. 把 memory 文本转成 embedding
2. 新问题也转 embedding
3. 做相似度搜索
4. 找出最相关的几条记忆

例如：

- 记忆里有：  
  “用户正在开发一个使用 LangGraph 的 AI agent”
- 用户新问题：  
  “我那个 agent 的状态机怎么拆？”

即使没提到完全相同关键词，也能通过语义相似度召回。

---

## 4. 在回答前，把相关记忆注入 prompt

这一步最关键。  
模型之所以“看起来记得”，是因为系统在调用 Claude 时，把检索到的记忆一并发过去。

比如系统 prompt 可能会被增强成：

```text
你正在与该用户继续对话。以下是已知长期记忆：

1. 用户偏好中文回答
2. 用户喜欢简洁、结构化输出
3. 用户正在开发一个 AI agent 项目，使用 LangGraph
4. 用户后端主要使用 Python

请在不生硬重复这些记忆的前提下，利用它们帮助回答。
```

这样 Claude 就会：

- 自动用中文
- 倾向简洁
- 回答 agent 问题时带上 LangGraph 背景
- 给 Python 示例

所以它的“记忆”其实是**检索增强上下文（retrieval-augmented context）**，不是模型自己学会了。

---

## 5. 记忆更新、合并、去重

成熟一点的记忆系统不只是“追加”，还会做：

- **去重**
  - “用户喜欢中文”
  - “默认用中文回复”
  - 其实是一条记忆
- **冲突更新**
  - 旧记忆：用户在上海
  - 新记忆：用户搬到深圳了
  - 要覆盖旧值
- **权重衰减**
  - 很久没提到的偏好降低权重
- **重要性排序**
  - 明确说“以后都用中文”比“随便都行”更重要

所以它通常会有一个 memory management 逻辑：

| 操作 | 含义 |
|---|---|
| add | 新增记忆 |
| update | 更新已有记忆 |
| merge | 合并相似记忆 |
| archive | 归档旧记忆 |
| delete | 删除错误记忆 |

---

# 一个典型的数据流

下面用流程图思维描述：

## 用户发来消息
> “我最近在做一个 Rust 写的 CLI 工具，以后代码示例尽量给 Rust。”

## 系统处理
### A. 正常回答用户问题
先让 Claude 回答眼前问题。

### B. 并行做记忆提取
提取出两条长期信息：

- 用户正在做 Rust CLI 项目
- 用户偏好 Rust 代码示例

### C. 存储
写入 memory store。

### D. 下次用户问
> “帮我设计一下配置加载模块”

系统检索到：

- Rust CLI 项目
- 偏好 Rust 示例

### E. 注入 prompt
Claude 就会直接从 Rust CLI 角度回答。

---

# 它大概率包含的几个核心模块

如果你去看 `claude-mem` 代码，通常会看到这些模块职责：

## 1. Memory Extractor
负责从对话中提炼记忆。

可能是：

- 一个 prompt 模板
- 一个 JSON schema
- 一个调用 Claude 的函数

---

## 2. Memory Store
负责持久化。

可能封装成：

- `save_memory(...)`
- `get_memories(user_id)`
- `update_memory(...)`
- `delete_memory(...)`

---

## 3. Memory Retriever
负责召回最相关记忆。

可能有：

- embedding 生成
- similarity search
- top-k 返回
- 按类型过滤

---

## 4. Prompt Augmenter
负责把记忆拼到 system prompt 或 context 里。

---

## 5. Memory Manager
负责冲突解决、合并、排序、去重。

---

# 它和 RAG 的关系

本质上，**这就是一种面向“用户信息/对话历史”的 RAG**。

普通 RAG：

- 检索知识库文档
- 给模型补外部知识

claude-mem：

- 检索“关于这个用户/这个长期任务”的记忆
- 给模型补个体化上下文

可以理解成：

$$
\text{Answer} = \text{LLM}(\text{current query} + \text{chat history} + \text{retrieved memories})
$$

---

# 它不是怎么做的

为了避免误解，这类系统**通常不是**下面这些方式：

## 不是训练了一个有记忆的新模型
没有真的微调出“长期记住你”的参数。

## 不是把所有历史对话永远塞进上下文
上下文窗口有限，而且成本太高。

## 不是简单聊天记录回放
它会做“摘要化、结构化、筛选化”的记忆，而不是原样堆积。

---

# 这种设计的优点

## 优点

- **跨会话持久**
- **可控**
  - 可以删、改、审计
- **成本低**
  - 不必把全部历史都发给模型
- **更个性化**
  - 用户偏好、长期项目能持续生效

---

# 这种设计的难点

## 难点 1：记什么，不记什么
如果全记，会污染上下文。  
如果记太少，又体现不出长期记忆。

## 难点 2：错误记忆
模型提取错了，就会“越记越偏”。

## 难点 3：冲突处理
用户以前喜欢 A，现在改成 B，要不要覆盖？

## 难点 4：检索质量
相关记忆没召回，系统就像失忆；  
不相关记忆召回太多，系统就像胡乱联想。

## 难点 5：隐私与安全
长期存用户信息，必须考虑：

- 用户是否知情
- 是否支持删除
- 是否加密
- 是否区分敏感信息

---

# 如果用一句更工程化的话描述

可以这样概括 `claude-mem` 的记忆机制：

> **它通过 LLM 从对话中抽取可持久化的用户事实/偏好/任务状态，存入外部记忆库，并在后续请求前根据当前查询检索最相关的记忆，再将其注入 Claude 的上下文中，从而模拟长期记忆。**

---

# 如果你想看代码，重点找这些东西

你打开 repo 后，可以优先搜这些关键词：

## 关键文件/关键词
- `memory`
- `store`
- `extract`
- `retrieve`
- `embedding`
- `vector`
- `prompt`
- `session`
- `context`
- `save`
- `recall`

## 特别关注
### 1. 记忆抽取 prompt
看看它怎么判断“值得记住的信息”。

### 2. 存储层
看看是：

- JSON
- SQLite
- Postgres
- Chroma / LanceDB / FAISS / pgvector 等

### 3. 检索策略
看看是：

- 纯关键词
- embedding 相似度
- 混合检索

### 4. 注入方式
看看它把 memory 放在：

- system prompt
- user prompt 前缀
- tool context
- hidden scratchpad

### 5. 更新策略
看看有没有：

- dedupe
- overwrite
- confidence score
- decay / recency

---

# 我对这个项目机制的高概率还原

如果让我高度概括 `claude-mem` 这种项目的实现，**大概率是下面这个范式**：

```text
对话输入
  ↓
Claude/LLM 提取长期记忆候选
  ↓
结构化保存（文件/数据库/向量库）
  ↓
新对话到来时做语义检索
  ↓
取 top-k 记忆
  ↓
拼接到 prompt
  ↓
Claude 生成更“连续”的回答
```

---

# 你如果只想知道“核心原理”，就记住这 4 点

## 核心四点

1. **记忆不在模型里，在外部存储里**
2. **记忆来自对话提炼，而不是原样保存全部聊天**
3. **回答前会检索相关记忆**
4. **检索到的记忆会被放进 prompt，模型因此表现得像“记得你”**

---

# 如果你愿意，我可以继续帮你做两件事之一

## 选项 A：我直接按仓库真实代码帮你拆
你把 repo 里的这些文件内容贴给我，我可以逐个分析：

- README
- memory 相关模块
- store / db 相关模块
- prompt 模板
- 检索逻辑文件

我会告诉你：
- 它**实际上用了哪种存储**
- 是否用了 embedding
- 是如何做去重/更新的
- prompt 是怎么拼的

## 选项 B：我给你画一个“claude-mem 记忆机制架构图”
我可以直接输出一版 markdown + ASCII 架构图，帮你秒懂整体实现。

如果你愿意，我下一条可以直接给你：

> **“claude-mem 记忆机制源码级拆解框架”**  
或者  
> **“我帮你把这个 repo 的记忆链路画成图”**

Python

博客信息

作者 eeettt

发布日期 2026-03-25

其他信息 : 其他三字母的人名首字母都是其他同学发布的哦