对 PandaWiki 的实现与技术栈的深度拆解 + 类似开源项目对比与选型建议

用 Go + Echo + PostgreSQL + Redis 搭了一个稳健的企业文档底座，再用 RAGLite + ModelKit 把大模型和向量检索封装在清晰的 SDK/服务层上，最后用 React + Tiptap 提供了一套面向非技术用户可直接上手的 Wiki 体验，并把这整套能力通过机器人/挂件的方式延伸到 IM 和网页中。

leovum

568人浏览 · 2026-02-07 12:01:36

leovum · 2026-02-07 12:01:36 发布

一、PandaWiki 是什么（从产品形态看实现目标）

raglite-go-sdk 能力简述[26]

结合 PandaWiki 功能来理解 RAG 流程

DeepWiki-Open（面向代码仓库的 AI Wiki）[32]

Docmost（开源团队 Wiki / Confluence 替代品）[39]

Wiki.js（成熟的开源 Wiki）[46]

RAG-WIKI（基于 Wikipedia 做 RAG 知识库）[52]

八、如果你要“照着 PandaWiki 打造一个类似系统”，关键技术点是什么？

九、选型建议：在什么场景下用哪个？

十、总结一句话

References

一、PandaWiki 是什么（从产品形态看实现目标）

PandaWiki 的定位可以概括为：

“AI 大模型驱动的开源知识库搭建系统”——帮你快速搭建带有 AI 创作、AI 问答、AI 搜索能力的产品文档/技术文档/FAQ/博客系统。[1][2]

核心特征：

每个「知识库」对应一个独立的 Wiki 站点（用户访问前台）
有独立的控制台（管理后台）管理知识库与内容
支持：
- AI 辅助写作（自动生成或润色文档）
- AI 问答（基于知识库内容的对话）
- AI 搜索（自然语言/语义搜索）
支持多种内容导入：URL、Sitemap、RSS、离线文件等[1]
支持作为网页挂件、聊天机器人（钉钉/飞书/企业微信）嵌入外部系统[1]

从这些能力倒推，它本质上是一个：

「传统企业文档平台 + RAG 知识库 + 大模型服务编排」的组合系统

二、整体架构拆解

仓库结构与分层

仓库顶层结构（节选）[2][18]：

backend/：后端服务（Go）
web/：前端（Node.js / React，monorepo）
sdk/：SDK（目前主要是 RAG 相关 sdk/rag）
其他：images/（图片）、规范文件（LICENSE、CONTRIBUTING、SECURITY 等）

从 PROJECT_STRUCTURE.md 可以看出这是一个典型的前后端分离 + SDK 的架构[2]：

后端：REST / GraphQL API + 业务逻辑 + 数据层
前端：
- web/admin：控制台管理界面
- web/app：面向访客的 Wiki 站点
SDK：
- sdk/rag：封装对内部 RAG 服务的访问（或对 raglite 服务的访问）

后端逻辑分层

backend 下的结构[18]：

api/：接口层（控制器）
handler/：HTTP handler
domain/、usecase/：业务域与用例层（DDD 风格）
repo/、store/：数据仓储与底层存储
mq/：消息队列整合
migration/：数据库迁移
telemetry/：监控与埋点
middleware/：HTTP 中间件
cmd/：可执行程序入口（cmd/api, cmd/migrate 等）
config/、utils/、pkg/：配置、工具库等

从 Dockerfile 可以看到构建了两个可执行文件[28]：

/app/panda-wiki-api：主 API 服务
/app/panda-wiki-migrate：启动时先执行数据库迁移，再启动 API

这属于较为标准的整洁架构 + DDD 分层，有利于后续扩展，如：

增加新的知识库类型
更换存储引擎
替换 AI 提供方 / 模型

三、后端技术栈与关键模块

基础技术栈（后端）

根据 backend/go.mod 关键依赖[30]：

语言 & 运行时
- Go 1.24.3（新版本 Go，性能与并发优势明显）
Web / API 框架
- github.com/labstack/echo/v4：Echo 作为主 Web 框架
- github.com/swaggo/echo-swagger + github.com/swaggo/swag：自动生成 Swagger 文档
数据库与持久化
- gorm.io/gorm + gorm.io/driver/postgres：PostgreSQL ORM
- github.com/lib/pq：Pg 驱动
- migration/ + panda-wiki-migrate：负责 schema 迁移
缓存与会话
- github.com/redis/go-redis/v9：Redis 客户端
- github.com/boj/redistore、github.com/gorilla/sessions：会话管理
消息队列 & 异步处理
- github.com/nats-io/nats.go：NATS 作为 MQ
- github.com/robfig/cron/v3：定时任务
配置、日志与监控
- github.com/spf13/viper：配置管理
- go.opentelemetry.io/otel 及相关 exporter：分布式追踪与指标
- Sentry 集成：github.com/getsentry/sentry-go + echo 中间件
身份认证 & 权限
- github.com/golang-jwt/jwt/v5：JWT
- github.com/labstack/echo-jwt/v4：与 Echo 集成
- github.com/go-ldap/ldap/v3：LDAP 支持（企业内部用户目录集成）
Markdown / 文档处理
- github.com/gomarkdown/markdown
- github.com/yuin/goldmark
- github.com/russross/blackfriday/v2
- github.com/JohannesKaufmann/html-to-markdown/v2：HTML 转 Markdown
- github.com/microcosm-cc/bluemonday：HTML 消毒/安全过滤

小结：

后端非常偏向“企业级 Go 服务”典型栈：Echo + GORM + Redis + NATS + OpenTelemetry + Sentry + JWT。

AI / 大模型 & RAG 相关

在 backend/go.mod 中有三个非常关键的依赖[30]：

github.com/chaitin/ModelKit/v2 v2.8.1
github.com/chaitin/raglite-go-sdk v0.2.1
github.com/cloudwego/eino 及 deepseek / gemini / ollama 等 Model 组件

这反映出 PandaWiki 的 AI 体系大致是：

ModelKit：统一管理不同大模型提供方（OpenAI、DeepSeek、Gemini 等）的调用配置与负载
raglite-go-sdk：接入独立的 RAG 服务（RAGLite），负责：
1. 模型管理（LLM 配置）
2. 数据集管理（知识库切分、配置）
3. 文档管理（上传、更新、删除、批量删）
4. 检索（Retrieve）
5. 问答（Ask）
6. 文本生成（Generate）[26]
cloudwego/eino：进一步做多模型/多后端编排，可能用于复合 Agent 流程

也就是说：PandaWiki 自己不是直接做低层向量检索，而是作为「业务编排层」，通过 raglite-go-sdk 调用后端 RAGLite 服务。

raglite-go-sdk 能力简述[26]

SDK 的典型调用模式：

初始化：

client, _ := sdk.NewClient("http://raglite:8080", sdk.WithAPIKey("xxx"))

管理模型（Create/List/Upsert/Check）
创建数据集：

CreateDatasetRequest{ Name: "技术文档", Config: DatasetConfig{ChunkSize: 512, ChunkOverlap: 50}, }

上传文档（支持 file、字符串形式内容），自动：
- 存文件（如 MinIO）
- 写关系型 DB（PostgreSQL）
- 写向量索引（pgvector/其他）
搜索 / 问答：

// 语义检索 RetrieveRequest{ Query: "如何部署 PandaWiki", DatasetID: datasetID, TopK: 10, } // 问答（RAG） QARequest{ Query: "如何配置 AI 模型？", DatasetID: datasetID, TopK: 5, }

结合 PandaWiki 功能来理解 RAG 流程

用户在控制台上传/导入文档 → 调用 raglite 文档接口，切分 + 向量化入库
前台「AI 问答」或「AI 搜索」：
- 将用户问题发给后端 → raglite 检索相关片段
- 把检索结果 + prompt 一起喂给配置好的大模型 → 生成答案/重写内容
配置 AI 模型时支持：
- 一键自动配置（走官方推荐，比如百智云模型广场）[1]
- 手动配置（键入 API Key、Base URL、模型名等）

钉钉 / 飞书 / 企业微信等集成

从依赖可以看到[30]：

钉钉：
- github.com/alibabacloud-go/dingtalk
- github.com/open-dingtalk/dingtalk-stream-sdk-go
飞书：
- github.com/larksuite/oapi-sdk-go/v3
企业微信：
- github.com/sbzhu/weworkapi_golang
- github.com/silenceper/wechat/v2

这些被用于「聊天机器人集成」场景：

在飞书/钉钉群里 @ 机器人 → 问答转发到 PandaWiki → 调用 RAG → 回复群消息
或用于工单/FAQ 的自动化答复

四、前端技术栈与实现思路

前端整体结构

web/ 目录为一个 PNPM + monorepo[21]：

.husky/：git hooks（代码检查、格式化等）
admin/：管理后台（控制台）
app/：前台 Wiki 站点
packages/：共享 UI、主题、icon 等包（@panda-wiki/ui、@panda-wiki/themes 等）

前端核心技术栈

从 web/package.json 提取的依赖[29]：

UI 框架
- react@19.x
- react-dom@19.x
UI 组件库
- @mui/material + @mui/icons-material：Material UI
- 内部组件库：@ctzhian/ui + @panda-wiki/ui + @panda-wiki/themes
- 样式：@emotion/react + @emotion/styled
编辑器
- @ctzhian/tiptap：基于 Tiptap 的富文本/Markdown 编辑器，适合文档场景
表单 & 工具
- react-hook-form：表单处理
- dayjs：时间处理

开发工具链：

TypeScript 5.9
ESLint 9
Prettier 3
Husky + lint-staged
Pnpm workspace

前端实现重点

结合产品描述[1]，前端至少要做几件事：

控制台（admin）：
1. 知识库管理：创建/删除/配置
2. 文档管理：编辑器（Tiptap）+ 文档结构（章节/目录）
3. AI 配置界面：录入 API Key、模型、RAG 参数等
4. 数据导入界面：URL/Sitemap/RSS/文件等
用户端（app）：
1. SEO 友好的 Wiki 渲染（Markdown/HTML）
2. AI 问答入口（浮窗、侧边栏、嵌入式对话）
3. 语义搜索/全文搜索界面
嵌入与集成：
1. Web 挂件模式（比如嵌入到产品官网，提供“智能问答”悬浮按钮）
2. 对应有一套轻量的 JS SDK 或 iframe 模式（结合 sdk / 前端包）

五、SDK / RAG 客户端层

sdk/rag 目录包含：

client.go：封装 HTTP 客户端[24]
dataset.go、document.go、retrieval.go、models.go 等：对 raglite API 的 Go 封装[23]
model_config.go：与模型配置相关接口

其核心职责：

向 raglite 服务发起 HTTP 请求，简化错误处理与统一响应格式（CommonResponse、Code、Message 等[24]）
封装常见操作：
- 创建/更新模型配置
- 创建数据集、更新配置、查询统计
- 上传文档、更新文档元数据、批量删除
- 检索/问答/生成接口调用

在 PandaWiki 内部，后端业务逻辑层用的是这些 Go SDK 来访问 RAG 服务，而不是直接用 HTTP client，这样解耦和可维护性更好。

六、部署与运维模式

基本要求

一台 Linux 服务器
Docker 20.x+ 环境[1][19]
使用 root 权限执行一键安装脚本：

bash -c "$(curl -fsSLk https://release.baizhi.cloud/panda-wiki/manager.sh)"

脚本会：

拉取相关 Docker 镜像（panda-wiki 后端、前端、raglite、数据库等）
启动容器
输出访问地址、默认账号（admin）和初始密码[1]

启动后流程

首次登录控制台 → 引导「配置 AI 模型」：
1. 一键接入（推荐配合「百智云模型广场」，注册送额度）[1][19]
2. 手动填写模型配置
创建第一个知识库（会自动生成对应 Wiki 站点）
导入/编辑文档，系统开始构建 RAG 索引
配置集成渠道：钉钉/飞书/企业微信机器人、网页挂件等

七、与类似开源项目的对比

这里重点对比几类“知识库/ Wiki + AI”方向的项目：

DeepWiki-Open（面向代码仓库的 AI Wiki）[32]

技术栈：

后端：Python + FastAPI
前端：Next.js (React)
AI & RAG：
- LLamaIndex + LangChain
- 多模型提供方：OpenAI、Gemini、Ollama、OpenRouter、Bedrock 等
数据：
- 使用本地目录 ~/.adalflow 存储向量、缓存和索引
部署：
- Docker + docker-compose
- 或本地虚拟环境 + Poetry

特点：

强项是：自动把 GitHub/GitLab/BitBucket 仓库变成可交互的文档 Wiki
很适合作为「代码文档 / 开发者文档」自动生成工具
RAG 侧可插拔性强（LangChain/LLamaIndex 生态），适合二次开发

和 PandaWiki 对比：

PandaWiki：
- 更偏通用知识库 + 企业知识管理
- 深度集成企业 IM（钉钉/飞书/企微）
- Go + RAGLite 架构，更适合高性能、生产环境
DeepWiki：
- 更偏工程师向，面向代码仓库
- Python 生态、LangChain 易于扩展创新方案

Docmost（开源团队 Wiki / Confluence 替代品）[39]

技术栈：

Nx monorepo + PNPM
Node.js / TypeScript
前后端拆分：apps/server + apps/client
使用 Pino 做 JSON 日志
使用 Tiptap 富文本编辑器扩展
Algolia 做全文搜索
图形工具：Draw.io / Excalidraw / Mermaid
License：AGPL-3.0，企业功能在 EE 模块

特点：

更像是「开源版 Confluence/Notion」
强调协作编辑、文档层级、实时协作
有企业版模块（EE）

和 PandaWiki 对比：

Docmost：
- 文档协作体验强，偏通用 Office/Confluence 场景
- AI 只是附加（目前更多是生态/扩展方向）
PandaWiki：
- 从一开始就是「AI-first」设计：AI 创作/问答/搜索是核心卖点
- 知识库 = AI 知识助手的数据底座

Wiki.js（成熟的开源 Wiki）[46]

技术栈：

Node.js + JavaScript
Docker 部署
丰富的扩展与存储后端（Git、数据库等）

特点：

传统 Wiki + 强扩展性
AI 相关能力更多是靠插件/社区方案（如 ChatGPT 集成）

对比：

Wiki.js：对「内容管理」历史悠久，稳定、扩展性强，但 AI 不是核心
PandaWiki：AI 是一等公民，知识库就是为 RAG 服务而设计

RAG-WIKI（基于 Wikipedia 做 RAG 知识库）[52]

技术栈：

Python + Streamlit （UI）
LLamaIndex + LangChain（RAG）
数据：Wikipedia dump + WikiExtractor 清洗

定位：

RAG 教学 demo / 实验项目
强调「用 Wikipedia 全库 + RAG 做问答」

对比：

更适合学习 RAG 概念、快速 PoC，而非直接生产部署
PandaWiki 则面向正式部署、一般用户与企业用户

八、如果你要“照着 PandaWiki 打造一个类似系统”，关键技术点是什么？

从工程实现角度，总结 PandaWiki 的几个关键“可借鉴设计”：

职责清晰的三层：业务后端 / RAG 服务 / 前端
1. 后端只负责：
  - 用户、权限、多知识库、多站点
  - 文档元数据 & 状态管理
  - 与 RAG 服务编排（调用 SDK）
2. RAG 服务（如 RAGLite）独立：
  - 文档切分、向量存储、检索、问答
3. 前端聚焦在编辑体验与 AI 交互 UI（编辑器 + ChatWidget）
RAG 层使用 SDK 封装，而不是在业务层手写 HTTP 调用
1. PandaWiki 用 sdk/rag 做了一层 Go SDK 封装，再由 backend 调用
2. 好处：
  - 可以方便替换实现（比如未来不再用 RAGLite，改用别的向量服务）
  - 业务代码更简洁
先把“文档体验”做好，再上 AI
1. PandaWiki 用 Tiptap 打底，Markdown/HTML 双向支持，支持导出 PDF/Word 等
2. 即使关掉 AI，它也是个可用的 Wiki 系统
3. 这是和很多「只做聊天界面」的知识库工具的差异
企业集成优先：LDAP、IM 机器人、Webhook
1. 丰富的第三方集成（钉钉/飞书/企微）
2. 这部分在未来价值会远大于“前端 UI 有多花哨”，值得优先设计接口
运维体验：一键脚本 + 多容器编排
1. 使用脚本包裹 docker-compose（内部细节对用户透明）
2. 初次安装时自动提示：
  - 是否一键配置 AI 模型
  - 是否导入 Demo 知识库

九、选型建议：在什么场景下用哪个？

希望有「开箱即用的 AI 文档 + FAQ 系统」，并计划长期运维
- 优先考虑：PandaWiki
- 目标场景：企业产品文档、技术文档、售后 FAQ、对外知识中心
重点是「为代码仓库生成智能文档 + 项目 Wiki」
- 使用：DeepWiki-Open
重点是「团队内部协作文档 + 替代 Confluence/Notion」
- 使用：Docmost、Wiki.js
- 再叠加自己的 RAG 服务或插件来做 AI
要研究/教学 RAG + Wikipedia 全库
- 使用：RAG-WIKI 类项目做实验，不适合作为最终产品

十、总结一句话

用 Go + Echo + PostgreSQL + Redis 搭了一个稳健的企业文档底座，再用 RAGLite + ModelKit 把大模型和向量检索封装在清晰的 SDK/服务层上，最后用 React + Tiptap 提供了一套面向非技术用户可直接上手的 Wiki 体验，并把这整套能力通过机器人/挂件的方式延伸到 IM 和网页中。