WeKnora 知识框架评估：RAG、ReAct Agent 与自动 Wiki 模式适合谁

企业知识库项目最容易翻车的地方，不是模型选得不够好，而是文档进去之后没人管结构：飞书里的会议纪要、Notion 里的产品文档、共享盘里的 PDF 和白皮书，各自躺在原地，检索时靠关键词碰运气，答错一次团队就失去信任。很多团队因此卡在"RAG 试点"阶段——demo 很惊艳，上线三个月后索引腐烂、没人更新、没人敢用。

腾讯开源的 WeKnora 想解决的正是这一段。它把自己定位成 LLM 知识平台：把原始文档变成可查询的 RAG、可自主推理的 agent，以及一份能自我维护的 Wiki。它值不值得上，取决于你的知识资产形态和团队愿意承担的运维复杂度。这篇从能力评估的角度，把它拆成三条主线来看。

三条主线：同一批知识库上的三种用法

WeKnora 的设计有一个容易被忽略的前提：RAG、Agent、Wiki 三种模式跑在同一组知识库上。这不是三个独立产品拼在一起，而是同一份索引的三种消费方式，这一点直接决定了它的定位——它更像知识底座，而不是一个问答机器人。

RAG：主打可核查

RAG 模式强调的是"答案你能自己验证"。官方描述里明确提到混合检索（hybrid search）、多模态解析和引用（citations）。对做企业文档理解的团队来说，引用比答案本身更关键：没有出处的高质量回答，在内部推广时反而会被质疑。多模态解析意味着扫描件、图表混排的文档也能进索引，但解析质量通常就是整条链路的天花板。

Agent：ReAct 循环加工具与记忆

Agent 模式在知识库之上跑一个 ReAct 推理循环，可调用的东西包括知识库、网络搜索、MCP 工具、skills 以及本地浏览器。它还支持长期记忆，并且可以在对话运行中 steer（干预方向）、fork（分叉）、rewind（回退重来）。这几项交互能力对调试和审计很实用——多步推理最怕跑偏之后只能重开一轮，能回退和分叉，意味着可以把一次失败的任务拆成两条路径去对比。

代价也要说清楚：多步推理意味着多次 LLM 调用，token 消耗不是线性增长。一次复杂任务的成本可能是单轮问答的十几倍。

Wiki：输出的是结构，不是答案

Wiki 模式在 v0.5.0 转为正式可用（GA），核心是让 agent 自动生成结构化、相互链接的 Markdown 页面，并配套知识图谱，UI 里有 Wiki 浏览器和可视化图谱，同时支持回滚。这是三条线里最有想象力也最需要警惕的一条：自动生成的 wiki 页面质量参差，回滚和人工复核机制因此不是可选项。

接入面决定了你能省多少搬运工

知识库项目的实际工作量，一大半花在"文档怎么进来、更新了怎么办"。从版本记录看，WeKnora 在这块的积累是有节奏的：v0.3.6 加入飞书数据源自动同步和 ASR 音频处理，v0.4.0 加上 Notion 连接器和附件处理，v0.5.1 则有知识库批量管理和 workspace 级的 IM 频道总览。IM 侧还接过微信，OIDC 也在这个阶段落地。

对国内团队来说，飞书自动同步往往是"能不能真正跑起来"的分水岭：手工上传的知识库一定会腐烂。如果你的文档主力在语雀或 RSS 上，动手前建议先核对当前版本连接器列表，别按功能清单想当然。

另外，v0.5.1 里"会话搜索 + 用户级置顶"和统一的 Model / Web Search / MCP 设置卡片，看起来是小功能，但决定了多人协作时它到底像个工具还是个玩具。

检索策略：GraphRAG 是加分项，不是万能药

检索侧有几层需要分开看。官方材料里明确出现的是混合检索、多模态解析和基于 Neo4j 的 GraphRAG 支持（在 Helm Chart 中提供）。稀疏检索（BM25 一类）与稠密向量检索的组合、向量索引的具体实现和参数，属于版本迭代很快的部分——这类细节不适合照抄任何一篇评测，应当对照你实际要部署的那个版本的仓库文档和部署模板逐项确认。

GraphRAG 的取舍也要现实一点：图检索对多跳、关系型问题（"A 项目的负责人还负责哪些模块"）收益明显，但它需要额外的图数据库组件，抽取阶段也要额外 LLM 调用，等于在成本和运维上各加一层。如果业务问题大多落在单文档事实检索上，图能力大概率是过度设计。

部署形态与真正花钱的地方

从公开信息看，WeKnora 至少有三种落地路径：Docker 单机部署、面向 Kubernetes 的 Helm Chart（带 Neo4j GraphRAG 支持），以及 WeKnora Cloud 托管版（托管 LLM 与解析）。v0.5.1 提到的桌面 workspace 切换，说明它也在往个人工作台方向延伸。

成本结构通常是这样的：

解析成本：多模态文档解析是刚性开销，文档量越大越明显，云端托管方案在这里最省事。
推理成本：RAG 单轮可控，ReAct agent 的多步循环会显著放大，需要按任务类型设预算和超时（v0.5.1 已支持 per-agent LLM 超时）。
基础设施成本：要 GraphRAG 就得养图数据库；K8s 部署换来弹性，也换来运维人力。
模型选择：可接 Azure OpenAI 等云端模型，也能配合本地模型与 Ollama 相关能力，混合部署是常见折中。

安全上，版本记录里提到过 SSRF 安全 HTTP 客户端这类加固，但多租户隔离、权限模型和链路可观测性这种硬要求，建议在自己环境里做 PoC 实测，而不是只看功能列表——它们往往决定了这套东西能不能进生产。