1. 它到底是什么微信团队开源知识库项目的定位与边界我第一次看到 WeKnora 这个名字是在某次技术社区的讨论帖里。当时帖子标题写着腾讯微信团队出品底下评论区吵得挺热闹——有人问它和 Dify 有什么区别有人关心是不是又一个开源即弃的项目还有人在讨论它和 Obsidian 这类本地知识库工具能不能打通。我自己的第一反应是腾讯内部做知识管理工具不稀奇稀奇的是愿意把整套东西开源出来。带着这个疑问我把它的文档、代码仓库和部署流程过了一遍也实际在本地环境里跑通了整条流水线今天这篇就把从了解到落地到排错的完整过程写出来。先给还不熟悉的朋友一个定位。WeKnora 的全称是 We Know RAG Architecture核心解决的是把企业内部文档变成可问答的知识库这件事。它不是单纯的文档管理软件也不是像 Obsidian 那样以 Markdown 文件为核心的个人笔记工具而是一套面向企业和开发者的 RAGRetrieval-Augmented Generation检索增强生成解决方案。说得更直白一点你给它一堆 PDF、Word、Markdown、网页链接它负责把这些内容解析、切分、向量化建立索引然后当你提问时它先从索引里检索出相关片段再把片段连同问题一起交给大语言模型生成回答。这个定位决定了它的使用场景。在我实际测试过程中最典型的用法是三类第一类企业内部知识库比如产品文档、运维手册、新人培训资料做成一个全员可用的问答机器人第二类个人知识库的进阶版很多人用 Obsidian 管理笔记但 Obsidian 本身没有 RAG 问答能力WeKnora 可以作为后端引擎把笔记导出后喂进去第三类特定领域知识库比如农业知识库、专利辅助查询热搜词里出现的农业知识库构建专利相关辅助链接就是这类需求。它和 Dify、RagFlow、MaxKB 属于同一赛道但侧重点有明显差异这个放到后面专门讲。还有个容易混淆的点WeKnora 不是AI 对话网站也不是无限制聊天工具。它是给开发者用的基础设施不是开箱即用的聊天机器人前台。如果你想要的是一键部署、输入文档就能对话的傻瓜式产品它目前的上手门槛比 Dify 要高一些但反过来如果你需要深度定制文档解析逻辑、需要对接自己已有的模型服务、需要把知识库能力嵌入到现有业务系统里WeKnora 的灵活度和可控性反而是优势。理解了这个边界后面所有操作你才知道每一步在做什么、为什么这么做。2. 架构核心拆解RAG 流水线、Agent 编排与深度文档解析2.1 知识库工作的完整链路要真正用好 WeKnora不能只会点鼠标部署得先理解它内部的数据流向。我画了一张脑图来帮自己记忆整个流程可以拆成五个阶段文档接入支持 PDF、DOCX、Markdown、TXT、HTML 等常见格式也支持直接传入 URL 抓取网页内容。这一步听起来简单实际坑最多后面单独说。文档解析把非结构化文档转换成结构化文本。这是 WeKnora 和很多同类项目拉开差距的地方它内置了专门的深度文档解析模块 DeepDoc能把表格、图片、排版信息提取出来而不是简单地把 PDF 转成纯文本。文本切分解析出来的长文本需要切成小块太长了检索不精准太短了上下文不完整。切分策略直接影响问答质量。向量化与索引每个文本块通过 embedding 模型转成向量建索引。这个环节依赖外部模型服务WeKnora 本身不内置向量模型。检索与生成用户提问后系统把问题向量化在索引里做相似度检索召回 TopK 个文本块拼接成 prompt 交给 LLM 生成回答。这五个阶段里前三个阶段是 WeKnora 的强项尤其文档解析那一环我实测下来对复杂 PDF 版式的还原度明显好于直接用 LangChain 内置的解析器。后面三个阶段依赖外部模型所以部署 WeKnora 之前你得先有一个可用的模型服务和 embedding 服务。2.2 Agent 能力知识库不仅是被动检索WeKnora 对 Agent 的支持是我觉得值得单独拎出来讲的部分。它不只是检索回答这么简单而是提供了一个会话级 Agent 框架可以处理多轮对话中的信息提取、意图判断和工具调用。举个例子我测试时让它从这份产品手册里找出所有提到 API 限流策略的地方并总结不同套餐的限额差异。这个问题本身包含多个子任务定位相关章节、提取限流数值、对比不同套餐。纯 RAG 的简单实现会把问题直接拿去检索返回一堆片段让你自己拼凑WeKnora 的 Agent 机制会把问题拆解成定位章节、提取参数、对比汇总三个步骤每一步分别检索、分别处理最后再统一生成结论。这个能力在专利相关辅助查询农业知识库构建这类需要深度阅读的场景里特别有价值。因为这类场景的问题往往不是某某是什么这种简单事实型问答而是帮我整理一下 X 和 Y 在三个维度上的差异这种复合型问题。如果没有 Agent 机制检索质量再高也回答不好这种问题。2.3 技术栈一览从部署角度看WeKnora 的技术栈很集中依赖的东西不算多组件作用说明Docker / Docker Compose容器化管理官方推荐部署方式Elasticsearch文档存储与检索默认方案语言模型服务生成回答支持 OpenAI 协议的服务都可通过接口配置Embedding 模型服务生成向量用于文本块向量化与检索语音识别服务可选语音输入转文字内置了 FunASR 方案的对接这里有个容易误解的地方Elasticsearch 不只是存文档原文它还承担了向量检索。WeKnora 在 ES 里同时保存了原文和向量字段检索时通过 ES 的 knn 查询实现相似度匹配。所以你不需要额外部署一套向量数据库这跟很多教程里LangChain Chroma 搭本地知识库的思路不一样部署链路更短。我个人补充一个基于常见实践的选型建议如果你只是个人使用、文档量在几千份以内Elasticsearch 单独占用的内存和 CPU 可能会显得大炮打蚊子但它是 WeKnora 的默认依赖没必要为了省资源去替换。反正我实际跑下来1 核 2G 的机器虽然吃力但小规模测试完全能扛住生产环境建议 4 核 8G 起步。3. Windows 11 下的部署实录与资源规划3.1 前置条件先把 Docker 环境理利索热搜词里有weknora windows11 下安装说明很多人卡在 Windows 上。我自己的主力机器就是 Windows 11整个部署过程踩了不少跟系统相关的坑这部分详细写一下。第一步是装 Docker Desktop。WeKnora 官方文档假设你在 Linux 服务器上部署但 Windows 桌面环境用 Docker Desktop 跑是完全可行的前提是满足两个硬性条件系统里启用了 WSL 2 后端。Docker Desktop 在 Windows 上有 Hyper-V 和 WSL 2 两种后端我用的是 WSL 2兼容性和性能都更好。BIOS 里开了虚拟化。这个很多人会忽略查一下任务管理器性能标签页里虚拟化状态如果是已禁用得先重启进 BIOS 打开。装完 Docker Desktop 之后注意检查 Docker 默认的资源配置。默认是 2 核 CPU 和 2G 内存新版可能不同WeKnora 全家桶——Elasticsearch、后端服务、前端服务——跑起来之后内存很容易吃掉 3G 以上。我当时没改配置直接启动结果 Elastcisearch 启动到一半进程被杀日志里写native memory allocation failed排查了一个多小时才意识到是这个原因。在 Docker Desktop 的 Settings - Resources 里把内存调到 6G 以上CPU 调到 4 核以上基本就稳了。另外如果你的机器是 16G 内存建议给 Docker 分配 8G 以内给宿主留出余量。3.2 拉取项目与配置模型服务的 KeyDocker Desktop 就绪后在 Windows Terminal 里执行git clone https://github.com/tencent/weknora.git cd weknora项目里有docker目录先别急着docker compose up有一项关键配置必须先改模型服务的 API Key 和 Base URL。WeKnora 的设计原则是自带框架、不带模型语言模型和 embedding 模型都要你自备服务。你可以在项目根目录找到.env.local或config目录下的配置文件版本不同路径略有差异把两个核心参数填进去OPENAI API Key 和 Base URL可以填 OpenAI 官方接口也可以填国内兼容 OpenAI 协议的服务商地址还可以填本地部署的 Ollama 或其他网关地址。关键是 Base URL 要完整例如http://localhost:11434/v1。Embedding 模型接口默认配置里往往指向 OpenAI 的 embedding 接口如果你用本地 Ollama要改为对应的模型名和接口路径。我第一次部署时没仔细看文档直接docker compose up -d结果前端页面能打开但创建知识库时一直报embedding service error。后来看到日志里模型接口返回 401 才反应过来Key 还没配。这个顺序反正记住就行任何自托管项目先把外部依赖的凭证配好再启动服务。3.3 启动与验证状态配置完成后再启动docker compose up -d第一次启动需要拉取多个镜像尤其是 Elasticsearch 那个镜像体积不小取决于网络情况可能要等一会儿。启动完成后用docker compose ps看容器状态正常情况下核心服务都是Up状态。WeKnora 的默认前端端口通常是 8080 或 9470具体看版本和配置。浏览器打开后先不要急着建知识库先去系统设置里确认模型服务已经被识别。如果前端页面显示模型配置异常或未检测到可用模型说明配置没生效检查 .env 文件的后缀名——Windows 系统默认会隐藏扩展名有时候你改的是.env.local.txt而不是.env.localDocker 加载不到这个小问题坑了不少人。3.4 部署完成后的初始自检清单我每次部署完一套知识库系统都会先跑一遍自检流程确认每个环节都正常再往上接业务数据上传一个不超过 10 页、纯文字为主的小 PDF创建知识库观察文档解析和切分是否正常提问一个能从文档里直接找到答案的问题确认召回和生成链路通再问一个需要跨章节、跨页面才能回答的复合问题验证 Agent 拆分能力查看日志里有没有 embedding 调用延迟过高或 ES 查询报错的记录提前发现隐患。这套流程走下来大约 10 分钟能帮你把 80% 的部署成功但问答跑不通问题提前暴露掉。很多人在这一步跳过直接把几百页的大文档传进去结果解析跑了一个小时报错了也不知道是模型问题还是文档问题排查成本反而更高。4. 从跑通到好用官方镜像二次开发与模型接入4.1 为什么需要二次开发WeKnora 跑通之后你会很快遇到一个尴尬官方前端界面偏管理员视角功能面板很全但普通用户用起来有点重。如果你是企业内部给同事用或者打算把它嵌入到自己已有的系统里通常有两条路线可选方案 A直接用官方前端把访问地址分享给团队。优点是零开发量缺点是交互不够定制化、权限体系可能跟企业现有账号体系不对齐。方案 B把 WeKnora 当作后端引擎通过它提供的 API 在自己业务系统里调知识库问答能力。优点是灵活缺点是需要写代码。我个人比较推荐方案 B尤其是你已经有一定开发能力、或者团队里有后端工程师的情况下。因为 WeKnora 的核心价值在于解析和 RAG 流水线前端只是壳子。把壳子换成自己业务系统的界面知识库能力就成了业务的一部分而不是一个孤立的问答网站。4.2 官方镜像的结构与替换思路WeKnora 的 Docker 部署里前端是打包好的静态资源在容器里通过 Nginx 托管。做二次开发时不必修改官方镜像内部更推荐的做法是在项目里增加一个自定义前端服务目录自己写页面把官方后端服务的 API 基地址配置到自定义前端里用 Nginx 做反向代理把/api路径转发到 WeKnora 后端容器把其他路径指向你的自定义前端。这样官方镜像始终保持原样升级时拉新镜像替换即可你的定制代码不依赖容器内部结构。你可能会问那官方前端不就得放弃了吗也不一定。如果你只是想做轻度定制比如改个 logo、换配色、调整首页文案那直接改官方容器里的静态资源再重新打包成自己的镜像成本更低。但如果要做流程定制比如知识库申请、审核、权限隔离那必须走 API 对接路线改静态资源是做不到的。4.3 模型接入的三种常见组合WeKnora 的模型接入层是标准的 OpenAI 协议所以理论上任何提供 OpenAI 兼容接口的服务都能接。我实测和调研下来最常见的组合有三种组合方案使用场景优缺点云端大模型 APIOpenAI、国内大厂服务等企业快速上线团队小、预算充足效果最好但数据在云端需要评估隐私合规本地模型Ollama 部署的 Qwen、Llama 等数据敏感、要求私有化部署数据不出内网但模型能力受硬件限制小模型回答复杂问题会明显吃力云端本地混合生产环境常见做法需要自己开发路由逻辑但兼顾效果和隐私热搜词里有llama 适合国内企业拿来搞知识库问答和私有化 agent 部署吗这个问题在我试完 WeKnora Ollama 跑 Qwen 系列模型之后有了比较明确的感受如果你的文档内容偏结构化、问题偏事实型7B~14B 的模型完全够用但如果文档里大量是隐含知识、需要推理总结的小模型会经常出现答非所问或引用错误的情况。所以我的建议是先用云端大模型跑通验证效果再根据效果决定要不要换成本地模型。一上来就追求纯私有化容易在模型效果上栽跟头然后误以为是知识库软件的问题。4.4 Embedding 模型的选择不容忽视大多数人在配置模型时只关注生成模型忘了 embedding 模型同样影响问答质量。这个在热搜词怎么提高匹配度里能看出来其实大部分召回不准的问题根源都在 embedding 选错或没配对。我的经验是embedding 模型要和文档语言、领域匹配。中文文档为主的知识库优先选中文语料训练过的 embedding 模型效果远好于通用英文向量模型。我测试过用英文 embedding 处理中文技术文档召回准确率下降非常明显很多明显相关的内容都排不到前面去。如果你用的是 Ollama 本地部署目前常见的方案是nomic-embed-text或bge-m3这类中文友好的模型如果用云端 API也要选支持中文的服务。这里有一个容易被忽略的技术细节WeKnora 在切分文本和检索时会调用同一个 embedding 服务。如果你中途换了 embedding 模型必须重建所有文档的向量索引因为不同模型生成的向量维度不同无法混用。我在测试时吃过这个亏换了 embedding 模型后旧文档还能检索到但检索出来的结果相关性明显异常排查了半天才想到是向量空间不一致的问题。重建索引后一切恢复正常。5. 高频排错清单解析失败、召回率低与版本更新5.1 解析失败的三层排查链路热搜词里weknora 解析失败的原因是什么绝对是命中率最高的问题我自己也踩过。整理一下完整的排查链路按顺序走就行。第一层检查文档本身。WeKnora 的解析模块对 PDF 的依赖尤其多如果 PDF 是扫描件图片型需要 OCR 能力而 WeKnora 的 DeepDoc 模块对图像型 PDF 的识别效果受限于配置的 OCR 服务如果扫描件没有 OCR 服务可用解析必挂。另外加密 PDF、损坏的 Word 文档、超大文件比如一个 300 页带大量高清图片的 PDF都容易触发解析超时或内存溢出。我的建议是先用一个小文件测试解析链路确认通了再传大文件。第二层看解析日志。Docker 部署下用docker logs查看处理文档的容器日志。最常见的报错类型是超时——解析服务默认有超时限制大文件或者网络慢如果注释了外部 OCR 服务时会容易触发另一类是模型接口报错——如果文档里包含图片WeKnora 可能会调用视觉语言模型来理解图片内容模型 Key 没配或者余额不足解析流程就会中断。第三层检查资源。ES 容器内存不够时索引写入会不断重试直到报错。如果你在日志里看到bulk相关报错或者 ES 容器反复重启十有八九是内存不足。前面说的 Docker Desktop 资源配置调整在这一层是最常被找到的根因。我实际处理过的一个案例一个同事上传 50 页产品手册解析卡在 30% 不动日志显示某一张数据处理超时。最终定位原因是文档里嵌入了大量高清产品图解析图片调用的模型服务响应太慢。解决方案是先把图片压缩再传或者调整解析服务的超时参数。5.2 召回率低先别急着调参数先检查这三个地方怎么提高匹配度真是个热门问题。我的经验是出现召回不准时先检查三个地方而不是上来就调 TopK 值检查 embedding 模型的领域匹配度。技术文档用通用 embedding 效果就差换成代码/技术方向的微调模型会有显著提升。检查文本切分粒度。WeKnora 默认切分基于 token 数如果你的文档段落很长一个切分块可能包含了多个主题检索时每个块都沾边但不精准。这种情况需要调整切分参数块大小、重叠大小或者启用基于标题结构的分块策略让每个块尽量对应一个语义单元。检查索引是否重建过。如果你改过 embedding 模型、调整过切分参数旧的索引数据会干扰检索结果必须重建知识库索引。我自己调试过程中的一个心得是不要指望一个参数适配所有文档。不同类型的文档比如对话记录、产品规格书、规章制度最优切分参数是不同的。WeKnora 一个知识库里如果塞了多种异质文档建议按类型建多个知识库分别调参比在一个知识库里找万能参数效果好得多。5.3 版本更新腾讯云的 WeKnora 如何升级这个热搜词很有意思其实 WeKnora 是开源项目所谓腾讯云的 WeKnora大概率是部署在腾讯云服务器上的自建实例或者是某个云市场镜像。升级方法跟部署方式强相关Docker Compose 部署进到项目目录git pull拉最新代码然后看docker-compose.yml里镜像版本有没有变更用docker compose pull拉新镜像再docker compose up -d重新创建容器。升级前务必备份 ES 数据目录和配置文件因为 ELS 的数据卷是不会随着镜像更新自动迁移的。直接改代码部署更简单拉代码、安装依赖、重启服务即可但要留意数据库结构变更。如果项目有 schema migration 机制通常会有指定的升级命令文档里一般有说明。升级这件事上建议不要盲目追新。如果不是为了修复某个 bug 或获取某项新功能维护在旧版本上更稳定。WeKnora 迭代速度不慢小版本升级通常问题不大跨大版本升级一定先看 release notes。5.4 日志排错的基本功最后补一个通用的排错技能Docker 部署类项目出了问题看日志永远是第一步。我自己整理了一个小口诀分享给团队后大家都觉得好用前端页面问题看前端容器日志比如 Nginx 报 502说明后端挂了后端接口问题看后端服务容器日志比如模型调用报错数据处理问题看处理文档的容器日志比如解析超时、ES 写入失败数据库问题看 ES 容器日志比如内存压力、索引状态异常。记住一条经验大多数部署问题都不是代码 bug而是配置或资源问题。不要一上来怀疑项目本身先确认环境是否满足要求。我在群里见过太多人把跑不起来归咎于项目有坑最后发现只是 .env 文件后缀名不对这种低级问题。6. 选型判断WeKnora、Dify、RagFlow、MaxKB 与 Obsidian 的边界6.1 同赛道对比WeKnora、Dify、RagFlow、MaxKB 这四个开源项目经常被放在一起比较选型时容易纠结。我给你一个基于实际使用经验的判断框架。Dify 的核心定位是 LLM App 开发平台知识库只是它众多能力里的一项。它的优势在 Agent 工作流编排、应用发布管理、团队协作适合做完整的 AI 应用但如果你的需求只是知识库问答用 Dify 会觉得重配置项太多。RagFlow 和 WeKnora 更像两者都强调文档解析。RagFlow 的深度文档理解做得很好尤其是复杂版面 PDF 的解析还原界面也更现代WeKnora 的优势在于背靠微信团队对中文场景的理解和优化更细而且播报 Agent 能力和开源协议相对友好。MaxKB 则更偏向开箱即用部署简单界面直观适合中小团队快速搭建内部问答。但它的可定制性和文档解析深度相对弱一些。项目最擅长的事相对短板适合谁WeKnora深度文档解析 中文场景 RAG 流水线上手门槛略高前端偏管理需要私有化、深度定制、中文文档为主DifyLLM 应用编排与 Agent 工作流知识库只是子模块偏重想构建完整 AI 应用的团队RagFlow复杂版面解析、可视化社区和中文生态不如 WeKnora文档排版复杂、重视界面体验MaxKB快速部署、易用性强深度定制能力有限中小团队要快出成果这四者没有绝对优劣关键看你的需求重心落在哪。如果核心痛点是文档解析不准和中文知识库效果差WeKnora 和 RagFlow 值得优先试如果是我要做一个带知识库的 AI 应用还要接很多其他工具Dify 更顺手。6.2 WeKnora 与 Obsidian 的组合玩法热搜词里weknora 和 obsidian出现频率不低这个组合其实代表了一种进阶玩法。Obsidian 是个人知识管理的利器它的核心优势在双向链接、图谱、本地存储但它的搜索本质上是全文匹配不是语义检索也没法做 RAG 问答。有人把 Obsidian 里的 Markdown 笔记批量导出放进 WeKnora 建立索引然后用 WeKnora 做语义问答。这个流程我试过效果确实不错笔记里那些散布在各处但内容相关的信息用全文搜索很难找全但语义检索可以。操作上有个坎Obsidian 的笔记通常分多个文件夹WeKnora 批量导入时能不能保留目录结构、避免切分时把不相关内容合并需要做一些数据预处理。我的做法是写一个脚本把 Obsidian 仓库里的 Markdown 按目录合并导出为几个大文件或者直接用 WeKnora 的多文件上传功能把整个目录传上去。实测下来每个笔记文件单独上传效果更好因为切分时不会把两个不同主题的笔记内容混到一个文本块里。6.3 企业私有化部署的补充判断还有一个被反复提起的问题国内企业拿 Llama 等开源模型做知识库问答和私有化 Agent到底行不行。我的结论是方案可行但效果底线受模型能力限制基础设施存档仍建议用云端大模型做对拍。具体到 WeKnora 私有化模型比较急迫的数据合规背景下的稳妥路径是先把最优公开模型跑出标准答案集再用本地小模型跑同一批问题两者差异一目了然。如果差异在可接受范围纯私有化方案直接上如果差异太大就必须考虑混合架构——把敏感文档留在本地把通用问题走云端。这个思路可以用于几乎所有私有化知识库项目不限于 WeKnora。7. 踩坑实录我这段时间遇到的最典型的三个问题7.1 安装好之后页面能打开但创建知识库总是转圈这个现象非常典型。前端页面正常加载但创建知识库、上传文档、提问等操作全部卡住或报错。我排查步骤是这样的先看后端容器日志发现 Elasticsearch 连接失败。用docker compose logs翻日志看到连接被拒绝的记录。再单独检查 ES 容器发现它的健康状态是 yellow 甚至 red——实际上单节点 ES 集群默认健康状态是 yellow因为副本分片未分配这本身不是故障但如果磁盘空间不足或内存压力过大ES 请求就会失败。我的处理方式是调大 Docker 内存配额然后重启 ES 容器问题解决。这类能打开但无法操作的问题十有八九在后端依赖服务尤其是 ES。很多人只看前端页面觉得部署成功了其实前端容器起来只代表静态资源能访问跟后端完全无关。判断部署是否成功的唯一标准是后端 API 能不能正常返回。7.2 配置文件改了半天不生效我在 .env 文件里改了模型配置重启容器之后发现不生效。排查下来是两个原因一是 Windows 下文件名后缀问题.env.local 被保存成了 .env.local.txtDocker 加载的是另一个配置二是 Docker Compose 某些版本有配置缓存即使文件改对了不重新执行docker compose up -d --force-recreate旧的容器环境变量也不会更新。正确操作顺序是确认文件名和内容无误后执行docker compose down再docker compose up -d --force-recreate强制重新创建容器环境变量才会从最新配置文件里读取。只restart是不行的这一点很容易踩。7.3 文档解析成功但检索结果总是文不对题我的经验里这类问题的排查顺序是先换一个问题试试排除是问题本身的歧义如果换问题后检索正常说明是特定文档内容的问题如果所有问题都检索不准则优先怀疑 embedding 模型匹配度和文本切分参数。有一次我调了很久最后发现问题是文档里的专业术语缩写太多embedding 模型没学过这些缩写导致语义相似度计算偏差。后来我在知识库配置里加入了一个同义词/关键词扩展的预处理规则问题得到明显改善。WeKnora 支持一定程度的检索前处理配置灵活使用能解决不少实际问题。8. 一份可以直接抄的启动清单根据我多次部署、重装、调试下来的经验最后整理一份抄作业级别的启动清单你按顺序走完大概率能一次跑通。在 Windows 11 上装 Docker Desktop确认 WSL 2 后端已启用虚拟化已开启Docker Desktop 资源配置改到 4 核 CPU、6G 内存以上克隆代码仓库到本地路径建议用全英文避免中文路径引发不可预知的问题配置 .env 文件填入语言模型服务和 embedding 服务的 Key、Base URL、模型名docker compose up -d拉取镜像并启动docker compose ps确认核心服务全部 Up浏览器打开前端页面到系统设置里确认模型服务连接成功上传一个小体量测试文档跑通解析 - 建库 - 提问 - 回答全链路自检复合问题问答验证 Agent 能力再上传真实业务文档按文档类型拆分知识库分别调切分参数。这套流程我前后在几台不同配置的机器上验证过按顺序执行问题出现率最低。如果你是在 Linux 服务器上部署前两步改为安装 Docker Engine 和 docker-compose-plugin防火墙开放对应端口即可。部署 WeKnora 这件事说难不难说简单也不简单。它最大的门槛其实不是技术而是对 RAG 流水线每个环节的理解——你理解了每个组件在干什么出了问题就知道往哪查你不理解就只能看着报错日志干瞪眼。这篇文章把我从零到一的过程完完整整记录下来了希望你在自己的部署路上能少走几步弯路一次点亮知识库。