---
template: sheet
theme: shadcn
title: Mnemosyne v2.4.0 与 hy-memory 结构对比
subtitle: 一个是会话级 RAG 记忆插件，一个是记忆引擎 —— 分层不同
cols: 3
source: astrbot_plugin_mnemosyne v2.4.0 · hy-memory SDK 1.2.21 + 插件 0.2.6
---
两者不在同一层。Mnemosyne 把「对话窗口」压成一条向量记录，够用、开箱即用、带管理面板；hy-memory 把记忆当数据管线做，抽取、调和、演进、图谱、多存储，代价是常驻进程和复杂度。

## A 结论

```callout info 一句话差别
Mnemosyne 记的是**总结**：每 N 轮把对话压成一段文本，存向量，语义相近就召回。
hy-memory 记的是**事实**：抽取原子记忆、去重合并成演进链、挂实体图谱，检索时混合召回再重排。
```

从代码看，Mnemosyne 的 `ConversationContextManager` 就是「in-memory 对话窗口 + 轮数/时间阈值」；hy-memory 有独立的 `extractor / reconciler / reflector / summarizer` 四段写入管线。这是产品定位差，不是水平差。

## B 定位与寄主

| 维度 | Mnemosyne v2.4.0 | hy-memory |
|---|---|---|
| 寄主 | AstrBot 插件（聊天机器人平台） | Hermes 记忆 provider（`kind: exclusive`）+ MCP/HTTP server |
| 记忆单元 | 一轮或数轮对话的 LLM 总结 | 抽取出的原子事实，带演进链与实体关系 |
| 写入触发 | 轮数阈值（默认 5）、时间阈值、显式「记住」、LLM 工具 | 5 个生命周期 hook（prefetch / sync_turn / on_session_end / on_pre_compress / on_memory_write） |
| 检索 | 稠密相似度 top_k=3 + 过滤 | BM25 + 向量 + RRF 融合 + 去重 + 强度衰减 + 演进链展开 |
| 隔离维度 | session / persona / participant / 平台黑名单 | user / agent 命名空间 |
| 模式 | 无 | lite / pro / ultra（ultra 加图谱） |

Mnemosyne 的多租户过滤比 hy-memory 细：人格、会话、发言用户、平台黑名单四层，这是群聊场景逼出来的。hy-memory 面向单机单人 agent，只有 user/agent 两级。

## C 写入路径

```flow LR
(对话轮次) -> (达到 num_pairs 阈值) : Mnemosyne
(达到 num_pairs 阈值) -> (LLM 总结)
(LLM 总结) -> (Embedding)
(Embedding) -> (Chroma / Milvus / Qdrant / Weaviate) : 一条记录
```

```flow LR
(每轮消息) -> (extractor 抽事实) : hy-memory
(extractor 抽事实) -> (reconciler 合并冲突)
(reconciler 合并冲突) -> (演进链 / 实体图)
(演进链 / 实体图) -> (向量库 + 图库 + SQLite)
```

两者本质不同。Mnemosyne 存摘要，回答「哪段对话最像」。hy-memory 存状态，回答「这件事现在是什么」。所以后者能答「偏好变了没有」，前者答不了。

## D 检索路径

| 环节 | Mnemosyne | hy-memory |
|---|---|---|
| 召回 | 单路稠密向量 top_k | 稠密 + 稀疏（BM25 多实现）+ 融合 RRF |
| 过滤 | persona / session / participant / 平台 | 命名空间 + 时间与强度 |
| 重排 | 可选轻量图谱（实体关系 one-hop 扩展） | scoring + dedup + intent 路由 + 演进链 |
| 注入 | user_prompt 或独立系统消息，prepend / append | provider 的 prefetch 结果直接进上下文 |

Mnemosyne 的 `use_lightweight_memory_graph` 是「便宜的一档重排」，不存图库；hy-memory 是真图库（Kuzu / Neo4j），重得多。

## E 存储与运行形态

| 项 | Mnemosyne | hy-memory |
|---|---|---|
| 向量库 | Chroma 默认（本地持久化），可切 Milvus Lite/Standalone、Qdrant、Weaviate | Chroma / FAISS / Qdrant / 腾讯 |
| 图库 | 无（只在内存里做 one-hop 重排） | Kuzu / Neo4j |
| 结构化缓存 | 无独立层 | SQLite / MySQL + history store |
| 运行形态 | 与 AstrBot 同进程，FastAPI 面板 8000 端口 | 独立进程 19527 端口 + 独立 venv + RSS 守护 |
| 嵌入来源 | 宿主的 Embedding Provider | `core/embed_service.py`，可换 embedder，有缓存 |

```callout warn 与你的容器约束相关
hy-memory 是常驻独立进程，代码 4.2 MB、约 4.5 万行，还带 RSS guard 和每日整理脚本。容器 cgroup 只有 900M 左右时，这是需要盯的成本；Mnemosyne 同进程内嵌 Chroma，没有额外进程。
```

## F 体量对比

```chart bar horizontal unit=千行
| 代码量
hy-memory SDK | 45
Mnemosyne v2.4.0 | 24
hy-memory Hermes 插件 | 3
```

Mnemosyne 44 个 Python 文件约 2.4 万行（含 12 个测试文件，其中一个重排测试就 1277 行）。hy-memory SDK 102 个文件、4.55 万行，另有 Hermes 侧插件 2692 行。

测试面：Mnemosyne 自报 `106 passed / 6 skipped`，有 1 个既有失败与本次发布无关。hy-memory 侧无对应公开数字，不作比较。

## G Mnemosyne 值得借的四点

- **轻量图谱档位**：不用图库、只在内存里做 one-hop 实体扩展当重排。hy-memory 的图检索只有「有/无」两态，缺一个便宜档。
- **记忆检查器**：面板里直接改一条记忆、保存时自动重嵌入。hy-memory 只有 CLI 和 inspector，改记忆要手动。
- **维度迁移一键**：`/memory init --force` 换 embedder 后自动备份文本、按新维度重建。hy-memory 换 embedder 的迁移成本明显更高。
- **多租户过滤**：persona / participant / 平台黑名单三层。单机 agent 用不上，但一旦多入口（飞书 + 本地 + cron）共享记忆池，这层就是刚需。

## H hy-memory 的代价

```callout err 实话
它买的是能力，付的是复杂度和常驻内存。真正的问题不是「哪个更强」，而是「你现在需不需要事实级记忆」。
```

- 独立性：与 Hermes 强绑定，换平台要重写 provider 层。
- 故障面：管线有 embed、去重、合并、图谱、缓存五个环节，近期你踩过 embedding 缓存和索引的内存问题。
- 可观测：有 metrics / inspector / doctor，但没有 Mnemosyne 那种可视化面板。
- 结论：**不要为了对比而改结构**。Mnemosyne 的写入触发与检查器逻辑值得抄；它的存储与检索对 hy-memory 是降级。

未核实：Mnemosyne 图谱重排的打分公式；hy-memory 换 embedder 有没有现成迁移脚本。这两项只看了目录与 README，没逐行读实现。