问题：变贵的不是"想"，是"回忆"
用了三个月 Claude / Cursor 之后，账单在涨、响应在变慢，而聊的东西并没变多。
把每次请求的 token 数打出来看，问题不在"问了多少"，而在每次问之前塞了多少。
token 不是被读取耗掉的，是被"把历史记忆塞进上下文"耗掉的。你三个月前说过的话，已经付过一次钱；今天它被重新加载，你要再付一次。而且这是复利式的：记忆越多，每次回忆越贵；越贵，你越不敢让它记。
（各平台管它叫积分、额度还是 credits，计量单位都是 token，下面统一叫 token。）
所以解法不是"少回忆几次"——回忆是这个东西存在的全部意义。解法是：让检索在模型之外完成。
架构：三件事
一、检索不过模型
判断"哪条记忆跟当前问题相关"是信息检索问题，不是推理问题。用大模型做检索，相当于开法拉利送外卖。
用 SQLite FTS5 + BM25 做关键词召回。记忆类文本命名实体密集（人名、项目名、术语），关键词命中率高得离谱。
中文没有空格，把 CJK 串切成重叠 bigram 再索引（数库、据库、库优……），零依赖，不用装分词库。需要语义召回再挂一个 24MB 的bge-small-zh-v1.5ONNX，CPU 单条 5–15ms；不装也能跑，退化成哈希向量，照样不花钱。
二、三层分级，只加载最薄的一层
| 层 | 内容 | 体积 | 什么时候加载 |
|---|---|---|---|
| L0 | 标题 + 自动关键词 | ~17 token/条 | 常驻系统提示 |
| L1 | 摘要 | ~80 token | 命中后才加载 |
| L2 | 原文 | 实际长度 | 明确要求才取 |
L0 的大小恒定：不管库里 300 条还是 5000 条，常驻索引都约 1000 token，因为它只取 Top-N。这条性质决定了它能不能长期用下去。
三、成本从读取侧搬到写入侧
原始对话流水账不存，存蒸馏后的事实：谁、做了什么、什么时候、什么决策、什么偏好。写一次花一次钱，之后读一万次都是零。这也是整个方案里唯一值得调用 LLM 的地方。
分词、关键词、向量、token 计数全部在写入时算好存进表，检索时唯一的计算是一次点积。
两个反直觉的性能陷阱
这部分是我觉得最有价值的，两个都跟直觉相反。
陷阱一：瓶颈不在打分。
5000 条记忆检索一次 260ms，我以为慢在 BM25 打分或向量点积。profile 出来才发现86% 的时间花在 SQLite 的 commit 上—— Windows 的 fsync 特别贵。
改成批量写入 + 单次提交 + WAL +synchronous=NORMAL，260ms → 10ms。
陷阱二：查询时别碰原文。
最初在查询时对候选文档做分词，200 个候选 × 全文，慢得离谱。改成写入时预计算，检索时只读已存好的 blob。
两个都是"改一行配置"级别的事，但不 profile 你永远不会往这个方向想。
实测数字
Windows，纯 Python，无 numpy，可复现：
| 记忆条数 | 单次注入 | 全库基线 | 压缩比 | 检索耗时 |
|---|---|---|---|---|
| 300 | 140 token | 33,442 | 0.40% | ~10ms |
| 5,000 | 140 token | 561,601 | 0.02% | 35–70ms |
两种规模下 L0 常驻索引都约 1050 token。
怎么用
我把它做成了memsave，一个 MCP 工具，任何支持 MCP 的客户端（Claude Desktop、Cursor、Windsurf、Cline、WorkBuddy）都能接，一份记忆所有 AI 通用。
pip install memsave memsave rules --write # 让新对话自动先查记忆 memsave savings --install # 每天告诉你省下多少 token暴露 9 个 MCP 工具：memory_index/memory_search/memory_get/memory_add（支持raw自动蒸馏）/memory_update/memory_forget/memory_export/memory_license/memory_stats。
每次memory_search的返回末尾附一行：本次省下 33,302 token ≈ ¥0.09（累计 XXX）。记忆存在本机 SQLite，随时export成 Markdown 或 JSON。纯标准库，零依赖，离线可用。
- 落地页：https://memsave.app.workbuddy.host/?sharecode=5V43SCBI5Q
- 教程：https://memsave.app.workbuddy.host/guide.html?sharecode=5V43SCBI5Q
还没做的
- 多机同步 / 团队共享库 / 云端备份：未上线，在路线图里
- 移动端：没有，短期不做
- 语义检索：需额外装 24MB 模型，不装也能用
如果你也在做 Agent 的记忆层，欢迎评论聊聊你的检索方案——特别是你踩的性能坑，我很想知道别人是不是也撞在 fsync 上。
