BiSheng LLM Application DevOps Platform

Version 2.5.1 introduces a transition from a flat multi-tenant model to a Tenant Tree Architecture. This architecture is specifically designed for private deployment scenarios within large organizations (e.g., parent companies and their subsidiaries).

Key architectural shifts include:

• Hierarchical Structure: Moving from flat tenants to a tree-based model.
• Simplified Data Model: Removal of tenant_path, level, and tenant_kind in favor of a streamlined model.
• Root Tenant Constraints: The Root tenant is automatically created and is immutable (cannot be deleted or disabled).
• Isolation Strategies: Enhanced tenant isolation for LLM resources and shared storage.

BiSheng (v2.5.0+) is an open-source LLM application DevOps platform designed for enterprises. It is built using a stack of FastAPI, React, and LangGraph. The platform utilizes a Domain-Driven Design (DDD) architecture organized into over 15 domain modules.

Key capabilities include:

• Workflow orchestration
• Knowledge Base / RAG (Retrieval-Augmented Generation)
• Multi-Agent collaboration (Linsight)
• MCP (Model Context Protocol) integration
• Model evaluation and fine-tuning
• Multi-tenant isolation

The bisheng-gateway is a commercial extension suite for BiSheng. It acts as a Java-based gateway layer deployed between the frontend and the backend. Its primary responsibilities include:

• SSO/OAuth Unified Authentication: Managing single sign-on and OAuth2 flows.
• Content Security Review: Filtering sensitive words in requests and responses.
• Traffic Control: Implementing rate limiting and online session counting.
• API Reverse Proxy: Routing requests to the BiSheng backend.

It is an independent Java project with its own database tables (prefixed with gt_*) and configuration, communicating with the BiSheng backend via HTTP.

Use the following directory structure to locate specific types of information within the BiSheng repository:

• Development Standards: Found in the root directory (e.g., constitution.md, SDD-Guide.md).
• System Architecture: Detailed subsystem documentation is located in the architecture/ directory.
• Feature Documentation: Organized by version and feature ID in the ../features/ directory (e.g., v{X.Y.Z}/{NNN}-{name}/).
• API Reference: Interface documentation for filelib retrieval, knowledge spaces, and knowledge bases is in the api/ directory.
• Deployment: Private/On-premise deployment guides are in the 私有化部署/ directory.
• Observability: Metric and log contracts (BS_METRIC) are in the observability/ directory.

The v2.6.0 release aims to unify cross-module product capabilities, such as the Approval Center.

Key features in this version include:

• F025: approval-center-unification: Unification of the approval center (Priority: P0).
• F028: conversation-export-import: Ability to export workspace conversation answers and import them into knowledge spaces (Priority: P0).

Linsight (灵思) is BiSheng's built-in autonomous task execution framework designed for complex scenarios requiring multi-step reasoning, tool calling, and human-in-the-loop interaction. It uses SOPs (Standard Operating Procedures) to decompose user requirements into structured task trees.

Key features include:

• SOP-driven execution: Decomposes tasks into structured steps.
• MCP Integration: Supports Model Context Protocol for unified external tool access via SSE, Standard I/O, and Streamable HTTP.
• Worker Architecture: Decoupled execution using a Redis-based FIFO queue and independent Worker processes.
• Human-in-the-loop: Supports pausing execution to wait for user input and resuming via continue_task().

BiSheng supports third-party organization synchronization (OrgSync) to automatically import department trees and employee information from platforms like Feishu, WeCom, or DingTalk.

Key Capabilities:

• Automated Management: Automatically creates departments, users, and membership relationships.
• Permission Maintenance: Automatically maintains OpenFGA permission tuples via DepartmentChangeHandler.
• Lifecycle Handling: Manages personnel changes (transfers, new hires) and departures (disabling accounts, cleaning permissions).
• Execution Modes: Supports both manual triggers and scheduled synchronization via Cron expressions.
• Architecture: Uses a Provider + Reconciler pattern. Providers fetch standardized data, while the Reconciler compares it with local data to generate change operations.

The ReBAC system uses a permission pyramid where higher-level roles inherit the capabilities of lower-level roles.

Hierarchy:

• owner: Can view + edit + manage + delete
• manager: Can view + edit + manage
• editor: Can view + edit
• viewer: Can view

Computed Relations:

• can_manage is equivalent to manager and its parents.
• can_edit is equivalent to editor and its parents.
• can_read is equivalent to viewer and its parents.

Deletion Logic (can_delete):

• Top-level resources (knowledge_space, workflow, assistant, tool, channel, dashboard): Only the owner can delete.
• Hierarchical resources (folder, knowledge_file): The owner OR anyone with can_manage from a parent can delete.