Hermes Agent 番外 03 | LLM Wiki 与 Obsidian：让 AI 成为知识库维护者
前两篇番外里，我先把 Hermes Agent 接进 Open WebUI，又继续拆了多人共享时的 profile、workspace 与权限隔离。那两篇讨论的是入口和边界：怎么让更多人用得上，以及怎么让它用得安全。
这一篇往里走一步：当 Hermes 不只是聊天入口，而是真的开始读论文、整理资料、维护 Markdown 文件时，它就不再只是“问答助手”，而更像一个知识库维护者。
我最近关注到 Karpathy 提到的 LLM Wiki 思路，也看了 Ar9av/obsidian-wiki 这个项目。它们给我的启发是：RAG 解决的是临时查询，LLM Wiki 解决的是长期积累；Obsidian 可以负责展示，Hermes 可以负责维护。
如果要用 Hermes Agent、LLM Wiki 和 Obsidian 搭一个会积累的知识系统，架构应该怎么理解？哪些设计值得吸收？又有哪些边界必须提前说清楚？
一、从 RAG 到 LLM Wiki：从“临时查询”到“长期积累”
过去一提 AI 知识库，很多人的第一反应是 RAG。
RAG 的做法通常是：把资料切块，丢进向量数据库；用户提问时，系统检索相关 chunk，再交给 LLM 生成答案。
这个思路没错，但它解决的是“查”的问题，不是“积累”的问题。
RAG 更像搜索引擎：
它的局限在于：每次 query，LLM 都像第一次见到这些材料。它不会主动维护概念之间的关系，不会在你读完一篇新论文后回头更新旧页面，也不会自动标注“这里和之前那篇论文的说法冲突”。
Karpathy 提出的 LLM Wiki 思路不一样。
LLM Wiki 不是“问的时候检索”，而是“读的时候编译”。
资料进入系统时，AI 就要完成一次知识消化：
- 提炼核心概念；
- 写成稳定页面；
- 建立双向链接；
- 更新旧页面；
- 标注矛盾和不确定性；
- 维护索引和来源记录。
所以我现在更愿意这样区分：RAG 是查询系统，LLM Wiki 是积累系统。RAG 帮你临时找到答案，LLM Wiki 帮你长期维护理解。
这也是我对它真正感兴趣的地方。
我不是想让 AI 替我“存资料”，而是想让 AI 替我维护一个会生长的知识网络。
二、Obsidian 是 Viewer，LLM 是 Maintainer
`Ar9av/obsidian-wiki` 里有一句话很关键：
Obsidian is the viewer, LLM is the maintainer.
这句话把角色分得很清楚。
很多人用 Obsidian，是把它当笔记软件；但在 LLM Wiki 语境里，Obsidian 更像一个知识库 IDE。
它负责：
- 展示 Markdown 页面；
- 渲染 `[[双向链接]]`；
- 提供 Graph View；
- 让人类方便浏览、编辑、review；
- 通过 Dataview、Bases、Graph 插件做可视化。
而 LLM 负责：
- 读原始资料；
- 拆分概念；
- 写入页面；
- 维护链接；
- 更新索引；
- 做 lint 体检；
- 在旧知识和新资料之间做对齐。
这就变成了一个很有意思的分工：
这套分工里，Obsidian 不是 AI 的替代品，AI 也不是 Obsidian 的插件。它们更像是围绕同一批 Markdown 文件协作的两个角色。
Obsidian 让知识库对人类可见。
Hermes 让知识库能够被维护。
三、我第一版 Hermes LLM Wiki 的结构
我最开始搭的版本非常轻量：
这个版本的好处是简单。
`raw/` 放 PDF、网页导出、txt 原文；`wiki/` 放 Hermes 生成的消化页面；`index.md` 是目录；`log.md` 记录每次 ingest 做了什么；`CLAUDE.md` 和 `SKILL.md` 告诉 Hermes 这个知识库该怎么维护。
它已经能跑通第一篇论文：Hermes 读取《Attention Is All You Need》，自主拆成了四个页面：
- `attention-is-all-you-need.md`：论文总览；
- `scaled-dot-product-attention.md`：Scaled Dot-Product Attention；
- `multi-head-attention.md`：Multi-Head Attention；
- `positional-encoding.md`：Positional Encoding。
这一步的关键不在于“生成了四篇摘要”，而在于 Hermes 判断出：论文总览、注意力公式、多头机制、位置编码分别值得成为独立知识节点。
这就是 LLM Wiki 和普通读书笔记的差异。
普通读书笔记往往是线性的：从第一页总结到最后一页。
LLM Wiki 更像概念网络：一篇论文会被拆成多个节点，每个节点再和未来的论文发生连接。
四、obsidian-wiki 给我的几个启发
`Ar9av/obsidian-wiki` 比我的第一版更工程化。
它不是一个传统 App，也不是一个 Obsidian 插件，而是一组 Agent Skills。也就是说，它把 LLM Wiki 拆成了很多个可执行动作：
- `wiki-setup`：初始化 vault；
- `wiki-ingest`：消化资料；
- `wiki-query`：基于 wiki 回答问题；
- `wiki-lint`：检查坏链、孤儿页、frontmatter、矛盾；
- `wiki-status`：查看知识库状态；
- `cross-linker`：补充双向链接；
- `tag-taxonomy`：维护标签体系；
- `wiki-export`：导出图谱；
- `hermes-history-ingest`：把 Hermes 历史也纳入知识库。
我看完以后，最大的感受是：LLM Wiki 不是一个 prompt，而是一套协议。
如果只靠一次 prompt，AI 可以帮你写一篇摘要。
但如果你想长期维护一个知识库，就需要明确约定：目录结构是什么、页面 frontmatter 怎么写、来源怎么记录、链接怎么命名、什么时候更新旧页面、什么时候标注不确定、什么时候触发 lint。
这里面最值得我吸收的有五个设计。
1. `.manifest.json`：记录 ingest 状态
我的第一版有 `log.md`，但 `log.md` 更适合人读。
如果要让 Hermes 长期自动维护，最好还需要一个机器可读的 `.manifest.json`，记录每个 source 的 hash、摄入时间、生成了哪些页面、更新了哪些页面。
这样下一次 ingest 时，Hermes 就能知道：哪些文件已经处理过，哪些文件发生了变化，哪些页面可能需要重建。
2. `hot.md`：给下一次 session 的热缓存
Hermes 每次新会话都需要重新恢复上下文。
如果每次都扫完整个 wiki，成本会越来越高。`hot.md` 的设计很巧：它保存最近活跃主题、关键结论、未解决问题、最近更新页面，相当于给 Agent 的快速启动页。
人类进 Obsidian 看 `index.md`，Agent 进知识库先看 `hot.md`。
3. provenance markers：区分事实、推断和不确定
LLM Wiki 最大的风险不是“写得不够多”，而是“把推断写成事实”。
所以页面里需要区分：
- extracted：原文明确说过的；
- inferred：AI 基于多个来源推断出来的；
- ambiguous：来源模糊或存在争议的。
这比单纯要求“不要幻觉”更实际。
因为 LLM Wiki 本来就需要综合和推理，关键不是禁止推理，而是把推理标出来。
4. `_raw/`：给临时资料一个入口
日常使用里，我们不只会摄入论文 PDF，还会有网页剪藏、聊天记录、灵感片段、临时摘抄。
这些东西直接放进正式 wiki 会污染结构，但完全不收又会丢。
- 作者:Vemperor
- 链接:https://tangly1024.com/article/hermes-extra-llm-wiki-obsidian
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
