【AI】-7 从知识库到 AI Agent -进阶

文章目录

• [让 AI 真正"进入"我的知识库：Obsidian + RAG + Local LLM + OpenCode 实践](#让 AI 真正"进入"我的知识库：Obsidian + RAG + Local LLM + OpenCode 实践)
• • [一、我真正想解决的，并不是"如何给 Obsidian 接入 AI"](#一、我真正想解决的，并不是"如何给 Obsidian 接入 AI")
  • [二、第一阶段：让 AI「找到我的知识」------ RAG](#二、第一阶段：让 AI「找到我的知识」—— RAG)
  • • [2.1 LLM 为什么不知道我的知识库？](#2.1 LLM 为什么不知道我的知识库？)
    • [2.2 Embedding 到底是什么？](#2.2 Embedding 到底是什么？)
    • [2.3 从 Markdown 到 RAG](#2.3 从 Markdown 到 RAG)
    • [2.4 RAG 的限制：AI 只能"看"](#2.4 RAG 的限制：AI 只能"看")
  • [三、第二阶段：让 AI「住在我的电脑里」------ Local LLM](#三、第二阶段：让 AI「住在我的电脑里」—— Local LLM)
  • • [3.1 为什么要折腾 Local LLM？](#3.1 为什么要折腾 Local LLM？)
    • [3.2 真实体验：本地模型并没有想象中那么强](#3.2 真实体验：本地模型并没有想象中那么强)
  • [四、第三阶段：让 AI「真正操作我的知识库」------ Agent](#四、第三阶段：让 AI「真正操作我的知识库」—— Agent)
  • • [4.1 对比：同一个需求，两种方案](#4.1 对比：同一个需求，两种方案)
    • [4.2 让 AI 操作本地知识库，需要什么？](#4.2 让 AI 操作本地知识库，需要什么？)
  • 五、OpenCode：从"聊天"走向"操作"
  • • [5.1 模型和 Agent，其实应该分开](#5.1 模型和 Agent，其实应该分开)
    • [5.2 OpenCode Go：把模型供应层抽出来](#5.2 OpenCode Go：把模型供应层抽出来)
    • [5.3 Claudian：把 Obsidian Vault 接到 Agent](#5.3 Claudian：把 Obsidian Vault 接到 Agent)
  • [六、真正跑起来之后，我可以让 AI 做什么？](#六、真正跑起来之后，我可以让 AI 做什么？)
  • • 检查知识缺口
    • 查找重复内容
    • 自动建立索引
  • [七、RAG、Local LLM、Agent 到底是什么关系？](#七、RAG、Local LLM、Agent 到底是什么关系？)
  • 八、最终架构
  • 九、这套系统还有很多问题没有解决
  • [十、从"AI 问答"到"AI 知识系统"](#十、从"AI 问答"到"AI 知识系统")
  • 写在最后

---

让 AI 真正"进入"我的知识库：Obsidian + RAG + Local LLM + OpenCode 实践

AI 不应该只是回答我的问题，它还应该能够理解我的知识、使用我的知识，甚至帮助我管理我的知识。

这是我搭建这套系统之后最大的感受。

过去，我们使用 ChatGPT、DeepSeek、Claude 等大模型时，本质上是在和一个"公共知识大脑"对话。它知道很多东西，却不知道我学过什么、我在哪些地方踩过坑、我之前是怎么理解 Docker 的、我的 Kubernetes 笔记到底写到了什么程度。

而我的 Obsidian 知识库恰恰保存着这些东西。

于是，一个问题开始出现------AI 到底应该怎样与一个属于个人的知识库结合？

我没有一开始就设计一个完整的 AI Agent 系统，而是一步一步进行了尝试：

先让 AI 找到我的知识 → 再让 AI 住进我的电脑 → 最后让 AI 真正操作我的知识库。

这篇文章记录的，就是这个过程。

一、我真正想解决的，并不是"如何给 Obsidian 接入 AI"

最开始，我对"AI + Obsidian"的理解其实非常简单：把 Markdown 笔记丢给大模型，然后让它帮我总结。

但很快我就发现，这种方式存在一个非常明显的问题------我的知识库越来越大。

几十篇、上百篇 Markdown 文件之后，如果每次都让我手动把相关笔记复制给 AI，这个所谓的"AI 知识库"其实并没有真正建立起来。

我真正需要的是：我只负责提问，AI 自己去我的知识库里找到相关内容。 再进一步------如果 AI 找到了内容，它能不能自己继续读取文件、分析结构，甚至修改我的笔记？

于是，我把整个过程拆成了三个阶段：

阶段	目标	核心技术
第一阶段	让 AI 找到我的知识	RAG
第二阶段	让 AI 住在我的电脑里	Local LLM
第三阶段	让 AI 操作我的知识	Agent

这三个阶段看起来都是"AI + 知识库"，但实际上解决的是完全不同的问题。

二、第一阶段：让 AI「找到我的知识」------ RAG

链接: 【AI】-2 本地大模型搭建 Ollama 安装与模型仓库原理

链接: 【AI】-6 Ollama 本地模型与 Embedding 实践

2.1 LLM 为什么不知道我的知识库？

大语言模型本身并不知道我的 Obsidian。假设我的 Vault 里面有这样的笔记：

Obsidian Vault
├── Docker
│   ├── Docker网络.md
│   ├── Docker存储.md
│   └── Docker Compose.md
├── Kubernetes
│   ├── Pod.md
│   ├── Service.md
│   └── Ingress.md
└── Linux
    ├── 网络.md
    ├── Shell.md
    └── 文件系统.md

我问："我之前有没有学习过 Docker 网络？"------普通 LLM 并不知道，因为这些内容根本不在它的上下文里。

所以我们需要一个中间过程：

1. 我提出问题
2. 去知识库寻找相关内容
3. 找到 Docker 网络相关笔记
4. 把相关内容提供给 LLM
5. LLM 根据这些内容回答

这就是 RAG。

2.2 Embedding 到底是什么？

RAG 的核心并不是"把所有 Markdown 文件都塞给模型"。真正关键的一步是：把文本转换成能够进行相似度计算的向量------这就是 Embedding。

例如我的笔记里可能存在这样的内容：

Docker 默认网络包括 bridge、host、none 等模式。容器之间可以通过自定义 bridge 网络进行通信。

Embedding 模型会把这段文字转换成一个向量，可以简单理解成：

文本 → Embedding Model → [0.12, -0.37, 0.81, ...]

这串数字本身对人没有什么意义，但对于计算机来说，它可以描述这段文字"在语义空间里"大概位于什么位置。

于是，"Docker 容器之间如何通信？"和"自定义 bridge 网络可以实现容器之间的通信"------虽然文字完全不同，但它们的向量可能非常接近。这就是向量检索能够工作的原因。

2.3 从 Markdown 到 RAG

一个最基础的 RAG 流程如下：

1. 离线阶段：Obsidian Markdown → 文本切分 → Embedding → 向量索引
2. 在线阶段：用户提问 → Vector Search → 找到相关内容 → LLM + 检索内容 → 回答

我在自己的 Obsidian 中使用 Local LLM Helper 进行了相关实验。这里有一个很重要的认识：

RAG 并没有让模型"学会"我的知识库。 它只是让模型在回答问题的时候，能够临时检索并使用我的知识。这两个概念差别很大。

对比一下：

	传统 LLM	RAG
流程	我问问题 → 模型凭自己的知识回答	我问问题 → 先去知识库找资料 → 模型根据资料回答
知识来源	模型训练数据	模型训练数据 + 外部检索

所以第一阶段解决的是："AI 能不能找到我的知识？" 答案是：可以。

但问题也随之出现了。

2.4 RAG 的限制：AI 只能"看"

假设我问："检查一下我的 Docker 笔记，看看有没有知识缺口。"

RAG 可以帮助 AI 找到 Docker 相关内容，但它本质上仍然是在 搜索 → 读取 → 回答，并没有真正拥有操作我的知识库的能力。

如果我进一步说："帮我把这些 Docker 笔记重新建立索引。"------这时候，仅仅依靠 RAG 就不够了。因为这个任务已经从 "找到知识" 变成了 "对知识采取行动"。

这也是我后来开始关注 Agent 的原因。但在此之前，我又做了另一个实验。

三、第二阶段：让 AI「住在我的电脑里」------ Local LLM

既然 AI 已经开始进入我的个人知识库，那么另一个问题自然出现了：这些知识一定要发送给云端模型吗？

对于个人知识库而言，这个问题其实很现实。我的 Obsidian 里面不仅有技术笔记，还有大量属于我自己的学习记录、思考过程和工作经验。

于是我开始尝试 Local LLM。我的方案非常简单：

Windows → NVIDIA GPU → Ollama → Qwen3-8B-Q4_K_M → 本地运行 LLM

3.1 为什么要折腾 Local LLM？

我最初考虑本地模型，主要有三个原因：

1. 隐私：知识库不需要全部发送给第三方 API
2. 成本：大量总结、分类、检索、改写等操作，本地模型理论上可以降低 API 成本
3. 离线能力：模型运行在自己的电脑上，不依赖远程 API

3.2 真实体验：本地模型并没有想象中那么强

听起来非常美好，但真正跑起来之后，我发现本地模型和云端大模型之间，仍然存在非常明显的差距。

我实际运行 Qwen3-8B-Q4_K_M 后，最大的感受不是"以后终于不用 API 了"，而是：原来个人电脑上的本地模型，和现在优秀的云端模型之间，差距依然很大。

尤其是在以下场景中，8B 级别的本地模型很难全面替代优秀的云端模型：

• 复杂推理
• 长上下文理解
• 多步骤任务
• 复杂代码分析
• Agent 类任务

同时，量化又会进一步影响模型能力。本地模型还要受到显存、模型参数量、量化方式、上下文长度、推理速度等因素限制。

所以我最后得出的结论是：Local LLM 是一种能力补充，而不是云端模型的全面替代。 对于隐私敏感、简单总结、分类、改写或者离线任务，本地模型非常有价值；但面对复杂推理任务，我仍然更愿意使用能力更强的云端模型。

这反而让我意识到："模型在哪里运行"和"AI 能做什么"其实是两个完全不同的问题。 于是第三阶段出现了。

四、第三阶段：让 AI「真正操作我的知识库」------ Agent

这是我认为整套系统里最重要的部分。因为 RAG 和 Agent 根本不是竞争关系，它们解决的问题不同：

	RAG	Agent
核心能力	AI 能找到我的知识	AI 能使用工具操作我的知识
解决的问题	Find Knowledge	Take Action

4.1 对比：同一个需求，两种方案

场景 A（RAG 就能搞定）：

"我之前学习过 Docker 网络吗？"

系统流程：用户问题 → 检索 Docker 网络相关笔记 → 读取相关内容 → LLM 回答

场景 B（需要 Agent）：

"检查我的 Docker 笔记，看看网络这一部分有没有知识缺口。"

Agent 可以：

1. 理解任务
2. 搜索文件
3. 读取 Docker 相关笔记
4. 分析知识结构
5. 发现缺失内容
6. 整理结果
7. 向我提出建议

甚至可以进一步："帮我给这些笔记建立索引。"------那么流程可能变成：搜索文件 → 读取 Markdown → 分析文件结构 → 创建索引 → 修改 Markdown → 建立 Obsidian 链接。

这时候 AI 已经不再只是一个"问答机器人"，它开始成为知识库里的一个操作主体。

4.2 让 AI 操作本地知识库，需要什么？

如果我要让一个 AI 真正操作我的 Obsidian Vault，至少需要四样东西：

组件	职责
模型	思考什么
Agent	决定下一步做什么
工具	具体怎么做
文件系统权限	允许它在哪里做

于是我开始寻找一个能够把这些东西连接起来的 Agent 层。最终，我把 OpenCode 放到了这个位置。

五、OpenCode：从"聊天"走向"操作"

链接: 【AI】-4 OpenCode Go 接入 Obsidian 完整指南

链接: 【AI】-5 OpenCode Go API Key 轮换与多端同步配置

OpenCode 对我而言，最重要的意义并不是"又多了一个 AI 客户端"，而是它提供了一个 Agent 层。

也就是说，我不再只是 用户 → LLM → 回答，而是：

用户 → Agent → 工具 → 文件系统 / Shell / Git / 其他能力
                ↕
              模型

于是，AI 开始拥有了"做事情"的能力。而这恰好与我的 Obsidian 知识库产生了结合点。

5.1 模型和 Agent，其实应该分开

这是我整个实践过程中一个比较重要的认识。以前我很容易把"AI 模型"和"AI 应用"混在一起，但实际上，它们完全可以分层：

┌─────────────────────────────┐
│        Agent 层              │
│    OpenCode / 工具调用        │
└──────────────┬──────────────┘
               ↓
┌─────────────────────────────┐
│        模型供应层             │
│  DeepSeek / Qwen / 其他模型  │
└─────────────────────────────┘

Agent 并不一定需要绑定某一个模型。这意味着：模型可以更换，而 Agent 工作流可以保持不变。

5.2 OpenCode Go：把模型供应层抽出来

如果直接给 Agent 配一个 DeepSeek API，那么整个系统很容易变成 Agent → DeepSeek API。但如果我希望以后尝试不同模型，就需要不断修改上层配置。

而 OpenCode Go 提供了一个统一的模型入口，于是我的架构变成：

Agent → OpenCode Go → ┬─ DeepSeek
                      ├─ Qwen
                      ├─ ...
                      └─ 其他模型

Agent 层负责"怎么工作"，模型供应层负责"用谁来工作"。 这其实是一种很典型的分层思想------应用层 → 中间层 → 基础设施，而不是让所有东西耦合在一起。

5.3 Claudian：把 Obsidian Vault 接到 Agent

如果说 OpenCode 解决的是"Agent 怎么工作？"，那么 Claudian 在我的这套系统里解决的是："Obsidian 怎么进入这个 Agent 工作流？"

于是最终形成：

Obsidian → Claudian → OpenCode → OpenCode Go → 具体模型

这时候，Obsidian 不再只是一个被动存储 Markdown 的笔记软件，它开始成为 Agent 可以读取、分析和操作的知识空间。

六、真正跑起来之后，我可以让 AI 做什么？

到了这里，如果继续讲概念，其实已经没有太大意义。真正有价值的是------让它干活。

检查知识缺口

"扫描我的 Kubernetes 笔记，分析目前的知识结构，并告诉我哪些核心知识点还没有覆盖。"

Agent 会：搜索 Kubernetes 目录 → 读取多个 Markdown → 分析标题与正文 → 建立知识结构 → 与核心知识体系对照 → 输出缺失内容。

查找重复内容

"扫描我的 Docker 笔记，找出重复或者高度相似的内容。"

Agent 会：搜索 Docker 文件 → 读取多个 Markdown → 比较内容 → 发现重复 → 整理结果。

自动建立索引

"帮我给 Docker 知识库建立一个索引页面。"

Agent 会：读取目录 → 分析文件 → 创建 Index.md → 生成 Obsidian WikiLink → 写入文件。

这时候，我真正感受到了一件事情：AI 不再只是我的"搜索框"，它开始成为我的知识库里的一个"工作人员"。

七、RAG、Local LLM、Agent 到底是什么关系？

走到这里，就可以把几个概念放在一起看了。

方案	AI 能看到知识	AI 能修改知识	本地运行	主要解决的问题
普通 LLM	❌	❌	❌	通用问答
RAG	✅	❌	可	找到相关知识
Local LLM	取决于配置	取决于工具	✅	模型在哪里运行
Agent	✅*	✅	可	执行任务
Agent + RAG	✅	✅	可	找知识 + 执行任务

* Agent 能否访问知识取决于它拥有的工具和数据源。

这里最容易产生的误解是：RAG 和 Agent 是不是两种互相替代的方案？ 其实不是，它们更像是两个维度：

• RAG：负责"找什么"
• Agent：负责"做什么"
• Local LLM：负责"模型在哪里运行"
• Model：负责"谁来思考"

所以真正完整的系统应该是这样的------Agent 作为决策与行动的核心，向下分叉为两条路径：一条是 Retrieval（找知识，连接到 Obsidian Vault），另一条是 Tools（做事情，连接到文件系统），而两者最终都依赖于底层的 Model。

八、最终架构

把整个实验串起来，我现在的系统可以抽象成：

                    ┌─────────────────────┐
                    │   Obsidian Vault    │
                    │     Markdown        │
                    └──────────┬──────────┘
                               │
              ┌────────────────┴────────────────┐
              │                                 │
              ↓                                 ↓
       Retrieval / RAG                       Agent
              │                                 │
        找到相关知识                     搜索 / 读取 / 修改
              │                                 │
              └────────────────┬────────────────┘
                               ↓
                          Claudian
                               ↓
                           OpenCode
                               ↓
                        OpenCode Go
                               ↓
              ┌────────────────┼────────────────┐
              ↓                ↓                ↓
          DeepSeek           Qwen             ...

如果再把 Local LLM 放进去，模型这一层还可以变成：

                    Agent
                      ↓
                  OpenCode
                      ↓
               Model Provider
               ↙           ↘
         Cloud LLM       Local LLM
            ↓               ↓
      OpenCode Go        Ollama
                          ↓
                        Qwen

这时候整个系统就不再是"我给 Obsidian 装了一个 AI 插件"，而更像是------我正在给自己的知识库搭建一层 AI 基础设施。

九、这套系统还有很多问题没有解决

不过我并不认为这套系统已经完成。恰恰相反，它现在更像是一个阶段性的实验。例如：

• RAG 的检索质量还可以继续优化
• Embedding 模型还有选择空间
• Markdown 如何切分会影响检索效果
• Agent 修改文件时如何保证安全性
• 如何避免 Agent 错误修改大量笔记
• 如何设计更可靠的权限控制
• 本地模型到底适合承担哪些任务
• 云端模型与本地模型应该如何分工
• 如何让 AI 真正理解我的知识体系，而不仅仅是搜索关键词
• 如何建立长期稳定的知识图谱和索引机制

这些问题都没有一个最终答案。而这可能也是个人 AI 知识库最有意思的地方。

十、从"AI 问答"到"AI 知识系统"

回头看整个过程，我对 AI + 知识库的理解发生了一点变化：

阶段	模式	说明
最初	我 → AI	我向 AI 提问
后来	我 → AI → 我的知识库	AI 开始能够找到我的知识
再后来	我 → AI → 我的知识库 → AI 修改/整理/分析	AI 开始真正参与知识管理

所以我现在更愿意把这几个阶段理解成：

• LLM → 回答问题
• RAG → 使用我的知识回答问题
• Agent → 使用我的知识完成任务
• Agent + RAG + Knowledge Base → 成为我的个人知识基础设施

这可能才是我真正想探索的方向：不是让 AI 替我记笔记，而是让 AI 成为我知识系统的一部分。

写在最后

这套系统当然还远远谈不上成熟，它甚至可能还有很多地方并不优雅。但对我而言，它最大的价值并不是最终搭出了一个多么复杂的架构，而是让我逐渐看清楚了几个原本容易混在一起的概念：

• RAG 负责让 AI 找到知识
• Agent 负责让 AI 使用工具完成任务
• Local LLM 决定模型在哪里运行
• 模型 决定 AI 本身拥有多强的能力

而真正有意思的地方，是把这些东西组合起来。

我的 Obsidian 只是一个开始。未来，如果模型能力继续提升，Agent 的工具调用能力继续增强，那么个人知识库可能不再只是一个"存放 Markdown 文件的地方"。它可能会逐渐变成------一个 AI 能够理解、检索、整理、维护，甚至持续参与其中的个人知识系统。

而这套方案，也只是我目前探索到这里的一个阶段性结果。

AI 进入知识库，并不是终点。

真正值得探索的问题是：当 AI 开始拥有自己的"记忆"、工具和行动能力之后，我们究竟应该怎样重新设计人与知识之间的关系？