问题变贵的不是想是回忆用了三个月 Claude / Cursor 之后账单在涨、响应在变慢而聊的东西并没变多。把每次请求的 token 数打出来看问题不在问了多少而在每次问之前塞了多少。token 不是被读取耗掉的是被把历史记忆塞进上下文耗掉的。你三个月前说过的话已经付过一次钱今天它被重新加载你要再付一次。而且这是复利式的记忆越多每次回忆越贵越贵你越不敢让它记。各平台管它叫积分、额度还是 credits计量单位都是 token下面统一叫 token。所以解法不是少回忆几次——回忆是这个东西存在的全部意义。解法是让检索在模型之外完成。架构三件事一、检索不过模型判断哪条记忆跟当前问题相关是信息检索问题不是推理问题。用大模型做检索相当于开法拉利送外卖。用 SQLite FTS5 BM25 做关键词召回。记忆类文本命名实体密集人名、项目名、术语关键词命中率高得离谱。中文没有空格把 CJK 串切成重叠 bigram 再索引数库、据库、库优……零依赖不用装分词库。需要语义召回再挂一个 24MB 的bge-small-zh-v1.5ONNXCPU 单条 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 synchronousNORMAL260ms → 10ms。陷阱二查询时别碰原文。最初在查询时对候选文档做分词200 个候选 × 全文慢得离谱。改成写入时预计算检索时只读已存好的 blob。两个都是改一行配置级别的事但不 profile 你永远不会往这个方向想。实测数字Windows纯 Python无 numpy可复现记忆条数单次注入全库基线压缩比检索耗时300140 token33,4420.40%~10ms5,000140 token561,6010.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/?sharecode5V43SCBI5Q教程https://memsave.app.workbuddy.host/guide.html?sharecode5V43SCBI5Q还没做的多机同步 / 团队共享库 / 云端备份未上线在路线图里移动端没有短期不做语义检索需额外装 24MB 模型不装也能用如果你也在做 Agent 的记忆层欢迎评论聊聊你的检索方案——特别是你踩的性能坑我很想知道别人是不是也撞在 fsync 上。