毕昇·企业AI中台架构

本文基于 BISHENG main 分支在 2026 年 11 月的架构文档和部署配置整理。项目仍在快速演进，具体模块和部署拓扑请以使用版本为准。

如果把一个 LLM 应用平台理解成“一个聊天页面，加上几个模型 API”，那么当系统开始面对知识库构建、可视化工作流、长时间 Agent 任务、多租户权限、文件管理和企业审计时，这种简单结构很快就会失效。

BISHENG 的架构选择是把这些问题拆成多个相对独立的执行平面：前端负责应用编排与终端交互，FastAPI 负责同步业务和领域逻辑，Celery 处理知识与工作流异步任务，Linsight Worker 独立执行 Agent 推理，Milvus 与 Elasticsearch 分别承担语义和关键词召回，OpenFGA 则负责资源级权限关系。

它更接近一个面向企业的 LLM Application DevOps 平台，而不是单一的 RAG 问答工具。

一、BISHENG 核心架构全景

从逻辑职责上看，BISHENG 可以划分为七个部分：

1. 接入与展示层；

2. Nginx 统一入口；

3. FastAPI 应用与领域服务；

4. 异步任务和实时通信平面；

5. 基础设施适配层；

6. 数据与检索基础设施；

7. 多租户、权限和可观测性等跨切面能力。

这张图同时表达了完整逻辑架构和主要运行时进程。默认 Docker Compose 可能把部分 Worker 合并启动，也不一定默认拉起完整的 Client SPA、Celery Beat 或 Linsight Worker，但这些模块在完整系统中承担不同职责。

二、为什么有两套前端

BISHENG 当前仓库包含两套独立的 React 应用：

• src/frontend/platform/：管理端和应用构建端，使用 Vite 5、Zustand、React Query v3 和统一 UI 包；

• src/frontend/client/：面向最终用户的工作台和聊天界面，挂载在 /workspace，使用 Vite 6、Recoil、TanStack React Query v4 和 shadcn/ui。

Platform 侧关注“如何构建和管理 AI 应用”，例如工作流、知识库、模型、评测和系统配置；Client 侧关注“如何消费 AI 应用”，例如工作台、聊天、会话记录和共享应用。

这种拆分带来两个好处。

首先，构建端和消费端可以拥有不同的信息密度、状态管理方式和发布周期。其次，终端工作台不需要携带大量管理控制台代码，更适合独立优化移动端体验和会话性能。

外部系统则不需要经过 SPA，可以直接访问 /api/v2 提供的开放 RPC 接口。它覆盖知识库、文件库、聊天、助手、工作流和模型调用等集成场景。

三、FastAPI 后端：API 入口和领域边界

所有前端和开放接口最终进入 FastAPI 服务。完整架构中，服务运行在 7860 端口，并提供两组主要路由：

• /api/v1：面向 BISHENG 前端的完整业务 API；

• /api/v2：面向外部系统的简化 RPC 和开放接口。

请求进入业务路由前，会经过 CORS、请求日志、Trace ID、WebSocket 日志等中间件。身份和租户上下文也会在这一阶段建立。

DDD 调用链

BISHENG 后端正在按领域驱动的方式组织业务模块，其架构约束明确要求调用链遵循：

Router → Endpoint → Service → Repository → ORM / Database

以 Knowledge 模块为例，API、领域模型、Schema、Service 和 Repository 分别位于不同目录。Endpoint 不应直接书写 ORM 查询，Service 负责业务规则，Repository 负责数据访问抽象。

这项约束的价值并不只是让目录“看起来整齐”。当系统同时支持 MySQL 和达梦 DM8、单租户和多租户、开源版和商业版网关时，数据访问和业务规则必须保持边界，否则每增加一种部署形态都会在 API 层产生大量条件分支。

主要业务域

FastAPI 应用层包含多个相互协作的领域：

• Knowledge、Knowledge Space、文件库和 RAG 问答；

• Workflow、Flow 和 LangGraph DAG 编排；

• Assistant、Chat、Session 和应用发布；

• Linsight Agent、技能、子智能体和人工介入；

• LLM、Embedding、Rerank 等模型管理；

• Evaluation、SFT、Dataset、审计、渠道和系统管理。

这些业务不会全部在 API 进程内同步完成。FastAPI 更像是控制面：负责验证、权限、领域编排和任务投递，耗时执行则被下沉到专门 Worker。

四、Celery：将耗时工作从 API 进程中拆出去

BISHENG 使用 Redis 作为 Celery Broker，并按任务性质划分队列。

knowledge_celery

知识 Worker 负责文档解析、Embedding 生成、向量写入和全文索引。典型处理过程可以概括为：

文件上传
  → 元数据与任务创建
  → Redis Broker
  → Knowledge Worker
  → 文档解析 / OCR
  → Chunk 与 Embedding
  → Milvus 向量索引
  → Elasticsearch 全文索引
  → 状态写回数据库

将知识入库异步化，可以避免大文件解析、OCR 和 Embedding 阻塞 HTTP 请求，同时也便于针对知识任务单独扩容 Worker。

workflow_celery

工作流 Worker 负责执行 Workflow DAG。BISHENG 的工作流不是简单的线性 ChatFlow，而是支持条件、循环、并行、批处理和人工介入等复杂控制结构。LangGraph 负责执行层编排，API 进程只保存定义、发起运行和返回状态。

默认队列与 Celery Beat

默认 Celery Worker 主要处理通用任务和遥测统计；Celery Beat 负责周期性投递任务，例如用户、知识库、应用和交互数据的增量统计，以及部分内容同步任务。

从生产部署角度看，三类队列应当分开观察。知识任务通常消耗 CPU、内存和外部模型配额；工作流任务容易形成长执行链；遥测任务则更关注吞吐和数据库压力。把它们放进同一个无差别队列，会让大文件解析拖慢在线工作流。

五、Linsight Worker：为什么 Agent 要独立运行

Linsight 是 BISHENG 的通用 Agent 能力。它不仅执行一次模型调用，还可能进行任务规划、拆分待办、调用技能、委派研究子智能体、等待人工确认，并在长任务中维护工作区和中间产物。

因此，Linsight 使用独立 Worker 进程，而不是完全依附于 FastAPI 请求生命周期。API 负责创建任务和交互，Redis 队列负责传递执行请求，Linsight Worker 负责真正的 Agent 推理。

独立 Worker 带来的直接收益包括：

• Agent 长任务不会占用 API Worker；

• 可以独立控制 Agent 并发和模型限流；

• 服务重启时更容易恢复或重新调度任务；

• 子智能体和技能运行可以使用独立上下文；

• Human-in-the-Loop 暂停时，不需要保持一个 HTTP 请求长期存活。

这也解释了为什么 BISHENG 强调不能把本机目录当成多进程共享的事实数据源。API、Celery 和 Linsight Worker 可能运行在不同机器上，跨进程需要读取的文件必须以 MinIO 等对象存储为事实来源，本地文件只能作为可丢弃缓存。

六、RAG 为什么同时使用 Milvus 和 Elasticsearch

BISHENG 的检索架构包含两类召回：

• Milvus 保存向量索引，负责语义相似度召回；

• Elasticsearch 负责全文和关键词检索。

只使用向量检索时，对精确名称、编号、术语和短关键词的召回可能不稳定；只使用关键词检索时，又难以覆盖同义表达和自然语言问题。双路召回能够把语义相关性和字面匹配结合起来，再由上层完成融合、过滤或重排。

知识入库时，原始文件进入 MinIO，结构化元数据进入 MySQL/DM8，Chunk 分别写入向量和全文索引。问答时，检索服务同时访问 Milvus 与 Elasticsearch，再把结果交给 Rerank 或回答链路。

可以把这套数据分工理解为：

数据类型	主要存储	作用
用户、应用、会话、任务和配置	MySQL / DM8	业务事实数据
缓存、Broker、任务队列和会话状态	Redis	高速临时状态与异步通信
Embedding	Milvus	语义向量召回
文本索引	Elasticsearch	全文与关键词召回
文档、图片和 Agent 工作区文件	MinIO / S3	跨进程文件事实来源
用户—角色—资源关系	OpenFGA	ReBAC 权限判定

七、WebSocket 与流式对话

普通管理请求可以沿着以下路径同步返回：

Browser → Nginx → FastAPI → Service → Repository → Database

对话场景则通过 WebSocket 和 ChatManager 维护长连接。模型生成的内容通过回调持续进入消息缓冲，再逐段推送给前端，并将最终消息持久化。

这种模式将“生成一个完整答案”拆成持续事件流，前端可以同时展示回答文本、工具调用、执行进度和结束状态。对于工作流和 Agent，流式通信也可以用于反馈当前节点、待处理任务或人工确认请求。

八、多租户与 OpenFGA 权限体系

企业级平台的权限问题远比“管理员和普通用户”复杂。知识库、工作流、应用、文件和会话都可能属于不同租户、组织或用户组，并且存在查看、编辑、调用、分享等不同操作。

BISHENG 将这部分拆为两层：

租户隔离

租户上下文通过 ContextVar 在请求链中传播，SQLAlchemy 事件对多租户表自动注入过滤条件。业务开发不应在每个查询里手写 tenant_id = ...，否则很容易出现漏加过滤条件的越权问题。

资源关系权限

业务代码通过统一的 PermissionService 进入权限检查，再由 OpenFGA 维护用户、角色、组织和资源之间的 ReBAC 关系。

这种结构把“数据属于哪个租户”和“某个用户能否对某个资源执行某个动作”分开处理。前者是数据隔离问题，后者是关系授权问题。

九、三条典型运行链路

1. 同步管理请求

Platform SPA
  → Nginx
  → FastAPI /api/v1
  → Endpoint
  → Domain Service
  → Repository
  → MySQL / DM8

适用于应用配置、模型管理、知识库列表和系统设置等快速 CRUD 操作。

2. 知识入库请求

上传文件
  → FastAPI 创建记录
  → Redis Broker
  → Knowledge Worker
  → 文档解析 / OCR
  → MinIO + MySQL/DM8
  → Milvus + Elasticsearch

适用于 PDF、Office 文档、图片和其他需要解析、分块、Embedding 的内容。

3. Agent 或工作流请求

Client SPA / Open API
  → FastAPI 创建运行任务
  → Redis Queue
  → Workflow Worker 或 Linsight Worker
  → 模型 / 工具 / 知识库
  → WebSocket 流式反馈
  → 消息与产物持久化

这条链路既支持普通 LangGraph 工作流，也支持需要计划、子智能体、技能和人工确认的长时间 Agent 任务。

十、这套架构值得借鉴的地方

1. 控制面和执行面分离

FastAPI 负责业务控制，Celery 和 Linsight Worker 负责重计算与长任务。二者可以按不同指标扩容，避免在线 API 被文档解析或 Agent 推理拖垮。

2. RAG 存储职责明确

原始文件、业务数据、向量、全文索引和权限关系分别进入适合的存储。没有试图用一个数据库解决所有问题。

3. Agent 是独立运行时，不是一个 API 函数

计划、技能、委派和人工介入都意味着 Agent 必须拥有独立生命周期。Linsight Worker 的存在让这一点在架构层面得到承认。

4. 权限成为基础设施能力

租户过滤和资源权限均通过统一入口完成，而不是散落在 Endpoint 或前端条件判断中。这对企业知识库和应用分享非常关键。

5. 架构约束可以被自动检查

项目通过 Architecture Constitution 和架构检查脚本限制跨层调用、数据库方言、权限入口和前端 HTTP 访问方式。架构不是只存在于文档里的建议，而是逐步变成可以在开发流程中检查的规则。

十一、部署和扩容时应重点观察什么

真正部署 BISHENG 时，不应该只观察一个 Backend 容器。

• API 延迟高：检查 FastAPI 进程、数据库连接池和同步外部请求；

• 知识入库慢：检查 Knowledge Worker、解析服务、Embedding 限流、Milvus 和 ES；

• 工作流排队：检查 workflow_celery 队列长度和 Worker 并发；

• Agent 长时间无响应：检查 Linsight Worker 心跳、Redis 队列、工具超时和模型调用；

• 对话卡顿：检查 WebSocket、ChatManager 队列和消息持久化；

• 多节点文件丢失：检查文件是否真正写入 MinIO，而不是只存在某个容器本地目录；

• 权限异常：沿 Tenant Context → PermissionService → OpenFGA 检查，不要只看前端按钮是否隐藏。

对于大规模部署，API、Knowledge Worker、Workflow Worker 和 Linsight Worker 应根据负载分别扩容。Redis、MySQL/DM8、Milvus、Elasticsearch 和 MinIO 则需要独立的持久化、备份与容量规划。

结语

BISHENG 的核心并不是把 RAG、Workflow 和 Agent 简单堆到一个产品页面里，而是为它们建立一套可以共同运行的企业级底座：

• 两套前端分别服务构建者和最终用户；

• FastAPI 与 DDD 模块承载业务控制面；

• Celery 隔离知识、工作流和通用异步任务；

• Linsight Worker 提供独立 Agent 运行时；

• Milvus 与 Elasticsearch 共同组成 RAG 召回层；

• MinIO、MySQL/DM8 和 Redis 分别管理不同类型的状态；

• ContextVar 与 OpenFGA共同构成多租户权限边界。

如果你正在设计一个从内部 Demo 走向企业生产的 LLM 平台，BISHENG 最值得参考的并不是某一个功能，而是它对进程边界、数据职责、异步执行和权限基础设施的拆分方式。

---

源码与文档参考

• BISHENG GitHub 仓库

• 系统架构总览

• 架构约束 Constitution

• 项目开发与运行规则

• 后端模块规则

• Docker Compose

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/zxncvb/article/details/169748279