Memory Provider 横向研究：MemPalace / Mem0 / Supermemory / Honcho

调研日期: 2026-05-01 调研目的: 四大 memory provider 源码级横向对比，输出 Meridian/Vyane MemoryStore 设计建议 对齐 issue: MER-196（记忆层升级 Epic）、MER-302（测试子任务） 证据等级: 源码阅读 + 官方文档 + 独立社区评测 + benchmark 复现报告

---

一、项目概览对比

维度	MemPalace	Mem0	Supermemory	Honcho
GitHub Stars	50.5k	54.5k	22.3k	3.1k
首次提交	2026-04-05	2023-06-20	2024-02	~2024
许可证	MIT	Apache 2.0	MIT（客户端）	AGPL-3.0
核心语言	Python	Python + TS	TypeScript	Python
融资	无（开源项目）	$24M Series A	$2.6M Seed	$5.35M Pre-Seed
存储后端	ChromaDB	26 种向量 DB	PG + pgvector（闭源）	PG + pgvector + Redis
开源程度	完全开源	核心开源（Graph Memory 移至商业版）	伪开源（核心引擎闭源）	完全开源
LLM 依赖	可选（规则式提取为主）	必需（事实提取 + 检索）	必需（闭源后端）	必需（三个 agent pipeline）
自部署	pip install 即用	Docker 三件套	仅 Enterprise	Docker Compose 四服务
维护活跃度	高（日更，但项目仅 1 个月）	高（3 年积累）	高（周更）	高（日更）

---

二、架构深度对比

2.1 存储哲学

项目	存储单元	写入策略	核心差异
MemPalace	Drawer（原始内容逐字存储）	规则式分块（800 char + 100 overlap），无 LLM 提取	不摘要、不改写，依赖语义搜索找回原文
Mem0	Memory（LLM 提取的原子事实）	LLM 提取关键事实 → embedding → 向量 DB	ADD-only 算法，新旧事实共存，保留变更历史
Supermemory	Profile（静态+动态用户画像）	自动提取 → 矛盾解决 → 画像合成（闭源）	用户画像驱动，不暴露原始记忆项
Honcho	Document（分层观察/结论）	三 agent pipeline：Deriver→Dreamer→Dialectic	渐进式知识构建，显式/演绎/归纳/矛盾四层分级

关键洞察：四个项目分布在"保真度 vs 抽象度"的光谱上。MemPalace 在保真度极端（存原文），Supermemory 在抽象度极端（只暴露画像），Mem0 和 Honcho 居中但侧重不同——Mem0 偏事实粒度，Honcho 偏推理链。

2.2 检索策略

项目	检索方式	延迟	Token 效率
MemPalace	BM25 + 向量混合（0.6:0.4）+ 可选 LLM rerank	未公开	L0+L1 ~170-900 tokens wake-up
Mem0	语义搜索 + BM25 + entity boost + reranker	7-8s（社区反馈）	<7,000 tokens/次（vs full-context 25,000+）
Supermemory	混合搜索（闭源实现）	sub-300ms	未公开
Honcho	Dialectic agent 工具化检索（prefetch + 按需搜索 + 推理链验证）	~200ms（context），chat 按推理级别	115K 输入 → ~12,650 tokens 实际使用（11%）

2.3 记忆分层模型

项目	分层方案	对应 ADR-003 scope
MemPalace	L0 Identity / L1 Essential Story / L2 On-Demand / L3 Deep Search（token 加载层级）	正交维度：MemPalace 切的是"加载多少"，ADR-003 切的是"可见范围"
Mem0	Semantic / Episodic / Procedural（认知科学三分法）	可映射但不直接对应：session≈Episodic，agent≈Semantic，project/org 需额外 namespace
Supermemory	Working / Episodic / Semantic / Procedural（四层认知模型）	类似 Mem0，多了 Working Memory 对应 session
Honcho	explicit / deductive / inductive / contradiction（推理置信度层级）	正交维度：Honcho 切的是"知识确定性"，不是"可见范围"

对 Vyane 的启示：ADR-003 的四层 scope（session/agent/project/org）切的是可见性和生命周期，与上述项目的分层维度正交。Vyane 需要同时支持两个维度：scope 决定"谁能看"，type/level 决定"是什么性质的记忆"。

2.4 知识图谱/实体关系

项目	图能力	实现方式	评价
MemPalace	时序三元组 + 实体关系	SQLite（entities + triples 表），带 valid_from/valid_to	简陋但实用。无图遍历、无实体消解、无矛盾检测
Mem0	Entity Linking（原 Graph Memory 已移至商业版）	向量 DB 中的并行 {collection}_entities 集合	开源版降级了——从 Neo4j/Memgraph 退到 entity linking
Supermemory	关系类型（update/extend/derive 等）	闭源	不可评估
Honcho	Observer-Observed 模式 + Document source_ids 推理链	PostgreSQL 关系型 + Collection 双向建模	最有设计深度——推理链可追溯，矛盾显式标记

---

三、Benchmark 横向对比

基准测试	MemPalace	Mem0	Supermemory	Honcho	说明
LongMemEval R@5	96.6% (raw) / 98.4% (hybrid)	93.4%	85.4%	90.4%	MemPalace 领先，但有 overfitting 争议
LoCoMo R@10	60.3% (raw) / 88.9% (hybrid)	91.6%	未公开具体分	89.9%	Mem0 新算法大幅提升
ConvoMem	92.9%	未公开	声称第一	未公开	数据不足以对比
BEAM	未测	未测	未测	顶级（到 10M 才下降）	仅 Honcho 测了

Benchmark 可信度评估：

• MemPalace 的 100% 宣称已撤回（teaching to the test），96.6% raw 分数经独立复现确认真实
• Mem0 的新算法 benchmark 来自自家博客，但有 arXiv 论文支撑（arxiv:2504.19413）
• Supermemory 声称三大 benchmark 第一，但已被 Hindsight 项目（MIT 开源）超越（89.0% → 91.4%）
• Honcho 的 benchmark 数据最透明，包含 token 效率分析

结论：单看 benchmark 数字意义有限——每家都在自己擅长的测试集上表现最好。更有意义的指标是 token 效率（同等召回率下消耗多少 token）和 延迟。

---

四、工程实践评估

4.1 可插拔性

项目	后端可插拔	LLM 可插拔	Embedding 可插拔
MemPalace	有 ABC 规范（RFC 001），通过 pyproject entry-points 注册。但目前只有 ChromaDB 一个实现	可选，默认无 LLM	支持 CUDA/CoreML/DML 加速，默认 all-MiniLM-L6-v2
Mem0	26 种向量 DB + 工厂模式	20+ LLM provider	14 种 embedding provider
Supermemory	闭源，不可评估	闭源	闭源
Honcho	PG + pgvector 为主，可选 Turbopuffer/LanceDB	3 种 transport（anthropic/openai/gemini）+ 兼容代理	OpenAI text-embedding-3-small 默认

对 Vyane：Mem0 的工厂模式最成熟但过度工程化（26 种后端大部分没人用）。MemPalace 的 ABC 规范设计得当但实现单一。Honcho 的 PG 统一方案最务实——关系数据 + 向量数据同库，简化运维。

4.2 MCP 集成

项目	MCP 工具数	实现方式	质量
MemPalace	29 个	JSON-RPC over stdio，Python 实现	有 stdout 重定向保护，工程细节考虑周到
Mem0	~5 个	mem0-mcp npm 包	基础 CRUD
Supermemory	~5 个	Cloudflare Worker	绑定云服务
Honcho	若干	TypeScript，Cloudflare Workers	功能完整

4.3 安全与隐私

项目	数据位置	隐私风险
MemPalace	完全本地	最低——零网络调用
Mem0	自托管可本地 / 云服务数据在远端	中等——有 telemetry，近期修复了 SQL 注入和 eval() 漏洞
Supermemory	数据必须经 api.supermemory.ai	最高——核心处理在云端，无法审计
Honcho	自托管可本地 / 云服务 app.honcho.dev	中等——AGPL 保证源码可审计

---

五、各项目独特贡献与借鉴价值

5.1 MemPalace：Token 经济性的极致

核心贡献：四层渐进加载（L0-L3），170 token wake-up 成本。

L0 Identity:       ~100 tokens（始终加载）
L1 Essential Story: ~500-800 tokens（始终加载，按 importance 排序取 top-15 drawer）
L2 On-Demand:      ~200-500/次（话题触发）
L3 Deep Search:    无限（显式语义搜索）

对 Vyane 的参考价值：

• wake-up 成本控制思路直接适用于 autoDream → context injection 环节
• importance 字段 + top-K 排序是 L1 层的关键，可映射到 MemoryEntry.importance
• 后端 ABC 规范（typed results、error hierarchy、capability declaration）值得参考

需警惕：

• 宫殿隐喻（Wings/Rooms）经独立分析证实对检索精度贡献有限，本质是 metadata filter
• verbatim 存储长期积累噪声，缺乏衰减/遗忘机制
• 项目仅 1 个月历史，519 个 open issues，稳定性未经验证

5.2 Mem0：最成熟的通用 Memory API

核心贡献：ADD-only 提取算法 + 多信号检索融合。

写入: 输入 → LLM 提取原子事实 → embedding → 向量 DB
检索: query → 语义搜索 + BM25 + entity boost → reranker → 阈值过滤
更新: ADD-only（新旧共存，保留变更历史）

新算法关键改进（2026-04）：

• 单次 LLM 调用完成提取（原来多次），降低 token 消耗
• Entity Linking 替代图数据库（实用主义简化）
• LoCoMo 从 71.4 跳到 91.6，时序查询 +29.6，多跳推理 +23.1

对 Vyane 的参考价值：

• MemoryType 三分法（Semantic/Episodic/Procedural）是成熟的认知科学分类框架
• ADD-only 策略保留完整变更历史——Vyane 的 MemoryEntry 可以借鉴，不做 in-place update
• Entity Linking 替代图数据库是务实选择——不需要 Neo4j 也能做实体关联
• 多信号融合（语义 + 关键词 + 实体）比纯向量检索更鲁棒

需警惕：

• 检索延迟 7-8s 在高频场景不可接受
• LLM 事实提取不总是准确（“讨厌蘑菇” vs “讨厌比萨上的蘑菇”）
• 开源版与商业版功能差距在拉大（Graph Memory 已从 OSS 移除）
• 近期有 SQL 注入和 eval() 安全修复，安全审计仍在追赶

5.3 Supermemory：用户画像自动合成

核心贡献：Static/Dynamic Profile 双画像模型 + 自动遗忘机制。

用户画像:
  ├── Static Profile:  不变事实（出生地、教育、偏好）
  └── Dynamic Profile: 频繁更新（当前项目、活动）

特色功能:
  ├── forgetAfter:     临时信息自动过期
  ├── 矛盾解决:        自动检测和处理矛盾信息
  └── 连接器生态:      Google Drive / Notion / Gmail / S3 / GitHub

对 Vyane 的参考价值：

• forgetAfter 遗忘机制——MemPalace 和 Mem0 都缺这个，MemoryEntry 的 valid_to 字段可以实现类似功能
• Static/Dynamic 画像分离——对应 ADR-003 中 org scope（相对稳定）vs session scope（频繁变化）
• 连接器架构思路——Vyane 的 autoDream 需要从多源（CC session/git/Linear）采集，可参考其 pipeline 设计

需警惕：

• 核心引擎闭源——GitHub 22.3k stars 容易误导，实际是客户端 + SDK wrapper
• 深度绑定 Cloudflare Workers，自部署仅 Enterprise
• 黑盒透明度差——开发者无法审计上下文选择逻辑
• 单人公司 + 种子轮，长期稳定性风险

5.4 Honcho：最有设计深度的推理式记忆

核心贡献：Peer Paradigm + 三 agent pipeline + 分层推理。

数据模型:
  Workspace → Peer（统一人/AI）→ Session ← 多对多 → Peer
  Collection（observer→observed）→ Document（分层观察）

三 agent pipeline:
  Deriver（摄入推理）: 消息 → explicit 原子事实提取
  Dreamer（后台整合）: explicit → deductive 推导 + inductive 归纳
  Dialectic（检索推理）: 查询 → prefetch → 工具化搜索 → 综合回答

Document 分层:
  explicit   → 直接事实（"用户说他喜欢 Python"）
  deductive  → 推理结论（"用户可能偏好动态类型语言"）
  inductive  → 归纳模式（"用户倾向选择开发效率高的工具"）
  contradiction → 矛盾标记（"用户之前说讨厌 JS，但最近在学 TypeScript"）

独特设计：

• Surprisal 采样：dreaming 阶段用 KD-tree 几何惊讶度过滤，找出"最出人意料"的观察作为探索起点——这在竞品中非常罕见
• Observer-Observed 双向建模：AI tutor 观察 student 和 student 观察 AI tutor 产生不同的 collection，建模"视角"概念
• 推理链可追溯：Document.source_ids 构成有向树，可沿推理链回溯到原始事实
• 5 级推理深度：minimal/low/medium/high/max，按需控制成本

对 Vyane 的参考价值：

• Deriver→Dreamer 异步管线 ≈ autoDream 的 Orient→Gather→Consolidate→Prune
• Document 四层分级比简单的 fact/preference 更精细——MemoryEntry.content_type 可以扩展
• Surprisal-based 探索对 autoDream 的 Consolidate 阶段有直接参考价值
• Observer-Observed 模式对多 agent 场景（Yi 观察 Maple、Developer 观察 codebase）有启发

需警惕：

• AGPL-3.0 对商业集成限制大（网络服务必须开源）
• 三个 LLM agent pipeline 的自托管成本不低
• 项目偏学术/愿景（crypto identity layer），实际用户规模有限

---

六、不确定性与证据空白

不确定项	说明	影响
Supermemory 核心算法	完全闭源，无法评估检索质量和用户画像合成逻辑	无法确定其 benchmark 成绩的可复现性
MemPalace 长期稳定性	项目仅 1 个月历史，HNSW 并行插入有 SIGSEGV bug	生产可用性存疑
Mem0 延迟问题根因	社区反馈 7-8s 延迟，但不清楚是 LLM 提取、向量搜索还是 reranker 的瓶颈	影响是否采用其检索策略
Honcho 3.0 规模验证	版本较新（2026 初），缺乏大规模生产环境数据	其三 agent pipeline 在高负载下的表现未知
Benchmark 可比性	各项目使用不同版本、不同配置跑 benchmark，无统一评测条件	数字对比仅供参考，不构成排名
Hindsight 项目	被 Supermemory 引用为后来者，MIT 开源，benchmark 超越 Supermemory（91.4%），但本次未深入调研	可能是更值得关注的新选手

---

七、Meridian/Vyane MemoryStore 设计建议

基于四个项目的横向对比和 ADR-003 v2 已有的 MemoryStore 概念定义，以下是具体设计建议。

7.1 存储层：PG + pgvector 统一方案（对齐 data-persistence-design.md）

推荐：沿用已有的 SQLite 统一存储决策，但参考 Honcho 的 PG + pgvector 方案为未来升级留口。

Phase 1 (autoDream MVP): SQLite + 文件混合（已有方案）
Phase 2 (Embedding):     SQLite → PG + pgvector（如果需要向量索引规模化）
                          或 SQLite + 外部向量 DB（ChromaDB/LanceDB）

理由：

• Honcho 证明了 PG 统一方案的可行性（关系数据 + 向量数据同库）
• MemPalace 的 ChromaDB 单一方案在 benchmark 上表现优异，说明早期不需要复杂后端
• Mem0 的 26 种后端是过度工程化的教训——先做好一个，再考虑可插拔

7.2 写入管线：规则式提取 + LLM 整合的两阶段方案

借鉴 Honcho 的 Deriver→Dreamer 分离和 MemPalace 的规则式提取：

Stage 1 — Deriver（实时，低成本）:
  CC session 消息 → 规则式提取（正则/关键词/结构化解析）→ explicit 级别 MemoryEntry
  类似 MemPalace 的规则式 room 分配和实体检测
  不需要 LLM，延迟低，可同步执行

Stage 2 — Dreamer（异步，autoDream）:
  explicit 条目积累到阈值 → LLM 整合（推导 + 归纳）→ deductive/inductive 级别条目
  类似 Honcho 的 Dreamer，但用 Vyane 已有的 Orient→Gather→Consolidate→Prune 四阶段
  可选 Surprisal 采样（Honcho 的 KD-tree 几何惊讶度）找出高信息增益的条目

7.3 MemoryEntry 扩展：增加 level 和 source_ids

在 mempalace-vyane-integration.md 已有的 MemoryEntry 基础上，增加两个字段：

@dataclass
class MemoryEntry:
    # --- 已有字段（保持不变）---
    id: str
    scope: Literal["session", "agent", "project", "org"]
    namespace: str
    topic: str
    content: str
    content_type: Literal["fact", "event", "discovery", "preference", "advice"]
    importance: float
    created_at: float
    valid_from: float | None
    valid_to: float | None          # 支持 Supermemory 式遗忘（forgetAfter）
    source_session: str | None
    source_agent: str | None
    embedding: list[float] | None
    metadata: dict[str, str]

    # --- 新增字段（借鉴 Honcho + Mem0）---
    level: Literal["explicit", "deductive", "inductive"]
        # 借鉴 Honcho：区分直接事实 vs 推理结论 vs 归纳模式
        # 检索时可按 level 过滤（只要 explicit？还是包含推理？）
    source_ids: list[str]
        # 借鉴 Honcho：推理链追溯。deductive/inductive 条目的 source_ids
        # 指向其推导来源的 explicit 条目，构成有向树
    superseded_by: str | None
        # 借鉴 Mem0 ADD-only：不做 in-place update，新条目写入时
        # 旧条目标记 superseded_by 指向新条目 ID

7.4 检索层：渐进式加载 + 混合检索

综合 MemPalace 的四层加载和 Mem0 的多信号融合：

Wake-up 加载（对标 MemPalace L0+L1，目标 <500 tokens）:
  L0: Agent identity + 当前 scope 的 org 级别高 importance 条目
  L1: 按 importance 排序取 top-K explicit 条目，按 topic 分组

按需检索（对标 L2+L3）:
  L2: 话题触发 → scope + topic 过滤 → metadata 检索
  L3: 显式语义搜索 → BM25 + 向量混合（参考 MemPalace 0.6:0.4 权重）
      + entity boost（参考 Mem0）
      + level 加权（explicit > deductive > inductive）

7.5 不建议做的事

不建议	理由	来源
照搬宫殿隐喻命名	Wings/Rooms 对检索精度贡献有限，ADR-003 的 scope 概念更清晰	MemPalace 独立评测
引入外部图数据库（Neo4j 等）	Mem0 已从开源版移除图 DB，Honcho 用 PG 关系型实现了推理链——够用	Mem0 架构变化
依赖 Supermemory 的闭源后端	核心引擎不可审计、绑定 Cloudflare、单人公司风险	Supermemory 分析
一开始就支持 26 种向量数据库	过度工程化，先做好 SQLite/PG 一个后端	Mem0 教训
纯 verbatim 存储不做任何提取	长期积累噪声，缺乏衰减机制	MemPalace 局限性
写入路径完全依赖 LLM	成本高、延迟大、提取不总是准确	Mem0 已知问题

7.6 推荐实施路径（对齐 MER-196 Phase 1-2）

MER-196 Phase 1 — autoDream MVP（预计 3-4 周）:
  1. MemoryEntry 数据结构落地（含 level、source_ids、superseded_by 新字段）
  2. 规则式 Deriver 实现（从 CC session JSONL 提取 explicit 条目）
  3. SQLite MemoryStore 写入/读取 API
  4. L0+L1 渐进加载实现（wake-up <500 tokens）
  5. autoDream Consolidate 阶段（LLM 整合 explicit → deductive）

MER-196 Phase 2 — Embedding + 向量检索（预计 6-8 周）:
  1. Embedding 计算（本地 all-MiniLM-L6-v2 或 Ollama）
  2. BM25 + 向量混合检索
  3. Entity Linking（Mem0 方式，不引入外部图 DB）
  4. valid_to 遗忘机制
  5. Surprisal 采样（可选，借鉴 Honcho）
  6. MCP 工具暴露（search_memory / add_memory / get_context）

---

八、推荐后续工作

1. Hindsight 项目深入调研 — MIT 开源，Docker 一键部署，benchmark 已超越 Supermemory（LongMemEval 91.4%），在本次调研中多次被提及但未深入。推荐优先级：高。
2. Mem0 新算法源码阅读 — 重点读 ADDITIVE_EXTRACTION_PROMPT 和 entity linking 实现，评估是否直接复用其 prompt 模板。
3. Honcho Deriver/Dreamer 源码阅读 — 重点关注异步队列实现和 Surprisal 采样的 KD-tree 部分，评估移植到 autoDream 的可行性。
4. MemPalace 后端 ABC 规范提取 — backends/base.py 的 typed results 和 error hierarchy 设计，可以作为 Vyane MemoryStore 接口规范的起点。
5. OpenMemory (CaviraOSS) 调研 — 多个对比文章提到的完全本地方案，与 Vyane 的隐私优先定位一致。
6. MemoryBench 统一评测 — 用 Supermemory 开源的 MemoryBench 框架对 Vyane MemoryStore 做标准化评测，建立基线。

---

附录 A：源码关键路径索引

MemPalace (github.com/MemPalace/mempalace)

文件	内容
mempalace/palace.py	宫殿操作核心
mempalace/layers.py	四层记忆栈 L0-L3
mempalace/searcher.py	BM25 + 向量混合检索
mempalace/knowledge_graph.py	SQLite 时序实体关系图
mempalace/backends/base.py	后端 ABC 规范（RFC 001）
mempalace/mcp_server.py	29 个 MCP 工具
mempalace/embedding.py	ONNX embedding 工厂

Mem0 (github.com/mem0ai/mem0)

文件	内容
mem0/memory/main.py	Memory 类核心（add/search/update/delete）
mem0/memory/base.py	MemoryBase 抽象
mem0/configs/prompts.py	FACT_RETRIEVAL_PROMPT / ADDITIVE_EXTRACTION_PROMPT
mem0/vector_stores/	26 种向量 DB 适配器
mem0/llms/	20+ LLM provider 适配器
mem0/embeddings/	14 种 embedding provider

Honcho (github.com/plastic-labs/honcho)

文件	内容
src/models.py	Peer/Session/Message/Collection/Document 数据模型
src/deriver/	Deriver agent（explicit 事实提取）
src/dreamer/	Dreamer agent（deductive/inductive 整合）
src/dialectic/	Dialectic agent（检索推理）
src/reconciler/	PG ↔ 外部向量存储同步
src/config.py	TOML + env 配置系统

---

附录 B：独立评测与社区反馈来源

来源	类型	关键发现
MemPalace Review (Substack)	独立评测	96.6% raw 真实，100% 宣称已撤回
Agentic Memory Analysis	源码分析	宫殿结构对检索贡献有限
danilchenko.dev Review	独立复现	“The 100% Score Was Fake. 96.6% Is Real”
Mem0 arXiv Paper	学术论文	新算法 benchmark 有同行评审
State of AI Agent Memory 2026 (Mem0 Blog)	行业报告	全景概览，有利益冲突但数据有参考价值
DEV: 5 Memory Systems Compared	社区对比	多维度对比，含代码示例
LogRocket: Mem0 vs Supermemory	开发者评测	侧重开发者体验对比
Plastic Labs: Benchmarking Honcho	官方 benchmark	含详细 token 效率分析
Variant Fund: Investing in Plastic Labs	投资分析	Honcho 的 identity layer 愿景