统一审批中心F025BISHENG 审批网关、流程版本化与旧审批链路收敛实战【免费下载链接】bishengBISHENG is an open LLM devops platform for next generation Enterprise AI applications. Powerful and comprehensive features include: GenAI workflow, RAG, Agent, Unified model management, Evaluation, SFT, Dataset Management, Enterprise-level System Management, Observability and more.项目地址: https://gitcode.com/GitHub_Trending/bi/bisheng导读本文围绕 BISHENG v2.6.0 的 F025「统一审批中心与旧审批链路收敛」特性展开系统讲解其从需求拆解到落地执行的完整路径通用审批中心的数据模型与 Repository 分层、ApprovalGate审批网关的 PASS / PENDING / EXCEPTION 决策语义、条件分支与流程版本化机制、菜单权限申请这一高要求主场景以及频道订阅、知识空间订阅旧消息审批链路的迁移和部门知识空间上传审批的下线。读者读完可掌握 BISHENG 审批中心 25 个开发任务T001–T017的完整执行计划、测试优先开发模式、MySQL / 达梦双库兼容约束以及如何在业务模块中通过ApprovalGate.request_or_pass()低成本接入新的审批场景。一、为什么需要统一审批中心BISHENG 在 F025 之前审批能力散落在多个业务模块中菜单权限申请仅有空白占位页、频道订阅通过send_generic_approval走旧站内信消息审批、知识空间加入依赖旧request_knowledge_space消息作为事实来源、部门知识空间文件上传则绑定在历史approval_request表上。这些链路各自实现了消息 状态 重试样板逻辑审批上下文割裂、无统一进度查询、无法配置化且approval_request强绑定部门知识空间上传字段无法表达场景、分支、节点、异常、outbox 等通用能力。F025 的核心理念是用一套通用审批中心替代分散的审批实现研发预置场景目录handler、条件字段、审批人来源与代码能力一致管理员只做租户级配置启停、条件分支、顺序节点、异常处理业务模块只接ApprovalGate.request_or_pass()与场景 handler 协议。架构决策 AD-01 明确选择新建通用中心表并下线历史部门知识空间上传审批选项 BAD-02 明确场景目录来源采用研发预置 管理员选择选项 BAD-03 明确审批事实来源为approval_instanceapproval_task而非站内信消息选项 BAD-04 明确业务执行通过approval_outbox异步执行并支持重试选项 BAD-05 明确流程变更通过创建实例时快照版本隔离影响选项 B。范围边界本次纳入主版本的能力包括审批中心核心域模型、审批管理页、我的审批、我的申请、异常流程列表、站内信提醒、菜单权限申请、频道订阅审批、知识空间加入/订阅审批明确排除知识空间创建审批、知识空间文件发布审批与首钢分支差异化流程同步移除部门知识空间文件上传审批。二、任务全景25 个任务的结构与依赖features/v2.6.0/025-approval-center-unification/tasks.md将整个特性拆解为25 个自包含任务T001–T017含 A/B/C 子任务按基础设施 → 后端核心服务 → API 层 → 主场景 → 旧链路迁移 → 前端 → 文档七个板块组织板块任务核心产出基础设施与 Domain 模型T001 / T002A / T002B11 张表 ORM、Alembic 迁移、4 个 Repository、网关/流程单测后端核心服务T003 / T004 / T005 / T006ApprovalGate、ApprovalRegistry、流程运行时、异常服务、outbox后端 API 层T007 / T008 / T008A用户端/管理端接口、路由注册、MySQL/达梦双库验证菜单权限申请主场景T009 / T010菜单 handler、个人菜单授权服务、错误码扩展部门上传审批下线T010A / T010BReBAC 回归测试、移除旧上传审批链路旧审批链路迁移T011 / T012 / T013 / T014频道订阅、知识空间订阅迁入审批中心前端 ClientT015A / T015B / T015C工作台我的审批/我的申请、业务入口返回态适配前端 PlatformT016A / T016B / T016C审批管理页、分支/流程/节点配置、异常列表版本文档更新T017release-contract 与版本索引登记任务依赖形成清晰的拓扑T001/T002A → T002B → T003 → T004 → T005 → T006 是后端主线T008 依赖 T007T008A 依赖 T002B T008T009/T010 依赖 T006T010A/T010B 依赖 T002BT011/T012 依赖 T006 T010BT013/T014 依赖 T006 T010B前端任务依次依赖各自后端完成。三、开发模式测试优先、迁移式开发与双库约束tasks.md 明确了六条开发纪律是整个特性落地质量的关键后端 Test-First审批网关、流程流转、异常处理、菜单授权与业务接入改造全部先写测试再补实现。例如 T003 在实现前先给出 7 个网关测试场景未配置/未启用报错、直通 PASS、命中流程 PENDING、重复 business_key 返回已有实例、route_missing 与 approver_empty 异常创建。前端 Test-AlongsidePlatform 以手动验证为主源码结构可补轻量 source-inspection 测试避免大面积 UI 回归。迁移式开发频道订阅、知识空间加入等旧消息审批链路需完成新旧切换部门知识空间文件上传审批直接移除上传路径回归 ReBAC 权限校验。双库约束除 sqlite 单元测试外审批中心表结构与迁移必须补 MySQL / 达梦方言验证T008A禁止实现后再补兼容。列优先于 JSON凡审批列表筛选、待办检索、异常处理、重复判定所需字段必须建显式列不得只放payload_snapshot/detail_snapshot再靠 JSON SQL 查询。自包含任务每个任务写明文件、逻辑、测试和 AC 覆盖实现阶段不必反复回读 spec。执行阶段分五步推进先落通用中心模型和审批网关新场景可创建实例、任务和异常→ 再落管理端配置与用户端查询跑通场景 → 分支 → 流程 → 节点 → 详情主链路→ 接菜单权限申请新场景里对数据模型要求最高的一条线→ 移除部门知识空间上传审批统一上传权限口径→ 最后迁移频道订阅和知识空间订阅并补站内信、审计、异常处理联调。四、基础设施11 张表与 Repository 分层4.1 数据模型T002A按 spec §5 新建 11 张 SQLModel 表全部带tenant_id、create_time、update_time表说明approval_scenario租户下某个预置场景的启停与展示配置approval_route_rule场景下的条件分支规则按sort_order顺序匹配approval_flow_definition流程定义头按场景归属approval_flow_version流程版本快照保存完整 DSL JSONapproval_node_definition某流程版本内的顺序节点定义approval_instance一次审批申请实例承载scenario_code、business_key、payload 快照、当前状态approval_task分配给审批人的节点待办支持pending/approved/rejected/skipped/cancelledapproval_action_log审批详情时间线用于谁在何时做了什么approval_exceptionroute_missing、approver_empty、execute_failed异常记录scenario_disabled已移除改为直接报错approval_outbox审批通过后的业务执行队列支持状态、重试次数、错误摘要user_menu_access用户级菜单授权表保存审批授予与撤回状态关键实现约束JSON 字段使用JsonType仓库统一的bisheng.core.database.dialect_helpers时间戳使用UPDATE_TIME_SERVER_DEFAULT不写 MySQL 专属 DDL迁移守卫使用 SQLAlchemyinspect()而不是information_schema。approval_route_rule必须包含enabled BOOLEAN NOT NULL DEFAULT 1字段_match_first_route依赖它跳过禁用分支。从源码看ApprovalInstance还额外建立了去重联合索引idx_approval_instance_dedupe_lookuptenant_id scenario_code business_key applicant_user_id服务于 AC-05 幂等判定见 approval_instance.py。4.2 状态机源码确认审批实例状态与任务状态在仓库中已落地为常量枚举approval_instance.py实例状态pending、approved、executing、executed、rejected、exception、withdrawn、cancelled、execute_failed任务状态pending、approved、rejected、skipped、cancelled异常类型route_missing、approver_empty、execute_failedscenario_disabled已移除场景未配置/未启用直接报错 18106outbox 状态pending、success、failed4.3 Repository 分层T002B审批中心后端默认走api - service - repository - database不再以 DAO 作为新功能首选数据访问层。四个 Repository 的职责分工Repository文件职责ApprovalScenarioRepositoryapproval_scenario_repository.py场景、分支、流程定义、流程版本、节点配置读写ApprovalInstanceRepositoryapproval_instance_repository.py审批实例、审批任务、异常、action log、outbox 读写UserMenuAccessRepositoryuser_menu_access_repository.py用户菜单授权写入、查询、撤回ApprovalQueryRepositoryapproval_query_repository.py我的审批、我的申请、异常列表、详情聚合查询T001 单测要求通过 repository 而非直接调用 DAO 风格入口验证主链路覆盖四类场景场景未配置/未启用触发ApprovalScenarioDisabledError、命中免审批分支只建实例不建任务、命中审批流程建实例 首节点任务、重复business_key命中已有实例。五、后端核心服务审批网关、流程运行时与异常处理5.1ApprovalGate.request_or_pass()T003/T004网关是业务模块接入审批中心的唯一入口。从源码看approval_gate.py其调用顺序为重复申请检查按tenant_id scenario_code business_key applicant_user_id查询活跃实例命中则直接返回已有实例 ID 及对应决策AC-05不创建新实例handler 详情构建通过registry.get_handler(scenario_code)取 handler先构建detail_snapshot与业务标题用于展示不参与筛选场景启停校验查不到场景或enabledfalse直接抛ApprovalScenarioDisabledError18106前端展示此功能未开放申请不创建任何实例、任务或 outboxAC-02分支匹配按sort_order自上而下调用_match_first_route命中即停空match_config表示无条件始终命中enabledfalse的分支被跳过决策返回命中pass分支 → 创建实例走approved - executing - executed不建任务AC-03命中flow分支 → 创建实例 首节点任务返回PENDINGAC-04无分支命中 → 创建route_missing异常AC-15。其中_get_user_role_labels实现了条件字段applicant_role的身份标签解析PRD §4.3 包含即命中语义固定标签admin系统超管、tenant_admin租户管理员、dept_admin部门管理员、regular_user兜底动态标签role_{id}对应当前租户系统角色允许多标签并存。5.2 场景预置目录T004ApprovalRegistry.with_default_presets()注册三个主版本场景approval_registry.pyscenario_codescenario_namecondition_fieldsapprover_source_typesmenu_access_request菜单权限申请[applicant_role, menu_key][direct_user, department_admin]channel_subscribe_request频道订阅审批[applicant_role][direct_user, department_admin, channel_owner, channel_manager]knowledge_space_subscribe_request知识空间加入审批[applicant_role][direct_user, department_admin, knowledge_space_owner, knowledge_space_manager]管理员新增场景时只能从该预置目录下拉选择名称同租户内scenario_code唯一AC-01避免配置层写入技术字段。5.3 流程运行时与异常处理T005/T006T005 的测试矩阵覆盖了全部节点流转语义或签一个审批人通过后节点即通过其余未处理任务变skippedAC-08会签所有审批人都同意才通过节点任一人拒绝则实例进入rejectedAC-09拒绝终止实例进入rejected后续节点不再生成AC-13撤回实例进入withdrawn所有pending任务变cancelledAC-14异常处理route_missing可指定流程继续approver_empty可指定审批人继续 / 跳过节点 / 取消审批AC-15/AC-16执行失败execute_failed重试成功进入executed重试失败保留状态并累计次数审批结论不回退AC-18审批人 rebind审批人被停用时重新按节点配置解析审批人成功则取消旧pending任务并生成新任务失败则进入approver_empty异常AC-33。ApprovalCenterService、ApprovalExceptionService、ApprovalOutboxService统一通过 repository 编排实例、任务、异常、outbox、action log 数据访问关键动作同时写approval_action_log与auditlogAC-28。outbox 异步执行与重试对应 worker/approval/tasks.py 中的execute_approval_outbox、retry_approval_outbox、rebind_approval_approver_on_user_disabled任务所有任务参数必须带tenant_id执行前恢复current_tenant_id。5.4 Handler 协议spec §7.2旧message.domain.services.approval_handler.ApprovalHandler仅有get_action_code()/on_approved()/on_rejected()无法承载新中心所需的标题、详情、审批人解析和撤回逻辑。F025 新增统一 handler 基类ApprovalScenarioHandler业务 handler 只需实现以下抽象方法class ApprovalScenarioHandler(ABC): scenario_code: str abstractmethod async def validate(self, req: ApprovalGateRequest, login_user: UserPayload) - None: ... abstractmethod async def build_title(self, req: ApprovalGateRequest) - str: ... abstractmethod async def build_detail(self, req: ApprovalGateRequest) - dict: ... abstractmethod async def build_business_link(self, req: ApprovalGateRequest) - dict: ... abstractmethod async def resolve_approvers(self, node_config: dict, req: ApprovalGateRequest) - list[int]: ... abstractmethod async def on_approved(self, instance_id: int, payload_snapshot: dict) - dict: ... async def on_rejected(self, instance_id: int, payload_snapshot: dict, reason: str | None) - None: ... async def on_withdrawn(self, instance_id: int, payload_snapshot: dict, reason: str | None) - None: ...三个业务场景的 handler 映射为menu_access_request→MenuAccessApprovalHandler新增负责菜单申请校验、详情、个人菜单授权、授权撤回channel_subscribe_request→ChannelSubscribeScenarioHandler复用并扩展现有激活/拒绝逻辑knowledge_space_subscribe_request→KnowledgeSpaceSubscribeScenarioHandler复用并扩展成员激活与权限同步逻辑。六、API 层与双库兼容验证6.1 用户端与管理端接口分离T007/T008用户端与管理端接口分离实现Endpoint 只调用 service 不直接访问 ORM / DAO统一resp_200包装使用UserPayload做认证与管理员校验。用户端接口包括GET /api/v1/approval/my-tasks我的审批列表、GET /api/v1/approval/my-tasks/{task_id}审批详情、POST /api/v1/approval/tasks/{task_id}/decision同意/拒绝、GET /api/v1/approval/my-requests我的申请列表、GET /api/v1/approval/instances/{instance_id}实例详情、POST /api/v1/approval/instances/{instance_id}/withdraw撤回、POST /api/v1/approval/instances/{instance_id}/resubmit重新提交、POST /api/v1/approval/menu-access/apply菜单申请、POST /api/v1/approval/menu-access/{instance_id}/revoke-grant授权撤回。管理端接口按场景管理预置目录 / 场景 CRUDscenario_code不可修改对应 AC-34、条件分支管理CRUD PATCH .../routes/reorder排序、流程与节点管理PUT /admin/flows/{flow_id}/nodes提交全量节点列表并触发新版本生成、异常流程处理retry / assign-approver / assign-flow / skip-node / cancel五个分组列表接口统一PageData[T]分页包装page默认 1、page_size默认 20。路由注册见 approval/api/router.pyuser / admin / legacy 三个子 router 统一纳入。6.2 错误码表源码确认 18100–18117spec §6.4 规划了 18100–18110仓库实际实现已扩展到18117common/errcode/approval.pyCodeError Class场景18100ApprovalRequestNotFoundError实例/任务不存在18101ApprovalRequestPermissionDeniedError无权限查看或处理18102ApprovalRequestAlreadyProcessedError任务已处理/实例不可重复操作18103ApprovalRejectReasonRequiredError驳回/取消未填必填原因18104ApprovalHandlerNotRegisteredError场景目录中找不到 handler18105ApprovalScenarioDuplicateError场景重复创建18106ApprovalScenarioDisabledError场景未配置或未启用前端展示此功能未开放申请18107ApprovalRouteNotMatchedError分支未命中网关内部抛转 exception18108ApprovalApproverEmptyError审批人解析为空网关内部抛转 exception18109ApprovalDuplicatePendingError存在重复申请18110ApprovalGrantNotRevokableError授权撤回条件不满足18111ApprovalMenuApplyDisabledError菜单审批模式关闭时绕过前端调用申请接口18112ApprovalSettingsPermissionDeniedError仅超管可修改审批设置18113–18115ApprovalRetryNoFlowRouteError等异常重试时无启用分支 / 无 active 流程版本 / 流程无节点18116ApprovalFlowNotFoundError流程不存在18117ApprovalFlowInUseByRoutesError流程已被分支引用需先解除绑定再删除6.3 双库兼容验证T008AT008A 是 F025 独有的方言级测试任务对应 test_approval_dialect_compat.py验证JsonType、UPDATE_TIME_SERVER_DEFAULT、主键自增、索引与迁移守卫在 MySQL / 达梦下都成立。spec §5.6 明确了五条必须遵守的风险结论风险 1payload_snapshot、detail_snapshot、流程 DSL 只用于详情展示、审计回放与 handler 上下文不承担列表筛选、排序、唯一性判断风险 2所有update_time走UPDATE_TIME_SERVER_DEFAULT不在 alembic 中写ON UPDATE CURRENT_TIMESTAMP风险 3AC-05 重复申请判定基于事务内查询 状态判断不依赖复杂方言相关的唯一索引风险 4审批待办查询以approval_task一人一行为准不引入审批人列表 JSON做待办过滤风险 5表/列/索引探测统一复用 SQLAlchemyinspect()或仓库 helper不写 MySQL 元数据 SQL。七、主场景菜单权限申请T009/T010菜单权限申请是 F025 中最独特、对数据模型要求最高的一条线核心决策 AD-07审批通过只给申请人写个人菜单授权user_menu_access不修改角色菜单与角色菜单做并集父级依赖菜单自动补齐。测试覆盖T009对应 test_menu_access_approval.pymenu_approval_modetrue且场景启用 → 创建menu_access_request审批返回PENDINGAC-24menu_approval_modefalse且无菜单权限 → 前端不展示申请入口直接调用申请接口被拒绝18111且不创建审批实例AC-32后端不能绕过批准后写入user_menu_access个人授权AC-24撤回授权后记录 revoke 状态AC-25。T010 实现要点新建菜单申请 handlervalidate / build_title / build_detail / on_approved / on_rejected / on_withdrawn / revoke_grant 完整协议、新增UserMenuAccessService与授权撤回逻辑、扩展approval.py错误码。授权撤回仅允许当前审批人、历史审批人、管理员执行审批通过后的业务动作仍调用原业务权限/存在性校验审批通过不等于绕过业务安全检查spec §7.4。八、旧链路迁移与能力收敛8.1 部门知识空间上传审批下线T010A/T010B历史部门知识空间文件上传审批在本版本直接移除部门知识空间上传与普通知识空间上传链路一致只校验现有 ReBAC 上传权限新上传请求不创建approval_request、审批消息或审批中心实例AC-31。approval_request标记为历史只读兼容对象不再被新上传流程写入。T010A 回归测试test_department_knowledge_space_upload_permission.py断言有上传权限 → 上传直接成功且不创建审批相关记录无上传权限 → 直接拒绝且不创建approval_request。8.2 频道订阅审批迁移T011/T012channel_service.subscribe_channel()从直接改成员状态并发send_generic_approval切换为调用ApprovalGate.request_or_pass()AC-26PENDING 时业务暂停APPROVED 后由ChannelSubscribeScenarioHandler激活成员关系REJECTED 置为rejected。旧ChannelSubscribeApprovalHandler逻辑抽到新 scenario handlerlegacy message handler 仅标记兼容用途、保留历史消息跳转。集成测试见 test_channel_subscription_approval_integration.py。8.3 知识空间加入/订阅审批迁移T013/T014知识空间加入/订阅入口切换为knowledge_space_subscribe_request进入审批中心AC-27不再以旧request_knowledge_space消息为事实来源。新 handler 复用现有成员激活 ReBAC 授权同步逻辑测试覆盖审批创建、通过后成员激活与权限同步、拒绝后状态回写、历史消息兼容跳转见 test_knowledge_space_subscription_approval_integration.py。九、前端落地Client 工作台与 Platform 审批管理9.1 Client 工作台T015A/T015B/T015C工作台src/frontend/client/src/路由基础路径/workspace承担我的审批、我的申请、消息提醒三个前台入口挂在左下角用户菜单layouts/UserPopMenu.tsx中沿用~/api/*、useLocalize()、Recoil/store 与现有Dialog/Tabs/DropdownMenu组件体系不引入 Platform 的controllers/API与 Zustand。推荐形态为用户菜单 → 弹窗/抽屉 → 左列表 右详情T015A新增入口 封装全部 Client 审批 APIlistMyApprovalTasksApi、decideApprovalTaskApi、listMyApprovalInstancesApi、withdrawApprovalInstanceApi、resubmitApprovalInstanceApi、applyMenuAccessApi、revokeMenuGrantApi点击审批类站内信消息只做跳转定位不含快捷审批按钮审批事实以审批中心数据为准AC-23T015B我的审批弹窗左列表待我审批 / 我已处理 右详情业务内容 审批进度 操作区或签/会签状态正确展示非本人待办只读AC-20T015C我的申请弹窗列表 详情 撤回/重新提交execute_failed展示失败原因菜单占位页入口仅在menu_approval_modetrue且无权限时出现频道订阅/知识空间加入接口接审批返回态PENDING → 提示已提交DISABLED → 此功能未开放申请菜单授权场景展示撤回授权二次确认弹窗AC-21/AC-24/AC-26/AC-27/AC-32。9.2 Platform 审批管理T016A/T016B/T016C管理后台src/frontend/platform/src/承担审批管理页与异常流程列表页面入口已落地为pages/ApprovalPage/index.tsx沿用/controllers/API/*、useTranslation()、bs-ui组件体系T016A场景管理——列表展示名称 启停、新增弹窗下拉选预置场景、场景 DELETE、scenario_code不可修改校验AC-34T016B条件分支 CRUD/启停/上下移动PATCH reorder 流程节点列表 CRUD/排序PUT 全量节点列表 流程预览弹窗GET /admin/flows/{flow_id}/versions/{version_id}获取快照AC-35。条件值 UI 规则AC-36/AC-37非常关键条件字段下拉按当前场景condition_fields过滤applicant_role申请人身份展示枚举下拉系统管理员 / 租户管理员 / 部门管理员 当前租户系统角色列表动态调角色列表接口menu_key申请菜单展示可申请菜单下拉动态加载不能自由文本输入space_type知识空间类型展示固定枚举公共 / 部门 / 团队T016C异常流程列表支持route_missing/approver_empty/execute_failed三类处理动作弹窗审计页加入approval模块筛选与approval.*动作文案备注列兼容结构化日志 reason metadata 摘要AC-28。双端边界Client 只承担我的审批/我的申请/消息提醒/发起申请/审批详情/审批人处理Platform 只承担场景、分支、流程、节点、异常列表与后台审计筛选。两端共享同一后端审批中心数据但不共享前端实现代码站内信只在 Client 侧呈现。十、验收标准AC与任务映射速查tasks.md 为每个任务标注了 AC 覆盖汇总如下便于核对与追踪AC语义主要任务AC-01预置场景目录、scenario_code 唯一T004/T008/T016AAC-02场景未配置/未启用直接报错 18106T001/T003/T004/T008AC-03免审批分支直通不建任务T001/T003/T004/T008AC-04命中流程建实例 首节点任务T001/T003/T004/T008AC-05重复 business_key 幂等返回已有实例T001/T002B/T003/T004/T008AAC-06~AC-10分支顺序匹配、顺序节点、或签、会签、流程版本化T005/T006/T007/T008/T016BAC-11~AC-14同意推进、末节点同意出 outbox、拒绝终止、撤回T005/T006/T008AC-15/AC-16route_missing / approver_empty 异常T003/T005/T006/T008/T016CAC-18/AC-19execute_failed 重试、异常取消T005/T006/T008/T016CAC-20~AC-23我的审批/我的申请/审批管理/消息跳转T007/T008/T015A/T015B/T015C/T016AAC-24/AC-25菜单申请授权、授权撤回T009/T010/T015CAC-26/AC-27频道订阅、知识空间订阅迁移T011/T012/T013/T014AC-28/AC-29审计与多租户隔离T006/T008/T016CAC-30MySQL/达梦双库兼容T002B/T008/T008AAC-31部门知识空间上传回归 ReBACT010A/T010BAC-32菜单审批模式关闭无入口且后端拒绝T009/T010/T015CAC-33审批人停用 rebindT005/T006AC-34scenario_code 不可修改T008/T016AAC-35流程版本快照预览T008/T016BAC-36/AC-37条件字段/条件值 UI 联动规则T016B十一、执行完成后的收尾版本契约与实际偏差记录T017 要求在所有功能完成后更新features/v2.6.0/release-contract.md登记 F025 领域对象 Owner、模块编码 181 的变更历史与features/v2.6.0/README.md补充 F025 索引条目。同时 tasks.md 末尾保留了实际偏差记录区块要求实现完成后在此记录与 spec.md 的偏差供后续版本参考——这是本仓库 feature 流程计划 → 实现 → 对账闭环的最后一环。总结F025 统一审批中心是 BISHENG v2.6.0 的 P0 能力其价值在于把审批从每个业务按钮里写死的样板逻辑升级为租户级可配置的通用能力研发只需注册预置场景、组装 payload、实现 handler 协议管理员即可通过条件分支、顺序节点、或签/会签和异常处理管理审批流程。从仓库现状看F025 已从任务清单落地为可运行的实现——approval_gate.py 网关、approval_registry.py 预置目录、approval_instance.py 状态机与模型、errcode/approval.py 错误码、test/approval 下的 16 个测试文件以及 ApprovalPage 管理页均已就位与 tasks.md 的任务拆解一一对应。对于后续新增审批场景标准接入路径是在ApprovalRegistry注册 preset → 实现ApprovalScenarioHandler子类 → 业务入口调ApprovalGate.request_or_pass()→ 前端业务接口接审批返回态——无需再复制消息 状态 重试样板逻辑。【免费下载链接】bishengBISHENG is an open LLM devops platform for next generation Enterprise AI applications. Powerful and comprehensive features include: GenAI workflow, RAG, Agent, Unified model management, Evaluation, SFT, Dataset Management, Enterprise-level System Management, Observability and more.项目地址: https://gitcode.com/GitHub_Trending/bi/bisheng创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
统一审批中心（F025）：BISHENG 审批网关、流程版本化与旧审批链路收敛实战
统一审批中心F025BISHENG 审批网关、流程版本化与旧审批链路收敛实战【免费下载链接】bishengBISHENG is an open LLM devops platform for next generation Enterprise AI applications. Powerful and comprehensive features include: GenAI workflow, RAG, Agent, Unified model management, Evaluation, SFT, Dataset Management, Enterprise-level System Management, Observability and more.项目地址: https://gitcode.com/GitHub_Trending/bi/bisheng导读本文围绕 BISHENG v2.6.0 的 F025「统一审批中心与旧审批链路收敛」特性展开系统讲解其从需求拆解到落地执行的完整路径通用审批中心的数据模型与 Repository 分层、ApprovalGate审批网关的 PASS / PENDING / EXCEPTION 决策语义、条件分支与流程版本化机制、菜单权限申请这一高要求主场景以及频道订阅、知识空间订阅旧消息审批链路的迁移和部门知识空间上传审批的下线。读者读完可掌握 BISHENG 审批中心 25 个开发任务T001–T017的完整执行计划、测试优先开发模式、MySQL / 达梦双库兼容约束以及如何在业务模块中通过ApprovalGate.request_or_pass()低成本接入新的审批场景。一、为什么需要统一审批中心BISHENG 在 F025 之前审批能力散落在多个业务模块中菜单权限申请仅有空白占位页、频道订阅通过send_generic_approval走旧站内信消息审批、知识空间加入依赖旧request_knowledge_space消息作为事实来源、部门知识空间文件上传则绑定在历史approval_request表上。这些链路各自实现了消息 状态 重试样板逻辑审批上下文割裂、无统一进度查询、无法配置化且approval_request强绑定部门知识空间上传字段无法表达场景、分支、节点、异常、outbox 等通用能力。F025 的核心理念是用一套通用审批中心替代分散的审批实现研发预置场景目录handler、条件字段、审批人来源与代码能力一致管理员只做租户级配置启停、条件分支、顺序节点、异常处理业务模块只接ApprovalGate.request_or_pass()与场景 handler 协议。架构决策 AD-01 明确选择新建通用中心表并下线历史部门知识空间上传审批选项 BAD-02 明确场景目录来源采用研发预置 管理员选择选项 BAD-03 明确审批事实来源为approval_instanceapproval_task而非站内信消息选项 BAD-04 明确业务执行通过approval_outbox异步执行并支持重试选项 BAD-05 明确流程变更通过创建实例时快照版本隔离影响选项 B。范围边界本次纳入主版本的能力包括审批中心核心域模型、审批管理页、我的审批、我的申请、异常流程列表、站内信提醒、菜单权限申请、频道订阅审批、知识空间加入/订阅审批明确排除知识空间创建审批、知识空间文件发布审批与首钢分支差异化流程同步移除部门知识空间文件上传审批。二、任务全景25 个任务的结构与依赖features/v2.6.0/025-approval-center-unification/tasks.md将整个特性拆解为25 个自包含任务T001–T017含 A/B/C 子任务按基础设施 → 后端核心服务 → API 层 → 主场景 → 旧链路迁移 → 前端 → 文档七个板块组织板块任务核心产出基础设施与 Domain 模型T001 / T002A / T002B11 张表 ORM、Alembic 迁移、4 个 Repository、网关/流程单测后端核心服务T003 / T004 / T005 / T006ApprovalGate、ApprovalRegistry、流程运行时、异常服务、outbox后端 API 层T007 / T008 / T008A用户端/管理端接口、路由注册、MySQL/达梦双库验证菜单权限申请主场景T009 / T010菜单 handler、个人菜单授权服务、错误码扩展部门上传审批下线T010A / T010BReBAC 回归测试、移除旧上传审批链路旧审批链路迁移T011 / T012 / T013 / T014频道订阅、知识空间订阅迁入审批中心前端 ClientT015A / T015B / T015C工作台我的审批/我的申请、业务入口返回态适配前端 PlatformT016A / T016B / T016C审批管理页、分支/流程/节点配置、异常列表版本文档更新T017release-contract 与版本索引登记任务依赖形成清晰的拓扑T001/T002A → T002B → T003 → T004 → T005 → T006 是后端主线T008 依赖 T007T008A 依赖 T002B T008T009/T010 依赖 T006T010A/T010B 依赖 T002BT011/T012 依赖 T006 T010BT013/T014 依赖 T006 T010B前端任务依次依赖各自后端完成。三、开发模式测试优先、迁移式开发与双库约束tasks.md 明确了六条开发纪律是整个特性落地质量的关键后端 Test-First审批网关、流程流转、异常处理、菜单授权与业务接入改造全部先写测试再补实现。例如 T003 在实现前先给出 7 个网关测试场景未配置/未启用报错、直通 PASS、命中流程 PENDING、重复 business_key 返回已有实例、route_missing 与 approver_empty 异常创建。前端 Test-AlongsidePlatform 以手动验证为主源码结构可补轻量 source-inspection 测试避免大面积 UI 回归。迁移式开发频道订阅、知识空间加入等旧消息审批链路需完成新旧切换部门知识空间文件上传审批直接移除上传路径回归 ReBAC 权限校验。双库约束除 sqlite 单元测试外审批中心表结构与迁移必须补 MySQL / 达梦方言验证T008A禁止实现后再补兼容。列优先于 JSON凡审批列表筛选、待办检索、异常处理、重复判定所需字段必须建显式列不得只放payload_snapshot/detail_snapshot再靠 JSON SQL 查询。自包含任务每个任务写明文件、逻辑、测试和 AC 覆盖实现阶段不必反复回读 spec。执行阶段分五步推进先落通用中心模型和审批网关新场景可创建实例、任务和异常→ 再落管理端配置与用户端查询跑通场景 → 分支 → 流程 → 节点 → 详情主链路→ 接菜单权限申请新场景里对数据模型要求最高的一条线→ 移除部门知识空间上传审批统一上传权限口径→ 最后迁移频道订阅和知识空间订阅并补站内信、审计、异常处理联调。四、基础设施11 张表与 Repository 分层4.1 数据模型T002A按 spec §5 新建 11 张 SQLModel 表全部带tenant_id、create_time、update_time表说明approval_scenario租户下某个预置场景的启停与展示配置approval_route_rule场景下的条件分支规则按sort_order顺序匹配approval_flow_definition流程定义头按场景归属approval_flow_version流程版本快照保存完整 DSL JSONapproval_node_definition某流程版本内的顺序节点定义approval_instance一次审批申请实例承载scenario_code、business_key、payload 快照、当前状态approval_task分配给审批人的节点待办支持pending/approved/rejected/skipped/cancelledapproval_action_log审批详情时间线用于谁在何时做了什么approval_exceptionroute_missing、approver_empty、execute_failed异常记录scenario_disabled已移除改为直接报错approval_outbox审批通过后的业务执行队列支持状态、重试次数、错误摘要user_menu_access用户级菜单授权表保存审批授予与撤回状态关键实现约束JSON 字段使用JsonType仓库统一的bisheng.core.database.dialect_helpers时间戳使用UPDATE_TIME_SERVER_DEFAULT不写 MySQL 专属 DDL迁移守卫使用 SQLAlchemyinspect()而不是information_schema。approval_route_rule必须包含enabled BOOLEAN NOT NULL DEFAULT 1字段_match_first_route依赖它跳过禁用分支。从源码看ApprovalInstance还额外建立了去重联合索引idx_approval_instance_dedupe_lookuptenant_id scenario_code business_key applicant_user_id服务于 AC-05 幂等判定见 approval_instance.py。4.2 状态机源码确认审批实例状态与任务状态在仓库中已落地为常量枚举approval_instance.py实例状态pending、approved、executing、executed、rejected、exception、withdrawn、cancelled、execute_failed任务状态pending、approved、rejected、skipped、cancelled异常类型route_missing、approver_empty、execute_failedscenario_disabled已移除场景未配置/未启用直接报错 18106outbox 状态pending、success、failed4.3 Repository 分层T002B审批中心后端默认走api - service - repository - database不再以 DAO 作为新功能首选数据访问层。四个 Repository 的职责分工Repository文件职责ApprovalScenarioRepositoryapproval_scenario_repository.py场景、分支、流程定义、流程版本、节点配置读写ApprovalInstanceRepositoryapproval_instance_repository.py审批实例、审批任务、异常、action log、outbox 读写UserMenuAccessRepositoryuser_menu_access_repository.py用户菜单授权写入、查询、撤回ApprovalQueryRepositoryapproval_query_repository.py我的审批、我的申请、异常列表、详情聚合查询T001 单测要求通过 repository 而非直接调用 DAO 风格入口验证主链路覆盖四类场景场景未配置/未启用触发ApprovalScenarioDisabledError、命中免审批分支只建实例不建任务、命中审批流程建实例 首节点任务、重复business_key命中已有实例。五、后端核心服务审批网关、流程运行时与异常处理5.1ApprovalGate.request_or_pass()T003/T004网关是业务模块接入审批中心的唯一入口。从源码看approval_gate.py其调用顺序为重复申请检查按tenant_id scenario_code business_key applicant_user_id查询活跃实例命中则直接返回已有实例 ID 及对应决策AC-05不创建新实例handler 详情构建通过registry.get_handler(scenario_code)取 handler先构建detail_snapshot与业务标题用于展示不参与筛选场景启停校验查不到场景或enabledfalse直接抛ApprovalScenarioDisabledError18106前端展示此功能未开放申请不创建任何实例、任务或 outboxAC-02分支匹配按sort_order自上而下调用_match_first_route命中即停空match_config表示无条件始终命中enabledfalse的分支被跳过决策返回命中pass分支 → 创建实例走approved - executing - executed不建任务AC-03命中flow分支 → 创建实例 首节点任务返回PENDINGAC-04无分支命中 → 创建route_missing异常AC-15。其中_get_user_role_labels实现了条件字段applicant_role的身份标签解析PRD §4.3 包含即命中语义固定标签admin系统超管、tenant_admin租户管理员、dept_admin部门管理员、regular_user兜底动态标签role_{id}对应当前租户系统角色允许多标签并存。5.2 场景预置目录T004ApprovalRegistry.with_default_presets()注册三个主版本场景approval_registry.pyscenario_codescenario_namecondition_fieldsapprover_source_typesmenu_access_request菜单权限申请[applicant_role, menu_key][direct_user, department_admin]channel_subscribe_request频道订阅审批[applicant_role][direct_user, department_admin, channel_owner, channel_manager]knowledge_space_subscribe_request知识空间加入审批[applicant_role][direct_user, department_admin, knowledge_space_owner, knowledge_space_manager]管理员新增场景时只能从该预置目录下拉选择名称同租户内scenario_code唯一AC-01避免配置层写入技术字段。5.3 流程运行时与异常处理T005/T006T005 的测试矩阵覆盖了全部节点流转语义或签一个审批人通过后节点即通过其余未处理任务变skippedAC-08会签所有审批人都同意才通过节点任一人拒绝则实例进入rejectedAC-09拒绝终止实例进入rejected后续节点不再生成AC-13撤回实例进入withdrawn所有pending任务变cancelledAC-14异常处理route_missing可指定流程继续approver_empty可指定审批人继续 / 跳过节点 / 取消审批AC-15/AC-16执行失败execute_failed重试成功进入executed重试失败保留状态并累计次数审批结论不回退AC-18审批人 rebind审批人被停用时重新按节点配置解析审批人成功则取消旧pending任务并生成新任务失败则进入approver_empty异常AC-33。ApprovalCenterService、ApprovalExceptionService、ApprovalOutboxService统一通过 repository 编排实例、任务、异常、outbox、action log 数据访问关键动作同时写approval_action_log与auditlogAC-28。outbox 异步执行与重试对应 worker/approval/tasks.py 中的execute_approval_outbox、retry_approval_outbox、rebind_approval_approver_on_user_disabled任务所有任务参数必须带tenant_id执行前恢复current_tenant_id。5.4 Handler 协议spec §7.2旧message.domain.services.approval_handler.ApprovalHandler仅有get_action_code()/on_approved()/on_rejected()无法承载新中心所需的标题、详情、审批人解析和撤回逻辑。F025 新增统一 handler 基类ApprovalScenarioHandler业务 handler 只需实现以下抽象方法class ApprovalScenarioHandler(ABC): scenario_code: str abstractmethod async def validate(self, req: ApprovalGateRequest, login_user: UserPayload) - None: ... abstractmethod async def build_title(self, req: ApprovalGateRequest) - str: ... abstractmethod async def build_detail(self, req: ApprovalGateRequest) - dict: ... abstractmethod async def build_business_link(self, req: ApprovalGateRequest) - dict: ... abstractmethod async def resolve_approvers(self, node_config: dict, req: ApprovalGateRequest) - list[int]: ... abstractmethod async def on_approved(self, instance_id: int, payload_snapshot: dict) - dict: ... async def on_rejected(self, instance_id: int, payload_snapshot: dict, reason: str | None) - None: ... async def on_withdrawn(self, instance_id: int, payload_snapshot: dict, reason: str | None) - None: ...三个业务场景的 handler 映射为menu_access_request→MenuAccessApprovalHandler新增负责菜单申请校验、详情、个人菜单授权、授权撤回channel_subscribe_request→ChannelSubscribeScenarioHandler复用并扩展现有激活/拒绝逻辑knowledge_space_subscribe_request→KnowledgeSpaceSubscribeScenarioHandler复用并扩展成员激活与权限同步逻辑。六、API 层与双库兼容验证6.1 用户端与管理端接口分离T007/T008用户端与管理端接口分离实现Endpoint 只调用 service 不直接访问 ORM / DAO统一resp_200包装使用UserPayload做认证与管理员校验。用户端接口包括GET /api/v1/approval/my-tasks我的审批列表、GET /api/v1/approval/my-tasks/{task_id}审批详情、POST /api/v1/approval/tasks/{task_id}/decision同意/拒绝、GET /api/v1/approval/my-requests我的申请列表、GET /api/v1/approval/instances/{instance_id}实例详情、POST /api/v1/approval/instances/{instance_id}/withdraw撤回、POST /api/v1/approval/instances/{instance_id}/resubmit重新提交、POST /api/v1/approval/menu-access/apply菜单申请、POST /api/v1/approval/menu-access/{instance_id}/revoke-grant授权撤回。管理端接口按场景管理预置目录 / 场景 CRUDscenario_code不可修改对应 AC-34、条件分支管理CRUD PATCH .../routes/reorder排序、流程与节点管理PUT /admin/flows/{flow_id}/nodes提交全量节点列表并触发新版本生成、异常流程处理retry / assign-approver / assign-flow / skip-node / cancel五个分组列表接口统一PageData[T]分页包装page默认 1、page_size默认 20。路由注册见 approval/api/router.pyuser / admin / legacy 三个子 router 统一纳入。6.2 错误码表源码确认 18100–18117spec §6.4 规划了 18100–18110仓库实际实现已扩展到18117common/errcode/approval.pyCodeError Class场景18100ApprovalRequestNotFoundError实例/任务不存在18101ApprovalRequestPermissionDeniedError无权限查看或处理18102ApprovalRequestAlreadyProcessedError任务已处理/实例不可重复操作18103ApprovalRejectReasonRequiredError驳回/取消未填必填原因18104ApprovalHandlerNotRegisteredError场景目录中找不到 handler18105ApprovalScenarioDuplicateError场景重复创建18106ApprovalScenarioDisabledError场景未配置或未启用前端展示此功能未开放申请18107ApprovalRouteNotMatchedError分支未命中网关内部抛转 exception18108ApprovalApproverEmptyError审批人解析为空网关内部抛转 exception18109ApprovalDuplicatePendingError存在重复申请18110ApprovalGrantNotRevokableError授权撤回条件不满足18111ApprovalMenuApplyDisabledError菜单审批模式关闭时绕过前端调用申请接口18112ApprovalSettingsPermissionDeniedError仅超管可修改审批设置18113–18115ApprovalRetryNoFlowRouteError等异常重试时无启用分支 / 无 active 流程版本 / 流程无节点18116ApprovalFlowNotFoundError流程不存在18117ApprovalFlowInUseByRoutesError流程已被分支引用需先解除绑定再删除6.3 双库兼容验证T008AT008A 是 F025 独有的方言级测试任务对应 test_approval_dialect_compat.py验证JsonType、UPDATE_TIME_SERVER_DEFAULT、主键自增、索引与迁移守卫在 MySQL / 达梦下都成立。spec §5.6 明确了五条必须遵守的风险结论风险 1payload_snapshot、detail_snapshot、流程 DSL 只用于详情展示、审计回放与 handler 上下文不承担列表筛选、排序、唯一性判断风险 2所有update_time走UPDATE_TIME_SERVER_DEFAULT不在 alembic 中写ON UPDATE CURRENT_TIMESTAMP风险 3AC-05 重复申请判定基于事务内查询 状态判断不依赖复杂方言相关的唯一索引风险 4审批待办查询以approval_task一人一行为准不引入审批人列表 JSON做待办过滤风险 5表/列/索引探测统一复用 SQLAlchemyinspect()或仓库 helper不写 MySQL 元数据 SQL。七、主场景菜单权限申请T009/T010菜单权限申请是 F025 中最独特、对数据模型要求最高的一条线核心决策 AD-07审批通过只给申请人写个人菜单授权user_menu_access不修改角色菜单与角色菜单做并集父级依赖菜单自动补齐。测试覆盖T009对应 test_menu_access_approval.pymenu_approval_modetrue且场景启用 → 创建menu_access_request审批返回PENDINGAC-24menu_approval_modefalse且无菜单权限 → 前端不展示申请入口直接调用申请接口被拒绝18111且不创建审批实例AC-32后端不能绕过批准后写入user_menu_access个人授权AC-24撤回授权后记录 revoke 状态AC-25。T010 实现要点新建菜单申请 handlervalidate / build_title / build_detail / on_approved / on_rejected / on_withdrawn / revoke_grant 完整协议、新增UserMenuAccessService与授权撤回逻辑、扩展approval.py错误码。授权撤回仅允许当前审批人、历史审批人、管理员执行审批通过后的业务动作仍调用原业务权限/存在性校验审批通过不等于绕过业务安全检查spec §7.4。八、旧链路迁移与能力收敛8.1 部门知识空间上传审批下线T010A/T010B历史部门知识空间文件上传审批在本版本直接移除部门知识空间上传与普通知识空间上传链路一致只校验现有 ReBAC 上传权限新上传请求不创建approval_request、审批消息或审批中心实例AC-31。approval_request标记为历史只读兼容对象不再被新上传流程写入。T010A 回归测试test_department_knowledge_space_upload_permission.py断言有上传权限 → 上传直接成功且不创建审批相关记录无上传权限 → 直接拒绝且不创建approval_request。8.2 频道订阅审批迁移T011/T012channel_service.subscribe_channel()从直接改成员状态并发send_generic_approval切换为调用ApprovalGate.request_or_pass()AC-26PENDING 时业务暂停APPROVED 后由ChannelSubscribeScenarioHandler激活成员关系REJECTED 置为rejected。旧ChannelSubscribeApprovalHandler逻辑抽到新 scenario handlerlegacy message handler 仅标记兼容用途、保留历史消息跳转。集成测试见 test_channel_subscription_approval_integration.py。8.3 知识空间加入/订阅审批迁移T013/T014知识空间加入/订阅入口切换为knowledge_space_subscribe_request进入审批中心AC-27不再以旧request_knowledge_space消息为事实来源。新 handler 复用现有成员激活 ReBAC 授权同步逻辑测试覆盖审批创建、通过后成员激活与权限同步、拒绝后状态回写、历史消息兼容跳转见 test_knowledge_space_subscription_approval_integration.py。九、前端落地Client 工作台与 Platform 审批管理9.1 Client 工作台T015A/T015B/T015C工作台src/frontend/client/src/路由基础路径/workspace承担我的审批、我的申请、消息提醒三个前台入口挂在左下角用户菜单layouts/UserPopMenu.tsx中沿用~/api/*、useLocalize()、Recoil/store 与现有Dialog/Tabs/DropdownMenu组件体系不引入 Platform 的controllers/API与 Zustand。推荐形态为用户菜单 → 弹窗/抽屉 → 左列表 右详情T015A新增入口 封装全部 Client 审批 APIlistMyApprovalTasksApi、decideApprovalTaskApi、listMyApprovalInstancesApi、withdrawApprovalInstanceApi、resubmitApprovalInstanceApi、applyMenuAccessApi、revokeMenuGrantApi点击审批类站内信消息只做跳转定位不含快捷审批按钮审批事实以审批中心数据为准AC-23T015B我的审批弹窗左列表待我审批 / 我已处理 右详情业务内容 审批进度 操作区或签/会签状态正确展示非本人待办只读AC-20T015C我的申请弹窗列表 详情 撤回/重新提交execute_failed展示失败原因菜单占位页入口仅在menu_approval_modetrue且无权限时出现频道订阅/知识空间加入接口接审批返回态PENDING → 提示已提交DISABLED → 此功能未开放申请菜单授权场景展示撤回授权二次确认弹窗AC-21/AC-24/AC-26/AC-27/AC-32。9.2 Platform 审批管理T016A/T016B/T016C管理后台src/frontend/platform/src/承担审批管理页与异常流程列表页面入口已落地为pages/ApprovalPage/index.tsx沿用/controllers/API/*、useTranslation()、bs-ui组件体系T016A场景管理——列表展示名称 启停、新增弹窗下拉选预置场景、场景 DELETE、scenario_code不可修改校验AC-34T016B条件分支 CRUD/启停/上下移动PATCH reorder 流程节点列表 CRUD/排序PUT 全量节点列表 流程预览弹窗GET /admin/flows/{flow_id}/versions/{version_id}获取快照AC-35。条件值 UI 规则AC-36/AC-37非常关键条件字段下拉按当前场景condition_fields过滤applicant_role申请人身份展示枚举下拉系统管理员 / 租户管理员 / 部门管理员 当前租户系统角色列表动态调角色列表接口menu_key申请菜单展示可申请菜单下拉动态加载不能自由文本输入space_type知识空间类型展示固定枚举公共 / 部门 / 团队T016C异常流程列表支持route_missing/approver_empty/execute_failed三类处理动作弹窗审计页加入approval模块筛选与approval.*动作文案备注列兼容结构化日志 reason metadata 摘要AC-28。双端边界Client 只承担我的审批/我的申请/消息提醒/发起申请/审批详情/审批人处理Platform 只承担场景、分支、流程、节点、异常列表与后台审计筛选。两端共享同一后端审批中心数据但不共享前端实现代码站内信只在 Client 侧呈现。十、验收标准AC与任务映射速查tasks.md 为每个任务标注了 AC 覆盖汇总如下便于核对与追踪AC语义主要任务AC-01预置场景目录、scenario_code 唯一T004/T008/T016AAC-02场景未配置/未启用直接报错 18106T001/T003/T004/T008AC-03免审批分支直通不建任务T001/T003/T004/T008AC-04命中流程建实例 首节点任务T001/T003/T004/T008AC-05重复 business_key 幂等返回已有实例T001/T002B/T003/T004/T008AAC-06~AC-10分支顺序匹配、顺序节点、或签、会签、流程版本化T005/T006/T007/T008/T016BAC-11~AC-14同意推进、末节点同意出 outbox、拒绝终止、撤回T005/T006/T008AC-15/AC-16route_missing / approver_empty 异常T003/T005/T006/T008/T016CAC-18/AC-19execute_failed 重试、异常取消T005/T006/T008/T016CAC-20~AC-23我的审批/我的申请/审批管理/消息跳转T007/T008/T015A/T015B/T015C/T016AAC-24/AC-25菜单申请授权、授权撤回T009/T010/T015CAC-26/AC-27频道订阅、知识空间订阅迁移T011/T012/T013/T014AC-28/AC-29审计与多租户隔离T006/T008/T016CAC-30MySQL/达梦双库兼容T002B/T008/T008AAC-31部门知识空间上传回归 ReBACT010A/T010BAC-32菜单审批模式关闭无入口且后端拒绝T009/T010/T015CAC-33审批人停用 rebindT005/T006AC-34scenario_code 不可修改T008/T016AAC-35流程版本快照预览T008/T016BAC-36/AC-37条件字段/条件值 UI 联动规则T016B十一、执行完成后的收尾版本契约与实际偏差记录T017 要求在所有功能完成后更新features/v2.6.0/release-contract.md登记 F025 领域对象 Owner、模块编码 181 的变更历史与features/v2.6.0/README.md补充 F025 索引条目。同时 tasks.md 末尾保留了实际偏差记录区块要求实现完成后在此记录与 spec.md 的偏差供后续版本参考——这是本仓库 feature 流程计划 → 实现 → 对账闭环的最后一环。总结F025 统一审批中心是 BISHENG v2.6.0 的 P0 能力其价值在于把审批从每个业务按钮里写死的样板逻辑升级为租户级可配置的通用能力研发只需注册预置场景、组装 payload、实现 handler 协议管理员即可通过条件分支、顺序节点、或签/会签和异常处理管理审批流程。从仓库现状看F025 已从任务清单落地为可运行的实现——approval_gate.py 网关、approval_registry.py 预置目录、approval_instance.py 状态机与模型、errcode/approval.py 错误码、test/approval 下的 16 个测试文件以及 ApprovalPage 管理页均已就位与 tasks.md 的任务拆解一一对应。对于后续新增审批场景标准接入路径是在ApprovalRegistry注册 preset → 实现ApprovalScenarioHandler子类 → 业务入口调ApprovalGate.request_or_pass()→ 前端业务接口接审批返回态——无需再复制消息 状态 重试样板逻辑。【免费下载链接】bishengBISHENG is an open LLM devops platform for next generation Enterprise AI applications. Powerful and comprehensive features include: GenAI workflow, RAG, Agent, Unified model management, Evaluation, SFT, Dataset Management, Enterprise-level System Management, Observability and more.项目地址: https://gitcode.com/GitHub_Trending/bi/bisheng创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考