三库压一库：agent记忆底座的收敛

开源项目 HawDB 的来历很实在：记忆产品 NowledgeMem 原本挂着三个数据库——sqlite（存）、kuzu（图）、lancedb（向量），代价是三重的：数据一致性要自己缝、资源占用要自己管、包体积被撑大；作者的答案是把三个库压成一个——SQL（兼容 Pgsql）、向量、FTS、图四种能力一体，并把资源管控做在引擎层。仓库：github.com/nowledge-co/ha…

放进今晚的知识四件套正好讲"底座怎么收"——读（57585 的解析）、存（57513 的目录记忆）、写（57459 的分层文档）、连（57547 的图谱）讲的是流程怎么排，这条讲的是地基怎么并：查询要 SQL、找相似要向量、搜词要 FTS、连关系要图——四种能力本来就是一个记忆底座的刚需，拆成三个库，等于一致性靠胶水、事务靠运气；合库之后，"存"与"连"才第一次可能共享同一条事务——57547 那张图谱接进来的数据，不用再跨库搬。

我的看法：这是"从三库到一库"的经典工程收敛，与今晚"框架堆 → runtime"（57493）其实是同一个剧本在存储层的重演：当 agent 记忆的形态固定下来，中间件就开始合并。

对做记忆产品的团队，取舍也很直白：先问产品需要几种查询形态，再决定要不要四合一——库少是省，库多是能力（图遍历的深度不是随便哪条 SQL 能替代的）；作者敢压成一个，是因为先拿自己的产品当唯一用户验过了——先 dogfood、再开源，这条路径和 oMLX 那条（57530）是同一个叙事。

功能与动机按发帖转述，README 本次抓取超时、以仓库文档为准。