3. 规则引擎核心组件：规则库、事实、工作内存、议程、规则条件与动作

规则引擎是风控决策系统的“大脑”，它通过一组预定义的业务规则，对输入的事实数据进行匹配、推理并执行动作。理解其核心组件是掌握规则引擎架构的基础。本章将逐一剖析规则库、事实（Fact）、工作内存、议程（Agenda）以及规则条件与动作这五大核心要素。

3.1 核心组件总览

规则引擎的运行时可以抽象为以下五个相互协作的组件。下表总结了每个组件的职责与在风控场景中的典型体现：

3.2 规则库（Rule Base）

规则库是规则引擎的静态存储层，通常以文件（如DRL、DSL）、数据库或配置中心的形式存在。在风控系统中，规则库需要支持版本管理、灰度发布和热加载。

• 规则结构：每条规则通常包含规则名、优先级、条件（LHS）和动作（RHS）。
• 组织方式：按业务域（如登录风控、支付风控）或风险等级（如低、中、高）进行分组。
• 性能要求：规则库的索引机制（如Rete网络）直接影响匹配效率。

3.3 事实（Fact）与工作内存（Working Memory）

事实是引擎推理的基本数据单元，可以是POJO、Map或结构化消息。当事实被插入引擎后，它便驻留在工作内存中，等待规则条件的匹配。

工作内存不仅是事实的容器，还负责维护事实之间的关联关系以及推理过程中产生的临时结论。例如，当一条规则执行后修改了某个事实的属性，工作内存会触发重新匹配。

// 示例：将风控事实插入工作内存（伪代码）
Fact fact = new Fact("transaction");
fact.setAttribute("amount", 15000);
fact.setAttribute("ip", "192.168.1.1");
workingMemory.insert(fact);
workingMemory.fireAllRules();

3.4 议程（Agenda）

议程是规则引擎的“调度中心”。当规则的条件部分与工作内存中的事实匹配成功时，该规则会被激活，并作为一个激活项（Activation）放入议程。议程根据规则的优先级、冲突解决策略（如最近使用优先、复杂度优先）决定执行顺序。

• 激活：条件匹配成功，规则进入待执行队列。
• 冲突解决：当多条规则同时激活时，议程按策略排序。
• 执行：引擎按议程顺序执行规则的RHS动作。

3.5 规则条件与动作（LHS & RHS）

每条规则由两部分组成：

• 条件（Left-Hand Side, LHS）：定义规则触发的约束条件，支持逻辑组合（AND/OR/NOT）、模式匹配、存在性检查等。
• 动作（Right-Hand Side, RHS）：条件满足时执行的操作，包括修改事实、调用外部服务、输出决策结果、抛出异常等。

// 规则示例：大额交易风控
rule "HighAmountRisk"
    salience 10
    when
        $tx: Transaction(amount > 10000, channel == "online")
        not (exists User(level == "vip") from $tx.user)
    then
        $tx.setRiskLevel("HIGH");
        System.out.println("触发大额交易风控，交易ID: " + $tx.getId());
        // 可调用外部黑名单服务
        // blacklistService.check($tx.getUserId());
end

3.6 组件协作流程（SVG）

下图展示了在一次风控请求中，上述五个核心组件如何协同工作：

3.7 组件交互要点

• 无状态 vs 有状态会话：无状态会话每次请求独立创建工作内存；有状态会话可跨请求保持事实，适用于长周期风控（如用户行为积累）。
• 规则冲突解决：议程的默认策略通常是“优先级优先”，同优先级下按“加载顺序”或“复杂度”裁决。
• 事实的不可变性与修改：修改工作内存中的事实属性会触发规则重新匹配，可能导致无限循环，需通过规则设计（如标记位）避免。