AI

• 1: 综合智慧信贷
  • 1.1: 智能信审平台业务架构
  • 1.2: 综合智慧信贷 AI 架构方案
  • 1.3: 智能信审平台需求文档
    • 1.3.1: 总体概述
    • 1.3.2: 业务架构与端到端流程
    • 1.3.3: 悬浮按钮与任务管理
    • 1.3.4: 风险检查（小查）
    • 1.3.5: 类案对比（小审）
    • 1.3.6: 审查报告
    • 1.3.7: 智能审核（小核）
    • 1.3.8: 评价分析
    • 1.3.9: 对外交互方案
    • 1.3.10: 10 财务风险分析
  • 1.4: 财务风险分析系统详细设计与实施方案
• 2: 星辰智能
  • 2.1: VLAgent 智能文档识别平台架构解读
  • 2.2: 结算类凭证要素核验需求规格说明书
  • 2.3: 智能文档识别平台规划方案
  • 2.4: 智能文档识别平台建设实施计划与详细方案
  • 2.5: StarWork 桌面端技术架构
  • 2.6: StarWork 云控服务端技术架构

1 - 综合智慧信贷

综合智慧信贷项目（智慧信贷二期 AI 能力建设）相关文档：

• 综合智慧信贷 AI 架构方案：业务、应用、技术、集成、部署、数据六个视图的架构总结，含九张交互式架构图（知识库、财务分析、制度解析与场景规则集技术架构）
• 智能信审平台业务架构：五大智能应用、四类底层能力、评价闭环与外部协同的业务架构全景
• 智能信审平台需求文档：依据 911 版软需与对外交互方案编制的九章需求文档及 0924 版财务风险分析补充章，含业务功能架构、两条业务主线、放款智能审核时序与目录版本生命周期等六张交互式图表
• 财务风险分析系统详细设计与实施方案：多智能体财务分析 PoC 的详细设计——总体架构、分析流水线与重算回路、数据层、规则库与判定引擎、议题聚合评分、图表体系、四类 LLM Agent 协作、前端页面与里程碑验收，含三张交互式图表

1.1 - 智能信审平台业务架构

依据《信贷项目-智能信审平台-911》需求规格说明书与《智能信审系统对外交互方案-911》整理，政策文件解析部分同步《政策文件解析需求规格说明书（0908）》。智能信审系统是智慧信贷二期 AI 能力建设的载体：门户以微前端形式集成信贷系统与智能信审两个平级子应用，前端互操作（悬浮按钮、页面跳转、页面嵌入）发生在两个子应用之间；后端与信贷管理系统各业务中心（授信作业中心、授信执行中心、客户中心等）、调查报告系统（智能尽调系统）、企业知识平台、外部数据管理平台（EDS）、影像平台协同工作。

定位与设计原则

平台以 “科技赋能业务、辅助不替代、增强不决策” 为核心原则：所有 AI 输出仅供人工确认与复核，不直接改变信贷业务流程数据。系统整体由 “底层能力 + 应用功能 + 评价闭环” 三层构成，并承载四项业务目标：

• 效率提升：审查报告由"从零撰写"转为"审核修改"；知识获取由翻阅文档转为即问即答。
• 风险管控：审查阶段前置识别调查报告专项风险与制度合规冲突；放款环节闭环校验批复条件与材料完整性。
• 知识沉淀：以"制度 + 案例 + 知识"一体化底座，将分散经验转化为可检索、可复用的结构化资产。
• 可控迭代：悬浮按钮统一入口、评价闭环与效果评价分析，保障 AI 能力可落地、可控制、可迭代。

业务架构总览图

全屏打开 ↗

术语与角色

核心术语：智能信审系统（AI 能力载体，与既有信贷系统接口集成）；小查（全面风险分析助手：制度合规检查、调查报告专项分析、财务分析）；小审（历史案例检索，即类案对比）；小核（智能审核助手：放款、出账、贷前落实条件、借款合同、贸易合同审核及制度合规检查）；小问（智能知识问答）；悬浮按钮（FAB，统一入口）；制度拆解（制度 → 结构化合规规则）。智能体分为任务式（小查、小审、小核，批量分析任务产出结构化结果）与对话式（小问，多轮对话逐条评价）两类。

主要角色：客户经理（业务发起、资料上传）、审查审批人员（小查查看/补充发起、审查意见确认、类案对比）、放款审核岗与出账审核岗（审核结果复核）、政策解析管理员与标准词库管理员（制度解析配置）、评价分析管理员与系统管理员（评价治理、悬浮按钮与运行管理配置）。

端到端业务流程

按对外交互方案，业务主线分三个环节、十二个场景：

业务发起与审查环节（场景 1–5）

1. 业务发起与调查报告获取：客户经理在调查报告系统完成尽调报告，正式版自动以 PDF 存入影像平台并登记文件索引；授信作业中心在授信申请提交成功后调用**“小查与审查意见生成统一发起接口”**——智能信审系统按业务流水号查询文件索引、拉取 PDF 本地暂存（不进知识库），统一执行一次财务分析与制度分析（财务要素、企查查、行业均值、政策法规等数据支撑只发生一次），结果复用后分别创建小查与审查意见生成任务。
2. 审查岗查看全面风险分析：审查审批人员进入业务详情后前端缓存点亮"小查"；因小查已随提交自动执行，此时点击属重复发起，按运行管理配置处理（允许重复时覆盖原任务、执行中任务自动终止）。
3. 审查岗出具审查意见：审查意见初稿已自动生成，审查人员经"查看/编辑"按钮以 URL 跳转（mode 参数区分只读/可编辑）；系统经客户关系查询接口自行生成集团关系图谱；授信作业中心跳转前完成权限校验，本系统在查看与下载时二次校验。
4. 审查岗类案对比：按业务特征检索相似历史案例，结合三套材料向量化内容与五级分类数据执行数据抽取与对比分析；贷款完整业务信息以页面嵌入方式由授信作业中心承接。
5. 终审与业务资料入库：终审通过——审查意见、批复入库（三套材料）；终审拒绝——仅审查意见入库（两套材料，无批复）；终审再议——流程废弃、不通知不入库。统一打标字段编码进文件名传递。

出账与放款环节（场景 6–9）

6. 出账申请资料上传 / 8. 放款申请资料上传：由智能信审系统承接（页面跳转唯一入口），支持目录同步与版本回滚、逐条不可删除标记、复用历史材料（物理复制两份）、目录影像映射回传（含失效状态）；上传任务提交不触发审核。
7. 出账审核 / 9. 放款审核：以授信执行中心的出账申请（paymentManage）/放款申请（loanReleaseApply）提交事件为唯一发起点，自动调用"放款智能审核接口"——同时执行材料智能审核与制度风险分析，返回双结果与取高后的合并风险等级；个贷放款审核另经 EDS 核对交易对手经营范围与贷款用途。出账审核与放款审核相互独立、不得互相覆盖。

评价与门户环节（场景 10–12）

10. 未评价结果门户提醒：每日批量生成未评价提醒文件上传影像平台，门户定时轮询获取并处理为门户提醒。
11. 门户主数据同步：机构、用户、角色及两类关系经 ESB 实时通知 + 企业知识平台表级同步（菜单不同步）。
12. 知识库门户接入：知识库功能提前上线，以门户菜单直接集成（对话框问答 + 资料管理），不经悬浮按钮。

入口与触发机制

悬浮按钮（FAB） 以 npm 包 + 微前端形式常驻信贷作业页面右侧：折叠态圆形主按钮，悬停展开查 / 审 / 核 / 问单项入口；按管理员功能配置、用户逐功能显示偏好、当前末级功能、页面业务上下文与任务状态动态展示，控制顺序为"管理员禁用 → 整体隐藏 → 用户始终隐藏 → 用户始终启用 → 自动显示"。存在未读已完成任务时圆点显示红点，启用风险提醒的功能显示风险等级角标（高/中/低/疑，放款/出账审核取材料与制度风险的更高者，高风险时字符交替闪烁）。

触发方式矩阵：

门户侧同时提供菜单直达与页面集成形态；统一身份认证、业务上下文透传（前端缓存 sessionStorage 写入业务流水号、合同号、客户号、批复编号）与免登录保障多入口体验一致。

应用功能层：五大智能应用

类案对比的运行机制：经 ESB 查询业务基本信息与对比业务关键要素快照，按业务特征检索相似历史案例；通过影像平台拉取三套材料 PDF 向量化入库，从企业知识平台实时获取贷后五级分类数据。对比分析采用固定公式 + 可配置业务参数口径（相似度权重、行业分值、置信度阈值由管理员维护，公式由系统固定执行、后端独立校验），大模型分析分两阶段执行——先逐案例生成摘要，再基于全部摘要生成综合建议（含建议敞口额度、期限与风控措施）。分析材料还包括行业/产品映射与抽取字段配置（项目贷款/非项目贷款由固定资产贷款产品名单自动判定）。

智能审核的规则体系：按目录节点配置审核规则，支持五种判断模式（图片直接大模型判断 / 提取要素后规则判断 / 提取要素后大模型复核 / 已有解析结果大模型判断 / 规则初判 + 大模型处理例外）；预审按输入指纹（材料内容哈希、目录绑定、规则版本）沿用上次有效结果，避免重复调用大模型。放款/出账审核同时执行制度风险分析——检查范围按智能制度检查配置的节点制度映射确定（loanReleaseApply 与 paymentManage 各自映射制度集合，个人条线复用同名映射），制度审核维度复用小查结果面板样式，风险条目提供制度条文与业务证据双重溯源。

业务材料上传（出账/放款申请）：影像目录树由信贷系统统一配置（影像树与产品相关），目录维护采用"联动差异确认"与"候选版本逐条确认 + 回滚"并列两种方式；业务打回后退回材料按逐条不可删除标记控制；支持复用历史材料（信贷系统物理复制两份实体文件，不做链接引用）；文件上传/删除/失效后经"业务目录影像映射回传接口"回传授信执行中心，任务提交时全量核对；文件实体存影像平台，本系统仅保存元数据与"目录节点 ↔ 影像文件"对应关系。

审查报告生成：融合业务基本信息、财务要素、客户关系（自行生成集团关系图谱图片）、行业均值与政策法规等多源数据，按模板生成报告初稿与结构化批复条件；查看/编辑双模式经 URL 参数区分，报告下载在审查意见页面内完成；ESB 调用失败时对应数据区域降级展示，不影响其他部分。

底层能力层

• 制度拆解与检查：将制度文件拆解为结构化合规规则，支撑小查制度合规检查，并为小核制度风险分析、审查报告生成提供合规规则依据；属需求分析性功能，不部署于生产环境。依据《政策文件解析需求（0908）》：以"标准对象库 + 三层同义词库（标准词/别称/上下位）“为双重语义基石；制度条目解析分为规则、说明、材料审核、流程审核四类（规则类生成规则表达式与审核要点，说明/材料审核/流程审核类不拆解）；支持生成新版本、历史版本、制度补充与修订（补充/更新两类，关联对象库与标准词库）、一致性检查（版本间规则表达式差异逐条确认）与审核场景配置/场景规则集（按适用产品×审核阶段裁剪规则并版本化推送，供小查/小核按场景执行）。
• RAG 知识底座：制度、操作手册、流程等知识的向量化底座，支撑小问问答与类案对比。业务资料按终审结论入库：通过业务入库调查报告、审查意见、批复三套材料（审批结论=通过），拒绝业务入库调查报告与审查意见两套（无批复），再议业务流程废弃不入库；统一打标字段由授信作业中心编码进文件名传递（含业务流水号、企业性质、企业规模、经营年限、所属行业、贷款用途、产品、主担保类型、所属分行、审批通过时间、审批结论），打标自文件名解析；同一材料类型更新时覆盖旧有效版本。场景 1 拉取的调查报告仅本地暂存，不进知识库。
• 历史案例库：标准化历史审批案例，以业务摘要 + 统一打标组织，支撑类案对比的语义检索（业务摘要）与精确条件检索（统一打标）。
• 财务分析：911 版需求中小查财务分析子模块标注"建设中占位”，《财务风险分析系统需求文档（0924）》已给出完整设计——作为信贷审批流程的"财务分析"环节（评审经带参跳转进入），按 969 条规则逐条核查年报：四层筛选（适用对象/数据可得性/业务前置/规则类型）与五类阈值形态、议题聚合（44 个事实域）与三轴评分（重大问题数/问题密度/加权分取中位）、八条一票否决重点关注事项、38 条程序生成图表、大模型仅承担判读与结论文案（五条硬约束：只用给定事实、人工判定优先、档位一致、触发否决必须不建议准入、固定 JSON 输出）。数据侧：三表科目取自行内已审批尽调报告，附注经影像平台 OCR + 人工补录，企查查经 EDS 获取，行业均值由企业知识平台同步。与 911 版"建设中"口径的关系（独立系统还是小查子模块的落地形态）建议在需求侧对齐，见需求文档第 10 章。

运行管理与任务模型

• 任务状态机：运行中 → 部分完成（仅小查，按子模块汇总）→ 已完成（成功/失败）；小核不产生部分完成状态。
• 唯一轮询器：有运行中任务默认每 10 秒、无任务每 60 秒拉取任务汇总；已完成未读数增加时弹出汇总通知。
• 运行管理配置：任务类型、模式、唯一性标识、是否可重复发起、失败重试次数与运行时间限制；允许重复发起时覆盖原任务（原任务仍在执行则自动终止），禁止重复时按入口语义拒绝或回退手工。
• 风险提醒：小查、小核启用风险提醒后，未读已完成任务驱动悬浮按钮风险角标（高/中/低/疑），风险等级文案经统一字典加载，颜色可按级自定义。

评价管理闭环

评价管理覆盖任务式智能体（小查、小审、小核）与对话式智能体（小问）：评价查询沉淀逐条评价明细（评分、评价等级、反馈原因、补充说明、截图）；效果评价分析对智能体服务效果做周期性量化分析，反哺模型与功能优化；评价提醒配置与未评价提醒——智能信审系统每日批量生成未评价提醒文件上传影像平台约定目录，门户定时轮询获取并处理为门户提醒（仅提醒最大提醒天数内、默认 7 天的未评价任务；对话式 AI 任一回答未评价即视为任务未评价）。

外部协同与交互模式

系统间交互抽象为六种模式：

关键接口（发起方 → 本系统）：小查与审查意见生成统一发起接口、放款智能审核接口、审查意见/批复入库通知接口、门户主数据变更通知；（本系统 → 外部）：调查报告文件索引查询、财务要素查询、企查查数据查询（EDS）、五级分类数据查询（企业知识平台）、放款/出账要素与合同信息查询、业务目录影像映射回传、客户关系查询。

边界与安全约束：审阅结果由智能信审前端承载展示，授信执行中心经状态/结果查询接口获取结论，不回写信贷业务表；授信作业中心在页面跳转前完成权限校验，本系统在查看与下载时二次校验授权上下文，未授权访问、拼接 URL 与越权下载被拒绝并记录审计日志；影像目录维护、任务发起等管理动作按角色权限隔离。

需求依据

• 《信贷项目-智能信审平台-911》需求规格说明书（业务功能、悬浮按钮、五大应用、评价管理）
• 《信贷项目-智能信审系统对外交互方案-911》（12 个交互场景、六种交互模式、接口清单）
• 《信贷项目-智能信审平台-软需-政策文件解析0908》（对象库与三层同义词库、四类解析、制度补充修订、一致性检查、场景规则集）

1.2 - 综合智慧信贷 AI 架构方案

依据《综合智慧信贷 AI 架构方案》整理。方案覆盖 AI 能力从业务场景到基础设施的完整链路，按 应用逻辑 → 系统技术 → AI 能力专项 → 数据 → 集成 → 部署 → 非功能设计 七个部分组织，本页按六个架构视图归纳其核心内容，各章节嵌入对应的交互式架构图。

一、业务架构

自上而下四层：场景层 → 智能应用层 → 能力支撑层 → 评价管理（闭环），核心原则是"辅助不替代、增强不决策"，所有 AI 输出均需人工确认。

• 场景层（用户入口，五个智能助手场景）：智能审查助手、审查报告 AI 智能生成、智能化批复助手、放款审核助手、智能知识库。
• 智能应用层（五个 AI 智能应用，内部可协同、复用输出）：小审·历史案例检索、小查·全面风险分析、审查意见生成、小核·放款审核、小问·智能知识问答。
• 能力支撑层（四大能力）：案例库、制度拆解与检查、财务分析、知识库。
• 评价管理：评价查询、效果评价分析、评价提醒配置与未评价提醒、评价设置，形成"使用 → 评价 → 分析 → 优化"闭环。

场景与应用的映射关系：智能审查助手先类案检索、后风险分析；审查报告 AI 生成可复用小审、小查输出；智能化批复助手聚焦制度合规冲突生成批复建议；放款审核助手校验批复条件与材料完整性；智能知识库即问即答并返回引用来源。

全屏打开 ↗

二、应用架构

服务层内部划分为上下两个子区域：

• 核心业务与智能服务：信审业务服务（信贷审批核心业务逻辑）、知识库服务（知识存储与检索，支撑智能问答）、智能助手服务（面向用户的 AI 交互入口）、智能体运行服务（承载智能体运行时环境，支撑多智能体协同与执行）。
• 支撑与基础服务：任务规划服务（异步任务管理与调度）、文档解析服务（信贷文档解析与结构化）、组织权限管理服务、认证授权服务、模型网关服务（统一模型调用与路由）、智能体追踪评价服务（智能体行为追踪与效果评价）。

调用关系：上半部分服务可调用下半部分支撑服务，并可通过智能体运行服务调度多个智能体协同完成任务；所有服务经 Nacos 注册与发现，实现动态调用。数据读写走 OceanBase/Redis，异步通信走 RabbitMQ，检索走 Elasticsearch，文件存储走 MinIO，观测数据统一存入 ClickHouse（详见下方调用链路）。

全屏打开 ↗

三、技术架构

自上而下四层：接入层 → 服务层 → 平台支撑层 → 基础设施与模型服务层，核心原则为四层解耦、服务化拆分、统一接入管控、平台化支撑、算力与业务分离。

• 接入层：反向代理 Nginx（负载均衡、静态资源、请求转发）+ API 网关（统一鉴权、限流、熔断、路由）。

• 服务层：内部按"核心业务与智能服务 / 支撑与基础服务"上下分区。

  核心业务与智能服务：

  服务	职责
  信审业务服务	信贷审批核心业务逻辑，承载各应用的业务规则与配置管理
  知识库服务	知识存储与检索，支撑智能问答与内容溯源
  智能助手服务	面向用户的 AI 交互入口（Chat 交互）
  智能体运行服务	承载智能体运行时环境，支撑多智能体协同与执行

  支撑与基础服务：

  服务	职责
  任务规划服务	智能体任务编排、异步任务管理与调度
  文档解析服务	信贷文档解析与结构化（MinerU 双引擎）
  模型网关服务	Higress 统一模型调用、限流、路由与协议适配
  智能体追踪评价服务	智能体行为追踪与效果评价
  认证授权服务	用户认证与授权（对接门户 SSO 与主数据同步）
  组织权限管理服务	组织架构与权限管理

• 平台支撑层：

  中间件	职责
  OceanBase	关系存储（主从/集群、双活 RPO≈0），独立部署
  Redis	缓存与分布式协调（任务队列、分布式锁、解析缓存），独立部署
  RabbitMQ	异步消息与削峰填谷（镜像队列）
  Elasticsearch	全文检索与 2560 维向量相似度计算（向量库），独立部署
  ClickHouse	MPP 数据库，观测数据存储，独立部署
  MinIO	对象存储与溯源审计（多副本/纠删码）
  Nacos	服务注册发现与配置管理（多实例）

  中间件（OceanBase、Redis、Elasticsearch、ClickHouse 等）均为智能信审系统独立部署，不与其他系统共用。

• 基础设施与模型服务层：物理机/虚拟机提供部署环境，算力服务器（GPU，5 台，海光 M890P / 鲲鹏 910C 二选一）支撑模型推理与训练；模型网关 Higress 部署于行方现有服务器。

调用链路：

1. 请求入口：外部请求 → Nginx → API 网关（限流/熔断/鉴权）→ 路由至服务层对应服务；
2. 服务协同：核心服务调用支撑服务（任务规划、文档解析、模型网关等），并经智能体运行服务调度多智能体协同完成任务；
3. 模型调用：模型调用统一经模型网关（Higress）转发至算力服务器，业务服务不直连算力；
4. 数据与中间件：OceanBase/Redis 读写、RabbitMQ 异步通信、Elasticsearch 检索、MinIO 文件存储、ClickHouse 观测落库；
5. 观测：OpenTelemetry 全链路采集 Trace/Metrics/Logs 统一存入 ClickHouse（MPP 架构），轻量自研查询与告警；
6. 服务治理与部署：所有服务经 Nacos 注册发现，全部组件部署于物理机/虚拟机之上。

AI 能力专项技术架构采用三个层次：

1. 开发与执行层：LangGraph（高码流程编排，图/状态机建模、条件分支、循环、并行、人机协同）+ DeepAgents（高级 Harness，任务规划、工具调用、多智能体协同、记忆管理与上下文压缩）；
2. 模型接入网关层：Higress 统一大模型服务入口，多模型调度、负载均衡、故障转移、限流配额与密钥安全；
3. 质量保障层：OpenTelemetry 标准技术栈（全链路 Trace/Metrics/Logs 采集与轻量自研查询）+ DeepEval（覆盖 LLM、Prompt、RAG、Agent 的评测与 CI/CD 质量门禁）。

关键能力方案：知识库采用父/子/孙三级切片、多路混合召回（向量 + BM25 + 结构 + 表格）、Query Rewrite、Rerank 精排与 PCR 上下文完整召回，输出带文档名/页码/章节的引用溯源；文档解析采用 MinerU + 本地解析器双引擎、大 PDF 拆分并发、跨页表合并、表格分类与表头识别、单元格像素级溯源与财报结构化。

全屏打开 ↗

知识库技术架构

知识库由入库与检索两条链路构成：

• 入库链路：原始文档经 MinerU 双引擎解析归一化为扁平 items，按"父/子/孙"三级切片组织——父/子切片存对象存储、孙切片入向量库；表格按行拆分保留表头，政策类文档按"章节—条款"语义切片；孙切片向量化后索引落库至 Elasticsearch，原文与切片快照持久化至 MinIO。
• 检索链路：检索请求经查询理解（意图识别、查询扩展、错别字纠正）后进入多路混合召回——向量检索（Elasticsearch）与 BM25 全文检索并行，融合结构召回（摘要树）、表格专项检索与图片摘要匹配；候选经 Rerank 模型精排，融合向量分、BM25 分与精排分输出归一化置信度，PCR（Parent-Child Retrieval）保证上下文完整；结果返回文档名、页码、章节及匹配高亮，支持快速定位原文。
• 可配置检索：top_k、阈值等参数按知识库粒度配置，支持多 Embedding/Rerank 模型切换。

全屏打开 ↗

财务分析报告技术架构

财务分析报告以财报解析结构化为主线：

• 双引擎解析：MinerU 外部服务处理复杂 PDF/图片，本地解析器（openpyxl/python-docx/PyMuPDF 等）处理结构化文件，统一输出扁平 items 元素列表；非 PDF 文件经 LibreOffice 转 PDF，大 PDF 拆分并发解析后拼接。
• 结构化处理：items 后处理（排序、合并、注入 ID）与标题分级后，基于版面信息构建跨页链自动合并续页表格；表格分类与表头识别采用"规则粗判 + LLM 精分 + 页面聚类纠偏"，LLM 结构化输出表头行信息。
• 单元格溯源：调用外部 OCR 线框检测获取单元格物理坐标，支持旋转图片逆变换，实现像素级定位。
• 财报结构化与分析：元数据提取、三大报表识别、标准科目匹配后持久化至 MinIO，支撑指标计算、风险分析与财务分析报告生成。
• 规则判定与评分下游（依据《财务风险分析系统需求文档 0924》）：结构化产物进入判定引擎——969 条规则、17 字段、四层筛选（适用对象/数据可得性/业务前置/规则类型），阈值引擎采用受限表达式语言（仅白名单函数），恒等式 1% 容差、近似勾稽用偏离度与跳变双阈值；判定结果按 44 个事实域聚合为议题，三轴（重大问题数/问题密度/加权分）取中位数评级，八条一票否决事项触发即覆盖结论为"不建议准入"；38 条图表定义程序生成、阈值带可视化。大模型职责严格受限：档位与评级由系统计算，模型只生成判读三段（归因/定性/处置）与结论文案，受五条硬约束（只用给定事实、人工判定优先、文案不得与档位相反、触发否决必须不建议准入、固定 JSON 输出）——与"辅助不替代"原则及 7.5 节幻觉控制措施一致。集成侧经新窗口带参跳转 + SSO 进入，结论摘要回写审批单。

全屏打开 ↗

制度解析与场景规则集技术架构

依据《政策文件解析需求规格说明书（0908）》，制度解析以"标准对象库 + 同义词库“为双重语义基石，形成"解析—匹配—校验—反馈"闭环：

• 解析类型（四类）：制度条目分为规则、说明、材料审核、流程审核四类——规则类拆解为规则表达式与审核要点，分别供规则引擎确定性校验与大语言模型语义推理使用；说明/材料审核/流程审核类不做表达式与审核要点拆解。
• 双重语义基石：标准对象库（实体、属性、参考值，映射业务系统数据字典）+ 三层同义词库（标准词库、别称同义词、上下位同义词），条目解析时按语义相似度与对象库对齐，未命中返回原因供管理员迭代对象库。
• 版本与一致性管理：支持生成新版本、历史版本回溯、制度补充与修订（修订类型分制度补充/制度更新，关联对象库与标准词库后触发重新解析）；一致性检查对比版本间规则表达式差异，冲突条目逐条确认后触发规则集更新。
• 场景规则集：按适用产品 × 审核阶段联合唯一配置场景，从制度按阶段筛选规则条款加入规则集，版本化管理并通过一致性检查后推送生效——为小查制度合规检查与小核制度风险分析提供按场景裁剪的规则依据。

全屏打开 ↗

四、集成架构

智能信审系统作为独立系统接入门户，与信贷管理系统各业务中心（授信作业中心、授信执行中心、客户中心）、调查报告系统（智能尽调系统）、企业知识平台、外部数据管理平台（EDS）、影像平台交互，共 12 个交互场景（场景 1–5 业务发起与审查、场景 6–9 出账与放款、场景 10–12 评价与门户），统一抽象为六种交互模式：

1. 后端部署与通信：智能信审系统与信贷系统后端独立部署、运行态隔离；系统间经 ESB 标准化通信（协议转换、消息路由、流量控制），信贷系统通过 ESB 传递业务上下文并发起任务调用。

2. 数据库（共库 · 双用户）：共库部署避免数据冗余与跨库同步，独立数据库用户遵循最小权限——智能信审用户仅被授予对信贷系统数据的只读查询权限；结构化数据由数据库查询工具按业务上下文经受控白名单 SQL 只读获取。

3. 前端集成与悬浮按钮：依托信贷门户微前端基座，以菜单直达、页面集成、悬浮入口（npm 包 + 微前端，查/审/核/问）三种形态对外赋能；门户统一身份认证、业务上下文透传与免登录。悬浮按钮按管理员功能配置、用户逐功能显示偏好、当前末级功能、页面业务上下文与任务状态动态展示，唯一轮询器按"有任务 10s / 无任务 60s"拉取任务汇总；任务完成后经事件总线广播完成事件，订阅该事件的信贷业务功能完成页面回显或数据刷新，形成"AI 结果回流业务"闭环。

4. 触发方式与触发节点：

5. 场景与关键接口映射：

6. 数据获取通道：结构化数据经数据库查询工具从信贷库只读获取；非结构化数据经影像系统/文件传输平台接口获取文件流；外部系统数据经 ESB 实时接口交互；行业均值与政策法规经企业知识平台 ETL 同步后本地引用。

7. 结果输出边界与安全：审阅结果由智能信审前端承载展示，结果经事件通知与接口查询方式供给信贷侧，不写入信贷业务表；授信作业中心在页面跳转前完成权限校验，本系统在查看与下载时二次校验授权上下文，未授权访问、拼接 URL 与越权下载被拒绝并记录审计日志；业务打回后退回材料按不可删除标记控制；出账审核与放款审核任务相互独立、不得互相覆盖。

全屏打开 ↗

五、部署架构

私有化部署，智能信审系统与信贷系统后端独立部署实现运行态隔离；数据库共库部署、双用户权限隔离；应用服务双活站点多副本，全部服务经 Nacos 注册发现，支持灰度发布与流量治理。

• 业务服务域（双节点）：智能审查后端、知识库、问答助手、智能体运行。
• 基础服务域（双节点）：文档解析、异步任务、智能体评测、UAA 认证授权、OCA 权限管理；模型网关 Higress 部署于行方现有服务器，统一转发模型调用。
• 数据存储服务器：OceanBase 主从/集群 + 双活数据同步（RPO≈0）、Redis 主从+哨兵、RabbitMQ 镜像队列、Elasticsearch 检索与向量库、MinIO 多副本/纠删码、Nacos 多实例、ClickHouse（MPP 观测数据）；中间件均独立部署、不与其他系统共用。
• 算力服务器（5 台）：大模型推理独立部署、算力与业务分离；硬件二选一——阿里云 APC PPU1.5（海光 7490×2 · 8×M890P · 1152GB HBM）或华为鲲鹏 910C（Kunpeng 920×4 · 8×910C · 1024GB）；单点 GPU 故障由模型网关故障转移 + 多卡集群冗余承接。

全屏打开 ↗

六、数据架构

系统定位为面向信贷智能审查的 AI 数据中台，不承担业务主数据管理职责——贷款申请、客户、担保、额度等以「业务上下文」metadata 由上游传入，仅用于过滤检索与租户/业务隔离。

数据按主题域划分为七个领域：D0 业务上下文域（横切）、D1 文档文件域（入口/载体）、D2 财务报告域、D3 政策制度域（含内部与外部政策、政策条目、规则表达式、场景规则集、检查任务、风险明细）、D4 知识内容域（含历史案例库）、D5 对象术语域（含标准词库与三层同义词库）、D6 配置模型域；D1 为共同入口，D2/D3 为业务结果，D4/D5 为能力底座，D0/D6 横切全链路。

数据流转由四条主线构成：

1. 财报分析链路：财报 PDF → 解析 → 财报元数据与三大表 → 标准科目对齐 → 结构化输出；
2. 政策检查链路：内部政策与外部政策信息（自政策平台同步）→ 解析成条目 → 制度规则检查 → 风险结论；
3. 知识召回链路：原始文档 → 解析 → 父/子/孙三级切片 → 向量化索引 → 检索命中与问答；
4. 支撑链路：对象术语域与配置模型域贯穿三条业务链路，提供标准化与调度能力。

存储落位：OceanBase 存放元数据、状态、配置、政策/检查与问答历史；Elasticsearch 存放孙切片文本与 2560 维向量；MinIO 存放原文、解析产物、父/子切片与快照；Redis 承担任务队列、分布式锁与解析缓存；ClickHouse（MPP）存放观测数据。Elasticsearch、Redis、ClickHouse 等均独立部署。关键设计决策：领域优于模块、业务上下文外置、溯源贯穿（元素/页码/文件标识）、异步与幂等（任务队列 + 幂等键防重）。

全屏打开 ↗

七、关键非功能设计

7.1 性能与容量

性能保障措施（已定）：

• 长耗时任务（文档解析、财报提取、制度检查、报告生成）一律入队异步执行，前端以轮询（有任务 10s / 无任务 60s）感知状态，避免同步阻塞；
• 缓存分层：Redis 承担任务队列、分布式锁、解析缓存、上传记录，检索命中与热点向量结果可缓存；
• 检索加速：向量检索（ES）+ BM25 并行召回 + Rerank 精排，父/子/孙三级切片控制单条向量维度与检索规模，top_k 与阈值按知识库粒度可配；
• 网关限流与熔断：API 网关对请求限流/熔断；模型网关（Higress）对模型调用限流、配额、负载均衡与故障转移；
• 解析并发：大 PDF 拆分并发解析后拼接，MinerU 与本地解析器双引擎按类型分流。

容量测算模型【待测算】：

7.2 可用性与容灾

高可用措施（已定）：应用服务多副本部署经 Nacos 注册发现与故障剔除；算力与业务分离，GPU 故障由模型网关故障转移 + 多卡集群冗余承接；中间件高可用——OceanBase 主从/集群 + 双活数据同步（RPO≈0）、Redis 主从+哨兵、ES 集群多副本、RabbitMQ 镜像队列、MinIO 多副本/纠删码；Nginx/API 网关/Nacos/模型网关多实例消除单点。

可用性指标【待定版】：

备份与数据留存：

• OceanBase 定期备份与恢复演练【周期待定版】；MinIO 对象版本化保留历史版本；
• 知识库可重建性：向量索引与切片可从 MinIO 原始文件全量重建——原始文件在则 RAG 底座可恢复，此为知识库最重要的容灾特性；
• 数据留存周期【待定版】：任务日志 / 对话记录 / 评价记录 / 审计日志分别明确留存时长。

7.3 降级矩阵

按依赖逐项明确"不可用时系统行为"，将需求中的分散降级描述（ESB 失败分区降级、预审失败保留已完成结果、影像拉取失败可重试）统一为矩阵：

7.4 数据安全与脱敏

已定措施：复用信贷门户 SSO；全链路审计留痕（登录、数据访问、AI 调用、模型调用、结果输出、评价记录）；模型网关密钥集中托管加密存储；模型输入统一管控防提示注入与越权数据外发；私有化算力不出内网。

待补充项：

• 数据分级与进 prompt/向量库的边界【待定版】：明确哪些客户字段可进入 prompt 上下文、哪些进入向量库，形成数据分级清单；
• 双向敏感信息过滤：输入侧（用户提问中的敏感数据）与输出侧（模型生成内容进前端前）内容安全过滤策略【过滤规则与词库待定版】；
• 向量数据删除机制：客户行使删除权或业务作废（再议）时，切片与向量的级联删除规则【待定版】；
• 界面脱敏承接：上传人员"张**“式脱敏显示（需求已有）由前端统一组件承接。

7.5 AI 质量与模型风险管理

• 质量指标目标【待定版】：

• 幻觉控制：答案强制携带溯源（文档名/页码/高亮，已具备）；无依据拒答策略【待定版】；数值类输出必须引用计算层结构化结果，禁止模型自行计算财务指标；
• 模型变更管控：模型与 Prompt 版本变更需通过 DeepEval 评测门禁后灰度发布；线上 badcase 定期回流评测集，评测集随版本累积；
• 双环质量保障：线上用户评价（评价闭环）+ 离线评测集（DeepEval）互为验证，周期性对齐。

7.6 审计与合规

• 审计日志防篡改与保存期限【待定版，等保要求 ≥ 6 个月，行内口径从其规定】；
• 人工确认留痕：谁在何时对 AI 结论执行了确认/修改/忽略（含忽略原因），作为责任界定依据——与"历史执行日志保留用于审计"的需求对齐；
• 生成内容合规：输出内容审核策略与拦截记录留存【待定版】；
• 模型调用记录（Higress 请求日志）含 prompt 摘要、token 数、耗时、模型版本，留存期限【待定版】。

7.7 成本与配额管理

• 启用 Higress 配额与成本追踪：按应用（小查/小核/小问/报告生成）设置 token 预算与超限行为（限流/告警）【阈值待定版】；
• 关注多层 Agent 的 token 放大效应（主+子 Agent 可达普通调用的数倍），子 Agent 数量与单任务轮次上限【待定版】；
• 月度成本核算口径：按应用、按机构维度的 token 成本报表【口径待定版】。

7.8 可观测性 SLO

• Trace 采样策略：正常请求采样 10%~20%，错误与慢调用（阈值【待定版】）全量保留；
• LLM 专项监控：模型调用延迟 P95、tokens/s、成功率、每任务 token 消耗，经 OTel GenAI/OpenInference 语义约定采集；
• 告警分级与响应时限【待定版】：P0（服务不可用）/ P1（队列积压超阈值）/ P2（指标劣化）对应的响应 SLA；
• 看板：任务运行看板（队列深度、成功率、时长分布）+ 模型服务看板（GPU 水位、推理延迟）+ 质量看板（误报率趋势、评价分布）。

7.9 发布与配置运维

• 灰度发布：按机构/角色灰度（承接需求"试用"机制——按用户/角色/机构灰度开放、收集反馈后正式上线）；
• Prompt 资产管理：承接需求的三级提示词配置（模板/节点/全局）、占位符校验、发起时快照机制；Prompt 版本库支持回放与回滚；
• 配置回滚：目录版本回滚（需求已有）、审核规则配置即时生效与停用、场景规则集版本化推送（一致性检查通过后生效）统一纳入配置管理策略；
• 发布流程：应用发布与知识库/规则集更新解耦，互不影响线上任务。

八、方案小结

方案以"场景层 → 智能应用层 → 能力支撑层 → 评价闭环"承接业务，以四层技术栈与 LangGraph/DeepAgents/Higress/OTel/DeepEval 的 AI 专项栈支撑实现，以主题域化数据架构与"ESB + 微前端 + 共库只读"的集成模式约束边界，最终形成可观测、可评测、可迭代的信贷智能审查 AI 能力体系；部署上算力与业务分离、关键组件多实例，非功能设计按九节展开（性能与容量、可用性与容灾、降级矩阵、数据安全与脱敏、AI 质量与模型风险、审计与合规、成本与配额、可观测性 SLO、发布与配置运维），其中【待定版】/【待测算】条目随评审逐块定版。

1.3 - 智能信审平台需求文档

依据《信贷项目-智能信审平台-911》需求规格说明书与《信贷项目-智能信审系统对外交互方案-911》编制（第 10 章依据《财务风险分析系统需求文档 1028》补充），与智能信审平台业务架构概览页互补：概览页讲"是什么"，本分册按模块讲"要做成什么样"。

• 01 总体概述：项目背景、建设原则与业务目标、术语定义、系统边界与功能清单总览
• 02 业务架构与端到端流程：三层功能架构、授信审查与放款出账两条主线、统一任务模型与公共机制
• 03 悬浮按钮与任务管理：FAB 统一入口、点击触发规则、风险提醒、悬浮按钮配置、运行列表与运行管理配置
• 04 风险检查（小查）：触发方式、三个子模块、风险结果页与风险分析配置
• 05 类案对比（小审）：相似案例检索与对比分析、业务资料自动入库与三组配置
• 06 审查报告：自动生成流程、模板与批复条件配置、智能报告详情工作台
• 07 智能审核（小核）：目录同步与确认、分类与审核规则配置、材料上传与审查、小核配置
• 08 评价分析：评价查询、效果评价分析、未评价提醒与评价设置
• 09 对外交互方案：六种交互模式、十二个场景、38 项接口清单与放款智能审核接口契约
• 10 财务风险分析：财报风险分析系统（1028）——独立上传与对接信贷两种使用方式、财报上传与解析、972 条规则体系与四层筛选、十个风险域、议题聚合与三轴评分、八条一票否决、大模型判读与结论文案、统一发起接口与信贷系统集成

1.3.1 - 总体概述

1. 项目背景与系统定位

智能信审系统（即智能审查系统，下称"智能信审平台"或"本系统"）是智慧信贷二期项目 AI 能力建设的载体。门户以微前端形式集成信贷系统与智能信审平台两个平级子应用：智能信审的业务入口（悬浮按钮、页面跳转、iframe 嵌入）直接嵌入信贷系统作业页面，前端交互发生在两个微前端子应用之间；后端通过 ESB 与信贷系统各业务中心集成。信贷系统承载授信、审查、放款等业务流程。

外围交互系统包括：信贷管理系统各业务中心（授信作业中心、授信执行中心、客户中心等）、门户、调查报告系统（智能尽调系统）、企业知识平台、外部数据管理平台（EDS）、影像平台。详见 09 对外交互方案。

2. 建设原则与业务目标

本期建设以"科技赋能业务、辅助不替代、增强不决策“为核心原则：将 AI 能力嵌入审查、审批、放款与知识查询等高频信贷作业环节，在保留人工确认与复核的前提下实现风险识别与合规校验关口前移、文书撰写提效、知识即问即答。

3. 术语定义

4. 系统边界

• 会计核算：不适用，本需求与核算无关。
• 上报要求（金融监督管理总局/人民银行/其他）：本平台仅提供操作建议与预警，不适用。
• 经营分析/报表需求：不适用。
• 业务材料上传边界：本系统仅承接"放款申请资料上传"“出账申请资料上传"两个场景，授信执行中心不自建上传功能；其他业务资料上传不属于本系统范围。
• 审查报告查看权限：由授信作业中心统一判定，暂定仅总行审查人员、总行审批人员可查看。

5. 功能清单总览（二级功能 → 三级功能）

内部工具说明：运行数据测试控制台、审查报告调用为本项目内部模拟/联调页面，不向业务用户开放，不参与对外交互。

6. 本章关联文档

• 业务功能架构与端到端流程：02 业务架构与端到端流程
• 图表：业务功能架构（全屏 ↗）、系统交互全景（全屏 ↗）

1.3.2 - 业务架构与端到端流程

1. 业务功能架构

本系统由"底层能力 + 应用功能 + 评价闭环“三层构成，各模块以"制度 + 案例 + 知识"底座为支撑，覆盖审查、审批、放款与知识查询全流程。

全屏打开 ↗

业务操作本身较少，流程的核心是各能力模块之间的支撑关系：风险检查由信贷系统在授信申请提交后自动发起并可经悬浮按钮补充发起；类案对比与智能问答经悬浮按钮触达；智能审核（小核）在非放款审核场景可按配置发起，放款/出账审核场景仅重新检查和查看已有任务；审查意见生成与放款/出账审核由信贷系统在客户经理提交业务后自动发起；各功能产生的用户评价汇入效果评价分析，形成闭环。

2. 端到端业务主线

2.1 授信审查主线（业务发起 → 材料入库）

全屏打开 ↗

1. 业务提交：客户经理在授信作业中心提交授信申请成功后，授信作业中心调用”小查与审查意见生成统一发起接口"（同时保留小查自动发起、审查意见生成自动发起两个兼容接口），传入业务流水号、提交批次/版本、客户及流程上下文。
2. 统一受理：智能信审系统按业务流水号查询调查报告系统文件索引，从影像平台拉取该业务最新正式版调查报告 PDF 本地暂存（暂不向量化）；先统一执行一次财务分析与制度分析（财务要素、企查查、行业均值、政策法规等数据支撑只发生一次），再分别创建小查风险检查与审查意见生成任务，两任务复用同一次分析结果。
3. 智能分析：小查输出结构化风险检查结果；审查报告按模板章节、运行批次异步生成，经 SSE 流式推送。
4. 审查审批：审查人员在信贷系统审查审批页面经悬浮按钮或页面跳转进入，查看/编辑报告、核对风险事实、使用溯源与 AI 改写。
5. 终审与入库：终审结论区分处理——通过：批复生成后，审查意见 + 批复 PDF 存影像平台，统一打标编码写入文件名，调用入库通知接口；拒绝：仅审查意见入库（无批复），打标标记审批结论=拒绝；再议：流程废弃，不通知、不入库。智能信审系统拉取材料后，将调查报告、审查意见、批复三套材料统一向量化、生成业务级摘要与统一打标，写入 RAG 知识底座，供类案对比与小问使用。
6. 打回重提：业务被打回后重新提交时，授信作业中心再次调用统一发起接口，系统重新拉取最新调查报告、重新统一分析并再次执行；新结果覆盖当前有效结果，历史执行日志保留用于审计。

2.2 出账与放款主线（资料上传 → 智能审核）

全屏打开 ↗

1. 上传入口：客户经理在授信执行中心放款/出账业务页面点击"资料上传"（唯一入口，不提供悬浮按钮入口），经页面跳转进入本系统材料上传页面，URL 携带业务流水号、客户信息、上传场景编码与不可删除标记列表。
2. 上传任务：系统按"业务流水号 + 上传场景"创建或加载资料上传任务，快照当前生效目录版本；客户经理按目录上传材料（非末级目录自动分类，无法确认进"未分类"），可复用历史材料（信贷系统物理复制）、对停用材料执行"失效"。
3. 一键预审：异步执行审核规则（规则 + 大模型），前端轮询进度；材料变化会使预审结果失效；未变化的规则沿用上次有效结果。
4. 提交上传任务：校验目录版本、处理中/解析失败/未分类材料、必传材料与风险项，通过后冻结当前目录版本。上传任务提交不触发审核。
5. 业务提交：客户经理返回授信执行中心正式提交放款申请（loanReleaseApply）或出账申请（paymentManage）后，授信执行中心自动调用"放款智能审核接口“发起对应场景审核。
6. 智能审核：智能信审系统按"业务流水号 + 审核场景"幂等执行材料智能审核与制度风险分析（制度检查范围按功能编码映射的制度集合确定），返回材料风险、制度风险与合并风险等级（取高）；打回重提重新发起并覆盖本场景当前有效结果；放款审核与出账审核相互独立。
7. 审查岗复核：放款/出账审查岗在"业务材料审查"工作台以"问题审查（问题队列 + 证据原文 + 问题详情）/全部材料"两种视图复核，任务支持"材料审核 N / 制度审核 M"分段切换。

全屏打开 ↗

2.3 主数据与门户

前端层面，门户统一承载信贷系统与智能信审两个微前端子应用，两个子应用之间直接完成缓存读写、页面跳转与页面嵌入（不走 ESB）；门户与智能信审之间仅保留系统级对接（主数据同步、知识库菜单集成）。机构、用户、角色及关系数据以门户为准：门户经 ESB 实时发送"门户主数据变更通知”（五大项：机构、用户、角色、机构-用户关系、用户-角色关系；菜单不再同步），企业知识平台做表级批量同步兜底。知识库功能通过门户菜单直接集成（场景 12）。

3. 统一任务模型

各智能体任务（小查/小审/小核/审查报告）共用一套任务运行机制：

3.1 触发模式与唯一性

• 每个任务类型维护任务唯一性标识（无/客户号/批复编号/业务流水号）与是否可重复发起：允许重复且有唯一标识的任务，重复发起将覆盖原任务（原任务执行中则自动终止并重新执行）；禁止重复时按入口语义拒绝或回退手工入口。
• 放款审核、出账审核不允许经悬浮按钮创建或重复发起，仅接收信贷系统回调创建的任务；小查信贷模式任务由授信作业中心调用统一发起接口创建，不经悬浮按钮提交接口。

3.2 任务状态与轮询

• 任务状态在**运行中 → 部分完成 → 已完成（成功/失败）**间流转；小核只允许运行中、已完成两种状态，不产生部分完成。
• 状态非实时推送：悬浮按钮使用唯一轮询器（有运行中任务默认 10 秒、空闲默认 60 秒，均可配置；失败指数退避，标签页恢复可见立即补拉），已完成未读数增加时弹出一次汇总通知。
• 首次拉取仅建立未读基线不弹窗；3 秒时间窗内多个任务完成只弹一次汇总通知。

3.3 评价机制

• 任务式功能按任务（小查按可评价子模块分项）评价；对话式功能（小问）按 AI 回答逐条评价——会话中存在任一未评价回答即视为整任务未评价。
• 评价要素：评分（0–100）、评价等级（按分数自动命中）、反馈原因（多选）、补充说明（≤200 字符）、截图。详见 08 评价分析。

4. 公共机制约定

• 统一字典机制：业务页面下拉选项（类型、检索方式、企业性质、行业三级、贷款用途、产品、担保方式、风险等级 FAB_RISK_LEVEL、评价等级等）均通过统一字典加载，禁止写死静态字典数组。
• 数据权限：任务数据按业务权限与用户可见范围隔离，用户仅可见本人经办、审查或授权范围内的任务；信贷模式任务发起方记录为授信作业中心/授信执行中心。
• 软删除与引用保护：各类配置记录删除均为逻辑删除；被规则、任务、流程引用的对象禁止删除。
• 版本快照：任务启动时冻结配置快照（模板、批复条件、目录版本、提示词等），后续配置变化仅影响新任务；业务重新提交时覆盖"当前有效结果"、保留历史执行日志。
• 上传人员脱敏：列表中上传人员脱敏显示（如张**）。

5. 本章关联文档

• 上一章：01 总体概述
• 入口与任务管理细节：03 悬浮按钮与任务管理
• 对外交互：09 对外交互方案

1.3.3 - 悬浮按钮与任务管理

1. 悬浮按钮（FAB）

1.1 功能概述

悬浮按钮（AI 悬浮按钮）是各智能体在信贷系统作业页面上的统一入口，常驻页面右侧。系统根据管理员功能配置、用户逐功能显示偏好、当前末级功能、页面业务上下文以及任务状态，动态展示小查、小审、小核、小问。

• 两层入口语义：折叠态彩色圆形主按钮是"查看已有结果或发起新任务"的复合入口；悬停展开后的自动、手工、运行中和完成徽标均为含义确定的单项入口。
• 圆形主按钮仅对任务类功能执行可排序的点击触发规则；小问直接打开对话。
• 小查的"自动发起/手工发起"均由审查人员发起，作为补充入口；主场景为授信申请提交后由授信作业中心调用统一发起接口自动创建（信贷模式）。放款/出账审核不适用"智能审核"发起操作，其任务由信贷系统提交业务后自动创建，悬浮按钮仅展示运行中和完成结果入口。
• 任务类功能展开后展示运行中数量、已完成未读数量、自动操作和可用的手工操作；不展示部分完成数量或绿点（小核任务不使用部分完成状态）。
• 智能体渲染顺序固定（任务类在前、问答类置底）。

1.2 操作权限

悬浮按钮不承载数据维护权限，所有任务的发起与查看均复用信贷系统的单点登录身份与功能权限。

1.3 显示规则（优先级从高到低）

1. 管理员禁用 → 不展示；
2. 用户"整体隐藏" → 隐藏整个悬浮按钮（保留右侧窄触发条用于恢复）；
3. 用户"始终隐藏" → 隐藏该功能（逐功能隐藏只影响入口，不停止后台轮询和通知）；
4. 用户"始终启用" → 强制展示（不绕过自动任务上下文校验）；
5. “自动显示”：管理员始终显示、存在运行中/已完成未读任务、或当前末级功能命中绑定且上下文满足，任一成立即展示。

1.4 圆形主按钮点击触发规则（可配置顺序，只执行第一条命中）

规则要点：

• “提交自动任务"是复合分支；取消确认后本次点击结束，不执行后续规则。
• 展开后的"自动"按钮只执行自动任务，所有分支均不得切换为手工；“手工"按钮只打开手工入口。
• 配置读取时对规则顺序做规范化：忽略未知项和重复项，按默认顺序补齐缺失规则。
• 展开后的单项按钮不受点击规则顺序影响；“运行中/完成"徽标仅在数量 >0 时显示，点击进入相应筛选后的运行列表。

1.5 风险提醒（仅小查、小核）

• 功能已启用风险提醒且存在未读的已完成任务时，圆点右上角显示风险等级角标（高/中/低/疑，经 FAB_RISK_LEVEL 字典加载），圆点与完成徽标颜色随最高风险等级变化；高风险时圆点字符在"功能字"与"风险字"间交替闪烁。
• 放款/出账审核任务的风险等级按"材料+制度统一考虑"合并：取材料智能审核风险与制度风险分析中的更高者；仅制度发现高风险时该笔业务同样按高风险驱动；均无风险时不驱动。
• 风险提醒只增强视觉提示，不改变点击规则；用户"始终隐藏"仍具最高优先级；管理员可按功能启停并自定义各级颜色（6 位 HEX，统一转大写）。

1.6 界面与关键规则

界面 1：悬浮按钮（折叠/展开）

• 折叠态：每个智能体显示单字标识（查/审/核/问）；运行中任务→脉冲动效；已完成未读→右上角红点。
• 展开态：显示"别名 + 功能说明”，右侧操作区——小查：运行中、完成、自动发起、手工发起；小审：运行中、完成、自动查找、手工查找；小核：运行中、完成（非放款审核场景可按配置展示"智能审核”，放款审核场景不展示发起按钮，无手工入口）；小问：仅"打开对话”。
• 自动按钮不满足当前业务页面或上下文时显示禁用样式，点击给出明确提示。
• 后端接口：配置接口（功能定义 + 末级绑定规则）、汇总接口（按智能体聚合运行中数/已完成未读数/失败数 + 最高未读风险等级，带版本号或变更时间）、自动提交接口（校验页面上下文、权限和唯一性；放款审核禁止经此发起）、已读标记接口、用户偏好接口。

界面 2：AI 助手设置对话框（鼠标悬停约 1 秒浮现设置齿轮）

• 整体隐藏悬浮按钮（开关，默认关；开启后仅保留约 6×48 像素半透明触发条）；
• 各功能显示方式（仅列管理员已启用功能，单选：自动显示/始终启用/始终隐藏，默认自动显示）；
• 纵向位置距底部滑块（最小 24px，默认 88px，上限随视口动态计算，区间内夹取）；
• 底部：恢复默认 / 取消 / 保存（乐观更新，失败回滚并仅控制台告警）。偏好按当前登录用户维度保存在服务端，合并优先级：用户值 > 管理员默认值 > 前端兜底常量；历史"显示全部已启用功能"偏好不迁移、不参与判断。

界面 3：任务完成提醒弹窗——轮询感知已完成未读增量后弹出系统通知"智能分析：有 N 个任务已完成"（成功类型，4 秒自动关闭），同步刷新角标并经事件总线广播。

界面 4：小查手工发起弹窗——标题"小查 · 手工发起"（860px，遮罩不可关闭）：查询条件区（客户号/客户名称/业务流水号，模糊匹配，至少输入一项）；调查报告单选列表（报告编号、客户号、客户名称、业务流水号、报告标题、业务功能、报告日期）；子模块选择区（禁用模块灰色显示"建设中"）。“开始检查"校验：必选一条调查报告 + 至少一个子模块；成功后仅提示"已经发起”，不自动跳转。

界面 5：小审检索配置弹窗——标题"类似案例对比 - 检索配置"（1200px），亦为类案对比列表页"新增"所复用：

• 检索方式（字典 CC_SEARCH_MODE）联动三区显示：精确条件筛选加语义检索 / 语义检索 / 仅精确条件检索；隐藏区域不参与必填校验、已填内容保留。
• 基础信息：类别、检索方式、是否数据抽取、是否项目贷款（CC_LOAN_TYPE，必选默认非项目贷款，项目/非项目不允许混用）、是否比对分析（选"是"时显示对比业务——经业务查找弹窗回填业务流水号、业务名称、客户名称、客户号；个人业务另显示产品种类）。
• 精确条件区：类型（可清空单选，与基础区联动）、企业性质、企业规模、经营年限范围、所属行业三级级联（大类→中类→小类按编码前缀过滤并清空）、贷款用途、产品（命中任意一个即匹配；“授信"匹配无产品业务）、主担保类型、所属分行、审批通过时间范围。
• 近似关键词区：关键词（逗号分隔）+ 最大数量（1–50）。
• 差异化必填校验 + 年限/日期区间合法性校验；通过后提示"检索请求已受理"并广播任务创建事件。

界面 6：小问对话面板——参看知识库部分。现状为简化浮层对话面板（单会话、会话仅内存、刷新后清空、不支持深链定位会话），完整版将参考 A 项目重构后回填。

2. 悬浮按钮配置

面向系统管理员，管理功能启停、末级功能绑定、上下文要求、管理员始终显示、圆形主按钮点击规则顺序及轮询参数；对所有用户统一生效（个人显示偏好在"AI 助手设置"维护）。

页面六区域：功能管理（别名/说明/类型/槽位 1-6/启用开关）、末级功能绑定（管理员始终显示、上下文要求[无/客户号/批复编号/业务流水号]、绑定末级功能多选；开启始终显示时绑定选择禁用并清空）、角色功能路由（小核任务按角色路由到业务功能页面的映射及进入方式[仅查看/正常]；业务材料上传/审查默认"仅查看”；无匹配路由跳转通用运行详情；目标路由与进入方式均为服务端配置项，程序不写死）、点击触发配置（5 条规则拖拽排序）、风险提醒配置（小查/小核启停 + 高/中/低/疑四级颜色，全功能统一，实时预览）、轮询与行为（轮询间隔 3–120 秒默认 10；空闲间隔 30–300 秒默认 60；标签页隐藏暂停轮询默认开）。

小查的末级功能绑定即为小查功能覆盖范围的唯一事实源；风险分析配置不再维护子模块级功能绑定，小查触发后在其覆盖范围内统一运行所有启用子模块。

3. 智能体运行列表

展示当前用户可见的各智能体分析任务记录；悬浮按钮"已完成"区域点击后跳转至本列表并按来源智能体预过滤。

• 主流程：进入运行列表（支持按功能、模式、状态、结果、风险等级、已读、评价状态筛选与分页）→ 点击任务标题/“查看”→（未读先调标记已读接口并刷新角标）→ 运行详情 → 返回列表（保留筛选与分页位置）。
• 详情页路由：审查报告 → 报告详情页；小审 → 类似案例对比详情页；其他 → 通用运行详情页。
• 运行详情页：顶部任务基础信息（只读，双列）；分析结果区按功能差异化渲染（小查渲染结构化风险检查结果组件；其他功能暂为占位）；结果评价区（小查按可评价子模块分项，其他按整任务单面板；评分 0–100、等级自动命中、反馈原因多选、补充说明 ≤200 字符、截图；已有评价回显）。
• 数据权限：按当前登录用户与业务权限过滤；自动/手动任务按提交人关联，信贷任务按业务经办、审查或授权范围关联。

4. 运行管理配置

面向系统管理员，集中管理各任务类型运行策略（与悬浮按钮配置互补：后者管"显示什么、何时显示"，本配置管"怎么执行、能否重复、何时超时"）。

列表操作：新增/编辑（弹窗 560px，确定带加载态防重）/删除；保存时后端校验名称唯一、枚举合法与数值区间。

5. 本章关联文档

• 任务状态与覆盖规则详见：02 业务架构与端到端流程 第 3 节
• 下一章：04 风险检查（小查）

1.3.4 - 风险检查（小查）

1. 风险审查（小查）

1.1 功能概述

风险审查（小查）是智能信审系统的风险检查智能体，可由信贷系统在授信申请提交后自动发起（主入口），也可由信贷作业用户通过悬浮按钮自动或手工补充发起，输出结构化风险检查结果供用户参考。

• 适用范围：支持全部业务类型（对公、个人等），不同业务的数据完整性不同；当业务无可用数据支撑时，不执行分析，结果页提示"无数据支撑"（dataSupported=false，子模块数组为空，任务置为已完成/成功）。
• 子模块（按风险分析配置启停；功能覆盖范围以悬浮按钮配置的末级功能绑定为准）：
  1. 制度合规检查：按制度规则核查业务材料合规性，输出风险等级与整改建议；
  2. 调查报告专项分析：按 7 项专项分析调查报告风险——主营业务识别、关联交易、客户集中度、授信匹配、资产结构、利润结构、现金流量，另含自由风险识别；
  3. 财务分析：建设中（占位状态）；所需企查查数据经外部数据管理平台获取（对外交互方案场景 1）。
• 输入材料：调查报告文档（PDF），不使用结构化数据；自动与手工发起均以调查报告为分析对象。

1.2 操作权限

1.3 业务处理流程

1. 信贷自动发起（主场景）：授信申请提交成功后，授信作业中心调用统一发起接口（同时发起小查与审查意见生成），传入业务流水号、提交批次/版本、客户及流程上下文。智能信审系统校验上下文和唯一性后创建任务（状态=运行中，模式=信贷），按业务流水号查询调查报告系统文件索引，获取最新正式版调查报告的文件名与影像位置，从影像平台拉取 PDF 并在本系统对象存储暂存，随后按启用的子模块异步执行风险检查。
2. 悬浮按钮自动发起：读取前端缓存的业务流水号等上下文提交；已有任务时按运行管理配置处理（允许重复→确认后重发并覆盖；禁止→拒绝）。
3. 手工发起：悬浮按钮"手工发起"弹窗，按客户号/客户名称/业务流水号组合查询调查报告（至少一项），单选一条后选择参与检查的子模块（禁用模块不可选，默认全选已启用），提交后任务标记手工模式，提示"已经发起"。
4. 异步分析：先判断业务数据可用性（无数据支撑→直接完成并携带标记）；部分字段缺失按"该维度数据缺失"处理；部分子模块完成→“部分完成”，全部完成→“已完成（成功/失败）"。状态经悬浮按钮轮询感知。
5. 结果查看与评价：经悬浮按钮"已完成"或运行列表进入运行详情页；按可评价子模块分项评价（复用运行列表评价机制）。
6. 打回重提：业务被打回重新提交时再次调用统一发起接口，按"业务流水号 + 小查场景"重新执行，新结果覆盖原当前有效结果，历史执行日志保留用于审计。

1.4 界面：小查风险检查结果（运行详情页）

• 无数据支撑提示：结果携带 dataSupported=false 时，不展示风险概览与模块面板，展示"无数据支撑"提示语及说明。
• 风险概览面板：统计栏展示风险项合计与各等级计数（高风险红、中风险橙、低风险蓝、存疑紫、合规绿）；支持按模块多选与按风险等级多选筛选。
• 各模块面板（可折叠）：制度合规检查、调查报告专项分析展示风险条目列表；财务分析显示"建设中"占位。
• 风险条目卡片：左边框按等级着色；展示风险等级标签、专项名称、风险标题、风险描述、整改建议、溯源原文（可折叠：来源类别[制度/业务类别]、文档名称、路径、原文片段）。
• 分析总结条目不计入风险统计，作为模块底部总结性描述。

后端要点：统一发起接口返回任务编号与受理状态；调查报告不存在、不可访问、格式错误或版本不一致时任务置为失败并保留错误原因，按运行管理配置重试；任务详情接口返回子模块数组（编码、名称、启用/占位标记、风险条目列表、统计信息）及数据支撑标记；风险条目结构含等级（高/中/低/存疑/合规/总结）、专项名称、标题、描述、整改建议、溯源证据数组。

2. 风险分析配置

面向评价分析管理员/系统管理员，管理小查子模块启停与调查报告专项分析参数。

• 参数范围：子模块启停（制度合规检查/调查报告专项分析/财务分析）；调查报告专项分析的系统提示词（所有专项共享）、检查项目（可增删、启停、编辑名称/必查点/提示词；必查点以中文顿号”、“分隔保存为数组）、自由检查（是否开启自由风险识别及其提示词；关闭时提示词框禁用）。
• 边界约定：本页仅维护子模块启停，不再维护子模块×末级功能绑定（小查功能覆盖范围以悬浮按钮配置为准）。
• 界面：四个区域（子模块管理 / 系统提示词 / 检查项目 / 自由检查）+ 右上角"保存风险分析配置”。
• 后端：配置读取/保存接口（合并写入返回完整配置）；统一发起接口按启用的子模块创建运行中的小查任务。

3. 本章关联文档

• 触发与任务状态公共机制：03 悬浮按钮与任务管理、02 业务架构与端到端流程
• 调查报告获取与数据支撑交互：09 对外交互方案 场景 1
• 制度合规检查的制度规则来源：制度拆解（底层能力，见 02 章）
• 下一章：05 类案对比（小审）

1.3.5 - 类案对比（小审）

1. 类案对比

1.1 功能概述

类案对比面向信贷作业用户与智能信审系统，对当前在办业务从历史相似案例库中检索、抽取、对比并形成结论，为审查决策提供横向参照与可解释依据。分析结果仅供人工审查辅助，不触发自动审批。

• 案例抽取范围：抽取维度是审批流程结束的结论，即调查报告、审查报告、批复的材料组合；审批结果包括通过、拒绝、再议——通过、拒绝业务入库并纳入抽取范围，仅再议业务不入库；不抽取对比客户自身的业务。
• 抽取数据范围：近五年数据（需连续一致），时间自系统上线起回推。
• 贷款类型：任务贷款类型统一为项目贷款/非项目贷款两类，不允许混用。手工创建必选；自动查找按"固定资产贷款产品名单"自动判定（对公命中名单=项目贷款、未命中=非项目贷款；个人默认非项目贷款）。任务首次抽取记录"首次抽取类型"（=任务贷款类型）；重新抽取固定使用任务贷款类型、不可更改，且不更新首次抽取类型。
• 分析材料：调查报告、审查意见、批复三套文档材料（向量化存入 RAG 知识底座）+ 贷后五级分类数据（经接口从企业知识平台实时获取，不入库）。
• 运行模式：模式一，新增类似案例对比任务（三入口：悬浮按钮手工发起 / 悬浮按钮以当前业务自动发起 / 结果页"新增"）；模式二，在已有任务数据中再次发起数据抽取或类似案例分析。

1.2 操作权限

1.3 业务处理流程

1. 列表页经统一字典加载下拉项，按"首次抽取类型"“发起方式"等列展示，支持按类别、首次抽取类型、状态、结果筛选（提交时间倒序）。
2. “新增"弹出检索配置弹窗（见 03 章 界面 5），提交后创建任务并记录首次抽取类型与发起方式，经 ESB 调用信贷系统查询业务基本信息并启动相似案例检索。
3. 任务期间轮询任务状态，经影像平台拉取该业务对应的调查报告、审查意见和批复三套材料 PDF 向量化处理，并实时获取贷后五级分类数据。
4. 详情页五个页签：类似案例列表 / 对比业务关键要素 / 类似案例数据抽取 / 业务对比分析 / 运行情况与反馈。
5. 对比业务关键要素：自动任务回显信贷数据并标记字段来源；手工任务初始为空（无"对比原业务"卡片）。表单按行业（三级级联）、企业经营、财务表现、申请方案与担保分区；担保方式为抵押时抵押率显示并必填。校验：经营年限 ≥0、敞口与期限 >0、抵押率 0–100。修改值只作用于当前任务、不回写信贷系统。
6. 重新抽取数据：需至少选中一个案例；确认"将重新生成 N 个业务的数据统计，会覆盖当前数据"后按任务贷款类型执行，抽取期间页签显示"数据抽取中"并提供刷新。
7. 重新进行对比分析：先保存并校验关键要素（不完整→跳转要素页签提示缺失项；后端错误码 CC_BUSINESS_INCOMPLETE 同样处理，不覆盖既有结果）；确认覆盖后重算。
8. 类似案例数据抽取页签：上区非项目贷款、下区项目贷款两区动态列表格（列由后端抽取列定义动态渲染；单类型任务仅对应区域有数据）；空值按字段适用性显示"无法确认"或"不适用”；支持按类型导出 Excel（含期次、证据状态和来源证据明细，供审计复核）。
9. 业务对比分析页签：见 1.4。
10. 运行情况与反馈页签：复用审查报告详情的运行反馈组件（基础信息 + 运行情况 + 结果评价）。

异常处理要点：创建/查询/详情/重抽/重算失败均以消息提示后端错误并保留现状；所选案例为空警告"请至少选择一个案例”；大模型分析进行中展示骨架占位与"大模型正在分析中，请刷新"；规则结论与模型结论方向或建议额度不一致时并列展示并提示以人工复核为准。

1.4 业务对比分析页签

• 对比概览卡：参与对比案例数、通过/未通过案例数、平均相似度、高度相似贷后良好率、分析时间。
• 数据对比图形区：相似度雷达图、额度对比、产品构成、担保结构（按担保类型字典聚合，半栏）、财务指标、贷后五级分类分布（半栏）六类图形 + 对比明细表（客户名称、相似度、审批结果、五级分类、申请敞口、批复敞口、担保方式、未通过原因）。
• 量化证据校验（规则分析结论）：结论标签三档——建议通过（绿）/建议谨慎通过并加强风控（黄）/建议审慎，暂不通过（红）；统计指标（对比贷款数、高度相似贷款数、高度相似通过率、建议敞口额度及计算依据）；判定依据列表；触发未通过案例相似度红线时错误告警。有效样本口径：仅同行业且数据覆盖率达标的案例进入有效样本统计，跨行业及行业无法确认案例只展示。
• 辅助审查建议（大模型分析结论）：两阶段执行——第一阶段单案摘要（逐案例基于三套向量化材料与贷后五级分类数据提炼关键证据），第二阶段综合建议；阶段横幅实时展示进度。产出含：建议标签与置信度、可核验的分析思路（每步含事实证据/专业判断/结论影响，四色标识）、关键证据权衡（支持/制约因素 + 决定性判断）、综合判断理由、建议敞口额度与期限、建议风控措施、相似点与差异点、数据局限与待核实事项。

1.5 关联配置

• 摘要与自动查找设置（系统管理员）：按对公/个人分别维护业务摘要提示词、自动检索提示词（均必填）；自动查找配置（是否数据抽取、是否比对分析、最大输出数量 1–100 默认 10）；“项目贷款判定配置（固定资产贷款产品）“经产品字典（CC_PRODUCT）多选维护，可恢复默认。配置保存后仅对后续新任务生效。旧接口仅返回通用提示词时，前端兼容映射到对公配置。
• 类案抽取配置（系统管理员维护公共配置，审批人员可个性化）：按客户类型（对公/个人）分入口，含四页签——行业映射配置、产品映射配置、项目贷款字段配置、非项目贷款字段配置。字段配置含字段编码、名称、值类型、统一单位、期次口径、启用状态、证据要求（“必须返回来源证据”）和提示词；停用字段不进入新任务抽取列。删除行业/产品映射时级联删除对应抽取字段配置与已选关联。一笔业务涉及多行业/产品时抽取列取并集，各案例只填充自身适用字段。个性化配置按作用域标识区分，审批人员可将本人配置按客户类型还原为公共配置快照（不还原行业分类与产品分类基础数据）。
• 业务对比分析配置（系统管理员）：
  • 固定口径只读：综合相似度按维度及维度内字段权重计算；行业层级——同小类 100 分、同中类/同大类分值可配置、跨大类 0 分；覆盖率按实际可用权重披露，缺失字段不以零分代替；结果字段隔离。
  • 相似度权重与行业分值：行业匹配/企业经营/财务情况/申请方案与担保四维权重（各 0–100，合计必须 100%，实时提示）；同中类行业分值不得低于同大类分值。
  • 结论、额度与置信度参数：高度相似阈值、最低有效样本数（1–20）、最低数据覆盖率、高度相似案例通过率门槛、贷后后三类占比上限、未通过案例相似度红线（不得低于高度相似阈值）、额度最低有效样本数、高置信度最低有效案例数（不得低于最低有效样本数）、高置信度最低平均覆盖率（不得低于最低数据覆盖率）。最低有效样本不足时只能输出低置信度辅助意见；存在仅同大类匹配的有效案例时不能评为高置信度。
  • 结构化分析提示词：入库摘要、单案分析、综合分析三类，支持输入预览与恢复系统默认；保存时校验占位符（未知或缺少必要占位符禁止保存）。后端对模型输出执行固定 JSON 结构、样本范围、额度上限和证据完整性校验，管理员提示词不能绕过系统约束。

2. 业务资料自动入库

后台处理能力，无独立前端界面。与历史数据迁移（存量一次性初始化入库）相互独立。

2.1 数据源及触发时点

• 通过业务入库三套材料；拒绝业务仅调查报告与审查意见两套（无批复），统一打标标记审批结论=拒绝；再议业务该流程废弃，不通知、不入库。
• 贷后五级分类数据不入库，经接口从企业知识平台实时获取。
• 入库数据服务于两个场景：类案对比（业务摘要用于语义相似检索，统一打标用于精确条件检索）与小问业务材料问答（原始材料与摘要供检索与溯源）。

2.2 关键规则

• 业务唯一性与版本：业务流水号为唯一主键；一笔业务最多各保留一份当前有效的调查报告/审查意见/批复，同一材料类型更新时覆盖旧有效版本；检索与问答只使用当前有效版本；一笔业务只有一份业务摘要和一套统一打标。
• 摘要与打标：审查意见或批复入库时触发该业务摘要重新生成与统一打标更新；摘要综合当前全部有效材料并使用"摘要与自动查找设置"中当前生效的提示词；调查报告系统的标签作为初始数据，最终统一打标以入库通知文件名承载为准（自文件名解析）。打标字段至少含：企业性质、企业规模、经营年限、所属行业、贷款用途、产品（多值，无产品标"授信”）、主担保类型、所属分行、业务审批通过时间（仅通过业务填写）、审批结论（通过/拒绝）及业务流水号等关联标识。“类型（项目/非项目贷款）“由本系统按产品名单自动判定，不打标。
• 后端处理：自动发起与入库通知均支持幂等；不采用轮询获取新文件；同一业务多材料任务按业务流水号串行化；RAG 底座建立业务流水号、材料类型、来源系统、文件状态、摘要与统一打标关联。
• 异常处理：索引查询超时按退避重试；影像拉取失败进重试队列且未成功前不覆盖原有效文件；格式校验失败保留索引待源系统修正；摘要提取失败不发布不完整索引、重试成功后原子更新；打标缺失允许为空并记录来源；并发更新按流水号加锁/版本号校验；重复通知按流水号+材料类型+更新时间幂等跳过。

3. 本章关联文档

• 检索配置弹窗与悬浮按钮入口：03 悬浮按钮与任务管理
• 材料入库触发链路：02 业务架构与端到端流程、09 对外交互方案 场景 4/5
• 下一章：06 审查报告

1.3.6 - 审查报告

1. 审查报告生成

1.1 功能概述

审查报告生成是智能信审平台的核心业务能力，本身无独立操作界面：由信贷系统（授信作业中心）在业务提交环节自动触发，无需人工发起。依据管理员预先配置的审查报告模板、批复条件、运行管理及各类检查配置自动执行，产出可供审查人员查看、编辑和提交的审查报告。

• 报告范围：本期覆盖 9 类报告——非集团审查报告、集团审查报告、住房审查报告、消费审查报告、经营贷审查报告、同业报告、低风险报告、委托贷款报告、银行信用债报告。
• 术语说明：“审查意见生成"指授信作业中心业务提交后自动触发审查报告生成的运行场景编码与接口命名，产物为审查报告，相关接口命名沿用该场景名称。

1.2 业务处理流程

1. 客户经理提交授信业务，系统判定需出具审查意见。
2. 业务提交成功后，信贷系统自动调用审查意见生成接口（传入业务流水号、提交批次/版本、客户及流程上下文）；本系统不提供人工发起入口。
3. 按"业务流水号 + 审查意见生成场景"创建或更新任务，按运行管理配置执行（信贷发起、业务流水号唯一标识、重试次数、运行时限）。
4. 后端冻结本次提交对应的业务数据、材料及配置快照（模板、批复条件等），加载任务模板，从信贷系统查询业务基本信息，从客户中心查询财务要素和客户关系，结合调查报告及相关检查结果启动 AI 生成。
5. 按模板章节、运行批次、输入能力和上游章节依赖依次执行：先生成事实类章节（授信方案概述、借款人基本情况、项目情况、担保情况分析），再生成授信方案可行性分析、结论及建议，最后生成批复条件及各类检查附件章节；各章节调用模板配置的能力提供方（调查报告结构化数据、调查报告专项分析、制度合规检查、政策检查、行业均值检查、批复条件自动生成）并遵循系统提示词约束。
6. 异步任务，通过 SSE 按章节流式推送；报告状态：排队中 → 生成中 → 生成完成/生成失败。
7. 业务打回重提时重新执行并覆盖当前有效结果；历史执行日志保留用于审计。
8. 生成完成后，审查人员进入智能报告详情页查看、编辑、溯源和提交。

2. 审查报告模板配置

面向系统管理员，直接维护模板结构、匹配规则及报告生成规格；配置不描述工作流节点/连线/重试/并发，由后端将报告生成规格编译为生产工作流。

• 模板类型与匹配：区分集团、非集团和个人三类模板，均由管理员新建、不预置；按匹配优先级（1 最高，100 最低，默认 50）+ 授信类型 + 产品维度匹配（产品为空表示适用全部产品）。
• 生效机制：暂存只更新唯一一份未发布草稿，不影响生产；确认发布后生效版本号递增并形成不可变生效版本；任务启动时冻结生效版本、格式和提示词快照。暂存/发布/放弃均携带草稿版本号，不一致返回版本冲突。
• 章节结构：章节、顺序、章内标题树均由管理员配置，无固定结构。章节类型：正文、批复条件（单例系统章节，重复新增时定位已有章节）、附件（能力须声明支持附件场景且输出类型为表格；初始附件为制度检查明细、政策检查明细、行业均值对比，不含财务分析附件）。
• 运行批次：批次为正整数（允许 10/20/30 等不连续批次号），相同批次并行、按数值升序执行；章节序号只控制展示顺序，运行批次只控制执行顺序；前章结果只能引用运行批次更小的正文。出厂配置：事实摘录章节和三类检查附件为第 1 批，可行性分析第 2 批，结论第 3 批，批复条件第 4 批。
• 章内标题树：支持二至四级；节点含稳定编码（一级章节内唯一）、标题、层级（须与深度一致）、同级序号、节点生成要求和子标题；每个节点必须生成正文，渲染顺序固定"标题→本节点正文→子标题→子节点正文”；模型只返回节点正文（Markdown，允许段落/列表/表格），不得返回或修改模板标题；旧版纯标题列表读取时自动迁移为二级节点。
• 提示词分层：
  • 工作流强制规则（不可编辑）：证据编码格式、引用真实性校验、未知证据拒绝、缺失信息兜底、结构化返回校验；
  • 模板系统提示词：审查角色、通用写作规则、集团/非集团差异；
  • 章节提示词与输出约束：章节范围、摘录或分析方式、输入来源、输出组织；
  • 节点生成要求：二至四级标题的细项规则（不得手写文件标识、页码或引用编号）。
• 引用契约：引用含单元内数字编号、工作流证据编码、来源类型（原始材料/系统能力结果）、文件标识、元素标识、原文片段、来源名称、能力编码和前章派生单元标识。模型只能使用本次证据目录中的证据引用标记（如 E001），后台验证后按首次出现顺序转换为数字引用（[1]）；无效引用先由工作流修复，仍失败输出统一缺失口径，不得保存虚假引用。前章结果不作为最终证据，后续章节使用前章事实时须继承并指向底层原始证据。
• 保存校验：至少一个正文；章节编码唯一；正文标题和提示词完整；运行批次为正整数；前章引用合法；系统章节能力有效；节点编码唯一、标题非空、层级连续 ≤4 级、同级序号连续。
• 界面：模板列表（按优先级升序、名称防抖 500ms 搜索、发布状态标签[未发布/已发布/有未发布修改]、操作：编辑模板/查看生效/删除）→ 创建/编辑弹窗（名称 1–200 字符、优先级、授信类型字典 RT_CREDIT_TYPE、产品字典 RT_PRODUCT 多选）→ 模板详情（“章节配置”+“模板格式编辑"两页签；顶部操作：放弃未发布修改/暂存/确认发布——发布前弹监管人工核验提示；模板格式编辑复用智能报告详情富文本编辑器，标题、编号和 AI 内容占位为受保护内容，页边距、页眉、页脚继承原文件只读）。

3. 批复条件配置

以模板方式维护标准贷前、贷后条件及自由审核规则。

• 一份模板可关联多个产品，一个产品只能关联一份模板；模板可暂不关联产品。配置保存即形成新版本；报告任务启动时冻结批复条件配置快照。
• 标准条件项字段：顺序（正整数不重复）、类别（RT_APPROVAL_CATEGORY：贷前落实条件/贷后落实条件）、必选性（RT_APPROVAL_REQUIRED：必选/可选）、合同项、标题、标准文本、分项提示词。
• 自由审核可启停并维护提示词，结果固定归入贷前落实条件；启用时提示词必填。
• 保存携带草稿版本号乐观锁；名称/系统提示词/条件标题/标准文本必填；产品冲突时返回已关联的冲突模板及产品信息，禁止覆盖。删除模板后原关联产品不再具有批复条件模板；已启动任务仍使用冻结快照。

4. 模板分析配置

保留在"功能备份"菜单的独立系统管理员功能，维护历史模板文件分析能力的两份 AI 分析提示词（首次上传分析提示词、变更模板文件分析提示词，均必填 ≤12000 字）。不与当前模板管理流程联动；配置只有当前版本、不保留可恢复历史；保存后立即影响新任务，运行中任务冻结启动快照。单个模板只能维护可选"分析备注”。

• 固定步骤与进度（后端固定实现，进度单调递增，前端只展示返回值）：
  • 首次上传：文件安全和完整性检查 0–10% → DOCX 内容与格式提取 10–25% → AI 全量结构和语义分析 25–65% → 集团/非集团审核基线映射 65–85% → 校验修复及草稿组装 85–100%；
  • 变更模板文件：文件检查和提取 0–25% → AI 全量识别新目录与章节语义 25–55% → 对比当前配置并生成合并建议 55–85% → 校验并形成合并预览 85–100%。
• 校验：再校验最大四级、编码唯一、系统章节、正整数批次、能力和前章引用；仍失败任务置为失败，原草稿和生效版本不变。变更匹配优先按稳定编码、标准化标题和父级路径匹配；匹配节点保留原配置，新增节点生成局部建议，移除节点必须人工确认。

5. 智能报告详情

审查报告模块的核心页面：AI 辅助报告查看、编辑、溯源和修订追踪的全流程工作台。

5.1 布局与进入方式

• 三栏布局：左侧目录树（点击锚定跳转）、中间富文本编辑器（含缩放 50%–200%）、右侧面板（报告溯源、修改记录子页签）；三栏均可折叠。
• 页头：返回、报告标题（客户名称）、页签切换（调查报告/运行情况与反馈）、隐藏/显示标记、保存、报告下载、全屏。
• 进入方式：审查人员从授信作业中心任务入口或运行列表进入已创建的报告任务（携带业务流水号、任务标识与工作区标识）；查看权限由授信作业中心统一判定（暂定仅总行审查人员、总行审批人员），跳转前校验，本系统后端在查看与下载时再次校验授权上下文；未授权访问、拼接 URL、越权下载一律拒绝并记录安全审计日志。菜单入口仅用于查看已有任务，不创建新任务。

5.2 AI 生成与编辑

• 报告状态为排队中/生成中时：编辑器只读、保存禁用，底部悬浮提示"报告生成中/排队中"，仅允许取消生成；通过 SSE 流式接收每个问题的 AI 回答并实时渲染（问题标签按状态显示加载中/已回答/无法回答图标）。
• 问题驱动：模板中以问题标签标记 AI 或人工填写位置；多级标题模板下每个二至四级标题正文对应独立内容单元、引用列表和修改状态。
• AI 改写：选中文本触发悬浮对话框（可拖拽）：原文展示、对话气泡（用户蓝/AI 灰）、AI 回复附接受/复制/重试操作、“参考对应调查报告"勾选（注入上下文，适合重新分析但较慢）、改写提示词回车发送。改写不沿用旧引用，须重新证据匹配与校验。
• 人工修改：保留未删除的引用标记并清理已删除引用，节点状态更新为"AI 已人工修改”；溯源面板提示引用只对应保留标记。
• 退出自动保存：返回或关闭标签页时自动保存编辑器内容。

5.3 溯源与修改记录

• 报告溯源：溯源点导航（翻页/单切换箭头 + 圆点列表）；内容区按文件类型自动选择预览器（PDF 分页高亮/图片/Excel/Docx/文本）；全屏预览（Esc 退出）附 RAG 召回结果卡片列表（文件名、摘要、命中分数，点击切换溯源点）。区分"原始材料"与"系统能力结果"（制度、政策、行业检查结果经虚拟来源文档复用预览与高亮）。引用列表按答案文本中的引用标记过滤展示。
• 修改记录：当前问题答案的历史版本列表（版本号"第 X 版"、当前标记、操作人、时间）；展开左右对比（改前灰/改后橙），支持还原至历史版本（二次确认）；按版本号倒序。

5.4 运行情况与反馈页签

运行详情基础信息（任务编号、标题、功能、业务功能、客户号、业务流水号、状态、结果、提交/完成时间）+ 运行情况（小查展示子模块结果组件）+ 结果评价（小查按子模块分项，其他整任务评价）。

5.5 异常处理

SSE 中断→保留已渲染内容并提供重新生成入口，启动状态轮询兜底；SSE 超时→拉取最新答案回填并清理连接；停止生成失败→保留连接可重试；模板获取失败→编辑器不渲染；保存/下载失败→错误提示不丢内容；ESB 调用失败→对应问题区域保持加载中/空态；影像平台拉取失败→溯源面板该来源不可预览并提供重试；权限校验失败→拒绝并记录审计。

6. 本章关联文档

• 自动触发链路：02 业务架构与端到端流程 §2.1
• 权限与页面跳转交互：09 对外交互方案 场景 3
• 下一章：07 智能审核（小核）

1.3.7 - 智能审核（小核）

1. 总体说明

智能审核（小核）提供"目录同步与确认、资料自动分类配置、审核规则配置、业务材料上传、业务材料审查、小核配置"六个三级功能，覆盖放款/出账环节的材料审核全链路。

• 子模块：对公含放款基本审核、出账基本审核、贷前落实条件审核、借款合同审核、贸易合同审核五个；个人条线不含出账基本审核，其余四个同名复用。
• 发起边界：放款审核、出账审核由授信执行中心在客户经理提交对应业务后自动发起（唯一发起点），本系统不提供人工新增/重新发起按钮；非放款审核场景可经悬浮按钮按配置发起"智能审核"。
• 材料+制度双审核：“放款智能审核接口"同时受理材料智能审核与制度风险分析：制度检查范围按智能制度检查配置的节点制度映射确定——放款申请（loanReleaseApply）与出账支付管理（paymentManage）分别映射各自制度集合，个人条线复用同名个人制度映射；返回材料风险、制度风险及合并风险等级（取高）。

全屏打开 ↗

2. 目录同步与确认

从信贷系统同步审查目录（材料目录树），在系统内进行版本化管理、影响确认与受控生效。同步生成的候选目录不会自动替换当前生效目录。目录节点携带材料要求属性（适用阶段、主体角色、必传规则、文本形态、份数规则、缺失风险、命名方式、命名模板、有效期、复用策略等），本期仅供配置和确认，上传资料功能暂不消费。

全屏打开 ↗

2.1 业务流程

1. 同步：点击"从信贷系统同步”，后端拉取最新目录并与当前生效目录差异比对，生成候选版本（状态"待确认"）；无差异提示"当前已是最新目录"；同步调用超时（30 秒）或数据校验失败不生成候选并记录日志。同一时间仅允许一个候选版本。
2. 影响确认：候选版本详情"影响确认"页签展示影响清单（影响等级[高/中/低/同步阻断]、变化类型[新增节点/删除节点/节点改名/调整上级/层级结构变化/材料要求变化/适用范围变化/命名规则变化]、节点、变化前后路径、变化说明、规则影响[直接/继承关联数]、确认状态）；支持逐条、按等级批量、勾选批量确认。
3. 失配处理：因节点删除导致规则失配的项，须先在"处理失配"弹窗选择处理方式——重新绑定（选择目标节点，必填）/ 停用并保留 / 删除规则；处理方案在目录生效时批量应用。
4. 生效与放弃：全部影响项确认且失配处理完成后候选状态变"待生效"，点击"生效候选目录"经二次确认后置为生效，原生效目录转为历史版本；可"放弃候选"丢弃候选及全部确认记录。
5. 回退：对历史版本点击"生成回退候选"，基于该历史版本快照生成新候选（待确认），需重新完成影响确认后生效。

2.2 界面要点

• 目录版本列表：平台版本、信贷源版本、状态（生效中/待确认/待生效/历史版本彩色标签）、节点数、同步/生效时间、操作人、说明；候选状态显示"确认"，历史版本额外显示"生成回退候选"（存在待处理候选时禁用）。
• 目录展示页签：左树（300px，搜索过滤、默认展开）+ 右侧节点材料要求详情（描述列表；非生效目录顶部黄色警告）。
• 目录变化详情弹窗（680px）：节点、影响等级、变化说明、变化前/后路径、关联规则、上传影响、确认记录（确认人+时间或"尚未确认"）。

3. 资料自动分类配置

管理上传材料的自动分类规则与全局分类参数。规则与目录版本"绑定+继承"：规则绑定到目录节点，作用范围为"仅当前节点"或"当前节点及全部后代"；最终生效提示词按目录层级从上到下拼接全局分类业务提示词 + 各层级适用节点提示词 + 系统固定输出协议，调用大模型完成自动分类。节点不在当前生效目录时规则状态为"待目录匹配“且不执行。

• 分类规则配置页签：平铺模式（表格：配置名称、绑定目录全路径、作用范围、节点补充提示词、当前状态[启用且可执行/待目录匹配/已停用]、更新人/时间；筛选：关键词、目录匹配状态、启用状态）/ 目录模式（左树 + 右侧节点规则列表，区分"本节点配置/继承自[上级]"；底部"最终生效提示词预览"按全局（蓝底）→各层级（标注来源）→固定协议（灰底）展示，仅显示启用规则；失配规则归入虚拟"失配规则"分组）。规则保存后立即生效。
• 全局配置页签：材料不符判断开关（默认启用；关闭后仍自动分类但不判断人工调整后的材料是否与节点不符）、分类业务提示词（≤2000 字符）、固定输出协议（系统固化不可编辑）、聚合判断规则（只读：同一节点多份材料时，至少一份符合则整个节点不提示材料不符）。“保存配置"需确认并立即生效。

4. 审核规则配置

管理智能审核所依据的审核规则、材料提取要素、业务数据项及全局提示词，是材料上传预审与审查环节的规则来源。规则按目录节点触发，可组合材料提取字段与业务系统结构化数据，通过可视化条件或大模型提示词完成风险判断。规则保存后立即生效；“目录匹配状态"计算规则同上。

4.1 页签与关键概念

• 规则配置（平铺/目录两种视图）：规则属性含规则编号/名称、绑定目录、作用范围、业务场景（放款基本审核/出账基本审核/贷前落实条件审核/借款合同审核/贸易合同审核，多选）、判断模式、执行粒度（当前业务/每个相关主体/每份材料）、命中风险（高/中/低/疑似）、使用端（仅审查端/上传及审查）、配置方式、启用状态、目录匹配状态。
• 五种判断模式：① 图片直接由大模型判断；② 图片提取要素后由规则判断；③ 图片提取要素后由大模型复核；④ 使用已有解析结果由大模型判断；⑤ 已有解析结果先规则初判再由大模型处理例外。模式决定是否需要配置结构化判断条件及大模型提示词。
• 提取要素：独立可复用配置单元（要素编号唯一、名称、绑定节点、数据类型[文本/金额/日期/比例/布尔/枚举]、提取要求、启用开关），同一节点的提取要素可被多条规则共同引用；被规则引用的要素删除需确认。
• 业务数据项（只读）：后端统一注册，来源包括材料提取字段、信贷系统、审批批复、外部查询（经 EDS 获取企查查数据，用于个贷放款核对交易对手经营范围与贷款用途）及系统变量；只暴露业务名称与含义，不暴露接口地址与数据库结构。
• 全局设置：审核通用提示词（≤3000 字符）、风险输出约束（≤1500 字符）、溯源提示词（≤2000 字符；材料证据定位到文件和页码，结构化数据记录数据项、当次取值、来源系统和获取时间，本期不含矩形坐标）、固定输出协议（固化）。单独"保存全局设置并生效”；进行中的预审任务沿用发起时快照。

4.2 规则编辑器（四步）

1. 基本信息与执行范围：规则编号（≤50，唯一）、规则名称（≤100）、绑定目录（必填，可搜索）、作用范围、适用场景（多选）、执行粒度、命中风险、判断模式、启用开关、“仅审查端"开关（开启后客户经理端不返回该规则名称/提示词/数量和结果，仅提交或审查阶段执行）。
2. 规则输入：输入项表格（输入别名必填、业务数据项必填[显示"业务名称（来源系统）"]、主体角色[借款人/保证人/抵押人/出质人/交易对手，可空]、必需开关、缺失风险）。
3. 判断逻辑：按判断模式动态展示——无需规则条件时提示直接填写提示词；需要时选择配置方式：可视化规则（条件关系[满足全部/任一] + 条件表格：左侧输入、操作符[按数据类型过滤：文本=等于/不等于/包含/不包含；金额与比例=数值比较；日期=比较及"在有效期内”；布尔与枚举=等于/不等于]、比较对象[固定值/其他输入项/系统变量]、比较值）或预置复杂规则（模板：抵质押物多材料描述一致性/主从合同核心要素一致性/公司决议合法有效性/押品保险覆盖有效性 + 模板业务参数）。
4. 模型提示词与制度依据：大模型提示词（≤2500 字符，需提示词的模式必填）、制度依据、适用日期、条款说明。

保存前校验：别名与数据项非空、条件完整或模板已选、提示词非空（按模式）；启用但绑定节点不在生效目录时确认"待目录匹配”。复制规则生成新编号、名称追加”-副本"。

5. 业务材料上传

授信执行中心完整放款和出账流程中的资料上传子功能（放款资料上传/出账资料上传两场景）。文件实体存影像平台，本系统仅保存元数据、分类信息和任务状态；完整放款、出账业务功能及最终业务提交均由授信执行中心提供。“新增任务/一键预审/提交"仅处理资料上传任务，不代表创建、提交或审批放款/出账业务，也不是审核任务的人工发起入口。

5.1 关键机制

5.2 界面

• 任务列表：关键词查询；列含任务名称、客户名称、业务流水号、上传场景、目录版本、完整度（进度条）、风险（有风险红色数字/无风险绿色 0）、状态（草稿灰/分析中橙/已完成分析与审核完成绿）、创建时间；草稿显示"上传/查看/删除"，其他仅"查看"。
• 材料工作台：顶部标题栏（返回、任务信息、目录版本/完整度/风险标签、一键预审、下载材料、提交）；预审结果面板（进行中蓝色含阶段与进度；完成绿色含统计与"沿用"说明；失效橙色提示重新发起）；中部左目录树（虚拟根目录 + “未分类”，节点状态齐/缺/处理中/未分类/险）右材料面板（复用历史材料、上传到当前节点[含子节点禁用]）；文件卡片（缩略图/后缀、材料名称、原始文件信息、风险等级与项数、分类状态、改名/移动目录/失效/删除）；底部上传队列可折叠。预审预计 1–3 分钟。

6. 业务材料审查

放款审查岗和出账审查岗查看由授信执行中心自动发起的审核任务，以问题优先方式复核智能分析结果及证据。审查模式只读：不显示上传、改名、移动、删除、预审和提交操作。

6.1 审查工作台

• 顶部：任务信息、目录版本/完整度/风险标签、下载材料；任务进入分析中/已完成分析后显示"材料审核 N / 制度审核 M“分段切换（默认材料审核；任一维度风险为 0 时按钮置灰仍可切换查看空态；下载与评价常驻，评价针对材料智能审核任务整体）。
• 制度审核维度：整面板复用"小查"样式（风险概览统计 + 制度合规检查模块 + 风险条目制度条文/业务证据双重溯源）；制度风险分析中显示"制度风险分析中，请稍后刷新查看结果”；0 条显示"审核完成，未发现制度风险"。
• 问题审查视图（默认）：问题队列（风险标签、规则名称、结论摘要、主证据来源；按高/中/疑似/材料不符/低过滤，字典加载）+ 证据原文栏（PDF 原生页码定位、图片预览、全屏；多证据按钮切换；证据文件不可用时展示"证据文件当前不可用"及最后已知定位）+ 问题详情栏（审核结论、比对数据、判断依据、规则详情）；三栏可折叠，“专注证据/恢复三栏"切换。
• 全部材料视图：目录树 + 材料只读预览 + 风险面板；风险项可"进入问题审查并定位证据”；无风险任务显示"未发现问题"并可查看全部材料。失效文件置灰展示"已失效"标签，不作为问题与风险依据。
• 证据契约：材料证据（证据编号、文件编号、文件名、页码、原文或提取值、主证据标识）+ 结构化数据证据（数据项名称、当次值、来源系统、获取时间）；同一风险可关联多份。旧记录单一定位信息自动适配为单条材料证据。
• 结果来源约束：正式审核可复用未变化的材料解析结果，但必须按当前审核场景、业务数据和生效规则重新确定最终结论；不得直接将上传环节预审结果作为正式审核结论。

7. 小核配置

管理小核子模块启停与"子模块 × 末级功能"绑定（与风险分析配置结构一致）。

• 默认绑定：放款基本审核→放款申请；出账基本审核→支付管理；贷前落实条件审核→贷前条件审查；借款合同审核→借款合同；贸易合同审核→支付用途审查。个人条线同名子模块按各自末级功能复用上述绑定；不绑定任何末级功能时对所有功能生效。
• 悬浮按钮进入业务材料上传/审查页面按"角色功能路由"配置的目标与进入方式执行，默认"仅查看"（只读，不提供上传、新增任务、删除或重新分析）。

8. 本章关联文档

• 放款智能审核接口契约：09 对外交互方案 §六/§七
• 目录版本状态机：图表 life-directory-version.html（全屏 ↗）
• 上一章：06 审查报告 ｜ 下一章：08 评价分析

1.3.8 - 评价分析

评价分析模块构成"用户评价 → 明细沉淀 → 周期量化分析 → 提醒回收 → 参数配置“的闭环，覆盖小查、小审、小核、小问及审查报告生成的评价数据。

1. 评价查询

面向评价分析管理员与业务用户，对用户在各智能体会话中提交的逐条评价记录做明细查询与详情查看。

• 查询条件：功能（小查/小审/小核/小问）、评价等级、评分范围（0–100 闭区间）、反馈原因、评价人（精确匹配）、评价机构（机构树搜索选择器单选，按名称精确匹配）、评价时间区间；按评价时间倒序分页。
• 列表列：评价时间、评价人、评价机构、功能、评价对象、评分、等级（彩色标签，颜色取自评价等级配置）。
• 评价详情：基础信息（评价时间、评价人、机构、功能、评价对象、任务编号、评分徽章、等级标签）+ 反馈区（反馈原因标签列表[无则"未选择”]、补充说明[无则"无"]、上传截图缩略图网格可预览大图）。
• 返回列表保留筛选与分页位置。

2. 效果评价分析

面向评价分析管理员，对信贷智能体服务效果做周期性量化分析。

• 主流程：分析列表（新增/查看/PDF 下载）→ 新增分析（配置统计周期、功能维度[知识库/审查意见/智能问答/风险识别，可多选]、功能类型[全部/试用/非试用]、评分范围、评价最多用户数 1–50 默认 10）→ 系统聚合生成报告 → 详情查看 → PDF 预览与下载。
• 执行机制：创建接口同步落库（状态=已提交）立即返回；异步聚合（按统计周期+功能维度+功能类型+评分范围过滤 → 聚合核心指标、等级分布、反馈原因统计、四维分组统计 → 落库 → 生成 PDF → 状态"已完成"）。状态非实时推送，重新拉取列表/详情时更新。
• 聚合口径：评价参与率 = 产生评价的对话数 ÷ 服务对话数 ×100%；评分平均值 = Σ评分 ÷ 评价数；评分中位数 = 升序取中位（偶数取中间两数均值）；评价数 = 满足筛选条件的评价记录计数。
• 分析详情：核心指标概览（服务对话数、评价参与率、评分平均值/中位数）+ 图形化分析（评价等级分布环形图[超出预期/优秀/合格/不及格]、反馈原因词云[没说清楚/回答错误/溯源错误/答非所问/异常报错/其他]）+ 分维度评价分析（用户/角色/机构/功能四维分组表：参与率/平均分/中位数/评价数）。
• PDF 报告：仅"已完成"可下载；下载接口后端再次校验任务状态与权限。

3. 评价提醒配置

管理未评价 AI 结果批量提醒参数；保存即时生效，次日批量程序按新配置执行。

4. 未评价提醒

批量后台程序，无前端界面。每日按配置时间执行一次：

1. 读取评价提醒配置（各功能启停、最大提醒天数）。
2. 任务式 AI 功能：扫描已完成且评价状态"未评价"、完成时间在最大提醒天数（含）以内的任务；对话式（小问）：扫描配置天数内有对话的会话，会话中存在任一未评价 AI 回答即视为整任务未评价。
3. 将待提醒记录写入提醒文件（用户标识、提醒标题、提醒内容、链接 URL），上传至影像平台约定目录；门户定时轮询获取并处理为门户提醒。
4. 链接规则：任务式→运行列表对应任务详情页（携带任务编号）；对话式→小问对话主页面并定位指定会话（现状简化浮层不支持深链，降级为仅打开对话面板）。
5. 已发送提醒的任务/会话标记"已提醒"避免重复；批量程序记录执行日志（起止时间、发送/跳过/失败条数）；文件生成或上传失败按重试机制处理，不阻塞后续批次。

5. 评价设置

维护评分等级标准与预设反馈原因两项基础配置，保存即时生效。

• 评分等级标准（0–100 须连续覆盖、互不重叠）：每行含最低分/最高分（0–100 整数）、等级名称、编码（同级唯一）、颜色（默认蓝色）、弹出反馈开关（默认开）、必填说明开关（默认关）。保存校验：至少一个等级；编码名称非空；区间合法（最低 ≤ 最高）；编码不重复；按最低分升序后首段最低分为 0、末段最高分为 100、相邻区间无缝衔接（上一段最高分 +1 = 下一段最低分）。
• 预设反馈原因：原因名称、编码（唯一）、启用开关（默认开；关闭后评价录入下拉不展示）。保存校验非空与编码唯一。
• 保存成功后按最低分降序排列等级（高分在前）；接口异常或无数据时回退内置默认配置。

6. 本章关联文档

• 评价录入入口与要素：03 悬浮按钮与任务管理 §3、§4
• 提醒文件经影像平台送达门户：09 对外交互方案 场景 10
• 下一章：09 对外交互方案

1.3.9 - 对外交互方案

门户以微前端形式集成信贷系统与智能信审系统两个平级子应用：智能信审不与门户直接做前端交互，页面级互操作（悬浮按钮读取缓存、页面跳转、iframe 嵌入）均发生在信贷系统与智能信审两个微前端子应用之间；门户与智能信审之间仅存在系统级对接（主数据同步、知识库菜单集成）。外围交互系统：信贷管理系统各业务中心（授信作业中心、授信执行中心、客户中心等）、门户、调查报告系统（智能尽调系统）、企业知识平台、外部数据管理平台（EDS）、影像平台。

全屏打开 ↗

1. 六种交互模式

缓存字段（场景 2/4 共用）：业务流水号、合同号（合同环节必须提供）、客户号、批复编号。

2. 交互场景总览（12 个）

场景要点

• 场景 1（业务发起与调查报告获取）：调查报告正式版保存后自动 PDF 入影像并登记索引（不感知信贷提交状态）；授信业务提交成功后授信作业中心调用统一发起接口（同时发起小查与审查意见生成，不再传输调查报告文件）；本系统查询文件索引并拉取 PDF 本地暂存，先统一执行一次财务分析与制度分析（结果供两任务复用），再分别创建任务。通知式查询替代以往准实时轮询，仅业务提交后查询一次。数据支撑：财务要素←客户中心；企查查←EDS；行业均值与政策法规←企业知识平台 ETL（T+1）。
• 场景 2（审查岗查看小查）：审查审批页面写缓存点亮"小查"；小查已随业务提交自动执行，此时点击属重复发起，按运行管理配置处理（默认允许，覆盖原任务；原任务执行中自动终止）。
• 场景 3（审查岗出具审查意见）：初稿由场景 1 自动生成；查看/编辑经 URL 的 mode 参数区分（同一接口）；授信作业中心跳转前完成权限校验，本系统后端查看与下载时再次校验，未授权/拼接 URL/越权下载拒绝并记审计日志。生成过程中经"客户关系查询接口"获取数据，自行生成集团关系图谱图片放入报告。
• 场景 4（类案对比）：任务期间经"业务基本信息查询接口"取当前业务与关键要素快照；经"五级分类数据查询接口"实时获取历史案例贷后五级分类；查看完整贷款信息时页面嵌入授信作业中心贷款信息查询页面（参数含 mode=current/case、业务流水号、客户号、业务名称、客户名称、客户类型，类似案例另带案例标识）。
• 场景 5（终审与业务资料入库）：通过→审查意见+批复入库（打标含审批通过时间）；拒绝→仅审查意见（打标不含通过时间）；再议→不通知不入库。同一材料更新再次通知并覆盖旧有效版本。统一打标 11 字段：业务流水号、企业性质、企业规模、经营年限、所属行业、贷款用途、产品（多值/无产品标"授信"）、主担保类型、所属分行、业务审批通过时间（仅通过）、审批结论。
• 场景 6/8（资料上传）：目录维护并列两种方式（方式一：信贷修改联动差异确认同时生效；方式二〔现行〕：目录同步接口获取→候选版本→逐条确认→激活，支持回滚）；删除控制按节点/文件粒度传入不可删除标记；复用历史材料物理复制两份；映射回传含失效状态；上传任务提交不触发审核。
• 场景 7/9（出账/放款审核）：以授信执行中心提交事件为唯一发起点；执行期间经"放款/出账要素查询接口"取利率、受托支付、还款方式等，合同审核经"合同信息查询接口"取合同信息；个贷放款审核另经 EDS 取交易对手企查查信息（重点关注经营范围与贷款用途相符性）；打回重提覆盖本场景结果，出账与放款审核相互独立。
• 场景 10（未评价提醒）：每日批量生成提醒文件上传影像约定目录；门户设定时间后轮询获取处理为门户提醒；仅对完成时间在最大提醒天数（默认 7）内的未评价任务生成。
• 场景 11（主数据同步）：实时（ESB 变更通知）+ 批量（企业知识平台表级同步）双通道；菜单由门户配置，本系统提供前端文件。

3. 接口清单（38 项）

业务层面接口清单。实际设计可复用/合并/拆分接口，数量、名称与出入参以接口设计文档为准。

注：原序号 14"审查意见下载接口"已取消——报告下载改为在审查意见查看/编辑页面内通过"报告下载"按钮完成；序号 36 上传文件失效接口、37 统一发起接口、38 放款智能审核接口（材料+制度双结果回执）为新增。

4. 接口必要字段（必传最小集合）

5. 放款智能审核接口契约（材料 + 制度双审核）

客户经理提交放款申请或出账申请后，授信执行中心调用本接口发起统一审核回执。本系统按业务流水号幂等创建或更新小核任务，执行材料智能审核的同时调用制度分析模块执行制度风险分析，一次性返回双结果。

5.1 触发节点映射

5.2 请求字段（授信执行中心 → 本系统）

5.3 响应字段（本系统 → 授信执行中心）

5.4 页面双审核切换约定

• 任务进入分析中/已完成分析后，顶部显示"材料审核 N / 制度审核 M"分段按钮，默认材料审核；任一维度 0 条时按钮置灰仍可点击查看空态；“下载材料/评价"常驻。
• 制度审核面板整面板复用小查样式；零风险显示"审核完成，未发现制度风险”。

6. 影像平台角色汇总

7. 本章关联文档

• 各场景对应的业务功能：04 风险检查（小查）、05 类案对比（小审）、06 审查报告、07 智能审核（小核）、08 评价分析
• 交互全景图：arch-interaction.html（全屏 ↗）

1.3.10 - 10 财务风险分析

依据《财务风险分析系统需求文档（1028）》整理。本版规则库由 969 条增至 972 条（2026-10-23 评审会新增 U-0970～U-0972 三条），并新增独立上传使用方式与财报上传与解析模块。

一、系统定位与两种使用方式

财报风险分析系统按 972 条规则逐条核查企业财报，给出风险评级与授信建议；每条结论都能追溯到实测数值、阈值档位与规则编号。系统支持两种使用方式：

输入与输出：

二、功能结构

2.1 财报上传与解析（新增）

任务与状态：一个任务对应一家企业、含一份或多份财报；任务名称不得与已有任务重名。任务状态由财报状态自动推出（从上往下取第一条满足的）：待上传 → 解析中 → 解析失败 n → 待审核 → 分析中 → 已完成。财报状态：排队中、解析中、解析成功、解析失败、已审核。

四个页面整页跳转、与风险分析页彻底分开：

• 任务列表页：「新建任务」必选适用对象（四选一、无默认值，选中即提示参与判定的规则条数——全部对公 724／上市公司 880／集团 796／上市集团 972），选填实控人、董事长、总经理出生年份（供 U-0972 使用；上市公司以年报「董事和高级管理人员情况」所列年龄为准，录入值仅作补充；只录年份不录身份证号）；仅创建人可删除，已生成分析的任务删除时确认框写明财报、解析结果、风险分析与人工补充记录一并删除。
• 财报上传页：「财报文件／数据明细」两个视图；添加财报时选报表类型（三张主表、年报含附注——决定规则按哪一档数据运行）；试算情况按口径分格（绿＝勾稽平衡且科目全映射、红＝有不平或未映射、灰＝文件中没有这张表）；数据明细按年份并排显示已审核数据，支持六张报表切换、变动对比（A 较 B：变动额、变动率，减少标红）、单位切换（元/万元/亿元）与 CSV 导出。
• 解析结果页：左边原文、右边科目表，分隔条 25%–75% 可拖动；表格类型纠正——原文上每张识别出的表格可跨页勾选多张后统改类型（合并三表/单体三表/未匹配），改后按新模版重新映射并重算勾稽；模版科目下拉带搜索，模版确实没有的科目用**本科目「＋/− 归属合计项」**并入勾稽式，并可反馈到模版或仅本报表生效；试算不平/校验通过面板点条即定位到科目与原文；基础信息（报表口径、报告期、金额单位、币种、是否经审计、审计意见类型）全部下拉选择不许手填，已审计必须选审计意见类型才能审核完成（供 U-0717 等审计类规则直接读取）；未匹配表格（如所有者权益变动表）只做基础解析、不映射模版科目。
• 风险分析页在新标签页打开。

勾稽校验：每张主表按模版科目分组自动生成勾稽式（不需逐家配置），容差 0.5；「其中」项不参与求和。跨期校验：本期财报的上年数＝上一期财报的本年数（比对资产总计、负债合计、所有者权益合计、营业收入、净利润、期末现金余额），追溯调整以本期重述数为准。

审核完成与解锁重审：「审核完成」作用于整个任务，前置条件为全部解析完成、每张主表无试算不平且无未映射科目，不满足时弹窗逐条列出「报表：试算不平 n、未映射 n」；完成后数据锁定、状态「分析中」，系统随即运行规则判定、评分与结论文案（第一次自动运行）。「解锁重审」只在财报上传页，确认后回到「待审核」可改数据、增删财报；重新审核完成后按新数据重生成，风险分析页已做的人工补充保留。

解析技术路径：默认走流水线（取文字层 → 扫描页 OCR → 版面分析 → 表格结构识别 → 字段匹配），数字逐字取自原文、可定位到页码坐标、结果确定、普通服务器可运行；对解析不准的页可点**「增强识别本页」**改用视觉大模型（VLM，适应扫描件、复杂版面与跨页表，需显卡算力、只在用户发起时用）。两条路径的结果都须通过勾稽与跨期一致校验，不过的字段进人工补录、不自动填数。留痕：每个数值记录解析路径、页码坐标、置信度，人工修改记录前后值与修改人；审核完成、解锁重审与风险分析版本一一对应。

2.2 总览页

评审进入后的第一屏，“不看明细也能下结论”，自上而下十个版块：

1. 评级横幅与核心结论：综合评级（极高/高/中/低）取三条轴的中间档；触发重点关注事项时结论直接覆盖为「不建议准入」并写明触发的闸号。数据不足按档处理：严重档（占比 ≥ 50% 或必查规则 ≥ 30% 数据不足）评级位置换成「无法评级（数据不足）」、授信建议「待补充资料」；中等档（20%–50%）保留评级加橙色提示并附链接直达规则库筛出数据不足规则；两条提示并存时否决在上。
2. 核心结论正文：三到五段、每段一个主题，大模型生成；生成前或失败时系统先写兜底正文（前 5 张卡各一句「议题名：风险指向原句」＋评级与行动建议），成功后整段覆盖。
3. 重大舆情与外部核查：结论区内一段话，明细在舆情核查页。
4. 授信建议表：六维（新增授信、存量授信、担保结构、财务指标约束、资金监控、治理与信息质量）档位由系统算出、文案由模型生成且不得与档位相反。取档规则：新增授信跟随综合评级（任一重点关注事项触发即「不建议」，否则极高「不建议」、高「审慎准入」、中低「可准入」）；其余五维按规则计数——所看域内任一 P0 且重点关注取红档，否则任一重点关注（任何优先级）或任一 P0 且关注取黄档，其余绿档；十个风险域被后五维全覆盖、不重不漏，档位旁显示「依据 N 条规则」可展开编号。
5. 放款前必须落实的核查清单：模型按风险议题生成、通常五到十条、不允许为空；兜底清单取前 10 张卡的处置动作原句去重，0 张卡时固定写「按常规贷前流程核查」一条，数据不足中等或严重时再加补录提示。
6. 核心指标概览：公司特定指标（重点关注且卡片优先级 P0 的议题卡按加权分取前 3 张）＋ 15 张四类核心指标（偿债/营运/盈利/现金流，含流动比率、资产负债率、现金转换周期、净现比、自由现金流等）＋ 大额科目（占总资产 20% 以上逐项列示，无超标改列最大三项）。每张卡数值、对照基准、好坏判断三样齐全；颜色只按警戒线定，基准只用来写「比行业均值高/低多少」；15 张中 7 张可用行业均值（ALR/ROL/365÷TAR/365÷ITR/GRP/NPR/ROE），其余只比上年；周转异常快（应收 < 5 天、存货 < 7 天、CCC < −60 天）不判红黄、改中性色提示确认业务模式。
7. 主营业务概览：分产品（或分行业）与分地区近三期收入、占比、毛利率；只由聚合组一方写入，无数据写「未取得」不留空。
8. 各域结论一览：十行——域名、判定标签与触发条数、一句话本域结论（即维度页本域结论第一行），点域名跳转。
9. 重点关注项：八条一票否决事项的状态表。
10. 风险项清单：一级风险（红，卡片等级为重点关注）与二级风险（橙，关注）两级；每个议题一张卡：规则编号（可跳转）、议题名（系统生成）、结论句、判读三段、依据规则列表；按卡片计数，与规则库「重点关注/关注」条数不相等是正常的。

2.3 风险域维度页（十个）

左侧栏按四个阶段分组：

每页含域头（规则数、必查项数、各判定计数）、本域结论两行、图表区、触发规则明细表。本域结论两行由大模型生成：第一行总判断（≤ 30 字、不带数字、先肯定再转折，必须覆盖本域最严重议题）；第二行支撑数字（2–4 个指标、≤ 120 字，逐字出现在实测依据里、不允许计算改写）。三种情况不调用大模型直接写固定文案且不显示第二行：全部不适用、未触发、可判定规则全部数据不足。

2.4 舆情核查、阅读指引与规则库

舆情核查页：舆情（随时发生、无人审计）与财报（一年一期、经审计、可勾稽）是两种证据，单独成页、不合并计数——舆情记录时间线（级别与正负面分两栏）＋ 外部信息族六条必查规则。

阅读指引页：134 条不直接产生判定的规则分三类——阅读路径 109、口径护栏 20、证据效力 5。其中只有 74 条 NOSCORE 阅读路径移出规则清单编成 109 步动线（另 35 条带阈值、既在动线上也照常判定打分，仍保留在清单里）；口径护栏与证据效力留在清单内，挂到指标出现的地方与上下文提示中。

规则库页：清单展示 898 条（972 − 74 条不判定的阅读路径），支持按域、类型、判定状态、关键词筛选，每页 150 行；其中 861 条参与判定与打分（每条一个状态：重点关注/关注/通过/数据不足/不适用/不可执行），另 37 条 NOSCORE 只展示不打分（口径护栏 16、证据效力 5、重点关注事项 7、其他 9）。972 ＝ 898 ＋ 74，898 ＝ 861 ＋ 37。每条展开显示 17 个字段全部内容并提供人工改判入口（改判、填实测值与核查说明，留痕）；页面顶部「大模型重算」按钮在人工判定后触发结论文案重写。

2.5 场景筛选

同一份规则库，不同评审环节看的条目不同。场景只过滤显示，不重跑判定、不改评级；人工改判在任何场景下做都即时改变全量评级。顶部场景条通栏吸顶（评级横幅之上）、可收起，九个按钮按审批流程排序：

每条规则有主场景（必填）与至多一个次场景；S6 贷后监控只出现在次场景，S8 舞弊识别规则以审批环节为次场景（如 67 条落到 S2）；S7 只有 U-0967、U-0968 两条，并入 S1 显示。场景字典与规则归属随规则库版本固化。各页面在场景下的行为有明确定义：评级、重点关注项、授信建议、核心指标、主营概览、核心结论始终按全量规则；风险项清单只列命中卡片但严重度、优先级与排序仍按全量计（不因过滤降级）；当前域 0 条时自动跳到第一个有命中的域。

三、整体逻辑：七个环节

数据层归集 → 规则判定 → 议题聚合 → 评分分档 → 图表与判读生成 → 结论文案生成 → 质量检查，任何一环的产物都可单独验证。

全屏打开 ↗

3.1 数据层

所有数值集中在七个命名空间，规则只能从这里取数、不允许写死数字：年报科目原值、派生指标（现算，全系统统一口径，如现金转换周期恒为"应收天数＋存货天数−应付天数"）、分季度数据（识别年末利润塌陷）、母公司报表科目（母子背离核对）、外部工商舆情（可缺，缺时显示未接入）、行业均值（固定取数）。

3.2 规则库结构

每条规则 17 个字段，核心九个：规则编号（全库唯一可点击）、所属风险域、检查项、计算口径（须可复算）、阈值（黄档/红档两段）、判定、实测依据（必须对得上口径）、优先级（P0 214 / P1 594 / P2 164）、实测标题。规则分布：按风险域 C 257 · J 198 · A 122 · I 95 · E 65 · K 55 · L 51 · F 50 · B 49 · H 30；按阈值形态比率 583 · 恒等式 151 · 不计分 111 · 状态 111 · 计数 16。

2026-10-23 评审新增三条（969 → 972，均为 P1、适用全部对公客户、参与判定打分）：U-0970 长期资产投入与融资期限匹配（短贷长用，B 域 F15，短贷长用比例 > 20% 关注、> 50% 重点关注）；U-0971 匡算应回款与实收现金差异（K 域 F20，差异率 > 10% 关注、> 20% 重点关注）；U-0972 实控人及核心管理层年龄（J 域 F40——董事长与总经理同时 ≥ 60 岁判关注，任一人 ≥ 70 岁判重点关注，边界归严；同一人兼任两职按该人计；实控人为法人或国资时只判董事长与总经理；判读提示人工核实接班安排但不作判定条件；2026-10-28 按评审意见调整）。

3.3 四层筛选

972 条不对每家公司全跑：

1. 适用对象：全部对公 724 / 上市公司 156 / 集团客户 72 / 上市集团 20，可叠加（上市公司 880、集团客户 796、上市集团 972）。程序不自行推测：独立上传由任务必选，对接信贷由跳转参数「是否上市」「是否集团」提供；参数缺失时先按 724 条跑，其余规则写数据不足、原因「客户类型未知」。
2. 数据可得性（累计）：仅定期报告 279 条（P0 覆盖 32%）→ ＋年报附注 770（90%）→ ＋外部数据 962（99%）→ ＋现场尽调 972（100%）；与适用对象交叉成矩阵（如普通对公仅定期报告 223/51，上市集团全量 972/214）。
3. 业务前置：19 类业务（并购商誉、制造业存货、境外业务等）不开展即标「不适用」，不计分母、不占清单，共 198 条。
4. 规则类型：量化检查 481（全自动）、勾稽校验 166（全自动）、定性判断 136（模型初判＋人工复核，报表外证据必须人工）、归因分解 26（全自动）、认知原则 41 与阅读方法 122（其中 NOSCORE 的 27/84 条移出执行队列做成检查清单/阅读引导，带阈值的照常判定）。是否参与打分只看判定形态：NOSCORE 111 条不打分，其余 861 条参与判定与打分。

阈值五形态：RATIO 连续比率分档、IDENT 勾稽等式超容差即异常、STATE 条件成立与否、COUNT 发生次数/连续期数、NOSCORE 不打分。

3.4 判定引擎与容差

阈值引擎用受限表达式语言描述规则——只允许调用白名单函数，不能执行任意代码。容差双口径：恒等式类用 1% 容差；近似勾稽关系用偏离度与跳变双阈值——偏离 10pp 判关注、20pp 判重点关注，相邻两期跳变 15pp/30pp 同理；只有两期数据的公司只判偏离不判跳变。

判定结果的完整性：结果须包含该客户、该套材料下应跑的每一条规则（未触发的行也要在内，问题密度与「数据不足有几条」都要看）；每行至少有规则编号、状态、实测值、实测标题、实测依据，关注/重点关注还要写越线方向（由判定引擎按当前实测值与阈值比较写回，比较不出记「无方向」，议题名第三层直接使用）。完整性校验：写回的编号集合须与规则库版本完全一致，缺一条、多一条都不收——分析状态记「生成失败」、自动重试一次、仍失败即停止不展示任何评级。NOSCORE 111 条状态一律写「不适用」、原因「不打分规则」（不得写成数据不足，否则虚增待补录）；定性判断暂不能初判的写数据不足、原因「定性项待人工判定」；创建分析实例时校验规则库版本须「已发布」且条数与登记一致，不得以空规则集输出「无风险」。

3.5 议题聚合

按 43 个事实域聚合（有规则的事实域 42 个；F12 法定公积计提挂 0 条规则不生成卡不出现在任何页面；事实域只用于合并议题，与十个风险域不是一回事）。同域触发规则合并为一个议题；卡片优先级取组内状态等于卡片等级的规则中的最高优先级（不能取全组最高，防止 P1 重判从 P0 轻判借权重）；未归入事实域的 191 条规则（可打分 141 条）单独成卡、一条一张。主规则决定议题名、所属风险域与判读字段（先取状态等于卡片等级的最高优先级，再取规则条数最多的域，再取编号最小）；跨风险域的卡片只在主规则所属域出现一次，另一域明细注明「已并入议题卡」可跳转；卡片排序依次比较严重程度 → 卡片优先级 → 触发规则条数 → 主规则编号。868 个议题簇只用于选图去重，不用于卡片合并。

3.6 评分与分档

三条相互独立的轴取中间档（任一轴单独拉满升不了档，必须两条同时到位；卡在切点上算高的一档；无触发卡片时问题密度记 0% 算低）：

三轴都按合并后的卡片计、不按规则条数；通过、数据不足、不适用、不可执行不进分子分母。档位与行动建议一一对应：低·可准入，中·可准入·加强监控，高·审慎准入，极高·不建议新增授信；任一重点关注事项触发时行动建议覆盖为「不建议准入」。加权分（重点关注 P0=6/P1=3/P2=1，关注 P0=2/P1=1/P2=0.4）按卡片计一次，不参与定档、不用于排序，只在传给模型时标明轻重、页面不显示。数据不足分档：占比 ≥ 50% 或必查规则中 ≥ 30% 数据不足 → 「无法评级（数据不足）」、授信建议「待补充资料」；20%–50% 照常评级加橙色提示；< 20% 照常。提示与核心结论首句由系统固定写（不交给大模型）；全部规则数据不足时直接显示「无法评级」。

3.7 重点关注事项（八条一票否决）

八条规则写明「直接排除/暂停授信」，不参与打分、单独判定位，触发即覆盖结论为「不建议准入」，优先级高于评分。按可判定程度分三类：自动三条（货币资金五类反常 U-0171 下挂 U-0166~0170、非标准审计意见 U-0717 下挂四条、现金流肖像排除型 U-0593——直接取最新一期经营/投资/筹资净额符号，排除型三种：大出血 −−−、骗吃骗喝 −++、混吃等死 −+−，不读下挂规则状态）；待确认三条（单点异常全面核验 U-0092、重大疑点存疑即排除 U-0773、无法解释的重大突变 U-0867——机器不预判、始终先显示「待人工确认」，评审点「核查后仍无法解释·否决」并填理由才触发，不操作就一直是待确认、任何时候不显示「未触发」）；未接入两条（高风险行业不计提存货跌价 U-0213——需存货跌价多期序列＋行业风险等级两类数据，其本身仍作为普通比率规则照常判定计提率；变相抽回注册资本 U-0406——需其他应收款按对手方拆分明细等三类数据）。「未接入」必须明确显示为「数据未接入」而非「未触发」——后者等于替公司声明查过了没问题；自动闸只许人工推翻（填理由留痕）、不许人工手动落闸；触发后不停止其余规则执行；与数据不足提示同时出现时两条都显示、否决在上。

3.8 图表体系

38 条图表定义覆盖 34 个事实域（四个域各两张），全部程序生成（序列只允许取数据层）。三道出图筛子：排除 NOSCORE 规则（111 条，带阈值的照常参与选图）、排除二值 STATE 判据（111 条）、同一议题簇（868 簇）只画一张且出在触发最多的维度页。图型匹配判据：走势拐点→折线、同向背离→并列柱、总量构成→横条、年内分布→分季柱、与基准距离→折线加基准线。折线图带阈值带（黄区/红区，双向阈值都渲染，阈值线参与纵轴范围）。出图条件＝该事实域有触发规则＋至少一条序列有非空、非零的数（全 0 不出，防缺数填 0 误判）；各公司实际渲染 11~34 张；43 个事实域中 9 个不单独出图（8 个无序列：对外担保、关联方交易、法定公积、人工成本、流动性比率、披露充分性、现金流勾稽、客户与供应商集中；递延所得税挂在税负域下）。行业均值不画进图（只有一年构不成对照），单期对照放总览指标卡。图下判读三行由程序现算（最新读数对比、触发条数与最重规则、通用读法），不调用模型。

3.9 大模型判读与结论文案

分工边界：议题聚合、风险评级、授信分项档位由系统计算（人工判定保存即自动刷新）；核心结论标题/行动建议/正文/总体判断、授信六项文案、放款前核查清单、议题卡判读三段、十个风险域本域结论两行由大模型生成。触发时机：审核完成后第一次自动跑 + 规则库页人工补充后点「大模型重算」。

判读三段：归因（数怎么变成这样，收入类补分产品分地区变动）→ 定性（取规则库风险指向字段）→ 处置（取处置动作字段）。定性与处置两段必须逐字包含对应规则字段的原句，程序按原句是否出现检查，不出现即判生成失败、卡片改用规则原句拼装；归因首句三级回落（实测结论句 → 计算口径展开 → 不写首句）。

议题名三层回落（全部系统生成、评审不修改）：① 大模型本案议题名（≤ 16 字、必须含卡片关键指标数值且逐字出现在实测依据中、结论措辞方向与阈值判定一致、程序校验长度/数值/禁用词/方向词，不过即回落）→ ② 事实域结论名（43 个固定配置表，如 F06「控股股东质押偏高」）→ ③ 主规则检查项＋越线方向词（高于上限补「偏高」、低于下限补「偏低」，无方向只写检查项）。

结论文案五条硬约束（写在提示词里）：只使用给出的事实和数字，不得编造；人工判定优先于系统原判定；授信六维文案必须与系统算好的档位一致；触发重点关注事项时结论必须是不建议准入；只输出固定字段的 JSON 对象。档位措辞约束：综合档与六维各档均规定允许写/禁止写的说法（如「不建议准入」禁写可准入、风险可控；存量授信「压降」禁写可提额），程序逐项检查，判词前一字为「无不未勿非」时不算命中；数据不足的维度只许写「数据不足，待补录后判定」；档位为空时固定写「档位未形成」。正文与核查清单都有系统兜底文案，大模型成功后整段覆盖；报告状态三态——生成中、已完成、生成失败（不展示任何评级）。

四、与信贷系统的集成

统一发起（新）：客户经理在授信作业中心提交业务（业务流水号、提交批次版本、客户及流程上下文）→ 调查报告为完成状态且业务提交成功时，信贷系统调起「小查与审查意见生成统一发起接口」（财务分析与制度解析由同一接口调起）→ 系统经「调查报告文件索引查询接口」向影像平台查询并下载该业务最新版调查报告 → 获取成功后执行财务分析，数据一次取齐（财务要素从客户中心、外部工商与舆情走企查查接口），执行过程中不重复拉取 → 授信作业中心查询完成状态、查看结果。审批退回后重新提交时再次调用统一发起接口，重新拉取最新调查报告覆盖本地暂存版本并重跑，历史执行日志保留用于审计；审批拒绝则业务结束。

评审跳转：审批单财务分析环节放入口，新窗口带参跳转 + 单点登录——bizNo 审批单号、custId 客户标识、opId 操作员、token SSO 票据、ret 返回地址（必填）；period 分析期间（缺省取最新完整年度）、isListed／isGroup 是否上市/集团（决定适用对象）、ctrlBirthYear／chairBirthYear／ceoBirthYear 三项出生年份（信贷系统按关联人身份证号算出后只传年份不传身份证号，供 U-0972）、scene 默认进入场景（可选）。选择跳转而非内嵌——本系统左栏十余个视图，嵌在面板里挪不开。不自建账号体系，权限沿用信贷系统客户可见范围。

数据：三表主体科目自动取自行内已审批的尽调报告；附注明细自动 OCR + 人工补录；外部工商数据接口自动，未接通时如实显示未接入。科目对照：合并三表 56 个科目、附注 13 项、母公司与分季度 6 项须由数据方填科目编码，名称对不上编码的序列不出图；增值税率按公司主营取参数（软件与服务 6%、农产品 9%、多数货物 13%），取不到时收现比只画不含税口径。

结论回写：评审确认后结论摘要（风险卡片）回写审批单财务分析栏（按 bizNo 定位）。

五、行业数据与外部接口

行业均值表（数据方提供）：国标行业小类 × 上市板块共 22 个行业小类，各公司比率简单平均；表内 14 个指标中 5 个可与规则直接比对、驱动 10 条行业比较规则（ITR 存货周转率 3 条、TAR 应收周转率 3 条、GRP 毛利率、ROE、营收/净利润增长率），其中 ITR/TAR 共 5 条「无可比样本时退自身近三年均值（至少三期）」、其余无兜底缺数即数据不足；ROA_TA 口径不明（U-0646、U-0507、U-0542、U-0647 四条保持数据不足）、ICR 仅 2 行有数、ALR/ROL 在规则里只有绝对阈值。行业均值表只用在两处：10 条规则的判定 + 总览指标卡的对照基准；只认同一会计年度、行业归属须写依据、卡上标明「行业均值」。

企查查接口（取与规则清单的交集，7 个 P0 必查）：被执行人详情 IQCC002（U-0968 红档「存在被执行记录」＋涉诉金额÷净资产 > 5%）；失信详情 IQCC001/047（同上）；股权出质 IQCC033＋069（U-0968 实控人股权出质率 > 60%、U-0862、U-0938）；股权冻结 IQCC037＋036（U-0938 司法冻结、U-0968）；行政处罚详情 IQCC008＝038（U-0767 红档处罚性质与整改状态）；破产重整 IQCC007＝053（U-0758 红档已进入破产重整程序）；企业对外投资核查 IQCC039＋081 穿透（U-0962 子公司清单工商核对）。

附录：A 38 张图逐图规格（数据层要求、事实域、序列口径、阈值带、图下判读、关联 P0 规则）；B 科目与字段对照；C 不打分与动线规则清单（74/37/35 条）与 43 个事实域结论名。

1.4 - 财务风险分析系统详细设计与实施方案

依据《财务风险分析系统需求文档（0924）》编制。本页是多智能体财务分析系统 PoC 的详细设计与实施方案——先跑通"数据层归集 → 规则判定 → 议题聚合 → 评分分档 → 图表与判读生成 → 结论文案生成 → 质量检查"七环节全链路，为行内落地探路。需求口径详见10 财务风险分析章。

一、定位与范围

目标：交付一个可运行的 PoC——样本公司数据 + 种子规则集 + 真实 LLM 调用，验证多智能体协作架构、判定可复算性、五条硬约束的可行性。不受行内技术栈约束，但选型与行内《综合智慧信贷 AI 架构方案》同构，验证结论可直接迁移。

PoC 要验证的四个核心命题：

1. 判定、聚合、评分全部由代码计算，每条结论可追溯到实测数值、阈值档位与规则编号；
2. LLM 只承担叙述与判读（判读三段、六项结论文案、核查清单），在五条硬约束下输出稳定 JSON；
3. 人工改判 → 档位即时刷新 →「大模型重算」→ 文案重写，这条核心交互链闭环；
4. 八条一票否决触发时评级被覆盖为「不建议准入」，且不停止其余规则执行。

明确不做（落地阶段再补）：信贷系统 SSO 与带参跳转、结论回写审批单（0924 待对齐点⑨在 PoC 中搁置，改为页面展示 + markdown/JSON 导出）、企查查接口、影像平台 OCR。外部工商舆情在数据层保留命名空间、以 mock 数据注入，未接入时如实显示「未接入」，不得显示为「未触发」。

二、总体架构

四层：评审前端（Vue3）、FastAPI 确定性服务层、LangGraph 多智能体层、数据与模型接入层。核心原则一句话：确定性计算走代码、Agent 不承担口径决策、LLM 只做叙述与判读并受硬约束。

全屏打开 ↗

关键设计决策（逐项经评审确认）：

三、分析流水线与重算回路

七环节中前四环（归集、判定、聚合、评分）与图表数据全部是确定性代码；后三环（判读、结论、质检）由 LLM Agent 承担，编排 Agent 负责调度。人工改判从评审复核泳道回流：改判保存 → 确定性结果即时重算 → 点「大模型重算」→ 判读与文案重写（只重写文案，不改档位）。

全屏打开 ↗

八条否决闸在评分后并行判定：触发即在结果上打覆盖位（结论变为「不建议准入」），但流水线继续走完——评审仍需要完整的判定明细；人工推翻必须填理由并留痕。

四、数据层设计

七个命名空间落为独立取数接口，规则只能从这里取数、不允许写死数字：

两家样本公司（5 年年度序列 + 附注 + 分季度 + 母公司报表 + 舆情 + 所在行业均值）：

• 健康厂：数据干净、少数触发、图少议题少——验证通过路径、低风险分档、「未披露」中性显示；
• 藏雷集团：预埋非标审计意见（一票否决）、存贷双高（F03 存贷利差）、应收与收入剪刀差（F21）、其他应收款长账龄占比（F09）、净现比持续低于 0.5（F38）、四季度利润塌陷（F19）——验证否决覆盖、图多议题多、退回重写路径。

五、规则库与判定引擎

17 字段结构全量落地（编号、风险域、检查项、计算口径、阈值、判定、实测依据、优先级、实测标题等），种子集构成策略：

1. A.01–A.38 图规格反推：38 张图点名的约 150 个 U-XXXX 规则优先编入，阈值直接取图规格（如现金短债比黄 1 / 红 0.5、有息负债率黄 40% / 红 60%、应收剪刀差黄 5pp / 红 20pp）；
2. 勾稽恒等式：资产＝负债＋权益等（IDENT，1% 容差）；近似勾稽如「销售收现 ≈ 营业收入×(1+增值税率)」（偏离 10pp 判关注、20pp 判重点关注；跳变 15pp/30pp；仅两期数据只判偏离）；
3. 八条否决：自动三条（货币资金五类反常、非标审计意见、现金流肖像排除型）+ 待确认三条（立待办）+ 未接入两条（如实显示）；
4. 行业比较 10 条：5 条有兜底（无可比样本退自身近三年均值、至少三期），5 条无兜底缺数判「数据不足」。

覆盖约束：10 个风险域每域 ≥5 条、代表事实域每域 ≥2 条、RATIO/IDENT/STATE/COUNT/NOSCORE 五形态齐备、P0/P1/P2 三级齐备。

判定引擎：自建受限表达式语言——只允许白名单函数（prev 取上期、yoy 同比、share 占比、ratio 比值、streak 连续期数、avg3y 近三年均值、industry 行业均值等），编译为 AST 解释执行，不能调用任意代码。每条规则输出：判定（重点关注/关注/通过/数据不足/不适用）+ 实测依据（算式与科目金额，可对上计算口径）。四层筛选（适用对象、数据可得性、业务前置、规则类型）在执行前收窄规则集，不适用条目不计分母、不占清单。

六、议题聚合与评分

• 议题聚合：按 44 事实域（种子集覆盖约 15 个代表域）聚合，同域触发规则合并为一个议题，议题卡标明「本议题同时触发 N 条规则，已合并计为 1 项」。严重度取组内最重判定；优先级取实际判了重点关注的那条规则的优先级（不取全组最高，防止 P1 重判从 P0 轻判借权重）。
• 评分三轴取中位数：重大问题数（必查项重点关注议题数）、问题密度（触发议题占已判定规则比例）、加权分（重点关注 P0=6/P1=3/P2=1；关注 P0=2/P1=1/P2=0.4）。三轴中位数映射极高/高/中/低四档。
• 否决覆盖：八条否决独立判定位，优先级高于评分，触发即结论覆盖为「不建议准入」。

七、图表体系

38 条图表定义全部落为数据驱动 spec（事实域、图型、序列、序列取数口径、阈值带、读法文本），序列只允许引用数据层命名空间。渲染层：Vue3 + ECharts 封装，折线阈值带用 markArea（黄区/红区，双向阈值都渲染）、阈值线参与纵轴取值范围。

• 出图条件（每次渲染重算）：该事实域至少一条规则判重点关注或关注（按人工复核后状态计）＋ 落在触发最多的维度页（触发数相同取规则数多的，再相同按导航顺序）＋ 至少一条序列取得到非空非零的数；
• 页内排序：按 P0 触发数、重点关注数、关注数依次降序；
• 图下判读三行由程序现算：最新读数与上期对比（有阈值带的加一句相对阈值线位置）、本域触发条数与最重规则（可点击跳转规则库）、规则库通用读法（标「读法」）；
• 8 个无数值序列的事实域（对外担保、关联交易等）不出图；渲染验证选 12–15 张代表图，其余 38 条定义 correctness 由 spec 单测保证。

八、多智能体设计

全屏打开 ↗

五条硬约束：只用给出的事实和数字；人工判定优先于系统原判定；授信六维文案必须与系统档位一致；触发重点关注事项时结论必须是不建议准入；只输出固定字段的 JSON 对象。质检不过由编排退回重写（附违规项），最多三次；仍不过则降级为模板文案并标注「模型生成未通过质检」——禁止带病发布。

LLM 网关：OpenAI 兼容抽象层，RECORD/REPLAY 两种模式——录制模式把 (模型, 提示词哈希) → 响应存入 fixtures；回放模式直接命中缓存，回归测试零 token、结果可复现。温度取低值并使用结构化输出。

九、前端设计

分析任务为长任务（规则数百条 + 多次 LLM 调用），API 以任务 id + SSE 推送进度；前端按环节显示流水线状态。

十、工程结构与实施方案

finrisk/
├── backend/app/
│   ├── models/       # SQLModel：公司/事实/派生/分季/母公司/外部/行业均值/规则/判定/议题/留痕
│   ├── datalayer/    # 七命名空间取数接口（唯一取数通道）
│   ├── rules/        # 规则库加载、四层筛选
│   ├── engine/       # 表达式语言（白名单函数 + AST）、五形态判定、双容差
│   ├── aggregate/    # 议题聚合、三轴评分、八条否决
│   ├── charts/       # 38 图 spec、出图条件、图下判读三行
│   ├── agents/       # orchestrator / readers / writer / qc（LangGraph）
│   ├── llm/          # OpenAI 兼容网关、录制回放
│   └── api/          # FastAPI 路由 + SSE
├── backend/data/     # 种子规则库（YAML，数据驱动可增量）
├── backend/fixtures/ # LLM 录制回放
├── backend/tests/    # 判定引擎与聚合的黄金用例
├── frontend/         # Vue3 + Vite + TS + ECharts
└── samples/          # 两家样本公司数据（健康厂 / 藏雷集团）

里程碑：

验收标准（对应四个核心命题）：①任一条判定点开可见实测数值、阈值档位、规则编号；②结论 JSON 通过 Schema 与质检三道校验，六项文案与档位一致率 100%；③人工改判保存后档位与评级即时刷新，「大模型重算」只改文案不改档位；④藏雷集团评级被否决覆盖为「不建议准入」且判定明细完整。

风险与对策：LLM 输出 JSON 不稳定 → 结构化输出 + 三次重试 + 模板降级；图规格反推的规则口径与行内真实规则库有偏差 → 种子集逐条标注来源（图规格/需求原文），真实规则库到位后按 17 字段导入替换；两家样本覆盖不了中间态分档 → 数据 schema 支持随时增补第三家公司。

十一、术语表

2 - 星辰智能

星辰智能（Xingchen Intelligence）项目文档：

• VLAgent 智能文档识别平台架构解读：项目组内部分享——前后端工程全景解读，覆盖业务架构、技术架构、数据架构、凭证核验主流程与 CI/CD 发布流水线，附五张交互式图表
• StarWork 桌面端技术架构：star-work 仓库全景解读——三层拼装（统一外壳 + Agent 引擎 + 编辑器层）、进程与运行时模型、五编辑器能力矩阵、AI 改文档的三条硬约束（门禁/事务/补丁）、工作区围栏与云控通道，附四张交互式图表
• StarWork 云控服务端技术架构：star-work-cloud 仓库全景解读——单进程双服务（TLS 长连接 + gin HTTP）、统一信封协议、配置定向下发、技能/版本包分片分发、设备连接生命周期与多副本就绪部署，附四张交互式图表
• 结算类凭证要素核验需求规格说明书：覆盖结算业务申请书与「转账支票+进账单」两个核验场景的完整需求规格——六张核验规则逐条映射、五态结论体系、印章识别混合方案与抽取自修复链，含核验总流程、印章管线与系统架构三张交互式图表
• 智能文档识别平台规划方案：基于 OCR + VLM 双引擎的企业级识别能力平台规划——目标、业务/应用/技术/数据/部署架构、技术栈选型、MCP×ESB 协同与演进路径，含六张交互式图表
• 智能文档识别平台建设实施计划：对应规划方案的落地实施文档——一期详细设计（数据模型、API 契约、编排运行时、引擎适配、评测体系）、二三期方案、项目计划（里程碑/人力/资源/依赖）与实施风险，附里程碑交互图

2.1 - VLAgent 智能文档识别平台架构解读

依据 vlagent 前后端仓库（vlagent-backend / vlagent-frontend）与工程内文档编制，用于项目组内部分享。文中五张图表均为交互式：支持缩放、语义视图、关系追踪与 PNG/SVG 导出。

一、项目概览

VLAgent 是部署在银行内网 K8s 上的智能文档识别平台：以 Qwen-VL 多模态大模型为主、PaddleOCR 为辅，对银行流水、结算凭证、询证函、发票、类凭证等影像做结构化抽取与规则核验，替代柜面与审计场景中的人工初核。系统以 iframe 嵌入**星辰智能助手（IOA）**对外提供服务，前端工作台与 FastAPI 后端共享同一 Ingress 域名（生产为 aisit.qdccb.cn / vlagent 路径）。

两个工程均为"垂直切片"式组织：后端 src/ 下每个业务模块自带 router + service + models + prompts；前端除平铺的 views/ 外，settlement/、credit_comparison/ 两个新模块采用自带 views/components/api 的 feature 目录，代表较新的组织方式。

二、业务架构

平台服务两类用户：柜面柜员（凭证影像上传、核验结果确认）与审计/运营人员（流水核对、报表核对）。接入侧通过 iframe 嵌入星辰智能助手（IOA），JWT 多通道取 token，用户无需二次登录；首页模块卡片由后端 modules + permissions/me 接口动态驱动，按权限渲染、前端零改动即可上下架模块。

业务能力划分为三个域 + 平台服务域，共九个业务模块：

全屏打开 ↗

三、技术架构

3.1 前端

• 无第三方组件库、无 Pinia：全部手写 Vue 组件 + Tailwind 工具类；状态用 composables 的模块级 ref 单例（useUser）与函数式状态机（useAuth、useSettlementRecords）共享。
• API 层单文件收敛：src/api/index.ts 约 400 行封装全部后端接口，统一注入 Bearer token、401 全局登出、blob 预览与下载。
• 重前端计算：credit_comparison 在前端完成 Word 段落锚点匹配、高亮分词、Excel 行列识别（约 1000 行纯前端数据变换）；PDF 渲染用 pdfjs-dist（含中文 cmaps），Word 用 docx-preview。
• 通信模式为纯 HTTP + 轮询（典型 3 秒，完成后自动停止），全库无 SSE/WebSocket。

3.2 后端

• 入口链路：main.py 组装 app（启动时自动 alembic upgrade head、按需起 JVM 与上游同步、APScheduler）→ api.py 统一挂载 13 组子路由，全部默认要求 JWT（HS256，支持 ?token= URL 参数以适配 iframe）。
• 无消息队列：异步识别全部走 FastAPI 后台任务 + asyncio.to_thread，全局 asyncio.Semaphore(2) 限流——2 副本 × 4 workers × 2 = 16 并发，压在 AI 网关 20 并发上限之内。
• 银行流水策略模式：抽象基类 BankHandler + @register_bank 注册表，11 家银行各一个 handler 与独立表结构，config/bank_schemas/ 外置 schema。
• 文档处理链：pdf2image/poppler 拆页压缩、pdfplumber/pymupdf 结构化提取、容器内 LibreOffice 做 DOCX→PDF、diff-match-patch 做比对。

3.3 AI 混合管线

核心设计是抽取与核验分离：Qwen-VL 只做忠实抽取（含裁片精读），PaddleOCR 只做定位（印章 bbox、版面），合规判定完全在确定性规则层。所有模型不确定性被限制在第一阶段，判定层可单测、可审计。

全屏打开 ↗

四、数据架构

双库架构：业务主库 vlagent（PostgreSQL，asyncpg 异步驱动）+ 上游星辰智能助手（IOA）只读库。APScheduler 定时单向同步模块与权限，用 PG Advisory Lock 保证多副本多 worker 只有一个实例执行。

建表策略：表结构真相在 SQLModel 模型，由 init_db() 的 create_all 创建；alembic 仅做增量列变更（基线迁移为空操作，后续迁移逐条 ADD COLUMN IF NOT EXISTS 保证幂等）。

表清单概览（约 38 张）：

全屏打开 ↗

五、核心流程：凭证核验主链路

以结算凭证核验为代表的通用异步契约：

1. 接入：柜员上传 PDF（魔数校验、防路径穿越）→ 建 pending 记录 → 接口立即返回任务 ID，前端开始 3 秒轮询。
2. AI 抽取：按票种分发 Handler（prompt + Pydantic schema）→ Qwen-VL 整图多面抽取 → PaddleOCR 印章定位 + VLM 裁片精读覆盖 stamps。
3. 自修复：盲区二次提取、金额复核读（裁左右半分读大小写）、付款人账号跨单复核，矛盾消解后才覆盖。
4. 规则核验：极简规则引擎（Rule.check() → Engine → Report）对要素总集逐条判定，输出五态结论（通过/不通过/警告/不适用/待人工复核），总体取最严重态。
5. 交付：记录 + 逐条明细落库，前端轮询到完成态后渲染报告，支持证据定位与导出。

全屏打开 ↗

六、CI/CD 发布流水线

三环境分级流转，生产网与研发网物理隔离：

双工程构建策略差异是理解流水线的关键：

• 前端在容器内多阶段构建（node:lts-bullseye 内 npm install + vite build → 拷入 OpenResty），.dockerignore 排除 lock 文件以适配内网 npm 源；
• 后端采用 Agent 预构建 + 纯打包（Jenkins Agent 上 uv sync 生成 .venv，镜像只 COPY venv + 源码），基础镜像 vlagent-backend-runtime:1.1 预装 poppler、中文字体、LibreOffice 与 tini。

配置注入走 Helm：非敏感项进 ConfigMap、密钥进 Secret，Pod 以 config-hash/secret-hash 注解实现配置变更自动重启；上传产物落 nfs-client PVC。

全屏打开 ↗

七、工程质量与演进方向

• 测试重心：44 个测试文件、361 个用例，其中 settlement_check 占 33 个文件约 300 例（规则逐条一测、印章管线 40 例、可注入假 extractor 不依赖网络/DB），TDD 痕迹明显；HTTP 层与早期模块（banks/files）基本无单测。
• 已知文档滞后：前端 README 提及的 Tiptap、api 分文件与后端的 native_statement 模块均与当前代码不符，以代码为准。
• 值得关注的取舍：无消息队列（进程内后台任务 + 信号量）在当前并发规模下最简可靠，但识别吞吐受副本数硬约束；轮询而非 SSE 也是同源 iframe 场景下的务实选择。
• 演进方向：结算凭证特种票种扩展、HTTP 层集成测试补齐、识别结果缓存与幂等重试。

2.2 - 结算类凭证要素核验需求规格说明书

依据《AI 审核规则》及 vlagent 项目已实现的核验能力编制。本说明书覆盖结算业务申请书（单张/批量）与**「转账支票+进账单」联合核验**两个场景，规则与需求文档逐条对应（申请书 1.1–1.8、支票 2.1–2.12），并纳入实现过程中经业务确认的判定口径。

一、引言

1.1 目的与范围

为银行柜面结算凭证的人工审核提供 AI 辅助要素核验：识别凭证影像上的要素，按规则逐条给出结论与证据，供柜员快速定位问题。本说明书界定两个核验场景的功能与非功能需求；特种转账借方传票等票种为规划范围（规则文档 §3 占位），不在本期。

1.2 术语

1.3 参考文档

《AI 审核规则》（结算业务申请书 §1、转账支票+进账单 §2）；项目 CONTEXT.md 词汇表与 ADR-0001～0004。

二、总体描述

2.1 系统定位与流程

系统采用抽取-校验分离的两阶段架构：第一阶段完成要素收集与自修复（VLM 整图抽取 → PaddleOCR 印章增强 → 金额/账号复核 → 文本兜底），产出一册完整的要素总集；第二阶段由规则引擎对同一册证据逐条判定，输出五态结论。所有模型不确定性被限制在第一阶段，判定层完全确定、可单测、可审计。

全屏打开 ↗

2.2 系统架构

前端为核验工作台（上传、轮询、报告呈现）；FastAPI 后端编排两阶段管线；AI 服务包括 Qwen-VL 多模态（整图抽取与裁片精读）与内网 PaddleOCR（版面解析与印章定位）；证据（裁片文件、PaddleOCR 输出、校验明细）随记录落库可追溯。

全屏打开 ↗

2.3 结论体系（五态）

总体结论取全部规则的最严重态。

2.4 凭证上传要求

• 结算业务申请书：单面凭证，支持单张与批量上传（一次最多 5 张，逐张独立识别）；批量时逐张展示状态与结论，支持汇总（N 通过 / M 不通过 / K 待复核）与单张钻取。
• 转账支票+进账单：三件配套必传——支票正面、支票背面、进账单，缺一拒绝受理（无背面则背书核对无从做起，无进账单则跨单比对无从做起）；可选输入交易码（票号位数模式用）。

三、功能需求——结算业务申请书

规则与需求文档 §1.1–§1.8 一一对应；申请日期与进账单日期共用公共日期口径。

印章分类按证据判定：类型词/形状会被识别错（如方形名章被读作「圆形+测试专用章」），分类依「章文结构 + person_name/unit_name 互斥字段 + 形状」综合反推；票面有单位章时按单位口径（户名启发式可被章型证据纠正）。

四、功能需求——转账支票+进账单

三件联合核验，规则与 §2.1–§2.12 一一对应。支票正面/背面字段平铺合并，进账单整体挂 slip 命名空间。

说明文案要求（业务确认）：无论结论如何，说明中固定罗列检核用到的各要素（票面收款人、每手背书人（标注形式）与被背书人（含委托收款标记）、进账单收款人全称），未识别项标注「未识别」。

五、印章识别混合方案

整图 VLM 识别印章不可靠（计数幻觉、锚点挪用、示例污染），采用 PaddleOCR 定位裁片 + VLM 裁片精读：

• PaddleOCR 只负责检测印章位置并输出裁片；章文内容由 VLM 按统一印章解剖学口径精读单枚特写；其余字段维持整图抽取。
• 归属用表格结构与 bbox 几何（背面 x 向三区：附加信息 / 第 1 手 / 第 2 手），VLM 不参与。
• 三重透印过滤（两面通用）：低饱和淡红（颜色）、裁片框红墨覆盖率过低（稀疏透痕）、镜像反字（方向）任一命中即剔除。
• 章证优先：检出单位章即以其单位名称重推锚点并覆盖手写标志；手写保护——该手未检出裁片时整图结果原样保留（手写第一行锚点不清空）。
• PaddleOCR 失败优雅降级退回整图值；被剔除裁片仍落盘留证。

全屏打开 ↗

六、抽取自修复链（第一阶段）

所有修复仅发生在证据层，「发现缺口/矛盾 → 定向重读 → 能消解才采纳」：

七、接口需求

八、非功能需求

• 确定性：同一输入必出同一结论；规则层不调用任何模型。
• 可追溯：每条结论附说明与证据；印章证据附裁片文件地址；PaddleOCR 输出目录随记录落库。
• 降级：任一外部服务（VLM/PaddleOCR）失败不影响主流程出报告（退回可用证据，标注待复核）。
• 性能：性能测试本期不涉及；单张凭证端到端（含两次 VLM 抽取 + 印章增强）按 ≤60s 设计、批量 5 张并行，仅作设计参考值，不作为测试验收口径。
• 安全：全接口 JWT 鉴权；影像与输出文件按用户目录隔离。

九、附录

9.1 规划范围

• 结算业务申请书批量上传（≤5 张）前端交互与汇总展示（增量需求）。
• 特种转账借方传票（规则文档 §3 占位）、电汇凭证等新票种。
• PaddleOCR 能力服务化（ADR-0004：独立 OCR 标准化服务，方案已定案）。

9.2 版式先验

背面背书栏位三区/手间分界等几何先验按样本标定，换版式样本须复标；进账单金额位值表格解析依赖表格结构识别质量。

2.3 - 智能文档识别平台规划方案

面向企业影像与文档智能场景的识别能力平台规划方案。平台以 OCR 与 VLM 双引擎为底座，通过 REST API、MCP 与可嵌入识别工作台（AG-UI）三种形态对外输出识别能力。本方案为从目标出发的全新设计，不绑定任何现有系统的实现；现有业务系统在方案中仅以"首个消费方"身份出现。文中七张图表均为交互式：支持缩放、语义视图、关系追踪与 PNG/SVG 导出。

一、背景与目标

1.1 建设动因

识别类能力目前散落在各业务系统中自建自用，存在三方面问题：

• 识别与业务规则耦合：抽取管线与校验规则交织在同一套代码里，换模型、调参数会波及业务逻辑，测试边界模糊；
• 能力无法复用：每个系统重复解决版面解析、手写识别、印章提取、裁片精读等同类问题，质量参差；
• 质量无闭环：识别错误依赖各系统自行发现，没有统一的 badcase 归集、评测与模型迭代机制。

1.2 平台目标

一句话定位：给一份文档，还你结构化与语义化的识别结果——OCR 负责结构与位置，VLM 负责语义与理解，双引擎一个平台，REST、MCP 与工作台三出口。

三条核心目标：

1. 识别与判断解耦：平台输出"事实"（字段、位置、置信度、证据），业务判断（合规校验、规则比对）完全留在消费方。判断类输出（一致/不一致、合规/违规）永远不出现在平台侧。
2. 识别能力服务化：企业内任何系统、任何智能体都可以通过标准契约消费识别能力，新场景上线是"新增一条类型配置"，不是"新写一套识别服务"。
3. 引擎可插拔可演进：OCR、CV、VLM 引擎都是可替换资源；接入第 N+1 个引擎只新增一个适配器，核心层零改动；模型可通过微调闭环持续变准。

1.3 设计原则

1.4 成功度量

二、业务架构

2.1 消费方

平台服务四类消费方，对应三种接入形态：

• 业务系统（REST API）：消费识别字段做业务处理。典型如结算凭证核验系统——平台读出大小写金额与印章位置，系统侧做一致性校验；
• 智能体（MCP）：对话式消费识别能力。柜员或审计在智能助手里"把这张凭证的金额读出来"，助手调 MCP 工具完成识别并组织回答；
• 终端操作者（可嵌入识别工作台 · AG-UI）：业务系统把平台提供的识别工作台嵌入自身页面，操作人员以对话方式完成上传、识别与人工复核——界面交互走 AG-UI 协议（第三出口），权威数据仍凭 log_id 走 REST/MCP 获取；
• 平台运营方：管理文档类型、评测集、引擎版本与调用配额。

2.2 能力分层

划分标准：“怎么读准"进平台文档类型，“读出来的对不对"留在消费方。版式先验（如票据金额栏位置）属于"怎么读准”，沉淀为平台文档类型，全行复用；合规规则属于业务立场，不得进入平台。

2.3 质量闭环

业务架构的灵魂是 badcase 闭环：消费方复核标记 → 平台归集台账 → 人工标注修正 → 沉淀 golden 评测集 → 驱动文档类型调优与引擎微调 → 评测通过后灰度上线 → 通知消费方。闭环转起来，平台从成本中心变成越用越准的资产。

全屏打开 ↗

三、应用架构

3.1 应用组件

3.2 统一结果模型（契约核心）

所有引擎输出归一到同一对象模型，这是 API 与 MCP 共享的地基：

{
  "document_id": "doc_8f3a",
  "pages": [
    {"page_no": 1, "blocks": [
      {"bbox": [0.12, 0.31, 0.68, 0.36], "type": "handwriting",
       "text": "青岛市北区……", "confidence": 0.71, "source_engine": "paddleocr-vl"}
    ]}
  ],
  "fields": [
    {"name": "merchant_name", "value": "……", "confidence": 0.64,
     "needs_review": true, "evidence_block_ids": ["blk_12"]}
  ],
  "meta": {"log_id": "…", "doc_type": "voucher-v1", "engines_used": […],
           "artifacts_uri": "minio://…", "latency_ms": 4200}
}

三个关键字段：confidence（字段级置信度）、needs_review（投票不一致即标记，宁缺勿错）、evidence_block_ids（每个字段可回溯到原图证据块，审计场景刚需）。

3.3 MCP 设计要点

• 工具粗粒度：upload_document（拿 doc_id）、recognize_document、extract_fields、compare_documents、query_result；文件走引用不传裸 base64；
• 结果作为 MCP resources 暴露，智能体可按 URI 二次取用；
• tool description 即给大模型的说明书，明确"何时该用、何时不该用”；
• 每次工具调用记调用方身份并进审计日志。

全屏打开 ↗

3.4 AG-UI 识别工作台：可嵌入的对话式识别界面

第三出口面向终端操作者：不是所有人都在智能助手里对话，更多时候是在业务系统页面里直接办事。AG-UI（Agent-User Interaction Protocol）是"智能体后端 ↔ 前端界面"的标准协议——平台实现该协议的会话端点，并交付一个可被任意业务系统嵌入的识别工作台前端，操作人员上传文档、看到流式识别过程、在界面上完成人工复核。

设计要点：

• 端点即协议：POST /agent/run 接收 RunAgentInput（会话 ID、消息历史、共享状态），以 SSE 事件流返回（RUN_* 生命周期、TEXT_MESSAGE_* 流式文本、TOOL_CALL_* 工具过程、STATE_SNAPSHOT 状态快照）——标准 AG-UI，前端实现可整体替换；
• 三出口单一实现：会话内的工具（列类型、抽取字段、查历史）直接调用与 REST/MCP 相同的业务层，工作台只是协议之上的第三个壳；
• 客户端权威状态：共享状态（doc_id、字段、复核标记）由前端持有、每轮全量上送，服务端无会话粘性——平台不成为有状态单体；
• 人在回路：needs_review 字段驱动复核表单，复核意见作为新消息进入下一轮会话，形成"识别 → 复核 → 确认"闭环；
• 嵌入契约：业务系统以 iframe 嵌入，URL 注入访问凭证；界面只管操作，权威结果凭 log_id 走 REST/MCP 获取（界面与数据解耦）；调用方/用户/机构级权限随调用方管理演进（凭证携带身份声明）。

全屏打开 ↗

3.5 MCP 与企业服务总线（ESB）的协同

企业已有传统 ESB，系统间接口调用统一经其转发。MCP 引入后的关系定位：两者不是替代关系，而是架构中两段不同的接线——ESB 管"系统之间怎么互相调用"（服务治理层），MCP 管"智能体怎么调用能力"（AI 接入层）。MCP Server 站在前面作为智能体接入层，它发起的跨系统服务调用仍然走 ESB，就像当年移动端渠道出现时，移动网关背后照样调 ESB 服务——智能体只是又一种前端。

MCP Server 的归属：跟着能力走，属于能力提供方系统。本平台的 MCP Server 是平台应用的组件之一，部署在平台命名空间、与 REST API 共享同一套编排实现；智能体平台只做消费方，不替提供方建工具适配，避免长出绕开治理的影子集成网。分工与 ESB 治理经验同构：工具语义（描述、参数 Schema、错误码）由能力提供方定义，鉴权/审计/限流等治理能力可集中——中期由 ESB/APIGW 原生托管 MCP 协议绑定时，这一分工不变。

调用边界：MCP Server 调用本平台内部能力（MCP → 编排层）属系统内调用，不经 ESB；跨系统调用（如经 ESB 到影像平台调阅影像、回写核心系统）一律走 ESB，纳入既有治理。两层审计各司其职：MCP 层记录"哪个智能体、代表哪个用户、调了什么工具"，ESB 层照旧记录服务调用，日志 ID 串联。

全屏打开 ↗

3.6 文档类型化接入：按类型识别输出

识别接口按**文档类型（文档类型）**输出对应字段集——发票返回发票字段、询证函返回询证函字段，文档类型与输出字段在平台管理端可配置。这是编排层类型化的直接应用：输出字段 = 文档类型中声明式定义的字段 Schema。

API 形态：按能力大类分端点，大类内按文档类型参数化。 大类与文档类型是两个正交维度——大类区分任务形态（识别、比对、批量），文档类型区分票种（发票、询证函、凭证）：

POST /v1/documents          // 文档接入：上传拿 doc_id、查询、状态（REST 资源型）
POST /v1/recognize          // 识别抽取大类：单文档进、字段集出
  { "file": "…", "doc_type": "invoice" }        // → 发票字段
  { "file": "…", "doc_type": "confirmation" }   // → 询证函字段
POST /v1/compare            // 比对大类：双文档进、差异结论出（doc_type 同样参数化）
POST /v1/batches            // 批量异步大类：文档集进、任务句柄出（引用文档类型）
GET  /v1/doc-types/{id}/schema  // 文档类型契约下发

划分判据：请求/响应骨架是否同构。 同构（单文档进、字段出）归入识别大类，用类型参数区分文档种类——发票、询证函、凭证互不开端点；不同构（双文档进差异出、批量任务句柄、文档资源管理）才开新大类。由此保留两个收益：新文档类型上线 = 管理端加类型，不发版；新任务形态出现才动 API 面。MCP 工具按大类映射（upload_document / extract_fields / compare_documents），保持粗粒度。印章提取等"输出为位置与图像证据"的能力首选纳入类型化配置（印章作为特殊字段类型，值 = 位置 + 裁片引用），仅当输出形态无法归入统一结果模型时才开专项端点，避免大类膨胀。

动态字段的契约机制（此设计成败的关键）：每个类型携带正式的字段 Schema 作为一等契约下发——GET /v1/doc-types/{id}/schema 随时可取，SDK 按文档类型生成强类型客户端；字段变更守纪律（加字段 = 文档类型小版本兼容升级；改字段语义/删字段 = 新大版本，消费方显式迁移）；管理端保存文档类型时即做 Schema 校验（命名规范、类型合法、必填约束自洽），脏配置进不了生产。文档类型配置模型示例：

{
  "id": "invoice", "version": "3.2",
  "fields": [
    {"name": "invoice_number", "type": "string", "required": true,
     "extraction": {"mode": "ocr_direct"},
     "post_rules": [{"type": "regex_validate", "pattern": "^[0-9]{8,20}$"}]},
    {"name": "amount", "type": "decimal", "required": true,
     "extraction": {"mode": "cross_engine_vote"}}
  ],
  "layout_priors": {"amount_region": "…"},
  "routing": {"preference": ["ocr", "vlm"], "fallback": true}
}

配置化的深度与边界：配置表达"结构与参数"，代码表达"算法与流程"——把逻辑塞进配置端会演化出没人敢改的"配置编程语言"，把结构参数写死代码又会让新场景接入周期失控。

两条配套约束：① 类型变更与代码变更同级对待——管理端配置同样走"草稿 → golden 集评测通过 → 发布"，不允许直接改生产文档类型；② 配置出来的字段同样携带 confidence / needs_review / evidence_block_ids，配置化不绕过质量纪律。自然扩展（按需）：doc_type: "auto"——混合批次先经 CV 引擎文档分类再路由到对应文档类型，文档类型机制天然支持。

3.7 提示词管理：渲染产物与护栏

VLM 识别的提示词不是独立维护的字符串，而是文档类型的渲染产物：字段定义是数据，提示词模板是模板，最终发给 VLM 的提示词 = 渲染器（模板 + 字段定义 + Schema 约束）生成——与文档类型同版本、同生命周期。

关键机制是渲染时注入：模板引用受控变量插槽（{{fields_schema}} 等）而非硬编码字段清单——文档类型加字段，下次渲染自动带上，不存在"字段加了、提示词忘了同步"的不一致。由此买到三样东西：一致性（字段与提示词同源）、可审计（结果 ↔ 类型版本 ↔ 渲染后提示词绑定，历史可重放）、缓存友好（同版本渲染结果可缓存）。

五条护栏（缺一条，动态提示词就是事故源）：

1. 模板与数据分离：字段清单永远经渲染注入，不写死在模板里；
2. 受控变量插槽：模板只支持平台预定义变量（fields、schema、language、context），不允许任意表达式——配置端不能演化成编程语言；
3. 系统级指令不可配：输出必须 JSON、不得编造等平台级纪律由代码持有，管理端模板覆盖不到；
4. 评测门禁覆盖提示词变更：提示词有牵一发动全身的隐性风险（改一个字段描述可能让整页其他字段退化），正确工作流是草稿 → golden 集回归 → 新旧 A/B 对比 → 发布，不允许直接改生产；
5. 提示词版本 = 类型版本：不存在独立的提示词版本，回滚文档类型即回滚提示词。

由此，提示词调优进入与模型迭代同一条质量闭环：badcase 台账发现字段系统性读错 → 定位字段描述歧义或模板问题 → 管理端改草稿 → golden 集验证提升且无回归 → 发布新类型版本。提示词从代码里的字符串变成可运营、可度量、可回滚的资产——这是文档类型化架构对 VLM 侧最大的红利。

四、技术架构

4.1 分层结构

自上而下四层 + 一条旁路 + 一个横切面：

• 接入层：REST 网关与 MCP Server，只做协议、鉴权与流控；
• 编排层：类型引擎（场景 = 配置而非代码）、引擎路由（按精度/成本/健康度选引擎）、投票融合与降级决策；
• 能力与适配层：对上暴露稳定的能力契约，对下吸收引擎差异——坐标归一（统一像素系）、置信度标定（引擎分数可比化）、块类型映射（统一版面词表）；
• 引擎层：可插拔资源，多版本灰度共存；
• 训练流水线（旁路）：标注集管理 → 微调训练 → golden 集评测 → 版本注册，产出新引擎版本进入引擎层；
• 横切治理：鉴权、审计、配额、监控在接入层统一实施。

4.2 双引擎协作模式

编排层固化的三种文档类型模式：

1. OCR 直出：印刷体、清晰扫描，一步到位——多数页面走这条，成本最低；
2. OCR 定位 + VLM 精读：OCR 出版面与 bbox，定位目标区域裁片增强后交 VLM 读字段——手写、印章、模糊区域走这条；
3. VLM 全读：无版式规律的语义理解与文档比对，整图交 VLM。

4.3 路由、投票与降级

• 成本路由：OCR 能解决的字段不过 VLM；冲突或低置信才升级，控制推理成本；
• 跨引擎投票：不同架构的模型错误模式不相关，关键字段（金额、户名）双引擎互验远比同模型多读可靠；
• 降级链：引擎超时/异常 → 重试 → 备用引擎 → 整图直读兜底；仍失败返回明确错误码；投票不一致字段标 needs_review 走人工。

全屏打开 ↗

五、技术栈选型

选型独立于任何现有系统评估，按扩展性、成熟度、开发效率、性能、运维成本、信创合规六个维度论证。

5.1 选型决策表

5.2 Python 与 Go：主体与边缘的分工

决策：平台主体语言为 Python；Go 不作为平台语言，仅作为特定边缘组件的按需选项——按瓶颈引入，不按偏好引入。

先看负载画像：处理一份文档的时间分布为——引擎推理（GPU，秒级）> VLM 调用（秒级）> 预处理（百毫秒级）> 编排逻辑（毫秒级）。延迟大头在引擎、吞吐瓶颈在算力，编排层是 IO 密集的轻计算层，FastAPI 的 asyncio 在凭证级调用量下余量充足；Go 的并发优势在高 RPS 网关场景才兑现，此处用不上。更关键的是语言分裂的代价：训练、微调、评测、预处理全在 Python 生态，编排层若用 Go，模型迭代链路被切成两半，每次调整都要跨语言维护两份实现——平台的核心竞争力（文档类型快速迭代 + 模型持续变准）都长在 Python 生态里。

公允对照 Go 的真实优势与平台需求：

分层语言分工：

组件改写为 Go 的三条触发判据（不满足任何一条则不引入，第二语言的维护成本是持续的）：

1. 实测瓶颈：压测显示 Python 组件在目标 SLA 下 p99 不可接受，且进程池、缓存等优化已到头；
2. 部署形态：组件需以单二进制下沉到无 Python 运行时的环境；
3. 纯网络转发：组件为无状态转发/聚合、无业务语义，用 Go 实现反而更简单。

补充选项：若企业平台工程规范倾向 Go 网关，可接受"Go 接入壳 + Python 编排核"的混合架构——Go 只做协议接入与流控，全部业务语义在 Python；前提是契约（OpenAPI）稳定且团队双语言人力齐备。

5.3 多智能体：不引入的架构决策

决策：识别平台不引入自主智能体编排（含多智能体）；平台是工具/能力提供方——被智能体调用的那一端——自身不成为智能体。跨工具的动态编排属于消费方智能体平台的职责。

期望"智能体"带来的能力，平台已用确定性等价物覆盖：多读投票（应对幻觉）、needs_review 复核标记（自我校验）、降级链（自主恢复）、文档类型路由（自适应选择）——效果可度量、路径可复现。

边界条件：若未来出现开放式任务（如"审计整卷信贷档案"需运行时分解、交叉比对、汇总结论），正确做法是在消费方/业务方案层增设智能体编排——由它规划步骤并循环调用平台的 MCP 工具，识别平台继续作为被调用的工具集，分层不变。

5.4 维度小结

• 扩展性：引擎适配层 + 注册表保证水平扩展（多引擎）与垂直扩展（多副本 HPA）两条路径都开放；
• 成熟度：全部选型均为生产级验证过的主流组件，无实验性依赖；
• 开发效率：单一语言（Python）覆盖业务编排到模型迭代，文档类型化让新场景以天级接入；
• 性能：计算密度在引擎层（GPU），编排层 IO 密集（异步足够），分层各自优化互不拖累；
• 运维成本：一期落地组件仅 3 个（平台服务、MinIO、PG；引擎复用已有部署），Redis 二期引入；
• 信创：框架（PaddlePaddle）与芯片适配（昇腾/昆仑）均国产化可选。

六、数据架构

6.1 存储分工

6.2 核心数据模型（表清单）

6.3 证据链与数据反哺

• 每个字段的 evidence_block_ids 指向块级记录，块级记录指向对象存储中的裁片与引擎原始输出——任何结论可重放验证；
• 低置信字段与复核标记自动进入 badcase 台账，人工标注后沉淀 golden 集；golden 集同时服务引擎评测、类型回归与微调训练三类消费；
• 数据生命周期：原始文档与证据按监管留存期归档；引擎原始输出可按期降冷，统一结果永久在线。

全屏打开 ↗

七、部署架构

7.1 K8s 拓扑

• 平台命名空间：统一接入（Ingress/TLS）+ 平台服务（API/MCP/编排，无状态多副本 + HPA）+ 存储组件（MinIO/PG/Redis，或接共享实例）；
• GPU 节点池：PaddleOCR-VL 等重推理产线，按负载独立扩缩容，容器独占卡（PaddleOCR-VL 已有部署，直接接入复用）；
• CPU 节点池：CV 任务与轻量 OCR；
• VLM：走大模型平台统一算力，平台不重复建设推理资源。

7.2 版本化与发布

• 模型版本 = 不可变镜像 tag：训练流水线产出带版本号的 serving 镜像，Harbor 承载，回滚即镜像回滚；
• 发布门禁：新引擎版本必须先在评测环境跑 golden 集回归，字段准确率不退化方可灰度；灰度通过端点 model_version 参数路由，默认 stable；
• 流水线：Jenkins 构建镜像 → Harbor → ArgoCD 声明式同步，发布与回滚均为 Git 变更，全程可审计。

7.3 环境规划

SIT（联调，黄金集回归常驻）/ UAT（业务验收 + 灰度验证）/ 生产（灰度发布 + 双版本并行）。生产网与研发网物理隔离，制品经镜像仓库摆渡。

全屏打开 ↗

八、演进路径

九、风险与对策

2.4 - 智能文档识别平台建设实施计划与详细方案

本文是《智能文档识别平台规划方案》的落地实施文档：规划方案回答"建什么、为什么这样建"，本文回答怎么建、什么节奏、做到什么程度算完成。所有架构决策以规划方案为准，本文不重复论证，只做实施展开。

一、建设原则

• 契约先行：统一结果模型与评测口径最先定版（M1），其后所有工作以此为验收基准；
• 演进式交付：一期到三期每期独立可交付，任何一期结束后暂停都不产生半成品负债；
• 评测门禁从第一天生效：一期上线即带 golden 集回归，“无评测集的场景不上线"从一期就是纪律而非愿景；
• 消费方牵引：每期以真实消费方场景验收，不以技术组件完成为验收标准。

二、总体建设路线

全屏打开 ↗

三、一期详细方案

3.1 范围界定

做：统一结果模型定版；编排引擎与双引擎适配（PaddleOCR-VL + VLM，VLM 经大模型平台 OpenAI 兼容协议接入）；提示词渲染器（类型模板 + 字段描述渲染，规划方案 3.7 的护栏一期即生效）；首个场景类型（结算凭证类，含手写字段的 OCR 定位 + VLM 精读）；REST API 与能力网关；管理端最小集（类型 CRUD + 发布门禁）；golden 评测集与 CI 门禁；SIT/UAT 环境部署。

做（追加）：MCP Server（原计划二期，应要求提前——Streamable HTTP 四工具：upload_document / recognize_document / extract_fields / query_result，与 REST 共用 services 业务层，双出口单一实现）；AG-UI 识别工作台（原计划二期，应要求提前——POST /agent/run 会话端点 + 规划器 + 三工具 + 可嵌入 React 工作台前端，三出口成型，见 3.7）。

不做（但接口预留）：跨引擎投票与复杂路由（二期）、智能体试点接入与 OAuth 对接（二期）、批量异步（二期）、训练流水线（三期）、消息队列（按需）、Redis（二期引入——一期限流用 PG 计数、引擎并发用 asyncio 进程内信号量）。一期与二期的切分是**“多引擎接入 → 多引擎协同决策”**：一期双引擎各自可用、类型声明三种基础模式（OCR 直出 / VLM 全读 / OCR 定位+VLM 精读），二期才有跨引擎投票这类组合决策。预留方式：编排引擎的引擎调用走适配器接口而非直连；融合器接口预留投票扩展点；结果模型字段（engines_used、needs_review）一期即落库。

3.2 工程结构

后端单仓（Python 3.12+，uv 管理）+ 两个独立前端工程：

idrp-backend/
├── server/            # FastAPI 应用：网关、管理 API、编排入口
│   ├── services.py    # 公共业务层：REST / MCP / AG-UI 三出口单一实现
│   ├── mcp_server.py  # MCP Server 独立进程（:8001/mcp，Streamable HTTP）
│   ├── api/           # REST 路由（/v1、/admin/v1）与 AG-UI 端点
│   └── agent/         # AG-UI 运行时：events / tools / runtime / api
├── core/              # 领域层：结果模型、类型引擎、编排状态机、融合器
├── adapters/          # 引擎适配器（paddleocr_vl + vlm）+ 注册表
├── preproc/           # 预处理：栅格化
├── eval/              # golden 集管理、准确率计算、门禁脚本
└── tests/             # 契约与流程测试（离线假引擎）

idrp-frontend/         # 管理台前端（Vue 3 + Vite：类型编辑/评测/发布门禁）
idrp-workbench/        # 识别工作台前端（React 18 + TS + AntD 5，可嵌入，见 3.7）

3.3 数据库详细设计（核心表）

延续规划方案 6.2 的域划分，一期落 7 张核心表（PostgreSQL，均带 created_at/updated_at）：

-- 文档域
documents(id, doc_id UNIQUE, source_caller, original_uri,   -- MinIO 对象
          mime_type, page_count, checksum, status)           -- uploaded/parsed/failed

-- 识别域
recognition_requests(id, log_id UNIQUE, doc_id FK, doc_type,
          doc_type_version, status,                       -- 见 3.9 状态机
          engines_used JSONB, latency_ms, error_code)
recognition_results(id, request_id FK, unified JSONB,        -- 统一结果模型全文
          field_count, review_count)

-- 证据域
result_blocks(id, request_id FK, page_no, block_type,
          bbox_norm JSONB,                                   -- 归一化坐标 [0..1]
          text, confidence, source_engine, artifact_uri)

-- 配置域
doc_types(id, doc_type, version, status,                      -- draft/released/deprecated
          definition JSONB,                                  -- 字段/提示词/版式先验/路由
          released_at)
engine_registry(id, engine_id, version, capabilities JSONB,
          endpoint, cost_profile, health, enabled)
golden_sets(id, set_id, doc_type, doc_uri, expected JSONB)
eval_runs(id, doc_type, doc_type_version, accuracy JSONB,
          passed, ran_at, trigger)                           -- ci/release/manual

3.4 统一结果模型定版（一期冻结内容）

以规划方案 3.2 的 JSON 为基线，一期补充冻结四点：坐标一律归一化到 [0,1]（相对页宽高，保留 4 位小数）；confidence 取值 [0,1]，未标定引擎给保守默认 0.5 并在 meta 标注 calibrated: false；block_type 词表一期含 text / handwriting / table / seal / figure / signature；fields[].value 统一字符串承载，数值与日期格式由类型 Schema 校验。定版后任何变更走大版本。

3.5 REST API 契约（一期）

错误码体系：4xx 消费方错误（INVALID_FILE、RECIPE_NOT_FOUND、QUOTA_EXCEEDED），5xx 平台错误（ENGINE_TIMEOUT、ENGINE_UNAVAILABLE、INTERNAL）；所有响应带 log_id；限流按调用方配额（一期以 PG 计数实现，二期 Redis 全局化）。

3.6 MCP Server（提前实现）

独立进程 server/mcp_server.py（uv run python -m server.mcp_server，默认 :8001，端点 /mcp），官方 MCP Python SDK（2.x MCPServer）+ Streamable HTTP 传输：

• 四个粗粒度工具：upload_document（base64 内容 → doc_id）、recognize_document（统一结果全文）、extract_fields（字段轻量视图）、query_result（历史查询）；
• 与 REST 共用 server/services.py 业务层——双出口单一实现，工具层只做协议适配不写业务；
• 工具 docstring 即 LLM 说明书（何时该用、参数含义、needs_review 提示），参数 schema 由类型注解自动生成；
• 错误契约与 REST 同构（error_code/error_msg 结构化返回，不抛协议错误）；
• 调用方鉴权与网关接入（OAuth 2.1 资源服务器语义）随二期智能体试点完善。

3.7 AG-UI 识别工作台（提前实现）

第三出口：面向终端操作者的对话式识别界面（规划方案 3.4）。后端 server/agent/ 四模块 + 独立前端工程 idrp-workbench。

后端（AG-UI 运行时）：

• 事件层 events.py：AG-UI 协议事件构造——RUN_STARTED/FINISHED/ERROR（生命周期）、TEXT_MESSAGE_START/CONTENT/END（流式文本，按块拆分）、TOOL_CALL_START/END（工具过程）、STATE_SNAPSHOT（状态快照），SSE data: 帧下发；
• 端点 /agent/run（agent/api.py）：接收 RunAgentInput（threadId、runId、messages、state），流式返回事件；X-Agent-Token 头做嵌入鉴权（骨架期全局 token，随调用方管理演进为按调用方签发的 JWT，携带用户/机构声明）；
• 规划器 runtime.py：默认规则规划器（离线可测：上传 → 选类型 → 识别 → 复核的会话状态机，类型词优先、上传通知重置残留状态、单轮动作数上限防失控），IDRP_AGENT_PLANNER=qwen 可切 LLM 函数调用规划（复用 VLM 通道）；
• 工具层 tools.py：list_doc_types / extract_fields / query_result 三工具——与 REST、MCP 调同一 services 业务层（三出口单一实现）；工具错误以结构化契约返回并转成可见文本事件；
• 交互细节：长耗时识别先发"正在识别"文本事件再执行工具（多页文档 1–2 分钟期间界面不失联）；每次识别的 fields/log_id 经 STATE_SNAPSHOT 下发驱动界面。

前端（idrp-workbench）：

• React 18 + TypeScript + Vite + Ant Design 5；自研 ~150 行 AG-UI 事件客户端（协议本身轻量，规避组件库 API 快速演进风险；后端是标准 AG-UI，可随时换 CopilotKit 等框架接入）；
• 会话界面：上传区（REST 拿 doc_id 进共享状态）→ 对话气泡（流式）→ 工具执行卡（进行中/耗时）→ 字段表（needs_review 高亮）→ 人工复核表单（复核意见作为新消息回传）→ 会话内识别记录（点击回看）；
• 嵌入契约：/workbench?token=… 注入凭证（localStorage + X-Agent-Token 头）；生产与平台服务同域部署，SSE 经代理需关闭缓冲（nginx proxy_buffering off）。

全屏打开 ↗

分期演进：二期补 postMessage 结果回传、按调用方/用户/机构的权限过滤（list_doc_types 只返回授权类型）、嵌入方自助接入；比对能力（compare_documents）落地后增设比对视图（同工程分流，见规划方案 3.4 视图拆分原则）。

3.8 管理端详细设计（一期最小集）

管理端服务平台运营方与接入人员，是文档类型化架构（规划方案 3.6）的运营界面。一期定位"最小但完整”：类型发布门禁的完整流程必须有界面，其余能力 API 优先、界面跟进。

功能模块（按优先级）：

管理 API（/admin/v1/*，与能力 API 隔离部署路径，独立管理鉴权）：

/admin/v1/doc-types          GET/POST/PATCH   类型草稿 CRUD
/admin/v1/doc-types/{id}/release   POST       发布（内部先触发评测门禁，未通过则 409）
/admin/v1/doc-types/{id}/rollback  POST       回滚至历史版本
/admin/v1/golden-sets      GET/POST         样本与期望标注管理
/admin/v1/eval-runs        GET/POST         评测触发与记录查询
/admin/v1/engines          GET/PATCH        注册表查看与启停
/admin/v1/callers          GET/POST/PATCH   凭证与配额
/admin/v1/requests         GET              审计检索（log_id / 调用方 / 类型 / 时间）

权限与留痕：角色三级——平台管理员（全部）/ 运营（类型 + 评测 + 审计）/ 只读；所有管理操作进审计日志（操作者、对象、前后版本）。发布即版本：每次发布生成不可变类型版本（含渲染后提示词快照），回滚 = 指向历史版本。

分期演进：二期增批量任务监控、MCP 调用审计、消费方自助接入流程（申请→审批→联调状态）；三期增 badcase 工作台（triage/分配/解决/验证）、训练流水线触发与灰度规则配置。

3.9 编排引擎运行时

请求状态机：pending → preprocessing → engine_calling → fusing → completed；异常路径 engine_calling --超时/重试耗尽--> degraded（降级为整图直读，结果标注 degraded: true）或 failed。异步执行用 FastAPI 后台任务 + PG 状态表（量级见规划方案 5.1，不引入分布式编排器），引擎并发用 asyncio 进程内信号量限流（多副本下为近似总量，一期规模可接受；二期引入 Redis 后全局精确）。needs_review 是字段级状态（投票不一致/低置信），不是请求级。

3.10 引擎适配器（PaddleOCR-VL 与 VLM）

PaddleOCR-VL 适配器三件事：能力声明（注册表登记 layout/text/handwriting 能力与成本画像）；协议适配（/layout-parsing 契约、参数透传——低阈值与关闭版面检测的手写召回参数封装为预处理策略）；结果归一（服务栅格坐标 → 归一化坐标；版面块标签 → 统一词表；无置信度时的保守默认与标注）。

VLM 适配器：OpenAI 兼容协议接入大模型平台；提示词由类型渲染器生成（模板与字段描述同版本，系统级指令由代码持有）；返回 JSON 修复与类型 Schema 校验；VLM 无原生置信度，融合器按"多次读取一致性"策略赋值（一期可先保守默认并标注 calibrated: false）。

两个适配器都必须通过 conformance test（标准样张进 → 统一结果模型 schema 校验 + 坐标/字段抽检）方可注册。

3.11 评测体系

• golden 集格式：每样本 = 文档对象 + 期望字段 JSON + 关键区块标注；一期每类型 ≥ 50 样本，覆盖典型/边界/低质量三类；
• 准确率口径：字段级完全匹配率为主指标，关键字段（金额、户名）辅以字符级差异率；needs_review 率单列；
• CI 门禁：类型发布与引擎版本变更必须触发 eval_runs，主指标不退化且无字段下降超阈值方可通过；门禁脚本进 CI 流水线。

3.12 一期部署清单

3.13 一期验收标准

① 首个消费方生产调用稳定运行 4 周（可用性 ≥ 99.5%，p95 ≤ 8s/单文档）；② golden 基线建立，准确率与复核率按周出数；③ 评测门禁在 CI 生效并拦截过至少一次违规发布（或演练验证）；④ 全部结果可经 log_id 回溯到证据裁片。

四、二期详细方案

• 智能体试点：MCP Server 已于一期实现（见 3.6），二期工作为试点接入星辰助手一个对话场景（凭证要素查询）、鉴权完善（OAuth 2.1 资源服务器语义）、网关/ESB 路由接入，以及 compare_documents 工具随比对大类补齐；
• 批量异步：/v1/batches（文档集 + 类型）→ 任务句柄 + 进度查询；PG 状态表 + 后台 worker，逐文档复用同步链路；
• 跨引擎投票：类型声明投票字段与引擎组合（如 PaddleOCR-VL + VLM）；投票算法首版先用字符级对齐取多数，不一致即 needs_review——宁可标记不裁断；触发条件由路由策略控制（关键字段或低置信字段）；
• 第二消费方接入：走标准 onboarding（申请凭证 → 选类型 → OpenAPI 联调 → 灰度 → 生产），沉淀接入手册。

五、三期详细方案

• 训练流水线：K8s Job 化——标注导出（badcase 台账 → 训练集）→ PaddleOCR 微调训练 → golden 全量评测 → 镜像构建（带版本 tag）→ 注册表更新；全程 Jenkins/ArgoCD 承载；
• badcase 运营：状态机 reported → triaged(定位: 数据/提示词/模型) → assigned → resolved(类型修复 | 微调排期) → verified；看板指标：闭环周期、badcase 存量、按类型分布；
• 灰度与回滚：新引擎版本按 model_version 参数灰度（5% → 50% → 100%），评测指标异常自动冻结灰度；回滚 = 注册表切回旧版本（镜像不可变）。

六、项目计划

6.1 里程碑时间线（相对周）

6.2 人力配置

6.3 外部依赖与协调

七、实施风险与应对

八、度量与验收汇总

2.5 - StarWork 桌面端技术架构

依据 star-work 仓库源码与 README.md 编制，与云控服务端架构互为表里：本文讲桌面端（终端），彼文讲服务端（治理）。文中四张图表均为交互式：支持缩放、语义视图、关系追踪与 PNG/SVG 导出。

一、项目概览

StarWork 是 AI 原生的企业级 Office 套件：一个桌面应用里装下文档、表格、演示、PDF、Markdown 五个编辑器，AI 与人工操作共用同一套文档模型——AI 能直接读写文档结构（改段落、改单元格、生成整套演示），而不是只在对话框里隔空聊天。打开和保存都是标准 Office 格式，不引入私有格式；本地功能不联网；AI 改动受代码级门禁约束。

二、总体技术架构

三层拼装：通用的 Agent 引擎负责「想」，成熟的编辑器负责「编辑」，自研的是把两者接起来并管得住的那一层。

全屏打开 ↗

• 统一外壳（自研 src/）：一个窗口 + 顶部标签页；首页工作台（会话、项目管理、记忆、设置）；Agent↔编辑器桥与工作区围栏；云控客户端；国际化与主题。
• Agent 层：第三方 pi-coding-agent SDK 承担推理与调度；自研的 workspace-jail 给全部会话套上文件/命令围栏，editor-bridge 为每个编辑器标签页注册领域工具。
• 编辑器层（自研应用层 + 文档引擎）：五个编辑器应用 + 14 个共享能力包；模型请求经模型网关（one-api 类）以 OpenAI 兼容协议转发，云控下发的网关根地址在客户端做 /v1 版本段幂等补全（model-url.ts），根治多实例网关偶发 404。

三、进程与运行时模型

全屏打开 ↗

• 一个主进程承载全部业务逻辑：五个编辑器的主模块都打包进同一个进程，窗口只有一个，靠标签页切换（tab-manager.ts）；
• 每个打开的文件新增一个界面视图（WebContentsView），首页不占独立视图——界面层进程数 = 1 + 打开的文件数，与应用个数无关；
• 真正的操作系统子进程只有一个：表格的 Rust 原生引擎 xlsx-sidecar，第一个表格打开时启动一次（带预热），之后所有表格共用，靠会话标识区分文件；
• 界面层拿不到文件系统与系统命令，所有文件读写与外部调用都经主进程受控执行，前后端走本机 IPC，不经网络。

四、编辑器与能力包

14 个共享能力包（packages/）按职责分四类：

五、AI 改文档的三条硬约束

这些约束不是提示词，是代码里的门禁。

5.1 演示：逐页生成与导出门禁

全屏打开 ↗

一句话任务进入后：附件与联网检索结果分配 [S#] 来源编号 → 大纲按页面角色逐页规划 → 模型流式生成语义 SVG（deck-stream）→ 每页过质量门禁（svg2pptx/quality.ts，与导出器共用同一渲染前端——凡是门禁放过的，导出器必然能渲染）→ 全套就绪后导出原生可编辑 PPTX，引用编号写入演讲者备注。

• 阻断项：页面角色缺失、元素越界、引用编号悬空 → 阻断导出；附件未读完 → 拒绝生成整套演示；
• 告警项：精确数字无来源 → 告警不阻断；
• 回归保障：127 份真实模板（decks/layouts/charts/tables）在 templates.test.ts 中持续验证产物一致性，改动导出器必跑。

5.2 表格：提议 → 预览 → 事务提交

AI 产出不直接改文件：先过 schema 校验 → 修订冲突检测 → 生成预览 → 使用者确认后才作为事务提交（apps/sheets/src/renderer/ai/ 的 response-verify / retry-prune / 编辑队列）。公式引用链可追踪审计（formula-audit）。大工作簿的内存占用与整表规模解耦、只与视口相关（架构如此，暂无实测基准）。

5.3 文档：按段落打补丁

docx-engine 以带 docxIndex 锚点的 Block 树解析 docx，保存时只重写 AI 实际动过的段落——样式、批注、页码等其余内容原样保留。

六、安全模型

• 工作区围栏（src/main/pi/workspace-jail.ts，1629 行）：全部 pi 会话共用；read/ls/grep/find/write/edit 路径越出工作区直接抛错，read 按扩展名分流——二进制文档经 file-parse 提取文本，图片保持裸字节交给多模态模型；
• 命令沙箱：macOS 用 sandbox-exec 硬沙箱（读写只放行工作区/临时目录/工具链缓存，$HOME 凭证目录不可读写）；Windows 无等价沙箱，用 spawnHook 命令级拦截（拦得住字面量，拦不住变量拼接）——如实说：强度低于 macOS；
• 网络：sandbox-net 沙箱代理受控放行；云控通道 TLS + 设备令牌；
• 委派（pi/delegate.ts）：把一整件事交给某个编辑器标签页的 agent 去办——模型只决定「目标应用 + 任务内容 + 源文件」，账号/会话/标签页寻址由主进程处理，领域工具与围栏在目标标签页那边。

七、云控通道

企业侧由云控承担：模型、配置、技能、版本、日志由服务端统一下发与回收，终端使用者不需要配置任何密钥。

全屏打开 ↗

客户端连接策略三阶段（src/main/cloud/client.ts）：启动期按内置清单轮询生产→准生产→测试入口（地址清单编译进 App，云控删不掉）→ 连上后按本地策略重连（间隔封顶 10s + 随机抖动）→ 连续失败够多次自动轮换候选入口。掉线判定由 socket error/close 驱动，睡眠唤醒后心跳失败主动 revalidate() 兜底 TCP 僵死的「假连接」。服务端侧协议与部署详见云控服务端技术架构。

八、工程与质量

• monorepo：根（外壳）+ apps/（5 编辑器，每个 = 主模块 + 界面层 + preload + shared）+ packages/（14 能力包），pnpm workspace；
• 开发形态：pnpm dev 并行起五个编辑器渲染服务（5173–5177，HMR）+ 外壳（首页 5199）；云控固定连本机 ws://127.0.0.1:8090；改主进程代码需重启 dev；
• 质量门禁：pnpm typecheck（主进程 + 首页 + 五编辑器）、ESLint + Prettier、vitest 单测分布在 apps/*/tests 与 packages/*/tests（实测合计 672 个 *.test.ts）；表格端另有 gate 全量门禁（typecheck + 夹具 + cargo test + 兼容性校验）；
• 运行期数据（开发形态）：~/Library/Application Support/StarWork Dev/（Windows %APPDATA%/StarWork Dev/）——home/projects.json（工作区）、app-settings.json、cloud-config.json、pi-sdk/models.json（云控下发的模型目录）、pi-sdk/sessions/ 与 home/pi-sessions/（完整对话与工具调用流水，排查问题先看这里）。

九、已知限制

2.6 - StarWork 云控服务端技术架构

依据 star-work-cloud 仓库源码与工程内文档（README.md / PROTOCOL.md）编制。文中四张图表均为交互式：支持缩放、语义视图、关系追踪与 PNG/SVG 导出。

一、项目概览

star-work-cloud 是桌面端（StarWork / Milo 客户端）的云控服务端：单个 Go 进程同时对外提供两条服务，共用一份 PostgreSQL 与同一套业务层。

代码采用经典分层：handler（解析请求/统一响应）→ service（业务逻辑）→ repository（数据访问）→ model（GORM 模型）；云控长连接独立成 internal/cloud（信封、会话表、topic 注册表、分片下发），TLS 治理在 internal/tls，后台巡检在 internal/worker + internal/leader（PG advisory lock 选主）。

二、总体架构

单进程内三个协作者：TLS 长连接服务（握手 / AUTH / 信封协议 / 会话表）、HTTP API（JWT + casbin 鉴权的 10 组管理接口）、后台巡检 Worker（心跳、补推、归档、选主）。入口分两条：设备走 L4 直达（NodePort / LB 的 TCP 8443，HTTP Ingress 无法转发 4 层 TLS），管理端走 Ingress 的 /starwork/api 前缀；前端 SPA 与后端同源部署，刻意不配置 CORS。

全屏打开 ↗

三、统一信封协议（Protocol v1）

一套信封覆盖上报 / 下发 / 配置同步 / 心跳，传输与业务分离：信封（怎么传）一次写死，业务能力以 topic 扩展——新增功能 = 注册表加一行 + 两端各一个处理函数，协议本身不动。

可靠性三件套：幂等（客户端记录已处理 id，重复消息直接 ack）、应答超时重试（按 meta.timeout/retry 重发，只补发未确认分片）、大 payload 分片（meta.seq/total 重组，可选 gzip 压缩）。

四、配置同步与定向下发

配置是云控的自举基座——客户端连接地址本身就在配置里，因此「地址可远程更新」是第一需求。服务端维护全局配置表（configs：每份配置独立 configId 与单调递增版本号，不按用户区分），客户端本地原子持久化（cloud-config.json），启动 / 重连必执行 config.sync 对账。

全屏打开 ↗

三个核心设计：

1. 双通道兜底：config.push（服务端定向推送，在线即时生效）+ config.sync（客户端拉取，离线攒下的新配置上线即补）。配置类消息靠 sync 全量对账兜底，离线队列只保留给一次性指令（重启、升级等）。
2. 全量下发 + 按字段合并：服务端始终下发完整配置对象，客户端按顶层字段合并（收到覆盖、未收到保留）。自带自愈——任何丢失或本地文件损坏，下次连接全量对账即恢复；配合原子写（临时文件 + rename）与版本守卫（旧版本拒绝覆盖新版本）。
3. 定向匹配：to 描述支持 platforms / deviceIds / minVersion 的 AND 组合——同一账号的 mac 更新只命中 mac 设备。每次下发落 config_deliveries + 逐设备明细（msg_id 关联 ack，状态 pending / delivering / done / failed），删除下发记录即撤销。

五、技能包与版本包分发

技能（zip，内含 SKILL.md）与版本安装包共用同一套 TLS 分片分发套路：base64 分片（128KB 原始字节/片）、共用命令 id 幂等、收齐重组后与元信息 sha256 强比对。设备端不暴露公网下载地址，HTTP 下载接口仅限管理端（JWT）。

全屏打开 ↗

关键防线与落地策略：

• 版本更新走配置携带：release 表（version / platform / arch / sha256）绑定到配置，随 config.push / config.sync 全量下发；客户端做平台/架构匹配（不符不弹窗）、版本比较（不高于当前忽略）、单会话去重后才弹确认窗。
• 技能按 category 六类落盘：global（全部编辑器）/ docs / sheets / slides / pdf / markdown 各自目录，非白名单取值兜底为 global；同目录原子替换 + .cloud-skill.json 登记，装完即用无需重启；后台改分类后，已装设备「更新」时自动迁移目录并清旧副本。
• 解压安全：防 zip-slip 路径穿越、校验 SKILL.md 必须存在，非法即回滚。

六、设备连接生命周期

连接治理三参数：握手读超时（10s）、空闲读超时（600s）、并发连接上限（默认 10000）；可选 DEVICE_AUTH_SECRET 二次鉴权。心跳按连接时长四阶段退避（15s → 30s → 60s → 5min），在线判定随策略动态计算：now - lastSeen < onlineTimeoutFactor × 当前阶段期望间隔（默认 2 倍系数）——Dashboard 不写死超时窗口，直接消费服务端状态字段。

全屏打开 ↗

七、数据模型

16 张业务表 + casbin 策略表，全部 GORM AutoMigrate 自动建表，无外键约束（运维规范），关联仅应用层维护：

八、安全设计

启动强校验（不满足直接退出）：JWT_SECRET ≥ 32 字符且非默认值；DATA_ENC_KEY 必须为 base64 的 32 字节。登录密码经 RSA 公钥加密传输（/auth/public-key 分发公钥，私钥服务端持有，生产务必挂载固定私钥文件）。设备侧可选 AUTH 二次鉴权；上传体积（UPLOAD_MAX_MB）与连接治理参数防滥用。刻意不配置 CORS：前后端同源部署于同一 Ingress host（/starwork 前端 SPA、/starwork/api 后端），浏览器只见一个 origin。

九、部署架构

• 镜像：CGO_ENABLED=0 静态二进制（amd64 / arm64 交叉编译），builder golang:1.26.3 + runtime alpine:3.12；vendor/ 入库离线构建（-mod=vendor），构建机无外网可编译。alpine 无 tzdata，二进制内嵌 time/tzdata 支撑 DB_TIMEZONE=Asia/Shanghai。
• K8s（Helm）：两端口同 Service（tls 8443 / http 8090，ClusterIP）；/app/data（上传包、归档、RSA 私钥）挂 PVC（nfs-client 动态供给，20Gi RWO）；8443 证书由 chart 建 Secret、流水线 --set-file 注入；JWT_SECRET / DATA_ENC_KEY 必须环境变量注入。
• Ingress 三前缀（最长前缀优先）：/starwork/api → 后端 8090；/starwork → 前端 SPA；/admin/static → 前端旧入口（301 到 /starwork/）。
• CI/CD：Jenkins 三环境流水线（sit / uat / prd：拉码 → make release-image.amd64 构图推 Harbor → Helm 部署）；敏感参数 sit 明文 / uat·prd 打码。

多副本就绪

设备长连接只在持有它的副本内存里，方案是不让副本共享会话（那要 Redis），每个副本自扫 + DB 兜底：

十、已知约束与演进

1. scripts/docker-deploy.sh 依赖的 docker-compose.yml 尚未入库。
2. builder 镜像 golang:1.26.3 tag 需 DevOps 在 Harbor 确认或新建。
3. vendor/ 约 270 MB（含已不被引用的 sqlite 依赖），清理需外网重跑 go mod vendor，或改私有 proxy。
4. 8443 需运维单独放通（NodePort / LoadBalancer / TCP 转发其一），HTTP Ingress 转发不了 4 层 TLS。
5. Ingress 的 serviceName 与前端仓库耦合（/admin/static 指向 star-work-cloud-front），改 release 名需两边同步。
6. 路由前缀 /staroffice → /starwork 的旧库迁移已自动化：种子菜单就地更新、casbin 旧前缀策略清理、接口条目按新路由重建，旧库重启即自动跟上。