Files
my_wiki/wiki/practices/LLM-Wiki-Desktop-Implementation.md
T

5.3 KiB

title, source, raw_sources, tags, last_updated
title source raw_sources tags last_updated
LLM Wiki 桌面实现与外部接入 nashsu/llm_wiki README_CN; nashsu/llm_wiki mcp-server README
path hash
raw/llm_wiki/README_CN.md sha256:247c2a97f3235ada39a36808aecea3b2aec05b04438164e84857c3d602e2e6cf
path hash
raw/llm_wiki/mcp-server/README.md sha256:e22e529aacaa745c2f282d2c710c3dcc9a3f4bad8babb91b105df346b2bea2a7
个人知识库
桌面应用
MCP
API
检索
2026-08-02

LLM Wiki 桌面实现与外部接入

页面定位

本页是 llm_wiki 桌面实现(README 与 MCP Server 文档)的工程细节案例页:摄取流水线、可靠性机制与外部接入。负责可复用的工程实现;安装命令、星标统计、推广与 API 密钥示例不入知识结论。

这篇文章记录 nashsu/llm_wiki README 和 MCP Server 文档中具有工程参考价值的实现细节。安装命令、发布渠道、星标统计、外部 Skill 安装推广和 API 密钥示例均不纳入知识结论。

摄取流水线

桌面实现把摄取拆成两个顺序 LLM 调用:第一步分析实体、概念、论点、关联和矛盾;第二步依据分析结果生成来源摘要、实体页、概念页、索引、日志和 Review 项。该拆分让理解过程与批量写入分离,便于测试、重试和审阅。

实现还提供了几个可靠性机制:

  • SHA-256 增量缓存,源文件未变更时跳过重复摄取。
  • 持久化摄取队列,串行处理写入,支持重启恢复、取消和重试。
  • 每个生成页面通过 sources[] 追溯到原始资料。
  • 删除资料时进行级联清理,同时保护仍被其他来源引用的共享实体。
  • 大文件夹采用渐进式渲染,避免一次性加载全部资料。

多阶段检索

实现采用由浅入深的检索管线:

  1. 词法搜索:英文分词,中文 CJK 二元组,标题命中加权;同时搜索 Wiki 和原始来源。
  2. 可选向量搜索:通过 OpenAI 兼容的 embedding 端点,把向量存入本地 LanceDB。
  3. 图谱扩展:以搜索结果为种子,沿 Wikilink、共同来源、共同邻居和页面类型亲和度扩展,限制跳数并衰减分数。
  4. 上下文装配:按搜索和图谱综合相关性排序,加入索引、目的、语言和引用规则,并要求回答引用编号页面。

向量检索应当是可选增强,而不是系统唯一入口。没有 embedding 服务时,词法检索加图谱扩展仍应保持可用。

图谱分析

图谱关联度使用四类信号:直接链接、来源重叠、Adamic-Adar 共同邻居和类型亲和度。Louvain 社区检测用于发现自然聚类,并用社区内聚度识别内部交叉链接薄弱的区域。

图谱洞察把结构分析转成维护任务:

  • 惊奇连接:跨社区、跨类型或边缘节点与核心节点之间的关系。
  • 孤立页面:与其他内容几乎没有连接。
  • 稀疏社区:页面聚在一起,但内部链接不足。
  • 桥接节点:连接多个知识社区的枢纽。
  • 知识空白:已有页面暴露问题,但缺乏证据或专门页面。

Review 与 Deep Research

摄取时发现的不确定事项进入异步 Review 队列,操作被限制为预定义动作,例如创建页面、发起研究或跳过。用户可以在摄取完成后处理这些事项,避免一个待判断问题阻塞整个队列。

Deep Research 应从图谱洞察和 overview.mdpurpose.md 中生成领域相关主题,再让用户确认搜索主题和查询,之后把研究结果重新送入摄取流程。这样外部搜索也会成为知识库的输入,而不是停留在一次性聊天结果中。

本地 API 与 MCP 的边界

桌面应用通过仅监听 127.0.0.1 的本地 HTTP API 暴露能力,MCP Server 再调用这套 API,而不是复制搜索、图谱或权限逻辑。适合暴露的能力包括:

  • 健康检查、项目列表和文件树。
  • 允许列表内的文件读取。
  • 关键词或混合检索。
  • Review 项查询和状态更新。
  • Wikilink 图谱读取。
  • 原始资料重新扫描。

MCP 会话可以固定到一个项目,避免多项目环境中误读其他项目;文件读取通过 API 的路径允许列表执行,内部应用状态不直接暴露。默认只读,写入操作应有明确的用户授权和审计记录。

Obsidian 的协作位置

Obsidian 适合作为 Wiki 的浏览和编辑前端,LLM 负责编译与维护,Git 负责版本历史。Obsidian CLI 进一步提供了可脚本化的检查入口:可以列出 Vault 文件、搜索文本、读取文件、检查反向链接、查找孤岛页面和未解析链接、统计任务与标签。

这意味着维护流程可以把 Obsidian CLI 当作本地结构传感器:

LLM 编译 Wiki
    |
    v
Obsidian CLI 检查 unresolved / orphans / backlinks
    |
    v
Lint 或人工审阅修复问题

CLI 只负责读取和结构化检查时风险较低;创建、移动、重命名和删除文件属于有副作用操作,应保持显式调用并在批处理前确认范围。

相关研究