harness技术手册-AI 记忆的两种范式：从向量检索到上下文积累¶

Ch01.1120 harness技术手册-AI 记忆的两种范式：从向量检索到上下文积累¶

📊 Level ⭐⭐ | 5.5KB | entities/harness技术手册-ai-记忆的两种范式从向量检索到上下文积累.md

harness技术手册-AI 记忆的两种范式：从向量检索到上下文积累¶

来源: Unknown

发布日期: 2026-04-17

原文链接: https://mp.weixin.qq.com/s/Zr4MPCWCNGV9hyYTBwguKQ

GitHub 上，450 多个仓库被标记为"智能体记忆"，460 多个仓库被标记为"上下文管理"。表面看，这是一个工具泛滥的领域——人们可能预期会看到几十个功能相似、只是接口不同的产品。但深入其中会发现，这里存在着两种根本不同的技术范式，而业界尚未清晰地区分它们。

第一种范式被称为 记忆后端 。这类系统从对话中提取事实片段，将其编码后存入向量数据库，在需要时检索相关内容。它们的工作模式类似于自动化的笔记系统：将信息归档存储，并在查询时召回。核心问题是："AI 应该记住什么？"

第二种范式是 上下文基底 。这类系统不追求"提取"或"编码"，而是维护结构化、人类可读的上下文文件，这些文件在多次会话中持续积累。AI 直接读取这些文件，在其框架内工作，并将输出写回其中。核心问题是："AI 应该在什么上下文中工作？"

当前生态中，绝大多数工具和关注度集中在记忆后端。但真正能够扩展到持续多会话、多项目协作的架构，正在上下文基底这一侧涌现。技术社区的话语体系，也开始向这一方向迁移。

本文将沿着这条分界线展开，首先深入记忆后端的技术实现，随后剖析上下文基底的设计哲学，最终呈现两种范式在工程实践中的本质差异。

阵营 1：记忆后端的技术谱系¶

阵营 1 的核心思路是将记忆视为独立的后端服务。LLM 负责生成内容，记忆系统负责存储和检索。这一阵营的代表性工具在架构设计上呈现出明显的分层特征。

Mem0（5.31 万星） 是当前采用率最高的类别领导者。它定义了四项基本操作：添加、搜索、更新、删除。系统从对话中提取事实，将其存储在三个层级——用户级、会话级、代理级，并通过混合检索实现快速召回。

Mem0 的集成复杂度极低，提供 Python 和 TypeScript 两种 SDK，可与任意技术栈对接。然而其局限性同样明显：记忆以扁平条目存储，条目之间不存在关联关系。每次提取都需要调用一次 LLM，提取质量完全依赖于提示词的设计。更关键的是，记忆一旦存储便不再演化——一月的事实与四月的事实并列存放，系统无法识别后者可能已经取代前者。

MemPalace（4.62 万星） 选择了截然不同的路径。它采用本地优先策略，以原话形式存储对话内容，而非提取后的事实摘要。其组织架构模仿物理空间：翼楼对应实体，房间对应主题，抽屉存储原始内容，检索由 ChromaDB 完成。

在基准测试中，MemPalace 的数据表现突出：仅凭原始语义搜索即可在 LongMemEval 评测上达到 96.6% 的检索召回率，混合管线可达 98.4%，若加入 LLM 重排序则超过 99%。这一方案的核心局限在于线性扩展——存储量随对话量同步增长，无压缩、无合成。若需求是"找回三周前说过的某句话"，这是最优工具；若需求是"概括五个项目的当前状态"，则并非合适选择。

Supermemory（2.18 万星） 明确将自身定位为"记忆不是 RAG"。其核心差异在于引入时间感知：当用户声明"我刚搬到旧金山"，系统会自动将旧城市信息标记为过期。过期事实会被自动遗忘，用户画像由稳定事实与近期活动组合而成，检索延迟约为 50 毫秒。

Supermemory 提供丰富的连接器，支持谷歌云盘、Gmail、Notion、

→ 原文存档

关联¶

• 相关概念: Harness Engineering