文章目录

别再把“知识库”都叫 RAG 了：RAG、LLM Wiki、Obsidian、Hermes Agent 到底有什么区别？

1. 先说结论：别再把所有“大模型知识库”都叫 RAG 了

1.1 一个常见误解：知识库不就是“上传文档，然后问 AI”吗？

现在很多人第一次接触“大模型知识库”时，脑子里通常会冒出一个非常自然的想法：

不就是把 PDF、Word、网页、Markdown 上传进去，然后让 AI 回答问题吗？

这句话不能说错，但它只说到了最表层。

就像你不能把“浏览器、搜索引擎、维基百科、个人笔记软件、自动化爬虫”全部叫成“查资料工具”一样，大模型知识库内部其实也有完全不同的技术路线。

它们虽然都能回答问题，但底层逻辑差别非常大：

同样是“问知识库一个问题”：

RAG 做的是：临时帮你搜几段资料，再让 LLM 组织答案

LLM Wiki 做的是：先把资料长期整理成一套结构化 Wiki，再让 LLM 基于 Wiki 回答

Obsidian 做的是：把这些 Markdown 知识页面变成人类可以浏览、编辑、链接、可视化的知识空间

Hermes Agent 做的是：让一个长期运行的 Agent 自动帮你收集资料、更新 Wiki、维护链接、检查矛盾

所以真正进入 AI 产品开发以后，你会发现：

“知识库”不是一种东西，而是一组技术架构。

它可以是搜索系统，也可以是笔记系统；可以是问答系统，也可以是自动维护的知识操作系统。

1.2 三种方法的第一印象：它们到底像什么？

为了让本科生、刚读研的同学一开始就能建立直觉，可以先用一个类比理解这三种路线。

┌────────────────────────────────────────────────────────────┐
│                    大模型知识库的三种路线                    │
├────────────────────────────────────────────────────────────┤
│  1. RAG 知识库                                               │
│     像：搜索引擎 + 临时资料包                                  │
│     特点：用户一问，系统马上去文档库里搜相关片段，再交给 LLM 回答 │
├────────────────────────────────────────────────────────────┤
│  2. LLM Wiki + Obsidian                                      │
│     像：AI 帮你维护的维基百科 + 本地知识库 IDE                  │
│     特点：LLM 把资料整理成 Markdown 页面，Obsidian 负责浏览和编辑 │
├────────────────────────────────────────────────────────────┤
│  3. Hermes Agent + LLM Wiki + Web / Obsidian                 │
│     像：一个自动维护知识库的数字员工                            │
│     特点：Agent 长期在线，自动摄取资料、更新页面、维护索引和链接   │
└────────────────────────────────────────────────────────────┘

更短一点说：

RAG             = 会搜索的知识库
LLM Wiki        = 会整理的知识库
Obsidian        = 好阅读、好编辑、好可视化的知识库界面
Hermes Agent    = 会自己干活、自己更新、自己维护的知识库管家

如果用更形象的比喻：

RAG 像“百度 / Google”：你问什么，它临时帮你搜什么。

LLM Wiki 像“维基百科”：知识已经被整理成主题页、概念页、人物页、对比页。

Obsidian 像“程序员的 VSCode”：它不是知识本身，而是打开、编辑、链接、管理 Markdown 知识库的工作台。

Hermes Agent 像“研究助理”：你把资料丢给它，它自己读、自己归类、自己写总结、自己更新目录。

1.3 三条路线的核心区别：搜索、整理、自动维护

很多人混淆这几种方法，是因为它们最后都能回答问题。

但它们的区别不在“能不能回答”，而在于：

知识在回答之前，被处理到了什么程度？

可以看下面这个流程图。

用户上传资料
     │
     ▼
┌──────────────────────┐
│  原始文档层 Raw Data  │
│ PDF / Word / 网页 / 论文 │
└──────────────────────┘
     │
     ├──────────────────────────────────────────────┐
     │                                              │
     ▼                                              ▼
┌──────────────────────┐                  ┌─────────────────────────┐
│      RAG 路线          │                  │      LLM Wiki 路线        │
│ 文档切块 + 向量检索     │                  │ LLM 阅读 + 总结 + 建链接   │
└──────────────────────┘                  └─────────────────────────┘
     │                                              │
     ▼                                              ▼
┌──────────────────────┐                  ┌─────────────────────────┐
│ 临时检索几个 chunk     │                  │ 形成长期存在的 Wiki 页面    │
│ 塞进 Prompt 给 LLM     │                  │ 概念页 / 对比页 / 索引页     │
└──────────────────────┘                  └─────────────────────────┘
     │                                              │
     ▼                                              ▼
┌──────────────────────┐                  ┌─────────────────────────┐
│      回答问题          │                  │ 基于结构化知识回答问题       │
└──────────────────────┘                  └─────────────────────────┘
                                                    │
                                                    ▼
                                      ┌─────────────────────────┐
                                      │ Hermes Agent 路线         │
                                      │ 自动摄取 + 自动更新 + 自动维护 │
                                      └─────────────────────────┘

所以三者最本质的差别是：

RAG：
资料还是原始资料，只是在提问时临时检索。

LLM Wiki：
资料已经被 LLM 消化成结构化知识页。

Hermes Agent：
不仅有结构化知识页，还有一个长期运行的 Agent 帮你维护它。

1.4 从工程角度看：它们的“知识流动方式”完全不同

如果从工程架构看，RAG、LLM Wiki、Hermes Agent 的数据流完全不一样。

🧩 RAG 的知识流动方式：查询时临时检索

[ 用户问题 ]
     │
     ▼
[ Embedding 用户问题 ]
     │
     ▼
[ 向量数据库检索 TopK 文档块 ]
     │
     ▼
[ 拼接 Prompt ]
     │
     ▼
[ LLM 生成答案 ]
     │
     ▼
[ 返回答案 + 引用片段 ]

它的特点是：

知识没有提前被深度整理。
系统只是在用户提问时，临时找几个相关片段。

所以 RAG 很像一个“资料检索员”：

你问一个问题，它马上跑进资料库，翻出几页可能相关的内容，然后交给大模型组织语言。

📚 LLM Wiki + Obsidian 的知识流动方式：先整理，再回答

[ 原始资料 raw/ ]
     │
     ▼
[ LLM 阅读资料 ]
     │
     ▼
[ 提取概念 / 人物 / 方法 / 结论 / 矛盾点 ]
     │
     ▼
[ 生成或更新 Markdown Wiki 页面 ]
     │
     ▼
[ Obsidian 浏览、编辑、图谱可视化 ]
     │
     ▼
[ 后续问答基于 Wiki 页面进行 ]

它的特点是：

知识不是每次临时找，而是提前被整理成体系。

这就像你读论文时，不只是把 PDF 放进文件夹，而是整理出：

- 这篇论文解决了什么问题？
- 它用了什么方法？
- 和前人方法有什么区别？
- 实验结果怎么样？
- 它和我研究方向有什么关系？
- 它和另一篇论文有没有冲突？

所以 LLM Wiki 更像一个“知识编辑部”。

🧑‍💻 Hermes Agent + LLM Wiki 的知识流动方式：Agent 自动维护

[ 用户丢进一篇文章 / 论文 / 网页 ]
          │
          ▼
[ Hermes Agent 接收任务 ]
          │
          ▼
[ 自动判断资料类型 ]
          │
          ▼
[ 读取 raw 文件或网页 ]
          │
          ▼
[ 调用 LLM 总结、分类、抽取关键信息 ]
          │
          ▼
[ 更新已有 Wiki 页面 / 新建页面 ]
          │
          ▼
[ 更新 index.md / backlinks / log.md ]
          │
          ▼
[ 可选：提交 Git / 发布 Web / 同步 Obsidian ]

它的特点是：

不只是知识库，而是一个知识库维护系统。

RAG 需要你上传文档。

LLM Wiki 需要你让 LLM 整理资料。

Hermes Agent 更进一步：你把资料丢进去，它自己决定该怎么处理。

这也是为什么 Hermes Agent 路线更像一个“数字员工”，而不是普通工具。

1.5 用一个具体例子理解：假设你正在研究“多模态大模型”

假设你是一个刚读研的学生，导师让你研究多模态大模型。你现在手里有这些资料：

LLaVA 论文
BLIP 论文
Flamingo 论文
CLIP 论文
MiniGPT-4 论文
GPT-4V 技术报告
一些知乎文章
一些 GitHub 项目 README
一些自己的阅读笔记

如果你用 RAG，它会怎么做？

你问：
“LLaVA 和 Flamingo 有什么区别？”

RAG 系统会：
1. 把问题向量化
2. 在所有论文 chunk 里检索相关片段
3. 找到几个包含 LLaVA、Flamingo、visual instruction tuning、perceiver resampler 的片段
4. 塞给 LLM
5. 让 LLM 生成一个对比回答

这个方法很快，但它的问题是：

它只是临时找了几个片段。
如果没检索到关键章节，答案可能就不完整。

如果你用 LLM Wiki + Obsidian，它会怎么做？

LLM 会提前帮你整理出：

wiki/models/LLaVA.md
wiki/models/Flamingo.md
wiki/models/BLIP.md
wiki/concepts/visual_instruction_tuning.md
wiki/concepts/vision_language_alignment.md
wiki/comparisons/LLaVA_vs_Flamingo.md
wiki/index_multimodal_llm.md

你再问：

“LLaVA 和 Flamingo 有什么区别？”

系统就可以直接基于已经整理好的对比页、概念页、模型页回答。

这个答案通常更系统，因为知识已经被提前消化过。

如果你用 Hermes Agent，它会怎么做？

你把新论文链接发给 Telegram Bot：

“帮我加入多模态知识库。”

Hermes Agent 自动执行：
1. 下载或读取论文
2. 判断它属于多模态大模型方向
3. 总结论文贡献
4. 更新 index_multimodal_llm.md
5. 新建或修改相关模型页
6. 如果发现它和旧论文观点冲突，写入 contradictions.md
7. 如果有代码仓库，补充 GitHub 链接
8. 最后告诉你：Wiki 已更新

这就是三者的区别：

RAG：你问的时候，它才去找。

LLM Wiki：你问之前，知识已经被整理好。

Hermes Agent：你甚至不用亲自整理，它会帮你维护。

1.6 从代码层面看：三种方法的伪代码完全不一样

为了更直观，我们可以用伪代码理解三种知识库的底层逻辑。

🚀 RAG 的核心函数：retrieve_then_generate()

def rag_answer(user_question):
    # 1. 把用户问题转成向量
    query_vector = embedding_model.encode(user_question)

    # 2. 从向量数据库里找最相似的文档块
    chunks = vector_db.search(
        vector=query_vector,
        top_k=5
    )

    # 3. 把检索到的片段拼进 Prompt
    context = "\n\n".join([chunk.text for chunk in chunks])

    prompt = f"""
    请根据下面资料回答用户问题。

    【资料】
    {context}

    【用户问题】
    {user_question}
    """

    # 4. 调用大模型生成答案
    answer = llm.generate(prompt)

    return answer

这个函数的核心是：

先检索，再生成。

它不关心整个知识体系长什么样，只关心这次问题需要哪些片段。

📚 LLM Wiki 的核心函数：compile_documents_to_wiki()

def update_llm_wiki(new_document):
    # 1. 读取原始资料
    raw_text = read_document(new_document)

    # 2. 让 LLM 抽取结构化信息
    extracted = llm.extract(
        text=raw_text,
        schema={
            "main_topic": "主题",
            "key_concepts": "关键概念",
            "methods": "方法",
            "claims": "主要结论",
            "related_pages": "相关页面",
            "conflicts": "可能冲突"
        }
    )

    # 3. 判断需要更新哪些 Wiki 页面
    target_pages = plan_wiki_updates(extracted)

    # 4. 更新 Markdown 页面
    for page in target_pages:
        old_content = read_markdown(page)
        new_content = llm.rewrite_or_append(
            old_content=old_content,
            new_information=extracted
        )
        write_markdown(page, new_content)

    # 5. 更新索引和反向链接
    update_index()
    update_backlinks()

    return "Wiki updated"

这个函数的核心是：

先理解，再沉淀。

它不是简单地把资料放进数据库，而是把资料“编译”成 Wiki 页面。

🧑‍💻 Hermes Agent 的核心函数：agent_loop()

def hermes_agent_loop():
    while True:
        # 1. 等待用户输入、网页链接、文件上传或定时任务
        task = wait_for_new_task()

        # 2. 判断任务类型
        if task.type == "new_article":
            handle_new_article(task)

        elif task.type == "ask_question":
            answer_from_wiki(task)

        elif task.type == "weekly_review":
            generate_weekly_summary()

        elif task.type == "lint_wiki":
            check_dead_links_and_conflicts()

        # 3. 写入操作日志
        write_log(task)

        # 4. 可选：提交 Git，发布网页
        git_commit_if_needed()
        publish_site_if_needed()

这个函数的核心是：

长期运行，自动维护。

它已经不是一个简单问答函数，而是一个 Agent 工作流系统。

1.7 一个更硬核的架构拓扑图：三种路线在系统里的位置

如果把一个完整 AI 知识库产品画成架构图，三者大概处在不同层级：

                         ┌────────────────────────┐
                         │      用户入口层          │
                         │ Web / App / Telegram / CLI │
                         └───────────┬────────────┘
                                     │
                                     ▼
                         ┌────────────────────────┐
                         │       Agent 调度层       │
                         │ Hermes / Auto Agent / Task │
                         └───────────┬────────────┘
                                     │
                 ┌───────────────────┼───────────────────┐
                 │                   │                   │
                 ▼                   ▼                   ▼
      ┌─────────────────┐   ┌─────────────────┐   ┌─────────────────┐
      │   RAG 检索层      │   │  LLM Wiki 编译层 │   │  Obsidian 展示层  │
      │ chunk / vector   │   │ Markdown / links│   │ graph / editor   │
      └────────┬────────┘   └────────┬────────┘   └────────┬────────┘
               │                     │                     │
               ▼                     ▼                     ▼
      ┌─────────────────┐   ┌─────────────────┐   ┌─────────────────┐
      │   向量数据库      │   │   Wiki 文件夹     │   │   本地 Vault      │
      │ Milvus / pgvector│   │ concepts / index │   │ Markdown notes   │
      └─────────────────┘   └─────────────────┘   └─────────────────┘

注意这里最关键的一点：

RAG 是检索层
LLM Wiki 是知识组织层
Obsidian 是人机交互层
Hermes Agent 是自动化调度层

所以它们不是简单的竞争关系。

更准确地说，它们可以组合在一起：

RAG 负责查原始资料
LLM Wiki 负责沉淀高价值知识
Obsidian 负责人类阅读和编辑
Hermes Agent 负责自动更新和维护

1.8 为什么很多人会把它们混在一起？

因为现在很多产品对外都叫“AI 知识库”。

但是从产品界面看，它们可能都长这样：

上传文件
输入问题
AI 回答

于是初学者很容易以为它们底层一样。

但真正的差别藏在后台：

有些产品只是做了 RAG 检索。

有些产品会把文档整理成结构化笔记。

有些产品会自动维护知识图谱。

有些产品只是把 Obsidian 当成 Markdown 编辑器。

有些产品会让 Agent 自己读资料、改文件、提交 Git。

这就像你看到几个软件都能“写代码”，但底层可能完全不同：

普通代码补全：预测下一行代码
Cursor Agent：能读项目、改文件、跑命令
Claude Code：更接近 Agent OS，有工具、权限、上下文调度
CI 自动修复 Agent：可以在流水线里自动修 bug

表面都是“AI 写代码”，底层架构完全不同。

知识库也是一样。

表面都是“AI 问答”，底层可能是三种完全不同的系统。

1.9 这篇文章到底要讲什么？

这篇文章不是简单介绍“怎么搭一个知识库”。

因为如果只是搭 demo，网上教程已经很多了：

Dify 上传 PDF 搭 RAG
LangChain 写一个 Retriever
Obsidian 安装插件
用 ChatGPT 总结笔记

这些都只是操作层。

这篇文章真正想讲的是：

1. RAG、LLM Wiki、Obsidian、Hermes Agent 到底分别是什么？

2. 它们的部署方式有什么区别？

3. 它们的知识流动方式有什么区别？

4. 它们各自适合哪些场景？

5. 哪种方法更适合做产品？

6. 哪种方法更适合学生和研究生做长期学习？

7. 哪种方法更消耗 Token？

8. 哪种方法知识更新最快？

9. 未来如果继续深研，还有哪些值得做的方向？

换句话说，这篇文章不是教你“点哪里上传文件”，而是帮你理解：

知识库系统背后的架构选择。

1.10 先给一个最终判断

在正式展开之前，可以先给出一个最实用的判断：

如果你只是想做企业问答、客服问答、文档问答：
优先选 RAG。

如果你想长期读论文、做研究、积累技术路线：
优先选 LLM Wiki + Obsidian。

如果你想让知识库自动更新、自动整理、自动发布：
考虑 Hermes Agent + LLM Wiki。

如果你想做一个真正强大的 AI 知识库产品：
最好不是三选一，而是组合使用。

最理想的架构其实是：

底层：RAG
负责从海量原始资料中快速找证据。

中层：LLM Wiki
负责把高价值知识沉淀成结构化页面。

上层：Hermes Agent
负责自动摄取、更新、维护、检查和发布。

界面层：Obsidian / Web
负责人类阅读、编辑、复查和分享。

可以把它理解成一套完整的知识库操作系统：

┌──────────────────────────────────────┐
│            知识库操作系统              │
├──────────────────────────────────────┤
│  用户界面层：Obsidian / Web / Telegram │
├──────────────────────────────────────┤
│  Agent 调度层：Hermes Agent             │
├──────────────────────────────────────┤
│  知识组织层：LLM Wiki                   │
├──────────────────────────────────────┤
│  检索增强层：RAG                        │
├──────────────────────────────────────┤
│  数据存储层：Raw Docs / Markdown / Vector DB │
└──────────────────────────────────────┘

所以这篇文章的核心观点可以压缩成一句话：

RAG 解决“怎么找资料”，LLM Wiki 解决“怎么整理知识”，Obsidian 解决“怎么让人读懂和管理知识”，Hermes Agent 解决“怎么让知识库自己持续生长”。

这也是为什么我们不能再把所有知识库都简单叫成 RAG。

因为未来真正有价值的知识库，不只是一个“文档问答机器人”，而是一套能够搜索、整理、链接、更新、复盘、进化的知识系统。

2. 为什么现在大家开始重新讨论知识库？

2.1 过去的默认答案：做 AI 知识库 = 做 RAG

过去两年，很多人一提到“AI 知识库”，脑子里默认浮现的基本都是 RAG。

比如下面这些场景：

企业客服机器人：
用户问售后问题，AI 从产品手册里找答案。

论文问答助手：
用户上传 PDF，AI 根据论文内容回答问题。

公司内部制度问答：
员工问报销规则、请假制度、审批流程，AI 从内部文档里找依据。

PDF 文档问答：
用户上传合同、说明书、技术文档，AI 帮忙总结和解释。

这些系统的底层流程通常都长这样：

上传文档
  ↓
文档解析
  ↓
文档切块
  ↓
Embedding 向量化
  ↓
存入向量数据库
  ↓
用户提问
  ↓
把问题也向量化
  ↓
检索相似片段
  ↓
把片段塞给 LLM
  ↓
生成答案

也就是经典的 RAG 流程。

可以画成一张更完整的架构图：

┌──────────────────────┐
│      用户上传文档       │
│ PDF / Word / Markdown │
└───────────┬──────────┘
            │
            ▼
┌──────────────────────┐
│      文档解析层         │
│ 抽取正文 / 标题 / 表格   │
└───────────┬──────────┘
            │
            ▼
┌──────────────────────┐
│      文档切块层         │
│ chunk_1 / chunk_2 / ...│
└───────────┬──────────┘
            │
            ▼
┌──────────────────────┐
│    Embedding 模型      │
│ 文本 → 向量             │
└───────────┬──────────┘
            │
            ▼
┌──────────────────────┐
│      向量数据库         │
│ Milvus / pgvector 等   │
└───────────┬──────────┘
            │
            ▼
      用户提出问题
            │
            ▼
┌──────────────────────┐
│      检索相关 chunk     │
│ TopK 相似片段           │
└───────────┬──────────┘
            │
            ▼
┌──────────────────────┐
│       拼接 Prompt       │
│ 问题 + 检索片段          │
└───────────┬──────────┘
            │
            ▼
┌──────────────────────┐
│        LLM 生成答案      │
└──────────────────────┘

这套方案非常成熟，所以很多开源平台和商业产品都围绕 RAG 展开。

例如 OpenAI 的 file search 工具就是一种托管式检索知识库能力：开发者创建 vector store、上传文件，模型在回答前可以通过语义搜索和关键词搜索检索文件内容。(OpenAI 开发者)

Dify 的 Knowledge 模块也把知识库定义为可以集成到 AI 应用中的自有数据集合，通过 RAG 把检索到的信息和用户问题一起送入 LLM，从而让模型基于外部知识回答，降低幻觉。(Dify 文档)

所以在很长一段时间里，大家对“大模型知识库”的理解基本是：

上传资料 + 向量检索 + LLM 回答 = AI 知识库。

这个理解很自然，也确实能解决很多实际问题。

但问题在于：这只是知识库的第一阶段。

2.2 RAG 为什么会成为第一代主流方案？

RAG 之所以流行，不是因为它完美，而是因为它刚好解决了大模型最痛的几个问题。

✋ 问题一：大模型不知道你的私有资料

大模型虽然很强，但它不知道你公司的内部制度、你的项目代码、你刚写的论文、你昨天上传的产品手册。

比如你问：

我们公司 2025 年新版差旅报销标准是什么？

如果没有外部知识库，LLM 只能凭训练数据和猜测回答。

而 RAG 的做法很直接：

你不知道？
没关系，我先从公司文档里帮你找出来，再让你回答。

这就相当于给大模型加了一个外部资料夹。

🛡️ 问题二：大模型容易幻觉

如果模型没有可靠依据，它可能编出一个看起来很合理但完全错误的答案。

RAG 可以把检索到的原文片段塞给模型，让模型尽量“根据资料回答”。

也就是说，RAG 不是让模型凭空回答，而是让模型做：

阅读材料
  ↓
理解问题
  ↓
基于材料组织答案
🚀 问题三：重新训练模型太贵

如果每次公司文档更新，都要重新训练大模型，那成本会非常高。

RAG 的优势是：

模型不用重新训练。
只需要更新外部知识库。

所以它非常适合企业落地。

2.3 但是 RAG 有一个根本问题：它每次都像“第一次读资料”

RAG 虽然好用，但它有一个很大的结构性问题：

它每次回答问题时，都像第一次读这些资料。

这句话非常关键。

因为 RAG 的流程是 query-time 的，也就是“用户提问时才检索”。

用户问一次
  ↓
系统检索一次
  ↓
LLM 临时阅读一次
  ↓
LLM 临时总结一次
  ↓
回答一次

下一次用户再问一个相关问题，它不会天然继承上一次已经整理好的知识结构，而是又重新开始：

用户又问一次
  ↓
系统又检索一次
  ↓
LLM 又临时阅读一次
  ↓
LLM 又临时总结一次
  ↓
再次回答

所以 RAG 像什么？

它像一个很勤快但没有长期笔记的学生。

每次老师问问题，他都立刻翻书，现场找资料，现场组织答案。

但他不会自动把这些资料整理成：

概念页
方法页
人物页
论文对比页
时间线
知识图谱
研究脉络
常见问题
矛盾观点

这就导致一个问题：

RAG 会检索，但不一定会沉淀。

2.4 用代码看 RAG：它的核心逻辑其实很“临时”

我们可以用一个简化版伪代码理解 RAG：

def rag_answer(user_question):
    # 1. 把用户问题转成向量
    query_vector = embedding_model.encode(user_question)

    # 2. 在向量数据库里搜索最相似的文档片段
    retrieved_chunks = vector_db.search(
        vector=query_vector,
        top_k=5
    )

    # 3. 把检索到的片段拼接成上下文
    context = "\n\n".join([
        chunk.text for chunk in retrieved_chunks
    ])

    # 4. 构造 Prompt
    prompt = f"""
    你需要根据下面的资料回答用户问题。

    【资料】
    {context}

    【用户问题】
    {user_question}

    请基于资料回答，不要编造。
    """

    # 5. 调用 LLM 生成答案
    answer = llm.generate(prompt)

    return answer

这段代码非常清楚地暴露了 RAG 的本质：

它不是先理解整个知识库。
它只是针对当前问题，临时找几个相关片段。

这就像考试时开卷查资料：

优点：
马上能查，马上能答。

缺点：
如果你没有提前建立知识体系，答案很容易是碎片化的。

2.5 RAG 的“临时检索”会带来哪些问题？

RAG 最大的问题不是“不能用”，而是当问题变复杂以后，它会暴露出几个明显短板。

① 检索到了相似内容，不代表检索到了关键内容

向量检索找的是“语义相似”，不是“逻辑必需”。

比如用户问：

LLaVA 和 Flamingo 在视觉语言对齐方式上有什么根本区别？

RAG 可能检索到包含 “LLaVA”“Flamingo”“vision-language” 这些词的片段。

但真正回答这个问题，可能还需要：

CLIP 的视觉编码器背景
Flamingo 的 Perceiver Resampler
LLaVA 的 visual instruction tuning
两者训练数据构造方式
两者模型连接方式
实验设定差异

如果这些内容分散在不同文档、不同章节里，普通 TopK 检索可能只拿到其中一部分。

结果就是：

检索结果看起来相关
但答案缺少关键结构
② 文档切块会破坏知识结构

RAG 一般要把长文档切成 chunk。

例如一篇论文原本结构是：

Abstract
Introduction
Related Work
Method
Experiment
Limitation
Conclusion

切块后可能变成：

chunk_001：Abstract + Introduction 前半部分
chunk_002：Introduction 后半部分 + Related Work
chunk_003：Method 前半部分
chunk_004：Method 后半部分
chunk_005：Experiment
chunk_006：Limitation + Conclusion

这会带来一个问题：

原本完整的论文逻辑，被切成了很多碎片。

LLM 每次只看到几个 chunk，很容易只理解局部，而不是理解整篇论文的技术路线。

③ 每次问答都重复消耗 Token

假设你每天都问多模态大模型相关问题。

RAG 每次都可能重新塞入类似的片段：

LLaVA 的方法介绍
Flamingo 的方法介绍
BLIP 的方法介绍
CLIP 的背景

这意味着很多 Token 被反复消耗在相同知识上。

它没有自动把这些内容沉淀成一个长期可复用的总结页。

④ RAG 很难天然形成“知识图谱”

比如你希望系统知道：

LLaVA 属于多模态大模型
LLaVA 依赖视觉编码器
视觉编码器通常使用 CLIP
Flamingo 使用 Perceiver Resampler
BLIP 和 LLaVA 都涉及视觉语言对齐
MiniGPT-4 和 LLaVA 都使用视觉指令微调

这些关系不是简单 TopK chunk 检索就能自然得到的。

它们更像是 Wiki 或知识图谱里的链接关系。

2.6 为什么 LLM Wiki 思路开始出现？

正是因为 RAG 有这些问题，所以大家开始重新思考：

知识库是不是只能“检索原文片段”？

Karpathy 的 LLM Wiki 思路就是在这个背景下出现的。

它的核心想法可以概括为一句话：

不要让 LLM 每次都从原始文档重新检索，而是让 LLM 持续维护一个结构化、互相链接、会积累的 Wiki。

也就是说，知识库不只是一个“搜索索引”，而应该变成一个“长期记忆系统”。

Karpathy 在 LLM Wiki gist 中提到，普通 RAG 是在 query time 检索相关 chunk，而 LLM Wiki 会让 LLM 增量构建和维护一个持久的、结构化的 Markdown Wiki；当新资料加入时，LLM 会更新实体页、主题总结、交叉引用和矛盾记录。(Gist)

这和传统 RAG 的区别非常大。

2.7 LLM Wiki 的思路：从“检索片段”升级到“编译知识”

如果说 RAG 是“搜索”，那么 LLM Wiki 更像“编译”。

RAG 的流程是：

原始资料
  ↓
切块
  ↓
向量化
  ↓
检索
  ↓
回答

LLM Wiki 的流程是：

原始资料
  ↓
LLM 阅读
  ↓
抽取概念
  ↓
整理结构
  ↓
建立链接
  ↓
更新 Wiki
  ↓
基于 Wiki 回答

可以画成这样：

┌──────────────────────┐
│      raw 原始资料       │
│ 论文 / 网页 / 笔记 / 文档 │
└───────────┬──────────┘
            │
            ▼
┌──────────────────────┐
│        LLM 阅读        │
│ 理解主题、概念、方法、结论 │
└───────────┬──────────┘
            │
            ▼
┌──────────────────────┐
│      信息抽取层         │
│ 概念 / 人物 / 方法 / 关系 │
└───────────┬──────────┘
            │
            ▼
┌──────────────────────┐
│      Wiki 编译层        │
│ 生成 Markdown 知识页面   │
└───────────┬──────────┘
            │
            ▼
┌──────────────────────┐
│      知识链接层         │
│ 双向链接 / 索引 / 交叉引用 │
└───────────┬──────────┘
            │
            ▼
┌──────────────────────┐
│      长期知识库         │
│ concepts / people / topics │
└──────────────────────┘

这里的关键变化是：

RAG 保存的是 chunk。
LLM Wiki 保存的是知识页面。

chunk 是碎片。

Wiki 页面是结构。

2.8 用代码看 LLM Wiki：它不是 retrieve，而是 update

RAG 的核心函数叫：

retrieve_then_generate()

而 LLM Wiki 的核心函数更像：

update_wiki_from_source()

伪代码如下：

def update_wiki_from_source(source_file):
    # 1. 读取原始资料
    raw_text = read_file(source_file)

    # 2. 让 LLM 提取结构化信息
    extracted_info = llm.extract(
        text=raw_text,
        instruction="""
        请从资料中提取：
        1. 核心主题
        2. 关键概念
        3. 重要人物或机构
        4. 方法和技术路线
        5. 主要结论
        6. 与已有知识可能相关的页面
        7. 可能存在的矛盾或争议
        """
    )

    # 3. 判断需要创建或更新哪些 Wiki 页面
    update_plan = llm.plan(
        extracted_info=extracted_info,
        existing_index=read_file("wiki/index.md")
    )

    # 4. 按计划更新页面
    for page in update_plan.target_pages:
        old_content = read_file(page)

        new_content = llm.rewrite(
            old_content=old_content,
            new_information=extracted_info,
            rule="""
            保留原有结构。
            不要删除已有来源。
            新增内容要标注来源。
            如果新资料与旧结论冲突，写入“争议与矛盾”小节。
            """
        )

        write_file(page, new_content)

    # 5. 更新索引和日志
    update_index()
    update_change_log(source_file, update_plan)

    return "Wiki updated"

这段代码和 RAG 最大的差异是：

RAG 的目标是回答当前问题。
LLM Wiki 的目标是更新长期知识结构。

所以 LLM Wiki 更适合长期研究、长期学习、长期知识沉淀。

2.9 那 Hermes Agent 为什么又被提出来？

LLM Wiki 虽然很好，但它还有一个现实问题：

谁来持续维护这个 Wiki？

一开始你可能很有热情：

今天整理 3 篇论文
明天更新 5 个概念页
后天维护 index.md
再过几天检查双向链接

但时间久了，大多数人会发现：

资料越来越多
页面越来越乱
索引没人更新
重复页面越来越多
旧结论没人检查
新旧观点发生冲突也没人记录

这时候 Hermes Agent 这类长期运行的 Agent 思路就出现了。

它解决的是 LLM Wiki 的维护问题。

你可以把它理解成：

LLM Wiki 是知识库本体。
Hermes Agent 是知识库维护员。
Obsidian / Web 是知识库界面。

整体结构大概是：

┌──────────────────────────┐
│        用户输入入口         │
│ Telegram / Web / CLI / API │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│       Hermes Agent        │
│ 任务判断 / 工具调用 / 文件操作 │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│        LLM 处理层          │
│ 总结 / 分类 / 改写 / 检查矛盾 │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│        Wiki 文件仓库        │
│ raw / wiki / index / log  │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│        展示与使用层          │
│ Obsidian / Web / GitHub Pages │
└──────────────────────────┘

这时候知识库就不只是“可查询”，而是开始变成“可生长”。

2.10 Hermes Agent 的工作方式：知识库开始有了“后台进程”

传统知识库是你主动操作：

你上传文档
你点击索引
你提问
你手动整理

Hermes Agent 路线更像一个后台进程：

你丢给它一个链接
它自己判断资料类型
它自己读取资料
它自己总结内容
它自己更新页面
它自己维护索引
它自己写日志
必要时它还能发布网站

可以用一个 Agent loop 来理解：

def hermes_agent_loop():
    while True:
        # 1. 等待任务
        task = wait_for_task()

        # 2. 判断任务类型
        if task.type == "new_document":
            ingest_document(task.file)

        elif task.type == "new_url":
            ingest_webpage(task.url)

        elif task.type == "ask_question":
            answer_from_wiki(task.question)

        elif task.type == "daily_maintenance":
            check_wiki_health()

        elif task.type == "publish":
            build_and_deploy_site()

        # 3. 记录操作日志
        write_operation_log(task)

        # 4. 可选：提交 Git
        commit_changes_if_needed()

这里最关键的变化是：

系统不再只是等待用户提问，而是可以主动维护知识库。

这就是为什么 Hermes Agent 这类路线会被关注。

它代表的是从“知识库工具”到“知识库 Agent”的升级。

2.11 三种路线背后的思维差异

现在可以把三者的思维方式放在一起看。

┌────────────────────────────────────────────────────────────┐
│                  三种知识库路线的思维差异                    │
├────────────────────────────────────────────────────────────┤
│ RAG                                                        │
│ 思维方式：用户问什么，我就临时检索什么。                      │
│ 关键词：检索、chunk、向量库、TopK、Prompt 拼接。               │
├────────────────────────────────────────────────────────────┤
│ LLM Wiki                                                   │
│ 思维方式：我先把资料整理成长期可复用的知识结构。               │
│ 关键词：Markdown、概念页、索引页、双向链接、知识沉淀。           │
├────────────────────────────────────────────────────────────┤
│ Hermes Agent + LLM Wiki                                    │
│ 思维方式：我让一个 Agent 长期帮我维护这套知识结构。             │
│ 关键词：自动摄取、自动更新、自动检查、Git 日志、Web 发布。        │
└────────────────────────────────────────────────────────────┘

再换一个更形象的比喻：

RAG：
像图书馆检索员。
你问什么，它帮你找几页书。

LLM Wiki：
像百科编辑。
它把书里的内容整理成条目、章节、索引和交叉引用。

Hermes Agent：
像长期雇佣的研究助理。
它不光整理，还会持续更新、检查、归档和发布。

2.12 为什么现在又重新讨论知识库？核心原因有 5 个

现在大家重新讨论知识库，不是因为 RAG 过时了，而是因为大家发现：

只会检索，已经不够了。

🚀 原因一：上下文窗口变长了，知识组织方式也变了

以前模型上下文短，只能塞几个 chunk。

现在很多模型上下文越来越长，系统可以一次读取更多内容。

这让大家开始思考：

既然模型能读更多内容，
为什么不让它直接维护一套结构化 Wiki？

这就是 LLM Wiki 出现的重要背景。

🧑‍💻 原因二：Agent 工具越来越成熟

过去 LLM 只能聊天。

现在 Agent 可以：

读文件
写文件
访问网页
调用命令行
修改 Markdown
提交 Git
部署网站

一旦 LLM 能操作文件系统，它就不只是“问答模型”，而可以成为“知识库维护员”。

🛡️ 原因三：企业开始关注知识可追溯和可维护

企业不只关心 AI 能不能回答，还关心：

答案来源在哪里？
引用是否可靠？
知识是否过期？
谁更新了这个结论？
不同文档是否冲突？
员工有没有权限查看？

RAG 可以解决一部分引用问题，但 Wiki + Agent 更适合做长期维护、版本管理和知识治理。

📚 原因四：个人知识管理进入 AI 时代

过去大家用 Obsidian、Notion、Logseq 做笔记。

现在大家希望 AI 不只是帮忙总结，而是能：

自动整理笔记
自动建立双向链接
自动生成学习地图
自动比较论文
自动维护技术路线
自动生成复习问题

这就推动了 LLM Wiki + Obsidian 这类工作流。

⚡ 原因五：大家开始意识到 Token 不能乱烧

RAG 每次回答都要塞检索片段。

如果经常问同一领域问题，大量 Token 会被反复消耗在相同背景知识上。

LLM Wiki 的思路是：

第一次读资料时，多花 Token 把知识整理好。
后面再问问题时，优先读整理后的 Wiki 页面。

这就有点像：

RAG：每次考试都现场翻书。
LLM Wiki：提前做成复习笔记。
Hermes Agent：请一个助教每天帮你更新复习笔记。

2.13 一个具体例子：同样是问“RAG 和 LLM Wiki 的区别”

假设你有 30 篇关于知识库的文章，用户问：

RAG 和 LLM Wiki 的本质区别是什么？
如果是 RAG

系统会这样做：

1. 检索包含 RAG、LLM Wiki、knowledge base 的片段
2. 取 TopK chunk
3. 拼进 Prompt
4. 让 LLM 总结区别

问题是：

如果 TopK 没检索到 Karpathy 的关键观点，
答案就可能只是普通 RAG 科普。
如果是 LLM Wiki

知识库里可能已经有这些页面：

wiki/concepts/RAG.md
wiki/concepts/LLM_Wiki.md
wiki/comparisons/RAG_vs_LLM_Wiki.md
wiki/concepts/query_time_retrieval.md
wiki/concepts/knowledge_compilation.md

系统可以直接基于结构化页面回答，答案更稳定。

如果是 Hermes Agent

它还可以进一步做：

1. 回答用户问题
2. 发现 comparisons/RAG_vs_LLM_Wiki.md 已经过期
3. 自动把新资料补进去
4. 更新 index.md
5. 写入 log.md：
   “2026-04-27 更新 RAG 与 LLM Wiki 对比页”

这就是三种路线的本质区别。

2.14 小结：这篇文章真正要抓住的主线

所以，现在大家重新讨论知识库，不是因为 RAG 没用了。

恰恰相反，RAG 依然是最成熟、最容易产品化的路线。

但新的问题出现了：

当资料越来越多时，只检索够不够？

当问题越来越复杂时，只拿几个 chunk 够不够？

当知识需要长期积累时，每次临时总结够不够？

当个人和团队希望知识库自己更新时，人工维护够不够？

这就是 LLM Wiki 和 Hermes Agent 出现的原因。

最后可以用一句话总结这一节：

RAG 是“临时检索”，LLM Wiki 是“长期编译”，Hermes Agent 是“自动维护”。

更形象一点：

RAG 解决的是：
我现在要找哪几段资料？

LLM Wiki 解决的是：
这些资料应该沉淀成什么知识结构？

Hermes Agent 解决的是：
谁来长期维护这套知识结构？

所以这篇文章后面要展开的核心问题就是：

如果你只是做问答产品，RAG 可能就够了。

如果你要做长期学习和研究，LLM Wiki 更有价值。

如果你想让知识库自己生长，Hermes Agent 才是更进一步的路线。

而真正强大的 AI 知识库系统，很可能不是三选一，而是三者组合。

3. 方法一：RAG 知识库——最像搜索引擎，也是现在最成熟的产品路线

3.1 RAG 到底是什么？

RAG，全称 Retrieval-Augmented Generation，中文一般叫 检索增强生成。

这个名字听起来有点学术，但它的思想其实非常简单：

大模型自己不知道的东西，先从外部知识库里找出来，再交给大模型回答。

也就是说，RAG 并不是把你的资料重新训练进模型里。

它不是这样：

公司文档 / 论文 / 产品手册
        ↓
重新训练大模型
        ↓
模型永久记住这些知识

而是这样：

公司文档 / 论文 / 产品手册
        ↓
放进外部知识库
        ↓
用户提问时临时检索
        ↓
把相关资料塞给大模型
        ↓
大模型基于资料生成答案

所以 RAG 的本质是：

R = Retrieval：先检索
A = Augmented：把检索结果增强到上下文里
G = Generation：再让大模型生成答案

可以把它理解成下面这个角色分工：

LLM 本身：
一个很会表达、很会推理、很会总结的人。

RAG 系统：
给这个人配了一个搜索引擎和资料柜。

用户问题：
你向这个人提出一个问题。

检索模块：
先帮这个人从资料柜里找相关内容。

生成模块：
这个人根据找到的资料组织答案。

更形象一点：

没有 RAG 的 LLM：
像一个记忆很好但不知道你公司内部资料的专家。

有 RAG 的 LLM：
像一个专家坐在图书馆里，回答前可以先翻资料。

所以 RAG 的核心不是“大模型变聪明了”，而是：

大模型回答时，可以临时看到你的私有资料。

3.2 RAG 为什么特别像“搜索引擎”？

RAG 和搜索引擎非常像。

传统搜索引擎是：

用户输入关键词
  ↓
搜索引擎找网页
  ↓
返回相关网页列表

RAG 是：

用户输入问题
  ↓
系统检索相关文档片段
  ↓
把片段交给 LLM
  ↓
LLM 生成自然语言答案

两者最大的区别是：

搜索引擎：
返回的是网页链接，需要人自己读。

RAG：
返回的是整理后的答案，由 LLM 帮你读完再总结。

所以 RAG 可以看成是：

搜索引擎 + 阅读理解模型 + 答案生成器。

可以画成下面这个结构：

┌─────────────────────────────┐
│          用户问题             │
│  “这个产品怎么申请退款？”      │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│        检索系统 Retrieval      │
│  从产品手册 / FAQ / 工单中找资料 │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│        相关文档片段 chunks      │
│  退款规则、时间限制、申请入口     │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│          LLM 生成答案          │
│  把片段组织成用户能看懂的回答     │
└─────────────────────────────┘

这也是为什么 RAG 特别适合做：

企业客服
产品问答
内部文档查询
PDF 问答
论文助手
知识库机器人

因为这些场景的共同点是：

答案大多已经存在于文档里，只是用户不知道去哪找。

3.3 RAG 的核心思想：不是训练模型，而是外挂知识

很多初学者会误以为：

我上传了公司文档，大模型是不是就被训练了？

不是。

RAG 不是 fine-tuning，也不是继续训练。

它只是把外部资料临时塞进大模型上下文。

可以这样理解：

Fine-tuning：
把知识或能力写进模型参数里。

RAG：
把知识放在模型外面，用的时候再拿出来。

LLM Wiki：
把知识整理成长期可读、可维护的结构化页面。

Agent Wiki：
让 Agent 自动维护这些结构化页面。

RAG 更像“开卷考试”。

模型本身不一定背下了所有资料，但考试时可以翻资料。

闭卷考试：
LLM 只能靠自己参数里的知识回答。

开卷考试：
LLM 可以临时看到检索出来的资料。

RAG：
就是给 LLM 安排了一场开卷考试。

所以 RAG 解决的核心问题是：

大模型不知道我的私有知识
        ↓
那就不要强行训练它
        ↓
让它回答前先检索我的资料
        ↓
再基于资料回答

3.4 一个标准 RAG 系统是怎么部署的？

一个完整的 RAG 知识库通常不是一个单独模块，而是一条工程流水线。

它大致分为两个阶段：

阶段一：知识入库阶段
把文档处理好，存进检索系统。

阶段二：用户问答阶段
用户提问时，检索相关资料，再让 LLM 回答。

完整流程如下：

┌────────────────────────────────────┐
│              阶段一：知识入库         │
└────────────────────────────────────┘

[ 原始文档 ]
PDF / Word / Markdown / HTML / 数据库
        ↓
[ 文档解析 ]
抽取正文、标题、表格、图片 OCR、页码
        ↓
[ 文档清洗 ]
去掉页眉页脚、乱码、重复内容、广告内容
        ↓
[ 文档切块 Chunking ]
按标题、段落、语义、固定长度切分
        ↓
[ 元数据提取 Metadata ]
文件名、章节、页码、时间、作者、权限标签
        ↓
[ Embedding 向量化 ]
把每个 chunk 转成向量
        ↓
[ 存入向量数据库 ]
Milvus / pgvector / Weaviate / Pinecone / Chroma


┌────────────────────────────────────┐
│              阶段二：用户问答         │
└────────────────────────────────────┘

[ 用户问题 ]
        ↓
[ 问题改写 / 查询扩展 ]
把口语问题改成更适合检索的 query
        ↓
[ 问题向量化 ]
把问题转成向量
        ↓
[ 向量检索 TopK ]
找最相关的文档块
        ↓
[ 可选：关键词检索 BM25 ]
补充精确关键词匹配
        ↓
[ 可选：Reranker 重排 ]
重新判断哪些片段最有用
        ↓
[ Prompt 拼接 ]
问题 + 检索片段 + 回答要求
        ↓
[ LLM 生成答案 ]
        ↓
[ 返回答案 + 引用来源 ]

3.5 RAG 系统的网络结构拓扑图

如果把 RAG 画成一个系统拓扑，它大概长这样：

                        ┌──────────────────────┐
                        │        用户界面        │
                        │ Web / App / Chatbot   │
                        └───────────┬──────────┘
                                    │
                                    ▼
                        ┌──────────────────────┐
                        │      后端 API 服务      │
                        │ 接收问题 / 鉴权 / 路由   │
                        └───────────┬──────────┘
                                    │
                  ┌─────────────────┼─────────────────┐
                  │                 │                 │
                  ▼                 ▼                 ▼
        ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
        │   Query 改写模块  │ │   权限过滤模块    │ │   日志监控模块    │
        │ 多轮问题补全      │ │ 用户能看哪些文档   │ │ 记录问题和命中率   │
        └────────┬────────┘ └────────┬────────┘ └─────────────────┘
                 │                   │
                 ▼                   ▼
        ┌──────────────────────────────────────┐
        │              检索层 Retrieval          │
        │ 向量检索 / 关键词检索 / 混合检索 / Rerank │
        └──────────────────┬───────────────────┘
                           │
                           ▼
        ┌──────────────────────────────────────┐
        │              知识存储层                │
        │ Vector DB + 文档数据库 + 元数据数据库    │
        └──────────────────┬───────────────────┘
                           │
                           ▼
        ┌──────────────────────────────────────┐
        │              Prompt 组装层             │
        │ 用户问题 + 检索结果 + 系统规则 + 引用格式 │
        └──────────────────┬───────────────────┘
                           │
                           ▼
        ┌──────────────────────────────────────┐
        │                 LLM                   │
        │ OpenAI / Claude / Qwen / DeepSeek 等   │
        └──────────────────┬───────────────────┘
                           │
                           ▼
        ┌──────────────────────────────────────┐
        │             答案后处理层               │
        │ 引用校验 / 敏感词过滤 / 格式化 / 置信度   │
        └──────────────────────────────────────┘

这张图里最容易被初学者忽略的是两个模块：

权限过滤模块
答案后处理模块

为什么它们重要？

因为企业知识库不是所有人都能看所有文档。

比如：

普通员工不能看财务薪酬表。
销售不能看研发未发布路线图。
外部客户不能看内部工单。

所以企业级 RAG 不只是“检索相似内容”，还必须先判断：

这个用户有没有权限看到这些内容？

3.6 RAG 的核心代码逻辑：从入库到问答

为了让你真正理解 RAG，不只是看流程图，我们可以写一个简化版伪代码。

3.6.1 文档入库函数：ingest_documents()

这个函数负责把原始文档变成可检索的向量数据。

def ingest_documents(file_paths):
    """
    文档入库流程：
    1. 读取文件
    2. 解析文本
    3. 切分 chunk
    4. 生成 embedding
    5. 写入向量数据库
    """

    for file_path in file_paths:
        # 1. 读取原始文档
        raw_text = document_loader.load(file_path)

        # 2. 清洗文本
        clean_text = text_cleaner.clean(raw_text)

        # 3. 切分文档
        chunks = chunker.split(
            text=clean_text,
            chunk_size=800,
            chunk_overlap=120
        )

        # 4. 为每个 chunk 添加元数据
        chunk_records = []
        for i, chunk in enumerate(chunks):
            metadata = {
                "source_file": file_path,
                "chunk_id": i,
                "page": chunk.page,
                "section": chunk.section,
                "permission": "internal"
            }

            # 5. 生成向量
            vector = embedding_model.encode(chunk.text)

            chunk_records.append({
                "text": chunk.text,
                "vector": vector,
                "metadata": metadata
            })

        # 6. 写入向量数据库
        vector_db.insert(chunk_records)

这个函数里最关键的是三个细节：

chunk_size：
每个文档块多长。

chunk_overlap：
相邻 chunk 之间保留多少重叠内容，防止语义断裂。

metadata：
记录来源、页码、章节、权限，用于引用和权限控制。

如果这三个地方做不好，后面回答质量会很差。

3.6.2 用户问答函数：rag_answer()

这个函数负责用户提问时检索资料并生成答案。

def rag_answer(user_question, user_id):
    """
    RAG 问答流程：
    1. 改写用户问题
    2. 检索相关文档块
    3. 权限过滤
    4. 重排
    5. 拼 Prompt
    6. 调用 LLM
    """

    # 1. 查询改写：把口语问题改成更适合检索的问题
    rewritten_query = query_rewriter.rewrite(user_question)

    # 2. 用户问题向量化
    query_vector = embedding_model.encode(rewritten_query)

    # 3. 向量检索 TopK
    candidate_chunks = vector_db.search(
        vector=query_vector,
        top_k=30
    )

    # 4. 权限过滤：只保留用户有权限看的 chunk
    allowed_chunks = permission_filter.filter(
        user_id=user_id,
        chunks=candidate_chunks
    )

    # 5. Rerank 重排：从 30 个候选里选最有用的 5 个
    final_chunks = reranker.rerank(
        query=user_question,
        chunks=allowed_chunks,
        top_k=5
    )

    # 6. 拼接上下文
    context = "\n\n".join([
        f"[来源: {chunk.metadata['source_file']}]\n{chunk.text}"
        for chunk in final_chunks
    ])

    # 7. 构造 Prompt
    prompt = f"""
你是一个严谨的知识库问答助手。

请只根据【参考资料】回答用户问题。
如果资料中没有答案，请明确说“知识库中没有找到相关信息”。
不要编造。

【参考资料】
{context}

【用户问题】
{user_question}

【回答要求】
1. 先直接回答结论。
2. 再列出依据。
3. 如果可能，请标注来源文件。
"""

    # 8. 调用 LLM
    answer = llm.generate(prompt)

    return answer

这段代码展示了 RAG 的核心思想：

不是让 LLM 自己猜。
而是先检索，再约束 LLM 基于资料回答。

3.7 RAG 里面最关键的 6 个模块

一个真正能用的 RAG 系统，不只是“向量数据库 + LLM”。

它至少有 6 个关键模块。

🧩 模块一：文档解析 Document Parser

不同文件格式解析难度完全不同。

Markdown：
最容易解析，标题结构清楚。

Word：
需要处理段落、标题、表格、批注。

PDF：
最麻烦，可能有双栏、页眉页脚、表格错乱、扫描图片。

网页：
需要去广告、导航栏、脚本、无关内容。

数据库：
需要把结构化字段转成自然语言或半结构化文本。

很多 RAG 系统效果差，不是模型不行，而是第一步文档解析就已经乱了。

比如 PDF 解析后变成这样：

第 一 章 产 品 介 绍
本 产 品 支 持
AI 智 能 问 答

那后面的 embedding 和检索都会受影响。

🧩 模块二：文档切块 Chunking

切块是 RAG 的灵魂之一。

常见切块方式有：

固定长度切块：
每 500 或 1000 字切一块，简单但容易切断语义。

按段落切块：
保留自然段结构，适合文章和说明文档。

按标题层级切块：
保留章节结构，适合论文、技术文档、产品手册。

语义切块：
根据语义边界切分，效果好但实现复杂。

滑动窗口切块：
相邻 chunk 有重叠，减少上下文断裂。

错误切块示例：

chunk_1：
退款申请需要在订单完成后 7 天内提交。超过

chunk_2：
7 天后，系统将不再支持自动退款。

如果用户问“退款期限是多少天”，检索只拿到 chunk_2，就会丢失关键信息。

更好的切块应该是：

chunk：
退款申请需要在订单完成后 7 天内提交。超过 7 天后，系统将不再支持自动退款。

所以 RAG 里有一句非常重要的话：

切块质量决定检索上限，模型能力决定生成上限。

🧩 模块三：Embedding 向量化

Embedding 的作用是把文本变成向量。

例如：

“如何申请退款？”
“退款流程在哪里？”
“订单不想要了怎么办？”

这三句话表面文字不同，但语义接近。

Embedding 模型会把它们映射到向量空间中相近的位置。

可以理解成：

原始文本：
“如何申请退款？”

Embedding 后：
[0.023, -0.118, 0.452, ..., 0.009]

RAG 检索时，就是比较问题向量和文档 chunk 向量之间的相似度。

常见相似度计算是 cosine similarity：

def cosine_similarity(a, b):
    return dot(a, b) / (norm(a) * norm(b))

它的含义是：

两个向量方向越接近，语义越相似。
🧩 模块四：向量数据库 Vector Database

向量数据库负责存储和检索 embedding。

常见选择包括：

Milvus：
适合大规模向量检索，企业和科研常用。

pgvector：
PostgreSQL 插件，适合已经使用 PostgreSQL 的项目。

Weaviate：
功能完整，支持向量检索和对象管理。

Pinecone：
托管式向量数据库，省运维。

Chroma：
轻量，适合 demo 和本地开发。

向量数据库里通常不只存向量，还会存：

chunk 文本
来源文件
页码
章节标题
更新时间
权限标签
文档类型
业务标签

这就是 metadata。

没有 metadata，RAG 很难做引用、过滤和权限控制。

🧩 模块五：Reranker 重排

第一轮向量检索可能找出 30 个候选 chunk。

但这 30 个里面不一定每个都真正有用。

Reranker 的作用是：

重新判断：
这些 chunk 哪几个最适合回答当前问题？

它一般比 embedding 检索更精细，但速度更慢。

所以常见做法是：

第一步：
向量数据库快速召回 Top 30。

第二步：
Reranker 精排出 Top 5。

第三步：
只把 Top 5 塞给 LLM。

这就像招聘：

向量检索：
先从 10000 份简历里筛出 30 份。

Reranker：
再从 30 份里挑出最合适的 5 份。
🧩 模块六：Prompt 组装

最后一步是把检索片段和用户问题拼成 Prompt。

一个最简单的 Prompt 是：

请根据以下资料回答问题：

资料：
{retrieved_context}

问题：
{user_question}

但企业级 RAG 通常会更严格：

你是企业知识库助手。
你只能根据参考资料回答。
如果参考资料中没有答案，请说不知道。
不要编造公司政策。
回答时必须给出引用来源。
如果多个资料冲突，请指出冲突。

Prompt 组装的好坏，会直接影响答案是否可靠。

3.8 RAG 的部署方式：从 Demo 到企业级系统

RAG 可以非常简单，也可以非常复杂。

3.8.1 初学者 Demo 级部署

适合本科生、研究生、个人学习。

Dify / FastGPT / AnythingLLM
        ↓
上传 PDF / Markdown
        ↓
自动切块和向量化
        ↓
选择大模型 API
        ↓
得到一个知识库问答机器人

优点：

上手快
不用写太多代码
适合演示和课程项目

缺点：

可控性有限
复杂检索策略不好调
企业权限和深度定制有限
3.8.2 开发者工程级部署

适合做毕业设计、科研原型、内部工具。

LangChain / LlamaIndex
        +
Embedding 模型
        +
Chroma / pgvector / Milvus
        +
OpenAI / Claude / Qwen / DeepSeek
        +
后端 API

这类部署可以自己控制：

怎么切块
怎么检索
TopK 取多少
要不要 rerank
怎么拼 prompt
怎么返回引用
3.8.3 企业产品级部署

企业级 RAG 会复杂很多。

文档接入层：
飞书 / Confluence / Notion / SharePoint / 数据库 / 网盘

解析清洗层：
PDF 解析、表格解析、OCR、去重、版本管理

索引层：
向量索引 + 关键词索引 + metadata 索引

权限层：
用户身份、部门权限、文档权限、行级权限

检索层：
混合检索、rerank、多路召回、查询改写

生成层：
LLM、Prompt 模板、引用控制、拒答机制

监控层：
命中率、用户反馈、答案质量、Token 成本、延迟

企业级系统最重要的不是“能不能回答”，而是：

答得准不准？
有没有引用？
有没有权限泄露？
有没有编造？
更新是否及时？
成本是否可控？
延迟是否能接受？

3.9 RAG 的优点

RAG 最大的优点是：

成熟、通用、容易产品化。

🚀 优点一：知识更新快

如果公司文档更新了，不需要重新训练模型。

只需要：

上传新文档
  ↓
重新解析
  ↓
重新切块
  ↓
重新向量化
  ↓
更新索引

用户下次提问时，就可以检索到新内容。

这对企业非常重要。

因为企业知识变化很快：

产品价格会变
报销制度会变
接口文档会变
客服话术会变
法律条款会变

RAG 的好处是：

知识更新在外部数据库完成，
不需要动大模型本身。
🚀 优点二：适合大规模文档

几十万、几百万篇文档不可能全部塞进 LLM 上下文。

但 RAG 可以只检索最相关的几段。

100 万份文档
        ↓
检索 Top 5 或 Top 10
        ↓
只把这几段交给 LLM

这就是 RAG 的强项：

用检索解决规模问题。

🚀 优点三：工程生态成熟

现在围绕 RAG 的工具非常多：

平台层：
Dify / FastGPT / AnythingLLM

开发框架：
LangChain / LlamaIndex

向量数据库：
Milvus / Weaviate / Pinecone / Chroma / pgvector

托管能力：
OpenAI file search 等

模型层：
OpenAI / Claude / Qwen / DeepSeek / GLM

这意味着你不用从零造轮子。

如果是课程项目，Dify 很快能搭出来。

如果是科研或工程项目，LangChain / LlamaIndex 可以快速实验。

如果是企业级系统，可以换成 Milvus、pgvector、权限系统和自定义后端。

🚀 优点四：适合嵌入产品

RAG 非常适合做成产品功能。

例如：

客服系统：
用户问问题，RAG 从 FAQ 和产品手册中找答案。

企业搜索：
员工问制度，RAG 从内部文档中找依据。

论文助手：
学生上传 PDF，RAG 回答论文相关问题。

法律助手：
律师上传合同，RAG 检索相关条款。

开发文档助手：
程序员问接口用法，RAG 从 API 文档中找示例。

它的产品形态很清晰：

一个输入框
一个知识库
一个回答区域
一个引用来源

这就是为什么 RAG 是现在最成熟的知识库产品路线。

3.10 RAG 的缺点

RAG 虽然成熟，但问题也很明显。

✋ 缺点一：切块容易破坏语义

文档本来是连续的。

但 RAG 要把文档切成很多 chunk。

一旦切块不好，就会破坏原本的逻辑。

例如一篇论文中：

第 2 页：
提出方法定义。

第 8 页：
展示实验结果。

第 12 页：
说明方法局限性。

如果用户问：

这个方法有什么优势和局限？

RAG 可能只检索到第 2 页和第 8 页，没有检索到第 12 页。

结果答案就会只讲优势，不讲局限。

这不是 LLM 不聪明，而是：

它没看到局限性那一段。

✋ 缺点二：检索不等于理解

向量检索找的是“语义相似”，不是“逻辑必需”。

比如用户问：

为什么 LLaVA 的视觉指令微调和 Flamingo 的 few-shot 多模态学习路线不同？

要回答这个问题，可能需要同时理解：

CLIP
视觉编码器
投影层
语言模型
训练数据构造
instruction tuning
few-shot prompting
Perceiver Resampler

普通 RAG 可能只检索到几个包含 LLaVA 和 Flamingo 的片段，却漏掉 CLIP 或 instruction tuning 的背景。

结果答案看起来对，但不够深。

所以 RAG 的一个根本限制是：

它擅长找相似片段。
但不天然擅长建立完整知识结构。
✋ 缺点三：每次都要重新检索和拼接

RAG 不会天然积累知识。

今天你问：

LLaVA 和 Flamingo 有什么区别？

系统检索一次，总结一次。

明天你又问：

LLaVA 为什么适合视觉指令微调？

系统又重新检索一次，总结一次。

它不会自动把昨天总结出来的知识沉淀成：

wiki/models/LLaVA.md
wiki/models/Flamingo.md
wiki/comparisons/LLaVA_vs_Flamingo.md

所以它像一个“临时查资料助手”，不是“长期知识编辑”。

这也是 LLM Wiki 要解决的问题。

✋ 缺点四：Token 消耗取决于检索片段数量

RAG 每次回答都要把检索结果塞进 Prompt。

如果 TopK 设置为 5，每个 chunk 800 字，那上下文可能就很长。

如果 TopK 设置为 20，Token 成本会更高。

TopK 太小：
可能漏掉关键信息。

TopK 太大：
Token 成本高，模型还可能被无关内容干扰。

这就是 RAG 的典型矛盾：

召回更多资料，可以降低漏检风险。
但塞入更多资料，会增加成本和干扰。
✋ 缺点五：很依赖文档质量

RAG 的答案质量高度依赖原始文档。

如果文档本身混乱：

标题不清楚
内容重复
版本过期
PDF 解析乱码
表格丢失
多个文档互相矛盾

那 RAG 很难生成稳定可靠的答案。

因为它只是检索和生成，不会自动帮你治理知识库。

✋ 缺点六：权限和安全容易被低估

个人 demo 可以不考虑权限。

但企业 RAG 必须考虑：

用户 A 能不能看这份文档？
用户 B 能不能看这个部门的数据？
外部客户能不能检索到内部知识？
离职员工的权限有没有取消？

如果权限过滤做不好，RAG 可能出现严重的信息泄露。

所以企业级 RAG 一定要在检索前或检索后做权限控制。

def permission_filter(user, chunks):
    allowed_chunks = []

    for chunk in chunks:
        if user_has_access(user, chunk.metadata["permission"]):
            allowed_chunks.append(chunk)

    return allowed_chunks

这段逻辑看起来简单，但在真实企业中非常关键。

3.11 RAG 的 Token 成本怎么理解？

RAG 的 Token 成本主要来自三个地方：

1. 用户问题本身
2. 检索出来的 chunk
3. LLM 生成的答案

其中最容易失控的是第二部分：检索 chunk。

可以简单估算：

用户问题：100 tokens
系统提示词：500 tokens
每个 chunk：600 tokens
TopK = 5
答案输出：800 tokens

总消耗约：
100 + 500 + 600 × 5 + 800 = 4400 tokens

如果 TopK 变成 15：

100 + 500 + 600 × 15 + 800 = 10400 tokens

所以 RAG 里 TopK 不是越大越好。

正确做法是：

先召回多一些：
TopK = 30

再重排筛选：
Rerank TopK = 5

最后只塞最有价值的片段：
Final Context = 5 chunks

这样既保证召回率，又控制 Token 成本。

3.12 一个典型 RAG 产品案例：企业制度问答机器人

假设你要做一个公司内部制度问答机器人。

资料包括：

员工手册
报销制度
请假制度
差旅制度
信息安全规范
入职流程
离职流程

用户问：

我去外地出差，高铁二等座能不能报销？

RAG 系统会这样工作：

1. 把问题改写为：
   “差旅制度 高铁 二等座 报销 标准”

2. 从知识库检索：
   - 差旅报销制度第 3.2 节
   - 交通费用报销标准
   - 高铁座位等级说明

3. 权限过滤：
   确认该员工可以查看差旅制度

4. Rerank：
   选出最相关的 3 段

5. Prompt：
   把这 3 段和用户问题一起发给 LLM

6. 回答：
   “可以报销。根据《差旅报销制度》第 3.2 节，员工因公出差可报销高铁二等座费用……”

这就是 RAG 最擅长的场景：

问题明确
答案在文档中
需要引用依据
知识会更新
用户需要快速查询

3.13 RAG 最适合哪些场景？

RAG 最适合下面这些场景：

企业制度问答：
报销、请假、审批、入职、离职。

客服 FAQ：
退款、物流、售后、账号问题。

产品说明书问答：
功能解释、参数查询、故障排查。

合同和法律条款查询：
根据合同条款回答问题。

论文 PDF 问答：
问某篇论文的方法、实验、结论。

内部文档搜索：
从公司 Wiki、飞书、Confluence 里找资料。

代码文档助手：
查询 API、SDK、部署文档。

这些场景的共同点是：

答案通常存在于某些文档片段中。
用户只是不知道在哪里。

所以 RAG 非常合适。

3.14 RAG 不太适合哪些场景？

RAG 不太适合下面这些场景：

长期研究脉络梳理：
比如长期跟踪 100 篇论文的发展路线。

复杂知识体系构建：
比如把一个学科整理成概念图谱。

多文档深度综合：
比如比较 20 篇论文的核心方法演进。

持续维护的个人第二大脑：
比如长期积累自己的研究笔记。

需要自动发现矛盾和更新旧结论：
比如发现新论文推翻了旧论文观点。

这些场景更适合 LLM Wiki 或 Agent + Wiki。

因为它们需要的不是“临时检索几个片段”，而是：

持续整理
建立结构
形成链接
沉淀观点
更新旧知识

3.15 小结：RAG 是成熟的第一代知识库路线，但不是知识库的终点

RAG 的价值非常明确：

它让大模型能够访问外部知识。
它不需要重新训练模型。
它适合大规模文档问答。
它工程生态成熟。
它最容易产品化。

但它也有明显边界：

它依赖切块质量。
它依赖检索质量。
它不天然沉淀知识结构。
它每次问答都要重新检索。
它容易重复消耗 Token。
它不擅长长期知识演化。

所以可以用一句话总结 RAG：

RAG 是给大模型外挂一个搜索引擎，让它回答前先查资料。

更工程化一点说：

RAG 解决的是：
如何从大量原始资料中，快速找出和当前问题最相关的片段。

它不主要解决：
如何把这些资料长期整理成一个会生长、会更新、会链接的知识体系。

因此，RAG 是现在最成熟、最容易落地的知识库产品路线。

但如果你的目标是长期研究、知识沉淀、自动维护、知识演化，那么仅靠 RAG 就不够了。

这也正是后面要介绍的 LLM Wiki + Obsidian 和 Hermes Agent + LLM Wiki 出现的原因。

4. 方法二：LLM Wiki + Obsidian——不是检索文档，而是让 AI 把知识“编译成 Wiki”

4.1 LLM Wiki 是什么？

LLM Wiki 是一种最近很值得关注的知识库方法。

它和 RAG 最大的不同是：

RAG 是在用户提问时临时检索资料，LLM Wiki 是提前让大模型把资料整理成一套长期存在的 Wiki。

也就是说，LLM Wiki 不只是“问答系统”，而更像是一个“AI 参与维护的知识编辑系统”。

如果用一句话解释：

LLM Wiki = 用大模型把原始资料持续整理成结构化、可链接、可维护的 Markdown Wiki。

它的核心思想不是：

用户问问题
  ↓
临时检索 chunk
  ↓
LLM 临时总结

而是：

新资料进入知识库
  ↓
LLM 阅读资料
  ↓
LLM 抽取概念、人物、方法、结论、争议
  ↓
LLM 更新已有 Wiki 页面
  ↓
LLM 创建新的概念页 / 主题页 / 对比页
  ↓
形成一套长期生长的知识结构

所以 LLM Wiki 更像是：

RAG：
像搜索引擎，用户问什么就临时查什么。

LLM Wiki：
像维基百科编辑部，先把资料整理成条目、链接和索引。

Obsidian：
像知识库 IDE，负责让人类舒服地阅读、编辑、跳转、可视化。

4.2 为什么说 LLM Wiki 是“知识编译器”？

理解 LLM Wiki 最关键的一个比喻是：

它不是检索器，而是编译器。

在编程里，编译器会把源代码编译成可执行程序。

在 LLM Wiki 里，大模型会把原始资料“编译”成结构化知识页面。

可以这样类比：

编程语言世界：

源代码 source code
  ↓
编译器 compiler
  ↓
目标程序 executable


LLM Wiki 世界：

原始资料 raw documents
  ↓
LLM knowledge compiler
  ↓
Markdown Wiki pages

更具体一点：

raw 资料：
论文、网页、访谈、笔记、书籍、报告、代码 README

LLM 编译过程：
阅读、总结、抽取概念、建立链接、更新旧页面、记录矛盾

Wiki 产物：
概念页、人物页、方法页、论文页、对比页、索引页、问题页

这就是为什么 LLM Wiki 和 RAG 的思路完全不同。

RAG 保存的是：

一堆被切开的 chunk

LLM Wiki 保存的是：

一套被整理过的知识页面

chunk 更像碎片。

Wiki 页面更像知识结构。

4.3 LLM Wiki 的三层结构：raw、wiki、schema

Karpathy 的 LLM Wiki 思路可以理解成三层：

raw/       原始资料层
wiki/      知识产物层
schema/    规则约束层

这三层非常关键。

如果没有这三层，LLM Wiki 很容易变成一堆 AI 生成的散乱笔记。

📂 第一层：raw/ 原始资料层

raw/ 是原始资料仓库。

里面可以放：

论文 PDF
网页保存内容
书籍摘录
会议纪要
访谈文本
课程笔记
代码 README
项目文档
博客文章

例如：

raw/
├── papers/
│   ├── 2023_LLaVA.pdf
│   ├── 2022_Flamingo.pdf
│   └── 2022_BLIP.pdf
├── articles/
│   ├── karpathy_llm_wiki.md
│   └── dair_llm_knowledge_base.md
├── notes/
│   ├── reading_note_001.md
│   └── meeting_note_2026_04_27.md
└── webclips/
    ├── obsidian_graph_view.md
    └── rag_best_practices.md

raw/ 的作用是：

保存证据
保留原文
方便回溯
防止 LLM 总结错误后找不到来源

非常重要的一点是：

LLM Wiki 不能只保留 AI 总结，一定要保留原始资料。

因为大模型可能总结错、漏掉细节、过度压缩内容。

raw/ 就像论文里的参考文献库，是知识可信度的基础。

📚 第二层：wiki/ 知识产物层

wiki/ 是真正给人读、给 AI 后续复用的知识层。

里面不再是原始资料，而是整理后的知识页面。

例如：

wiki/
├── concepts/
│   ├── RAG.md
│   ├── LLM_Wiki.md
│   ├── Embedding.md
│   ├── Vector_Database.md
│   └── Visual_Instruction_Tuning.md
├── papers/
│   ├── LLaVA.md
│   ├── Flamingo.md
│   └── BLIP.md
├── comparisons/
│   ├── RAG_vs_LLM_Wiki.md
│   ├── LLaVA_vs_Flamingo.md
│   └── Obsidian_vs_Notion.md
├── projects/
│   ├── Robot_Vision_Knowledge_Base.md
│   └── Enterprise_RAG_System.md
├── questions/
│   ├── How_to_reduce_RAG_hallucination.md
│   └── How_to_design_LLM_Wiki_schema.md
└── index.md

wiki/ 的作用是：

保存结构化知识
形成长期记忆
支持后续问答
支持人类阅读
支持 Obsidian 双向链接

例如一个概念页可以长这样：

# RAG

## 一句话定义

RAG，Retrieval-Augmented Generation，指的是在大模型生成答案前，先从外部知识库中检索相关资料，再把资料放入上下文，让模型基于资料回答。

## 核心流程

1. 文档解析
2. 文档切块
3. Embedding 向量化
4. 向量数据库检索
5. Rerank 重排
6. LLM 生成答案

## 优点

- 知识更新快
- 适合大规模文档
- 工程生态成熟
- 容易产品化

## 缺点

- 切块可能破坏语义
- 检索不等于理解
- 不天然沉淀知识结构
- 多次问答可能重复消耗 Token

## 相关页面

- [[Embedding]]
- [[Vector_Database]]
- [[RAG_vs_LLM_Wiki]]
- [[LLM_Wiki]]

这就不再是一个普通 chunk，而是一个可以长期复用的知识单元。

🧩 第三层：schema/ 规则约束层

schema/ 是整个 LLM Wiki 最容易被忽略，但最关键的一层。

它告诉 LLM：

怎么命名页面
怎么创建目录
怎么更新旧页面
怎么标注来源
什么时候创建新页面
什么时候合并重复页面
遇到矛盾怎么办
如何写 index
如何维护 log

例如：

schema/
├── AGENTS.md
├── page_template.md
├── citation_rules.md
├── naming_rules.md
├── update_policy.md
└── contradiction_policy.md

其中 AGENTS.md 可以写成这样：

# LLM Wiki 维护规则

你是这个知识库的维护 Agent。

## 目录规则

- raw/ 存放原始资料，禁止随意修改。
- wiki/concepts/ 存放概念页。
- wiki/papers/ 存放论文页。
- wiki/comparisons/ 存放对比页。
- wiki/questions/ 存放高频问题页。
- wiki/projects/ 存放项目相关知识页。

## 页面命名规则

- 概念页使用英文名或通用技术名，例如 RAG.md、Embedding.md。
- 对比页使用 A_vs_B.md。
- 论文页使用论文简称或常用名，例如 LLaVA.md。
- 不要创建含糊的页面名，例如 note1.md、summary.md。

## 更新规则

- 如果新资料补充了已有概念，优先更新旧页面。
- 如果出现全新概念，再创建新页面。
- 不要重复创建意思相同的页面。
- 每次更新后，需要更新 index.md 和 log.md。

## 引用规则

- 关键结论必须注明来源。
- 如果来自 raw/papers/xxx.pdf，需要写明文件名和章节。
- 如果是自己的推理，需要明确标注“推断”。

## 矛盾处理

- 如果新资料与旧结论冲突，不要直接覆盖。
- 在页面中增加“争议与矛盾”小节。
- 记录两个观点分别来自哪里。

schema/ 的意义非常大。

没有 schema 的 LLM Wiki，会变成：

AI 想怎么写就怎么写
今天一个命名规则
明天一个目录结构
后天重复创建页面
最后知识库越来越乱

有 schema 的 LLM Wiki，才像一个真正可维护的知识工程项目。

4.4 LLM Wiki 的整体工作流

LLM Wiki 的工作流可以画成下面这样：

┌──────────────────────────────┐
│          新资料进入 raw/        │
│ 论文 / 网页 / 笔记 / 访谈 / 文档 │
└───────────────┬──────────────┘
                │
                ▼
┌──────────────────────────────┐
│        LLM 读取 schema/        │
│ 命名规则 / 引用规则 / 更新规则   │
└───────────────┬──────────────┘
                │
                ▼
┌──────────────────────────────┐
│        LLM 阅读原始资料         │
│ 识别主题、概念、方法、人物、结论 │
└───────────────┬──────────────┘
                │
                ▼
┌──────────────────────────────┐
│        生成更新计划             │
│ 新建哪些页？更新哪些页？合并哪些页？ │
└───────────────┬──────────────┘
                │
                ▼
┌──────────────────────────────┐
│        修改 wiki/ 页面          │
│ 概念页 / 论文页 / 对比页 / 索引页 │
└───────────────┬──────────────┘
                │
                ▼
┌──────────────────────────────┐
│        更新 index.md           │
│ 让人和 AI 都知道知识库有什么     │
└───────────────┬──────────────┘
                │
                ▼
┌──────────────────────────────┐
│        更新 log.md             │
│ 记录本次更新了什么、依据是什么   │
└───────────────┬──────────────┘
                │
                ▼
┌──────────────────────────────┐
│        Obsidian 打开 Vault      │
│ 浏览 / 搜索 / 双向链接 / 图谱视图 │
└──────────────────────────────┘

这个流程和 RAG 最大的不同是：

RAG 的核心动作是 retrieve。
LLM Wiki 的核心动作是 update。

RAG 是：

用户问了什么，我现在去找什么。

LLM Wiki 是：

来了新资料，我要把它整理进已有知识结构。

4.5 Obsidian 在这里是什么角色？

Obsidian 不是大模型，也不是向量数据库。

它更像是：

Markdown 知识库的 IDE。

为什么叫 IDE？

因为程序员写代码时需要 VSCode、PyCharm、CLion 这类 IDE。

而当你维护一个 Markdown 知识库时，也需要一个工具来：

打开文件
编辑页面
搜索内容
跳转链接
查看反向链接
看图谱关系
管理标签
安装插件

Obsidian 正好适合做这个事情。

在 LLM Wiki + Obsidian 体系里，三者分工非常明确：

LLM / Agent：
负责读资料、总结、改写、建立链接、维护索引。

Markdown 文件夹：
是真正的知识库本体。

Obsidian：
负责浏览、编辑、可视化、人工复查。

可以画成下面这个结构：

┌──────────────────────────────┐
│           LLM / Agent          │
│ 读取 raw，更新 wiki，维护 index  │
└───────────────┬──────────────┘
                │ 写入 Markdown
                ▼
┌──────────────────────────────┐
│        本地 Markdown Vault     │
│ raw/ wiki/ schema/ index.md   │
└───────────────┬──────────────┘
                │ 打开文件夹
                ▼
┌──────────────────────────────┐
│            Obsidian            │
│ 双向链接 / 图谱视图 / 搜索 / 编辑 │
└──────────────────────────────┘

Obsidian 的优势是它直接使用 Markdown 文件。

这意味着：

你的知识库不是锁在某个平台数据库里。
你的知识库就是一堆普通 Markdown 文件。
可以用 Git 管理。
可以用 VSCode 编辑。
可以用脚本处理。
可以用静态网站发布。
可以迁移到其他工具。

这点非常重要。

因为很多笔记软件的问题是：

导出困难
格式封闭
长期迁移成本高
AI 不好直接读写

而 Markdown 天然适合 LLM 和 Agent 操作。

4.6 Obsidian 的双向链接为什么适合 LLM Wiki？

Obsidian 最有价值的能力之一是双向链接。

例如你在 RAG.md 里写：

RAG 的核心依赖包括 [[Embedding]]、[[Vector_Database]] 和 [[Reranker]]。

那么 Obsidian 会自动知道：

RAG.md 链接到了 Embedding.md
RAG.md 链接到了 Vector_Database.md
RAG.md 链接到了 Reranker.md

同时，在 Embedding.md 的反向链接里，也能看到：

哪些页面提到了 Embedding？

这对知识库很重要。

因为知识不是线性的。

一篇文章可能同时关联：

RAG
Embedding
向量数据库
混合检索
LLM 幻觉
企业知识库

Obsidian 可以把这些关系显示出来。

而 LLM 在维护 Wiki 时，也可以主动建立这些链接。

例如：

# LLM Wiki

LLM Wiki 和 [[RAG]] 最大的区别是：RAG 更偏向 query-time retrieval，而 LLM Wiki 更偏向长期知识编译。

相关概念包括 [[Markdown]]、[[Obsidian]]、[[Knowledge_Compilation]] 和 [[Agent_Memory]]。

这样知识库会逐渐形成一张网。

4.7 LLM Wiki + Obsidian 的部署方式

最简单的部署方式如下：

1. 本地创建一个 Obsidian Vault
2. 建立 raw/、wiki/、schema/ 三层目录
3. 写好 AGENTS.md 或 CLAUDE.md 规则文件
4. 使用 Claude Code / Codex / Cursor / ChatGPT / OpenCode 等 Agent 工具
5. 让 Agent 读取 raw，并维护 wiki
6. 用 Obsidian 打开 vault，浏览和人工检查
7. 可选：用 Git 做版本管理
8. 可选：用 MkDocs / Quartz / Hugo 发布成网站

一个推荐目录结构可以这样设计：

my_llm_wiki/
├── raw/
│   ├── papers/
│   │   ├── LLaVA.pdf
│   │   ├── Flamingo.pdf
│   │   └── BLIP.pdf
│   ├── articles/
│   │   ├── karpathy_llm_wiki.md
│   │   └── dair_llm_knowledge_base.md
│   ├── books/
│   └── notes/
│
├── wiki/
│   ├── concepts/
│   │   ├── RAG.md
│   │   ├── LLM_Wiki.md
│   │   ├── Embedding.md
│   │   └── Vector_Database.md
│   ├── papers/
│   │   ├── LLaVA.md
│   │   └── Flamingo.md
│   ├── people/
│   ├── projects/
│   ├── comparisons/
│   │   └── RAG_vs_LLM_Wiki.md
│   ├── questions/
│   └── index.md
│
├── schema/
│   ├── AGENTS.md
│   ├── page_template.md
│   ├── naming_rules.md
│   ├── citation_rules.md
│   └── update_policy.md
│
├── inbox/
│   └── 待处理资料.md
│
├── log.md
└── README.md

这里可以加一个 inbox/ 文件夹。

它的作用是：

临时放还没整理的资料。

比如你今天看到一篇好文章，但没时间处理，就先放进 inbox。

之后让 Agent 执行：

请处理 inbox/ 里的新资料，并根据 schema/AGENTS.md 更新 wiki/。

4.8 一个真实使用流程：读一篇论文如何进入 LLM Wiki？

假设你正在研究多模态大模型，今天读了一篇 LLaVA 论文。

你把论文放进：

raw/papers/LLaVA.pdf

然后对 Agent 说：

请阅读 raw/papers/LLaVA.pdf，根据 schema/AGENTS.md 规则更新我的 LLM Wiki。

Agent 应该做的不是简单总结，而是生成一个更新计划：

需要新建或更新的页面：

1. wiki/papers/LLaVA.md
   记录论文核心贡献、方法、实验、局限性。

2. wiki/concepts/Visual_Instruction_Tuning.md
   补充视觉指令微调的定义和作用。

3. wiki/concepts/Vision_Language_Alignment.md
   更新视觉语言对齐相关内容。

4. wiki/comparisons/LLaVA_vs_Flamingo.md
   如果已有 Flamingo 页面，则补充对比。

5. wiki/index.md
   在多模态大模型部分加入 LLaVA 链接。

6. log.md
   记录本次更新来源和修改内容。

这比 RAG 的“上传 PDF 后检索”更进一步。

因为它把一篇论文消化成了一组长期可复用的知识页面。

4.9 LLM Wiki 的核心代码逻辑：不是 query，而是 compile

RAG 的核心函数通常是：

retrieve_then_generate()

LLM Wiki 的核心函数更像：

compile_source_to_wiki()

下面是一段简化伪代码。

def compile_source_to_wiki(source_path):
    """
    LLM Wiki 的核心流程：
    1. 读取原始资料
    2. 读取维护规则
    3. 提取结构化知识
    4. 规划需要更新的页面
    5. 修改 Wiki
    6. 更新索引和日志
    """

    # 1. 读取原始资料
    raw_text = read_source(source_path)

    # 2. 读取 schema 规则
    agent_rules = read_file("schema/AGENTS.md")
    naming_rules = read_file("schema/naming_rules.md")
    citation_rules = read_file("schema/citation_rules.md")
    page_template = read_file("schema/page_template.md")

    # 3. 让 LLM 抽取结构化信息
    extracted = llm.extract(
        instruction=f"""
        你正在维护一个 LLM Wiki。

        请根据以下规则抽取资料中的知识：

        {agent_rules}

        需要抽取：
        - 主题
        - 关键概念
        - 方法
        - 人物或机构
        - 主要结论
        - 与已有页面的关系
        - 可能的争议和矛盾
        - 需要引用的来源
        """,
        text=raw_text
    )

    # 4. 读取当前 Wiki 索引
    existing_index = read_file("wiki/index.md")

    # 5. 让 LLM 规划更新哪些页面
    update_plan = llm.plan(
        instruction=f"""
        根据当前 Wiki 索引和新资料抽取结果，制定更新计划。

        当前索引：
        {existing_index}

        新资料抽取结果：
        {extracted}

        输出：
        - 需要新建的页面
        - 需要更新的页面
        - 不应该重复创建的页面
        - 需要记录的矛盾
        """,
    )

    # 6. 执行更新计划
    for target_page in update_plan.pages:
        old_content = read_file_if_exists(target_page.path)

        new_content = llm.rewrite(
            instruction=f"""
            请根据页面模板和引用规则更新页面。

            页面模板：
            {page_template}

            引用规则：
            {citation_rules}

            要求：
            - 保留已有有价值内容
            - 新增内容必须标注来源
            - 如果新资料与旧内容冲突，写入“争议与矛盾”
            - 尽量添加双向链接，例如 [[RAG]]、[[Embedding]]
            """,
            old_content=old_content,
            new_information=extracted
        )

        write_file(target_page.path, new_content)

    # 7. 更新总索引和日志
    update_index()
    append_log(source_path, update_plan)

    return "Wiki compilation finished"

这段代码暴露了 LLM Wiki 的关键点：

RAG 关注的是：
这次问题要检索哪些 chunk？

LLM Wiki 关注的是：
这份资料应该更新知识库里的哪些页面？

所以 LLM Wiki 更像一个知识工程系统。

4.10 页面模板：LLM Wiki 为什么一定要有模板？

如果没有模板，LLM 写出来的页面会很随意。

今天写成这样：

# RAG 简介
RAG 是一种技术……

明天写成这样：

# 关于向量检索的一些想法
这里讨论一下……

后天又写成这样：

# note
这篇文章讲了很多……

时间久了，知识库会越来越乱。

所以 LLM Wiki 最好为不同页面设计模板。

概念页模板
# {{concept_name}}

## 一句话定义

用一句话解释这个概念。

## 背景

这个概念为什么出现？解决什么问题？

## 核心机制

分点说明技术流程或原理。

## 典型应用

列出适用场景。

## 优点

- 优点 1
- 优点 2

## 局限

- 局限 1
- 局限 2

## 相关页面

- [[相关概念1]]
- [[相关概念2]]

## 来源

- raw/...
论文页模板
# {{paper_name}}

## 基本信息

- 论文名称：
- 作者：
- 年份：
- 机构：
- 方向：

## 解决的问题

这篇论文主要解决什么问题？

## 核心方法

方法结构是什么？

## 主要贡献

1. 
2. 
3. 

## 实验结果

主要实验结论是什么？

## 局限性

论文有哪些不足？

## 和已有工作的关系

- 与 [[相关论文A]] 的关系
- 与 [[相关方法B]] 的关系

## 对我研究的启发

这部分可以写自己的理解。

## 来源

- raw/papers/...
对比页模板
# {{A}} vs {{B}}

## 一句话结论

先用一句话说明二者最大区别。

## 对比表

| 维度 | {{A}} | {{B}} |
|---|---|---|
| 核心思想 |  |  |
| 输入输出 |  |  |
| 训练方式 |  |  |
| 优点 |  |  |
| 局限 |  |  |
| 适合场景 |  |  |

## 详细分析

展开解释关键差异。

## 相关页面

- [[A]]
- [[B]]

## 来源

- raw/...

模板的作用是让知识库越来越规整，而不是越写越散。

4.11 LLM Wiki + Obsidian 的网络结构拓扑图

如果把 LLM Wiki + Obsidian 画成系统拓扑，大概是这样：

                         ┌──────────────────────┐
                         │      用户 / 研究者      │
                         │ 提供资料、提出问题、复查 │
                         └───────────┬──────────┘
                                     │
                                     ▼
                         ┌──────────────────────┐
                         │      Agent 工具层      │
                         │ Claude Code / Codex   │
                         │ Cursor / ChatGPT      │
                         └───────────┬──────────┘
                                     │
             ┌───────────────────────┼───────────────────────┐
             │                       │                       │
             ▼                       ▼                       ▼
┌──────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│       raw/ 原始资料     │ │      schema/ 规则层    │ │      wiki/ 知识层      │
│ PDF / 网页 / 笔记      │ │ 命名 / 引用 / 模板      │ │ 概念页 / 对比页 / 索引  │
└───────────┬──────────┘ └───────────┬──────────┘ └───────────┬──────────┘
            │                        │                        │
            └────────────┬───────────┴────────────┬───────────┘
                         │                        │
                         ▼                        ▼
              ┌──────────────────────┐ ┌──────────────────────┐
              │       Git 版本管理      │ │       Obsidian 展示     │
              │ diff / commit / rollback│ │ 双向链接 / 图谱 / 搜索   │
              └──────────────────────┘ └──────────────────────┘

这张图里有两个很重要的工程思想：

第一，Markdown 文件夹才是知识库本体。
Obsidian 只是打开它的界面。

第二，schema 是 LLM 的操作系统规则。
没有 schema，Agent 很容易乱写。

4.12 LLM Wiki 和 RAG 的本质区别

可以用一张表总结。

维度 RAG LLM Wiki + Obsidian
核心动作 检索 chunk 更新 Wiki 页面
知识形态 文档片段 Markdown 知识页
工作时机 用户提问时 新资料进入时、定期维护时
是否长期积累 弱 强
是否适合人类阅读 一般，chunk 很碎 强，页面可读
是否需要向量数据库 通常需要 小规模可不需要
是否适合长期研究 一般 很适合
是否适合企业海量文档 很适合 不一定
典型界面 Chatbot / 搜索框 Obsidian / Markdown / Web
主要风险 检索漏召回 LLM 总结错误、结构混乱

最关键的区别是：

RAG：
原始文档是知识库，向量库是索引。

LLM Wiki：
Wiki 页面本身就是知识库，原始文档只是原料。

这句话非常重要。

RAG 更像是在原始资料上加了一个搜索引擎。

LLM Wiki 是把原始资料加工成了新的知识产品。

4.13 LLM Wiki 的优点

LLM Wiki 最大的优点是：

知识会积累。

RAG 是每次重新检索。

LLM Wiki 是每次更新一个长期存在的知识结构。

🚀 优点一：特别适合长期研究

比如你研究“多模态大模型”。

今天读 BLIP。

明天读 Flamingo。

后天读 LLaVA。

如果是 RAG，你每次问问题都要重新检索。

如果是 LLM Wiki，它会逐步形成：

wiki/concepts/Vision_Encoder.md
wiki/concepts/Vision_Language_Alignment.md
wiki/concepts/Visual_Instruction_Tuning.md
wiki/concepts/Multimodal_Pretraining.md

wiki/papers/BLIP.md
wiki/papers/Flamingo.md
wiki/papers/LLaVA.md

wiki/comparisons/LLaVA_vs_Flamingo.md
wiki/comparisons/BLIP_vs_CLIP.md

wiki/index_multimodal_llm.md

几个月后，你拥有的不是一堆 PDF，而是一套自己的“小型多模态百科”。

这对研究生非常有价值。

因为科研最痛苦的不是“读不到论文”，而是：

读过就忘
论文之间没有联系
不知道技术路线怎么演进
不知道哪些观点互相矛盾
不知道自己的研究切入点在哪里

LLM Wiki 正好解决这个问题。

🚀 优点二：适合回答综合型问题

比如：

“LLaVA 和 Flamingo 在视觉语言对齐方法上有什么根本区别？”

“这些多模态论文对我的机器人视觉项目有什么启发？”

“过去三个月我读的文章里，哪些观点互相矛盾？”

“RAG、LLM Wiki、Agent Memory 的关系是什么？”

“我的知识库里有哪些主题已经过时，需要更新？”

这类问题不是简单检索几个 chunk 就能解决的。

它需要系统知道：

有哪些相关概念
哪些页面互相链接
哪些资料来自哪里
哪些观点曾经出现过
哪些结论后来被更新

LLM Wiki 更适合这种任务。

🚀 优点三：可读性强，适合人类复查

RAG 的检索结果通常是 chunk。

chunk 对机器友好，但对人类不一定友好。

比如：

chunk_372:
... previous works have demonstrated that visual instruction tuning can improve alignment between visual encoders and language models...

你看完以后可能还要自己整理。

但 LLM Wiki 生成的是页面：

# Visual Instruction Tuning

## 一句话定义

视觉指令微调是一种让多模态模型按照自然语言指令理解和处理图像任务的方法。

## 背景

它主要解决传统视觉语言模型只能做固定任务，而不擅长开放式对话和指令跟随的问题。

## 代表工作

- [[LLaVA]]
- [[MiniGPT-4]]
- [[InstructBLIP]]

## 和 RAG 的关系

二者不是同一层级。RAG 是知识检索方法，视觉指令微调是模型训练方法。

这种页面人可以直接读，也可以改，还可以继续链接到其他页面。

🚀 优点四：长期使用可能更省 Token

LLM Wiki 初期构建会比较耗 Token。

因为它要：

阅读原始资料
总结内容
抽取概念
更新页面
建立链接
写日志

但是一旦 Wiki 成型，后续问答就可以优先读取：

index.md
概念页
对比页
总结页

而不是每次都读取大量原始 PDF 或检索很多 chunk。

可以这样理解：

RAG：
每次考试都现场翻书。

LLM Wiki：
先把书整理成复习笔记，以后优先看笔记。

Hermes Agent：
再请一个助教每天帮你更新复习笔记。

如果你只问一次，RAG 更省。

如果你长期研究同一个方向，LLM Wiki 的知识复用价值会越来越高。

🚀 优点五：适合 Git 版本管理

因为 LLM Wiki 本质上是 Markdown 文件夹，所以可以用 Git 管理。

这意味着：

每次 Agent 修改了什么，可以看 diff。
如果改错了，可以回滚。
可以多人协作。
可以写 commit message。
可以发布到 GitHub Pages。

例如：

git status
git diff wiki/concepts/RAG.md
git add wiki/
git commit -m "Update RAG and LLM Wiki comparison"

这对知识库很重要。

因为 AI 修改文件一定会有风险。

有 Git，就可以看到：

AI 改了哪些页面？
删了哪些内容？
新增了哪些结论？
有没有误删？

这比黑盒笔记软件安全很多。

4.14 LLM Wiki 的缺点

LLM Wiki 也不是万能的。

它很适合长期知识沉淀，但不一定适合所有场景。

✋ 缺点一：初期搭建成本高

RAG 可以很快搭一个 demo。

上传 PDF，选 embedding，点创建知识库，就能问答。

但 LLM Wiki 一开始要设计很多东西：

目录结构
页面模板
命名规则
引用规则
更新规则
冲突处理规则
索引维护方式
日志格式

如果这些没设计好，知识库很快就会乱。

常见失败情况包括：

同一个概念建了多个页面：
RAG.md
Retrieval_Augmented_Generation.md
检索增强生成.md

页面命名混乱：
note1.md
summary_final.md
new_page.md

结构不统一：
有的页面有来源，有的没有。
有的页面写得很长，有的只有两句话。
有的页面有双向链接，有的完全没有。

所以 LLM Wiki 不是简单让 AI 写笔记，而是要做知识工程设计。

✋ 缺点二：容易被模型写错

LLM 会总结，但不保证永远正确。

它可能：

误解论文贡献
漏掉关键限制
把作者观点写成确定结论
把自己的推断写成事实
错误合并两个相似概念
编造不存在的来源

所以 LLM Wiki 必须有两个安全机制：

第一，保留 raw 原始资料。

第二，关键结论标注来源。

例如页面里最好这样写：

## 主要结论

LLaVA 的核心思路是将视觉编码器与语言模型连接，并通过视觉指令数据进行微调。

来源：
- raw/papers/LLaVA.pdf，第 2 节 Method

如果是自己的推断，要写清楚：

## 对我研究的启发

推断：LLaVA 的视觉指令微调思路可以借鉴到机器人视觉问答任务中，但需要额外考虑实时性和边缘端部署问题。

不要把推断写成事实。

✋ 缺点三：不适合超大规模实时文档

如果你是企业级知识库，有：

100 万份文档
每天新增 5 万份
每份文档都要实时可查

那 LLM Wiki 全部编译一遍会非常贵，也非常慢。

这种场景更适合 RAG。

因为 RAG 可以：

快速入库
快速检索
不必把每份文档都整理成 Wiki 页面

LLM Wiki 更适合高价值资料，而不是所有资料。

一个更合理的企业架构是：

所有原始文档：
进入 RAG。

高价值知识：
由 LLM Wiki 整理成结构化页面。

重要主题：
由 Agent 定期更新。

也就是说，LLM Wiki 不一定替代 RAG，而是补充 RAG。

✋ 缺点四：更新不是“上传即用”

RAG 上传文档后，只要向量化完成，就可以检索。

LLM Wiki 不一样。

它需要：

读取资料
理解资料
判断影响哪些页面
修改旧页面
新建新页面
更新链接
更新索引
记录日志

所以它更新更慢。

但换来的好处是：

知识质量更高
结构更清晰
更适合长期复用

这就像：

RAG：
把书放进图书馆，马上能搜索。

LLM Wiki：
把书读完，整理成百科条目，需要时间，但以后更好用。
✋ 缺点五：需要人工复查

LLM Wiki 不应该完全无人监管，尤其是科研、法律、医疗、企业制度这类严肃场景。

更安全的流程是：

Agent 生成更新计划
        ↓
人类审核
        ↓
Agent 修改页面
        ↓
Git diff 检查
        ↓
确认后 commit

可以设计成这样：

┌──────────────────────┐
│      Agent 生成计划     │
└───────────┬──────────┘
            │
            ▼
┌──────────────────────┐
│      人类审核计划       │
└───────────┬──────────┘
            │
            ▼
┌──────────────────────┐
│      Agent 修改页面     │
└───────────┬──────────┘
            │
            ▼
┌──────────────────────┐
│      Git diff 检查      │
└───────────┬──────────┘
            │
            ▼
┌──────────────────────┐
│      确认并提交         │
└──────────────────────┘

这比让 AI 直接乱改整个知识库安全得多。

4.15 LLM Wiki 适合哪些场景？

LLM Wiki 特别适合：

长期读论文
个人研究方向积累
实验室技术知识库
课程学习笔记
开源项目源码研究
行业调研
长期写作素材库
产品经理竞品分析
创业者市场研究
工程团队经验沉淀

这些场景的共同特点是：

资料不是一次性用完。
知识需要长期积累。
不同资料之间有关系。
用户希望形成自己的理解。
后续还会反复引用这些知识。

例如你做“机器人视觉 + 多模态大模型”方向，LLM Wiki 可以逐渐积累：

wiki/concepts/
├── RK3588.md
├── RKNN.md
├── MediaPipe_FaceMesh.md
├── FER2013.md
├── AffectNet.md
├── Multimodal_LLM.md
└── Vision_Language_Model.md

wiki/projects/
├── Emotion_Recognition_Pipeline.md
├── RK3588_Deployment.md
└── Night_Vision_Enhancement.md

wiki/comparisons/
├── ONNX_vs_RKNN.md
├── RAG_vs_LLM_Wiki.md
└── LLaVA_vs_Flamingo.md

时间久了，这就是你自己的技术百科。

4.16 LLM Wiki 不适合哪些场景？

LLM Wiki 不太适合：

超大规模原始文档实时查询
客服高并发问答
简单 FAQ
文档每天大量变化且价值密度低
只需要一次性问答的 PDF
强权限隔离的企业系统

这些更适合 RAG。

例如：

客户问“怎么退货？”
员工问“今年报销标准是什么？”
用户问“这个合同第 5 条是什么意思？”

这类问题答案通常就在某个文档片段里，不一定需要整理成 Wiki。

所以不要为了高级而强行用 LLM Wiki。

正确选择应该是：

短期问答、大规模检索：
优先 RAG。

长期研究、知识沉淀：
优先 LLM Wiki。

自动维护、持续更新：
再考虑 Hermes Agent。

4.17 一个推荐的 LLM Wiki 命令工作流

如果你用 Claude Code、Codex、Cursor 这类 Agent，可以这样维护 Wiki。

第一步：初始化知识库
请根据下面目标，为我创建一个 LLM Wiki 目录结构：

目标：
我想长期研究 RAG、LLM Wiki、Agent、Obsidian 和企业知识库产品。

请创建：
raw/
wiki/
schema/
inbox/
index.md
log.md

并在 schema/AGENTS.md 中写清楚维护规则。
第二步：处理新资料
请读取 inbox/karpathy_llm_wiki.md。

根据 schema/AGENTS.md：
1. 判断应该新建或更新哪些页面。
2. 先输出更新计划，不要直接修改。
3. 等我确认后再执行。
第三步：执行更新
同意这个更新计划。

请执行：
1. 更新 wiki/concepts/LLM_Wiki.md
2. 新建 wiki/comparisons/RAG_vs_LLM_Wiki.md
3. 更新 wiki/index.md
4. 更新 log.md
5. 所有关键结论保留来源。
第四步：检查知识库健康度
请检查当前 wiki/：

1. 有没有孤立页面？
2. 有没有重复概念？
3. 有没有缺少来源的关键结论？
4. index.md 是否需要更新？
5. 哪些页面应该增加双向链接？

只输出检查报告，不要修改文件。
第五步：用 Git 查看修改
git diff
git status
git add wiki/ schema/ log.md
git commit -m "Update LLM Wiki notes"

这个流程非常适合研究生和技术写作者。

因为它既能利用 AI，又不会完全失控。

4.18 小结：LLM Wiki + Obsidian 是“会沉淀的知识库”

LLM Wiki + Obsidian 的核心价值，不是让 AI 回答得更花哨，而是让知识真正沉淀下来。

可以用一句话总结：

RAG 是让大模型临时查资料，LLM Wiki 是让大模型长期整理资料。

更具体一点：

RAG 解决的是：
当前问题应该检索哪些片段？

LLM Wiki 解决的是：
这些资料应该沉淀成什么结构？

Obsidian 解决的是：
这些结构化知识如何让人类阅读、编辑、跳转和复查？

它最适合：

长期研究
论文阅读
个人第二大脑
技术路线整理
实验室知识库
写作素材沉淀
开源项目研究

它不适合：

海量文档实时查询
简单客服 FAQ
每天大量低价值文档入库
只需要一次性问答的场景

所以 LLM Wiki + Obsidian 不是 RAG 的简单替代品，而是另一种知识库范式。

RAG 像一个搜索引擎。

LLM Wiki 像一座持续生长的百科。

Obsidian 则像这座百科的编辑器、浏览器和地图。

最终可以这样理解：

raw/ 是原材料仓库。
schema/ 是知识库维护规则。
wiki/ 是知识产品。
Obsidian 是知识库 IDE。
LLM / Agent 是知识编辑员。

如果你是本科生、研究生，或者正在长期研究某个技术方向，LLM Wiki + Obsidian 很值得尝试。

因为它能帮你从“我读过很多资料”，真正升级到：

我拥有一套不断生长、可以复用、可以追溯、可以继续扩展的个人知识系统。

5. 方法三：Hermes Agent + LLM Wiki + Obsidian / Web——让知识库自己维护自己

5.1 Hermes Agent 这条路线是什么？

如果说 LLM Wiki 解决的是：

知识应该被整理成什么结构？

那么 Hermes Agent + LLM Wiki 解决的是另一个更现实的问题：

谁来长期维护这套知识结构？

这句话非常重要。

因为很多人一开始做知识库时都很兴奋：

今天整理 3 篇论文
明天更新 5 个概念页
后天维护 index.md
再过几天补充双向链接

但时间一长，问题就出现了：

资料越来越多
页面越来越乱
索引没人更新
重复页面越来越多
旧结论没人检查
新资料和旧资料冲突也没人记录

最后很多知识库都会变成：

刚开始很漂亮
一个月后没人维护
三个月后没人敢动
半年后彻底变成资料坟场

所以 Hermes Agent 这类长期运行的 Agent 被提出来，本质上是为了解决：

知识库维护自动化的问题。

5.2 一句话理解 Hermes Agent + LLM Wiki

可以先用一句话理解这条路线：

Hermes Agent + LLM Wiki =
让一个长期在线的 AI Agent 自动接收资料、读取资料、整理资料、更新 Wiki、维护索引、检查矛盾，并把知识库发布给用户使用。

它不是简单的“上传文件问答”。

它更像是一个“知识库后台进程”。

RAG：
你问问题，它临时检索。

LLM Wiki：
你给资料，它整理成 Wiki。

Hermes Agent + LLM Wiki：
你随手丢资料，它长期自动维护整个 Wiki。

如果用更形象的比喻：

RAG 像图书馆检索员：
你问什么，它帮你找哪几页书。

LLM Wiki 像百科编辑：
它把书里的内容整理成百科条目。

Hermes Agent 像长期雇佣的研究助理：
它每天帮你收资料、读资料、改页面、更新目录、检查错误、发布网站。

5.3 为什么说这条路线不是“知识库工具”，而是“知识库操作系统”？

传统知识库大多数是被动的。

你上传文档
你点击整理
你手动修改
你手动维护索引
你手动发布

Hermes Agent 路线的思路是主动的。

Agent 长期在线
  ↓
用户随时丢资料
  ↓
Agent 自动判断资料类型
  ↓
Agent 自动读取和总结
  ↓
Agent 自动更新 Wiki 页面
  ↓
Agent 自动检查索引、矛盾、孤立页面
  ↓
Agent 自动写日志
  ↓
Agent 可选自动提交 Git
  ↓
Agent 可选自动发布 Web

这时候知识库就不再是一个“文件夹”，而是一个持续运转的系统。

可以把它理解成：

raw/       = 原材料仓库
wiki/      = 知识产品仓库
schema/    = 操作规则
Agent      = 执行器
Git        = 版本控制系统
Web        = 发布层
Obsidian   = 人类编辑器
Telegram   = 移动端入口

这就很像一个小型知识库操作系统。

5.4 Hermes Agent 在整个系统里的角色

在 LLM Wiki + Obsidian 里，人类通常要主动告诉 AI：

请读取这篇文章
请总结它
请更新这个页面
请补充 index.md
请检查有没有重复概念

而 Hermes Agent 路线希望把这些步骤自动化。

它大概承担 6 个角色：

┌────────────────────────────────────────────┐
│              Hermes Agent 的角色             │
├────────────────────────────────────────────┤
│ 1. 网关入口                                 │
│    接收来自 Telegram / Web / CLI 的资料和指令 │
├────────────────────────────────────────────┤
│ 2. 任务调度器                               │
│    判断这是 ingest、query、lint 还是 publish │
├────────────────────────────────────────────┤
│ 3. 资料读取器                               │
│    读取网页、PDF、Markdown、GitHub README 等 │
├────────────────────────────────────────────┤
│ 4. Wiki 编辑器                              │
│    新建页面、更新页面、补充链接、维护 index   │
├────────────────────────────────────────────┤
│ 5. 质量检查器                               │
│    检查孤立页面、重复概念、缺失来源、矛盾内容 │
├────────────────────────────────────────────┤
│ 6. 发布执行器                               │
│    Git commit、构建静态站点、发布到 Web       │
└────────────────────────────────────────────┘

所以 Hermes Agent 不只是“调用 LLM 回答问题”。

它更像是：

围绕知识库运行的一套 Agent 工作流系统。

5.5 Hermes Agent + LLM Wiki 的整体架构

一个典型部署结构如下：

[ 手机 / 浏览器 / Telegram / CLI ]
              ↓
[ Hermes Agent 网关层 ]
              ↓
[ Agent 任务调度层 ]
判断任务类型：ingest / query / lint / publish / review
              ↓
[ Agent 执行层 ]
读取网页、解析文件、调用 LLM、执行脚本、维护 Git
              ↓
[ LLM Wiki 仓库 ]
raw/ + wiki/ + schema/ + index.md + log.md
              ↓
[ 展示层 ]
Obsidian / MkDocs / Hugo / Next.js / 静态网站

更完整一点，可以画成这样：

┌─────────────────────────────────────────────────────────────┐
│                         用户入口层                           │
│                                                             │
│  Telegram Bot   Web UI   CLI   Discord   Slack   Mobile Share │
└───────────────┬───────────────┬───────────────┬─────────────┘
                │               │               │
                └───────────────┴───────┬───────┘
                                        ▼
┌─────────────────────────────────────────────────────────────┐
│                     Hermes Agent 网关层                      │
│  接收消息 / 文件 / 链接 / 命令 / 定时任务                       │
└───────────────────────────┬─────────────────────────────────┘
                            ▼
┌─────────────────────────────────────────────────────────────┐
│                     Agent 任务调度层                          │
│                                                             │
│  classify_task()                                            │
│  ├── ingest：摄取新资料                                      │
│  ├── query：回答问题                                         │
│  ├── lint：检查知识库健康度                                   │
│  ├── review：生成周报或研究综述                               │
│  └── publish：构建并发布网站                                  │
└───────────────────────────┬─────────────────────────────────┘
                            ▼
┌─────────────────────────────────────────────────────────────┐
│                     Agent 工具执行层                          │
│                                                             │
│  read_file     write_file     web_fetch      pdf_parse        │
│  git_diff      git_commit     site_build     llm_call         │
└───────────────────────────┬─────────────────────────────────┘
                            ▼
┌─────────────────────────────────────────────────────────────┐
│                       LLM Wiki 仓库                           │
│                                                             │
│  raw/       原始资料                                          │
│  wiki/      知识页面                                          │
│  schema/    维护规则                                          │
│  index.md   总索引                                            │
│  log.md     更新日志                                          │
└───────────────────────────┬─────────────────────────────────┘
                            ▼
┌─────────────────────────────────────────────────────────────┐
│                         展示层                               │
│                                                             │
│  Obsidian 本地浏览   MkDocs 静态站   Hugo   Next.js   GitHub Pages │
└─────────────────────────────────────────────────────────────┘

这张图的关键点是：

Hermes Agent 不直接等同于知识库。
它是知识库的维护者、调度器和自动化执行器。

真正的知识库本体仍然是：
raw/ + wiki/ + schema/ + index.md + log.md

5.6 一个典型部署方式：VPS + Telegram + Git + Web

公开文章中有人把 Hermes Agent 部署在 Linux VPS 上，连接 Telegram 作为“第二大脑”入口，然后把 Karpathy 的 LLM Wiki 模式作为 spec 喂给 Hermes，让 Hermes 维护本地 git repo 中的 wiki，并通过静态网站暴露出来。(Medium)

这类部署大概可以理解成：

你在手机上看到一篇文章
        ↓
转发给 Telegram Bot
        ↓
Hermes Agent 在 VPS 上收到链接
        ↓
Agent 下载网页内容
        ↓
Agent 调用 LLM 总结和分类
        ↓
Agent 更新 wiki/ 里的 Markdown 页面
        ↓
Agent 写入 log.md
        ↓
Agent git commit
        ↓
Agent 构建静态网站
        ↓
你在浏览器里看到更新后的知识库

如果用步骤写出来，大概是：

1. 买一台 Linux VPS

2. 安装 Hermes Agent

3. 配置模型 API
   例如 OpenAI / OpenRouter / Anthropic / 本地模型

4. 配置 Telegram Bot 或 Web UI 网关

5. 创建一个 wiki git repo

6. 建立目录：
   raw/
   wiki/
   schema/
   index.md
   log.md

7. 把 LLM Wiki 维护规则写进 schema/AGENTS.md

8. 给 Hermes 定义核心任务：
   ingest：摄取新资料
   query：基于 Wiki 回答问题
   lint：检查知识库健康度
   review：生成总结报告
   publish：发布为静态网站

9. 用 MkDocs / Hugo / Next.js / Quartz 把 wiki 发布成网页

10. 可选：
    本地用 Obsidian 打开同步后的 Markdown

5.7 推荐目录结构：给 Agent 一个清晰的工作空间

Hermes Agent 一定要有清晰的目录结构。

如果你只给它一个混乱文件夹，它很容易乱写、乱建页面、乱改旧内容。

一个推荐结构如下：

hermes_llm_wiki/
├── raw/
│   ├── papers/
│   ├── articles/
│   ├── webclips/
│   ├── books/
│   └── notes/
│
├── inbox/
│   ├── urls.md
│   ├── todo.md
│   └── incoming_files/
│
├── wiki/
│   ├── concepts/
│   ├── papers/
│   ├── people/
│   ├── products/
│   ├── projects/
│   ├── comparisons/
│   ├── questions/
│   └── index.md
│
├── schema/
│   ├── AGENTS.md
│   ├── task_policy.md
│   ├── page_template.md
│   ├── naming_rules.md
│   ├── citation_rules.md
│   ├── safety_rules.md
│   └── publish_rules.md
│
├── reports/
│   ├── weekly/
│   └── monthly/
│
├── logs/
│   ├── ingest.log
│   ├── query.log
│   └── agent_actions.log
│
├── site/
│   └── mkdocs.yml
│
├── index.md
├── log.md
└── README.md

这里面最重要的是 schema/AGENTS.md。

它相当于 Hermes Agent 的“工作说明书”。

5.8 AGENTS.md 应该怎么写？

如果 AGENTS.md 写得差，Agent 就会变成“乱写笔记的 AI”。

如果 AGENTS.md 写得好，Agent 才像一个可靠的知识库维护员。

一个简化版可以这样写：

# Hermes LLM Wiki Agent Rules

你是这个 LLM Wiki 的维护 Agent。

## 你的目标

你需要持续维护一个结构化 Markdown Wiki，而不是简单总结资料。

你的任务包括：

1. 摄取新资料
2. 提取关键概念
3. 更新已有页面
4. 新建必要页面
5. 补充双向链接
6. 维护 index.md
7. 记录 log.md
8. 检查矛盾和过期内容

## 目录规则

- raw/ 保存原始资料，原则上不要修改。
- inbox/ 保存待处理资料。
- wiki/concepts/ 保存概念页。
- wiki/papers/ 保存论文页。
- wiki/comparisons/ 保存对比页。
- wiki/questions/ 保存高频问题页。
- reports/ 保存周期性总结。
- logs/ 保存 Agent 操作日志。

## 更新规则

- 优先更新已有页面，不要重复创建同义页面。
- 如果新资料引入了新概念，再创建新页面。
- 每次修改 wiki/ 后，都必须更新 log.md。
- 每个关键结论必须标注来源。
- 如果新资料和旧结论冲突，不要覆盖旧结论，要写入“争议与矛盾”。

## 安全规则

- 不要删除 raw/ 文件。
- 不要批量删除 wiki/ 页面。
- 修改超过 5 个页面前，先输出更新计划。
- 涉及 schema/ 的修改必须先征求用户确认。
- 执行 git commit 前必须生成变更摘要。

## 输出风格

- 先给结论。
- 再列出修改内容。
- 最后列出待人工确认的问题。

这份规则的作用是给 Agent 加上“轨道”。

否则它可能今天建一个 AI.md，明天建一个 Artificial_Intelligence.md，后天又建一个 人工智能.md，最后知识库会变得越来越乱。

5.9 Hermes Agent 的核心任务：ingest / query / lint / review / publish

Hermes Agent 维护知识库时，最好不要只有一个“万能任务”。

应该把任务拆成几类。

┌────────────────────────────────────────────┐
│             Hermes Agent 核心任务            │
├────────────────────────────────────────────┤
│ ingest                                      │
│ 摄取新资料，更新 Wiki                         │
├────────────────────────────────────────────┤
│ query                                       │
│ 基于 Wiki 回答用户问题                        │
├────────────────────────────────────────────┤
│ lint                                        │
│ 检查知识库健康度                              │
├────────────────────────────────────────────┤
│ review                                      │
│ 生成周报、月报、研究综述                       │
├────────────────────────────────────────────┤
│ publish                                     │
│ 构建并发布静态网站                             │
└────────────────────────────────────────────┘

这几个任务分别解决不同问题。

🧑‍💻 ingest：摄取新资料

用户发来一篇论文、文章、网页链接时，Agent 执行 ingest。

输入：
一篇文章、一个链接、一个 PDF、一个 Markdown 文件

输出：
更新后的 wiki 页面、index.md、log.md

工作流：

新资料进入 inbox/
        ↓
Agent 判断资料类型
        ↓
复制或保存到 raw/
        ↓
读取 schema/AGENTS.md
        ↓
抽取主题、概念、结论、来源
        ↓
判断应该新建还是更新页面
        ↓
写入 wiki/
        ↓
更新 index.md
        ↓
更新 log.md
🔍 query：基于 Wiki 回答问题

用户问：

RAG 和 LLM Wiki 的本质区别是什么？

Agent 不一定需要去原始文档里检索。

它可以优先读取：

wiki/concepts/RAG.md
wiki/concepts/LLM_Wiki.md
wiki/comparisons/RAG_vs_LLM_Wiki.md
index.md

再回答用户。

🛡️ lint：检查知识库健康度

这个任务非常重要。

它可以定期检查：

有没有孤立页面？
有没有重复概念？
有没有页面缺少来源？
有没有 index.md 没收录的页面？
有没有坏链接？
有没有新旧结论冲突？
有没有页面太长需要拆分？

例如输出：

知识库健康检查报告：

1. 发现 3 个孤立页面：
   - wiki/concepts/Agent_Memory.md
   - wiki/questions/How_to_reduce_token_cost.md
   - wiki/projects/Old_RAG_Demo.md

2. 发现 2 个疑似重复页面：
   - wiki/concepts/RAG.md
   - wiki/concepts/Retrieval_Augmented_Generation.md

3. 发现 4 个页面缺少来源：
   - wiki/concepts/LLM_Wiki.md
   - wiki/concepts/Embedding.md

4. 建议更新 index.md：
   - 新增 Agent Memory 相关链接
📚 review：生成周期性总结

Agent 可以每周生成一份总结：

本周新增了哪些资料？
哪些主题增长最快？
哪些概念出现频率最高？
有哪些新问题值得继续研究？
有哪些旧结论需要复查？

例如：

reports/weekly/2026-04-27.md

内容可以包括：

# Weekly Knowledge Review - 2026-04-27

## 本周新增资料

- Karpathy LLM Wiki
- Dify Knowledge 文档
- OpenAI File Search 文档
- Hermes Agent 相关文章

## 本周新增页面

- [[LLM_Wiki]]
- [[RAG_vs_LLM_Wiki]]
- [[Hermes_Agent]]

## 本周值得继续研究的问题

1. LLM Wiki 是否可以和向量检索混合？
2. Agent 自动更新 Wiki 时如何控制幻觉？
3. 如何设计低 Token 成本的 Wiki 更新流程？
🚀 publish：发布成 Web

当 Wiki 更新后，Agent 可以执行：

mkdocs build
git commit
git push
部署到 GitHub Pages / VPS / Vercel

这样你的知识库就不只是本地 Obsidian 笔记，而可以变成一个公开或私有的知识网站。

5.10 Hermes Agent 的核心伪代码：一个长期运行的 Agent Loop

可以用下面这个伪代码理解 Hermes Agent。

def hermes_agent_loop():
    """
    Hermes Agent 主循环：
    长期监听用户输入、定时任务和文件变化，
    然后调度不同知识库维护任务。
    """

    while True:
        # 1. 等待新任务
        task = wait_for_task()

        # 2. 识别任务类型
        task_type = classify_task(task)

        # 3. 根据任务类型调度
        if task_type == "ingest":
            result = ingest_new_source(task)

        elif task_type == "query":
            result = answer_from_wiki(task)

        elif task_type == "lint":
            result = lint_wiki()

        elif task_type == "review":
            result = generate_review_report(task)

        elif task_type == "publish":
            result = publish_wiki_site()

        else:
            result = ask_user_for_clarification(task)

        # 4. 记录操作日志
        write_agent_log(task, task_type, result)

        # 5. 如果有文件修改，生成 diff 摘要
        if workspace_has_changes():
            diff_summary = summarize_git_diff()

            # 6. 根据策略决定是否自动提交
            if can_auto_commit(task_type, diff_summary):
                git_commit(diff_summary)

        # 7. 返回结果给用户
        send_result_to_user(result)

这段代码暴露了 Hermes Agent 的本质：

它不是一次性问答函数。
它是长期运行的知识库维护循环。

RAG 的核心函数是：

retrieve_then_generate()

LLM Wiki 的核心函数是：

compile_source_to_wiki()

Hermes Agent 的核心函数是：

agent_loop()

这三者的层级完全不同。

5.11 ingest_new_source() 函数解析：Agent 如何处理一篇新文章？

假设你把一篇文章链接发给 Telegram Bot：

https://example.com/article-about-llm-wiki

Agent 的 ingest 函数可以这样设计：

def ingest_new_source(task):
    """
    摄取新资料，并更新 LLM Wiki。
    """

    # 1. 获取资料
    source = fetch_source(task.input)

    # 2. 保存原始资料到 raw/
    raw_path = save_to_raw(source)

    # 3. 读取维护规则
    agent_rules = read_file("schema/AGENTS.md")
    naming_rules = read_file("schema/naming_rules.md")
    citation_rules = read_file("schema/citation_rules.md")

    # 4. 抽取结构化知识
    extracted = llm_extract(source.text, rules=agent_rules)

    # 5. 读取现有索引
    index = read_file("wiki/index.md")

    # 6. 生成更新计划
    update_plan = llm_plan_update(
        extracted=extracted,
        existing_index=index,
        naming_rules=naming_rules
    )

    # 7. 安全检查：如果要修改太多页面，先让用户确认
    if len(update_plan.pages_to_modify) > 5:
        return ask_user_to_confirm(update_plan)

    # 8. 执行页面更新
    for page in update_plan.pages_to_modify:
        old_content = read_file_if_exists(page.path)

        new_content = llm_update_page(
            old_content=old_content,
            extracted=extracted,
            citation_rules=citation_rules
        )

        write_file(page.path, new_content)

    # 9. 更新 index 和 log
    update_index(update_plan)
    append_log(raw_path, update_plan)

    # 10. 生成变更摘要
    diff_summary = summarize_git_diff()

    return {
        "raw_path": raw_path,
        "updated_pages": update_plan.pages_to_modify,
        "diff_summary": diff_summary
    }

这个函数里最关键的不是 LLM 总结，而是这几个控制点：

保存 raw：
保留原始证据。

读取 schema：
让 Agent 按规则做事。

生成 update_plan：
先计划，再修改。

安全检查：
防止 Agent 一次性乱改太多文件。

diff_summary：
让用户知道它到底改了什么。

5.12 lint_wiki() 函数解析：Agent 如何检查知识库健康度？

知识库长期运行后，一定会出现结构问题。

所以 Hermes Agent 最有价值的任务之一是 lint_wiki()。

def lint_wiki():
    """
    检查 LLM Wiki 的结构健康度。
    """

    pages = scan_markdown_pages("wiki/")
    index = read_file("wiki/index.md")

    report = {
        "orphan_pages": [],
        "duplicate_candidates": [],
        "missing_sources": [],
        "broken_links": [],
        "not_indexed_pages": [],
        "too_long_pages": []
    }

    # 1. 检查孤立页面
    link_graph = build_link_graph(pages)

    for page in pages:
        if link_graph.in_degree(page) == 0 and link_graph.out_degree(page) == 0:
            report["orphan_pages"].append(page)

    # 2. 检查疑似重复页面
    for page_a, page_b in pairwise(pages):
        if title_similarity(page_a, page_b) > 0.85:
            report["duplicate_candidates"].append((page_a, page_b))

    # 3. 检查缺少来源的页面
    for page in pages:
        content = read_file(page)

        if contains_key_claims(content) and not has_source_section(content):
            report["missing_sources"].append(page)

    # 4. 检查坏链接
    for page in pages:
        links = extract_wikilinks(read_file(page))

        for link in links:
            if not page_exists(link):
                report["broken_links"].append((page, link))

    # 5. 检查未加入 index 的页面
    for page in pages:
        if page not in index:
            report["not_indexed_pages"].append(page)

    # 6. 检查过长页面
    for page in pages:
        if token_count(read_file(page)) > 6000:
            report["too_long_pages"].append(page)

    return report

这个函数非常像代码项目里的 lint 工具。

代码项目有：

eslint
pylint
clang-tidy

LLM Wiki 也应该有自己的：

wiki-lint

它检查的不是代码格式，而是知识结构质量。

5.13 Hermes Agent 的安全边界：为什么不能让 Agent 随便改？

Hermes Agent 最大的优势是自动化。

但最大风险也来自自动化。

因为它可能有：

文件读取权限
文件写入权限
网页访问权限
Git 提交权限
静态站点发布权限
甚至终端执行权限

这就意味着，一旦 Agent 行为失控，可能出现：

误删 raw 原始资料
覆盖已有 Wiki 页面
错误合并概念
把推断写成事实
提交错误内容
发布未审核知识
泄露私有资料

所以 Hermes Agent 路线一定要有安全边界。

可以设计成三层防线。

🛡️ 第一层：文件权限边界
raw/：
只允许新增，不允许删除和覆盖。

schema/：
默认只读，修改必须人工确认。

wiki/：
允许修改，但大范围修改需要确认。

logs/：
只允许追加，不允许删除历史记录。

site/：
允许构建输出，但不允许改核心配置。

可以写成策略：

def check_file_permission(action, path):
    if path.startswith("raw/") and action in ["delete", "overwrite"]:
        raise PermissionError("raw/ 原始资料禁止删除或覆盖")

    if path.startswith("schema/") and action in ["write", "delete"]:
        require_human_confirmation("修改 schema/ 需要人工确认")

    if action == "delete" and path.startswith("wiki/"):
        require_human_confirmation("删除 wiki 页面需要人工确认")

    return True
🛡️ 第二层：操作规模边界

如果 Agent 一次只改 1 个页面，风险较低。

如果一次要改 30 个页面，就必须人工确认。

def check_update_scope(update_plan):
    if len(update_plan.pages_to_modify) > 5:
        require_human_confirmation(
            "本次计划修改超过 5 个页面，请确认后再执行"
        )

    if len(update_plan.pages_to_delete) > 0:
        require_human_confirmation(
            "本次计划删除页面，请确认后再执行"
        )

    return True
🛡️ 第三层：Git diff 审查边界

Agent 修改完之后，不应该悄悄提交。

最好先输出：

本次修改了哪些文件？
每个文件新增了什么？
删除了什么？
哪些内容是 AI 推断？
哪些内容来自原始资料？

然后用户再决定是否 commit。

git diff
git status
git add wiki/
git commit -m "Update LLM Wiki with new RAG article"

这个流程非常重要。

因为 Git 是 Agent 自动化的安全绳。

5.14 Hermes Agent 路线的优点

这条路线最吸引人的地方是：

知识库不再是一个死文件夹，而是一个持续工作的系统。

🚀 优点一：自动维护成本低

传统 LLM Wiki 需要你手动做很多事情：

移动资料到 raw/
新建页面
更新旧页面
补充链接
更新 index.md
写 log.md
检查坏链接
整理重复概念

Hermes Agent 可以把这些重复工作自动化。

你只需要：

把资料丢进去
看它的更新计划
审核关键修改

这对长期研究非常有价值。

因为真正消耗人的不是“读一篇文章”，而是“长期维护结构”。

🚀 优点二：非常适合移动端输入

很多资料不是你坐在电脑前看到的，而是在手机上刷到的。

比如：

一篇论文
一篇博客
一个 GitHub 项目
一个产品公告
一个行业分析
一个视频文字稿

如果你要手动整理，流程很麻烦：

复制链接
发到电脑
打开 Obsidian
创建页面
写摘要
加标签
更新索引

Hermes Agent 的体验可以变成：

手机上看到文章
        ↓
转发给 Telegram Bot
        ↓
Agent 自动处理
        ↓
晚上打开知识库，已经整理好了

这就是它很适合“第二大脑”的原因。

🚀 优点三：知识可以发布到 Web

Obsidian 更偏本地个人知识管理。

Hermes Agent + Web 可以把 Wiki 变成：

个人知识网站
团队内部知识站
公开技术博客
研究方向地图
课程资料站
项目文档站

例如：

wiki/
  ↓
MkDocs build
  ↓
静态 HTML
  ↓
部署到 GitHub Pages / VPS / Vercel

这样你的知识库不只是自己看，还可以分享给团队、同学、读者。

🚀 优点四：可以定期生成报告

Hermes Agent 长期运行后，可以做很多主动任务。

例如每周自动生成：

本周新增了哪些资料？
哪些页面更新最多？
哪些概念越来越重要？
哪些页面缺少来源？
哪些主题值得继续研究？

这对研究生非常有用。

比如你长期研究 RAG 和 Agent，每周可以得到：

本周新增知识：
- LLM Wiki
- Hermes Agent
- OpenAI File Search
- Dify Knowledge

本周核心变化：
- RAG 与 LLM Wiki 对比页新增 Token 成本分析
- Hermes Agent 页面新增安全边界设计
- Obsidian 页面新增 Graph View 说明

下周建议研究：
- Agent 自动更新 Wiki 的幻觉控制
- Wiki-lint 工具设计
- RAG + LLM Wiki 混合架构

这就像一个 AI 研究助理。

🚀 优点五：Agent 可以帮助改进知识库规则

Hermes Agent 不只能更新内容，还可以观察你的知识库结构问题。

比如它发现：

很多概念页没有“来源”小节
很多对比页格式不统一
index.md 没有收录新页面
同义页面太多

它可以建议修改 schema：

建议在 page_template.md 中增加：
- 来源
- 相关页面
- 争议与矛盾
- 最后更新时间

这就是“自我改进知识库”的雏形。

注意，不是说 Agent 真的自己变聪明了，而是：

它可以通过检查知识库结构，反过来改进维护规则。

5.15 Hermes Agent 路线的缺点

Hermes Agent 很强，但它也是三种路线里最复杂、风险最高、最容易烧 Token 的。

✋ 缺点一：部署复杂度最高

RAG 可以用 Dify 很快搭起来。

Obsidian 可以本地打开就用。

Hermes Agent 需要涉及：

Linux VPS
Bot 网关
LLM API
文件系统
Git
静态网站生成器
权限控制
日志系统
任务调度
错误恢复

所以它不适合完全零基础用户一上来就搞。

更适合：

已经理解 RAG
已经会用 Obsidian
已经知道 LLM Wiki 怎么组织
想进一步自动化维护知识库的人
✋ 缺点二：安全风险更高

Agent 如果有终端权限、文件写权限、Web 访问权限，就必须限制权限。

否则它可能：

误删文件
错误覆盖页面
提交错误内容
发布敏感资料
错误执行命令

所以 Hermes Agent 一定要配合：

权限边界
人工确认
Git diff
操作日志
回滚机制
敏感目录保护

这和工业级 Agent 的设计思想一致：真正可靠的 Agent 不能只靠模型自觉，必须靠工具层、权限层和状态管理来约束。

✋ 缺点三：Token 消耗可能最高

Hermes Agent 不只是回答问题。

它会做很多额外操作：

读取资料
总结资料
抽取概念
生成更新计划
更新多个页面
维护索引
检查矛盾
补充交叉链接
生成日志
生成周报
可能还要构建网页

如果没有控制，很容易变成“自动烧 Token 机器”。

例如处理一篇长文章时，可能发生：

第一次 LLM 调用：
总结文章

第二次 LLM 调用：
抽取概念

第三次 LLM 调用：
规划更新页面

第四次 LLM 调用：
改写概念页

第五次 LLM 调用：
改写对比页

第六次 LLM 调用：
更新 index.md

第七次 LLM 调用：
生成日志

这比普通 RAG 单次问答贵得多。

所以 Hermes Agent 必须做预算控制：

def should_process_task(task, budget):
    estimated_tokens = estimate_task_tokens(task)

    if estimated_tokens > budget.max_tokens_per_task:
        return "需要用户确认：本次任务预计 Token 消耗较高"

    return "允许执行"
✋ 缺点四：质量高度依赖 schema

Hermes Agent 只是执行者。

真正决定知识库质量的是：

AGENTS.md 写得好不好
页面模板是否清晰
命名规则是否稳定
引用规则是否严格
更新策略是否安全

如果 schema 很差，Agent 会把错误自动化放大。

比如你没有写：

不要重复创建同义页面

它可能创建：

RAG.md
Retrieval_Augmented_Generation.md
检索增强生成.md

如果你没有写：

关键结论必须标注来源

它可能生成一堆看起来很专业但无法追溯的总结。

所以 Hermes Agent 的质量不是单纯由模型决定，而是由：

模型能力 + 工具能力 + schema 规则 + 安全边界 + 人类审核

共同决定。

✋ 缺点五：需要长期运维

Hermes Agent 是长期运行系统，就会有运维问题。

例如：

VPS 挂了
Bot token 失效
LLM API 额度用完
网页解析失败
Git push 失败
静态站点构建失败
任务队列堆积
日志太大

这和本地 Obsidian 笔记不一样。

Obsidian 是软件。

Hermes Agent 是服务。

服务就需要监控、日志、备份和恢复。

5.16 Hermes Agent 适合哪些场景？

Hermes Agent + LLM Wiki 特别适合：

个人第二大脑
研究生长期读论文
产品经理长期行业调研
创业者资料库
开源项目长期跟踪
团队轻量知识库
公开知识网站
AI 技术博客素材库
实验室研究资料库

这些场景有几个共同点：

资料持续增加
知识需要长期整理
人工维护成本很高
用户希望随手输入
知识最好能发布和分享

例如：

你长期跟踪 RAG、Agent、LLM Wiki、Cursor、Claude Code、OpenAI API。

每天看到很多文章和项目。

如果靠手动整理，很快就放弃。

如果有 Hermes Agent：
你只要把链接转发给 Bot，
它就能后台整理、更新、归档、生成周报。

5.17 Hermes Agent 不适合哪些场景？

它不太适合：

简单 FAQ 问答
一次性 PDF 问答
企业高并发客服系统
强监管、强审计但没有人工审核流程的场景
完全零基础用户
不愿意维护 VPS 和 Git 的用户
Token 成本非常敏感的场景

如果你只是想：

上传一个 PDF，然后问几个问题

那用 RAG 就够了。

如果你只是想：

本地整理自己的学习笔记

那 LLM Wiki + Obsidian 就够了。

Hermes Agent 适合的是：

资料长期增长
知识库需要持续维护
你希望尽量自动化
你愿意承担部署和安全成本

5.18 一个推荐的 Hermes Agent 工作流

如果要真正落地，推荐不要一开始就让 Agent 全自动修改。

更安全的流程是“半自动”。

第一步：用户投递资料
用户在 Telegram 里发：
https://example.com/new-rag-article
第二步：Agent 生成处理计划
我已读取该文章，建议执行以下更新：

1. 保存原文到：
   raw/articles/new-rag-article.md

2. 更新页面：
   wiki/concepts/RAG.md
   wiki/comparisons/RAG_vs_LLM_Wiki.md

3. 新建页面：
   wiki/concepts/Hybrid_RAG_Wiki.md

4. 更新：
   wiki/index.md
   log.md

是否执行？
第三步：用户确认
同意执行，但不要新建 Hybrid_RAG_Wiki.md，先把内容放到 RAG_vs_LLM_Wiki.md。
第四步：Agent 执行修改
已完成：

- 保存 raw/articles/new-rag-article.md
- 更新 wiki/concepts/RAG.md
- 更新 wiki/comparisons/RAG_vs_LLM_Wiki.md
- 更新 wiki/index.md
- 更新 log.md

本次没有新建 Hybrid_RAG_Wiki.md。
第五步：Agent 输出 diff 摘要
变更摘要：

1. RAG.md
   - 新增“混合检索”小节
   - 补充 BM25 + Vector Search 对比

2. RAG_vs_LLM_Wiki.md
   - 新增“混合架构”部分
   - 补充 Token 成本对比

3. index.md
   - 新增 RAG_vs_LLM_Wiki 链接

4. log.md
   - 记录本次资料来源和修改内容
第六步：用户决定是否 commit
确认提交。

Agent 再执行：

git add raw/ wiki/ index.md log.md
git commit -m "Update RAG wiki from new article"

这个流程比“Agent 直接全自动乱改”安全很多。

5.19 Hermes Agent 和 Obsidian / Web 的关系

这条路线里，Obsidian 不是必须的。

你可以有三种使用方式。

方式一：Hermes Agent + Obsidian

适合个人知识管理。

Agent 自动维护 Markdown
        ↓
Obsidian 打开本地 Vault
        ↓
用户查看双向链接和图谱

优点：

本地可控
编辑舒服
适合个人研究
方式二：Hermes Agent + Web

适合公开知识网站或团队知识库。

Agent 自动维护 Markdown
        ↓
MkDocs / Hugo / Next.js 构建网站
        ↓
用户浏览网页

优点：

容易分享
适合团队
适合公开发布
方式三：Hermes Agent + Obsidian + Web

这是最完整的模式。

Agent 负责维护
Obsidian 负责本地编辑
Web 负责分享和发布
Git 负责版本控制

可以画成这样：

┌──────────────────────┐
│    Hermes Agent       │
│ 自动摄取、更新、检查    │
└───────────┬──────────┘
            │ 写 Markdown
            ▼
┌──────────────────────┐
│      Git Wiki Repo    │
│ raw / wiki / schema   │
└───────┬─────────┬────┘
        │         │
        ▼         ▼
┌──────────────┐ ┌────────────────┐
│  Obsidian     │ │ Static Web Site │
│ 本地编辑和图谱 │ │ 公开或团队访问   │
└──────────────┘ └────────────────┘

5.20 小结：Hermes Agent 是让知识库“自己生长”的路线

Hermes Agent + LLM Wiki + Obsidian / Web 的核心价值是：

让知识库从一个静态文件夹，变成一个持续工作的知识系统。

它解决的问题不是“怎么回答一个问题”，而是：

谁来持续摄取新资料？
谁来更新旧页面？
谁来维护索引？
谁来检查坏链接？
谁来记录矛盾？
谁来生成周报？
谁来发布网站？

RAG 解决的是：

当前问题应该检索哪些资料？

LLM Wiki 解决的是：

这些资料应该沉淀成什么知识结构？

Hermes Agent 解决的是：

谁来长期维护这套知识结构？

所以三者可以这样理解：

RAG：
知识库的搜索引擎。

LLM Wiki：
知识库的百科结构。

Obsidian：
知识库的人类编辑器。

Hermes Agent：
知识库的自动维护员。

但是也要注意：

Hermes Agent 最强，也最复杂。
它自动化程度最高，但安全风险、部署成本、Token 成本也最高。

所以最稳妥的学习路径是：

第一步：
先理解 RAG，知道知识检索怎么做。

第二步：
再尝试 LLM Wiki + Obsidian，理解知识如何沉淀。

第三步：
最后再上 Hermes Agent，让知识库逐渐自动维护。

最终，一个成熟的知识库系统可能不是三选一，而是组合：

底层用 RAG：
负责海量原始资料检索。

中层用 LLM Wiki：
负责高价值知识沉淀。

上层用 Hermes Agent：
负责自动摄取、更新、检查和发布。

界面用 Obsidian / Web：
负责人类阅读、编辑和分享。

一句话总结：

Hermes Agent 不是让 AI 多回答几个问题，而是让 AI 变成知识库的长期维护者。

这就是它和普通 RAG、普通 Obsidian 笔记最大的区别。

6. 三种方法的核心区别：到底差在哪里？

6.1 架构层面对比

维度 RAG 知识库 LLM Wiki + Obsidian Hermes Agent + LLM Wiki
核心思想 检索相关片段，再生成答案 把资料编译成结构化 Wiki 让 Agent 自动维护 Wiki
知识本体 原始文档 + 向量库 Markdown Wiki Markdown Wiki + Agent 工作流
主要工具 向量数据库、Embedding、Rerank Obsidian、Markdown、LLM Agent Hermes、Telegram/Web、Git、LLM
是否需要向量库 通常需要 小规模可不需要 可选
是否长期积累 弱，需要额外设计 强 很强
更新速度 快，上传后可检索 中等，需要整合 中等到慢，但自动化
可解释性 看引用 chunk 看 Wiki 页面和来源 看 Wiki 页面、log、Agent 操作记录
适合规模 中大型文档库 个人/小团队知识库 个人/小团队长期知识系统
产品化难度 中等，生态成熟 中等偏高 高
自动化程度 中 中 高

6.2 Token 消耗对比

如果只看单次问答，一般是：

RAG < LLM Wiki 查询 < Hermes Agent 维护

但如果看长期研究，情况会变：

短期问答：RAG 最省
长期积累：LLM Wiki 可能更省
全自动维护：Hermes 最方便，但最容易烧 Token

更具体一点：

场景 Token 消耗
RAG 单次问答 主要消耗在检索 chunk + LLM 生成
RAG 多次复杂问答 每次都重新检索和综合，重复消耗较多
LLM Wiki 初次整理 很耗 Token，因为要读 raw、总结、建链接
LLM Wiki 后续查询 可能更省，因为读结构化页面即可
Hermes Agent 自动维护 最高，因为除了问答，还要 ingest、lint、更新、写日志

所以结论不是“哪个永远更省”，而是：

一次性问答选 RAG；长期研究选 LLM Wiki；想自动维护选 Hermes Agent，但要控制任务边界和预算。

7. 知识更新速度：谁迭代最快？

7.1 RAG 更新最快

RAG 的更新方式最直接：

上传新文档
  ↓
切块
  ↓
向量化
  ↓
入库
  ↓
可以检索

所以在“文档频繁更新”的场景下，RAG 很强。

例如：

公司制度每天更新
客服 FAQ 经常变化
产品说明书版本迭代
电商商品知识库
法律法规数据库

这些场景不一定需要精美的 Wiki，只需要快速查到最新内容。

7.2 LLM Wiki 更新更慢，但质量更高

LLM Wiki 的更新不是简单入库，而是整合：

新资料进 raw/
  ↓
LLM 阅读
  ↓
提取关键信息
  ↓
判断应该更新哪些旧页面
  ↓
新建或修改概念页
  ↓
更新索引
  ↓
记录来源和矛盾

这比 RAG 慢，但得到的是“消化后的知识”。

7.3 Hermes Agent 更新可以自动化，但不一定最快

Hermes Agent 可以帮你自动做 LLM Wiki 的维护流程，但它依然要读、写、检查、重构。速度取决于：

资料长度
模型速度
Agent 工具效率
是否增量处理
是否有缓存
是否有清晰 schema

如果做得好，它不是最快的，但它是最省人力的。

8. 目前市场上哪些产品更接近这些路线？

8.1 RAG 路线产品

这一类最多，也是商业化最成熟的。

典型产品和平台包括：

OpenAI file search
Dify Knowledge
FastGPT
AnythingLLM
LangChain / LlamaIndex 应用
Glean
Microsoft Copilot Studio
Google NotebookLM 的部分能力
企业内部知识问答机器人

Dify 官方文档明确说明其 Knowledge 可用于客服机器人、内部知识门户、内容生成工具、研究分析应用等典型 RAG 场景。(Dify 文档) Microsoft Copilot Studio 的知识源则可以让 agent 使用企业数据、Dynamics 365 数据、网站和外部系统来生成回答，并且会考虑用户访问权限。(Microsoft Learn) Glean 这类企业搜索产品强调连接企业数据、企业级权限、数据治理和可引用性，也更接近企业级 RAG / AI Search。(Glean)

8.2 LLM Wiki + Obsidian 路线产品

这一类目前更像“工作流模式”，不是完全标准化的商业产品。

典型组合是：

Obsidian + Claude Code
Obsidian + ChatGPT / Codex
Obsidian + Cursor
Obsidian + Local LLM
Markdown Vault + Agent

Karpathy 的 LLM Wiki 模式明确提到，实践中可以让 LLM Agent 在一边，Obsidian 在另一边；LLM 根据对话修改 Wiki，用户在 Obsidian 中实时浏览、检查图谱和页面。(Gist)

这类方法特别适合学生和研究者，因为它不像企业 RAG 那样需要数据库和后端服务，只需要：

一个 Markdown 文件夹
一个 LLM Agent
一个 Obsidian
一套清晰规则

8.3 Hermes Agent + LLM Wiki 路线产品

这一类更偏“自托管 Agent 工作流”。

公开案例里，作者把 Hermes Agent 部署在小型 Linux VPS 上，连接 Telegram，把 Karpathy 的 LLM Wiki pattern 作为 spec，让 Hermes 维护 wiki repo，并通过静态站点发布。(Medium)

它不一定是主流企业产品路线，但代表了一个很重要的趋势：

知识库从“被动查询系统”变成“主动维护系统”。

这对未来 AI Agent 产品非常重要。因为未来很多产品不是让用户点按钮上传文档，而是：

用户随手丢资料
Agent 自动分类
Agent 自动总结
Agent 自动建立链接
Agent 自动提醒矛盾
Agent 自动产出报告

9. 面对不同场景，到底该选哪一种？

9.1 企业客服 / 内部制度问答：优先 RAG

如果你的目标是：

让员工快速查制度
让客户快速查 FAQ
让售后机器人回答产品问题
让销售查产品手册

建议优先 RAG。

原因很简单：

文档多
更新快
问题明确
答案需要引用来源
产品需要稳定上线

推荐架构：

Dify / FastGPT / LangChain
+ 向量数据库
+ embedding
+ reranker
+ 权限系统
+ 引用展示

9.2 研究生读论文 / 写综述：优先 LLM Wiki + Obsidian

如果你的目标是：

长期读论文
积累研究方向
写文献综述
做开题报告
跟踪技术路线

建议用 LLM Wiki + Obsidian。

因为这类任务最怕的不是“搜不到”，而是：

读过就忘
笔记之间没有联系
不同论文观点无法比较
几个月后不知道自己当时怎么理解

推荐结构：

raw/papers/
wiki/concepts/
wiki/methods/
wiki/datasets/
wiki/experiments/
wiki/comparisons/
index.md
literature_map.md
open_questions.md

9.3 个人第二大脑 / 长期知识网站：选择 Hermes Agent + LLM Wiki

如果你的目标是：

看到文章随手丢给机器人
让知识库自动更新
想在手机上随时输入
想把 Wiki 发布成网站
不想每天手动维护 Obsidian

可以考虑 Hermes Agent + LLM Wiki。

但前提是你愿意折腾部署，并且能接受一定的 Token 成本和维护复杂度。

9.4 大规模实时业务知识库：RAG + 局部 Wiki 混合

真实企业里，我最推荐的不是三选一，而是混合架构：

底层：RAG 管所有原始文档
中层：LLM Wiki 管高价值知识总结
上层：Agent 管自动更新、审查和报告

例如一个机器人公司内部知识库可以这样设计：

RAG：
  存所有代码文档、硬件手册、会议纪要、测试报告

LLM Wiki：
  维护核心技术页：
  - RK3588 部署经验
  - VAD 远场抑制方案
  - 唤醒词调参记录
  - 情感识别模型路线
  - ROS2 音频链路问题库

Agent：
  每周扫描新增文档
  更新问题总结
  生成周报
  标记过期方案

这样就同时利用了三者的优势。

10. 这三种方法对其他行业有什么作用？

10.1 教育行业

RAG 可以做课程资料问答：

上传教材、PPT、实验指导书
学生提问
系统引用教材回答

LLM Wiki 可以做课程知识图谱：

每一章变成概念页
每个公式变成解释页
每个实验变成操作页
章节之间建立链接

Hermes Agent 可以做学习陪跑：

学生发一篇论文
Agent 总结并放入课程 Wiki
定期生成复习计划
自动发现薄弱知识点

10.2 科研行业

RAG 适合查论文细节。

LLM Wiki 适合做长期文献综述。

Hermes Agent 适合自动跟踪新论文、生成研究地图、维护 open problems。

这对研究生非常重要，因为研究不是“读一篇论文”，而是“长期把很多论文织成一张网”。

10.3 企业知识管理

RAG 解决“查得到”。

LLM Wiki 解决“看得懂”。

Agent 解决“有人维护”。

很多公司知识库失败，不是因为没有文档，而是因为文档没人整理、没人更新、没人判断冲突。Agent + Wiki 的价值就在这里。

10.4 软件工程

RAG 可以查代码文档和 issue。

LLM Wiki 可以生成项目架构说明、模块关系、接口说明、历史决策记录。

Agent 可以自动更新变更日志、检测过期文档、生成 onboarding 文档。

这和你上传的 Claude Code 源码研究报告里的思路很像：真正高级的 AI 工具不是简单聊天，而是有 Agent 调度、工具层、上下文管理和安全边界的系统。

11. 如果继续深研，这三个方向还有哪些值得研究？

11.1 RAG 值得继续研究的方向

RAG 还远没有结束，真正难的是这些问题：

如何切块才不破坏语义？
如何做多跳检索？
如何结合关键词搜索和向量搜索？
如何加入知识图谱？
如何做权限过滤？
如何做引用溯源？
如何减少 hallucination？
如何评估检索质量？

尤其是多跳问题，比如：

“这个故障和上个月哪次测试现象类似？”

这不是简单 TopK 检索能解决的，需要检索、推理、再检索。

11.2 LLM Wiki 值得继续研究的方向

LLM Wiki 的研究重点是“知识编译”。

可以继续研究：

如何设计 schema？
如何自动发现新概念页？
如何判断旧页面需要更新？
如何处理矛盾信息？
如何保留引用来源？
如何防止 AI 过度总结导致信息丢失？
如何评价 Wiki 质量？

这里有一个很有意思的类比：

RAG 像数据库查询，LLM Wiki 像编译器。

它把 raw documents 编译成一个人和模型都能读的中间表示。

11.3 Hermes Agent 路线值得继续研究的方向

Agent 维护知识库最值得研究的是安全和自治边界：

Agent 能不能自动改旧结论？
哪些页面必须人工确认？
如何防止误删？
如何做 Git diff 审查？
如何做任务队列？
如何控制 Token 预算？
如何为不同任务分配不同 Agent？

你上传的参考报告里提到的 Manager-Worker、权限沙盒、上下文隔离、缓存边界，在这里都能直接借鉴。一个维护知识库的 Agent，也应该像一个小型 Agent OS：有主控、有子任务、有权限、有日志、有回滚，而不是让模型随便改文件。

12. 最后给一个最实用的选择建议

如果你是本科生或刚读研，我建议这样选：

第一阶段：先用 Obsidian + LLM Wiki

不要一上来就搭复杂 RAG。你可以先做：

Obsidian Vault
+ raw 文件夹
+ wiki 文件夹
+ index.md
+ AGENTS.md
+ ChatGPT / Claude / Codex 辅助维护

这个阶段你能真正理解“知识结构”是什么。

第二阶段：再学 RAG

当你的文档变多，或者你要做产品 demo，就开始学：

embedding
chunking
vector database
rerank
citation
metadata filtering

这时你会知道 RAG 为什么适合产品。

第三阶段：最后研究 Agent 自动维护

当你已经有稳定 Wiki，再考虑：

Hermes Agent
Telegram bot
Web frontend
Git 自动提交
定期 lint
自动 ingest

不要一开始就上 Hermes，否则很容易陷入部署细节，反而忘了知识库本身的设计。

13. 一句话总结

RAG、LLM Wiki、Obsidian、Hermes Agent 不是互相替代，而是处在不同层级：

RAG 解决：怎么从大量资料里快速找相关内容
LLM Wiki 解决：怎么把资料长期整理成知识结构
Obsidian 解决：怎么让人类舒服地阅读和编辑这套结构
Hermes Agent 解决：怎么让知识库长期自动维护和生长

真正高级的知识库产品，未来大概率不是单纯 RAG，也不是单纯笔记软件，而是：

RAG 做底层检索，LLM Wiki 做知识编译，Agent 做持续维护，Obsidian/Web 做人类界面。

也就是说，知识库的终局不是“上传文件问答”，而是：

           |

6.2 Token 消耗对比

如果只看单次问答，一般是：

RAG < LLM Wiki 查询 < Hermes Agent 维护

但如果看长期研究，情况会变：

短期问答：RAG 最省
长期积累：LLM Wiki 可能更省
全自动维护：Hermes 最方便，但最容易烧 Token

更具体一点：

场景 Token 消耗
RAG 单次问答 主要消耗在检索 chunk + LLM 生成
RAG 多次复杂问答 每次都重新检索和综合，重复消耗较多
LLM Wiki 初次整理 很耗 Token，因为要读 raw、总结、建链接
LLM Wiki 后续查询 可能更省，因为读结构化页面即可
Hermes Agent 自动维护 最高，因为除了问答，还要 ingest、lint、更新、写日志

所以结论不是“哪个永远更省”，而是：

一次性问答选 RAG；长期研究选 LLM Wiki；想自动维护选 Hermes Agent，但要控制任务边界和预算。

7. 知识更新速度：谁迭代最快？

7.1 RAG 更新最快

RAG 的更新方式最直接：

上传新文档
  ↓
切块
  ↓
向量化
  ↓
入库
  ↓
可以检索

所以在“文档频繁更新”的场景下，RAG 很强。

例如：

公司制度每天更新
客服 FAQ 经常变化
产品说明书版本迭代
电商商品知识库
法律法规数据库

这些场景不一定需要精美的 Wiki，只需要快速查到最新内容。

7.2 LLM Wiki 更新更慢，但质量更高

LLM Wiki 的更新不是简单入库，而是整合：

新资料进 raw/
  ↓
LLM 阅读
  ↓
提取关键信息
  ↓
判断应该更新哪些旧页面
  ↓
新建或修改概念页
  ↓
更新索引
  ↓
记录来源和矛盾

这比 RAG 慢，但得到的是“消化后的知识”。

7.3 Hermes Agent 更新可以自动化，但不一定最快

Hermes Agent 可以帮你自动做 LLM Wiki 的维护流程，但它依然要读、写、检查、重构。速度取决于：

资料长度
模型速度
Agent 工具效率
是否增量处理
是否有缓存
是否有清晰 schema

如果做得好，它不是最快的，但它是最省人力的。

8. 目前市场上哪些产品更接近这些路线？

8.1 RAG 路线产品

这一类最多，也是商业化最成熟的。

典型产品和平台包括：

OpenAI file search
Dify Knowledge
FastGPT
AnythingLLM
LangChain / LlamaIndex 应用
Glean
Microsoft Copilot Studio
Google NotebookLM 的部分能力
企业内部知识问答机器人

Dify 官方文档明确说明其 Knowledge 可用于客服机器人、内部知识门户、内容生成工具、研究分析应用等典型 RAG 场景。(Dify 文档) Microsoft Copilot Studio 的知识源则可以让 agent 使用企业数据、Dynamics 365 数据、网站和外部系统来生成回答，并且会考虑用户访问权限。(Microsoft Learn) Glean 这类企业搜索产品强调连接企业数据、企业级权限、数据治理和可引用性，也更接近企业级 RAG / AI Search。(Glean)

8.2 LLM Wiki + Obsidian 路线产品

这一类目前更像“工作流模式”，不是完全标准化的商业产品。

典型组合是：

Obsidian + Claude Code
Obsidian + ChatGPT / Codex
Obsidian + Cursor
Obsidian + Local LLM
Markdown Vault + Agent

Karpathy 的 LLM Wiki 模式明确提到，实践中可以让 LLM Agent 在一边，Obsidian 在另一边；LLM 根据对话修改 Wiki，用户在 Obsidian 中实时浏览、检查图谱和页面。(Gist)

这类方法特别适合学生和研究者，因为它不像企业 RAG 那样需要数据库和后端服务，只需要：

一个 Markdown 文件夹
一个 LLM Agent
一个 Obsidian
一套清晰规则

8.3 Hermes Agent + LLM Wiki 路线产品

这一类更偏“自托管 Agent 工作流”。

公开案例里，作者把 Hermes Agent 部署在小型 Linux VPS 上，连接 Telegram，把 Karpathy 的 LLM Wiki pattern 作为 spec，让 Hermes 维护 wiki repo，并通过静态站点发布。(Medium)

它不一定是主流企业产品路线，但代表了一个很重要的趋势：

知识库从“被动查询系统”变成“主动维护系统”。

这对未来 AI Agent 产品非常重要。因为未来很多产品不是让用户点按钮上传文档，而是：

用户随手丢资料
Agent 自动分类
Agent 自动总结
Agent 自动建立链接
Agent 自动提醒矛盾
Agent 自动产出报告

9. 面对不同场景，到底该选哪一种？

9.1 企业客服 / 内部制度问答：优先 RAG

如果你的目标是：

让员工快速查制度
让客户快速查 FAQ
让售后机器人回答产品问题
让销售查产品手册

建议优先 RAG。

原因很简单：

文档多
更新快
问题明确
答案需要引用来源
产品需要稳定上线

推荐架构：

Dify / FastGPT / LangChain
+ 向量数据库
+ embedding
+ reranker
+ 权限系统
+ 引用展示

9.2 研究生读论文 / 写综述：优先 LLM Wiki + Obsidian

如果你的目标是：

长期读论文
积累研究方向
写文献综述
做开题报告
跟踪技术路线

建议用 LLM Wiki + Obsidian。

因为这类任务最怕的不是“搜不到”，而是：

读过就忘
笔记之间没有联系
不同论文观点无法比较
几个月后不知道自己当时怎么理解

推荐结构：

raw/papers/
wiki/concepts/
wiki/methods/
wiki/datasets/
wiki/experiments/
wiki/comparisons/
index.md
literature_map.md
open_questions.md

9.3 个人第二大脑 / 长期知识网站：选择 Hermes Agent + LLM Wiki

如果你的目标是：

看到文章随手丢给机器人
让知识库自动更新
想在手机上随时输入
想把 Wiki 发布成网站
不想每天手动维护 Obsidian

可以考虑 Hermes Agent + LLM Wiki。

但前提是你愿意折腾部署，并且能接受一定的 Token 成本和维护复杂度。

9.4 大规模实时业务知识库：RAG + 局部 Wiki 混合

真实企业里，我最推荐的不是三选一，而是混合架构：

底层：RAG 管所有原始文档
中层：LLM Wiki 管高价值知识总结
上层：Agent 管自动更新、审查和报告

例如一个机器人公司内部知识库可以这样设计：

RAG：
  存所有代码文档、硬件手册、会议纪要、测试报告

LLM Wiki：
  维护核心技术页：
  - RK3588 部署经验
  - VAD 远场抑制方案
  - 唤醒词调参记录
  - 情感识别模型路线
  - ROS2 音频链路问题库

Agent：
  每周扫描新增文档
  更新问题总结
  生成周报
  标记过期方案

这样就同时利用了三者的优势。

10. 这三种方法对其他行业有什么作用？

10.1 教育行业

RAG 可以做课程资料问答：

上传教材、PPT、实验指导书
学生提问
系统引用教材回答

LLM Wiki 可以做课程知识图谱：

每一章变成概念页
每个公式变成解释页
每个实验变成操作页
章节之间建立链接

Hermes Agent 可以做学习陪跑：

学生发一篇论文
Agent 总结并放入课程 Wiki
定期生成复习计划
自动发现薄弱知识点

10.2 科研行业

RAG 适合查论文细节。

LLM Wiki 适合做长期文献综述。

Hermes Agent 适合自动跟踪新论文、生成研究地图、维护 open problems。

这对研究生非常重要，因为研究不是“读一篇论文”，而是“长期把很多论文织成一张网”。

10.3 企业知识管理

RAG 解决“查得到”。

LLM Wiki 解决“看得懂”。

Agent 解决“有人维护”。

很多公司知识库失败，不是因为没有文档，而是因为文档没人整理、没人更新、没人判断冲突。Agent + Wiki 的价值就在这里。

10.4 软件工程

RAG 可以查代码文档和 issue。

LLM Wiki 可以生成项目架构说明、模块关系、接口说明、历史决策记录。

Agent 可以自动更新变更日志、检测过期文档、生成 onboarding 文档。

这和你上传的 Claude Code 源码研究报告里的思路很像：真正高级的 AI 工具不是简单聊天，而是有 Agent 调度、工具层、上下文管理和安全边界的系统。

11. 如果继续深研，这三个方向还有哪些值得研究？

11.1 RAG 值得继续研究的方向

RAG 还远没有结束，真正难的是这些问题：

如何切块才不破坏语义？
如何做多跳检索？
如何结合关键词搜索和向量搜索？
如何加入知识图谱？
如何做权限过滤？
如何做引用溯源？
如何减少 hallucination？
如何评估检索质量？

尤其是多跳问题，比如：

“这个故障和上个月哪次测试现象类似？”

这不是简单 TopK 检索能解决的，需要检索、推理、再检索。

11.2 LLM Wiki 值得继续研究的方向

LLM Wiki 的研究重点是“知识编译”。

可以继续研究：

如何设计 schema？
如何自动发现新概念页？
如何判断旧页面需要更新？
如何处理矛盾信息？
如何保留引用来源？
如何防止 AI 过度总结导致信息丢失？
如何评价 Wiki 质量？

这里有一个很有意思的类比：

RAG 像数据库查询，LLM Wiki 像编译器。

它把 raw documents 编译成一个人和模型都能读的中间表示。

11.3 Hermes Agent 路线值得继续研究的方向

Agent 维护知识库最值得研究的是安全和自治边界：

Agent 能不能自动改旧结论？
哪些页面必须人工确认？
如何防止误删？
如何做 Git diff 审查？
如何做任务队列？
如何控制 Token 预算？
如何为不同任务分配不同 Agent？

你上传的参考报告里提到的 Manager-Worker、权限沙盒、上下文隔离、缓存边界，在这里都能直接借鉴。一个维护知识库的 Agent，也应该像一个小型 Agent OS：有主控、有子任务、有权限、有日志、有回滚，而不是让模型随便改文件。

12. 最后给一个最实用的选择建议

如果你是本科生或刚读研，我建议这样选：

第一阶段：先用 Obsidian + LLM Wiki

不要一上来就搭复杂 RAG。你可以先做：

Obsidian Vault
+ raw 文件夹
+ wiki 文件夹
+ index.md
+ AGENTS.md
+ ChatGPT / Claude / Codex 辅助维护

这个阶段你能真正理解“知识结构”是什么。

第二阶段：再学 RAG

当你的文档变多，或者你要做产品 demo，就开始学：

embedding
chunking
vector database
rerank
citation
metadata filtering

这时你会知道 RAG 为什么适合产品。

第三阶段：最后研究 Agent 自动维护

当你已经有稳定 Wiki，再考虑：

Hermes Agent
Telegram bot
Web frontend
Git 自动提交
定期 lint
自动 ingest

不要一开始就上 Hermes，否则很容易陷入部署细节，反而忘了知识库本身的设计。

13. 一句话总结

RAG、LLM Wiki、Obsidian、Hermes Agent 不是互相替代，而是处在不同层级：

RAG 解决：怎么从大量资料里快速找相关内容
LLM Wiki 解决：怎么把资料长期整理成知识结构
Obsidian 解决：怎么让人类舒服地阅读和编辑这套结构
Hermes Agent 解决：怎么让知识库长期自动维护和生长

真正高级的知识库产品，未来大概率不是单纯 RAG，也不是单纯笔记软件，而是：

RAG 做底层检索，LLM Wiki 做知识编译，Agent 做持续维护，Obsidian/Web 做人类界面。

也就是说，知识库的终局不是“上传文件问答”，而是：

让 AI 和人一起维护一座会生长、会自检、会引用、会进化的知识城市。

Logo
openEuler 社区

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐

2026年腾讯云部署OpenClaw/Hermes Agent三步秒级部署及使用保姆级教程

OpenClaw并非传统的聊天机器人，而是一款本地优先、云端适配的AI自动化代理——它以大语言模型为“大脑”，以Skills插件生态为“手脚”，能理解自然语言指令，自主完成网页操作、邮件管理、文档处理、多平台协同等具象化任务，无需编写复杂的自动化脚本。零代码门槛：通过自然语言下达指令，无需掌握Python/Java等编程技能；多端适配：支持阿里云服务器、本地设备、无影云电脑等多环境部署；生态扩展：

avatar openEuler 社区

2026年阿里云部署Hermes Agent/OpenClaw配置百炼Token Plan不需要技术教程

OpenClaw并非传统的聊天机器人，而是一款本地优先、云端适配的AI自动化代理——它以大语言模型为“大脑”，以Skills插件生态为“手脚”，能理解自然语言指令，自主完成网页操作、邮件管理、文档处理、多平台协同等具象化任务，无需编写复杂的自动化脚本。零代码门槛：通过自然语言下达指令，无需掌握Python/Java等编程技能；多端适配：支持阿里云服务器、本地设备、无影云电脑等多环境部署；生态扩展：

avatar openEuler 社区

【Linux】进程等待和进程退出码与退出信号

根据下面对status存储 的解释：上面的status等于：参数2.获取子进程statuswait和waitpid，都有一个status参数，该参数是一个输出型参数，由操作系统填充。如果传递NULL，表示不关心子进程的退出状态信息。否则，操作系统会根据该参数，将子进程的退出信息反馈给父进程。获取退出码：(status>>8)&0XFF获取退出信号：（status&0X7F）其中，也可以使用两个宏来

avatar openEuler 社区