当规则数量超过 50 条或涉及多个业务线时，扁平化管理会导致规则冲突难以排查、修改影响范围不可控。采用分层架构可将复杂度隔离，推荐按以下三层进行划分：
12.2.1 三层标准架构
- L1 决策层（Decision）：负责"是/否"的粗粒度判断。如黑名单拦截、白名单放行、系统维护期熔断。特点是高优先级、低计算成本、立即生效。
- L2 策略层（Strategy）：承载具体业务逻辑。如风控评分、价格计算、内容审核策略。允许复杂计算（调用外部模型、多表关联），但必须基于 L1 的放行结果。
- L3 执行层（Execution）：处理动作落地。如发送短信、记录日志、更新订单状态、触发工作流。特点是无返回值、可异步执行。
12.2.2 配置要点
- 优先级硬隔离
设定明确的优先级区间：L1（1000-1999）、L2（2000-2999）、L3（3000+）。禁止跨层调整优先级，防止 L3 规则意外覆盖 L1。
- 数据上下文隔离
每层只能读写指定的上下文对象：
- L1 只读
request（原始请求） - L2 读写
fact（业务事实对象） - L3 只写
action（动作队列）
- 短路机制
L1 若触发拒绝，直接返回，不进入 L2/L3；L2 若未命中任何策略，执行默认规则后进入 L3。
12.2.3 实战示例：电商促销规则
# L1 决策层（优先级 1500）
- name: 黑名单用户拦截
condition: user.tag contains 'fraud'
action: reject("账户异常")
# L2 策略层（优先级 2100）
- name: 会员折扣计算
condition: L1.passed == true && user.level == 'VIP'
action: fact.discount = 0.8
# L3 执行层（优先级 3100）
- name: 发送优惠券到账短信
condition: fact.discount > 0
action: sendSMS(user.phone, "您已获得折扣")12.2.4 避坑指南
- 避免在 L3 做业务判断：曾有团队在 L3 中加入"如果库存不足则取消订单"的逻辑，导致与 L2 的价格计算规则产生竞态条件。所有业务判断应留在 L2。
- L2 内部再分组：若 L2 规则过多，可按业务域拆分为 L2-A（风控）、L2-B（营销），组内优先级管理，组间并行执行。
- 日志分层输出：生产环境排查时，先过滤
level=L1的日志，可快速定位 80% 的拦截原因，避免被 L3 的海量执行日志淹没。
12.2.5 渐进式上线建议
新规则先挂靠在 L2 的"观察模式"（只记录不生效），运行一周确认无误判后，再调整优先级至正式区间。L1 规则修改必须走双人复核，因其影响面最大。