设计了一套基于纯 md 的 agent 记忆方案,召回率还不错,安装也简单

5 月 26 日
 bronyakaka

Agent 用多了最烦一件事,每次新开一个 session ,之前聊过的偏好、踩过的坑,全忘了,下次还是得再说一遍。

所以搞了个记忆系统。市面上方案不少,但要么重/贵/黑盒。我想弄得简单点。

想法

  1. 记忆以 markdown 文件存,一条记忆一个文件,放在 data/ 目录下
  2. 搞一个 INDEX.md,里面列了所有记忆文件的标题和简短描述,agent 每次干活前先扫一眼索引,感觉相关的就去加载对应的文件

本质上就是个文件索引表。没有数据库、embedding 、向量检索。agent 用自己的语言理解能力去判断"这条记忆跟当前任务有没有关系",其实和 llm wiki 有些异曲同工

结构长这样:

~/.agents/memories/
├── INDEX.md          # 索引表,agent 第一眼就看这个
└── data/
    ├── like.md
    ├── user-profile.md
    └── pi-install-commands.md

INDEX.md 里面大概是:

| 文件 | 关键词 | 摘要 |

Agent 执行任务前,先扫一遍 INDEX.md ,觉得哪条相关就去读 data/ 下面对应的文件。整个过程不需要 API 调用、外挂数据库,就是读文件。

跟其他方案比

SQLite FTS5

FTS5 是 SQLite 内置的全文检索引擎,支持分词、BM25 排序、前缀匹配。比 md 索引强的地方:

但它的问题也很明显:

说到底,FTS5 是个全文检索方案,不是语义检索。搜 "存储方式" 和 "数据库",它不会觉得这俩有半毛钱关系,除非在一开始就精心设计同义词表。

向量检索( embedding + 向量数据库)

这是现在最主流的方案。每条记忆算一个 embedding 向量存进向量库,检索时用当前任务描述也算一个向量,找最接近的 top-k 。

优势:

但代价也不小:

对 agent 记忆这种场景来说,每天可能就几十条记忆,全文检索和语义检索的差距没那么大。枪打蚊子。

纯 md 方案的特点

这套方案说白了是"把索引和检索交给 agent 自己的语言理解能力"。

优点:

缺点:

但这套方案有个隐藏优势:agent 决定加载哪些记忆这件事本身,就是一次理解过程。它读 INDEX.md 不只是在匹配关键词,而是在理解"现在这个任务到底需要什么上下文"。向量检索是根据一个向量做 top-k ,它不"理解"任务,只做相似度计算。

实际效果

日常场景下的召回说实话够用。项目偏好、API key 位置、奇怪的端口号、之前踩过的坑——基本都能在需要的时候被加载进来。

偶尔会漏,比如 INDEX.md 里写的摘要不够准确,agent 扫过去没对上。这种时候补一个更直白的摘要就行,本质上是在帮自己写更好的提示词。

仓库

github.com/Bronya0/llm-md-memory

安装就两步,细则 README 里有,不啰嗦了。


<sub>如果你记忆量不大(几百条以内),agent 模型能力还行,这套方案值得试试。毕竟最简单的方案往往最不容易出幺蛾子。</sub>

1090 次点击
所在节点    分享创造
1 条回复
sssunxw
5 月 27 日
claude 不是本来就有 auto memory 吗

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1215530

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX