3. 策略引擎核心组件：规则引擎、决策树、评分卡、工作流引擎
策略引擎听起来很玄乎，拆开来看，核心就四个组件：规则引擎、决策树、评分卡、工作流引擎。我做了这么多年策略系统，说白了，大部分业务场景都逃不出这四样东西的组合。
你想想看，一个完整的策略决策过程，无非就是：拿到数据 → 做判断 → 出结果 → 走流程。这四个组件正好对应了这四个环节。今天我就把这四个家伙掰开揉碎了讲清楚。
核心观点：规则引擎负责「判断」，决策树负责「路径选择」，评分卡负责「量化打分」，工作流引擎负责「流程编排」。四者组合，能覆盖 90% 以上的策略场景。
3.1 规则引擎：策略的「if-then」基石
规则引擎是最基础、最直观的组件。它的核心就是一组 if-then 规则。你给它一个事实（fact），它匹配规则，然后执行动作。
我习惯把规则引擎比作一个「裁判」。裁判手里有一本规则手册，球员犯规了，裁判翻手册，找到对应条款，吹哨判罚。规则引擎干的就是这个事。
一个典型的规则长这样：
规则名称: 高风险交易拦截
条件:
- 交易金额 > 10000
- 交易频率 > 5次/小时
- 交易对手为黑名单账户
动作:
- 拒绝交易
- 触发风控告警
- 记录审计日志规则引擎的核心能力有三个：
- 规则匹配：快速找到满足条件的规则。Rete 算法是经典方案，我早年做实时风控时用过，效率确实高。
- 冲突解决：多条规则同时满足时，谁先执行？优先级、最近最久未使用、指定顺序，各有各的玩法。
- 规则管理：增删改查、版本控制、热加载。嗯，这里要注意，生产环境千万别直接改规则库，一定要走版本发布流程。
我的经验：规则引擎最适合「确定性高、变化频繁」的场景。比如风控规则、优惠券发放规则。我曾经在一个项目中，把 2000 多条硬编码的 if-else 全部迁移到规则引擎，上线后策略调整时间从 3 天缩短到 10 分钟。
3.2 决策树：多级分支的「导航仪」
决策树和规则引擎有点像，但思路不同。规则引擎是「平行匹配」，决策树是「逐级分支」。你从根节点出发，每到一个节点做一个判断，走到叶子节点就得到结论。
为什么会需要决策树？我举个例子。你在做客户分层时，先判断「是否新客」，是的话走新客策略，不是的话再判断「消费金额是否大于 5000」，再往下分。这种层级结构，用规则引擎写会很啰嗦，用决策树就一目了然。
决策树的三种节点：
| 节点类型 | 作用 | 示例 |
|---|---|---|
| 根节点 | 决策起点，包含第一个判断条件 | 用户类型 == 新客？ |
| 内部节点 | 中间判断点，每个节点一个条件 | 消费金额 > 5000？ |
| 叶子节点 | 最终结论，不再分支 | 发放 8 折优惠券 |
决策树的优势很明显：可解释性强。你问系统「为什么给这个用户 A 策略」，系统可以告诉你：因为用户是 VIP → 消费超过 1 万 → 最近 30 天活跃 → 所以走 A 策略。每一步都清清楚楚。
避坑指南：决策树深度不要超过 10 层。我曾经接手过一个项目，决策树深度到了 15 层，维护起来简直噩梦。每加一个分支都要重新梳理全路径。建议控制在 5-7 层以内，超过这个深度，考虑拆成多棵树或用规则引擎替代。
3.3 评分卡：量化决策的「计算器」
评分卡和前面两个不一样。规则引擎和决策树做的是「定性判断」，评分卡做的是「定量打分」。它给每个特征分配一个分数，加权求和，得到一个总分，然后根据总分区间做决策。
评分卡在金融风控领域用得最多。我记得在做一个信贷审批系统时，评分卡就是核心中的核心。客户的年龄、收入、征信记录、负债率，每个维度都有对应的分数，加起来就是客户的信用分。
一个简化的评分卡示例：
| 特征 | 取值区间 | 分数 |
|---|---|---|
| 年龄 | 25-35 岁 | 15 |
| 年龄 | 36-50 岁 | 20 |
| 月收入 | 5000-10000 | 10 |
| 月收入 | 10000-20000 | 25 |
| 征信记录 | 无逾期 | 30 |
| 征信记录 | 有逾期 | -20 |
总分 = 年龄分 + 收入分 + 征信分。假设总分阈值是 60 分，超过 60 分通过，低于 60 分拒绝。就这么简单直接。
评分卡的好处是灵活、可调、可解释。业务方说「最近坏账多了，收紧一下」，你不需要改逻辑，只需要调一下阈值或者某个特征的分数就行。
关键点：评分卡的分数设计要遵循「单调性」原则。比如收入越高分数越高，不能出现收入 5000 比收入 10000 分数还高的情况。除非你有非常特殊的业务理由，否则不要打破单调性。
3.4 工作流引擎：策略的「总导演」
最后一个是工作流引擎。前面三个组件解决的是「单个决策点怎么做」，工作流引擎解决的是「多个决策点怎么串起来」。
你想想看，一个完整的策略流程，往往不是一步到位的。比如：
- 先做身份核验（规则引擎）
- 再做信用评估（评分卡）
- 根据信用分走不同分支（决策树）
- 最后触发审批流程（工作流引擎）
工作流引擎就是把这些步骤编排起来，管理状态流转、超时处理、异常回滚、人工介入。我常用的工作流引擎有 Activiti、Camunda，轻量级的可以用状态机模式自己实现。
工作流引擎的核心概念：
- 节点（Node）：流程中的一个步骤，可以是自动执行，也可以是人工任务
- 连线（Transition）：节点之间的跳转条件
- 状态（State）：当前流程执行到哪一步了
- 事件（Event）：触发状态变化的外部信号
我的建议：不要把业务逻辑写在工作流引擎的脚本节点里。工作流引擎只负责「流程编排」，具体的「判断逻辑」交给规则引擎或决策树。这样职责清晰，改流程不改逻辑，改逻辑不改流程。
3.5 四个组件的协同关系
这四个组件不是孤立的。在实际项目中，它们经常组合使用。我画了一张图来说明它们的关系：
实际项目中，我常用的组合方式：
- 规则引擎 + 评分卡：先用规则引擎做黑白名单过滤，再用评分卡做精细打分
- 决策树 + 工作流引擎：决策树决定走哪个分支流程，工作流引擎执行对应流程
- 三件套组合：规则引擎做前置校验，评分卡做核心评估，决策树做最终决策，工作流引擎做全流程编排
避坑指南：组件之间的调用不要搞成循环依赖。比如规则引擎调评分卡，评分卡又回调规则引擎，这种设计一旦出问题，排查起来非常痛苦。我曾经踩过这个坑，最后花了整整两天才把循环链路理清楚。记住：调用关系必须是单向的、有向无环的。
好了，四个核心组件讲完了。规则引擎是基础，决策树是路径，评分卡是量化，工作流引擎是编排。理解清楚每个组件的定位和适用场景，后面做策略设计时才能选对工具。