【AI】-7 从知识库到 AI Agent -进阶
文章目录
- 让 AI 真正"进入"我的知识库：Obsidian + RAG + Local LLM + OpenCode 实践
让 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 并不知道，因为这些内容根本不在它的上下文里。
所以我们需要一个中间过程：
- 我提出问题
- 去知识库寻找相关内容
- 找到 Docker 网络相关笔记
- 把相关内容提供给 LLM
- 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 流程如下：
- 离线阶段：Obsidian Markdown → 文本切分 → Embedding → 向量索引
- 在线阶段：用户提问 → 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？
我最初考虑本地模型，主要有三个原因：
- 隐私：知识库不需要全部发送给第三方 API
- 成本：大量总结、分类、检索、改写等操作，本地模型理论上可以降低 API 成本
- 离线能力：模型运行在自己的电脑上，不依赖远程 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 可以：
- 理解任务
- 搜索文件
- 读取 Docker 相关笔记
- 分析知识结构
- 发现缺失内容
- 整理结果
- 向我提出建议
甚至可以进一步：“帮我给这些笔记建立索引。”——那么流程可能变成：搜索文件 → 读取 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 开始拥有自己的"记忆"、工具和行动能力之后，我们究竟应该怎样重新设计人与知识之间的关系？
Agent 垂直技术社区，欢迎活跃、内容共建。
更多推荐
33
0- 0
已为社区贡献1条内容
所有评论(0)