最近读到一篇博客，作者原本想做的是「给 LLM agent 更好的记忆」，结果写着写着就跑偏了，最后落地成了一门正经的工程产物 —— Lemmalog：一个把 agent 的知识库当作"分析状态"来维护的 Datalog 引擎。

听起来有点抽象，我们拆开看。

出发点

作者最初的问题很朴素：现在大家都在卷 RAG、长上下文、向量记忆、知识图谱，agent 的"记忆"模块越来越重，但大多还是当成一个检索系统在做 —— 存进去，取出来，拼接进 prompt。但作者意识到，agent 真正需要的不是"回忆"，而是在当前对话和过去事件之间做推理。这一下就不是存储问题，而是分析问题了。

拐点：为什么是 Datalog

Datalog 是数据库和程序分析圈子里的老朋友，递归查询、增量求值、前向/后向链全都在行。换句话说，当 agent 从对话里抽出新的事实，或者发现之前的结论要被推翻，Datalog 天然就能处理这种"知识在变"的场景。

于是 Lemmalog 的核心思路变成了：

  • 把 agent 学到的每条事实（"用户在 3 月提过 X 项目""X 项目依赖 Y"）作为 Datalog 事实存入
  • 用 Datalog 规则描述派生知识
  • 当新事实到来，引擎只重新计算受影响的结论，支持撤销（retraction）和增量求值
  • 每一条结论都带着来源溯源（provenance），你能追到它是从哪段对话推出来的

这就不是"记忆"了，这是对 agent 的世界模型做抽象解释。

评测

作者没有只停留在设计思路上，还把它丢进了两个 benchmark：

  • LongMemEval：测长时记忆
  • LoCoMo：测多轮对话中的复杂检索与推理

具体数字博客里给了表格，但结论大致是：在需要"边回忆边推理"的场景里，Lemmalog 比纯向量检索或朴素的滑动窗口拼接要稳健得多，尤其当事实之间存在传递依赖、需要回溯的时候。

一句点评

这件事有意思的地方不在"Datalog 很强"，而在于视角的切换：很多人把 agent 记忆当 DB 问题，作者把它当程序分析问题 —— 你写的是 rule，求的是 fixpoint，面对的是增量更新和无效化。这套思路一旦想通，其实可以套到很多 agent 框架上：工具调用日志、计划执行状态、多 agent 协作的知识共享，本质上都吃这一套。

如果你正在做 agent 框架、或者被"记忆该存什么、怎么查"反复折磨，这篇博客值得花半小时读一遍，比又一篇 RAG 综述有用得多。

来源：Hacker News