如何搭建本地知识库：llm wiki+gbrain

问题

先说一个日常场景：你的信息散落在各处。PDF文件在下载文件夹里堆积如山，网页文章在浏览器收藏夹里落灰，微信聊天记录里的关键信息过几天就石沉大海，邮件里的决策结论深埋在收件箱底部。

这些零散的信息有个共同的麻烦：

• 搜索的碎片化
  。想找一个概念，得在文件夹、浏览器、微信、邮箱里分别搜一遍，耗时耗力。

• 格式的孤岛化
  。PDF、Word、Excel、网页、聊天记录，每种格式有自己的打开方式，无法放在一起统一检索。

• AI的盲区
  。这是最关键的一点——这些知识对大模型来说是不可见的。模型再强，也搜不到你本地的PDF和微信记录。

所以，需要一套系统，把所有知识统一存储、结构化管理，既能让你自己快速检索，也能让AI Agent直接调用。这套系统不能依赖云端，数据必须完全本地化。

方案

最终搭出来的系统，由四个组件协同工作，各司其职。

：知识的骨架。它定义了知识如何分类、如何组织。本质上就是磁盘上的一套目录结构和Markdown文件。按照概念、资料来源、人物实体、方法论等类别进行存放。每个文件用YAML frontmatter标记类型、标签、创建时间等元数据。文件之间用[[slug]]语法互相引用，形成一张知识网络。这套目录可以直接用Obsidian打开，也可以用任何文本编辑器操作。

：知识的搜索引擎。底层是PostgreSQL数据库加上pgvector向量扩展。所有知识存入后，它能做到：全文搜索（关键词精确匹配）、语义搜索（理解问题意图，找到相关内容，即使关键词不完全一致）、知识图谱（自动提取人物、公司、概念等实体，并建立它们之间的关联）、时间线（按时间轴组织事件）。它提供MCP接口，AI Agent可以直接调用这些能力。

：人类的编辑窗口。它直接读写LLM Wiki目录下的Markdown文件，本身不存储任何数据。其图谱视图能直观展示知识之间的关联网络——哪个概念连着哪个人物，哪份资料引用了哪个理论。它就像一个可视化的地图。

：微软出品的格式转换利器。PDF、Word、Excel、PPT、网页HTML、甚至图片OCR和音频语音转文字，统统转为干净的Markdown。这是知识入库最关键的一步：不管原始文件是什么格式，最终都变成统一的Markdown文本。

数据怎么进来

知识进入系统有三种入口，最终都汇到同一条处理管线。

• 浏览器上传
  ：内网有一个上传页面，监听8199端口，局域网内的任何设备打开浏览器就能用。拖拽文件进去，文件自动进入投递箱目录。

• 命令行
  ：直接把文件复制到投递箱目录：cp report.pdf ~/llmwiki/inbox/。

• 告诉AI
  ：对Agent说“帮我导入这个PDF”或“保存这篇文章：{URL}”，Agent会自动处理。

无论哪种方式，文件最终都会落到同一个地方：~/llmwiki/inbox/。然后，一个叫watchdog的后台脚本接管后续处理：

1. 检测到新文件
2. 判断文件类型——文本文件直接处理，二进制文件先用MarkItDown转为Markdown
3. 存档原始文件到raw/sources/目录（按日期归档）
4. 保存转换后的.md文件到wiki/sources/目录
5. 导入GBrain数据库（存储 + 生成向量索引 + 提取实体关联）
6. 原始文件移到inbox/.processed/归档

整个过程全自动。你只需要把文件丢进去，剩下的交给系统。

查询的时候，三种方式都可以：命令行gbrain search "关键词"或gbrain query "如何构建投资组合"（语义搜索）；Obsidian搜索框；或者直接问Agent。Agent通过MCP协议连接GBrain，搜索知识后基于结果生成回答。

实际使用场景

搭好之后的日常是这样的：

早上看到一篇好文章，浏览器里用MarkDownload扩展一键复制Markdown，粘贴给Agent，说“保存到知识库”。Agent自动提取关键信息、识别文中提到的人物和公司、创建知识页面、建立关联。整个过程几秒钟。

下午收到一份研究报告PDF，拖到上传页面。几秒钟后就能搜到。问Agent“这份报告的核心观点是什么”，它能基于报告内容回答。问“报告里提到了哪些公司”，它能列出，并自动关联到知识库里已有的公司页面。

开完会，把微信聊天记录复制给Agent，说“保存这段讨论”。它会提取参与者、识别关键决策、创建时间线事件。下次问“上次关于XX的讨论结论是什么”，直接就能找到。

做研究的时候，问Agent“我之前保存过哪些关于因子投资的资料”，它会搜索知识库，列出相关文章、报告、会议记录，还能基于这些内容做综合分析。

所有知识都存在本地Mac Studio上，不上传到任何云端。搜索的时候，既能精确匹配关键词，也能理解语义——比如搜“如何控制回撤”，即使文章里没有“回撤”这两个字，只要内容是关于风险控制的，也能找到。

技术实现

整套系统运行在一台Mac Studio上，不依赖任何外部服务。

：GBrain使用的三个模型全部本地部署。搜索意图理解和回答生成用Qwen3.5-27B，向量embedding用Qwen3-Embedding-8B，通过omlx推理服务器提供OpenAI兼容的API。完全离线运行，不需要调用任何外部API。

：PostgreSQL + pgvector。向量维度1024，支持高效的语义相似度搜索。

：GBrain以HTTP服务方式运行，监听3131端口，绑定0.0.0.0（内网可访问）。支持Bearer Token认证，可以为不同的Agent创建不同的Token。文件上传服务监听8199端口。两个服务都配置了macOS launchd开机自启，Mac Studio开机后自动运行。

：watchdog脚本基于fswatch监控文件系统事件，只处理最近1分钟内新增的文件。MarkItDown安装在独立的Python虚拟环境中，不影响系统Python。

：通过MCP（Model Context Protocol）协议暴露81个工具，包括搜索、读写、关联、标签、时间线等。Agent调用时需要在请求头带Bearer Token，响应格式是SSE（Server-Sent Events）。

局限

这套系统有几个明显的短板：

• 纯文本定位
  。图片、音频、视频没法直接入库，需要先转成文字。MarkItDown支持图片OCR和音频转文字，但效果取决于原始文件质量。

• 需要人工维护结构
  。虽然有自动分类和实体提取，但知识的组织还是需要人为干预。概念之间的关联、实体的归类、重要程度的判断，Agent能辅助，但不能完全替代人的决策。

• 本地孤岛
  。数据存在本地Mac Studio上。如果需要多设备访问，只能通过内网。没有自动备份机制，需要自己定期备份PostgreSQL数据库。

• 学习成本
  。日常使用很简单——拖文件、问Agent。但如果要深入了解系统配置、故障排查、自定义工作流，需要一定的技术基础。至少得熟悉命令行和Markdown。

• 模型能力上限
  。本地部署的27B模型在复杂推理上不如GPT-4或Claude，实体提取和语义搜索的准确率也有提升空间。但好处是完全离线、没有API费用、数据不离开本地。

适合谁

这套系统适合这样的场景：个人知识管理，信息量大、来源分散；需要AI辅助整理和检索知识；注重数据隐私，不想把知识上传到第三方平台；有一定的技术能力，能处理基本的命令行操作。

不太适合的场景：团队多人协作（这是个人知识库设计，没有多用户权限管理）、需要严格版本管理的文档（用Git更合适）、纯图片/视频类素材管理。

总结

这套系统的核心思路是：

技术栈并不复杂：PostgreSQL + pgvector做存储和搜索，Qwen做语言模型，Obsidian做编辑器，MarkItDown做格式转换，一个watchdog脚本做自动化处理。所有组件都是开源的，跑在本地，数据不离开Mac。

搭好之后最大的感受：

。不管是几周前保存的文章，还是昨天的会议记录，问Agent一句话就能找到。而且Agent能基于知识库回答问题、生成分析、做头脑风暴——这才是知识管理的最终目的，不只是存起来，而是能用起来。