2.1 Mem0 —— 通用记忆层 ⭐25K#

Mem0 的思路很直觉：把记忆当成一个独立的中间件服务。

核心流程：

1
用户对话 → LLM 提取记忆片段 → 向量化存储 → 下次对话时语义检索 → 注入 prompt

1
from mem0 import Memory
2

3
m = Memory()
4

5
# 存：从对话中自动提取记忆
6
m.add("我喜欢用 Rust 写后端，讨厌 XML 配置", user_id="yangbo")
7

8
# 取：语义检索相关记忆
9
results = m.search("推荐一个后端框架", user_id="yangbo")
10
# → ["用户喜欢 Rust", "用户讨厌 XML 配置"]

优点： 开箱即用，自动提取，语义检索比关键词匹配强太多。

缺点： 依赖向量数据库（Qdrant/Chroma），记忆的”提取”依赖 LLM 判断（有时会提取出无关信息或遗漏关键信息），对于长期运行的 Agent 来说，记忆条目会膨胀到难以管理。

2.2 Letta/MemGPT —— 三层记忆 ⭐13K#

MemGPT（现在叫 Letta）的思路更有野心：模拟操作系统的虚拟内存机制。

它把记忆分成三层：

1
┌─────────────────────────────────────────┐
2
│  Core Memory（核心记忆）                  │
3
│  始终在 context 中，类似 CPU 寄存器       │
4
│  存：用户画像、系统指令、关键状态          │
5
├─────────────────────────────────────────┤
6
│  Recall Memory（回忆记忆）                │
7
│  对话历史的数据库，按需检索               │
8
│  类似内存 / RAM                          │
9
├─────────────────────────────────────────┤
10
│  Archival Memory（归档记忆）              │
11
│  长期知识库，向量检索                     │
12
│  类似硬盘 / SSD                          │
13
└─────────────────────────────────────────┘

核心思想： Agent 自己决定什么时候”翻页”——当 context 快满时，主动把不重要的内容存到外部存储，需要时再取回来。就像操作系统的 page fault：内存不够了，换页到磁盘。

优点： 理论上可以处理无限长的对话历史，Agent 有自主记忆管理能力。

缺点： 复杂。需要 Agent 学会调用 memory 工具函数，实际体验中经常出现”忘了该记住的”或”记了不该记的”。部署依赖也不轻——需要数据库、向量存储、额外的 LLM 调用。

2.3 Memori —— SQL-native 记忆基础设施#

Memori 走了另一条路：用结构化 SQL 来管理记忆，而不是纯向量检索。

思路是把记忆当成数据库表——有明确的 schema、可以 JOIN、可以做精确查询。比如”用户三天前提到的那个 API 地址”这种查询，用 SQL 比向量检索靠谱得多。

适合场景： 企业级、多用户、需要精确查询的场景。

不适合： 个人 Agent、快速原型。引入 SQL 基础设施对于轻量场景来说太重了。

2.4 小结#

看完这些方案，我的判断是：对于个人 Agent 场景，这些方案都太重了。 我不需要向量数据库，不需要额外的服务进程，我需要的是一个 简单、可维护、纯文件系统 的方案。

整体架构#

1
workspace/
2
├── MEMORY.md          ← L1 核心记忆（≤50行，每次必读）
3
├── memory/
4
│   ├── index.md       ← L2 索引（目录，知道什么信息在哪）
5
│   ├── project-A.md   ← L2 主题文件（按需加载）
6
│   ├── tech-stack.md  ← L2 主题文件
7
│   ├── 2026-04-07.md  ← L3 每日归档
8
│   ├── 2026-04-08.md  ← L3 每日归档
9
│   └── 2026-04-09.md  ← L3 每日归档（今天）

L1 核心记忆（Core）—— 始终在线#

规则：≤50 行，每次会话启动必读。

这是 Agent 的”身份证 + 速记卡”。存什么？

• 用户身份和偏好（“用户是开发者，偏好 Rust，讨厌 XML”）
• 当前进行中的关键任务
• 重要决策和约定
• 需要长期记住的规则

1
<!-- MEMORY.md 示例 -->
2
## 用户画像
3
- 开发者，全栈，偏好 TypeScript + Rust
4
- 有一台 4G 内存的 Ubuntu VPS，构建大项目需要 swap
5
- 博客用 Astro，代码托管 Gitee
6

7
## 当前任务
8
- 博客迁移到新主题（进行中）
9
- AI Agent 记忆系统优化（本周重点）
10

11
## 重要约定
12
- 部署前必须先在沙盒测试
13
- 不要在群聊里暴露服务器信息
14
- 用户不喜欢等太久，长任务用子 Agent 异步处理

为什么限制 50 行？ 因为这部分每次都要读，直接占用 context 窗口。50 行大约 1000-1500 token，是一个合理的固定开销。超过了就该下沉到 L2。

L2 工作记忆（Working）—— 按需加载#

规则：索引文件 + 主题子文件，提到才读。

索引文件 memory/index.md 是一个目录，告诉 Agent “什么信息在哪个文件里”：

1
<!-- memory/index.md 示例 -->
2
## 项目
3
- project-blog.md — 博客相关：主题、部署流程、历史问题
4
- project-tools.md — My Tools 站点：功能清单、部署方式
5

6
## 技术
7
- tech-stack.md — 技术栈偏好、选型记录
8
- infra.md — 服务器配置、域名、SSL
9

10
## 人际
11
- contacts.md — 常联系的人、沟通偏好

当用户说”帮我看看博客部署的问题”，Agent 看到 index 里有 project-blog.md，就加载它。不相关的文件完全不碰——零 token 开销。

这和 MemGPT 的 recall memory 异曲同工，只是检索方式从向量搜索变成了 人类可读的索引文件。简单粗暴，但在个人 Agent 场景下，效果出奇地好。

L3 归档记忆（Archive）—— 原始日志#

规则：每日一个文件，记录当天发生的一切。

1
<!-- memory/2026-04-09.md 示例 -->
2
## 2026-04-09
3

4
### 09:00 博客文章
5
- 写了一篇 AI Agent 记忆优化的文章
6
- 部署到 boke.hackerdream.xyz
7
- 构建时遇到 OOM，加了 swap 解决
8

9
### 14:30 服务器维护
10
- 更新了 nginx 配置
11
- SSL 证书还有 60 天过期，记得续

L3 是最”脏”的一层——什么都记，不做过滤。它的价值在于 可追溯性：三个月后你想知道”当时为什么选了这个方案”，翻日志就能找到。

但 L3 绝不应该每次都读。只有在需要回顾特定日期的上下文时才加载。

三层记忆的读取策略#

用伪代码表示 Agent 每次启动时的逻辑：

1
def on_session_start():
2
    # L1: 必读（固定开销 ~1000 token）
3
    core = read("MEMORY.md")
4

5
    # L2: 读索引（~200 token），但不读子文件
6
    index = read("memory/index.md")
7

8
    # L3: 只读今天的日志（获取最近上下文）
9
    today = read(f"memory/{date.today()}.md")
10

11
    return core + index + today  # 总共 ~2000 token
12

13
def on_user_message(msg):
14
    # 按需加载 L2 子文件
15
    if mentions_project(msg, "blog"):
16
        context = read("memory/project-blog.md")
17

18
    # 极少数情况才翻 L3 历史
19
    if asks_about_specific_date(msg):
20
        context = read(f"memory/{extract_date(msg)}.md")

启动成本约 2000 token，相比把所有历史对话塞进去（轻松 20000+ token），这是一个数量级的优化。

什么是蒸馏？#

类比人类学习：你每天上课记了一堆笔记（L3），周末整理成知识点（L2），考试前再浓缩成一页速记卡（L1）。

蒸馏 = 从原始日志中提取有价值的信息，合并到主题文件中。

蒸馏的触发时机#

我的实践是 每 3 天做一次蒸馏，可以用 cron 任务或者在 Agent 空闲时（heartbeat）自动执行：

1
def distill():
2
    # 1. 读取最近 3 天的 L3 日志
3
    logs = [read(f"memory/{d}.md") for d in last_3_days()]
4

5
    # 2. 用 LLM 提取有价值的信息
6
    prompt = f"""
7
    以下是最近 3 天的工作日志：
8
    {logs}
9

10
    请提取：
11
    1. 新的技术决策或发现
12
    2. 需要长期记住的用户偏好
13
    3. 项目进展和状态变更
14
    4. 踩过的坑和解决方案
15

16
    按主题分类输出。
17
    """
18
    insights = llm(prompt)
19

20
    # 3. 更新 L2 对应的主题文件
21
    for topic, content in insights:
22
        append(f"memory/{topic}.md", content)
23

24
    # 4. 如果有足够重要的信息，更新 L1
25
    if has_critical_update(insights):
26
        update("MEMORY.md", critical_items)

蒸馏示例#

L3 原始日志：

1
2026-04-07: 部署博客时 OOM 了，加了 2G swap 解决
2
2026-04-08: 又 OOM 了，swap 不够，改成 4G
3
2026-04-09: 博客构建稳定了，4G swap 是最低要求

蒸馏到 L2（infra.md）：

1
## 博客构建
2
- Astro 构建需要 4G+ swap（4G 物理内存不够）
3
- 不要在沙盒构建，只能在服务器上构建

提炼到 L1（MEMORY.md）：

1
- 博客构建必须在服务器上（需要 4G swap），沙盒会 OOM

三天的试错经验，浓缩成一行核心记忆。下次再遇到构建任务，Agent 直接就知道该怎么做，不用再踩一遍坑。

Token 消耗对比#

token 消耗降低约 50-70%，而且不会随着使用时间增长而膨胀——因为 L1 有 50 行硬限制，L2 按需加载，L3 虽然在增长但不会被读取。

信噪比提升#

全量历史的问题是：90% 的内容跟当前对话无关。模型的注意力被大量无关信息稀释，反而容易”忘记”重要的东西。

三层架构的 L1 是 纯信号（人工/蒸馏提炼过的），L2 是 高信号（按主题组织），只有 L3 是原始噪音——但 L3 平时不读。

实际体验：Agent 对用户偏好的遵守率明显提高，“我不是说过不要用 Java 吗”这种对话基本消失了。

可维护性#

半年后回头看：

• MEMORY.md 始终保持 50 行以内，干净利落
• memory/index.md 有十几个主题文件，结构清晰
• L3 日志积累了 180+ 个文件，但完全不影响性能（不读就不占资源）
• 任何人（包括未来的你）打开 workspace 都能快速理解整个记忆结构

这是纯文件方案最大的优势：人类可读、可编辑、可 git 管理。出了问题你可以直接打开文件看，不用去翻数据库。

继续用文件系统 ✅#

• 单用户 / 个人 Agent
• 记忆条目 < 1000 条
• 不需要复杂的语义检索（关键词 + 文件组织够用）
• 想保持简单、零依赖
• 需要人类直接编辑记忆

该上 SQLite 🗄️#

• 需要结构化查询（“最近 7 天提到过的所有项目名”）
• 记忆条目 1000 - 100,000
• 需要事务保证（多个 Agent 并发写入）
• 仍然想保持单文件部署的简洁

1
import sqlite3
2

3
db = sqlite3.connect("memory.db")
4
db.execute("""
5
    CREATE TABLE IF NOT EXISTS memories (
6
        id INTEGER PRIMARY KEY,
7
        topic TEXT,
8
        content TEXT,
9
        importance INTEGER DEFAULT 0,
10
        created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
11
        last_accessed TIMESTAMP
12
    )
13
""")
14

15
# 按重要性 + 相关性检索
16
memories = db.execute("""
17
    SELECT content FROM memories
18
    WHERE topic = ?
19
    ORDER BY importance DESC, last_accessed DESC
20
    LIMIT 10
21
""", ("blog",)).fetchall()

该上向量数据库 🔍#

• 需要真正的语义检索（“跟微服务架构相关的所有记忆”）
• 记忆条目 > 100,000
• 多模态记忆（文本 + 图片 + 代码）
• 多用户场景，需要隔离

该上 MySQL/PostgreSQL 🏢#

• 多 Agent 协作，需要强一致性
• 企业级场景，需要审计日志
• 与现有业务数据库集成

我的建议：从文件系统开始，遇到瓶颈再升级。 过早引入数据库是最常见的过度工程——你的 Agent 可能永远也不需要处理十万条记忆。