大模型记忆不该只是保存聊天记录，Lemmalog 选择维护“当前事实”

作者：林岚｜OC 开发者生态编辑

据安全研究者在 pwning.systems 发布的技术文章，Lemmalog 尝试把 Agent 记忆拆成两部分：大模型负责从代码、调试器输出和自然语言中提取事实，Datalog 引擎负责维护事实之间的依赖、有效时间、撤回关系和推导结果。

一句话结论：Agent 真正缺少的往往不是更多历史记录，而是一套能回答“现在什么仍然成立、为什么成立”的状态系统。

常见的 Agent 记忆方案会保存对话和观察结果，再通过向量检索找回语义相关的片段。它适合回答“我们之前讨论过什么”，却不天然知道某项结论后来已经被推翻。

假设一次漏洞研究先得到三个事实：攻击者控制对象 A，A 指向对象 B，B 是内核对象。Agent 因此推导出攻击者可以控制某个内核对象。两小时后，调试器证明“A 指向 B”是错误假设。向量数据库仍可能同时召回旧事实、新事实和旧结论，然后把消除矛盾的工作再次交给模型。

Lemmalog 的做法更像程序分析：把观察表示成事实，用规则推导结论，并记录每个结论由哪些事实支持。当输入事实被撤回时，只更新受到影响的推导；如果一项结论还有另一条独立证据链，它就不会被误删。

这套结构还保留事实的有效时间。它可以同时回答“这个攻击原语现在是否可行”和“我们上午为什么曾经认为它可行”，而不是把两条互相冲突的文字都塞给模型。依赖追踪也让研究者可以追问某个判断的来源：如果系统找不到支持它的观察和规则，这个判断就不应进入维护状态。

测试结果没有证明 Datalog 已经“解决”大模型记忆。Lemmalog 在 LongMemEval 上的 F1 为 0.463，落后于 PropMem 的 0.550，也略低于 SimpleMem 的 0.480；但它明显高于作者测试的完整上下文方案，并把每个问题交给回答模型的上下文从约 10.4 万 token 降到约 2700 token。在知识更新类别中，它取得 0.579，优于作者引用的其他方案。

LoCoMo 上的结果同样有边界：Lemmalog 总体 F1 约 0.533，落后于 PropMem 和 OpenClaw，对需要保留语气、条件偏好等模糊信息的推理尤其不擅长。它的瓶颈往往不在 Datalog，而在前端提取——如果模型根本没有把一次预订或一个人物别名抽成正确事实，后面的确定性引擎也无从推导。

问题不在这里：符号记忆不是为了消灭向量检索，而是把“找相关历史”和“维护当前真相”分开。前者仍适合语义检索，后者需要撤回、时间、来源和依赖关系。两套系统组合起来，比盲目扩大上下文窗口更接近长期运行 Agent 的工程需求。

关键事实

• 项目：Lemmalog，大模型事实提取与 Datalog 状态维护实验
• 核心能力：增量推导、事实撤回、来源追踪、时间有效性、混合检索
• LongMemEval：F1 0.463，回答上下文约缩小 38 倍
• 主要限制：事实提取、实体统一和模糊条件知识仍依赖概率模型

OC 判断

Lemmalog 最有价值的不是某个榜单名次，而是把 Agent 记忆重新定义成一个老派的软件工程问题：数据建模、状态更新和依赖失效。大模型可以当概率型前端，但不必同时承担数据库、规则引擎和审计日志的职责。

为什么重要

• 对开发者：长任务 Agent 应分别设计检索记忆、当前状态和审计来源，不能只接一个向量库。
• 对企业：可撤回、可解释的状态更适合安全分析、运维和合规等高风险流程。
• 对用户：Agent 更不容易重复已经证伪的建议，但错误事实提取仍可能污染系统。

参考来源

• I accidentally turned LLM memory into program analysis｜pwning.systems