2026-05-10 蒸馏塔distill-vault个人知识库AI协作

知识库应该是 runtime，不是 storage

大多数知识库真正缺的，不是编辑器，不是双链，也不是再多一个 AI 总结按钮。

它缺的是运行时。

很多系统只解决了一件事：把东西存进去。

结果当然比散落在各处强。但做到这里，知识库最多只是一个 storage。

而对持续和 AI 协作的人来说，真正关键的问题不是“有没有存住”，而是：

这条知识在下一次检索、判断、执行和构建时，还能不能继续参与工作？

这才是 runtime 该回答的问题。

Storage 只解决“别丢”

我越来越觉得，很多知识库后面之所以越用越乱，不是因为记得不够勤，也不是因为工具不够强，而是因为它们默认的世界观就是 storage。

storage 的核心动作是保存。

问题在于，“以后”通常不会自己发生。

信息一旦持续涌入，系统里很快就会混在一起：

这时候文件都还在，链接也未必断，但系统已经开始失去可解释性。

你会碰到几种非常常见的情况：

  1. 改了一个概念定义，却不知道哪些项目页还在沿用旧说法。
  2. 删除或覆盖一条来源后，才发现某个结论已经失去了证据链。
  3. 让 AI “基于知识库回答”，却根本不知道它拿到的是原始来源、整理后的概念，还是一篇早就过期的输出。

这些问题都不是“没存住”。

这些问题是：存住之后，系统并不会反馈它现在还能不能工作。

为什么很多笔记系统会一直重建

我之前写过一篇 《你的笔记系统为什么一直在重建？》，核心判断是：问题不在工具，而在你从来没有定义过什么值得记，什么该晋升，什么该淘汰。

现在我更想把这个判断再往前推一步：

很多知识系统之所以反复重建，不只是因为分类做得差，而是因为它从一开始就被当成 storage 来设计，而不是 runtime。

当你把知识库理解成 storage，你默认优化的是：

这些都重要，但还不够。

因为 runtime 关心的是另一组问题：

如果这些问题没有被系统化回答，知识库就会越来越像一个“存量越来越大、反馈越来越少”的黑盒。

黑盒一大，人就会本能地想重建。

不是因为想折腾，而是因为旧系统已经不敢信了。

Runtime 和 storage 的区别，不是口号，是反馈结构

我现在更愿意这样区分两者：

维度storageruntime
主要目标把内容存住让知识持续参与工作
最小单元一篇篇笔记有类型的知识对象
结构关注点文件怎么放对象如何关联、流转、失效
改动后的反馈基本没有有检查、分析和状态更新
与 AI 的关系喂一堆 Markdown 让它猜给一套可查询、可验证的知识运行面

如果要让知识库变成 runtime，我觉得至少要有四层能力。

1. 对象模型

系统里不是只有“笔记”这一种东西。

来源、项目、概念、实体、决策、约束、输出，它们的职责和命运都不一样。

如果所有内容都以同一种文档形态堆在一起，后面就很难知道：

对象模型的价值，不是为了分类得更漂亮，而是为了让系统知道自己在处理什么。

2. 生命周期

不是所有信息都值得长期维护。

有些内容停在 raw 就够了，有些需要 parsed、linked、promoted、maintained，有些最终会 superseded 或 archived。

生命周期不是形式主义。

它解决的是：哪些内容值得继续投入维护成本。

3. 健康检查

代码世界里，大家默认接受编译器、测试和 CI 的存在。

知识库也应该有类似的反馈：

如果一个系统只能无限写入、不能持续检查，那它迟早会在沉默中退化。

4. 影响分析

这一点最像真正的 runtime。

改一个核心概念，不该只被理解成“改了一篇笔记”。

它实际上是在改系统中的一个事实节点。只要这个节点被项目、决策、输出复用，它就会产生传播效应。

所以系统应该能回答：

只有当知识改动开始具备可观测性，知识库才真正从静态存储变成运行中的系统。

distill-vault：把知识库做成一套 runtime

distill-vault 就是我对这个问题的产品化回答。

它不是再做一个笔记工具，而是把 Obsidian 兼容 vault 变成一套可扫描、可解析、可建图、可检查、可分析、可被 AI 直接调用的知识库运行时。

目前这套 runtime 的骨架大概是这样：

对象层

知识先按对象进入系统，而不是先堆成一摞文件。

当前核心对象包括：

这让系统第一次能区分“原始输入”“稳定认知”“项目上下文”和“对外产物”。

Pipeline 层

它的主干是一条 6 阶段流水线：

Scan → Parse → Graph → Analyze → Promote → Export

我很看重这条流水线，不只是因为它把步骤排出来了，而是因为它把知识处理变成了可重复执行的过程。

这条链路更像 CI，而不是“记完一篇笔记就结束”。

图谱层

底层我用了 KuzuDB。

因为真正重要的从来不是 Markdown 文件本身，而是：

一旦这些关系进入图，很多过去只能靠人脑维护的事情就能落成查询：

检索与 Agent 接口层

如果知识库要成为 runtime，就不能只服务于“人打开来看看”。

它还要能被 AI 稳定调用。

所以我在 distill-vault 里把搜索、对象上下文、Cypher 查询、上下游影响分析、变更检测、pipeline 触发这些能力都暴露成了 MCP 工具。

这样 Agent 拿到的就不再只是“几篇可能相关的 Markdown”，而是一套：

的知识运行面。

AI 真正需要的不是更多文本，而是更可靠的上下文。

这不是概念图，它已经在真实 vault 上跑起来了

我不太喜欢只讲愿景，所以直接说几组已经跑出来的数据。

根据我当前维护的项目记录，distill-vault 现在的状态大概是：

这些数字不代表项目已经到终局。

但它们足够说明一件事：这不是一个停留在“概念很好”的 demo，而是一套已经打通了对象模型、图数据库、搜索、健康检查、影响分析、Agent 接口和自动化钩子的系统。

对我来说，更重要的不是“又做了一个工具”，而是终于把这句话落实成了能运行的东西：

知识库不是用来堆东西的，它是下一次构建的运行时。

为什么这件事在 AI 时代更重要

AI 把信息进入系统的速度放大了。

这既是机会，也是压力。

过去你一天可能只整理几条笔记。现在你可能同时在让 Agent：

如果知识库还是 storage 逻辑，结果通常是输入越来越多，噪声越来越厚，AI 也越来越容易在错误的层上工作。

它可能会：

所以 AI 时代的知识库，不只是“更需要搜索”。

它更需要：

这也是我为什么会把 Distill 放在整套系统的底层。

Technical Knockout 给我外部样本，Agent Workflow 负责执行闭环，而 Distill 负责把内部知识变成可维护、可复用、可继续参与工作的资产。

它不是配套件。

它是底盘。

如果只记一件事

很多知识库的失败，不是因为你没有记下来。

而是因为你记下来之后，系统再也没有告诉你：

storage 只能回答“东西还在不在”。

runtime 回答的是另一件更重要的事：

这套知识，现在还能不能工作。

如果你也在用 Obsidian 管知识、用 AI 做检索、分析、写作或开发，那我越来越相信：知识库应该像代码仓库一样被治理。

至少对我来说，distill-vault 正在把这件事从判断，慢慢变成现实。

← 返回构建记录