把 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.mdL1和一句话描述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 理念可以在工程上做到大规模、分层、自进化。但它的价值更多是方向性的验证而非直接可用的产品——它告诉你上下文分层供给这条路是走得通的具体的实现可以根据你自己的规模选择合适的复杂度。