别把你的AI当成金鱼。以下是如何给它长期记忆。

发布: (2025年12月17日 GMT+8 19:52)
3 min read
原文: Dev.to

Source: Dev.to

问题:向量孤单

构建 AI 代理很有趣,直到上下文窗口滑动。你花了数小时精心编写系统提示,喂入文档,并进行了一段精彩的对话——随后几分钟,代理就忘记了开头提到的关键依赖。它的记忆像金鱼一样短暂。

RAG(向量数据库)看起来像是解决方案:“它可以访问我的整个代码库!” 实际上,向量数据库本质上是一个高级的 Ctrl + F。它们能找到关键词,却不理解它们之间的关系。如果一个概念分散在多个文件中,标准 RAG 就会失效,因为向量只是孤立的片段,缺少真实记忆的“连接组织”。

解决方案:给 AI 一个“睡眠周期”

不要仅仅把文本丢进数据库,而是实现一个异步处理管道——我称之为 睡眠周期

摄取

  • 推送代码或文档。
  • 它会立即向量化,以便快速、短期检索。

整合

  • 背景工作者(例如 Redis + BullMQ)醒来,读取新数据,并提取实体和关系。

图谱构建

  • 更新知识图谱(GraphRAG)。
  • 链接相关组件(例如 “User Service” ↔ “Database Config”),即使它们位于不同文件夹中。

当你稍后查询代理时,它会同时从 向量索引(相似度)和 知识图谱(关系)中提取数据,提供更丰富的长期记忆。

自动化输入(GitHub Action)

我构建了一个在每次推送到 main 时运行的 GitHub Action:

  1. 对比差异。
  2. 将新代码/文档同步到 MemVault API
  3. 自动触发 “睡眠周期”,让代理保持最新,无需手动干预。

试一试

如果你厌倦了金鱼记忆的代理,试试这种方法吧。

告诉我你对 “睡眠周期” 方法的看法。它是大材小用,还是 RAG 必须走的方向?

Back to Blog

相关文章

阅读更多 »

RAG 分块策略深度解析

检索增强生成(RAG)系统面临一个根本性挑战:大型语言模型(LLM)拥有上下文窗口限制,而文档往往超出这些限制。仅仅填塞……