---
title: "LLM Wiki 的实现模式"
type: concept
confidence: medium
source: "nashsu/llm_wiki README"
raw_sources:
  - path: raw/LLM Wiki - Persistent Personal Knowledge Bases.md
    hash: "sha256:cd64125fcf5070abff12dd8f25f0371658833d08e0138bd8ee71fc7cb9bfc89d"
tags:
  - "个人知识库"
  - "LLM Wiki"
  - "检索系统"
  - "知识图谱"
last_updated: 2026-08-02
---

# LLM Wiki 的实现模式

这篇文章把 [[LLM-Wiki-Persistent-Personal-Knowledge-Bases|LLM Wiki 方法论]]映射到可实现的系统组件。重点是哪些机制能让“持续编译知识”在文件系统和桌面应用中稳定运行；项目下载、订阅、星标和其他推广信息不属于知识库内容。

## 页面定位

本页是与平台无关的实现抽象，重点是摄取队列、增量状态、混合检索、图谱分析和 Review 闭环。当前仓库的桌面 API、MCP 和 Obsidian 操作细节分别保留在 [[LLM-Wiki-Desktop-Implementation|LLM Wiki 桌面实现与外部接入]]和 [[Obsidian-CLI-Wiki-Maintenance|Obsidian CLI 作为本地 Wiki 维护工具]]。

## 摄取：先分析，再生成

比起让一次 LLM 调用同时阅读来源和修改多份 Wiki 页面，更稳妥的做法是拆成两个顺序阶段：

```text
来源文档
   |
   v
分析阶段：实体、概念、主张、矛盾、关联页面、结构建议
   |
   v
生成阶段：来源摘要、实体页、概念页、索引、日志、审阅项
```

分析阶段提供一个结构化中间结果，生成阶段只负责将分析转成文件。这样可以把“理解来源”和“修改知识库”分开审查，也便于重试、缓存和比较生成结果。每个页面应在 YAML frontmatter 中记录 `sources` 或 `raw_sources`，使结论能够追溯到原始文件。

### 增量与队列

对原始文件计算 SHA-256，未变化的文件可以跳过摄取。摄取队列应串行处理写入，避免多个 LLM 调用同时修改相同索引；队列状态持久化后，应用崩溃或重启时可以恢复。失败任务应区分可重试错误和需要人工处理的错误，并保留失败原因。

## 检索：关键词、语义和图谱互补

个人 Wiki 的规模较小时，`INDEX.md` 加文件搜索就足够；规模扩大后，可以使用分阶段检索：

1. **词法检索**：对中文使用 CJK 二元词，对英文分词并去除停用词；标题命中应获得额外权重。
2. **可选向量检索**：用兼容 OpenAI API 的 embedding 服务建立本地向量索引，发现没有共享关键词但语义相近的页面。
3. **图谱扩展**：从高分页面出发，沿 Wikilink 和来源重叠关系进行一到两跳扩展。
4. **预算控制**：按相关性分配上下文，把索引、Wiki 页面、对话历史和系统规则分别纳入预算。
5. **证据组装**：为页面编号并要求答案引用页面编号，同时保留原始来源作为核查路径。

知识图谱的相关性可以综合四类信号：直接链接、共同来源、共同邻居带来的 Adamic-Adar 分数，以及页面类型亲和度。图谱不仅用于展示，还可以发现孤立页面、稀疏社区、桥接节点和潜在研究空白。

## 文件和图谱的一致性

当来源被删除或替换时，维护流程不能只删除一个摘要页。应当：

- 根据 `sources[]`、来源摘要名称和 frontmatter 引用寻找受影响页面。
- 对共享多个来源的实体页，只移除被删除的来源，不删除页面本身。
- 从索引移除失效页面，并清理指向不存在页面的 Wikilink。
- 对新旧来源冲突保留证据和时间关系，不静默覆盖旧结论。

这类级联清理是 Wiki 与普通文件夹的关键区别：知识页面之间存在可计算的依赖关系。

## 图谱洞察与异步审阅

图谱可以主动暴露维护任务，而不是等用户偶然发现问题：

- **孤立页面**：入度或总度很低，可能是未挂载的新知识。
- **稀疏社区**：页面之间缺乏有效交叉链接，可能需要概念整理。
- **桥接节点**：连接多个主题，适合作为导航或综合页面。
- **知识空白**：已有页面提出问题但缺少来源或证据。

摄取阶段可以把需要判断的事项放入 Review 队列，例如“创建页面”“发起研究”“跳过”。将审阅异步化可以避免整个摄取任务被一个不确定判断阻塞，同时把高风险选择留给用户。

## 外部接入

一个本地 HTTP API 可以把 Wiki 暴露给外部 Agent，但应保持本机绑定、令牌保护和明确的读写边界。适合提供的接口包括：

- 健康检查和项目列表。
- 文件列表与文件内容读取。
- 关键词或混合搜索。
- Wikilink 图谱读取。
- 未解决 Review 项导出和状态更新。
- 原始来源重扫描。

MCP 可以把同一组能力包装为标准工具；Agent Skill 则负责向编码 Agent 描述何时调用这些接口、如何引用页面路径以及默认采用只读操作。接口、Skill 和 Wiki 页面应保持职责分离：协议定义调用契约，Skill 定义操作流程，Wiki 保存知识内容。

## 适合加入个人知识库的设计原则

1. 原始来源可追溯，Wiki 页面可重建，索引和日志可检查。
2. 摄取先分析后生成，避免理解和批量写入互相污染。
3. 所有增量处理都使用哈希和状态记录，避免重复消耗上下文与模型调用。
4. 关键词检索是基础，向量检索和图谱扩展按规模渐进加入。
5. 删除、替换和冲突处理必须是显式工作流，而不是手动清理。
6. Review、Lint 和来源引用共同构成质量控制闭环。
7. 外部 API 默认只读，任何写入都应有明确的权限和审计边界。

## 与 Harness 工程的关系

LLM Wiki 的三层文件结构对应 Harness 工程中的上下文与可观测性基础：`raw/` 提供事实来源，`wiki/` 提供可检索的工作上下文，Schema 和技能文件提供前馈指南，索引、日志、Lint 和 Review 提供反馈传感器。更大的知识库还需要[[Context-Budget-Management|上下文预算管理]]，以避免页面数量增长反过来淹没 Agent。

## 相关研究

- [[LLM-Wiki-Persistent-Personal-Knowledge-Bases|LLM Wiki：构建持久累积型个人知识库]]
- [[Harness-Engineering|Harness 工程]]
- [[Externalization-in-LLM-Agents|LLM Agent 中的外部化]]
- [[Memory-Systems|记忆系统]]
- [[Agent-Protocols|智能体协议]]
- [[Meta-Harness|Meta-Harness：模型 Harness 的端到端优化]]