Generated by Answer me with HTML 0.5.7 · 2026-10-23 18:00 · ★ Star on GitHub
Mnemosyne v2.4.0 与 hy-memory 结构对比
一个是会话级 RAG 记忆插件，一个是记忆引擎 —— 分层不同
两者不在同一层。Mnemosyne 把「对话窗口」压成一条向量记录，够用、开箱即用、带管理面板；hy-memory 把记忆当数据管线做，抽取、调和、演进、图谱、多存储，代价是常驻进程和复杂度。
结论
Mnemosyne 记的是总结：每 N 轮把对话压成一段文本，存向量，语义相近就召回。 hy-memory 记的是事实：抽取原子记忆、去重合并成演进链、挂实体图谱，检索时混合召回再重排。
从代码看，Mnemosyne 的 ConversationContextManager 就是「in-memory 对话窗口 + 轮数/时间阈值」；hy-memory 有独立的 extractor / reconciler / reflector / summarizer 四段写入管线。这是产品定位差，不是水平差。
定位与寄主
| 维度 | 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 两级。
写入路径
两者本质不同。Mnemosyne 存摘要，回答「哪段对话最像」。hy-memory 存状态，回答「这件事现在是什么」。所以后者能答「偏好变了没有」，前者答不了。
检索路径
| 环节 | 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），重得多。
存储与运行形态
| 项 | 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，有缓存 |
hy-memory 是常驻独立进程，代码 4.2 MB、约 4.5 万行，还带 RSS guard 和每日整理脚本。容器 cgroup 只有 900M 左右时，这是需要盯的成本；Mnemosyne 同进程内嵌 Chroma，没有额外进程。
体量对比
数据
| 代码量 | |
|---|---|
| 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 侧无对应公开数字，不作比较。
Mnemosyne 值得借的四点
- 轻量图谱档位：不用图库、只在内存里做 one-hop 实体扩展当重排。hy-memory 的图检索只有「有/无」两态，缺一个便宜档。
- 记忆检查器：面板里直接改一条记忆、保存时自动重嵌入。hy-memory 只有 CLI 和 inspector，改记忆要手动。
- 维度迁移一键：
/memory init --force换 embedder 后自动备份文本、按新维度重建。hy-memory 换 embedder 的迁移成本明显更高。 - 多租户过滤：persona / participant / 平台黑名单三层。单机 agent 用不上，但一旦多入口（飞书 + 本地 + cron）共享记忆池，这层就是刚需。
H hy-memory 的代价
它买的是能力，付的是复杂度和常驻内存。真正的问题不是「哪个更强」，而是「你现在需不需要事实级记忆」。
- 独立性：与 Hermes 强绑定，换平台要重写 provider 层。
- 故障面：管线有 embed、去重、合并、图谱、缓存五个环节，近期你踩过 embedding 缓存和索引的内存问题。
- 可观测：有 metrics / inspector / doctor，但没有 Mnemosyne 那种可视化面板。
- 结论：不要为了对比而改结构。Mnemosyne 的写入触发与检查器逻辑值得抄；它的存储与检索对 hy-memory 是降级。
未核实：Mnemosyne 图谱重排的打分公式；hy-memory 换 embedder 有没有现成迁移脚本。这两项只看了目录与 README，没逐行读实现。