笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
不想公开、只想临时给人看：点“分享”生成一条带密码和有效期的链接，到期自动失效，你也能随时撤销。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
把LLM记忆变成程序分析：用Datalog维护AI研究中的知识状态
本文介绍作者在漏洞研究中意外将LLM记忆系统转化为Datalog引擎，实现知识依赖追踪与自动失效，提升AI辅助研究的可靠性。
背景：LLM在漏洞研究中的记忆困境
过去几个月，我一直在尝试将LLM智能体用于漏洞研究。它们在导航大型代码库、解释陌生子系统和探索潜在攻击面方面表现出色。然而，当调查持续数小时后，我反复遇到同一个问题：模型会逐渐丢失我们已确认的信息。它可能重新提出我们已经排除的方案，忘记某个假设已被推翻，或者自信地基于失效的观察继续推理。
显然，告诉LLM某个事实是错误的，并不代表它会放弃所有依赖该事实的推论。这促使我开始研究记忆系统，希望提升LLM在复杂漏洞研究中的实用性，减少这类幻觉。
现有记忆系统的不足
目前已有许多为LLM提供记忆的方案，通常涉及：将旧对话或观察存储起来，进行嵌入，然后在模型需要时检索最相关的片段。这在实践中效果尚可，但有一个问题困扰着我：
在漏洞研究过程中，我不仅希望模型记住我们说过什么，更希望它维护我们当前已知什么。
例如，假设调查中我们确认了以下事实：
- 攻击者控制对象A
- 对象A指向对象B
- 对象B是内核对象
由此我们可以推断：攻击者可以控制一个内核对象。传统记忆系统可以存储这些观察，并在需要时检索，让LLM重新推导出结论。这没问题。
但假设两小时后，我们在LLDB中发现对象A实际上并不指向对象B，之前的观察基于错误假设。此时记忆中可能同时存在：
- 对象A指向对象B
- 攻击者能控制对象B
- 对象A实际上不指向对象B
我们检索到这些矛盾信息，然后寄希望于LLM能正确判断哪些结论依然有效。这显然不可靠。
程序分析的启示
这种情境让我感到熟悉。我日常工作中大量涉及程序分析。分析程序时，我们通常拥有关于程序的事实集合，以及从事实推导新事实的规则。例如：
- calls(foo, bar)
- calls(bar, baz)
定义规则：如果函数A调用函数B，而B能到达函数C，则A也能到达C。最终计算出一个不动点，包含所有可推导的事实。更重要的是，如果某个输入事实改变，有成熟技术可以只更新受影响的结果，而无需从头重算。
这正是我在LLM辅助研究中所期望的：如果某个观察改变，我不希望模型从完整转录中重建整个调查，并祈祷它能注意到所有后果。我希望受影响的结论自动失效。
从这个角度看，我开始质疑：为什么我们要让LLM反复重建其整个状态？我们为什么不能直接维护它？
于是，我意外地开始为LLM编写Datalog引擎。
Datalog简介
Datalog是一种声明式逻辑编程语言。我们不编写描述计算步骤的指令，而是描述事实和规则，从中推导新事实。
例如，存储以下事实：
controls(attacker, object_a).
points_to(object_a, object_b).
kernel_object(object_b).
定义规则：
controls_kernel_object(Attacker) :-
controls(Attacker, ObjectA),
points_to(ObjectA, ObjectB),
kernel_object(ObjectB).
引擎可从现有事实推导出：controls_kernel_object(attacker).
目前这没什么特别。但假设后来发现points_to(object_a, object_b)是错误的。如果controls_kernel_object(attacker)是从该事实推导的，我们就能精确知道哪个结论依赖于这个变化的观察，并自动使其失效。这远比将旧信息塞进提示词、寄希望于LLM注意到相同问题要可靠得多。
Lemmalog：LLM与确定性引擎的分工
这个项目最终演变为Lemmalog。核心思想是：LLM不必负责维护自身知识。相反，我将问题拆分为两部分：
LLM处理模糊部分：理解自然语言、源代码、调试器输出等混乱信息，将其转化为结构化事实。例如：
- LLDB显示释放的对象后来被用作写入目标。
- LLM输出：
freed(object_a),reused_as(object_a, write_target)
Lemmalog处理确定性部分：事实 → 规则 → 推导事实。数据库负责计算所有逻辑后果，无需模型反复推理。
这种分工利用LLM擅长处理非结构化信息的优势，同时将逻辑推理交给确定性引擎，避免幻觉累积。
事实撤销：维护支持关系
实现中遇到的第一个有趣问题是删除事实。向Datalog数据库添加事实相对简单：添加新事实，评估可能产生新结果的规则。删除则更棘手。
考虑例子：
a.
b.
c :- a.
c :- b.
这里c有两个独立的成立理由。如果我们删除a，不能简单删除c，因为b仍然支持c。但如果同时删除a和b，c也应消失。
在漏洞研究中这很重要，因为一个结论可能由多个观察支持。例如，candidate_3_is_exploitable可能即使某个特定利用原语失败后仍然成立，因为存在另一条独立路径达到相同结果。
因此，Lemmalog必须跟踪事实的派生方式，并在变化时更新它们的支持关系。
追溯：为什么AI相信某事
跟踪依赖关系带来了另一个有用特性：我们可以询问某事实为何为真。
想象运行代理数小时后，它得出结论：candidate_3_is_exploitable。这很好，但我也想知道为什么。由于Lemmalog已跟踪派生事实的依赖，我们可以查询结论的来源（provenance）。
例如，可能得到类似这样的概念图：
candidate_3_is_exploitable
├── attacker_controls_pointer
│ ├── observation_41
│ └── observation_57
├── pointer_reaches_target
│ └── observation_57
└── rule_12
如果observation_41后来被证明错误，我们知道该结论可能不再有效，数据库也能自动移除受影响的结论。
这最初是为了正确实现增量评估，但后来发现，能够询问AI代理为何相信某事也非常有用。它解决了LLM辅助研究中最令人沮丧的失败模式之一：模型自信地说“我们已经确认这个指针是攻击者控制的”，而事实并非如此。如果结论有明确来源，我们可以直接检查其依赖是否成立。
总结与展望
Lemmalog的核心理念是：不要让LLM维护自己的知识状态，而是将知识维护交给确定性引擎。LLM负责将非结构化信息转化为结构化事实，Datalog负责事实的推导、撤销和追溯。这显著提高了LLM在长时间复杂任务（如漏洞研究）中的可靠性，减少了幻觉和遗忘问题。
未来，我计划探索如何让LLM更自动地生成高质量规则，以及如何处理不完全确定的事实（如概率支持）。但就目前而言，将程序分析技术应用于LLM记忆，已被证明是一条有前景的路径。
原文链接：https://pwning.systems/posts/llm-memory-program-analysis/