用 SQLite 构建分层 Agent 记忆引擎

把 Agent 的长期记忆全部塞进向量库，检索相似内容很方便，却未必能处理偏好更新、事实冲突和来源追溯。InfinityDB 的作者提出另一条路线：用 SQLite 保存原始对话，再用规则、因果关系、时间衰减和哈希校验组织记忆。

这套设计值得看，尤其适合正在给 AI 应用加持久记忆的开发者。不过，原文对架构的说明比性能证据完整，标题里的「亚毫秒」还不能当作已被充分验证的结论。

为什么相似度检索还不够

作者认为，现有记忆框架有四个问题：依赖额外 LLM 调用提取、总结记忆，每个活跃 Agent 每月花费约 $30–$150；传统向量和图查询耗时约 35–140ms；相似度容易把互相冲突的事实聚在一起；检索结果缺少可验证的原始来源。

这里最有价值的是对「相似」和「有效」的区分。

用户先说喜欢 JavaScript，后来改用 TypeScript，两句话在语义上非常接近，但应用需要知道当前该采用哪条偏好。向量检索可以找到它们，如何更新状态还需要额外规则。

找到相关记忆，与判断记忆现在是否有效，是两件事。

但作者列出的费用、延迟并没有附上具体对照系统和配置，不能直接推广到所有向量数据库或记忆框架。

七层记忆分别解决什么问题

InfinityDB 是作者宣称已开源的本地优先记忆引擎，底层采用 SQLite WAL 模式，即通过预写日志组织数据库写入。它把记忆分成 L0–L6：

• L0 保存磁盘上的追加式原始对话日志。作者称，将记录移出 LLM 提示上下文后，prompt token 最多减少 81.4%。
• L1 用规则提取原子事实，也就是可单独存储、检索的小条事实。作者称提取耗时低于 10ms，无额外 LLM 调用，token 成本为 $0。
• L2 建立情节因果图，保留交互之间的因果联系，帮助跨轮理解。
• L3 维护动态用户画像，按时间协调过时偏好，处理冲突。
• L4 在召回结果中注入组织安全约束和标准操作流程（SOP）。
• L5 根据交互的新近程度和频率，执行 Ebbinghaus 时间衰减。
• L6 给召回事实附上 SHA-256 哈希，并关联到原始对话的精确字节偏移。

所谓神经符号记忆，在这篇文章里更值得关注的是规则、结构和可追溯记录如何配合。原文没有详细解释神经部分的具体实现。

这套分层让几个常被混在一起的问题各有位置：原文负责留证，事实负责检索，画像负责更新，策略负责约束。代价是每层都要定义清楚边界。规则能提取哪些表达、冲突如何判定、哪些记忆应该衰减，原文没有展开。

Node 接入很短，性能证据还缺什么

原文给出的 Node.js / TypeScript 安装命令是：

npm install infinitydb

下面的代码演示按用户写入偏好，再召回相关事实：

import { InfinityDB } from "infinitydb";
const db = new InfinityDB();
db.add("Sarah prefers TypeScript for backend APIs.", "usr_sarah");
const memory = db.recall("what language does Sarah prefer?", { userId: "usr_sarah" });
console.log(memory.results);

要留意 db.add 的用户标识是第二个位置参数，而 db.recall 使用 { userId: ... }。示例没有说明默认存储位置和生产部署方式，不能仅凭这几行代码推断完整运行行为。

Python 包则通过 pip install infinitydb-ai 安装，使用 InfinityDB("agent_memory.db") 指定文件，db.add 和 db.recall 都传入 user_id。

集成方面，作者提供了 LangChain 的 InfinityDBLangChainMemory、CrewAI 的 InfinityDBCrewMemory 适配器示例，也支持执行 python -m infinitydb.mcp_server，作为 Claude Desktop 和 Cursor 的 MCP server。

性能部分，作者称在相同硬件 Apple M2、16GB 内存上，使用 PersonaMem、LongMemEval 和 LoCoMo 评测，共覆盖 300 个测试场景；另一次 2,000 轮压力测试写入并召回 10,020 条事实，操作成功率为 100%，零错误。

这些是作者报告的测试结果。原文没有给出逐项成绩、对照表或延迟分位数；示例注释写的是召回低于 5ms，与标题的「亚毫秒」也不是同一个指标。操作没有报错，更不能直接证明召回内容全部正确。

我的判断

我认可它把记忆更新、冲突处理和来源追溯单独设计。对于偏好、配置等相对明确的信息，这比只按相似度拼接历史更容易解释。

但规则提取的 $0 token 成本，不等于系统没有维护成本。中文表达、省略、否定、临时偏好能否正确处理，需要实际验证。按时间处理冲突也有前提：最新一句可能只是短期需求，未必应该覆盖长期偏好。

SHA-256 和字节偏移有助于追溯来源，但「有哈希」本身不足以保证记录不可篡改，还要看校验链与存储保护如何实现。L4 把约束放进召回结果，也不能据此认定模型一定遵守。

和「向量检索加结构化状态表」相比，这套七层设计是否更准确、更省钱，作者没有提供足够对照数据。目前可以把它当作一种可试验的架构方案，性能优势仍需复核。

能拿来做什么

• 给 Node AI 应用试接记忆时，可以先照示例验证写入和召回，再加入中文改口、否定和临时偏好，检查画像更新是否符合预期。
• 已经使用向量库的团队，可以先补上事实的时间信息和原始来源，再评估是否需要引入完整七层架构。
• 在 Cursor 或 Claude Desktop 中试用 MCP 接入时，可以重点检查跨轮偏好是否正确保留，并记录本机召回延迟，避免直接套用作者的性能数字。