memweave，由 Sachin Sharma 开发的开源 Python 库，本周出现在 Towards Data Science 上，定位为"零基础设施"的 agent 内存——不用 Pinecone、不用 Weaviate、不用任何托管向量数据库。只要一个 markdown 文件夹加一个 SQLite 索引。时机很有意思：市面上大多数 agent 内存基础设施都在追求规模——向量存储、图数据库、分布式 embedding——而大多数 agent 实际上并不需要规模。它们需要的是持久化、可审查性，以及一个在精确匹配查询上不掉链子的检索信号。memweave 下注的是：默认配置一直选错了。
架构由三部分组成。文件夹里的 markdown 文件是真理源，人与 agent 都可读可写。SQLite 持有派生索引，里面包含三件东西：FTS5 用于 BM25 关键词匹配，sqlite-vec 扩展用于 SIMD 加速的 embedding 相似度，还有一个以内容 SHA-256 为键的 embedding 缓存——这样重写文件不会触发冗余的 API 调用。默认检索是混合式的：0.7 × 向量 + 0.3 × BM25，再用 MMR 重排求多样性。时间衰减按文件龄给老记忆降权，长青文件（无日期前缀）与日期型文件（YYYY-MM-DD.md）按不同曲线老化。Agent 命名空间来自子目录。README 里链接了两个可运行的 notebook——一个读书会演示，一个会议纪要 agent——但没有公开基准测试，这值得指出：这个库还新，规模化未经验证。
库的底下其实藏着一个关于"agent 内存到底需要什么"的真实论证。大多数 agent 操作的是千级条目，不是百万级；SQLite 加上 sqlite-vec 无需网络跳转就能搞定。BM25+向量的混合默认也大概率是对的：单用 embedding 会在精确匹配场景翻车——"我给服务 X 的 API key 是啥"这类用户就把字面值写出来了的情形；单用 BM25 又会在语义表达上失手。但真正值得留意的操作性优势是另一个：跑 git diff memory/ 就能看出 agent 在两次运行之间学到了什么，逐个 commit 可追。这是没有任何向量数据库能给你的调试原语，也正是你凌晨三点想搞清楚"它当时为什么那么决定"时最想要的东西。把版本控制当作内存上的一等操作，而不是事后贴着数据库导出补上去的念头。
这套模式就算不用这个库本身也可复制。对于那些内存规模本质上没到百万级条目的 agent——就是开发者实际交付的大多数 agent——值得偷过来的模板是：把一个 markdown 文件夹当作真理源；派生出一个任何时候都能从头重建的索引；用混合检索而不是纯向量；把内存纳入版本控制，这样任何改动都可审计。坦白的注脚：真到向量数据库确实值回票价的规模——海量文档语料、带上百万用户内存的多租户生产——这个方案多半会崩，作者也没有跑出失败模式的基准。对于个人 agent、研究 agent、内部工具——这也是被打造出来的绝大多数沉闷但真实的东西——这套 lo-fi 模式就是一个好起点。读一下那两个 notebook 示例，判断它合不合，总之把思路偷走再说。