AI记忆工具深度解析：内存后端与上下文工程的两大阵营

GitHub 上有超过 450 个标记为 "agent-memory" 的仓库，以及 460 多个标记为 "context-management" 的仓库。我和我的 Agent 助手们浏览了这些内容，以了解整个行业的现状。

我原本期望发现几十个使用不同 API 但功能大致相同的工具。实际上我发现的是两种截然不同的范式，而且几乎没有人区分它们，其中一个类别甚至还没有名字。

在 Mac Mini M4 上运行一个 24/7 全天候运行的 Agent 设置，且每个会话都在前一个会话的基础上进行累积，这让这种分歧变得显而易见。大多数 Memory 工具无法支持我正在做的事情，而那些能够支持的工具根本没有被作为 Memory 工具来讨论。

两个阵营

• Camp 1: Memory Backends – 这些工具从对话中提取事实，将其存储在向量数据库中，并在提示时检索相关内容。它们充当自动记事员，将东西归档并在需要时调取。
• Camp 2: Context Substrates – 这些维护结构化的、人类可读的 Context，并跨会话进行累积。没有任何东西是被“提取”的；Context 本身就是文件。Agent 阅读这些文件，在其中工作，并写回这些文件，从而让工作随时间产生复利效应。

Camp 1 问：“AI 应该记住什么？” Camp 2 问：“AI 应该在什么样的 Context 中工作？”

虽然该领域的大多数工具都属于 Camp 1，但 Camp 2 才是能够扩展到持续性、多会话、多项目工作的架构出现的地方。

Camp 1: Memory Backends

Mem0 (53.1k stars)

按采用率计算的类别领导者。它使用四种操作——添加、搜索、更新、删除——从对话中提取事实。它在三个层面（用户、会话、Agent）存储这些事实，并通过混合搜索进行检索。它易于集成，但受限于扁平化的条目以及事实之间缺乏演进的关系。

MemPalace (46.2k stars)

一个本地优先的逐字 Memory 工具。它不是提取事实，而是逐字存储对话，并将其组织成“侧翼”（实体）、“房间”（主题）和“抽屉”（原始内容）。它拥有极高的检索召回率（通过 LLM 重排序可达 99%+），但呈线性扩展，这使得它更适合查找特定的过往陈述，而不是管理当前的项目状态。

Supermemory (21.8k stars)

通过声明“Memory 不是 RAG”来定位自己。它的区别在于时间感知——新信息可以取代旧事实。它包括 Google Drive、Gmail、Notion 和 GitHub 的连接器，并将事实视为不断演变的而非永久的。

Honcho (2.4k stars)

在架构上与众不同，Honcho 将人类和 Agent 视为“同行 (peers)”。异步推理服务推导心理洞察，以构建用户思维方式的模型，而不仅仅是他们说了什么。它需要更繁重的底层设施，如 PostgreSQL 和 pgvector。

其他 Camp 1 工具

• Cognee (15.4k): 将向量搜索与图数据库相结合。
• Memori (13.3k): 拦截 LLM API 调用以捕获执行 Context。
• AgentScope, MemOS, EverOS, MIRIX, SimpleMem, Memobase: 提取-检索循环的各种迭代。

Camp 1 的共同点

该阵营中的每个工具都遵循相同的循环：

1. 对话发生。
2. 系统提取事实或存储内容。
3. 事实进入数据库（向量、图或两者兼有）。
4. 在下一次对话中，检索并注入相关事实。

这种方法解决了特定事实召回的问题：“关于 X 我说了什么？”或“用户的偏好是什么？”

Camp 2: Context Substrates

OpenClaw (358k stars)

OpenClaw 使用纯 Markdown 文件进行 Memory 管理：MEMORY.md 用于长期存储，每日笔记用于运行中的 Context，DREAMS.md 用于合并。没有隐藏状态；模型只“记得”保存在磁盘上的内容。它使用一个“做梦”后台进程，通过轻度睡眠、REM 和深度睡眠阶段将每日笔记合并到长期 Memory 中。

Zep (4.4k stars)

Zep 最近从“Memory”更名为“Context Engineering”。它使用时间知识图谱 (Graphiti)，其中的事实包含有效性时间戳。它返回为 LLM 消费而优化的预格式化 Context 块，标志着从单纯的存储转向管理 Context。

Thoth (145 stars)

一个复杂的项目，构建了一个具有 10 种实体类型和 67 种关系的个人知识图谱。它具有每晚四个阶段的做梦周期，用于重复合并、丰富、关系推理和置信度衰减。它将 Context 视为一种严肃的、结构化的资产。

TrustGraph (2.0k stars)

引入了“Context Cores”——包含模式 (schemas)、图 (graphs)、嵌入 (embeddings) 和策略 (policies) 的便携式、版本化捆绑包。它像对待代码一样对待 Context，可以进行版本控制、测试和回滚。这允许一个 Agent 立即继承完整的操作 Context。

MemSearch (由 Zilliz 提供) (1.2k stars)

一个 Markdown 优先的 Memory 系统，其中 .md 文件是事实来源。向量索引 (Milvus) 充当访问的“影子索引”。这种方法优先考虑人类可读、版本可控的文件，而不是以数据库为中心的存储。

Camp 2 的共同点

Camp 2 的循环有所不同：

1. Agent 在工作前读取结构化的 Context。
2. Agent 在该 Context 中工作。
3. Agent（或后台进程）写回结构化的 Context。
4. 下一次会话的 Context 变得更加丰富。

Camp 1 优化的是召回（找到正确的事实），而 Camp 2 优化的是复利（系统随时间变得更好）。

未来展望与正在进行的工作

Memory 和 Context 不是同一个问题。Agent 不仅仅需要记住偏好；它需要在一个由活跃项目、决策和历史组成的 Context 中运行，而这个 Context 每天都在变得更加丰富。

虽然 Memory Backends 非常适合简单的召回，但对于持续运行并执行复杂工作的 Agent 来说，Context Substrate 方法是必要的。我预测，“Context Engineering”将在未来六个月内取代“Memory”，成为严肃的 Agent 基础设施的标准术语。

我目前正在开发 ALIVE，这是一个文件原生且与 Agent 无关的结构化 Context Substrate。它使用 "walnuts" 作为便携式 Context 容器——这些纯文件可以在没有繁重基础设施依赖的情况下产生复利效应。这种方法正是让我的 24/7 设置能够真正跨会话工作，而不是每次都重置的原因。

如果你正在构建旨在运行超过单次对话的 Agent，你最终将需要一个 Context Substrate。

• 原文链接： x.com/witcheer/status/20...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～