106 lines
5.3 KiB
Markdown
106 lines
5.3 KiB
Markdown
---
|
|
title: "LLM Wiki 桌面实现与外部接入"
|
|
type: practice
|
|
confidence: medium
|
|
source: "nashsu/llm_wiki README_CN; nashsu/llm_wiki mcp-server README"
|
|
raw_sources:
|
|
- path: raw/llm_wiki/README_CN.md
|
|
hash: "sha256:247c2a97f3235ada39a36808aecea3b2aec05b04438164e84857c3d602e2e6cf"
|
|
- path: raw/llm_wiki/mcp-server/README.md
|
|
hash: "sha256:e22e529aacaa745c2f282d2c710c3dcc9a3f4bad8babb91b105df346b2bea2a7"
|
|
tags:
|
|
- "个人知识库"
|
|
- "桌面应用"
|
|
- "MCP"
|
|
- "API"
|
|
- "检索"
|
|
last_updated: 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.md`、`purpose.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 当作本地结构传感器：
|
|
|
|
```text
|
|
LLM 编译 Wiki
|
|
|
|
|
v
|
|
Obsidian CLI 检查 unresolved / orphans / backlinks
|
|
|
|
|
v
|
|
Lint 或人工审阅修复问题
|
|
```
|
|
|
|
CLI 只负责读取和结构化检查时风险较低；创建、移动、重命名和删除文件属于有副作用操作，应保持显式调用并在批处理前确认范围。
|
|
|
|
## 相关研究
|
|
|
|
- [[LLM-Wiki-Persistent-Personal-Knowledge-Bases|LLM Wiki：构建持久累积型个人知识库]]
|
|
- [[LLM-Wiki-Implementation-Patterns|LLM Wiki 的实现模式]]
|
|
- [[Context-Budget-Management|上下文预算管理]]
|
|
- [[Agent-Protocols|智能体协议]]
|
|
- [[Harness-Engineering|Harness 工程]]
|