mini-openclaw/兴邦金租Agent方案决策记录.md

兴邦金租 Agent 方案决策记录

本文档记录讨论中已经敲定的产品决策、开发要求和待确认事项。开发时以最新记录为依据。

一、共同前提

已确定

• 系统最终部署在兴邦金租服务器及内网环境中。
• 最终接入兴邦认可的本地模型，业务数据不发送到外部模型服务。
• 当前阶段先验证业务方案可行性，再进入正式开发。
• 当前讨论的四个 Agent 为：风险研判助手、报告助手、评审调配助手、保单条款智能核验助手。

二、风险研判助手

2.1 定位

风险研判助手服务于兴邦对公项目的风险识别。它从现有 ERP 和关联材料中获取项目事实，对照兴邦规则、历史经验和相似案例，输出有证据的风险项、数据缺口和建议核查动作。最终判断仍由业务人员或主审员作出。

2.2 ERP 数据接入方案

已确定

• 不要求兴邦改变现有 ERP 数据库结构。
• 在风险研判助手中提供数据源、SQL 查询模板及字段映射的配置功能。
• 配置工作由兴邦 IT 或被授权的系统管理员完成；普通业务人员不填写数据库连接信息，也不编写 SQL。
• 业务人员通过客户或项目编号选择项目，一键取得研判所需数据。
• 一个业务主题配置一个查询模板，例如项目基本信息、客户信息、财务报表、征信、集团关系、担保、租赁物和历史审批记录；不强制使用一条大型 SQL。
• SQL 使用预先审核、发布的只读参数化查询。模型不得生成 SQL 后直接执行，也不得自由浏览数据库。
• 查询结果通过字段映射转换为风险研判助手的统一业务数据结构。字段映射需要包含字段含义、数据类型、单位、报表期间和财务口径。
• 数据库中如只保存附件地址，系统需要按权限读取关联的尽调报告、审计报告、合同、保单等文件。
• 每次研判保存数据快照、查询时间、项目编号、数据源、查询模板版本和字段映射版本，以便复核和追溯。
• 未查询到的数据标记为“缺失或未接入”，不得解释为“无风险”。

开发所需配置对象

1. 数据源：名称、数据库类型、内网地址、端口、数据库名、只读账号、加密保存的凭据、连接参数。
2. 查询模板：业务主题、参数定义、SQL、超时时间、最大返回行数、允许使用的库表或视图、版本及发布状态。
3. 字段映射：源字段、标准字段、类型、单位、口径、是否必填、转换规则。
4. 附件映射：附件类型、文件标识或路径字段、读取方式、项目关联键。
5. 测试与发布：连接测试、参数样例、结果预览、缺失字段检查、管理员确认、版本发布和回滚。

2.3 建议纳入的核心功能

以下功能建议进入风险研判助手的产品范围，具体优先级仍待逐项确认。

A. 数据准备与质量检查

• 项目材料完整性检查：按项目类型显示必需、已取得、缺失、过期和待补正材料。
• 数据质量检查：识别空值、重复记录、单位混用、期间不一致、异常值及主表与附件之间的矛盾。
• 多期财务数据标准化：统一合并/母公司口径、币种、金额单位和会计期间，再进行同比和趋势分析。
• 数据新鲜度提示：明确征信、诉讼、财报、工商和舆情数据的取得时间，过期数据不参与“无异常”判断。

B. 可解释的风险研判

• 确定性指标计算：资产负债率、流动比率、利息保障倍数、现金流覆盖等由 Python 计算，不交给模型心算。
• 可配置规则库：每条规则包含适用行业、适用项目类型、阈值、严重程度、生效日期、制度依据和版本。
• 事实、规则、模型分层：事实由 ERP/附件提供，指标和规则由程序计算，模型负责归纳、解释和提出核查建议。
• 每个风险项附证据：显示源系统、字段或文件页码、原文片段、数据时间、计算公式和引用规则。
• 区分“已确认风险”“待核查疑点”“信息缺失”，避免把缺少材料误判为客户存在问题。
• 支持人员修正：主审员可以确认、驳回、调整等级或补充说明，所有修正保留记录。

C. 历史经验复用

• 相似案例检索：结合行业、客户规模、授信金额、财务特征、租赁物和风险标签检索历史项目。
• 历史案例只展示有权限访问且已完成脱敏或授权的数据，并说明相似依据，不直接照搬历史结论。
• 专家经验沉淀：把人工确认后的风险判断、处置措施和最终结果形成可检索经验。
• 反馈闭环：记录风险提示是否被采纳、最终审批结论及后续表现，用于评估规则有效性；不能让模型未经审核自动修改正式规则。

D. 业务操作体验

• 项目选择后一键研判，页面先显示数据是否齐备，再允许生成风险报告。
• 允许按财务、征信、集团关联、担保、租赁物、行业等主题查看风险。
• 支持从某个风险项回到原始数据或附件证据。
• 支持重新取数并比较两个研判快照，显示新增、消失和等级变化的风险。
• 将确认后的结构化研判结果提供给报告助手，避免再次录入项目事实和风险内容。

2.4 不建议采用的做法

• 不让客户经理或主审员配置数据库和 SQL。
• 不让大模型直接连接生产数据库或执行自由生成的 SQL。
• 不只输出一段无法追溯来源的自然语言报告。
• 不把硬性指标、金额和评分计算交给大模型完成。
• 不把查询失败、字段缺失或附件未读取解释成“检查通过”。

2.5 GitHub 调研参考

• Vanna：参考数据库语义层、受控查询与问数交互；本项目不采用模型自由执行生产 SQL。
• SQLBot：参考数据源配置、数据集管理和面向业务用户的查询体验。
• Great Expectations：参考数据质量规则、验证结果和批次证据管理。
• OpenMetadata：参考字段含义、血缘、数据责任和数据新鲜度管理。
• Open Policy Agent：参考规则与业务代码分离、规则版本化和可测试决策。
• Langfuse：参考模型调用追踪、版本、评价和反馈闭环。本地部署时仍需按兴邦权限要求裁剪日志内容。
• PrivateGPT：参考本地模型和私有文档检索的部署方式。

2.6 待确认事项

• 风险研判助手一期的主要用户是客户经理、主审员，还是两者分别提供不同视图。
• 一期优先接入哪些业务主题和附件类型。
• 兴邦现有数据库类型，以及是否已经提供只读视图或数据仓库接口。
• 兴邦是否允许本系统直接读取附件存储，还是只能通过 ERP 接口获得附件。
• 正式规则由哪个部门维护、审核和发布。
• 风险研判结果是否需要回写 ERP；如果需要，采用接口回写还是人工导出后上传。

三、报告助手

3.1 定位

报告助手不只是把文字写成 Word，而是把已取得的项目事实、风险研判结果和评审员判断，整理成正式评审材料，并将经过人工确认的项目判断沉淀为可复用的经验卡。

3.2 已确定的双输出

每次完成评审报告，系统同时形成两类输出：

1. 正式报告：供评审员修改、定稿、上会和归档，可按兴邦模板导出 Word 或其他正式格式。
2. 项目经验卡：供后续风险研判和相似案例检索，记录项目特征、客观风险事实、规则依据、评审员判断、缓释措施、方案调整、审批结果和后续实际表现。

报告不是知识库的原始单位。只有经过确认的“事实、风险、判断、措施、结果”才进入共享经验库。

3.3 经验卡确认与生命周期

已确定

• 系统可以从报告和研判结果自动提取经验卡草稿，但不得自动将其视为正式公司经验。
• 主审员在报告定稿时确认或修改核心风险、事实依据、判断理由、缓释措施、额度/期限/报价/担保调整和审批结果。
• 高金额、高风险或有争议的案例，由评审部门负责人进行二次审核。
• 审批结论和租后结果持续补充到经验卡，包括正常还款、逾期、提前结清、出险和损失等。
• 经验卡状态为：草稿 → 主审员已确认 → 部门审核 → 可检索 → 已验证 → 已过期/归档。
• “可检索”与“已验证”分开。审批通过后可作为参考，经过租后观察并有明确结果后，才能标记为已验证案例。
• AI 可以提取、整理和推荐经验卡，但不能自动把个案经验改成正式制度规则，也不能未经人工审核修改规则。

3.4 不要求定期重写全部经验卡

评审员不需要定期给所有经验卡重新写评审意见。采用“项目结束沉淀、关键节点复核、定期批量治理”：

• 项目评审完成时：主审员确认一次经验卡关键字段。
• 发生重大变化时：补充复核，例如新增诉讼、被执行、逾期、违约、出险或重大方案调整。
• 每月：处理新生成且待确认的经验卡。
• 每季度：复核高频使用、重大金额、高风险或争议案例。
• 每年：清理过期案例，并根据制度变化更新适用期限和状态。

3.5 经验卡建议结构

项目特征:
  行业:
  客户规模:
  授信金额:
  租赁模式:
  租赁物:
核心风险:
  - 风险类型:
    客观事实:
    数据来源:
    规则依据:
    主审员判断:
    缓释措施:
方案调整:
  原申请额度:
  审批额度:
  期限变化:
  报价变化:
  担保和保证金条件:
审批结果:
租后结果:
验证状态:
适用范围:
确认人和版本:

3.6 角色分工

角色	责任
主审员	确认具体项目的风险事实、判断和处置逻辑
评审部门负责人	审核高金额、高风险或争议案例
风险管理部门	维护正式制度规则，区分制度与个案经验
租后人员	补充还款、逾期、出险和损失结果
系统管理员	管理权限、版本、检索、归档和审计

3.7 报告助手一期工作链

选择项目 → 读取已确认数据和研判结果 → 选择兴邦报告模板 → 分章节生成 → 主审员补充判断 → 事实与数字一致性检查 → 主审员定稿 → 提取经验卡 → 主审员确认 → 审批结果回写 → 租后结果补充

3.8 关键约束

• 报告助手不能为了填满报告而编造事实；证据不足时必须显示待核实或缺失。
• 金额、日期、期限、比例和评级等关键字段优先从结构化数据和确定性计算结果带入。
• 主审员已经确认的内容，模型再次生成时不得无提示覆盖。
• 经验卡只向有权限的用户和业务域开放，并保留来源、确认人、版本和审计记录。

四、评审协同助手

4.1 定位

将原“评审调配助手”扩展为评审协同助手。它既辅助评审秘书分配项目，也跟踪项目为什么等待、由谁处理、还缺什么材料，以及数据和方案变化影响了哪些评审结论。

4.2 建议功能范围

1. 主审员推荐：依据行业经验、在手项目的数量和复杂度、历史处理时间、人员可用状态及回避要求推荐人选，由评审秘书最终确认。
2. 项目任务卡：显示当前节点、负责人、等待时间、阻塞原因、下一步、未确认风险和数据更新时间。
3. 补件闭环：风险项可以转为补件任务，记录所需材料、责任人、截止时间及处理状态。区分“文件已上传”和“问题已解决”，风险关闭必须由主审员确认。
4. 方案版本管理：记录额度、期限、报价、保证金、担保等方案变化。
5. 变更影响分析：数据或方案变化后，提示需要重算的指标、需要复核的增信条件及需要更新的报告章节。
6. 上会前摘要：汇总当前方案、历史变化、未关闭风险、补件情况、数据截止时间和需要委员会重点讨论的问题。

4.3 建议状态

待分配 → 待资料初检 → 待补件/待现场核查 → 待财务分析/测算 → 待主审员意见 → 待部门复核 → 待上会 → 已完成

补件任务状态为：待提交 → 已提交待检查 → 检查不通过 → 待主审员确认 → 已解决/继续追问。

4.4 一期实施边界

• 一期作为 ERP 旁边的辅助工作台，通过只读 SQL 获取项目和人员状态。
• 协同任务、补件关系、风险关闭和版本变化先保存在本系统数据库。
• 正式项目分配和审批仍由 ERP 完成；验证价值后再决定是否回写 ERP。
• 系统辅助检查材料是否对应和是否包含必要内容，问题是否关闭由主审员决定。

4.5 待确认事项

• 兴邦现有 ERP 能提供哪些项目节点、处理人和时间字段。
• 主审员负荷是否能从 ERP 实时取得，以及复杂度如何定义。
• 补件材料由本系统接收，还是继续上传 ERP 后由本系统读取。
• 上会前摘要的正式模板和必看项目。

五、租赁物与增信措施核验助手

5.1 定位

将原“保单条款智能核验助手”升级为租赁物与增信措施核验助手。它回答：当前项目依靠哪些资产和增信措施控制风险，这些措施是否真实、有效、足额、可执行，并且是否与当前授信方案一致。

5.2 建议功能范围

1. 租赁物适格性核验：检查租赁物类型、可识别性、权属、型号数量、序列号、购买关系、权利限制、登记及处置条件。
2. 跨材料一致性核验：比对 ERP、租赁物清单、采购合同、发票、评估报告和现场材料中的名称、数量、价格及标识信息。
3. 价值覆盖与情景分析：由 Python 计算租赁物价值、授信覆盖率，并展示不同折价情景下的可处置价值和风险敞口。
4. 保单实质核验：OCR 提取保单和批单信息，检查保险标的、险种、保额、期限、受益人、免赔、赔偿上限和除外责任；每个问题定位到文件、页码和原文。
5. 担保与保证金核验：检查保证人代偿能力、担保额度和期限、抵押/质押登记、重复抵押、保证金比例和余额，避免重复计算同一风险来源。
6. 方案变更联动：额度、期限或其他条件变化后，自动提示需要重新核验的覆盖率、保额、保险期限、保证金、担保合同和登记材料。
7. 投放前条件清单：形成已满足、待补充、待登记、待人工核验、不一致和已失效的检查结果，供放款管理岗确认。

5.3 核心亮点

建立“风险缓释有效性视图”，把租赁物、保险、保证金、保证人、抵押和质押统一放到当前项目方案下，说明风险发生时依靠什么回收、措施能否执行，以及不同折价情景下剩余的风险敞口。

5.4 关键约束

• 保额、险种、除外责任和增信要求由兴邦配置并发布版本，不由开发方根据会议讨论写死。
• OCR 置信度不足或条款存在歧义时必须转人工复核。
• 每项核验结论需要保留原始文件、页码、原文、规则版本、计算过程和确认人。
• Agent 提供检查结果和待办条件，是否允许投放由有权限的业务人员决定。

5.5 待确认事项

• 不同租赁物类型的适格性和价值覆盖规则。
• 保单必备险种、保额、期限、受益人、免赔及除外责任规则。
• 担保、抵押、质押、中登登记和保证金的正式核验清单。
• 一期优先做保单核验，还是同时覆盖租赁物和其他增信措施。

六、四 Agent 的职责边界与闭环

6.1 职责边界

• 风险研判助手：项目有哪些风险，证据是什么，缺少哪些信息。
• 评审协同助手：风险处理到哪一步，谁需要做什么，变化影响了什么。
• 租赁物与增信措施核验助手：用于缓释风险的资产和措施是否真实、足额、有效、可执行。
• 报告与经验沉淀助手：如何把确认后的事实和判断形成报告，并沉淀为可复用、可验证的经验。

6.2 业务闭环

ERP/附件取数 → 风险研判 → 补件和评审协同 → 租赁物与增信核验 → 报告及上会材料 → 经验卡 → 审批和租后结果回写 → 已验证经验支持新项目

6.3 重点展示场景

1. 前置风险筛查：业务经理选择项目，系统从 ERP 取数并列出风险、缺件和证据，不代替评审员下结论。
2. 方案变化联动：额度、期限或报价变化后，自动标识需要重新测算、复核和更新的内容。
3. 风险缓释有效性：统一展示租赁物和各类增信措施在不同情景下的覆盖能力。
4. 经验验证闭环：主审员确认判断，审批和租后表现持续回写，区分历史审批经验和后来实际结果。

七、总体审阅结论

7.1 可行性判断

• 四个 Agent 覆盖会议明确提出的前置风险共识、看资料/做测算/写报告、人员紧缺和项目等待、方案反复调整、租赁物和保险实质核查、个人经验沉淀等对公痛点。
• 四个 Agent 可以形成完整链路，职责边界清楚，业务方向合理。
• 亮点应来自数据证据链、方案变化联动、风险缓释有效性和经验结果验证，而不只是模型对话或 OCR。
• 当前产品框架可以确定；正式开发前仍需取得兴邦的字段口径、规则、材料清单、报告模板和权限要求。

7.2 共同设计原则

• 事实来自 ERP、附件或已授权数据源；确定性计算由程序完成；模型负责整理、解释和辅助建议。
• 缺失数据不等同于无风险，所有结论必须能够返回来源证据。
• Agent 不代替客户经理、主审员、评审秘书、部门负责人或放款岗作出正式业务决定。
• 四个 Agent 共用项目数据、风险项、补件任务、方案版本和经验卡，不形成四套相互隔离的数据。
• 先作为小工具验证个人和短流程效率，再逐步与 ERP 流程集成，符合会议提出的分步实施思路。