WeKnora：腾讯开源的企业级 RAG 知识库框架
大模型进入企业场景后，一个绕不开的问题是：如何让模型真正理解企业自己的知识？
通用大模型知道很多事情，但它并不知道一家公司的产品文档、内部制度、技术方案和业务数据。更现实的问题是，这些知识通常还散落在 PDF、Word、PPT、Excel、网页以及各种知识管理平台中，并且一直处于变化之中。
RAG 是目前解决这个问题最常见的技术路线。它的基本思路并不复杂：先把企业文档处理成可以检索的知识，当用户提出问题时，从知识库中找到相关内容，再把这些内容作为上下文交给大模型生成答案。
但从一个 RAG Demo 到真正可以使用的企业知识系统，中间还有很长的距离。
不同格式的文档如何解析？几百页的 PDF 如何异步处理？文档应该怎样切片？只做向量检索是否足够？知识库如何更新？多个用户之间如何进行权限隔离？如果用户提出的不是一个简单问题，而是需要查询知识、调用工具甚至执行代码的复杂任务，又应该怎么办？
腾讯开源的 WeKnora，就是围绕这些问题构建的一套知识库框架。
从文档开始构建企业知识库
WeKnora 最基础的能力，是把企业中原本分散的非结构化资料转换成大模型能够使用的知识。
它支持 PDF、Word、PPT、Excel、Markdown、HTML、图片等多种类型的内容，也能够从飞书、GitLab、Notion、语雀、钉钉、RSS 等外部数据源同步资料。这些内容进入系统之后，会经过解析、切片、向量化和索引等处理，最终进入知识库。
这听起来和常见的 RAG 系统没有太大区别，但真正值得关注的是背后的工程实现。
例如，一份大型 PDF 的处理可能涉及文本解析、OCR、图片提取、Chunk 切分、Embedding，甚至摘要和知识图谱生成。整个过程可能持续几十秒甚至更长，因此不适合直接放在一次 HTTP 请求中同步执行。
WeKnora 为此设计了一套异步文档处理 Pipeline。用户上传文件之后，系统首先创建知识记录和处理任务，再通过 Redis 和 Asynq 将任务交给 Worker。Worker 调用文档解析服务完成内容提取，之后继续执行Chunking、Embedding 和索引构建。只有这些步骤全部完成之后，这份文档才真正成为可以被检索的知识。
在技术实现上，WeKnora 也做了比较明确的职责划分。系统的核心后端采用 Go，负责 API、业务逻辑、知识库、RAG、Agent、权限和任务调度；文档解析则单独使用 Python 实现 docreader 服务，并通过 gRPC 与主服务通信。
这种设计并不难理解。Go 更适合作为长期运行的业务服务，而 Python 在 PDF、Office、OCR 和 AI 文档处理方面拥有更丰富的生态。WeKnora 没有为了统一语言而强行选择一种技术，而是让两者分别承担更合适的工作。
经过这一整套处理之后，原本只是存储在硬盘上的文件，才真正变成了一套能够被机器检索和理解的知识。
RAG 的关键不只是向量数据库
有了知识库，接下来的问题是如何把正确的知识找出来。
很多 RAG 入门项目的实现方式非常直接：把用户的问题转换成向量，在向量数据库中寻找最相似的几个 Chunk，然后把结果交给大模型。
这种方法能够快速构建一个 Demo，但企业知识的检索要复杂得多。
比如用户查询一个具体的错误码、API 名称或者产品型号时，语义相似并不一定比关键词匹配更加可靠；而面对一个涉及多个实体和关系的问题时，单纯依靠某几个文本 Chunk，同样可能无法提供足够完整的上下文。
因此，WeKnora 没有把检索能力局限在 Vector Search 上，而是提供了 BM25、Dense Vector、混合检索、GraphRAG、父子分块以及 Rerank 等能力。
它背后的思路是：不要期待一种检索方式解决所有问题，而是通过不同召回方式找到候选知识，再对结果进行重新排序。
这也解释了为什么 WeKnora 默认并不要求部署一个独立的专业向量数据库。系统可以基于 PostgreSQL 同时处理关系数据、BM25 和向量检索，在部署规模较小时尽可能减少基础设施复杂度；如果业务规模扩大，也可以继续接入 Milvus、Qdrant、Weaviate、Elasticsearch、OpenSearch 等检索后端。
从这里可以看出，WeKnora 对 RAG 的理解已经不只是接一个向量数据库，而是把检索本身作为一个独立的工程体系。
文档解析决定了知识能否正确进入系统，Chunking 决定了知识如何被组织，Embedding 和索引决定了知识如何被召回，Rerank 又进一步影响最终送给大模型的上下文。任何一个环节出现问题，都可能最终表现为大模型回答错了。
这也是生产级 RAG 和简单知识库 Demo 之间很重要的区别。
从回答问题到完成任务
如果 WeKnora 只做到这里，它仍然可以被归类为一个比较完整的企业 RAG 系统。但这个项目后续的发展方向已经明显超出了传统知识问答。
原因在于，现实中的用户需求往往不是单纯的帮我查一段资料。
例如用户可能会提出这样的需求：根据公司的差旅报销制度，计算这次出差可以报销多少钱，并生成一份 Excel。
这里实际上包含了多个步骤。系统首先需要从知识库找到公司的报销制度，然后理解其中的规则，再结合用户提供的数据完成计算，最后生成一个 Excel 文件。
RAG 可以解决第一步，却很难独立完成后面的工作。
因此 WeKnora 在知识检索之上加入了 ReAct Agent，并逐渐引入 MCP、Skill、Sandbox 和长期记忆等能力。
在这种模式下，知识库不再是整个系统的终点，而变成了 Agent 可以使用的一种能力。Agent 可以根据当前任务决定是否查询知识库，也可以通过 MCP 调用外部工具，通过 Skill 执行特定工作，或者进入 Sandbox 执行代码和处理文件。
MCP 的加入尤其值得关注。一方面，WeKnora 可以作为 MCP Client，让自己的 Agent 连接外部工具和业务系统；另一方面，它本身也可以作为 MCP Server，把知识检索能力提供给其他 AI 应用。这意味着 WeKnora 中沉淀的知识并不一定只能通过自己的 Web 页面使用，也可以成为其他 Agent 的知识来源。
Sandbox 则进一步扩大了 Agent 的执行边界。当一个任务需要运行 Python、处理文件、分析数据或者生成新的文件时，Agent 可以在隔离环境中完成这些操作。
于是整个系统处理问题的方式发生了变化。
传统 RAG 解决的是 Question → Answer：用户提出问题，系统找到知识，然后生成答案。
Agent 解决的则更接近 Task → Reason → Action → Result：用户提出任务，系统查询知识、选择工具、执行操作，最后交付结果。
从 RAG 到 Agent 的这一步，也是理解现在 WeKnora 定位变化的关键。
WeKnora 不只是一个知识库
如果从整个仓库的架构重新审视 WeKnora，会发现它实际上已经形成了三个相互连接的部分。
第一部分是知识管理。文档、Chunk、知识库、数据源、Wiki 和知识图谱都属于这一层，它解决的是企业知识如何进入系统、如何组织以及如何持续维护的问题。
第二部分是 AI Runtime。RAG、Retriever、Rerank、LLM、Agent、MCP、Skill、Memory 和 Sandbox 都属于这一层，它解决的是大模型如何使用这些知识，并进一步完成复杂任务的问题。
第三部分则是平台基础设施。WeKnora 已经包含多租户、RBAC、API Key、任务队列、Worker、对象存储、可观测性以及 Docker、Kubernetes 等部署能力。这些功能可能没有 RAG 和 Agent 那么吸引眼球，却恰恰决定了一套 AI 系统能否从 Demo 走向实际使用。
这三部分组合起来，也就构成了今天的 WeKnora。
从技术栈来看，它的核心后端使用 Go，文档解析使用 Python + gRPC，前端采用 Vue 3；PostgreSQL 承担主要的数据存储和默认检索能力，Redis + Asynq 负责异步任务，同时又可以根据实际需求扩展不同的向量数据库、对象存储和模型服务。
因此，如果只把 WeKnora 理解成一个上传 PDF，然后和文档聊天的项目，会忽略这个仓库更有价值的部分。
它的发展路线其实相当清晰：最初的问题是如何让大模型使用企业知识，于是需要文档解析和 RAG；随着知识规模扩大，需要更完整的混合检索和知识管理；当用户希望 AI 不只是回答问题，而是完成任务时，又进一步需要 Agent、MCP、Skill 和 Sandbox；当系统真正进入多人使用场景，又必须补充权限、多租户、任务调度、存储和可观测性。
最终，这些能力共同指向了一个更完整的目标：
把企业中原本散落的文档和数据，转化为 AI 可以持续检索、理解和使用的知识基础设施。
这也是 WeKnora 相比一个普通 RAG Demo 更值得关注的地方。对于想了解 RAG 如何工程化、企业知识库如何设计，以及 RAG 如何进一步与 Agent 结合的开发者来说，这个仓库提供了一个比较完整的参考实现。
收录于 FunTester 原创专题：AI ，测试有点东西
相关阅读：构建 AI Agent，先设计上下文系统 · MCP：引领 AI 测试新时代 · Anthropic 解法：记忆分层，让 Agent 越用越聪明 · claude-mem：让 Agent 上下文更可控 · Long-Running Agent 落地