这个矛盾会导致三种典型结果同时存在：
整个供应商相关的业务，由两条并行的主线构成。供应商在线一里"进入系统"，在线二的关键节点被反复"使用"，每次使用都会触发对集团火眼的风险扫描。
| 节点 | 业务动作 | 风险扫描行为 |
|---|---|---|
| 采购对接供应商 | 采购同学线下与供应商谈合作意向，确定要不要邀请其入库。 | 无系统行为。 |
| 入库 OA 流程 | 分管理方走三套独立流程：控股、AIDC、菜鸟。每套流程的审批节点和填报字段不同。 | OA 完成时，第一次调用火眼，作为基线扫描。 |
| 淘汰 / 重启 | 已淘汰供应商再次启用走独立的"重启"OA 流程，避免与新入库混淆。 | 重启时重新扫描（数据可能已大幅变化）。 |
| 业务方提需求 | 业务方告诉采购"我要买什么"，此时通常不带供应商。 | 无扫描。 |
| 采购申请 | 采购同学根据业务需求形成申请单。绝大多数不指定供应商，少数走"指定材料"。 | "指定材料"分支会触发扫描，因为此刻已锁定特定供应商，需重判风险。 |
| 招标 / 报价 | 邀请几十到几百家候选供应商参与投标报价。 | 批量扫描，对所有候选供应商重新跑一遍火眼。 |
| 中标定标 | 从候选池中筛出最终合作的几家。 | 对中标方再扫一次（距离上次扫描可能数日到数周）。 |
| 合同签订 | 与中标方签订正式合同。 | 最后一道闸，合同前必扫。 |
真正的问题不在火眼本身，而在火眼返回结果之后，系统是怎么处理的。下图是当前实际链路：
规则覆盖：失信被执行人、被列入经营异常、行政处罚、税务监管、出口管制、司法判决、关联方风险等。每条规则不分轻重——失信 90 块和失信 9000 万都同样输出"高风险"标签。
这是过去做的产品形态，挂在业务单据右侧，展示火眼命中的具体规则和"建议报备"等说明文案。它只展示，不卡控。
当前实现是：点击按钮跳转一个钉钉文档；文档里按"控股/AIDC/菜鸟"分别维护了一组报备入口链接；用户自己找到对应链接，再跳到 BPMS 审批表单。
BPMS 审批层级由风险类型决定：行政处罚类 → 法务审批；出口管制类 → 合规/海关相关审批；以此类推。最少 1 级，最多 3 级。整个走完平均天级，快则当天、慢则跨周。
没有。BPMS 审批通过与否，业务系统全程不知。"应报已报"靠用户回到业务单据手动勾选一个"历史已报备"的标记。
上面的链路里，每一处问题都不是孤立的，背后都有一个共同的根因。
| # | 问题 | 表象 | 根因 |
|---|---|---|---|
| R1 | 报备结果不回写 | 业务系统不知道用户报没报备、审批结果是什么 | BPMS 审批和业务系统是两套系统，无数据回流通道 |
| R2 | 报备入口分散 | 用户要打开钉钉文档自己找链接，三个管理方各一套 | 报备入口是文档级维护，不是产品级路由 |
| R3 | 风险规则颗粒度粗 | 52 条规则不分轻重，触发率高、误报多 | 火眼面向集团通用场景，不会为采购单独细化 |
| R4 | 无业务侧二次判定 | "火眼说有风险"=="业务系统说有风险" | 缺少介于"原始风险数据"和"业务决策"之间的判定层 |
| R5 | 历史报备靠人工勾选 | "我之前报过"全凭用户记忆，无法精确到事件维度 | 报备没有按"供应商+风险事件"建模，只是单据级标记 |
| R6 | 审批靠人养 | 一单天级，断头单堆积，需要提报人主动催 | 审批流没有 SLA、没有自动升级、没有看板 |
| R7 | 风险监控只在触点 | 合同签完之后供应商出风险，业务系统不会主动发现 | 没有持续监控（continuous monitoring）机制，扫描只发生在节点上 |
所有问题指向同一个结构性缺失：
火眼（数据/规则原始层） ━━ ？？？ ━━ 业务单据（决策层）
当前架构里，火眼的输出直接顶到了业务决策上。中间没有一层负责"翻译"：把通用的工商风险信号翻译成"对采购业务到底意味着什么"。
这一层在行业里有标准叫法：Supplier Risk Intelligence Layer（供应商风险情报层）。它做的事情是吸收外部数据源、按业务规则二次评分、输出业务可执行的风险结论。
供应商风险管理（Supplier Risk Management，SRM）在大型企业里是个成熟领域。下面看几个公开资料里能查到的标杆做法，重点不是它们的产品功能，而是它们的架构思路。
SAP 的供应商风险产品，集成 Dun & Bradstreet、RepRisk、EcoVadis 等多源数据。核心架构是三层分离：
Coupa 的差异化点是"持续监控"+"风险水位"。供应商一旦入库，平台就持续订阅其外部信号变化（诉讼、负面舆情、财务异常），按多因子叠加算出风险评分。任何评分跳变都会触发业务流程。
Oracle 的做法强调"业务规则可配置 + 流程嵌入"。风险评估不是独立模块，而是嵌入到 Sourcing、Contract、PO 各环节。每个节点都有自己的"准入条件"，未达条件单据不能往下走。
国内大型采购平台普遍采用"基础风险源 + 业务白名单"：天眼查/企查查/启信宝提供原始数据，平台自建一层规则引擎做白名单豁免、行业差异化处理。例如制造业供应商对环保处罚敏感，IT 供应商则更关注信息安全资质。
独立 GRC 厂商的做法更偏"事件化"：每一条风险都建模成"事件"，事件有生命周期（发现→评估→处置→关闭），有归属人、有 SLA、有审计轨迹。报备和审批是事件处置的一部分，所有动作都回写到事件上。
虽然不是采购，但"风险规则二次判定"这件事金融业做了几十年。典型范式：外部黑名单（OFAC、PEP）只给原始命中，银行内部有"调查工作流"决定是否真的拦截/上报。这个范式跟采购的"火眼+业务判定"几乎一一对应。
把上面六个标杆放在一起看，能看到五条共性模式：
| 模式 | 含义 |
|---|---|
| P1 · 数据源与判定层分离 | 外部数据源（火眼、邓白氏、OFAC）只负责"原始信号"；业务侧自建判定层做翻译。这是几乎所有标杆都遵守的架构红线。 |
| P2 · 持续监控而非触点扫描 | 供应商入库后系统订阅其变化，主动推送，而不是只在合同前扫一次。Coupa、SAP Ariba 都把这个作为核心卖点。 |
| P3 · 多因子叠加 + 风险水位 | 单一规则不上钩，多个低风险因子组合提升水位。这正是火眼 52 条要扩展为 200+ 条业务规则的方向。 |
| P4 · 事件化建模 | 每个风险是一个有生命周期的事件，报备和审批是事件处置环节，所有动作回写事件，可追溯。 |
| P5 · 流程嵌入式卡控 | 风险评估嵌在采购各业务节点（申请、招标、合同），不是旁路提醒，而是"未达条件不能继续"。 |
把当前现状放到上面五条模式里逐一对比：
| 能力维度 | 行业标杆做法 | 当前现状 | 差距 |
|---|---|---|---|
| P1 数据源/判定层分离 | 独立判定层，业务规则自治 | 火眼结果直接顶到业务决策，无独立判定层 | 缺失 |
| P2 持续监控 | 订阅式实时变更推送 | 只在节点扫描，节点之间盲区 | 缺失 |
| P3 多因子叠加 | 风险水位+因子组合 | 52 条规则单独触发，无叠加 | 部分 |
| P4 事件化建模 | 每条风险是独立事件，有生命周期 | 报备只是单据级标记，无事件实体 | 缺失 |
| P5 流程嵌入式卡控 | 未达条件单据不能继续 | 风控助手只展示不卡控，应报未报照样能走 | 部分 |
| 报备入口产品化 | 系统内一键报备，路由由系统决定 | 跳转钉钉文档，用户自己找链接 | 缺失 |
| 审批 SLA 和看板 | 超时自动升级、看板实时可见 | 靠提报人催，无 SLA | 缺失 |
| 外部数据接入 | 多源（信用/司法/财务/ESG/合规） | 火眼一个数据源 | 部分 |
| 触点扫描 | 节点必扫 | 已实现（入库/指定/招标/中标/合同） | 达成 |
| 外部数据集成 | 有 API 接入 | 火眼接入已跑通 | 达成 |
当前流程的本质问题不是"火眼不准"，而是"火眼之后是真空"。
火眼这层做得到的事情，在行业里叫"数据接入层"，本来就只该负责给原始信号。 而真正决定业务体验的"判定层 + 事件层 + 闭环层"，目前在采购系统里都没有独立存在，它们要么散落在用户的人工判断里，要么散落在钉钉文档里。
| 风险 | 等级 | 说明 |
|---|---|---|
| 合规暴露 | 高 | 应报未报无法识别，一旦真出事，无法证明流程尽责 |
| 业务效率 | 高 | 大量误报+人工跳转钉钉文档，单据流转效率低 |
| 数据资产沉淀 | 中 | 报备和审批数据散在钉钉，业务系统拿不到，无法做风险画像和复盘 |
| 用户体验 | 中 | 用户既要做判断又要找入口，疲劳累积 |
| 跨管理方一致性 | 中 | 控股/AIDC/菜鸟三套独立维护，规则不一致，跨方协作困难 |
诊断指出，缺的是"火眼之后的判定层 + 闭环层"。后面两章先把变化讲清楚：八做前后流程对比；九讲当前阶段怎么走，用 Web Agent 把判定、分流、外部 BPMS 审批整套链路代跑起来。
在写方案之前，先用一张对照图把变化讲清楚：原来怎么跑，改造后怎么跑。
| 维度 | Before · 现状 | After · 改造后 |
|---|---|---|
| 风险扫描 | 仅节点触发，节点间盲区 | 节点触发 + 系统定期扫存量（终极态） |
| 风险判定 | 火眼一锤定音，52 条规则不分轻重 | AI 业务判定层二次分流：无风险/真有风险/已报备 |
| 报备入口 | 跳钉钉文档，按管理方人工找链接 | 业务系统内一键，Agent 自动接管 |
| 审批跑流 | 人工跑 BPMS 审批，天级 | Web Agent 以业务方身份代跑，分钟级 |
| 业务方角色 | 操作员：找入口、填表、催审批 | 知情人 + 确认人：被通知、点确认 |
| 状态回写 | 无，业务系统不知道结果 | 全程回写，单据状态实时可见 |
| 历史报备复用 | 用户自觉勾选，颗粒度模糊 | 系统按"供应商+风险事件"自动识别 |
| 业务节点速度 | 每个节点都被风险扫描卡住 | 有效期内复用档案，不重扫不阻塞（终极态） |
当前阶段不动外部系统（火眼、BPMS 审批仍维持原状），改造点全部落在业务系统侧：在火眼数据接进来之后，加一层 AI 判定，再用 Web Agent 把跑外部 BPMS 审批的体力活接管掉。
| 分支 | 判定依据 | 系统怎么处理 | 用户感受 |
|---|---|---|---|
| A · 无风险 | 水位低 + 无叠加因子 + 历史无负面 | 静默放行；事件归档到供应商风险档案，不弹卡片 | 无感 |
| B · 已报备可复用 | 同一供应商 + 同一风险事件 + 报备在有效期内 | 自动绑定历史报备卷宗；业务单据上展示"已复用 #编号" | 看到结果，无操作 |
| C · 真有风险 | 水位达阈值 或 多因子叠加 或 命中关键词 | 触发 Web Agent 接管全流程；业务方收通知，跑完后点"确认" | 被通知 + 一次确认 |
根据当前供应商的管理方（控股 / AIDC / 菜鸟），自动选对应 BPMS 审批入口，不再让用户去文档里翻链接。
从业务单据、火眼信号、AI 判定结果里拼出报备表单字段，业务方不用手敲。
1~3 级审批节点逐级提交、催办、应答，整个 BPMS 审批全程由 Agent 操作，业务方不再人工跑流。
每过一级，把状态、审批意见、附件回写业务单据，业务系统始终知道"这单走到哪一级了"。
遇到审批驳回、字段缺失、超时等情况，Agent 不蒙头硬跑，而是回到业务方那里要补充或确认。
跑完一单，自动把"事件 + 报备 + 审批结论"挂到供应商风险档案上，下次同类事件可直接复用。
| 业务方需要做的事 | Before | After（当前阶段） |
|---|---|---|
| 判断真假风险 | 自己看右侧卡片猜 | AI 判定层告诉结论 + 依据 |
| 找报备入口 | 跳钉钉文档按管理方找 | 不再需要 |
| 填报备表单 | 手动整理资料填字段 | 不再需要（Agent 拼好） |
| 跑 BPMS 审批 | 人肉催 1~3 级，天级 | 不再需要（Agent 代跑） |
| 知道结果 | BPMS 里自己翻 | 业务单据上自动可见 |
| 最终动作 | 持续操作 + 等结果 | 读一条通知 + 点一次确认 |