腾讯 WeKnora:把企业文档接成 RAG、Agent 和可回滚 Wiki 的开源知识平台

摘要：WeKnora 把企业文档放进同一套知识底座，让 RAG 负责带引用的问答，Agent 负责搜索、读文档和调用工具，Wiki 负责把资料整理成可编辑、可追溯、可回滚的知识页面。它适合想把“知识库”继续接到业务流程里的团队，也适合评估私有化部署和开源 Agent 平台的人。

如果你搭过企业知识库，通常会遇到三个断点：检索能回答，却不一定能完成任务；Agent 能调用工具，却和文档检索各用一套数据；资料更新后，旧答案和旧页面没人维护。腾讯开源的 WeKnora 把这三件事放到一个知识底座里：RAG 负责可引用问答，Agent 负责多步工作，Wiki 负责把资料整理成可回看、可回滚的页面。它更适合已经有文档资产、又想把知识接入内部流程的团队。

先看懂：它解决的不是“再做一个聊天框”

WeKnora 官方仓库 的一句话定位很清楚：把原始文档变成可查询的 RAG、能自主推理的 Agent，以及能持续维护的 Wiki。这里的重点不是功能数量，而是三种模式共用一套知识库。相同的文档可以先用来回答问题，再被 Agent 读进去完成任务，最后沉淀成带关系和版本记录的页面。

这让它和单纯的 FAQ 机器人拉开了距离。对于技术文档、制度流程、产品资料、研究报告和客服知识，读者真正需要的往往不是一句“答案”，而是答案来自哪里、下一步能做什么、资料变化后谁来维护。WeKnora 的产品结构正好围绕这三个问题展开。

这张图里的三种模式不是并排摆放的功能卡，而是同一份知识的三种用法：RAG 给出可核对的答案，Agent 把检索结果带进多步任务，Wiki 把实体、关系和页面继续整理下去。

RAG、Agent、Wiki 分别做什么

RAG 解决的是“回答能不能查回原文”。README 提到混合检索、多模态解析和来源引用，回答可以跳回原始文档中的证据位置。对企业场景来说，引用比一句流畅的总结更重要：它让读者有机会核对版本、上下文和适用范围。

Agent 解决的是“查到之后能不能继续做事”。它可以规划多步任务，搜索和阅读知识库，再调用工具与 Skills；官方产品导览还列出了沙箱、浏览器、MCP 工具和跨会话记忆。也就是说，知识库不再只是聊天窗口背后的检索接口，而是 Agent 执行动作时可以反复调用的上下文。

Wiki 解决的是“资料能不能继续被整理”。WeKnora 会从文档中提取人物、产品和概念，生成带来源引用的页面，并用知识图谱呈现关系。页面可以直接编辑，变更可以查看差异并回滚。这个设计适合那些会持续增删、修订、合并资料的团队，尤其是产品、研发和运营知识。

一条从资料到知识的工作链

官方 README 列出了飞书 Wiki、飞书云盘、Confluence、GitLab、腾讯 IMA、Notion、语雀、钉钉文档、Seafile 和 RSS 等数据源，也支持 PDF、Word、图片、Excel、XMind 等十多种文档格式。模型侧提供多家厂商和 Ollama，向量库、存储后端也可以替换，部署可以落在本地或私有云。

这条链的价值在于，资料更新后不必重新建立一套孤立的“问答数据”。文档先被解析和索引，RAG 用它回答并给出证据，Agent 用它完成任务，Wiki 再把变化整理成页面。需要追查时，可以沿着引用、关系和版本记录回到原始内容。

v0.9.0：把“能用”推进到“可管理”

官方更新记录显示，v0.9.0 于 2026 年 10 月 29 日发布，新增能力集中在运行管理：WeKnora assistant 可以基于当前页面创建 Agent、安排任务和管理知识；多 Agent 协作可以把独立子任务分派出去；自动化支持一次性或周期性执行，并保留历史结果和审批通知；执行权限则区分只读、变更前确认和自动写入，还能限制会话与自动化的授权范围。

这组更新说明了项目的方向：它不满足于“模型能不能回答”，而是继续处理任务如何运行、权限如何收敛、结果如何追踪。对企业来说，这些控制面往往比再增加一个模型供应商更决定能不能上线。

怎么开始，谁适合用

最短的自托管路径仍然是 Docker Compose：

git clone https://github.com/Tencent/WeKnora.git
cd WeKnora
cp .env.example .env
docker compose pull
docker compose up -d

启动后打开本地 Web UI，按向导配置模型、存储和网络；需要知识图谱、对象存储或 Langfuse 时，再按需启用对应 profile。生产环境要把服务放在内网或私有网络，配置防火墙和访问控制，并持续更新安全补丁。

我的判断是，WeKnora 更像“知识操作系统”的候选，而不是一个开箱即用的答案机器。已经有大量内部资料、希望把检索接到 Agent 工作流、又需要权限和审计的团队，可以重点评估它；只有少量 FAQ、没有多步任务和知识维护需求的项目，简单的 RAG 服务可能更省事。

真正值得观察的是三件事：引用能否稳定定位到正确版本，Agent 的工具权限能否收敛在明确范围内，Wiki 的自动整理是否真的减少维护成本。WeKnora 把这三件事放进同一套开源系统里，剩下的判断就取决于你的资料质量、部署能力和治理要求