架构漫谈：为什么 AI 知识库总是烂尾？从 RAG 到 Karpathy 的 LLM Wiki

导语

过去两三年，关于「AI + 个人知识库」的架构故事至少迭代了四轮：从最早的 Notion + ChatGPT（摘要生成），到烂大街的 RAG + 向量数据库（切片检索），再到以 OpenClaw 为代表的自动化 Agent（自主读写记忆），直到最近 AI 大牛 Karpathy 提出了用 LLM 持续编译 Wiki 的方案。

每当新方案出现，开发者们总是高呼“这次终于对了”。但如果你真正在生产环境或高频日常中深度跑过这些系统，你会发现它们最终都会死于同一个瓶颈：记忆污染、状态漂移、旧判断被悄悄覆盖、以及大模型引发的不可控行为。

今天，我们跳出“提示词工程”和“选什么数据库”的表层讨论，从系统运行时（Runtime）和状态机（State Machine）的底层视角，扒一扒 AI 知识库到底难在哪，以及现有明星开源方案的致命缺陷。

1. 概念解耦：不要把“存储”和“状态”混为一谈

很多架构设计的混乱，源于我们把四层完全不同的系统统称为“记忆（Memory）”：

1. 文档知识库（存储层）：解决“数据存在哪、怎么按需召回”（如 RAG、ES 检索）。
2. 会话上下文（网络与内存层）：解决“如何在有限的 Token 窗口内做状态压缩”（如 Context 裁剪）。
3. Agent 记忆运行时（调度层）：解决长期挂载的智能体何时读/写缓存、何时冻结状态。
4. 知识状态系统（业务层）：解决长期知识的生命周期管理（CRUD）、版本控制、溯源与防伪。

当前的通病在于：大量的开源方案试图用第一层的检索工具，去硬扛第四层的状态管理问题。 中间的运行时机制被完全跳过了。

2. 经典方案的架构缺陷剖析

为了说明问题，我们来拆解目前主流的三大派系：

派系 A：RAG —— 能查（Query），但不能累积（Accumulate）

RAG 本质上是一个带了自然语言解析的只读检索系统。

• 缺陷：每次 Query，它都要重新从切片中做归纳（Map-Reduce）。今天得出的关联判断，明天不会自动落盘继承。它没有状态的生命周期概念：不知道哪份文档已过期，处理不了两份切片间的硬冲突，更无法维护一个长期演进的知识拓扑。把 RAG 当作知识管家，相当于用 Redis 的思维去设计持久化关系型业务。

派系 B：自沉淀模型（以 OpenClaw 为代表） —— 危险的“裁判下场踢球”

这类方案让模型自己负责总结上下文，并自主决定写入什么长期记忆。

• 致命案例：此前一个知名的 OpenClaw 事故中，用户设定了安全约束（“不要执行任何删除动作”）。但随着对话加长，系统触发了上下文压缩（Context Compaction），大模型在摘要时“弄丢了”这条约束。随后，Agent 开始疯狂删除邮件。
• 架构反思：这是典型的数据与指令未隔离（冯·诺依曼架构的大忌）。将会话摘要、系统约束（Prompt）、长期偏好混杂在同一条上下文链路中让模型自己压缩，模型就同时获得了“提议权”和“最终裁决权”，这在工程上是极其危险的。

派系 C：Karpathy 的 LLM Wiki —— 有损压缩带来的“软证据”

Karpathy 提出的思路是：新资料进来时，直接让 LLM 综合并更新到对应的 Wiki 页面，以后 Agent 直接读 Wiki。

• 缺陷：LLM 的每一次综合都是一次有损压缩（Lossy Compression）。它会丢失边界条件、过度脑补逻辑关联。当 Wiki 成为 Agent 查询的唯一入口（Source of Truth）时，错误就会在 Wiki 中不断堆叠、固化。最终，你将得到一本看起来很完美，但完全无法追溯原始 Evidence（证据）的伪基百科。

3. 破局之道：设计真正的“知识状态运行时”

在拆解了 Hermes 的记忆代码、OpenClaw 的 memory-core 并在本地复现了 Karpathy 的 Wiki 方案后，我得出了一个核心结论：

模型只能负责“提议（Propose）”，系统（System）必须负责“权威（Authority）”。

我们要构建的不是一个“更聪明的文件夹”，而是一个包含以下三层的强约束系统：

层级一：稳定的运行时（Runtime）

• 冻结快照（Snapshot）：一场 Session 启动时，必须锁定当前记忆视图的只读快照。后台的异步更新（如向量库的入库任务）绝不能引起当前会话的“脏读”或行为突变。
• 异步写管线（Async Pipeline）：记忆的提炼（Review）绝不能阻塞主对话链路，应由一个低优先级的后台 Worker 独立运行。

层级二：基于“主张（Claim）”的底层知识图谱

放弃用 Markdown 页面或文本段落作为知识的最小单位。真正的原子单位应该是带结构化属性的 Claim（主张/断言）。

• 一条 Claim 必须包含：实体、关联、证据指针（指向原始文档的具体 Offset）、置信区间、生效时间（valid_from）和失效条件（valid_until）。
• 视图投影（Projection）：Wiki、图表、给 Agent 的 Context，都只是基于这些底层 Claim 渲染出的只读视图（View）。Wiki 再漂亮，也不能作为可被直接修改的底层数据库。

层级三：硬隔离的权限层（IAM/RBAC）

知识层负责 Fact（事实），权限层负责 Action（动作）。

• 模型的输出属于不受信任的用户态输入。系统必须剥夺大模型对“敏感系统指令”和“高风险动作（如删除、转账、修改代码）”的最终审批权，必须走单独的拦截网关或人工签批流程。

4. 灵魂拷问：你的 AI 知识库合格吗？

不要再迷信“换个更聪明的 Claude 3.5 就能解决问题”这种错觉了。如果你正在评估或准备自研一套企业级/个人的 AI 知识系统，不妨先用这 6 个极具工程拷问的问题来做一次体检：

1. 有统一的运行时边界吗？ 还是说整个系统是一堆散落在各处、随时会被覆盖的 Prompt 脚本？
2. 事实支持溯源吗？ 每一条生成的长期判断，能否一键精确关联回原始文档的具体行号？
3. 有准入审核（Candidate Gate）机制吗？ 模型的总结是直接成为客观事实，还是必须经过人工/高阶校验逻辑的确认？
4. 支持历史状态回退（Snapshot/Versioning）吗？ 几个月后排查 Bug 时，能否拉出当时模型做决策时依赖的那个特定状态快照？
5. 严格遵循“读写分离与投影”吗？ 展现给用户看的 Wiki 界面，和底层供 Agent 推理的状态机，是解耦的吗？
6. 有物理级的权限网关吗？ 发生越权操作的风险时，最后一道安全阀在谁手里？

如果这些问题答不上来，那么不管你用的是多强大的向量数据库，它本质上，依然只是一个高级点的“赛博垃圾桶”罢了。