用 Datalog 引擎管理 LLM 记忆：Lemmalog 的设计与思路

在长时间漏洞研究任务中，作者注意到 LLM agent 会逐渐丢失此前已建立的事实：已被排除的方案被重新提起、已被证伪的假设仍被当作推理前提继续使用。常见做法是把历史观察嵌入向量库、按需检索，但这种"回忆"方式依赖模型自行重建结论，无法保证一致性。受程序分析中"事实-规则-不动点计算"思路启发，作者将 LLM 记忆问题重新建模为可增量维护的知识库，并由此写出了一个面向 LLM 的 Datalog 引擎，命名为 Lemmalog。

问题：LLM 在长任务中为何失忆

• 漏洞研究中一次调查常持续数小时，期间会陆续产生大量中间结论。
• 传统方案把对话或观察写入外部存储，再以嵌入检索的方式送回上下文，模型据此自行推导。
• 当某一底层事实被推翻时，模型难以精确识别哪些上层结论随之失效，容易继续从已被否定的观察出发推理。

思路：把记忆当作可推导的知识库

程序分析中常见的事实-规则范式与作者的需求高度契合：

• 已知事实，例如 controls(attacker, object_a)、points_to(object_a, object_b)、kernel_object(object_b)。
• 派生规则，例如"若攻击者控制的对象指向内核对象，则攻击者能控制内核对象"。
• 引擎据此自动派生 controls_kernel_object(attacker) 等结论，并维护一个不动点。

当某条底层事实改变时，Datalog 引擎能够定位依赖该事实的所有派生结论，并自动将其标记为失效，而无需重新跑整段推理。这正是作者希望 LLM 获得的能力。

Lemmalog 的分工

Lemmalog 把任务拆成两部分：

• LLM 负责"模糊"部分：理解自然语言、源码、调试器输出，并将非结构化信息转化为结构化事实，例如 freed(object_a)、reused_as(object_a, write_target)。
• Datalog 引擎负责"确定"部分：接受事实、套用规则、持续维护派生结论。

这样既保留了 LLM 在理解上的优势，又避免了在每轮对话中让其重复推导相同结论。

撤回（Retraction）的挑战

Datalog 中添加事实较为直接：写入新事实并重新评估可能受影响的规则。但删除一条事实要复杂得多：

• 规则可能由多条事实共同触发，简单的反向追踪无法覆盖所有派生存活路径。
• 引擎需要维护足够的状态来回答"哪些派生结论依赖于已删除的事实"，并在事实撤回时同步失效这些结论。

小结

Lemmalog 提供了一种不同于"检索式记忆"的思路：用确定性的逻辑引擎维护 LLM 的知识状态，让结论随底层事实变化而自动更新。这对于需要长时间、多轮、且结论可被持续修正的 agent 任务（例如漏洞研究）具有参考意义。不过文中尚未给出完整的 benchmark、性能数据或对比实验，目前更适合作为一种架构思路而非成熟产品来看待。