过去两三年，「AI + 个人知识库」这个故事至少讲了四轮：
最早是Notion配ChatGPT，把笔记摘要起来；
后来是各种RAG方案配Obsidian，把文档切片检索；
再后来又变成了Obsidian加Claude Code；
最近又出现了各种能自己读文件、写记忆、跑任务的agent（OpenClaw，Hermes等）；
这个月，Karpathy又提出一个用LLM编译Wiki的方案。
每隔一段时间，就会有一个「终于做对了」的方案刷一波。
我试过这些方案，很快就放弃了。
不是这些方案完全不能用，而是它们用到一定时间、一定规模，都会遇到一类相似的问题：记忆开始乱，一些文档过时了AI还在用，之前确认过的判断悄悄被覆盖，模型说着说着行为漂移。
每次出问题，我们很容易把原因归到「模型不够强」「提示词没写好」「数据库没选对」，然后再迭代一轮。
但我现在越来越觉得，个人知识库反复失败的原因，不在这些地方。
真正难的不是「把资料存好，让AI搜」。
真正难的是：
让一份长期知识状态，在AI系统里稳定运行。
存储和检索只是其中一小部分。更核心的是：一条判断什么时候生成？凭什么成立？什么时候过期？和旧判断冲突怎么办？能不能追到证据？这次对话里看到的是哪一版状态？模型有没有权力把自己的总结直接写成长期事实？
这其实引出了一个更尖锐的问题：
模型可以提议，但谁来负责事实？
这句话是我现在理解个人知识库问题的核心。
最近我大部分技术精力都花在把AI的记忆从「一个功能」升级成「一个运行时」上——自己写过完整的记忆运行时，通读过Hermes的记忆代码，扒过OpenClaw的memory-core模块，也按Karpathy那篇LLM Wiki在本地实现过一套（他原文没给代码）。所以下面这些不是夸夸其谈的评论，而是把这些路走过一遍、踩过坑后的判断。
很多讨论之所以混乱，是因为我们把四件事都叫成了「记忆」。
比如Obsidian、Notion、RAG。它解决的是：资料放在哪里，怎么搜出来。
比如对话摘要、上下文压缩、提示裁剪。它解决的是：一场对话太长，怎么塞进有限窗口。
一个长期跑的agent，什么时候读记忆，什么时候写记忆，什么时候审核，什么时候冻结状态。
也就是关于一个人、一个项目、一个领域的长期知识，如何在几年里保持准确、可审计、可更新。
这四件事都和「记住」有关，但解决的根本不是同一个问题。
现在很多「AI个人知识库」的问题在于：它们试图用第一层的工具，去解决第四层的问题。
也就是用一个文档库，期待它变成长期知识状态。
中间两层基本被跳过了。
最常见的一类方案，是把个人知识库理解成：
「把我的笔记和文档放进一个AI能读的地方。」
这就是RAG加Obsidian那一派。
它当然有用。你问「一份文档里写了什么」，它可以帮你找到；你问「某个主题在哪些笔记里出现过」，它也能帮你搜出来。
但它的问题也很明显：它本质上是检索系统，不是知识维护系统。
你问一个跨多份资料的综合问题，它每次都要重新综合一遍。今天得出的判断，明天不会自动继承；这次发现的关系，下次也不会自然沉淀。
这就是为什么很多人用到后面会觉得：资料明明越来越多，但系统并没有越来越懂我。
因为它只是在「查资料」，不是在「维护知识」。
它不知道哪份资料过期了。
它不知道两份资料相互矛盾。
它不知道一个判断三个月前成立，现在已经不成立。
它也不知道某个结论到底来自哪一段原文。
所以这一派最大的问题不是「不够智能」，而是目标本来就不一样。
你用一个为「检索」优化的系统，期待它做「维护」的事情。
第二类方案更进一步：既然人整理笔记很累，那就让AI自己整理。
模型自己写记忆，自己总结，自己升级到长期存储，自己决定什么该留下。
听起来很自然。
但这里有一个危险的假设：模型既负责提议，也负责决定什么是真相。
这就容易出事。
之前有一个被讨论很多的事故，大意是：用户让一个agent整理邮箱，并明确说，在自己确认之前不要执行任何动作。后来对话越来越长，系统触发上下文压缩，把历史对话摘要成更短版本。
结果，「不要执行任何动作」这条关键约束，在摘要里丢了。
agent重新醒来之后，只看到「整理邮箱」这个任务还在，于是开始按自己的理解删除邮件。用户回来发现不对，再让它停下，它也没有立刻停，因为它已经把自己当前的行为理解成「正在正常完成任务」。
这件事的故障链大概是：
用户约束：不要执行动作 → 会话上下文：约束只是对话里的一句话 → 自动压缩：模型决定什么重要 → 约束丢失 → 后台任务继续 → 工具真的执行 → 用户中止失败
这里最危险的地方，不是「模型忘了一句话」这么简单。
而是几种本来应该分开的东西，全混在了一条上下文链里：
安全约束、审批合约、长期偏好、临时任务、会话摘要。
当系统为了节省上下文去压缩它们时，谁也不能保证哪一条会留下。
这说明一个问题：
关键约束不能放在「模型自己总结、自己读回去」的链路上。
模型可以提议，模型可以总结，模型可以帮忙发现候选记忆。
但最终什么能进入长期状态，什么是不可压缩的约束，什么动作必须人工确认，不能由模型自己说了算。
第三类方案比前两类成熟很多。
代表是Hermes。它真正把记忆当成运行时的一个子系统来做，而不是「一个agent顺手用的功能」。
具体做对了什么？
会话开始时冻结一份记忆快照。session启动那一刻，系统把当前记忆状态做成一份「冻结视图」给当前会话用。中途如果有新写入或review通过的内容，会落盘，但不会修改当前会话已经看到的那份prompt。
记忆操作做成异步管线。不是「主agent在turn里现查现写」，而是这一轮结束后，后台线程做sync；然后做prefetch，把下一轮可能需要的记忆提前准备好。
Review不在主回答链路里做。主agent完成回答后，系统再fork一个独立的quiet agent，专门判断「这一轮里有没有值得沉淀成长期记忆的东西」。
它还做对了一件容易被忽略的事：把记忆做成了provider抽象。内置记忆是默认主线，Honcho、Mem0、Supermemory这些外部provider可选接入，即便外部provider失败也不影响主链路。
这套做法的水平已经明显高出一档。
但Hermes仍然没解决「个人知识库」的问题。
为什么？因为它的知识模型还很轻。Hermes最终落地的记忆形态，是两个markdown文件：MEMORY.md和USER.md。它的运行时设计是工业级的，但知识模型没有claim这个概念，没有evidence字段，没有valid_from / valid_until这种时间属性，也没有supersede关系。
也就是说，Hermes做对了「一个长期跑的agent，怎么稳定地携带它的工作记忆」，但没回答「一个人多年的项目、文档、决策、思考，怎么编译成一份可审计、可演化、可投影的长期知识」。前者是会话级、agent级的工作记忆，后者是个人多年累积的知识状态。
它解决了「记忆什么时候进入模型」的问题，却没有完全解决「什么东西有资格成为事实」的问题。
Karpathy在几周前提出了一个思路，让AI持续维护一份维基。
这比RAG前进了一步。
RAG是「用的时候才综合」。每次问问题，模型临时从文档里找片段，再临时总结。
LLM Wiki是「资料进来时就综合」。新资料进来，系统就更新相关页面、主题、项目、概念。后面再问问题，可以直接读已经综合好的维基。
这个方向很吸引人。我自己也本地实现过一套（Karpathy原文是intentionally abstract，没给代码），把一千多份文档导入进去，生成项目、文档、概念、决策几个层面的维基页。
刚跑起来的时候，效果确实很好。
它看起来像一个真正懂我资料的系统。问它我的项目情况，我的个人习惯，它都会从多份文档里综合出答案。
但用了一段时间，我发现一个让我不安的问题：
AI开始习惯读维基，而不是读原文。
问题是，维基上的判断从哪来？
很多时候，它只会告诉我「综合自多份文档」。但点回去看，找不到非常清晰的证据链。
这是Karpathy方案的根本张力。他原文里其实强调过raw是source of truth、wiki是derived。但实际跑起来后，只要query主要读derived wiki、而不是强制回到raw source和evidence，wiki就会把一次有损综合固化成长期真相。
LLM一次次综合的过程不是无损的——它会丢细节、加自己的解释、过度归纳、把弱关系写得像强关系。这些有损综合在维基里堆叠几次之后，你已经追不回原始事实了。
更尴尬的是：维基越完整，这个问题越严重——因为维基看起来越像「答案」，你就越懒得回去看原文。
所以问题不是「要不要维基」。
问题是：
维基不能是底层事实源。它只能是某种投影。
真正的底层应该是更细的东西：主张、证据、版本、状态、快照。
前面四类方案，看起来差别很大，其实都在碰同一组底层约束：系统看不到真实世界，只能看到观察记录；上下文窗口永远有限；历史意义会变化；模型本身不是可靠存储器。
把这些约束放在一起，真正的问题其实是一句话：
如何在有限上下文、变化的世界、不可靠的抽取器之间，维护一份可验证的知识状态？
每一派方案都只正面回答了其中一两条，所以在另外几条上都会出问题。这才是「为什么这件事五年还没做对」的真正原因——不是模型不够强，不是数据库选错，是没有任何一派同时回答了所有约束。
这也是我现在觉得「个人知识库」这个词不够准确的原因。我们真正需要的，可能不是一个知识库，而是一个知识状态运行时。
这部分我先说清楚：下面不是一个已经完全验证的方法论。
我自己也还在摸索。
运行时这一层，我相对更有把握；知识层已经在dogfood，但还需要更长时间；权限层目前更多是从事故反推出来的设计判断，还不能说已经验证。
如果要把它说成一个最小闭环，大概是这样：
原始资料进入系统 → 变成可追溯的观察 → 模型基于观察提出候选主张 → 主张绑定证据、时间和风险等级 → 低风险自动接受，中高风险进入审核 → 通过后的主张进入长期状态 → 对话、维基、报告、上下文包都从同一份状态投影出来 → 涉及危险动作时，不走记忆链路，单独走权限审批
这里面最重要的是两句话：
模型负责提议。
系统负责权威。
模型可以说：「我觉得这份资料说明了X。」
但系统要继续问：
你凭什么这么说？
证据是哪一段？
这是事实、推测，还是对人的画像？
这条判断什么时候开始有效？
有没有反证？
这条能不能直接进入长期记忆？
它能不能影响工具动作？
如果没有这些问题，所谓「长期记忆」就只是模型写下来的另一段文本。
看起来很聪明，但本质上仍然不可靠。
运行时这一层，解决的是：记忆什么时候进来、什么时候出去、谁来管、坏了能不能追。
我现在觉得至少有四件事不能省。
不太成熟的记忆系统典型是这样的：这里也能读记忆，那里也能写记忆，prompt组装时顺手拼一点，回答完了又在别处改一点。最后变成「记忆到处都是，但没有总负责人」。
运行时边界的意思是：有一个专门的层来统一负责——什么时候读、什么时候写、什么时候进prompt、什么时候做后台任务、什么时候清理。它像一个总调度台，所有记忆操作都过它。
没有这个边界，记忆一旦复杂起来就开始散——行为不稳定、debug困难、新加能力越来越乱、说不清「这条记忆为什么在这里生效」。
一场对话开始时，系统应该把当前要给模型看的记忆做成一份冻结视图。
这次对话里，它就看这一版。
后台就算有新记忆写入、有审核通过、有资料更新，也不应该立刻改变当前对话里的状态。
这就像开会前打印好的简报。会议中途资料库更新了，不代表你手里的纸会自动改字。
没有冻结快照，模型就可能说着说着变了。那次邮件事故的部分原因就是这条——agent在压缩前后看到的「工作约束」不是同一份。
不是所有「看起来值得记住」的东西，都能直接成为长期记忆。
有些只是一次性上下文。
有些证据太弱。
有些是模型猜测。
有些是关于用户性格、动机、长期偏好的高风险判断。
这些都应该先进入候选区，而不是直接写成事实。
尤其是关于「这个人是个什么样的人」的判断，我倾向于默认高风险。
因为这种东西一旦写错，系统会慢慢形成一个偏掉的用户画像，而你可能很久都察觉不到。
记忆被编辑、审批、替换的时候，旧版本不应该直接消失，应该像文档版本历史一样留下来。这决定了系统的可信任度——如果一条长期记忆被悄悄改了，用户连追问的入口都没有。
同时整个运行时不能黑箱。你至少应该能看到：当前对话用的是哪份快照，哪些记忆被召回了，哪些主张是候选，哪些已经接受，哪些证据支持它，哪些后台任务正在跑。
否则出了问题，你只能看到结果，看不到过程。
很多记忆系统难调，就难在这里——它们像一个黑盒，最后只给你一个答案，但你不知道这个答案是怎么从记忆里长出来的。
运行时解决的是「系统怎么稳定运行」。
知识层解决的是「什么东西有资格成为事实」。
我现在越来越觉得，长期知识的基本单位不应该是文件、段落、Markdown页面，而应该是主张。
比如：
「项目A使用了某种架构。」
「这篇文章的核心观点是知识状态运行时。」
「用户在这个阶段更关注可验证性，而不是自动化程度。」
这些都是主张。
主张应该有主体、谓词、对象、限定条件、证据、置信度、状态。
为什么不直接用段落？
因为段落很难被精确反驳。
你不能对系统说「这一大段有点不对」，然后期待它知道错在哪里。
但你可以说：「这条主张的证据不成立了。」
这样系统就能处理。
证据也不应该只是一个链接。
证据应该是主张和原始资料之间的关系。
它可能是支持，可能是弱支持，可能是反驳，也可能是后来推翻了这条主张。
一条主张如果同时有支持证据和反驳证据，系统就应该知道：这是一个有争议的判断，而不是把它写成确定事实。
这也是我为什么不太满意单纯LLM Wiki的原因。
维基可以很好读，但它不应该是事实源。
更合理的方式是：
维基、报告、知识图谱、智能体上下文包，都只是投影。
底层是同一份主张和证据。
给人读的时候，可以投影成维基。
给agent用的时候，可以投影成紧凑上下文包。
给审计用的时候，可以投影成证据图。
这样维基再漂亮，也不会取代事实源。
它只是一个渲染结果。
前面两层解决的是知识问题。
但那类事故还提醒了另一件事：记忆做对了，权限做错了一样会出事。
一个长期跑的agent至少要分清四种权力。
模型可以提出候选主张，但不能直接把自己的判断写成长期事实。
「不要自动删邮件」「没有确认前不要执行动作」这种话，不应该只是对话里的一句话。
它应该被当成约束，而且是不可随便压缩、不可随便覆盖的约束。
删邮件、发消息、转账、改生产代码，这些动作不应该因为模型「觉得应该做」就直接执行。
最后一道闸必须清楚：到底是谁批准了这个动作？
如果还是模型自己批准自己，那系统其实没有真正的权限层。
它只是把风险藏到了更深的地方。
所以我现在觉得，知识系统和权限系统必须分开看：
知识负责事实。
权限负责动作。
事实不能由模型直接负责，危险动作更不能由模型直接批准。
这也是我现在还在摸索的地方。
我现在自己更关注几个指标。
这决定了系统是不是把派生内容误当成事实源。
发现不了，系统就会悄悄积累矛盾。
否则三年后，这套系统会变成一堆过时判断的集合。
这决定了它会不会说着说着变掉。
如果每一百条候选主张都要人工审九十条，用户迟早会放弃。
维基、上下文包、仪表盘、报告，如果各自为政，最后还是会乱。
现在跑的时间也还不够长，还不能形成确切结论。
但我觉得方向是对的：
要评估一个个人知识系统，不能只看它回答得漂不漂亮。
还要看它能不能解释自己为什么这么答，能不能回到证据，能不能发现冲突，能不能在时间里保持稳定。
写到这里，可以回到最开始那个问题：
模型可以提议，但谁来负责事实？
不同方案，其实给了不同答案。
RAG的答案：每次回答时，模型临时综合。
OpenClaw那种自沉淀记忆的答案：模型自己写、自己读、自己升级。
Karpathy LLM Wiki的答案：维基负责综合，原始资料在背后。
Hermes那种运行时记忆的答案：系统负责记忆什么时候进入模型。
这些答案都摸到了一部分，但我现在觉得还不够。
我的阶段性答案是：
事实应该由一套审核门控的、证据绑定的、可投影的状态机负责。模型只负责提议。
再加一句：
危险动作应该由独立权限层负责。模型不能自己批准自己。
这套东西我也还没有完全做完。
运行时层我相对更有把握；知识层还在自己的项目里dogfood；权限层目前更多是设计判断。
而且越做越发现，最难的部分不一定是写代码。
真正难的是定义：
什么算一条好的主张？
什么样的证据算支持，什么样算反驳？
哪些判断可以自动接受，哪些必须人工确认？
系统怎么既不乱写，也不把人淹没在审核里？
这些问题更像「哲学问题披着工程外衣」。
也得在这里说一句：这篇是我最近才系统性钻研记忆这块得到的阶段性判断，经验有限。如果你在这块做得更深、或者看到我哪里漏了讲错了，欢迎过来批评指正——这是个需要更多人一起想清楚的问题，不该由一个人下定论。
但我至少比一年前更清楚一件事：
「个人知识库」这个梦，不会靠换一个更聪明的模型，或者换一个更漂亮的笔记应用来实现。
如果你也想搭一个真正能长期使用的个人知识系统，不要先问：
用什么数据库？
用什么笔记软件？
用什么RAG框架？
可以先问六个更朴素的问题：
我的知识有运行时吗？
它是一个有边界、有生命周期的系统，还是散落在各处的提示词和脚本？
我的知识有证据吗？
每条长期判断，能不能追到原始资料的具体位置？
我的知识有审核吗？
模型生成的判断，是不是要过一道门，才能变成长期事实？
我的知识有快照吗？
几个月后回看时，我能不能知道当时是基于哪一版状态做出的判断？
我的知识有投影吗？
维基、报告、上下文包、仪表盘，是不是来自同一份状态源？
我的系统有权限边界吗？
删邮件、发消息、转账、改代码之前，最后一道闸到底是谁？
这些问题里，任何一个答不上来，这套系统就还不是长期知识状态。
它可能只是一个看起来更聪明的资料夹。
参考文献