设计了一套基于纯 md 的 agent 记忆方案，召回率还不错，安装也简单
Agent 用多了最烦一件事，每次新开一个 session ，之前聊过的偏好、踩过的坑，全忘了，下次还是得再说一遍。
所以搞了个记忆系统。市面上方案不少，但要么重/贵/黑盒。我想弄得简单点。
想法
- 记忆以 markdown 文件存，一条记忆一个文件，放在
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 调用、外挂数据库，就是读文件。
跟其他方案比
SQLite FTS5
FTS5 是 SQLite 内置的全文检索引擎，支持分词、BM25 排序、前缀匹配。比 md 索引强的地方：
- 准确度高：BM25 算法打分，比 keyword 肉眼匹配靠谱
- 支持模糊搜索：写 “vscdoe”，能找回 “vscode” 相关记忆
- 增量更新快：插一条新记忆，重新建索引成本很低
但它的问题也很明显：
- 需要维护一个 SQLite 文件，多了个依赖
- FTS 索引表和数据表要手动同步，忘了更新索引就废了
- agent 得会写 SQL ，实际用起来还得封装一层
- 跨平台、跨环境迁移不如纯文件方案利索
说到底，FTS5 是个全文检索方案，不是语义检索。搜 “存储方式” 和 “数据库”，它不会觉得这俩有半毛钱关系，除非在一开始就精心设计同义词表。
向量检索（ embedding + 向量数据库）
这是现在最主流的方案。每条记忆算一个 embedding 向量存进向量库，检索时用当前任务描述也算一个向量，找最接近的 top-k 。
优势：
- 语义匹配强：你说”怎么存数据”，它能找回”项目使用 SQLite 做持久化”这种表述完全不同但语义相关的记忆
- 不依赖关键词：同义词、不同语种都能召回
- 多模态可能：图片、代码片段都能向量化
但代价也不小：
- 每召回一次就得调 embedding API （或者本地跑模型），有成本、有延迟
- 向量数据库要么另外部署（ Chroma 、Milvus ），要么托管花钱（ Pinecone ）
- embedding 质量直接影响召回效果，换模型还得重建整个向量库
- 召回结果不透明：你不知道为什么召回了这条，没召回那条，调参基本靠感觉
对 agent 记忆这种场景来说，每天可能就几十条记忆，全文检索和语义检索的差距没那么大。枪打蚊子。
纯 md 方案的特点
这套方案说白了是”把索引和检索交给 agent 自己的语言理解能力”。
优点：
- 零依赖：文件系统自带，不装任何东西就能跑
- 全透明：记忆内容随便用任何编辑器打开看、改、删，Git 也能追踪
- 可迁移：换个电脑，复制整个文件夹就行
- 无成本：不调 API ，不跑模型，纯本地
缺点：
- 依赖 agent 模型的阅读理解能力，小模型可能瞎判断
- 记忆量上去了（几百条），INDEX.md 会变长，每次全扫一遍吃 token （几 k 其实还好，记忆总得有点代价）
- 没有真正的语义匹配，全靠 agent 自己联想
但这套方案有个隐藏优势：agent 决定加载哪些记忆这件事本身，就是一次理解过程。它读 INDEX.md 不只是在匹配关键词，而是在理解”现在这个任务到底需要什么上下文”。向量检索是根据一个向量做 top-k ，它不”理解”任务，只做相似度计算。
实际效果
日常场景下的召回说实话够用。项目偏好、API key 位置、奇怪的端口号、之前踩过的坑——基本都能在需要的时候被加载进来。
偶尔会漏，比如 INDEX.md 里写的摘要不够准确，agent 扫过去没对上。这种时候补一个更直白的摘要就行，本质上是在帮自己写更好的提示词。
仓库
github.com/Bronya0/llm-md-memory
安装就两步，细则 README 里有，不啰嗦了。
如果你记忆量不大（几百条以内），agent 模型能力还行，这套方案值得试试。毕竟最简单的方案往往最不容易出幺蛾子。