Agent 用多了最烦一件事,每次新开一个 session ,之前聊过的偏好、踩过的坑,全忘了,下次还是得再说一遍。
所以搞了个记忆系统。市面上方案不少,但要么重/贵/黑盒。我想弄得简单点。
data/ 目录下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 调用、外挂数据库,就是读文件。
FTS5 是 SQLite 内置的全文检索引擎,支持分词、BM25 排序、前缀匹配。比 md 索引强的地方:
但它的问题也很明显:
说到底,FTS5 是个全文检索方案,不是语义检索。搜 "存储方式" 和 "数据库",它不会觉得这俩有半毛钱关系,除非在一开始就精心设计同义词表。
这是现在最主流的方案。每条记忆算一个 embedding 向量存进向量库,检索时用当前任务描述也算一个向量,找最接近的 top-k 。
优势:
但代价也不小:
对 agent 记忆这种场景来说,每天可能就几十条记忆,全文检索和语义检索的差距没那么大。枪打蚊子。
这套方案说白了是"把索引和检索交给 agent 自己的语言理解能力"。
优点:
缺点:
但这套方案有个隐藏优势:agent 决定加载哪些记忆这件事本身,就是一次理解过程。它读 INDEX.md 不只是在匹配关键词,而是在理解"现在这个任务到底需要什么上下文"。向量检索是根据一个向量做 top-k ,它不"理解"任务,只做相似度计算。
日常场景下的召回说实话够用。项目偏好、API key 位置、奇怪的端口号、之前踩过的坑——基本都能在需要的时候被加载进来。
偶尔会漏,比如 INDEX.md 里写的摘要不够准确,agent 扫过去没对上。这种时候补一个更直白的摘要就行,本质上是在帮自己写更好的提示词。
github.com/Bronya0/llm-md-memory
安装就两步,细则 README 里有,不啰嗦了。
<sub>如果你记忆量不大(几百条以内),agent 模型能力还行,这套方案值得试试。毕竟最简单的方案往往最不容易出幺蛾子。</sub>
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.