🤖 AI记忆系统设计指南

AI Memory Systems Agent ⭐ 4.5/5

来源: Lobsters | 发布时间: 2026-04-03

        核心洞见： 长上下文模型 ≠ 记忆系统。研究显示当相关信息出现在上下文窗口中间时，性能下降30%。专用记忆系统是必要的。
    

为什么记忆系统是必要的？

当作者第一次使用 MemGPT（现 Letta）时，感觉就像"跨越了卢比孔河"——记忆将简单的问答机器人转变为看似有生命的实体。

但是，随着模型上下文窗口增大，有人怀疑记忆系统变得不必要。然而研究证明：

所有记忆系统可分为四个通用阶段：存储(Store) → 检索(Retrieve) → 注入(Inject) → 发出(Emit)

存储方法主要分为两派：

图数据库： Zep 声称"state of the art"的大海捞针性能
平面文件： Letta研究发现"Files are all you need"，Claude Code使用markdown文件+frontmatter存储元数据

AI记忆系统主要犯三种错误：

你希望AI agent发展记忆并了解你的一切吗？作者认为AI的未来是本地和开源的。

检索的第一个关键决策是如何启动记忆搜索：

基本的向量相似度是最有效的，但容易误排或匹配表面相似但实际不相关的内容，导致响应像"太棒了！想谈谈我们之前讨论的完全不相关的话题吗？"

解决方案： 检索后增加过滤步骤，但会增加延迟。

Claude Code不使用向量相似度，而是保持一些关于哪些记忆可用的元数据，委托给后台Sonnet调用。作者猜测是因为他们没有公共的embeddings API。

将回忆的记忆注入标准OpenAI上下文有点像"把方钉塞进圆孔"。标准LLM API没有自然的地方来放置"以下是相关对话的额外信息"。

选项包括：

最终决定如何发出响应——直接用户消息、工具调用还是assistant消息。

作者构建了自己的开源系统 Elroy (elroy.bot)，已交互3年。它帮助作者头脑风暴、讨论职业起伏，作为一种交互式日记。

经过实验，作者选择markdown文件而非数据库。记忆文件直接放在Obsidian Vault中，与其他笔记自然融合。

不关注实体分类，而是关注agent应该对记忆做什么。使用"议程项目(Agenda Item)"代表作者的一些长期目标，包括子任务和提醒触发器。这使记忆可操作，而不仅仅是泛泛地提供信息。

Elroy检索少量记忆，与上下文中已有的进行去重。最初注入原始文本，但发现上下文膨胀。后来添加了反思步骤，让AI暂停思考回忆如何与对话相关联。

最新方案：原始文本，但加上简单的LLM-backed过滤步骤过滤向量相似度搜索结果。误报比漏报更糟糕——让agent突然谈论完全不相关的话题会很奇怪。