企业官网建设流程全解析

过去一年多我一直在折腾私有化知识库。从最早用向量数据库自己写检索管道，到后来用Dify搭过一阵流水线，也专门拿RAGFlow跑过重解析场景，期间还试过AnythingLLM这类轻量工具。整体感觉是：主流开源RAG方案已经能把“文档问答”做得差强人意了，但距离我想要的“知识库”还有不小距离。最大的瓶颈不是召回率，而是知识库本身太被动——你问一句它答一句，对话一关它什么都记不住；它也没有“手”，不能去查实时数据、不能调API、不能帮你生成一份现成的报告。

所以看到WeKnora v0.8.0把“记忆、手脚、技能”这三个方向同时打通的时候，我确实眼前一亮。这篇落地手记不是官方文档的复述，也不是功能介绍的搬运，而是我实际部署和使用一段时间的完整记录：为什么换到这个方案、Docker部署怎么一次跑通、短期记忆和长期记忆的机制到底怎么回事、工具调用和技能系统怎么接入、文档解析和召回优化怎么做，以及生产环境里踩过的那些坑。如果你正在选型开源知识库，或者已经把WeKnora跑起来但对记忆和技能模块一头雾水，这篇应该能省你不少时间。

先交代我的使用场景，方便你理解后文很多决策为什么这么做。我拿知识库主要做两件事：一是把团队内部的IT资产信息、网络拓扑文档、运维手册整理成可问答、可调用的知识库，供售后和技术支持查询；二是给项目组做一个项目Wiki式的辅助工具，日常积累的决策记录、复盘和规范都往里丢。前者偏向准确性和工具调用，后者偏向长期记忆和持续沉淀。WeKnora v0.8.0正好落在这两个需求的重合点上。

1. 为什么我对v0.8.0这么上心：传统RAG知识库缺的三块拼图

1.1 缺记忆：检索问答是“失忆式”的

绝大多数RAG知识库的上限不是模型，而是“记忆”。传统做法把每次提问当成独立请求，先做向量检索，再把命中的文档片段拼进Prompt交给大模型回答。这套流程对单轮问答没问题，但连续对话时就露馅了：用户上一句说“我们网络出口是两条电信专线”，下一句问“那备线带宽多少”，知识库并不知道“备线”指的是什么，除非你把完整历史全部塞进上下文，否则它只能重新检索，大概率答非所问。

更麻烦的是跨会话。今天用户问过什么、关心过什么、最终结论是什么，明天再开一个会话，一切都归零。对个人助手这种场景还好，但知识库一旦放进团队、放进售后支持，失忆就是硬伤。WeKnora v0.8.0引入的短期记忆加长期记忆双网络设计，解决的正是这个“失忆”问题。

1.2 缺手脚：知识库只能“说话”不能“干活”

传统知识库是“只会说话的资料员”。你问“某台服务器的IP是多少”，它能从运维手册里翻出答案；但你问“当前这台服务器在线状态怎么样”，它做不到，因为知识库里没有实时数据。再比如“帮我把本周的工单情况汇总成一张表”，传统RAG知识库只能干瞪眼——它没有查询数据库的工具，没有调用监控系统的通道，也没有生成表格文件的能力。

这一点在企业场景中特别致命。知识库的价值不在于“背资料”，而在于“基于资料去完成实际任务”。WeKnora v0.8.0里给模型接上了工具调用能力和MCP标准协议支持，相当于给这个资料员装上手脚：它可以请求外部API、执行搜索、读取数据库、甚至可以按照指定格式生成文件。知识库从“能答”进化到了“能做”。

1.3 缺技能：通用问答覆盖不了垂直场景

第三个缺口是“技能”。通用RAG知识库把所有问题都当成“从文档里找答案”，但实际使用中很多场景需要的是流程化处理。比如IT资产盘点：它需要先查询资产数据库，再对照网络拓扑图，再结合历史变更记录，最后生成一份规范化的盘点报告。这不是一次向量检索能完成的，而是多个步骤的组合。

WeKnora v0.8.0里的“技能”模块，就是把这些多步骤、多工具、多提示词的流程固化下来。一个技能可以看作一组预定义的工作流：什么时候调用什么工具、用哪段提示词引导模型、输出格式约束成什么样，全部封装好。用户不需要每次都从头描述需求，直接触发技能就行。这一点和Claude的Skills、OpenCode的Skills思路一致，但WeKnora把它做进了开源知识库本体。

2. Docker部署全流程：从拉镜像到建第一个知识库

2.1 硬件与前置要求

先泼一盆冷水：WeKnora虽然开源，但它不是那种单容器就能跑的轻量工具。我的实际部署环境是一台32GB内存的Linux服务器，4核CPU，没有独立GPU。这套配置跑下来的感受是：检索问答完全够用，批量文档解析时CPU会飙到接近满载，但不会卡死。如果你只有8GB内存，不建议尝试，因为光是向量库加模型网关再加Web服务，内存就占到6GB以上。

另外需要准备一个大模型API。WeKnora本身不自带模型，它通过模型网关接入外部的大语言模型服务。我本地用的是通过兼容接口接入的Qwen系列，也测试过OpenAI兼容模式的远端服务。Embedding模型我选择了本地部署的bge-large-zh-v1.5，这类中文向量模型在Docker里很好跑，检索准确率比通用多语言模型高不少。你还需要一个向量数据库，WeKnora默认支持Qdrant，部署脚本里会一并拉起。

2.2 修改配置和启动

部署方式我用的是Docker Compose，项目仓库里提供了完整的编排文件。整体启动的核心组件包括：WeKnora后端服务、前端Web界面、Qdrant向量库、模型网关，以及一个负责文档解析的任务队列。第一次部署时我图省事直接执行了默认脚本，结果模型网关连不上我本地的模型服务，排查了半天才发现是环境变量里的模型地址没改。

修改配置集中在环境变量里。需要确认几个关键项：模型API地址指向你实际的模型服务端口，API Key填写正确，Embedding模型的向量维度要和Qdrant集合创建时的维度一致。我当时用的bge-large-zh-v1.5输出1024维向量，而默认配置里写的是768维，启动阶段不会报错，直到第一次执行知识库检索时才发现召回结果全是乱的。这种维度不一致的问题后面在踩坑章节细说。

配置改完执行docker compose pull拉镜像，然后docker compose up -d启动。首次启动需要等一会儿，因为Qdrant需要初始化集合，模型网关也要加载路由配置。整个过程顺利的话，浏览器访问服务器的8080端口就能看到Web界面了。

2.3 初始化与建第一个知识库

Web界面首次登录会让你创建管理员账号，这一步没什么特殊的。进入主界面后，我建议按这个顺序操作：先去模型设置里确认网关状态，然后添加Embedding模型，最后创建知识库。

创建知识库时有几个选项需要认真看：知识库名称、描述语言、分块策略、召回模式。默认的分块策略是按固定字符数切分，但我实际测下来，对结构化文档更适合用“按标题层级切分”，这个在后面章节专门讲。召回模式我一开始用的纯向量召回，后来改成“向量+全文关键词混合召回”加“Rerank重排”，准确率提升非常明显。

建完知识库就可以上传文档了。我传了一份包含表格的Word网络拓扑文档，系统自动进入了解析任务队列。第一次解析花了大约40秒，解析完成后能在文档列表里看到每个分块的内容预览。到这里，一个“能回答文档问题”的基础知识库已经跑通了。

3. 记忆机制拆解：短期记忆和长期记忆怎么协同工作

3.1 短期记忆：会话内的上下文窗口

WeKnora的短期记忆实现方式是会话级别的上下文管理。在同一个会话里，每一轮问答都会把之前的对话记录拼进Prompt，让模型知道“刚才聊过什么”。这个机制本身不新鲜，几乎所有聊天机器人都做了，但WeKnora做得比较聪明的地方是它不会无限堆历史——它有一个滑动窗口，超过一定轮次的旧对话会被“摘要化压缩”。

我在实际使用中感受最明显的是连续修正场景。比如我连续问了三个关于网络拓扑的问题，前两个问出口后又补充了更正信息，如果没有短期记忆，模型会把三个问题割裂开，容易把更正前的错误信息当作依据。有了短期记忆，模型能理解“我前面说的某台设备型号实际是另一款”，回答后续问题时就不会自相矛盾。

短期记忆的单位是会话。一个会话对应一组上下文，会话之间的记忆不共享，只沉淀到长期记忆。所以纯靠短期记忆解决不了跨会话遗忘的问题，你必须同时开启长期记忆功能。这也就是为什么WeKnora把两套机制做成了“双网络”而不是单一记忆。

3.2 长期记忆：把对话沉淀成可检索的“事实”

长期记忆是我认为v0.8.0最值得花时间理解的部分。它的设计思路可以概括成一句话：从对话中抽取“可复用的信息”，以结构化的形式存入独立的长期记忆向量索引，下次对话时再按需召回。

实际工作中它表现成什么样子？举个例子：某天用户问“我们公司深圳机房的出口带宽是多少”，我从文档里检索到答案后，在后续对话中补充了一句“深圳机房目前主用电信，备用联通的链路切换由SD-WAN自动完成”。这句话不在原始知识库文档里，但它是这次对话产生的新信息。开启长期记忆后，系统会把这句对话里的关键信息抽取成事实条目，经过向量化后存入长期记忆库。

过了一周，另一个会话里用户问“如果电信线路全挂了会怎样”，系统会从长期记忆里召回“深圳机房主用电信、备用联通、SD-WAN自动切换”这条沉淀下来的事实，再结合知识库文档回答。这个效果就很有意思了——知识库不再只依赖你上传的静态文档，它开始从对话中“长出”新的知识。热搜词里有一个“记忆系统设计”和“hindsight记忆库”，跟这个思路是同一个方向，只是WeKnora把它做成了开箱即用的功能。

3.3 双网络记忆模型的实际检索流程

所谓“双网络”，指的是两条平行的检索通道。一次提问发起后，系统会同时做三件事：第一路从短期记忆取最近对话上下文，第二路从长期记忆库做向量检索召回历史事实，第三路才去知识库文档做常规的RAG检索。三路结果会经过一个合并排序模块，按相关度打分后一起拼进Prompt。

这个合并排序模块很影响最终效果。我实测下来的感受是：如果长期记忆召回的条目和当前问题高度相关，它的优先级会排在文档检索结果前面；但如果相关度不够高，会被过滤掉。这个过滤阈值是可以调节的——太宽松会导致长期记忆里的过期信息抢答，太严格会让记忆形同虚设。我用的阈值在0.35到0.4之间，既能召回相关事实，又不会明显干扰文档检索。

长期记忆的更新有一个判别机制：不是每句话都值得沉淀。系统会对对话内容做一次信息量评估，只有包含具体实体、关系或可验证事实的表述才会被抽取。纯闲聊、重复提问、无意义寒暄会被自动跳过。另外，如果新对话中的信息与旧记忆冲突，系统会标记出来，在召回时提示用户发现矛盾条目。

3.4 记忆机制的边界和注意事项

记忆机制再强，也有自己的边界。首先是记忆污染问题：如果知识库被多人共用，A用户在某次对话中表达的偏好可能会被当作通用事实沉淀，影响B用户后续的检索结果。所以我在团队环境里开启了多用户隔离，让每个用户的长期记忆分开存储，只有知识库文档是共享的。这个开关很重要，尤其是售后团队使用场景。

其次是长期记忆的容量增长问题。使用时间越长，长期记忆库里的条目越多，检索延迟会上升，召回准确率也可能下降。我的处理办法是每月做一次记忆清理，对明显过时的信息（比如临时使用的设备型号、一次性故障处理记录）手动删除或标记过期。目前看效果还可以，但我觉得官方后续应该出一个自动衰减机制，让长期记忆带上时间权重。

最后提醒一句：长期记忆沉淀的是从对话中抽取的事实，它有出错的可能。模型抽取时可能把口语化的、带有歧义的表述当成确定事实存进去。所以对于技术类知识库，我建议把长期记忆的定位从“知识来源”降级为“辅助线索”，最终回答的权威依据还是要以知识库原始文档为准。

4. 手脚与技能：MCP工具调用和技能系统实战

4.1 内置工具调用是怎么生效的

先说说“手脚”这一部分。WeKnora v0.8.0把工具调用做成了标准化的函数调用机制：模型在回答过程中如果发现需要实时数据或外部操作，会先输出一个工具调用请求，系统执行完再把结果返回给模型，由模型基于结果继续生成回答。这个机制和我之前集成OpenAI Function Calling的流程类似，但WeKnora把工具生命周期的管理做进了知识库的会话流程里，不需要额外写中间层。

我实际用得最多的是四个内置工具：HTTP请求工具、数据库查询工具、文件生成工具、浏览器搜索工具。HTTP请求工具最常用，我配置了对接内部监控API的模板，让知识库能实时查询服务器状态和带宽占用；数据库查询工具用来对接资产管理系统，用户问“某设备保修到什么时候”，它不是从文档里背一个静态答案，而是实时查数据库返回最新状态；文件生成工具可以把问答结果直接导出成Word或CSV。

首次使用工具时，你需要做两件事：一是确认工具已经启用，二是配置工具的访问权限和参数模板。权限设置很关键，我之前没有给HTTP请求工具加白名单，结果模型在回答一个问题时试图请求内网的一个敏感接口，虽然被防火墙拦住了，但也暴露了安全隐患。建议把所有工具调用都加上“人工确认”选项，让每一次工具执行需要用户在界面上点确认，等业务跑顺了再逐步放行。

4.2 MCP标准：把外部工具接入WeKnora

MCP是最近AI工具集成领域很热的一个标准，WeKnora v0.8.0完整支持了这套协议。简单说，MCP把“工具能力”抽象成了标准的服务器，任何符合MCP协议的工具服务器都能接入到WeKnora里，不需要为每个工具单独写适配代码。我的理解是：传统集成方式是“给每个API写一个封装”，MCP是“把API能力描述成标准工具清单”，模型按清单调用。

我在生产环境接入了一个自己开发的工单查询工具，不到半小时就跑通了。步骤是：开发一个满足MCP协议的小服务，把工单查询接口暴露成工具；在WeKnora界面里添加MCP服务器地址；刷新后工具列表就多出了这个能力。通过MCP接入的工具和内置工具在技能里可以混用，这个体验非常流畅。

我在接入过程中踩过一个小坑：MCP工具返回的数据格式没有统一，有的返回JSON，有的返回纯文本，导致模型解析时偶尔出错。后来我把所有工具返回值都规范成了同一结构，在返回前加了一个描述字段说明数据类型，问题就消失了。这算是个很实用的经验，你对接MCP时最好也做一层返回值规范化。

4.3 技能系统：把多步骤做成可复用流程

技能系统是把“记忆、手脚”串起来的那个“大脑”。一个技能定义包含三部分：触发条件或使用场景描述、模型执行时的引导提示词、需要调用的工具序列。创建技能不需要写代码，在界面里以表单形式配置即可。

我配置了一个“IT资产盘点报告”技能，它的流程是这样的：先触发数据库查询工具拉取资产清单，再触发HTTP请求工具查询各核心设备状态，然后让模型按照预设的周报模板把信息整合成结构化报告，最后调用文件生成工具导出为Word文档。整个过程中用户只需要在对话框里输入“帮我生成这个月的IT资产盘点报告”，剩下的事情全部由技能自动完成。

技能配置里最核心的是“提示词模板”。模型能不能正确地按流程走，基本取决于提示词写得清不清楚。我之前写得太笼统，结果模型跳过了数据库查询步骤，直接拿文档里的旧资产信息生成了报告。后来我在提示词里明确写了“必须先调用工具查询实时数据，禁止使用知识库中的历史资产信息作为当前盘点依据”，效果立竿见影。

4.4 技能和知识库的协同

技能不只能调工具，还能主动访问知识库。同一个技能里可以指定使用哪个知识库、设置检索条件、限定召回范围。我做的“变更影响分析”技能就是这样：先到变更数据库查最近提交的变更申请，再检索知识库中的网络拓扑和依赖关系文档，最后综合两部分信息输出影响分析。

这种协同能力让知识库的“资料员”属性彻底变成了“分析师”属性。传统RAG知识库是“人在使用知识库”，技能加持之后，更像是“知识库+工具+流程”构成了一个能独立完成任务的小型自动化单元。我现在的目标是把高频的售后问答、巡检、盘点任务都固化成技能，让团队成员不需要懂技术也能用知识库完成复杂操作。

5. 文档解析与索引优化：喂进去的Word/PDF是怎么变成答案的

5.1 文档解析管道：从字节流到干净文本

文档解析质量直接决定知识库智商的上限。WeKnora的文档管道大致分四步：格式识别、内容抽取、清洗转换、结构化分块。第一步判断文件是哪一种格式，第二步抽取文字和表格，第三步去掉页眉页脚、多余换行、无意义的批注，第四步按策略切分成块。

我在生产环境里喂得最多的两类文件是Word和PDF。Word文档解析比较顺利，标题层级、表格结构都能保留；PDF则分两种情况。文本型PDF（比如从WPS直接导出的）内容抽取很干净；扫描版PDF就麻烦了，虽然系统内置了OCR支持，但对中文表格的识别误差比较大。我的经验是：扫描版PDF先在外面用专业OCR工具处理一遍，输出文字版PDF再喂给知识库，准确率明显提升。

还有一个小细节：图片中的文字。网络拓扑图、架构图、截图里的关键信息，文档解析管道默认是抓不到的。我需要额外上传一份提取过的文字说明文档，或者在原文档里给图片补充说明文字。这个习惯养成之后，知识库的“知识密度”会高很多。

5.2 分块策略：切分方式直接影响召回效果

分块是RAG里最容易被忽视、但对效果影响最大的环节。WeKnora默认按固定字符数切分，默认块大小是大概500字，重叠50字。这种策略对长文档的段落切分很方便，但会把本来连贯的表格拆散，也会让文档的标题和正文内容分成两块。

我的实测建议是：Markdown类文档用“按标题层级切分”更合适，一次切分到二级标题，每个二级标题下的内容作为一个独立的块；Word文档先转为结构化的标题树，再按标题切分；PDF表格多的文档，尽量让一个表格完整地落在一个块内，不要让表格跨块。块大小也需要微调。我一开始用默认500字，检索命中了一些内容不完整的片段；后来把块大小调整到800字、重叠100字，并且把最小块下限设为200字，召回文本的信息完整度明显提高。

分块策略改完，需要重新对知识库内的文档做一次索引重建。这个操作会消耗一定CPU资源，建议在业务空闲时段执行。

5.3 混合检索与重排：准确率的关键一步

WeKnora的召回模式分为纯向量检索、全文检索、混合检索三种。纯向量检索对语义理解好，但对精确关键词不敏感，比如文档里写的是“出口带宽”，你问“专线速率”，向量检索有可能召回，也有可能召回一堆语义相近但不包含关键参数的内容。全文检索对关键词敏感，但对语义相近的改写不友好。混合检索把两者结合起来，再用RRF算法融合排序，是生产环境中最稳的选择。

加Rerank重排模型之后，准确率还有一截提升。Rerank模型的任务是对混合检索召回的前20条结果重新打分，把最相关的排到最前面。实测下来，在同一批测试问题上，不加Rerank时Top1命中率大概70%，加Rerank后提升到88%左右。这个提升对知识库的问答体验非常关键。

Rerank模型的部署成本不高，一个几百MB的模型就能跑，CPU也能接受。如果机器内存紧张，可以只在最重要的知识库上开Rerank，次要知识库继续用混合检索。

5.4 召回参数调优的经验值

给一组我打磨了很久的参考参数：Top K召回数先取20，Rerank后取前5；相关度过滤阈值设为0.2，低于这个分数的片段不进入Prompt；上下文裁剪启用“按窗口截断”，保证最终Prompt里知识片段总长度不超过模型输入限制的三分之一。这套参数在我的场景下表现比较均衡。

还有一个技巧是知识库描述与问题改写。WeKnora支持在检索前对用户问题进行扩展改写，把“它”指代的具体内容还原，把口语化表达改成书面查询词。我建议开启这个功能，因为实际用户提问往往存在指代和省略，问题改写能显著提升召回命中率。不过要留意改写带来的延迟增加大约200到400毫秒，对交互式问答来说可以接受。

6. 和Dify/RAGFlow/AnythingLLM横向比较后，我的选型结论

6.1 一次客观的对比

做选型时我不只看WeKnora，而是把当时主流的三条路线都重新过了一遍。Dify胜在应用编排成熟、节点化设计完善、插件生态也丰富，但在“记忆”这一块偏轻，长期记忆和知识库的结合不是它的重点；RAGFlow的文档解析能力很有优势，特别是版面分析和表格还原，但整体更偏向于纯检索问答，对工具调用和技能编排支持较弱；AnythingLLM适合个人轻量使用，单机部署非常简洁，但多用户权限、工具扩展、记忆机制这些企业级能力基本都不具备。

下面用一张表汇总我当时的对比结果：

6.2 我为什么最终定在WeKnora

其实没有完美的方案，只有适不适合自己场景的方案。我的核心痛点是“知识库要能长记忆、能干活、能沉淀技能”，这三个需求里面Dify的强项是技能编排，但记忆和知识库结合太弱；RAGFlow的强项是文档解析，但不是为一个多功能的Agent型知识库设计的；AnythingLLM更不可能承担团队级别的职责。

如果你的核心诉求是“让文档解析和问答准确率做到极致”，我建议选RAGFlow；如果你的核心诉求是“搭一个可视化的AI应用流程编排平台”，Dify仍然是很强的选择；但如果你像我一样，想要的是一个能陪伴团队持续成长、能记住过去、能干实事的知识库，WeKnora v0.8.0目前是开源路线里最贴合的选择。需要提醒的是，这三者并不互斥，我也见过有人把RAGFlow做前端解析、WeKnora做问答与接口的混合架构，只是维护成本会高一些。

7. 生产环境踩坑记录，按坑的大小排序

7.1 第一坑：Docker部署后Qdrant内存爆掉

第一次把WeKnora整套用Docker Compose拉起来后，跑了不到一天，服务器直接卡死。查看状态发现Qdrant容器吃掉了将近16GB内存，原因是我导入了一批数量很大的文档，索引全量构建时Qdrant默认占用无上限。解决方案是给Qdrant容器设置内存上限，并开启内存映射数量相关的系统参数调整，同时在启动环境变量里限制向量索引的每个分片大小。之后把Qdrant的memory_limit手动设到4GB，索引构建变慢了一些，但整套系统稳定了。

这个坑很有代表性。很多人刚跑起RAG项目时只关注模型和知识库本身，忽略了向量库其实是最吃内存的一环，特别是全量索引重建阶段。生产环境部署前一定要先给排障用的监控工具留好位置。

7.2 第二坑：Embedding向量维度不匹配，检索结果全乱

前面部署章节提到过一次，这里详细说。默认配置里的向量维度是768，但我本地部署的bge-large-zh-v1.5输出1024维，知识库创建时如果没注意，实际写入Qdrant的向量维度和你配置的维度不一致，检索时会产生大量无语义意义的“随机召回”。症状表现为问答结果驴唇不对马嘴，而且不出任何报错。

排查过程很费劲。我一开始以为是模型网关的问题，反复切换模型供应商，问题依旧；后来直接在Qdrant里查看集合的向量维度，发现是1024，而配置里写的是768，才意识到是维度冲突。解决方案是删掉已有知识库集合，把模型配置改成实际维度后重新创建索引。这个问题提醒我：任何向量数据库方案，第一步永远是对齐 Embedding 维度。

7.3 第三坑：长期记忆串号，多用户互相污染

上线给团队使用后，有同事反馈“A用户问过的问题，B用户再问时会带出A用户的结论”。查了半天发现是长期记忆默认没有按用户隔离，不同用户的对话事实都会被写入同一个长期记忆库。在单用户个人知识库场景下这没问题，但多人共用一套部署时，这会造成严重的记忆污染。

解决方案是在用户管理和记忆设置里开启“长期记忆按用户隔离”，让每个用户的记忆沉淀互不可见。这个开关早开早安心，等数据积累多了再切换，历史记忆的归属会非常混乱。

7.4 第四坑：工具调用失控，连续发了几百个请求

技能刚开始上线时，有一个巡检报告技能的流程里配了循环查询，模型在执行工具时没有加执行次数上限，结果对着监控API连续发了几百个请求，把下游系统打出了限流告警。虽然没造成事故，但暴露了一个设计问题：技能里的工具调用必须有防护机制。

我现在给每个技能配置了三道保险：工具调用最大次数默认5次，超过就停止并提示；HTTP请求设置超时时间3秒；高风险的写入类工具全部要求人工确认。技术平台的功能再强，流程上的安全边界还是要自己守着。

7.5 第五坑：扫描版PDF和复杂表格识别不准

最后这个坑不致命但很烦。知识库里放了一批扫描版设备说明书和带合并单元格的表格，解析完成后的分块内容经常把表格拆得七零八碎，回答问题时引用到的数据错位。后来我对这批文档做了前置处理：扫描件先OCR成文字版再导入；复杂表格导出成图片并额外上传一份手动整理的纯文本版本供检索。这个方法牺牲了一点效率，但数据准确率保住了。

另外一个容易忽略的点是编码问题。部分从Windows传上来的Word文档内嵌了特殊字符，解析后出现乱码，影响检索。解决办法是在上传前统一用脚本做一次文本规范化。这个操作我已经放进了每周的文档入库流程里。

我在实际使用中最大的体会是：知识库工具的边界正在从“回答问题”向“参与工作流”平移。WeKnora v0.8.0让我第一次觉得知识库不再只是一个查询入口，它开始像一个有记忆、能动手、按流程办事的团队成员。最后再分享一个建议：不要一上来就把所有记忆、工具、技能全部打开，你的知识库也需要一个“实习期”。先让它把文档问答做稳，再逐步开启长期记忆、接入MCP工具、沉淀高频技能，一步步来，它才能真正成为团队里那个靠谱的同事。