WeKnora 四种默认智能体模式：检索逻辑、适用场景与选型方法

5

本文根据 WeKnora v0.7.1 当前工作区配置整理，更新时间为 2026 年 8 月 24 日。默认参数只是预置模板；管理员仍可修改模型、提示词、工具、知识库范围和检索参数，实际行为应以部署环境为准。

一分钟选型

先判断问题的主要任务，而不是先判断哪个模式“更聪明”：

| 用户想做什么 | 首选模式 | 快速判断 | 典型问题 |
|---|---|---|---|
| 从制度、FAQ、说明书里找一个明确答案 | 快速问答 | 答案通常藏在一两个相关分段里 | 国外出差补助标准是多少？ |
| 比较、排查、跨文档综合，可能需要多轮检索 | 智能推理 | 一次检索无法完整回答 | 两个方案有哪些差异，风险分别是什么？ |
| 了解人物、组织、产品、概念之间的关系和全貌 | 维基问答 | 需要沿页面链接逐层展开 | 某产品有哪些核心产品和关联技术？ |
| 对 CSV/Excel 做计数、筛选、汇总、排行或统计 | 数据分析师 | 问题里出现多少、合计、平均、按月、排行等词 | 2026 年 5 月申请了多少件国内专利？ |

一句话记忆：快速问答是“直接查答案”，智能推理是“边查边分析”，维基问答是“沿知识关系找全貌”，数据分析师是“对表格算出结果”。

四种模式的共同底层

可以把 WeKnora 想成一位资料员：用户提问后，系统先决定去哪个资料柜、用什么方式寻找依据，再把证据组织成回答。四种模式的核心差异有两个：

1. **查哪里**：原始文档分块、FAQ、Wiki 页面，还是 CSV/Excel 数据表。
2. **怎么查**：一次召回后直接回答，还是分多步检索、阅读、补查和验证。

1. 快速问答

WeKnora quick workflow
WeKnora workflow diagram

核心定位

快速问答像前台资料员：收到问题后，快速找到最相关的几段，然后直接回答。它走固定的 RAG 流水线，不会像多步智能体那样反复制定计划和调用工具。

检索流程

1. **理解问题**：结合最近对话改写问题，让省略主语、上下文追问等表达更适合检索。
2. **召回候选内容**：结合语义检索和关键词检索，从知识库分段或 FAQ 中找候选内容；启用联网时也可获取网页结果。
3. **必要时扩展查询**：初次召回不足时，扩展关键词再次搜索。
4. **重新排序**：使用 ReRank 判断候选内容与问题的相关性；FAQ 可以获得额外加权。
5. **生成答案**：把少量高相关内容放入上下文，由模型一次性组织答案；依据不足时执行兜底策略。

适合

  • 企业制度、流程、产品说明和操作手册中的单点事实查询。
  • FAQ 客服：用户问法多样，但标准答案相对固定。
  • 响应速度要求高、问题量大的企微机器人。
  • 少量文档分段即可完整支撑的短答案。

不适合

  • 跨多份文档比较、原因排查和多条件综合判断。
  • Excel 全表计数、汇总、排行；命中的分段不等于业务数据总数。
  • 沿人物、产品、组织关系逐层探索的知识图谱问题。

当前默认倾向

默认启用问题改写、查询扩展、FAQ 优先、语义/关键词召回与 ReRank；检索和重排各取前 10 条，多轮历史保留 5 轮，联网搜索默认开启。管理员可以调整这些数值。

2. 智能推理

WeKnora reasoning workflow
WeKnora workflow diagram

核心定位

智能推理像研究员：先摸底，再拆问题，边查边判断，直到证据足够。它采用 ReAct 式多步工作方式，关键区别不只是模型能力更强，而是能够主动决定下一步查什么、读什么、是否补查。

检索与证据闭环

1. **判断是否需要检索**：寒暄等简单交互可以直接回答；事实性或专业问题会重新检索。
2. **先做一轮摸底**：通常同时使用关键词定位和语义搜索，找到可能相关的文档与分段。
3. **深读原文**：搜索结果只是路标；命中后还会读取完整分段或文档内容，避免只看摘要就下结论。
4. **决定直接回答还是拆任务**：证据完整就回答；涉及比较、缺口或多个主题时拆成检索子任务。
5. **循环补查和反思**：每个子任务执行“搜索—深读—检查缺口”，必要时换同义词、查知识图谱，或在知识库不足时使用网页搜索。
6. **汇总证据**：所有子任务有足够依据后，进行一致性检查，再生成完整答案。

适合

  • 合同版本差异、制度口径和多个产品方案的比较。
  • 根据错误信息、配置和操作记录逐步缩小范围的复杂排障。
  • 一个问题包含多个子问题，需要证据拼接和交叉验证的研究任务。
  • 需要调用知识图谱、文档工具或外部系统的任务。

使用边界

单点 FAQ 使用智能推理会增加等待时间和模型调用次数；如果没有开放正确工具，多步推理也无法突破能力边界。它仍不是电子表格计算器，可靠的全表统计应使用数据分析师。

当前默认倾向

默认允许关键词搜索、语义搜索、完整分段读取、知识图谱和文档信息读取；最大迭代次数 50，多轮历史保留 5 轮，联网搜索默认开启。

3. 维基问答

WeKnora wiki workflow
WeKnora workflow diagram

核心定位

维基问答像翻企业百科：先找到入口页，再沿链接阅读相关人物、产品和概念。它以 Wiki 页面及页面之间的链接为主，而不是直接在全部原文分段中“撒网”。

Search - Read - Expand 流程

1. **找到入口**：具体问题先搜索 Wiki；全库概览可以从首页进入，近期变化可以从日志页进入。
2. **阅读全文**：搜索结果只负责找到页面，真正回答前应打开页面阅读全文。
3. **沿关系扩展**：根据页面中的“链接到”和“被哪些页面引用”继续阅读相关页面，一般扩展 1—2 跳。
4. **必要时回查源文档**：Wiki 是整理后的摘要；用户要求原话、精确数字、代码或表格行时，应回到来源文档。
5. **发现问题则标记**：如果 Wiki 混合了两个实体、存在事实冲突或信息过期，可以提交巡检问题。

适合

  • “什么是……”类概念解释。
  • 产品、组织、人物的背景介绍和实体关系梳理。
  • 用户不知道资料在哪，希望先获得全貌再继续深入的知识导航。
  • 跨文档形成主题脉络，而不是只找某一句话。

使用前提与局限

知识库必须启用并生成质量良好的 Wiki；只有向量/关键词分块的知识库不适合此模式。Wiki 是模型整理后的二次内容，可能过时、遗漏或合并错误。精确数字、原句和最新表格数据不能只相信 Wiki 摘要，应回查源文档。当前默认不开启网页搜索，因此它更像内部百科研究员，而不是互联网搜索助手。

当前默认倾向

默认开放 Wiki 搜索、页面阅读、源文档精读和问题标记；最大迭代次数 30，多轮历史保留 10 轮，网页搜索默认关闭。

4. 数据分析师

WeKnora data workflow
WeKnora workflow diagram

核心定位

数据分析师像会写 SQL 的数据同事：先看表结构，再计算，出错就修正查询。它专门处理 CSV 和 Excel，不是从几个相似分段里猜总数，而是把表格当作数据表，用只读 SQL 对整表进行筛选、分组和计算。

检索与计算流程

1. **先看数据结构**：读取表名、列名、字段类型、行数等元信息，不跳过这一步直接猜 SQL。
2. **翻译查询条件**：识别时间范围、主体、分组、去重口径和需要返回的字段。
3. **执行只读 SQL**：通过 DuckDB 运行 `SELECT` 查询，禁止新增、修改或删除数据。
4. **失败后修正**：遇到列名、类型或日期格式问题时，根据报错调整查询并重试。
5. **解释结果**：把查询结果整理成总数、明细、表格或业务结论，而不是只抛出原始数字。

适合

  • 计数与去重：多少件、多少人、多少订单、多少个唯一编号。
  • 合计、平均值、中位数、最大值、最小值和标准差。
  • 按月份、部门、产品、状态分组，进行趋势、环比或排名分析。
  • 按日期、主体和状态筛选明细。

最容易踩的坑

  • Excel 有多个工作表时，必须明确目标页签，否则同名字段可能被跨页签混算。
  • “申请多少件”要先定义按行数还是按申请号去重，统计口径要和明细一致。
  • Excel 日期可能以序号保存，应先识别类型再转换和筛选。
  • 工具可能限制明细返回行数；要求完整明细时应分页查询，并核对明细行数与总数一致。

当前默认倾向

默认开放数据结构查看和数据分析两类工具，支持 CSV/XLSX，温度为 0.3，最大迭代次数 30，开启反思，网页搜索默认关闭；默认 SQL 明细建议最多返回 100 行。

四种模式横向对比

| 维度 | 快速问答 | 智能推理 | 维基问答 | 数据分析师 |
|---|---|---|---|---|
| 主要检索对象 | 文档分块、FAQ | 文档分块，可组合图谱和网页 | Wiki 页面及其源文档 | CSV/Excel 数据表 |
| 工作方式 | 固定流水线，一次生成 | 多步搜索、深读、补查 | 搜索页面、读页、沿链接扩展 | 先读结构，再执行 SQL |
| 响应速度 | 通常最快 | 通常较慢 | 中等，取决于跳转层数 | 中等，取决于查询复杂度 |
| 准确性关键 | 分段与检索排名 | 工具配置与证据闭环 | Wiki 质量与源文档核验 | 字段、筛选与去重口径 |
| 典型输出 | 简短答案、条款摘录 | 综合结论、对比、排障步骤 | 概念全貌、关系说明、导航链接 | 统计表、总数、明细、趋势 |
| 最常见误用 | 用命中片段推全表总数 | 简单问题过度调用工具 | 把 Wiki 摘要当精确原文 | 没有限定页签或统计口径 |

按企业知识库场景配置

场景 A：企微机器人回答制度与 FAQ

首选快速问答。把常见问法整理成高质量 FAQ，保留清晰标题、关键词和负责人信息；对无法回答的问题，在提示词中约定兜底联系人或转人工规则。复杂排障再转智能推理。

场景 B：法务、技术或项目资料研究

首选智能推理，让它深读多个文档并分步补查。如果知识库同时有 Wiki，可以使用 Wiki + RAG 的混合型自定义智能体：Wiki 负责导航，原文分块负责精确核验。

场景 C：企业百科、产品与组织知识导航

首选维基问答。重点不是简单调高 TopK，而是提高 Wiki 页面的实体拆分、别名、链接和来源质量，并定期处理事实冲突和混合实体问题。

场景 D：台账、报表和统计问答

首选数据分析师。上传结构清晰的 CSV/Excel，保持列名稳定；多工作表文件应让页签名称具有业务含义。提示词中明确日期字段、主体字段、去重键以及“总数与明细一致”的校验规则。

常见误区

| 误区 | 正确理解 |
|---|---|
| 智能推理一定比快速问答准确 | 不一定。单点 FAQ 上，快速问答更直接；智能推理配置不当反而更慢、更容易绕路。 |
| 把相似度阈值调低就一定能找到答案 | 阈值只影响召回范围。解析失败、分段缺失、字段不一致或问法完全不同，不能靠调阈值解决。 |
| 知识库里有 Excel，RAG 就能回答总数 | RAG 命中的是部分分段，不是扫描整表；可靠统计必须执行数据查询。 |
| Wiki 是原文的另一种显示方式 | Wiki 是模型整理生成的主题页面，便于导航；精确事实仍可能需要回查源文档。 |
| 四个内置智能体的参数是固定的 | 它们只是默认配置，可被管理员覆盖；修改后应重新做典型问题回归测试。 |

落地建议

真实企业场景往往不是四选一：可以保留快速问答作为高频入口，为复杂问题配置智能推理，为百科导航保留 Wiki，为台账统计配置数据分析师。关键是让每种问题进入正确的检索路径，并为每种模式准备一组典型问题做回归测试。

发布前建议核对：

  • 快速问答的 FAQ、标题、关键词和兜底联系人是否完整；
  • 智能推理是否开放了真正需要的工具，并设置合理的迭代上限；
  • Wiki 页面是否拆分清晰、来源可追溯且定期巡检；
  • 数据分析师是否明确页签、字段、时间范围、去重键和明细上限；
  • 模型、提示词、知识库范围或工具变更后，是否重新验证四类典型问题。

编写依据

本文依据 WeKnora v0.7.1 工作区中的以下配置与实现说明整理：

  • `config/builtin_agents.yaml`：四个内置智能体的默认参数与工具列表；
  • `config/agent_type_presets.yaml`：RAG、Wiki、混合检索和数据分析预设；
  • `config/prompt_templates/system_prompt.yaml`：快速问答的知识库回答约束；
  • `config/prompt_templates/agent_system_prompt.yaml`：智能推理、Wiki、数据分析工作流；
  • `internal/application/service/chat_pipeline/`：快速问答的问题改写、检索和重排流水线。