目录

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

二、整体架构拆解

仓库结构与分层

后端逻辑分层

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

基础技术栈（后端）

小结：

AI / 大模型 & RAG 相关

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

结合 PandaWiki 功能来理解 RAG 流程

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

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

前端整体结构

前端核心技术栈

前端实现重点

五、SDK / 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 知识库 + 大模型服务编排」的组合系统

二、整体架构拆解

  1. 仓库结构与分层

仓库顶层结构（节选）[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 服务的访问）

  1. 后端逻辑分层

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 提供方 / 模型

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

  1. 基础技术栈（后端）

根据 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。

  1. 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 体系大致是：

  1. ModelKit：统一管理不同大模型提供方（OpenAI、DeepSeek、Gemini 等）的调用配置与负载

  2. raglite-go-sdk：接入独立的 RAG 服务（RAGLite），负责：

    1. 模型管理（LLM 配置）

    2. 数据集管理（知识库切分、配置）

    3. 文档管理（上传、更新、删除、批量删）

    4. 检索（Retrieve）

    5. 问答（Ask）

    6. 文本生成（Generate）[26]

  3. 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、模型名等）

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

从依赖可以看到[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 的自动化答复

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

  1. 前端整体结构

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

  • .husky/：git hooks（代码检查、格式化等）

  • admin/：管理后台（控制台）

  • app/：前台 Wiki 站点

  • packages/：共享 UI、主题、icon 等包（@panda-wiki/ui、@panda-wiki/themes 等）

  1. 前端核心技术栈

从 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. 前端实现重点

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

  1. 控制台（admin）：

    1. 知识库管理：创建/删除/配置

    2. 文档管理：编辑器（Tiptap）+ 文档结构（章节/目录）

    3. AI 配置界面：录入 API Key、模型、RAG 参数等

    4. 数据导入界面：URL/Sitemap/RSS/文件等

  2. 用户端（app）：

    1. SEO 友好的 Wiki 渲染（Markdown/HTML）

    2. AI 问答入口（浮窗、侧边栏、嵌入式对话）

    3. 语义搜索/全文搜索界面

  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，这样解耦和可维护性更好。

六、部署与运维模式

  1. 基本要求

  • 一台 Linux 服务器

  • Docker 20.x+ 环境[1][19]

  • 使用 root 权限执行一键安装脚本：

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

脚本会：

  1. 拉取相关 Docker 镜像（panda-wiki 后端、前端、raglite、数据库等）

  2. 启动容器

  3. 输出访问地址、默认账号（admin）和初始密码[1]

  1. 启动后流程

  1. 首次登录控制台 → 引导「配置 AI 模型」：

    1. 一键接入（推荐配合「百智云模型广场」，注册送额度）[1][19]

    2. 手动填写模型配置

  2. 创建第一个知识库（会自动生成对应 Wiki 站点）

  3. 导入/编辑文档，系统开始构建 RAG 索引

  4. 配置集成渠道：钉钉/飞书/企业微信机器人、网页挂件等

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

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

  1. 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 易于扩展创新方案

  1. 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 知识助手的数据底座

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

技术栈：

  • Node.js + JavaScript

  • Docker 部署

  • 丰富的扩展与存储后端（Git、数据库等）

特点：

  • 传统 Wiki + 强扩展性

  • AI 相关能力更多是靠插件/社区方案（如 ChatGPT 集成）

对比：

  • Wiki.js：对「内容管理」历史悠久，稳定、扩展性强，但 AI 不是核心

  • PandaWiki：AI 是一等公民，知识库就是为 RAG 服务而设计

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

技术栈：

  • Python + Streamlit （UI）

  • LLamaIndex + LangChain（RAG）

  • 数据：Wikipedia dump + WikiExtractor 清洗

定位：

  • RAG 教学 demo / 实验项目

  • 强调「用 Wikipedia 全库 + RAG 做问答」

对比：

  • 更适合学习 RAG 概念、快速 PoC，而非直接生产部署

  • PandaWiki 则面向正式部署、一般用户与企业用户

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

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

  1. 职责清晰的三层：业务后端 / RAG 服务 / 前端

    1. 后端只负责：

      • 用户、权限、多知识库、多站点

      • 文档元数据 & 状态管理

      • 与 RAG 服务编排（调用 SDK）

    2. RAG 服务（如 RAGLite）独立：

      • 文档切分、向量存储、检索、问答

    3. 前端聚焦在编辑体验与 AI 交互 UI（编辑器 + ChatWidget）

  2. RAG 层使用 SDK 封装，而不是在业务层手写 HTTP 调用

    1. PandaWiki 用 sdk/rag 做了一层 Go SDK 封装，再由 backend 调用

    2. 好处：

      • 可以方便替换实现（比如未来不再用 RAGLite，改用别的向量服务）

      • 业务代码更简洁

  3. 先把“文档体验”做好，再上 AI

    1. PandaWiki 用 Tiptap 打底，Markdown/HTML 双向支持，支持导出 PDF/Word 等

    2. 即使关掉 AI，它也是个可用的 Wiki 系统

    3. 这是和很多「只做聊天界面」的知识库工具的差异

  4. 企业集成优先：LDAP、IM 机器人、Webhook

    1. 丰富的第三方集成（钉钉/飞书/企微）

    2. 这部分在未来价值会远大于“前端 UI 有多花哨”，值得优先设计接口

  5. 运维体验：一键脚本 + 多容器编排

    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 和网页中。

References

[1] PandaWiki README. https://github.com/chaitin/PandaWiki [2] PROJECT_STRUCTURE.md. https://github.com/chaitin/PandaWiki/blob/main/PROJECT_STRUCTURE.md [18] backend 目录结构页面. https://github.com/chaitin/PandaWiki/tree/main/backend [19] PandaWiki Releases / 安装脚本说明. https://github.com/chaitin/PandaWiki/releases [21] web 目录结构页面. https://github.com/chaitin/PandaWiki/tree/main/web [23] sdk/rag 目录结构页面. https://github.com/chaitin/PandaWiki/tree/main/sdk/rag [24] sdk/rag/client.go 摘要. https://raw.githubusercontent.com/chaitin/PandaWiki/main/sdk/rag/client.go [26] raglite-go-sdk README 提取. https://github.com/chaitin/raglite-go-sdk [28] backend/Dockerfile.api 摘要. https://raw.githubusercontent.com/chaitin/PandaWiki/main/backend/Dockerfile.api [29] web/package.json 提取. https://raw.githubusercontent.com/chaitin/PandaWiki/main/web/package.json [30] backend/go.mod 提取. https://raw.githubusercontent.com/chaitin/PandaWiki/main/backend/go.mod [32] DeepWiki-Open 仓库页面提取. https://github.com/AsyncFuncAI/deepwiki-open [39] Docmost 仓库页面提取. https://github.com/docmost/docmost [46] Wiki.js README 摘要. https://raw.githubusercontent.com/requarks/wiki/main/README.md [52] RAG-WIKI 仓库页面提取. https://github.com/lyyf2002/RAG-WIKI

# 开源
Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

Gemini认证：AI职业发展的黄金通行证

Gemini认证是AI领域的重要专业资质，涵盖机器学习、自然语言处理等核心技术，主要面向开发者与数据科学家。该认证通过验证专业技能提升职业竞争力，获得企业广泛认可，可助力薪资增长与职位晋升。备考需重点掌握深度学习框架与AI伦理规范，推荐结合官方教材与实践项目。认证与AI产品经理等新兴岗位高度契合，并具有国际就业优势。随着技术迭代，认证内容将持续更新，在医疗、金融等垂直领域应用前景广阔，是AI从业者

avatar 2048 AI社区

【AI测试全栈：质量】45、Kubernetes云原生AI服务测试全实战：从容器化到多租户隔离（附Kind集群实操+踩坑指南）

云原生AI服务测试实战指南 本文针对Kubernetes环境下AI服务的特殊需求，提供了一套完整的测试方法论和实操指南。文章首先分析了云原生AI服务的核心架构，重点突出了GPU适配、模型持久化、推理性能等关键测试维度。随后详细介绍了五大核心测试模块：容器化测试、资源调度测试、弹性伸缩测试、服务网格测试和多租户隔离测试。 测试方案基于Kind本地集群，整合了Docker、Helm等云原生工具链，并特

avatar 2048 AI社区

存储系统核心技术全解析

本文系统梳理了存储技术体系，从基础架构到前沿趋势：1）硬件层面分析HDD/SSD/NVM介质特性及SATA/NVMe协议差异；2）软件层面详解文件系统结构、日志恢复及缓存优化策略；3）分布式场景探讨CAP理论与RAID/纠删码技术；4）前瞻方向包括SCM内存、存算一体架构和量子存储研究。通过多层次技术解析，呈现了存储系统设计中的性能、可靠性与成本平衡机制。

avatar 2048 AI社区