企业官网建设流程全解析

一个多月前，我把公司那个只会“查文档、吐摘要”的静态 RAG 知识库下线了。原因很简单——它不回答多轮问题，不查实时数据，更不会主动干任何事。直到我把入口和配置迁到 WeKnora v0.8.0，让知识库同时接上了记忆、工具和技能，并用企业微信号挂到公司内部，才真正感觉到这是一个“能干活”的工程系统，而不是一个摆设。这篇落地手记不搞产品宣传，我会直接讲清楚我为什么从 Dify、RAGFlow、AnythingLLM 这几个方案里挑中它，本地用 Ollama 接模型时怎么配置不出错，记忆和工具调用是怎么实现的，以及最后接入微信回调和生产调优过程里那些必须避开的坑。

如果你正在搭开源知识库，或者已经有一个“问答还行但不够聪明”的 RAG 系统，这篇应该能给你省下不少时间。下面所有步骤都是我自己跑过的，能直接抄作业。

1. 被“静态知识库”劝退之后，我为什么押注 WeKnora v0.8.0

先说清楚我原来的架构有多“教科书”。文档上传后切块，用嵌入模型转成向量，建立向量索引，然后每次提问就把问题和库里最相似的片段一起丢给大模型生成回答。看起来是典型的 RAG 知识库，搜索热词里人人都在聊的那套。但真实用起来，问题接踵而来。

我总结了四个逼我换系统的失败场景：

• 用户问完“华东区 3 月销售额是多少”，紧接着补一句“那上个月呢”，系统直接把“上个月”当独立问题去检索，返回一堆不知所云的内容，因为没有多轮记忆。
• 问“今天下午三点的会议室定了吗”，知识库里根本没有日历数据，再强的检索也捞不出答案，因为没有手脚去调用外部系统。
• 用户说“请把这份审批提醒发给财务经理”，模型只会回复“很抱歉我无法执行”，因为没有可用的工具链。
• 同一个高频问题，隔两天又有人问，知识库仍然不会把上次的高质量回答沉淀下来，知识永远不会自己长大。

这四个问题分别对应标题里的记忆、手脚和技能。WeKnora v0.8.0 之所以能让我留下来，不是因为它把界面做得多漂亮，而是它在工程上把这三件事变成了可配置、可观测、可维护的模块。

1.1 v0.8.0 到底新增了哪些能力：记忆、手脚和技能

先说记忆。它不是单纯把聊天记录多传几轮给模型，而是分成了会话记忆和长期记忆。会话记忆负责把多轮上下文压缩成摘要，避免上下文窗口被撑爆；长期记忆则会把用户偏好、历史事实、未完成事项写入独立的记忆存储，让知识库“记得老用户是谁”。

再说手脚。v0.8.0 里我印象最深的是插件和工具协议。官方把工具调用做成了标准 JSON Schema，我可以在管理后台注册一个查询数据库的工具、搜索网页的工具、发微信通知的工具，然后让模型自己决定什么场景该调用哪个。这本质上就是大模型应用里常说的 function calling，但它多了一层权限控制，写操作和读操作分开授权。

最后是技能。技能不是一句提示词模板，而是一整套可编排的工作流。比如“周报数据问答”这个技能，内部包括意图识别、查询改写、多路召回、重排、生成回答五个阶段。模型只是最后一步，前面每一步都通过配置串联起来。这套东西放在生产环境里，最大的好处是每个环节都可以单独优化，不用重启整个服务。

1.2 和 Dify、RAGFlow、AnythingLLM 的横向对比

我真正动手前，把市面上常见的几个开源知识库方案都试了一遍，包括搜索热词里高频出现的 Dify、RAGFlow、AnythingLLM。每个都有可取之处，但都有我没法接受的短板。

RAGFlow 在文档解析和表格抽取上确实很强，但我想做的不只是文档问答，还要让知识库去查数据库、发通知，它的开放接口明显不够用。AnythingLLM 胜在简单，但复杂场景撑不住。Dify 是一个成熟的低代码平台，可惜它的定位偏“应用搭建”，而我想把知识库当成一个智能体基础设施去深度定制，工具调度和记忆策略的自由度不够。WeKnora 刚好补齐了这些点，所以最终选型定在了 v0.8.0。

2. 本地部署：Ollama 接模型，向量库选 Qdrant，其余交给 Compose

选型定了之后就开始落地部署。我的原则是能容器化就容器化，能本地跑就本地跑，数据不出内网。下面的环境清单和启动方式都是实际验证过的，你可以直接照抄。

2.1 硬件和软件版本清单

本地部署最关键的是先明确硬件底线。我用的是公司一台 8 核 32G 内存的旧服务器，没有独立 GPU，整体跑起来能接受，但回答速度偏慢。如果预算允许，建议上一块 8GB 以上显存的消费级 GPU，体感会好非常多。

软件方面，我用了 Docker 24+、Docker Compose v2，模型服务用 Ollama，向量数据库用 Qdrant，嵌入模型用 bge-m3，重排模型用 bge-reranker-v2-m3，对话生成模型用 qwen2.5:7b-instruct。这套组合在中文场景下性价比很高，而且都是搜索热词里大家常用的本地化组件。

2.2 docker-compose 配置和启动步骤

我习惯把整个栈拆成四个服务：Ollama、Qdrant、WeKnora Server、WeKnora Console。Console 是管理界面，生产环境可以不对公网暴露，只走内网。

services: ollama: image: ollama/ollama:latest container_name: ollama volumes: - ./ollama:/root/.ollama ports: - "11434:11434" qdrant: image: qdrant/qdrant:latest container_name: qdrant volumes: - ./qdrant_storage:/qdrant/storage ports: - "6333:6333" weknora-server: image: weknora/weknora-server:0.8.0 container_name: weknora-server depends_on: - ollama - qdrant environment: WKNORA_BASE_URL: http://localhost:8080 VECTOR_STORE: qdrant EMBEDDING_PROVIDER: ollama EMBEDDING_MODEL: bge-m3 OLLAMA_BASE_URL: http://ollama:11434 MEMORY_ENABLED: "true" MEMORY_SESSION_WINDOW: "6" ports: - "8080:8080"

启动命令很简单：

mkdir -p /opt/weknora/{ollama,qdrant_storage} cd /opt/weknora docker compose pull docker compose up -d

第一次启动后，先拉模型：

docker compose exec ollama ollama pull qwen2.5:7b-instruct docker compose exec ollama ollama pull bge-m3

然后打开 http://localhost:8080 初始化管理员账号，在模型配置里把 Ollama 地址填成 http://ollama:11434，把对话模型设为 qwen2.5:7b-instruct，嵌入模型设为 bge-m3。这里有个关键点：嵌入模型的维度是 1024，向量库第一次创建 Collection 时会记住这个维度。如果后面你换了嵌入模型，维度对不上，Qdrant 会直接报 dimension mismatch。我吃过这个亏，所以建议第一次就把模型定下来，不要频繁切换。

2.3 文档切块的参数经验

创建知识库、上传文档时，有一个容易被忽视的配置就是切块大小。我试过 256、512、1024 三档，最常用的是 512，重叠区设置 64。512 个字符大约能覆盖 300 到 600 字的中文段落，既不会让单段语义太碎，也不会让向量检索定位到过大的无关区域。64 个字符的重叠区，是为了避免句子正好被切在关键短语中间。如果是英文技术手册，块大小可以适当调到 1024，因为英文 token 密度和中文不一样，模板化段落更多。

召回数量我也建议从平台的默认 10 改成 5。这个细节后面调优章节会展开说，但你可以先记住：召回多了不一定是好事，尤其是知识库里有很多相似文档时，Top 10 会把一些完全不相关但措辞相近的内容也拉进来，模型容易把内容“缝”在一起，出现幻觉。

3. 给知识库装上“记忆”：会话记忆与知识沉淀的工程实现

接下来聊我最看重的记忆模块。静态 RAG 最大的缺陷是“答完就忘”，要让它有记忆，不是简单把历史消息拼到 prompt 前面。那样做有两个问题：一是上下文窗口很快被撑满，二是大量未筛选的历史信息会干扰检索，反而让回答变差。

3.1 短期记忆：压缩摘要而不是硬塞历史

WeKnora 的处理方式是，每个会话维护一个滑动窗口。我在配置里把session_window设为 6，意思是最近 6 轮消息会完整保留。一旦超过这个轮数，或者累计 token 超过阈值，系统会触发一次摘要压缩，用一个小模型把前面的对话内容归纳成几十个字的摘要，例如“用户正在核对华东区 3 月销售数据，关注逾期订单数量”。后续请求携带的是“摘要 + 最近几轮原始消息”，而不是全部历史。

这样设计的好处非常明显。上下文从“不断膨胀的完整日志”变成“定长的压缩摘要 + 近期原文”，既保留了多轮语境，又不会让 prompt 越来越臃肿。

我在配置里就是这样开的：

memory: enabled: true session_window: 6 context_compression: true compress_threshold_tokens: 2000 long_term: true long_term_ttl_days: 90

3.2 长期记忆：把真正有价值的信息沉淀下来

长期记忆解决的是“跨会话记得用户”的问题。我落地时做了一件比较大胆的事：给知识库开放了memory.write工具。当对话过程中模型判断出这是用户偏好、历史事实、未完成任务时，会主动触发这个工具，把信息写入长期记忆库。下次任何一次对话开始前，系统会先根据用户 ID 召回相关长期记忆，作为 prompt 的“背景资料”。

举个实际例子。用户说过“我做报表时只关心华东区，华南区不用看”，这个信息会被写入长期记忆。之后无论他问哪个月的数据，系统都会先想起这条偏好，直接把他关心的范围固定到华东区，不用他每次重复。

每个长期记忆项带有时间戳和 TTL，默认 90 天未有有效交互就自动淘汰。针对敏感内容还可以开启人工审核，避免模型把错误的推断当成事实存下来。这里我踩过一个坑：模型会把用户随口说的一句“这个月好忙”也当作事实写入记忆，导致后来每次回答都莫名其妙地被“用户很忙”影响。后来我把长期记忆的写入条件改成“必须同时满足明确表述 + 可验证性 + 用户无否定”，才把这种垃圾记忆压下去。

3.3 知识沉淀：让知识库从静态导入变成动态生长

除了用户侧的记忆，我还非常看重知识库自身的“成长”。v0.8.0 里有一个问答沉淀链路：每次模型回答后，用户如果点“有用”，这条问答对就会进入待审核队列。管理员审核通过后，系统会把问题作为新知识点写入知识库，标题就是问题本身，正文就是被采纳的回答。之后有人再问类似问题，就不再需要临时检索几十个片段拼答案，而是直接命中沉淀出来的高质量条目。

我把它理解成“用问题喂知识库”。跑了两个星期后，平台上最常被问的 30 个问题基本都有了精确匹配的知识条目，回答速度从原来的 4 到 5 秒降到了 2 秒以内。这个收益纯粹来自沉淀机制，不需要额外调模型。

4. 给知识库接上“手脚”：工具注册与函数调用链

记忆解决的是“记得住”，工具解决的才是“做得到”。这一章我专门讲讲我是怎么让知识库去查数据库、查日历、发企业微信通知的。

4.1 我注册的六个工具

工具协议并不复杂，关键在于你给模型多少“能力”以及怎么控制权限。我第一个版本只开了六个工具，都是基于真实办公场景切出来的：

工具的定义就是标准的 function calling JSON Schema，比如database_query是这样的：

{ "type": "function", "function": { "name": "database_query", "description": "查询只读BI数据库，返回Markdown表格格式的数据", "parameters": { "type": "object", "properties": { "question": { "type": "string", "description": "用户想通过SQL查询的数据需求描述" }, "table_hint": { "type": "string", "description": "可选的表名提示，辅助生成SQL" } }, "required": ["question"] } } }

实际运行流程是：用户问“华东区 3 月订单完成率是多少”，模型识别出这属于数据库查询需求，输出一个包含 question 参数的工具调用请求。WeKnora 的引擎收到这个请求后，去调一个内部服务，这个服务根据 question 用自然语言生成 SQL，然后对只读副本执行查询，把结果整理成 Markdown 表格返回。模型再基于表格结果生成最终回答。

4.2 让本地模型正确识别工具，而不是“看起来会调”

这里要特别提醒：本地模型和云端模型在 function calling 上的稳定性差距不小。我用 qwen2.5:7b-instruct，第一周测试时最大的问题是它偶尔会不按标准 JSON 格式输出工具参数，或者擅自填一个不存在的工具名。解决办法有三个：

• temperature调低到 0.2，减少输出随机性。
• 在系统提示词里明确列出可用的工具名称和调用格式，不要指望模型从函数列表里自己猜。
• 对工具调用的返回结果做格式校验，如果解析失败，给模型一次“修正输出格式”的重试机会。

实测下来，这三点配合好后，工具调用的成功率从 70% 左右提到了 95% 以上。剩下那一小部分失败，基本来自用户问题本身模糊，模型不知道要不要调用工具，这时我会让它先反问澄清，而不是强行猜测。

4.3 工具权限和失败兜底

工具链一旦开放，安全边界就变成第一优先级。我给每个工具挂了 RBAC，角色和用户组绑定，工具对用户组可见。普通用户看不到meeting_book和approval_notify，模型就不会给普通用户生成写操作调用。

对于写操作，我还开了二次确认。比如meeting_book被触发时，系统先在微信侧发一张确认卡片，用户点“同意”后真正执行。这个设计看着多了一步，但在生产环境里非常必要，否则模型一次参数理解错误就可能把会议室给定了。

失败兜底同样重要。工具调用超时或报错时，我统一设置成“向用户说明暂无法获取实时数据”，绝不允许模型自行编造一个结果。最开始我没做这个限制，模型在工具返回空结果时居然会“补全”一份看似合理的数据，这在对内汇报场景里风险很大。加了兜底后，至少保证了“不知道就是不知道”。

5. “技能”是先厂的工作流：多路召回、查询改写、重排的一整套纽带

工具解决了“能干什么”，技能则解决“怎么把事情干好”。我在落地中期发现，单纯靠“向量检索 + 工具调用 + 大模型生成”组合出来的回答，质量是不稳定的。原因在于，RAG 检索的精度只要有一点偏差，模型就会基于错误片段生成错误答案。技能编排的价值，就是把这个链条变成可控制的流水线。

5.1 一个“周报数据问答”技能拆解

我以公司里最常用的“经营周报问答”技能为例。这个技能的目标是回答类似“上周华东区订单趋势怎么样”的问题。它内部被拆成五个阶段：

• 意图识别：判断用户想问数据、问文档还是闲聊。意图识别我用了最简单的分类 prompt，成本很低，但能避免“数据问题”被误送进“文档检索”通道。
• 查询改写：把含有多轮记忆和模糊时间的表达还原成完整查询。比如“那上个月呢”，会被改写为“华东区 2025 年 3 月订单汇总”。
• 多路召回：向量召回、BM25 全文检索、数据库查询结果并行进行，然后把三路结果合并去重。
• 重排：把候选内容交给重排模型打分，只保留最相关的 5 条。
• 生成：基于“重排结果 + 工具数据”生成回答，并要求标注数据出处。

配置起来大概是这样的：

skills: weekly_report: enable: true route_condition: "话题包含:周报,经营,指标,订单" query_rewrite: true recall: vector: true bm25: true top_k: 20 rerank: model: bge-reranker-v2-m3 top_n: 5 generation: temperature: 0.2 strict_source: true

多路召回的意义在于互补。向量检索理解语义，但拼写和精确术语容易偏；BM25 精确匹配强，但不管语义。两者合并后，再用重排模型做最后把关，比任何单一检索都稳。

5.2 查询改写和重排器的配置

查询改写是本技能里性价比最高的一步。它本质上是用模型把小问题扩展成完整问题，但要注意别让改写过程引入错误信息。我的经验是：改写尽量基于对话记忆，不要发挥，只把省略的主语和具体时间补齐，其他原样保留。

重排器我用了 bge-reranker-v2-m3，它是一个交叉编码器模型，虽然速度比向量检索慢，但因为只对 20 条候选打分，整体延迟还是可控的。重排后的 Top 5 质量比直接向量 Top 5 高很多。一个典型的对比是：用户问“报销流程”，纯向量召回可能返回几条财务制度，但重排后真正排前面的就是带“报销流程”字样的操作手册。

5.3 技能的评价指标

不要只在界面上感觉“好像准了”，要落地的话一定要留评价指标。我统计了三个核心指标：检索命中率、回答采纳率、平均响应延时。

提高最明显的是首问检索命中率，主要靠的就是多路召回和重排。回答采纳率的提升则是因为强加了“严格引用来源”，模型不敢再胡编，蜻蜓点水式的错误反而少了。

6. 微信侧接入：企业微信应用、回调验签和消息收发

标题里带“微信”二字，说明微信入口是整个落地里绕不开的一环。我选择的是企业微信自建应用方式，既可以用私有化聊天记录，也可以直接主动推送消息，比个人微信机器人正规得多。

6.1 回调配置的三个必要操作

企业微信接入本质上是一个“消息收发长连接”的替代方案，它通过 HTTP 回调把用户发给应用的消息推送到你的服务器。三个必要操作：

• 在企业微信管理后台创建自建应用，拿到 AgentId 和 Secret。
• 配置“接收消息服务器 URL”，格式为https://your-domain/weknora/webhook/wecom，同时设置 Token 和 EncodingAESKey。
• 在服务器侧把回调地址反代到 WeKnora 的 8080 端口，保证外网能够访问。

我本地测试时直接用 Nginx 反代，配置大致是：

server { listen 443 ssl; server_name bot.example.com; ssl_certificate /etc/nginx/cert.pem; ssl_certificate_key /etc/nginx/key.pem; location /weknora/webhook/wecom { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

6.2 消息加解密处理

企业微信回调的消息体不是明文，而是经过 AES 加密的 XML，同时在 URL 参数里有签名。第一次接入时最容易卡在“签名验证失败”和“解密乱码”上。签名验证的逻辑不复杂，核心就是把 token、timestamp、nonce 三个参数按字典序排序后拼接，做 SHA1 得到签名：

import hashlib def verify_signature(token, timestamp, nonce, signature): sort_list = sorted([token, timestamp, nonce]) calc = hashlib.sha1("".join(sort_list).encode("utf-8")).hexdigest() return calc == signature

但企业微信的echostr还需要 AES 解密，这一步强烈建议直接用官方 SDK，不要自己从零实现。解密后的 XML 里包含FromUserName（用户 ID）、Content（消息内容）、MsgType等字段。WeKnora 拿到这些字段后，会把内容交给 Agent 引擎处理。

我在生产里遇到过一个典型问题：回调验证时能收到消息，但实际提问后没有回答。后来发现是企业微信把消息推到了回调 URL，但我的服务器处理完没调发送消息 API 来回消息。也就是说，你要在回调处理完生成回答后，再调用一次企业微信的“发送应用消息”接口，给用户推回文本卡片。这一步没配置好，整个链路就是断的。

6.3 主动推送与群聊 @ 机器人

企业微信接入的一个额外好处是可以主动推送。知识库每次有新沉淀、有未解决问题、工具执行失败，我都可以通过 WeKnora 的接口主动发送通知到用户或群聊。这个能力在实际管理里非常有用。

我做了两个实际应用：一是当知识库收到一个没有命中任何内容的问题时，自动把问题推送到运维群里；二是当数据库工具查询结果异常时，主动通知管理员。主动推送需要应用有“发消息”权限，接收人必须在应用的可见范围内。

群聊场景则是把应用机器人拉到群内，成员通过 @ 机器人 提问。企业微信的回调里会带ChatId，WeKnora 渠道插件会识别群聊 ID，把回答发回群里。注意群聊里用户 ID 是企业微信内部 ID，不是手机号，需要做一次映射，否则记忆模块会把同一个人的两个不同 ID 当成两个用户。

7. 一个月实测下来的调优清单

任何系统上了生产都会暴露测试环境看不见的问题。我运行一个月后，把最有价值的调优和排错经验按主题整理出来，都是可以直接照用的。

7.1 检索准确率从崩溃到可用的调试

第一周最严重的问题是幻觉。用户问“公司考勤制度是什么”，系统回答里居然把“年假”和“加班工资”的条文缝在了一起。这两段内容在知识库里的前后位置差了十万八千里，就是因为纯向量召回 Top 10 后把中间所有相似段落全部拉进来了。

我做的第一件事是把召回数从 10 降到 5，第二件事是强制要求模型在回答中标注“该回答基于知识库哪些片段”。没用重排之前，降召回数会让短文档经常被漏掉；配上重排之后，Top 5 的质量足够，幻觉比例肉眼可见地下降了。如果回答里检索到的证据置信度低于阈值，我直接让模型回复“我在知识库里没有找到明确信息”。

7.2 并发、超时和内存治理

并发问题是本地部署最容易爆的雷。好几个同事同时在微信里问问题时，Ollama 的处理能力就成了瓶颈。我的服务器是 8 核 CPU，默认情况下 Ollama 每个模型只加载一个实例，多请求只能排队。我把 Ollama 的OLLAMA_NUM_PARALLEL调到了 2，允许两个请求并发，同时在 WeKnora 后端把 workers 从默认值调到 4。

OLLAMA_NUM_PARALLEL=2

内存方面，7B 模型需要约 5 到 6 GB，嵌入模型和重排模型又要占用两三 GB，加上 Qdrant 和 WeKnora 服务进程，32GB 内存跑起来勉强够用，但一旦有人同时上传大量文档并触发重新向量化，内存会迅速冲到 90%。治理办法是把文档解析和向量化任务放到低优先级队列，避免和实时推理抢资源。

7.3 在真实对话中不能踩的隐藏坑

最后分享几个不太容易在官方文档里找到的实践细节。

第一个是重复消息问题。企业微信回调在网络抖动时会重试同一消息，如果不做消息 ID 去重，用户会看到同一个问题被回答两遍。我加了一个简单的 Redis 缓存，以消息 ID 为 key 设置 60 秒过期时间，重复消息直接丢弃。

第二个是不要把数据库工具指向生产主库。模型生成的 SQL 可能带上全表扫描，也可能在问题不清时漏掉 where 条件。我用的只读副本，并且在工具内部强制给查询加 LIMIT 限制。宁可结果不全，也不能把主库拖垮。

第三个是日志要按request_id串起来。调试工具调用链路时，最头疼的是不知道模型为什么选择了一个不相关的工具。我们可以在 WeKnora 日志里把一次请求的完整链路打出来，包含原始问题、改写后的问题、召回候选分数、重排分数、工具调用参数、工具返回结果，按request_id过滤就能快速定位问题。

写在最后的一个小提示

如果你也准备在内部搭知识库，我最大的建议是把“记忆、工具、技能”当成三个独立模块先分别验证，而不是一把梭全配齐。先把静态检索调到可接受的水平，再加会话记忆，再开放只读工具，最后才接写操作。每加一层，就在微信里反复压测一轮。我的经验是，第一周只跑“静态知识库 + 微信回调”，第二周才放记忆和只读数据库查询，第三周才开始上写工具和主动推送。虽然上线节奏被拉长了，但真正出问题时，你能一眼看出是哪一层出的问题，而不是在一个复杂的智能体里大海捞针。