lemmalog：用Datalog给LLM Agent装一个可追溯的共享记忆

当 Agent 需要记住的不只是几句对话，而是一堆事实、关系和规则时，普通的向量数据库就有点力不从心了。向量检索能告诉你“相关”，但说不清“为什么”。lemmalog 走的是另一条路：它用 Datalog——一种声明式逻辑编程语言——把 Agent 的记忆变成一组可推导、可溯源的事实和规则。

它到底怎么工作？

lemmalog 的核心是一个 Datalog 引擎，用 Rust 写成，MIT 协议开源。它接受你定义的事实（比如“用户A喜欢科幻电影”）和规则（比如“如果用户喜欢某导演的电影，就推荐该导演的其他作品”），然后自动推导出新的事实。关键在于，每条推导出的结论都带有 provenance（溯源），也就是你能知道它从哪些原始事实和规则得来。这对 Agent 来说很重要——当它需要向用户解释“我为什么推荐这部片子”时，不是给出一堆隐向量，而是能回溯到具体的逻辑链。

它还支持分层规则（stratified rules），允许规则之间有优先级或层次，避免循环推导导致的不一致。增量推导（incremental derivation）意味着当你新增或删除一条事实时，引擎只重新计算受影响的部分，而不是全量重跑。这在 Agent 的长期运行中能省下不少计算资源。

作为共享大脑的 MCP 服务器

lemmalog 最特别的地方是它自带一个 MCP（Model Context Protocol）服务器。MCP 是 Anthropic 提出的开放协议，让 AI 应用能标准化地连接外部工具和数据。lemmalog 把这个协议用在了记忆上：你的 Agent 编排框架（比如 Claude 的 harness）可以通过 MCP 把 lemmalog 当作一个共享的记忆服务来调用。

这意味着什么？多个 Agent 或同一个 Agent 的不同会话可以读写同一套事实库，而且这套记忆是结构化的、可查询的、可推导的，不是一堆文本块的向量索引。比如你让 Agent 管理一个项目，它可以记录“任务A依赖任务B”“任务B的负责人是小王”，然后通过规则推导出“如果任务B延期，任务A也会延期”，并在风险提示时给出完整的推导路径。

它适合干什么，不适合干什么

lemmalog 很适合那些需要精确状态跟踪和逻辑推理的场景，比如工作流编排、自动化决策、知识图谱构建。它比纯向量检索更严谨，比硬编码的状态机更灵活。但要注意，Datalog 的表达能力是有限的——它不擅长处理模糊或概率性信息，也不适合做大规模非结构化数据的全文检索。如果你的 Agent 只是需要“回忆”聊天历史，那用向量库就够了；但如果需要“推理”出新的结论，lemmalog 就有优势了。

在开发者社区，这个项目目前有 256 个 star，不算多，但主题标签指向 agent-memory、knowledge-graph、neurosymbolic，属于一个比较前沿的细分方向。Rust 实现意味着性能和内存安全都有保障，但这也意味着如果你要二次开发，需要熟悉 Rust 和 Datalog 语法，有一定学习成本。

什么时候真的需要它？

想象一下，你不再满足于让 Agent 基于提示词做一次性回答，而是希望它像一个真正的助手那样，记住你的偏好、理解项目上下文、并在不同任务间保持一致。当这种一致性需求变强，而你发现提示词工程已经撑不住复杂状态时，就是考虑 lemmalog 的时候。它不便宜——不是指价格（它开源免费），而是指你需要投入时间去建模事实和规则。但一旦建好，它给 Agent 带来的逻辑一致性，是纯靠堆提示词难以达到的。

反过来，如果你的 Agent 只是简单问答，或者数据全是非结构化的文本、图片，那 lemmalog 帮不上什么忙，反而会拖慢开发节奏。它是给那些“记忆即逻辑”的场景准备的——比如自动化运维诊断、复杂业务规则引擎、多 Agent 协作中的共享事实层。

lemmalog 不是记忆的仓库，而是记忆的推理引擎。它把 Agent 从“记住”提升到“理解”，而理解，才是智能的起点。

FAQ：常见问题

lemmalog 和向量数据库在 Agent 记忆上有什么本质区别？

向量数据库存的是文本的向量表示，能按相似度检索，但回答不了“为什么相关”。lemmalog 存的是结构化事实和规则，能通过 Datalog 推导出新结论，并且每条结论都带溯源路径。前者适合模糊回忆，后者适合精确推理和状态跟踪。

lemmalog 的 MCP 服务器是干什么的？

它让 Agent 编排框架能通过 MCP 协议把 lemmalog 当作共享记忆服务来调用，这样多个 Agent 或会话就能读写同一套事实库，并利用其推导能力。也就是说，它把记忆从“本地私有”变成了“可共享的推理大脑”。