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 索引强的地方：

• 准确度高：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 模型能力还行，这套方案值得试试。毕竟最简单的方案往往最不容易出幺蛾子。}