77 lines
6.3 KiB
Markdown
77 lines
6.3 KiB
Markdown
---
|
||
title: "I Went Through Every AI Memory Tool I Could Find. There Are Two Camps."
|
||
type: source
|
||
tags: [AI-Agent, Memory-Tools, Context-Management, Agentic-AI]
|
||
sources: []
|
||
last_updated: 2026-04-15
|
||
---
|
||
|
||
## Source File
|
||
- [[raw/Agent/AI-Memory-Tools-Two-Camps.md]]
|
||
|
||
## Summary（用中文描述）
|
||
- 核心主题：AI Agent 记忆工具的全景分类——作者系统梳理了 450+ 个 GitHub 仓库，将 AI 记忆工具划分为两个根本不同的范式阵营
|
||
- 问题域：AI Agent 如何在多会话、长时间运行的场景中保持上下文连续性
|
||
- 方法/机制：提出 Memory Backend（记忆后端）和 Context Substrate（上下文基质）两大阵营的分类框架
|
||
- 结论/价值：Camp 1 工具解决"事实召回"问题；Camp 2 工具解决"上下文累积复合"问题；长期运行的 Agent 需要 Context Substrate 架构；"Context Engineering"将取代"Memory"成为主流术语
|
||
|
||
## Key Claims（用中文描述）
|
||
- 作者系统梳理了 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
|
||
> "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；核心问题是"事实召回"
|
||
- [[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）：本地优先，逐字记忆，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
|
||
- [[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
|
||
- 与 [[ALIVE]] 对比：
|
||
- 冲突点：ALIVE 声称是 Context Substrate，但文档未详细说明其具体架构实现细节
|
||
- 当前观点：ALIVE 是作者认为最有效的 Context Substrate 方案（因为在 24/7 设置中成功运行）
|
||
- 对方观点：现有 Wiki 中 ALIVE 页面可能缺少与其他 Camp 2 工具（OpenClaw/Thoth/Zep）的架构对比
|