"文档不该只是被检索，还应该被理解、被组织、被持续维护。"
这是"一天一个开源项目"系列的第 220 篇。今天的项目是 WeKnora。
大多数企业知识库产品到今天还停留在"上传文档 → 向量化 → 相似度检索 → 拼进 Prompt"这一套标准 RAG 流程。这套流程能回答简单问题，但遇到需要多步推理、跨文档综合、或者"这份文档到底讲了什么，帮我整理成一份能查阅的百科"这类需求时就露怯了。
WeKnora 是腾讯开源的答案。它不是又一个 RAG 框架，而是把三种能力叠在一起：快速问答用 RAG，复杂任务用 ReAct 智能体自主编排工具，长期知识沉淀用 Wiki 模式自动生成互联的知识图谱。它是微信对话开放平台的核心技术框架，已经在真实的企业场景里跑过一轮。
25.4k Stars，MIT 协议，Go 语言后端。
WeKnora 的三大核心能力：RAG 问答、ReAct 智能体、Wiki 模式
模块化流水线架构：文档解析 → 向量化 → 检索 → 推理
官方 MCP Server 的 29 个工具能做什么
企业级部署考量：多工作区 RBAC、安全加密、可观测性
可选：了解向量数据库（pgvector/Milvus 等）
WeKnora 官方定位是："一个开源的、基于 LLM 的知识框架，专为企业级文档理解、语义检索和自主推理而构建"。
它想解决的核心问题是：把零散的文档转化为可查询、具备推理能力、持续演进的知识资产。这三个形容词对应它的三大能力——可查询（RAG）、具备推理能力（ReAct 智能体）、持续演进（Wiki 模式的版本管理与自维护）。
关联产品：微信对话开放平台（WeChat Dialog Open Platform）的核心技术框架
传统企业知识库（纯 RAG）：
文档上传 → 切块 → 向量化 → 相似度检索 → 拼 Prompt → 回答
↑ 能回答"这份文档里提到了什么" 类简单问题
↑ 遇到"综合三份文档分析趋势"就吃力
↑ 知识库本身不会"整理自己"，永远是原始文档堆
WeKnora（三合一）：
简单查询 → RAG 快速问答（低延迟，够用）
复杂任务 → ReAct 智能体
├── 自主决定要不要检索
├── 调用 MCP 工具/网络搜索/沙箱执行代码
└── 多步推理后给出综合答案
长期沉淀 → Wiki 模式
├── 智能体把原始文档提炼成互联的 Markdown 知识库
├── 生成交互式知识图谱
└── 支持人工编辑、版本历史、一键回滚
员工手册、产品文档、技术规范集中管理，员工通过企业微信/飞书直接提问
接入 IM 渠道（Slack/Telegram/企业微信），把产品文档转化为自动应答知识库
ReAct 智能体调用网络搜索 + 内部文档检索 + 代码沙箱，完成"调研 + 分析 + 输出报告"的多步任务
Wiki 模式让文档知识库像百科一样自我更新和互联，而不是一堆孤立的 PDF
通过微信对话开放平台，非技术人员也能配置出可用的知识库问答系统
# 前置依赖：Docker、Docker Compose、Git
git clone https://github.com/Tencent/WeKnora.git
cd WeKnora
cp .env.example .env
docker compose pull
docker compose up -d
# 启动后访问 http://localhost
# 启用知识图谱（Neo4j）
docker compose --profile neo4j up -d
# 启用对象存储（MinIO）
docker compose --profile minio up -d
# 启用可观测追踪（Langfuse）
docker compose --profile langfuse up -d
# 启用全部功能
docker compose --profile full up -d
若使用本地 Ollama 模型，需先运行 ollama serve。升级时设置 .env 中的 WEKNORA_VERSION，再执行 docker compose pull && docker compose up -d。
不同于大多数问答系统"每次对话从零开始"，WeKnora 维护跨会话的记忆维度：
WeKnora 提供官方 MCP Server，把自身能力暴露为标准 MCP 工具，让 Claude Code、Cursor 等 AI 工具可以直接调用 WeKnora 的知识库能力——检索、写入、Wiki 编辑等操作都可以通过 MCP 完成。
PDF、Word、图片、Excel、XMind 等 10+ 格式
覆盖国际主流（OpenAI、Azure OpenAI、Anthropic Claude、Gemini）和国内主流（DeepSeek、通义千问、智谱、混元）模型，还支持 LiteLLM 和 Ollama 作为统一接入层。
WeKnora 的架构设计强调"每个环节都可替换"：
文档解析（Document Parsing）
↓ 支持 PDF/Word/Excel/图片/XMind 等格式解析器
向量化（Vectorization）
↓ 支持多种 Embedding 模型
检索（Retrieval）
↓ 支持 PostgreSQL(pgvector)/Elasticsearch/OpenSearch/Milvus/Weaviate/Qdrant
推理（LLM Inference）
↓ 支持 20+ LLM 提供商，通过 LiteLLM 统一接入
这种设计的好处是企业可以根据现有基础设施做替换——已经在用 Milvus 的团队不需要迁移向量库，已经有私有化部署的模型服务也可以直接接入。这也是"数据主权"承诺的技术基础：整套流水线可以完全在私有环境内闭环运行，不需要任何数据出企业内网。
纯 RAG 模式的局限：
检索 → 拼 Prompt → 生成
↑ 延迟低，成本低，但推理能力弱
↑ 适合"这份文档里有没有提到 X" 这类问题
纯 Agent 模式的问题：
每次都走完整的推理链
↑ 简单问题也要多轮工具调用，延迟高、成本高
↑ 用户体感"变慢了"
WeKnora 的分层设计：
简单查询 → 直接走 RAG（快）
复杂查询 → 升级到 ReAct（准）
知识沉淀 → 异步走 Wiki 模式（不影响实时问答）
这种"按需升级复杂度"的设计思路，本质上是在延迟/成本和能力之间做动态权衡——不是所有问题都需要智能体级别的推理能力。
Wiki 模式是 WeKnora 相对独特的能力。大多数 RAG 系统把文档当作检索的"原材料"，检索完就完了，文档本身不会变化。
WeKnora 的 Wiki 模式反过来：智能体主动阅读原始文档，提炼出结构化的 Markdown 页面，页面之间互相链接，形成一个类似维基百科的知识网络。这个网络：
有完整的版本历史（类似 Git 的 diff 对比）
这解决了一个 RAG 系统的常见痛点：原始文档质量差（结构混乱、信息重复、过时内容混杂）时，检索出来的内容质量也差。Wiki 模式相当于让 AI 先做一轮"文档整理"，之后的问答建立在整理过的知识之上。
WeKnora 的差异化在于 Wiki 模式和 ReAct 智能体的原生集成，以及对国内 LLM 生态（DeepSeek、通义千问、混元）和企业协作工具（飞书、钉钉、企业微信）的原生支持——这对国内企业落地是明显优势。
🌟 GitHub：github.com/Tencent/WeK…
🌐 官网：weknora.weixin.qq.com
Model Context Protocol — WeKnora 官方 MCP Server 所依托的标准协议
Langfuse — WeKnora 集成的可观测追踪工具
pgvector — WeKnora 支持的向量检索方案之一
三合一能力矩阵：RAG 应对简单查询，ReAct 智能体处理复杂任务，Wiki 模式沉淀长期知识——按需升级复杂度
Wiki 模式是差异化亮点：把原始文档提炼成自维护、可回滚的互联知识库，而不是让文档永远保持"原始状态"
模块化流水线：解析、向量化、检索、推理每一环都可替换，适配企业已有基础设施
官方 MCP Server：29 个工具让 Claude Code 等 AI 工具直接调用 WeKnora 能力
国内生态原生支持：DeepSeek/通义千问/混元 + 飞书/钉钉/企业微信，本土化程度高
企业 IT/知识管理团队：需要把分散文档转化为可维护的知识资产，而不只是"能搜索"
国内 AI 应用开发者：需要原生对接国产大模型和企业协作工具的知识框架
构建复杂 Agent 应用的团队：需要 ReAct 级别的多步推理，而不满足于简单 RAG
重视数据主权的组织：整套流水线可私有化部署，无需数据出内网
WeKnora 想解决的问题是：知识库不该只是一堆能被检索的文档，它应该是一个会自己整理、会推理、会持续进化的活的知识系统。
欢迎访问 PrimeSkills —— 一个精心策划的 AI Agent 与技能市场，所有内容均经过真实企业级工作流验证。没有噱头，只有真正有效的东西。
