回到 LLM Wiki 五范式

把 OpenViking 放回我们 [[开发/概念/知识库五范式|已有的知识范式框架]] 中看：

维度 LLM Wiki 原版 OpenViking
知识表示 Markdown + wikilink viking:// URI + L0/L1/L2 三层
检索方式 index.md + grep 目录递归检索 + rerank
规模承载 ~100 页 数千页（向量索引 + 分层过滤）
知识更新 手动 ingest 会话后自动提取 + 增量 DAG
权限控制 无 多租户 + ACL + 路径级权限
可观测性 无 OpenTelemetry + Prometheus + 事件总线
自进化 无 ReAct 记忆提取 + RL 训练管线
OpenViking 本质上是 LLM Wiki（范式二）+ GraphRAG（范式四的检索能力）+ 企业级基础设施 的工程融合，但核心哲学仍然是 Karpathy 的：

知识要被编译、沉淀下来，而不是每次从零检索。

L0/L1 就是"编译后的知识"——它们不是原始文档的 chunk，而是 LLM 理解了整棵目录树后产出的结构化摘要。

对 wiki-vault 的启示
回到我们自己的 wiki-vault 实践，OpenViking 有几个可以直接借鉴的设计：

L0/L1 思路可以轻量化落地：不一定需要向量数据库，给每个 wiki 目录生成一个 SUMMARY.md（L1）和一句话描述（L0），就能实现按需加载
增量 DAG：文件变更时只重新生成受影响的摘要，不全量重建
热度衰减：在 wiki 检索中引入时间衰减因子，最近更新的页面优先展示
会话后自动提取：每次有价值的对话结束后，自动更新相关 wiki 页面
五、局限与思考
OpenViking 不是银弹，它有自己的工程代价：

代价 具体表现
LLM 调用成本高 每个文件都要 LLM 生成摘要，每个目录都要生成 overview，大规模摄入时 Token 消耗巨大
延迟 递归检索需要多轮向量搜索 + 可能的 rerank，比单次向量检索慢
系统复杂度 Python + Rust + C++ 三语言栈，AGFS 文件系统 + 向量数据库 + 消息队列，部署运维门槛高
摘要质量依赖 LLM L0/L1 的质量完全取决于 LLM 的总结能力，弱模型会导致摘要失真
这些代价在企业场景下是可接受的（有运维团队、有预算），但对个人用户来说，[[开发/概念/LLM-Wiki模式|LLM Wiki 原版]]的轻量方案仍然是更务实的选择。

核心判断：OpenViking 证明了 LLM Wiki 理念可以在工程上做到大规模、分层、自进化。但它的价值更多是方向性的验证而非直接可用的产品——它告诉你"上下文分层供给"这条路是走得通的，具体的实现可以根据你自己的规模选择合适的复杂度。