BISHENG 企业级大模型应用技术全景一、BISHENG 是什么不只是一个聊天机器人搭建器1.1 三条主要应用路线1.2 当前公开版本的能力边界二、总体架构两个前端、一个 API 与多类异步执行器2.1 技术分层、运行拓扑与源码目录2.2 API、Worker 与状态存储2.3 “配置支持”不等于“默认生产拓扑”三、RAG 源码链路从文件上传到带引用回答3.1 文档解析与切分3.2 Milvus Elasticsearch 的混合召回3.3 RAG 节点、只检索节点与权限收口四、两种编排内核可视化工作流与 Linsight Agent4.1 可视化工作流画布 JSON 变成 LangGraph 状态图4.2 LinsightBISHENG 适配 DeepAgents而不是旧版自研 ReAct4.3 Skills、模型、工具、MCP 与人机交互五、Docker Compose 部署与首次使用5.1 快速启动5.2 当前基础 Compose 到底启动了什么5.3 跑通第一个完整闭环六、权限、生产化与适用边界6.1 OpenFGA 细粒度授权链6.2 上线前必须修改的默认项6.3 并发与可靠性不能只看 Worker 参数6.4 备份、恢复和升级6.5 适用与不适用场景七、总结参考资料BISHENG毕昇是一套面向企业的大模型应用开发平台把知识库、可视化工作流、通用 Agent、模型工具接入和权限治理组织进同一条应用交付链路。它既可用于快速搭建知识问答与自动化流程也适合作为继续集成内部模型、知识资产和业务系统的工程底座。本文基于v2.6.0-fix2对应源码从数据流与关键实现出发分析混合检索、LangGraph 工作流、DeepAgents 执行内核、Redis 断点恢复和 OpenFGA 权限链并给出 Docker Compose 部署、使用及生产化边界。GitHub仓库https://github.com/cmyk-labs/bisheng.git如果这个仓库对你有帮助欢迎在 GitHub 上点一个 Star ⭐ 支持一下。官方GitHub仓库https://github.com/dataelement/bisheng官方文档https://dataelem.feishu.cn/wiki/ZxW6wZyAJicX4WkG0NqcWsbynde图一、BISHENG 是什么不只是一个聊天机器人搭建器从当前仓库看BISHENG 并不是只在一个聊天页面外面套模型 API而是把企业应用通常需要的几个层次放进了同一个工程应用层普通助手、可视化工作流、Linsight 通用 Agent、知识库问答及对外 API能力层LLM、Embedding、Rerank、ASR、TTS 等模型角色以及预置工具、自定义 API 工具和 MCP 工具数据层文档解析、对象存储、向量检索、关键词检索、对话与任务状态治理层用户、部门、用户组、租户、角色、资源权限、审核与审计等模块运行层FastAPI、Celery、LangGraph、Redis、MySQL、Milvus、Elasticsearch、MinIO 和 OpenFGA。这套组合适合两类团队。一类希望通过界面快速做出知识问答、流程自动化或研究型 Agent另一类需要从源码继续集成内部模型、知识资产、工具和权限系统。它的价值不在“零代码”三个字本身而在于把模型调用、检索、流程状态、工具执行和权限判断串成了相对完整的应用链路。从当前 API、前端导航和部署配置看主要能力可以按下面的关系理解功能域核心能力与其他模块的关系知识库文件解析、切分、向量/关键词索引、引用与问答测试为助手、工作流和 Linsight 提供受权限约束的企业知识助手与编排普通助手、可视化工作流、Linsight Agent组合模型、知识库、工具、Skills 和人工交互形成应用模型与工具LLM、Embedding、Rerank、语音模型、预置/自定义工具、MCP为检索、生成、流程节点和 Agent 执行提供基础能力评测与微调数据集、模型评测和微调相关任务入口用于比较模型与应用效果部分链路依赖额外计算资源和可选编排发布与渠道应用发布、终端用户界面、外部接口和渠道配置把已配置应用交付给用户或业务系统审批与治理用户、部门、用户组、OpenFGA 资源关系、审批和审计控制谁能查看、配置或运行资源并记录高风险操作这张表描述的是公开源码能够看到的功能域不表示基础 Compose 已默认开启商业网关、完整 SSO 或高可用部署。图片来源BISHENG 官方 GitHub README。Linsight 通用 Agent可视化工作流企业应用与对话文档解析与知识入库1.1 三条主要应用路线路线适合的问题核心特点需要重点控制的风险知识库 / RAG基于内部文档回答、检索、引用文档解析Milvus Elasticsearch 混合召回可选 Rerank解析质量、越权检索、无权文档进入上下文、敏感文档泄露可视化工作流步骤相对确定、需要分支或人工输入的业务流程图形化编排、条件边、循环、节点中断与恢复、事件流长时间暂停的状态持久性、幂等、工具副作用Linsight Agent目标开放、需要规划、研究、工具与交付物的任务DeepAgents 内核、子 Agent、Skills、Redis checkpoint、人机交互工具权限、模型不确定性、外部依赖、成本与并发这三条路线不是替代关系。例如一份尽调任务可以由 Linsight 负责规划和产出报告由知识库工具提供受限的内部资料再调用 MCP 或自定义 API 获取外部系统数据而一个固定的审批流程更适合工作流不必让 Agent 自由决定每一步。1.2 当前公开版本的能力边界官方 README 还展示了 SSO、多租户、高可用、内容审核等企业能力。不过阅读源码时必须区分三个范围已经落在当前公开源码和基础 Compose 中的能力例如知识库、工作流、Linsight、OpenFGA 资源权限代码中已有开关或接口、但基础 Compose 默认未开启的能力例如多租户配置依赖商业网关或外部基础设施的完整企业方案。仓库的网关架构文档明确提到商业版 Java 网关它不在基础 Compose 中。所以下文不会把营销页上的全部企业功能都等同于“执行一条 Compose 命令就能得到”。二、总体架构两个前端、一个 API 与多类异步执行器当前仓库采用 Monorepo 组织。后端位于src/backend管理/搭建端前端位于src/frontend/platform终端用户侧前端位于src/frontend/client。两个前端都使用 React 和 Vite但状态管理及依赖版本并不完全相同基础 Compose 最终运行一个dataelement/bisheng-frontend镜像由 Nginx 对外暴露3001端口并反向代理后端。可以把主要运行链路概括为浏览器 / 外部系统 │ ▼ 前端镜像Nginx3001 │ HTTP / SSE / WebSocket ▼ FastAPI 后端7860 ├─ /api/v1管理与应用接口 ├─ /api/v2外部、兼容与 RPC 类接口 ├─ MySQL业务元数据、用户、配置、任务记录 ├─ OpenFGA资源关系与授权判断 └─ Redis缓存、消息、Celery broker、Agent checkpoint │ ▼ backend_worker ├─ knowledge_celery文档解析与入库 ├─ ocr_celeryOCR 类任务 ├─ workflow_celery工作流执行与续跑 ├─ celery其他后台任务 └─ Linsight workerAgent 任务 │ ├─ MinIO原文件、图片和附件 ├─ Milvus向量索引 └─ Elasticsearch关键词索引这里需要注意队列逻辑上有区分但当前基础 Compose 的backend_worker通过entrypoint.sh worker启动一个线程池 Celery Worker同时监听knowledge_celery,ocr_celery,workflow_celery,celery并启动 Linsight Worker 和 Celery Beat。源码也提供了拆分不同 Worker 的启动函数不过那不等于基础 Compose 已经替用户完成了生产隔离。2.1 技术分层、运行拓扑与源码目录上面的运行图描述“服务怎样协作”源码目录则说明“职责在哪里实现”。按当前提交可以把工程分为以下层次层次主要实现关键职责交互层src/frontend/platform、src/frontend/client应用搭建、平台管理、最终用户对话和运行结果展示API 与领域层FastAPI、bisheng/api知识库、应用、模型、工具、用户、审批等业务接口AI 编排层bisheng/workflow、bisheng/linsight、bisheng_langchainLangGraph 工作流、DeepAgents 适配、Agent 与工具运行异步执行层Celery Worker、Beat、Linsight Worker文档/OCR、工作流续跑、后台任务和 Agent 执行数据与权限层MySQL、Redis、MinIO、Milvus、Elasticsearch、OpenFGA业务状态、检查点、对象、索引和资源关系授权交付层Nginx、Docker Compose、入口脚本构建前后端、组织依赖服务和启动运行进程bisheng/ ├── src/ │ ├── frontend/ │ │ ├── platform/ # 管理、搭建与配置端 React 前端 │ │ └── client/ # 最终用户应用与对话端 │ └── backend/ │ ├── bisheng/ │ │ ├── api/ # FastAPI 路由与领域服务入口 │ │ ├── knowledge/ # 文档、切分、索引与 RAG │ │ ├── workflow/ # LangGraph 工作流节点与图执行 │ │ ├── linsight/ # DeepAgents 适配与任务运行时 │ │ ├── mcp_manage/ # MCP 连接与工具适配 │ │ ├── permission/ # 权限领域服务 │ │ ├── approval/ # 统一审批与 Outbox │ │ └── worker/ # Celery 任务入口 │ └── bisheng_langchain/ │ └── gpts/ # Agent、工具与代码执行器 ├── docker/ │ ├── docker-compose.yml # 基础单机编排 │ ├── docker-compose-office.yml # 可选 OnlyOffice 编排 │ └── docker-compose-ft.yml # 可选微调编排 ├── docs/architecture/ # 项目架构说明 ├── features/ # 版本功能设计与发布契约 └── LICENSE # 开源许可证两个前端共享同一组后端领域能力但服务对象不同知识库、工作流和 Linsight 分域后可以采用各自的数据结构与执行方式bisheng_langchain再承接 Agent、工具与代码执行适配。docker/描述部署组合并不意味着目录中的每个领域都会独立成为一个服务。固定提交中的架构说明包含更广的产品视图实际进程数量仍以当前 Compose 和入口脚本为准。2.2 API、Worker 与状态存储后端入口会先执行 Alembic 数据库迁移再启动 Uvicorn。当前 Compose 中 API 使用两个 Uvicorn Worker/health返回服务健康状态。API 路由覆盖知识库、工作流、助手、模型、评测、微调、Linsight、工具、MCP、渠道、用户组、部门、权限、租户、审计与审批等模块。各存储组件的职责并不相同组件主要职责不能替代什么MySQL用户、模型配置、知识库元数据、应用、任务等关系数据不是大规模向量召回引擎RedisCelery、缓存、事件桥接、Linsight checkpoint 等短期状态默认不是全部业务数据的最终事实源MinIO原始文件、解析附件、图片、交付物等对象不负责语义搜索Milvus稠密向量检索不擅长原词、编号等精确关键词召回Elasticsearch关键词 / BM25 类检索不等同于语义向量检索OpenFGA用户、用户组、部门与资源之间的关系授权不负责登录认证和业务数据本身2.3 “配置支持”不等于“默认生产拓扑”当前配置代码能够看到 Redis Sentinel、多租户等扩展点但官方docker-compose.yml是一个面向试用和单机部署的拓扑单 MySQL、单 Redis、单 Milvus Standalone、单 Elasticsearch、单 MinIO。它没有自动组成高可用集群也没有默认接入企业 SSO 网关。因此架构评估应从实际 Compose、入口脚本和当前代码反推而不能只看旧版架构说明中的容器数、Worker 数或宣传图。本文固定提交中的部分docs/architecture文档仍带有 v2.4 时代的描述当前代码和 Compose 在冲突时应作为主要依据。三、RAG 源码链路从文件上传到带引用回答BISHENG 的知识库不是单一“向量数据库上传”动作而是一条异步管线。概括后是上传文件 │ ├─ 元数据写入 MySQL └─ 原文件写入 MinIO │ ▼ knowledge_celery parse_knowledge_file_celery │ ▼ KnowledgeFilePipeline Load → Transform → Ingest │ │ ├─ Milvus 向量索引 │ │ └─ Elasticsearch 关键词索引 │ ├─ 切分、摘要可选 │ ├─ 图片/附件回写 MinIO │ └─ 缩略图与预览缓存 └─ PDF / Office / 文本 / 表格 / 图片解析关键入口可以从文件 Worker、知识库服务和文件处理管线串起来看。3.1 文档解析与切分当前 Loader 映射覆盖 PDF、DOC/DOCX、PPT/PPTX、TXT/Markdown、HTML、XLS/XLSX/CSV以及 PNG、JPG、JPEG、BMP 等常见格式。PDF 可以根据配置走 ETL4LM、MinerU、PaddleOCR 等解析服务并存在本地解析回退图片 OCR 则需要配置相应 OCR 服务不能把它理解为所有格式都一定在本地离线完成。请求 Schema公开了三种split_mode真正执行时再由文件管线根据类型和参数选择规则分段方式关键输入当前实现边界autochunk_size、chunk_overlapSchema 默认大小 1000、重叠 100未显式传入重叠时管线会把自动模式重叠改为 0Web 链接同样使用 0PPT/PPTX 按页处理custom自定义分隔和块参数使用普通SplitterTransformer适合读者已经明确文本边界的材料hierarchicalhierarchy_level、append_title、max_chunk_size只对 Markdown、DOC、DOCX 使用层级切分其他扩展名回退自动模式超长层级内容仍会继续普通切分Excel 规则ExcelRule等表格参数按表格结构生成内容不能套用纯文本标题层级是否保留图片还受retain_images控制知识文件管线会在HierarchicalSplitterTransformer与SplitterTransformer之间选择。层级切分会保留标题路径便于片段脱离原文后仍携带章节语境但它不是所有格式的默认方案也不能修复解析阶段已经丢失的表格关系或扫描文本。生产环境仍应按文档结构和问答粒度做评测合同条款适合保留标题与层级产品手册可能需要较小片段表格需要专门规则。这里使用的是 BISHENG 自己的split_mode和 Transformer 名称不应套用其他项目的SplitModel术语。3.2 Milvus Elasticsearch 的混合召回查询侧同时使用两条检索路线Milvus 返回语义相近的向量结果Elasticsearch 返回关键词相关结果两组排序由 RRFReciprocal Rank Fusion融合若应用显式开启且配置了 Rerank 模型再执行重排最终片段交给 LLM 节点生成答案并记录来源文档和引用。当前工作流知识检索组件中向量和关键词的默认权重都是0.5单路候选k100将某一路权重设为0可以关闭该路。RRF 实现的默认平滑常数c60其得分可写成score(d) Σᵢ wᵢ / (rankᵢ(d) 60)RRF 关心文档在各结果列表中的名次而不直接比较 Milvus 相似度与 Elasticsearch 分数这两种量纲不同的原始值。当前实现以page_content去重并汇总得分详见RRF 源码和知识检索工具。一个容易误读的点是RRF 融合是当前混合检索链的重要组成部分但模型 Rerank 是可选项不是每次查询必经步骤。3.3 RAG 节点、只检索节点与权限收口工作流提供两类容易混淆的节点KnowledgeRetriever负责取回片段方便下游节点自行处理RagNode在检索后组织上下文与提示词调用 LLM 生成结果并维护引用信息。RAG 节点会把来源文档纳入回调和引用注册而不是只返回一段无法追踪出处的纯文本。实际项目中仍应保存检索候选、融合后名次、最终上下文和模型输出才能定位“没召回”“召回了但被截断”“模型忽略证据”等不同问题。知识库检索入口会在取得检索后端前检查知识库权限知识空间检索链还会在召回后、进入模型上下文前按用户可见文件过滤。这个顺序非常关键如果只在界面隐藏无权引用而不在模型取上下文前过滤文档内容仍可能进入提示词并泄漏。不过源码中存在检查并不代表部署后无需验证。上线前至少要做以下反向测试普通用户检索管理员文件、跨部门共享文件、被移出用户组后的缓存窗口、知识库转移所有者以及 Agent 通过工具间接读取知识库。权限测试应覆盖 API 和后台任务而不只是页面按钮是否显示。四、两种编排内核可视化工作流与 Linsight AgentBISHENG 当前同时保留了两类执行模式。可视化工作流适合流程相对确定的图执行Linsight 适合让模型围绕目标规划、研究、调用工具并形成交付物。二者底层都能看到 LangGraph 生态但状态管理方式和运行语义并不一样。4.1 可视化工作流画布 JSON 变成 LangGraph 状态图当前节点枚举和节点工厂注册了 13 种可执行画布节点开始、结束、输入、输出、工具、RAG、报告、QA 检索、条件、Agent、代码、LLM 和知识检索。NOTE只负责画布注释FAKE_OUTPUT是引擎内部辅助类型。执行链如下画布节点与边 JSON │ ▼ WorkFlowService 校验并创建任务 │ ▼ workflow_celery │ ▼ GraphEngine ├─ 实例化节点 ├─ 建普通边 / 条件边 ├─ 处理汇合、层级与循环步数 ├─ compile(MemorySaver, interrupt_before...) └─ 流式执行 │ ▼ RedisCallback → 状态、Token、来源文档、用户输入事件 → 前端GraphEngine会构造 LangGraphStateGraph。输入节点会触发中断前端提供数据后调用续跑逻辑交互式输出还会插入内部输出节点。引擎通过递归上限控制循环步数因此把当前工作流简单描述为“只支持无环 DAG”并不准确。工作流 Worker 使用StatefulWorker将续跑任务路由回绑定的 Worker。与此同时图编译使用的是进程内MemorySaver。从源码可以推断暂停工作流的继续执行依赖原 Worker 中的图状态Worker 重启或丢失绑定时不能默认认为一定可以跨进程无损恢复。对需要等待数小时或数天的审批流程应实际测试重启、扩缩容、任务重投、超时和幂等必要时再改为持久化 checkpointer。4.2 LinsightBISHENG 适配 DeepAgents而不是旧版自研 ReAct仓库中的旧架构文档仍能看到 SOP、任务管理器和自研 ReAct 的描述但v2.6.0-fix2当前执行路径已经变化。Agent 工厂调用deepagents.create_deep_agentBISHENG 负责把自己的模型、工具、工作区、中间件、子 Agent 和 checkpoint 适配进去。核心装配关系可以缩写为returncreate_deep_agent(modelmodel,tools[*tools,ask_user,*export_tools],middlewaremiddlewares,subagents[researcher],backendbackend,checkpointercheckpointer,)这段关系比“它有一个 Agent”更有解释力model由 BISHENG 的LLMService根据任务模型或租户默认模型解析tools合并用户选择工具、向用户提问、DOCX/PDF 导出等能力middleware提供工具循环保护、二进制内容保护、错误韧性、Skills 和语言约束researcher是名为general-purpose的研究子 Agent工具集合会被过滤不能向用户提问也不负责最终导出backend是共享工作区主 Agent 负责最终交付物真实任务会注入 Redis checkpointer未传入时的内存 checkpointer 主要用于测试或早期装配场景。换言之DeepAgents 提供推理与图执行内核BISHENG 的工程价值主要体现在企业运行时适配。把 DeepAgents 的全部内部能力都说成 BISHENG 自研也是不准确的。这套装配还有一层容易被忽略的运行韧性。LinsightModelResilienceMiddleware并不是笼统地“失败就重试”瞬时错误按指数退避重试鉴权和配额错误直接失败内容过滤等不可重试错误只允许研究子 Agent 返回一条降级结果让主任务带着已有材料继续主 Agent 自身遇到同类错误则干净失败避免把一条伪造的成功消息当成最终答案。模型在生成工具参数时因长度上限被截断系统还会注入一次“拆成较小写入”的纠偏提示。模型轮次接近上限时系统采用三段式“软着陆”先提醒停止探索并收尾再把可见工具收窄到write_file、edit_file、export_docx、export_pdf最后拒绝新的检索、读取和代码执行只保留交付物写入及任务状态维护。这里既在模型调用层缩小工具集合也在工具调用层阻断越界调用原因是仅从提示词里移除工具并不能保证模型不再调用历史中出现过的工具。StreamEventMapper则把 DeepAgents/LangGraph 的流式事件转换为前端既有事件协议并处理去重和部分乱序使内核替换不必同时推翻前端消费链。工作区不是一个抽象名词而是一套明确的文件协议。WorkspaceBackend以 MinIO 的workspace/{svid}/为事实源以当前任务的本地file_dir为写穿缓存写入和编辑同时落本地与 MinIO缓存未命中时再从 MinIO 懒加载目录列表以对象存储为准。路径会被归一化为工作区相对路径并拒绝..穿越。它把文件分成四类区域用途是否跨新一轮复制uploads/上传文件的 Markdown 阅读视图、需要保留的原件及解析图片是output/报告、图表、文档等最终交付物是scratch/中间文件和临时状态否manifest.json大文件或二进制对象的指针信息随工作区协议处理上传链路采用源码所称的offload-first策略workbench_impl.py把解析后的 Markdown 写进uploads/对 PDF、DOCX、XLSX 等文件还保留原件提示词只加入文件名、工作区路径、行数和图片数等指针不把整篇正文塞进上下文。Agent 需要内容时再调用read_file代码解释器需要表格或文档结构时使用原件。这样既能控制上下文长度也能保留程序化处理原文件的能力。每次新对话轮次都会创建新的 session-version 工作区。task_exec.py在创建工具前以 MinIO 服务端复制的方式把上一轮的uploads/、output/和顶层清单带到新svid但不复制scratch/随后再把需要代码处理的原件同步到本地缓存。这样“把上一轮报告转成 HTML”可以继续读取旧产物但代价是附件和产物会随轮次重复占用对象存储。长期运行时应为workspace/配置生命周期和容量监控不能只清理 Worker 本地缓存。代码执行有 Local 与 E2B 两条边界。加载器默认选择localLocalExecutor以file_dir为工作目录启动子进程并在超时后终止进程树。工作目录和超时能限制误操作范围却不是强安全沙箱代码仍继承 Worker 进程所在系统的文件权限、依赖和网络能力。E2bCodeExecutor把代码放进远程 E2B SandboxLinsight 将超时设为 3600 秒并复用 Sandbox。初始化时只把本地工作区中不超过 5 MB 的文件加入file_list这与上传链路可保留最高 50 MB 原件不是同一个上限。执行后的文件仍会通过local_sync_path同步回 Worker 本地目录但固定提交中的动态 working-set 方法仍返回空集合Linsight 构造解释器时也没有注入WorkspaceBackend因此不能宣称超大文件会按需从 MinIO 自动拉入 E2B或所有新产物都已通过 WorkspaceBackend 完整写回 MinIO。生产使用 E2B 时应把大文件 copy-in、output/copy-out、Sandbox 过期和重复执行列为独立验收项。4.3 Skills、模型、工具、MCP 与人机交互Linsight 的 Skills 会被物化到工作区的/skills目录通过中间件渐进加载旧 SOP 到 Skill 的迁移在 v2.6 仍需要按项目说明执行不能仅凭数据库升级就假定全部自动完成。如果用户为任务选择了知识库执行器会解析实际知识库 ID并只在白名单非空时注入搜索工具知识库搜索工具执行时还会再次拒绝白名单之外的 ID。这两次校验可以减少模型通过伪造参数越权访问其他知识库的机会。当 Agent 调用ask_user时LangGraph 进入interrupt。Linsight Worker 释放当前执行资源用户在工作台提交输入后任务重新入队并用同一thread_id的 checkpoint 继续。当前Redis checkpointer默认 TTL 为 7 天因此它比工作流的进程内MemorySaver更适合跨 Worker 或重启恢复但也不是无限期归档超过 TTL 的暂停任务、Redis 数据丢失和不完整备份仍会破坏恢复能力。模型层按角色区分llm、embedding、rerank、asr和tts。源码中可见本地推理、OpenAI 兼容接口和多个云厂商适配但各供应商支持的模型角色并不相同。部署时至少要先配置一个可用 LLM 和一个与知识库一致的 Embedding 模型Rerank 是质量增强项不是系统启动的硬前提。工具层有三种主要来源平台预置工具根据 OpenAPI 等信息构建的自定义 API 工具MCP 工具。MCP 管理器覆盖 SSE、stdio 和 Streamable HTTP 连接方式并把服务端工具转换为 LangChain 工具。工具能扩大 Agent 能力也同时扩大风险面代码解释器、Shell、文件系统、数据库写操作、外部 HTTP 和带密钥 API 都应分别配置权限、网络出口、超时和审计不能因为它们被封装成“工具”就视为安全。五、Docker Compose 部署与首次使用官方 README 给出的最低建议环境为 8 核 CPU、32 GB 内存Docker 不低于 19.03.9Docker Compose 不低于 1.25.1。由于当前栈同时运行 MySQL、Redis、Elasticsearch、Milvus、MinIO、OpenFGA、后端和 Worker低配机器即使能拉起容器也可能在文档解析或并发检索时出现内存压力。5.1 快速启动建议首先用官方仓库复现固定基线如果使用用户指定仓库也应检查提交哈希是否一致。gitclone https://github.com/dataelement/bisheng.gitcdbishenggitcheckout 0076f21220aadb037e0ec5104d5cbcfa24bc75a3cddockerdockercompose-fdocker-compose.yml-pbisheng up-d检查服务dockercompose-fdocker-compose.yml-pbishengpscurlhttp://localhost:7860/health浏览器访问http://服务器IP:3001官方 README 说明第一个注册的用户会成为管理员。公网部署时不要先把注册页面裸露出去再等待管理员注册应先通过安全组、反向代理或临时白名单限制入口。5.2 当前基础 Compose 到底启动了什么固定提交中的基础 Compose 包含 10 个持续运行服务和一个一次性迁移任务类别服务作用入口frontendNginx 与 Web 前端端口 3001应用backendFastAPI端口 7860异步backend_workerCelery、Beat 与 Linsight Worker业务数据mysql业务数据库同时承载默认 OpenFGA 数据库状态redis队列、缓存、消息和 checkpoint搜索elasticsearch关键词索引向量milvusStandalone 向量数据库向量依赖etcd、minioMilvus 元数据和对象存储MinIO 也供业务文件使用权限openfga关系授权服务初始化openfga-migrate一次性迁移 OpenFGA 数据库README 中提到的 OnlyOffice 不在当前基础docker-compose.yml中而是放在可选的docker-compose-office.ymlGPU 微调服务也位于单独的docker-compose-ft.yml。是否启动它们应以实际需求、镜像安全评估和资源容量为准。5.3 跑通第一个完整闭环容器全部Up只说明进程存活不说明模型与 RAG 已经可用。建议用一个很小但可复现的闭环验收注册管理员关闭或限制公开注册添加一个 LLM 和一个 Embedding 模型分别执行连通性测试建立测试知识库上传一份内容已知的短文档等待解析状态完成确认 MinIO、Milvus、Elasticsearch 均产生对应数据创建知识问答应用分别测试原词问题、语义改写问题和文档外问题检查答案引用是否指向正确文档片段创建普通用户验证无权知识库不能通过页面、API、工作流和 Agent 工具间接读取分别暂停一个工作流和 Linsight 任务测试正常续跑再在测试环境验证 Worker 重启后的差异。六、权限、生产化与适用边界真正把 BISHENG 放进企业环境难点通常不在“能否聊天”而在于默认口令、权限一致性、异步任务隔离、状态恢复、备份和外部工具治理。6.1 OpenFGA 细粒度授权链当前授权模型覆盖知识空间、知识库、文件夹、文件、工作流、助手、工具、渠道和仪表盘等资源主体包括用户、部门和用户组关系包括 owner、manager、editor、viewer 及派生的管理、编辑、读取、删除权限。PermissionService的实际检查顺序可概括为超级管理员快捷判断 → 租户可见性与子租户管理员判断 → 可缓存关系查询缓存 → OpenFGA Check → 在受限条件下做数据库创建者/隐式所有者回退 → 异常时拒绝安全敏感的can_manage、can_delete不走普通权限缓存其他可缓存关系存在短 TTL。这套设计减少每次调用 OpenFGA 的开销但用户组变更后的短暂缓存窗口仍应纳入运维预期。登录侧支持 Cookie 或 Bearer TokenJWT 携带租户与token_version禁用账号等动作可以通过递增版本使旧令牌失效。当前多租户配置默认关闭而 OpenFGA 默认启用。也就是说代码具备多租户相关结构不代表基础部署已经自动完成租户域名、SSO、网关隔离和计费治理。OpenFGA 解决的是“谁能访问或管理某个资源”需要人工批准的写操作则由统一审批中心承接。固定版本的核心链路可以概括为业务 Gate 判断是否需要审批 → 按 tenant_id 与 scenario_code 解析流程及当前版本 → 固化 payload/detail 快照创建 ApprovalInstance → 按节点和审批人创建 ApprovalTask → approve / reject / withdraw 更新实例与任务事实 → 最终通过时写 ApprovalOutbox → Celery 执行场景 Handler产生真正业务副作用ApprovalCenterService把approval_instance和approval_task作为审批状态事实源站内信只负责提醒和跳转不能反推审批是否完成。实例、任务、流程和 Outbox 都带租户边界详情和操作时仍会检查实例租户、申请人或审批人身份。审批最终通过后先创建ApprovalOutbox再投递execute_approval_outboxCelery 任务把“审批状态已落库”和“业务副作用已执行”拆开避免在一次请求里把两件事强耦合。流程修改也不是覆盖原记录。ApprovalScenarioAdminService会停用当前版本新建带节点快照的流程版本已经发起的实例继续绑定创建时的flow_version_id新配置只影响后续申请。按照项目的发布契约审批通过也不能绕过原业务安全校验场景 Handler 在执行真正写操作前仍应重新检查资源状态、权限和业务不变量。审批只证明“人同意了”不证明目标资源仍处于可写状态。仓库仍保留标记为 deprecated 的旧部门知识库上传审批服务它属于兼容路径不应再被解释为当前统一审批架构。二次开发新审批场景时优先复用Gate → Instance/Task → Outbox → Handler并为 Handler 设计幂等键、可重试错误分类和执行审计否则 Outbox 重投可能把一次批准变成多次外部写入。6.2 上线前必须修改的默认项当前 Compose 是便于启动的开发/试用基线其中存在不应直接带入生产的配置MySQL root 密码为1234Redis 默认没有密码MinIO 默认访问密钥和秘密密钥均为minioadminCompose 内含静态网关 HMAC secretOpenFGA 使用可变的latest标签并开启 PlaygroundMySQL、Redis、Elasticsearch、Milvus、MinIO、OpenFGA 等多个基础设施端口映射到宿主机后端、Worker 和 Milvus 使用seccomp:unconfinedOnlyOffice 可选 Compose 中的默认 JWT 配置也需要单独审查。至少应执行以下加固更换数据库、Redis、MinIO、HMAC、JWT 和所有模型/API 密钥并通过 Secret 管理而不是提交到仓库只暴露反向代理入口基础设施放入私网关闭 OpenFGA Playground 和非必要端口配置 HTTPS、可信域名与BISHENG_CORS_ORIGINS。当前 CORS 默认是本机开发地址不应靠放宽为*解决跨域固定 OpenFGA 和其他关键镜像的版本或 digest先在预发布环境做迁移和兼容验证对高风险工具应用最小权限隔离文件目录和网络出口限制超时、并发、输出大小和密钥可见范围评估并收紧seccomp:unconfined尤其是允许执行代码或 Shell 的场景打开操作审计、模型调用和工具调用日志同时对提示词、文件内容与密钥做脱敏。6.3 并发与可靠性不能只看 Worker 参数基础入口脚本中合并 Celery Worker 使用线程池并设置较高并发Linsight Worker 也有自己的并发参数。但“线程数 100”不等于能并行处理 100 个大文档、100 个 OCR 或 100 个长上下文模型请求。真实容量同时受制于Python 任务是 I/O 密集还是 CPU 密集文档大小、页数、OCR 服务能力与解析超时模型服务的 RPM、TPM、上下文长度、首 Token 时延Milvus、Elasticsearch、MySQL 和 Redis 的连接池Agent 工具调用和代码沙箱的资源占用单机内存与容器 OOM 策略。生产环境更稳妥的做法是按队列拆分 Worker为解析、OCR、工作流、普通后台任务和 Linsight 分别设置资源限额与扩缩容指标并对模型和工具增加租户级限流。所有带副作用的节点都应设计幂等键防止 Celery 重试或人工续跑造成重复写入。6.4 备份、恢复和升级完整备份至少覆盖 MySQL、Redis 中需要恢复的 checkpoint/队列状态、MinIO、Milvus、Elasticsearch 以及 OpenFGA 数据。只备份 MySQL 无法恢复知识索引和原文件只备份对象存储也无法恢复权限关系和应用配置。建议将恢复演练写成流程停写或做一致性快照 → 备份各状态组件 → 在隔离环境恢复 → 核对用户与权限 → 抽样验证原文件、向量、关键词索引 → 恢复暂停中的 Agent / 工作流测试 → 验证应用 API 与引用升级前要同时检查数据库迁移、配置项、前后端镜像版本、OpenFGA 模型、Embedding 模型和索引兼容性。更换 Embedding 模型后旧向量通常不能直接与新向量混用应安排重建索引并做召回回归测试。6.5 适用与不适用场景BISHENG 比较适合内部知识助手、制度/合同检索、客服辅助、研究与报告生成、带人工输入的业务工作流以及需要统一管理模型和工具的团队。它提供了较完整的二次开发骨架尤其适合愿意维护 Python、React 与多种中间件的组织。但以下需求不能只靠默认配置解决严格监管行业的全链路合规、跨地域高可用、长期流程状态的强一致恢复、完全离线的多格式高精度解析、无人工监督的高风险写操作以及“任何模型接上都能稳定回答正确”。这些都需要额外的基础设施、评测、权限设计和运行治理。七、总结BISHENG 的核心不是某一个聊天组件而是三条链路的组合知识库用解析、混合检索和引用把企业数据接入模型可视化工作流用 LangGraph 状态图表达确定性流程Linsight 用 DeepAgents、Skills、工具、子 Agent 和 Redis checkpoint 处理更开放的目标。OpenFGA 再把用户、部门、用户组与应用资源联系起来。从源码角度最值得记住的几个边界是模型 Rerank 可选当前工作流 checkpoint 在进程内而 Linsight checkpoint 在 Redis 且默认保存 7 天基础 Compose 是单机基线不是高可用方案README 的企业能力与当前开源基础部署不能完全画等号生产上线前必须重做默认密钥、网络暴露、工具权限、备份恢复和容量验证。参考资料BISHENG GitHub 仓库https://github.com/cmyk-labs/bishengBISHENG 官方 GitHub 仓库https://github.com/dataelement/bishengBISHENG 官方网站https://www.dataelem.com/BISHENG 官方文档https://dataelem.feishu.cn/wiki/ZxW6wZyAJicX4WkG0NqcWsbynde
