Auto-sync: 2026-04-28 12:03
This commit is contained in:
@@ -1,68 +1,76 @@
|
||||
---
|
||||
title: "I Went Through Every AI Memory Tool I Could Find. There Are Two Camps."
|
||||
type: source
|
||||
tags: [ai-agent, memory, context-management, tooling]
|
||||
tags: [AI-Agent, Memory-Tools, Context-Management, Agentic-AI]
|
||||
sources: []
|
||||
last_updated: 2026-04-23
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/AI-Memory-Tools-Two-Camps.md]]
|
||||
- [[Agent/AI-Memory-Tools-Two-Camps.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI 记忆工具的全景分类——揭示该领域存在两个根本不同的技术路线
|
||||
- 问题域：AI Agent 的持久化上下文问题——如何让 Agent 跨会话保持记忆
|
||||
- 方法/机制：Camp 1（记忆后端）通过向量提取+检索解决事实召回；Camp 2（上下文基质）通过文件累积+背景整合实现上下文复合增长
|
||||
- 结论/价值：提出了"记忆"与"上下文"不是同一问题的核心洞察；预测 6 个月内"context engineering"将取代"memory"成为主流术语；ALIVE 是作者实际运行的上下文基质方案
|
||||
- 核心主题：AI Agent 记忆工具的全景分类——作者系统梳理了 450+ 个 GitHub 仓库，将 AI 记忆工具划分为两个根本不同的范式阵营
|
||||
- 问题域：AI Agent 如何在多会话、长时间运行的场景中保持上下文连续性
|
||||
- 方法/机制：提出 Memory Backend（记忆后端）和 Context Substrate（上下文基质）两大阵营的分类框架
|
||||
- 结论/价值：Camp 1 工具解决"事实召回"问题；Camp 2 工具解决"上下文累积复合"问题；长期运行的 Agent 需要 Context Substrate 架构；"Context Engineering"将取代"Memory"成为主流术语
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Camp 1 与 Camp 2 是两个根本不同的技术范式，而非同一问题的不同实现
|
||||
- Camp 1 工具优化目标是**召回**：能否找到正确的事实
|
||||
- Camp 2 工具优化目标是**复合**：系统是否随时间变得更好
|
||||
- Zep 将品牌定位从"memory"重塑为"context engineering"是市场上最强的信号，表明 Camp 2 路线正在成为主流
|
||||
- GitHub 上 450+ repos 标记"agent-memory"、460+ 标记"context-management"，但几乎无人明确区分这两种范式
|
||||
- 持续运行的 24/7 Agent 场景下，只有 Camp 2 架构才能真正实现跨会话复合增长
|
||||
- 作者系统梳理了 450+ 个 GitHub 仓库，将 AI 记忆工具划分为两个根本不同的范式阵营
|
||||
- Camp 1（Memory Backend）：从对话中提取事实，存入向量数据库，检索相关事实——问的是"AI 应该记住什么？"
|
||||
- Camp 2（Context Substrate）：维护结构化、人类可读的上下文，跨会话累积——问的是"AI 应该在什么上下文中工作？"
|
||||
- Camp 1 工具的共同循环：对话发生 → 系统提取事实或存储内容 → 事实进入数据库（向量、图或两者） → 下一对话，检索并注入相关事实
|
||||
- Camp 2 工具的共同循环：Agent 工作前读取结构化上下文 → Agent 在上下文中工作 → Agent 或后台进程写回结构化上下文 → 下一会话，上下文比之前更丰富
|
||||
- Camp 1 优化的是召回（recall）：系统能否找到正确的事实？
|
||||
- Camp 2 优化的是复合（compounding）：系统是否随时间变得更好？
|
||||
- Zep 从"Memory"全面重新品牌定位为"Context Engineering"，这是整个领域最强的市场信号
|
||||
- 作者预测：6 个月内，"Context Engineering"将取代"Memory"成为严肃 Agent 基础设施的默认术语
|
||||
|
||||
## Key Quotes
|
||||
> "there are 450+ repos tagged 'agent-memory' on github and 460+ tagged 'context-management.' me and my agentic best friends went through them." — @witcheer，揭示该领域分类混乱的现状
|
||||
> "the line from their docs that defines the philosophy: 'the model only remembers what gets saved to disk, there is no hidden state.'" — OpenClaw 定义了 Camp 2 的核心哲学
|
||||
> "a funded company with 4.4k stars looked at where the space was going and decided 'memory' was the wrong word for what they were building." — Zep 的品牌重塑是市场信号
|
||||
> "within 6 months, 'context engineering' replaces 'memory' as the default term for what serious agent infrastructure does." — 作者的核心预测
|
||||
> "if you're building agents that need to run for more than one conversation, you're going to end up here." — Camp 2 是长期运行 Agent 的必然归宿
|
||||
> "the model only 'remembers' what gets saved to disk, there is no hidden state." — OpenClaw 官方文档，定义 Context Substrate 的核心哲学
|
||||
> "memory is not RAG." — Supermemory 的核心差异化定位
|
||||
> "Context Cores" — TrustGraph 引入的便携、带版本的知识容器，可类比代码进行版本控制、测试和回滚
|
||||
> "ALIVE (alivecontext.com)" — 作者正在使用的 Context Substrate 项目，结构化上下文基质、文件原生、Agent 无关
|
||||
|
||||
## Key Concepts
|
||||
- [[Memory Backend]]：从对话中提取事实，存入向量数据库，检索时召回。代表工具：Mem0、MemPalace、Supermemory、Honcho、Cognee。核心问题：记忆是扁平条目，无关系；提取质量依赖 LLM prompt；事实不进化
|
||||
- [[Context Substrate]]：维护结构化、人类可读的上下文文件，跨会话累积。代表工具：OpenClaw、Zep、Thoth、TrustGraph、MemSearch、ALIVE。核心哲学："nothing gets extracted — the context is the files"
|
||||
- [[Fact Recall]] vs [[Compounding]]：Camp 1 优化召回精度，Camp 2 优化复合增长；前者问"AI 应该记住什么"，后者问"AI 应该在什么样的上下文中工作"
|
||||
- [[Dreaming Cycle]]：OpenClaw 的背景整合过程——light sleep（分组）→ REM（频繁访问提升）→ deep sleep（写入长期记忆），六维评分机制（相关性0.30、频率0.24、查询多样性0.15、时效性0.15、整合度0.10、概念丰富度0.06）
|
||||
- [[Temporal Knowledge Graph]]：Zep 的 Graphiti 框架使用带 valid_at/invalid_at 时间戳的知识图谱，自动提取关系，返回预格式化上下文块，<200ms 检索
|
||||
- [[Context Core]]：TrustGraph 引入的可移植、带版本控制的上下文捆绑包（领域schema+知识图谱+向量嵌入+证据来源+检索策略），将上下文视为第一公民制品
|
||||
- [[Context Engineering]]：作者预测将取代"memory"成为描述 Agent 基础设施的标准术语
|
||||
- [[Memory-Backend]]：从对话中提取事实并存储到向量数据库的工具范式；代表工具：Mem0、MemPalace、Supermemory；核心问题是"事实召回"
|
||||
- [[Context-Substrate]]：维护结构化、人类可读上下文，跨会话累积，不提取事实而是让上下文成为文件本身的工具范式；代表工具：OpenClaw、Zep、Thoth、TrustGraph；核心问题是"上下文复合"
|
||||
- [[Context-Engineering]]：由 Zep 重新品牌化引入的术语，代表从"Memory"向"Context Substrate"方向的范式转移
|
||||
- [[Dream-Cycle]]：OpenClaw 和 Thoth 采用的后台知识整合机制——夜间多阶段过程将日常笔记整合为长期记忆
|
||||
- [[Context-Cores]]：TrustGraph 引入的概念，便携、带版本的上下文容器，包含领域 schema、知识图谱、向量嵌入、证据来源和检索策略
|
||||
- [[Fact-Recall-vs-Compounding]]：Camp 1 优化召回精度（96%+），Camp 2 优化随时间的复合增长能力
|
||||
|
||||
## Key Entities
|
||||
- [[Mem0]]：53.1k stars，Camp 1 类别领导者，四操作（add/search/update/delete），三层存储（user/session/agent），混合检索，集成简单但记忆为扁平条目，无关系推理
|
||||
- [[MemPalace]]：46.2k stars，本地优先逐字记忆，用 ChromaDB 组织为 wings（实体）/rooms（主题）/drawers（原内容），LongMemEval 96.6% 召回率但线性增长无压缩
|
||||
- [[Supermemory]]：21.8k stars，差异化是时序感知（"I moved to SF"自动取代旧城市），expired facts 自动遗忘，MemoryBench 声称第一，多模态连接器（Google Drive/Gmail/Notion/GitHub）
|
||||
- [[Honcho]]：2.4k stars，将人/Agent 视为统一模型中的"对等体"，异步推理服务推导心理洞察，PostgreSQL + pgvector，AGPL-3.0
|
||||
- [[OpenClaw]]：358k stars，plain markdown 文件（Mmemory.md + daily notes + DREAMS.md），无向量数据库，dreaming 三阶段整合，Camp 2 典型代表
|
||||
- [[Zep]]：4.4k stars，从"memory"重塑品牌为"context engineering"，Graphiti 时序知识图谱，SOC2 Type 2 + HIPAA 合规，<200ms 检索，架构上处于两 Camp 边界
|
||||
- [[Thoth]]：145 stars，最深层架构，10 实体类型 + 67 有向关系类型 + FAISS + 图扩展检索，四阶段夜间 dream cycle，三层反污染机制防止跨实体事实混淆
|
||||
- [[TrustGraph]]：2.0k stars，Context Cores 可移植版本化上下文容器，treats context like code，Cassandra + Qdrant 基础设施
|
||||
- [[MemSearch]]：1.2k stars，Zilliz 团队出品，Markdown 文件为唯一真相，Milvus 为下游"阴影索引"，三层层级渐进披露（语义块→完整章节→原始记录）
|
||||
- [[ALIVE]]：作者实际运行的方案，structured context substrate，file-native，agent-agnostic，walnuts 作为可移植上下文容器，零基础设施依赖，运行在 Hermes Agent + Claude Code + Mac Mini M4 上
|
||||
- [[Mem0]]（53.1k stars）：Camp 1 类别领导者，四操作（add/search/update/delete），三层级存储（user/session/agent），依赖提取质量
|
||||
- [[MemPalace]]（46.2k stars）：本地优先，逐字记忆，Wings/Rooms/Drawers 组织结构，LongMemEval 基准 96.6% 纯语义搜索召回率
|
||||
- [[Supermemory]]（21.8k stars）：时间感知，自动覆盖过期事实，声称在 LongMemEval/LoCoMo/ConvoMem 排名第一，提出 MemoryBench 基准
|
||||
- [[Honcho]]（2.4k stars）：将人和 Agent 视为统一模型中的对等体，后台异步推理服务推导心理洞察，PostgreSQL + pgvector
|
||||
- [[OpenClaw]]（358k stars）：Camp 2 代表，MEMORY.md + 每日笔记 + DREAMS.md 架构，"无隐藏状态"哲学，Dreaming 三阶段整合机制
|
||||
- [[Zep]]（4.4k stars）：从"Memory"重新品牌为"Context Engineering"，TKG 时间知识图谱（Graphiti），valid_at/invalid_at 时间戳，SOC2/HIPAA 合规
|
||||
- [[Thoth]]（145 stars）：10 种实体类型 + 67 种有向关系类型，FAISS + 图扩展，Dream Cycle 四阶段，90 天置信度衰减，反污染三层机制
|
||||
- [[TrustGraph]]（2.0k stars）：引入 Context Cores，将上下文视为代码（版本控制/测试/回滚），Cassandra + Qdrant 实现
|
||||
- [[MemSearch]]（1.2k stars）：Markdown 优先，Milvus 作为"影子索引"，文件是真相来源，向量搜索只是访问层
|
||||
- [[ALIVE]]（alivecontext.com）：作者 @witcheer 正在使用的 Context Substrate 项目，文件原生，Agent 无关，核桃作为便携上下文容器
|
||||
- [[@witcheer]]：Twitter/X 作者，24/7 Mac Mini M4 Agent 设置运营者，独立完成全景分析
|
||||
|
||||
## Connections
|
||||
- [[RAG]] ← related_to ← [[Memory Backend]]：两者共享向量检索的基本机制，但 RAG 通常指一次性问答场景，Memory Backend 指跨会话累积
|
||||
- [[OpenClaw]] ← implements ← [[Context Substrate]]：OpenClaw 的 Markdown 文件架构是 Context Substrate 范式的典型实现
|
||||
- [[Semantic-Memory-Search]] ← extends ← [[OpenClaw]]：MemSearch 为 OpenClaw 的 Markdown 记忆提供语义搜索能力
|
||||
- [[Memory Backend]] ← evolves_into ← [[Context Substrate]]：Supermemory 的时序感知和 Honcho 的心理建模代表了 Camp 1 向 Camp 2 的演进趋势
|
||||
- [[Second Brain]] ← uses ← [[Context Substrate]]：[[Second Brain]] 基于 OpenClaw 的累积记忆能力，本质上是 Context Substrate 范式在个人知识管理中的应用
|
||||
- [[养龙虾5天血泪史]] ← experiences ← [[OpenClaw]]：实战中暴露了 OpenClaw 记忆压缩和检索的痛点，推动了对 Context Substrate 架构的深入理解
|
||||
- [[Context Substrate]] ← enables ← [[Self-Improving-Skill]]：Self-Improving 的复盘机制（[[养虾日记2]]）是 Context Substrate 中背景整合思想的实践
|
||||
- [[Mem0]] ← 属于 ← [[Memory-Backend]]
|
||||
- [[MemPalace]] ← 属于 ← [[Memory-Backend]]
|
||||
- [[Supermemory]] ← 属于 ← [[Memory-Backend]]
|
||||
- [[Honcho]] ← 属于 ← [[Memory-Backend]]
|
||||
- [[OpenClaw]] ← 属于 ← [[Context-Substrate]]
|
||||
- [[Zep]] ← 属于 ← [[Context-Substrate]]
|
||||
- [[Zep]] ← 重新品牌化 ← [[Context-Engineering]]
|
||||
- [[Thoth]] ← 属于 ← [[Context-Substrate]]
|
||||
- [[TrustGraph]] ← 引入 ← [[Context-Cores]]
|
||||
- [[OpenClaw]] ← 实现 ← [[Dream-Cycle]]
|
||||
- [[Thoth]] ← 实现 ← [[Dream-Cycle]]
|
||||
- [[Memory-Backend]] ← 优化目标 ← [[Fact-Recall-vs-Compounding]]
|
||||
- [[Context-Substrate]] ← 优化目标 ← [[Fact-Recall-vs-Compounding]]
|
||||
- [[Context-Engineering]] ← 预测将取代 ← [[Memory-Backend]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[semantic-memory-search]] 可能存在张力：
|
||||
- 冲突点：MemSearch（Camp 2）将向量索引视为文件的下游"阴影索引"，可随时重建；[[semantic-memory-search]] 则将向量搜索作为记忆检索的核心能力
|
||||
- 当前观点：向量索引是可选的访问加速层，Markdown 文件才是唯一真相
|
||||
- 对方观点：向量语义搜索是必要的，单纯的关键词/Markdown 文件无法高效处理"我上周讨论的那个关于 X 的内容"
|
||||
- 注：两者其实互补——MemSearch 本身也使用混合搜索，但强调文件优先而非索引优先
|
||||
- 与 [[ALIVE]] 对比：
|
||||
- 冲突点：ALIVE 声称是 Context Substrate，但文档未详细说明其具体架构实现细节
|
||||
- 当前观点：ALIVE 是作者认为最有效的 Context Substrate 方案（因为在 24/7 设置中成功运行）
|
||||
- 对方观点：现有 Wiki 中 ALIVE 页面可能缺少与其他 Camp 2 工具（OpenClaw/Thoth/Zep）的架构对比
|
||||
|
||||
Reference in New Issue
Block a user