策略引擎：规则 DSL 与执行框架文章目录策略引擎：规则 DSL 与执行框架引言：链路是哑的，得有人判断"该不该发"一、规则模型：把国标条款变成配置项二、规则生命周期：语法、校验、优先级、版本与生效范围2.1 规则语法：声明式，禁自由代码2.2 加载校验：语法关、语义关、安全关2.3 优先级纪律：默认规则可被覆盖，安全关才是红线2.4 版本与生效范围三、规则引擎：教学默认规则 + 区域规则覆盖四、执行框架：指令下发前的四道关五、与第 15 篇的合流：策略在前，链路在后六、冲突检测与历史回放：规则治理的两个抓手6.1 冲突检测：加载时把歧义消灭掉（原理伪代码）6.2 历史回放：用当时的规则重审当时的决策（原理伪代码）七、单测：8 项代表性场景验证结语：五个教学模块成型，钱该算了引言：链路是哑的，得有人判断"该不该发"上一篇指令链路解决了"怎么安全送到"，但留下一个更大的问题：链路忠实执行任何指令，不判断"这个指令该不该发"。该不该发的判断并不简单。教学默认规则来自 44260 的场景要求，但比标准更严：调频只放储能（标准 5.10(d) 是"宜以分布式储能、电动汽车充电桩为主，配置部分可调分布式电源"，并不排他）、调峰以可调负荷为主、备用要确定性资源——这是场景决定资源类型；指令不能超过资源当前可信容量——超出部分没有兑现依据；涉控指令要额外的安全校验（47241 第 9.4 条控制校核）。这些规则散在标准的各章各节，本篇把它们收敛成一台策略引擎：规则可配置、执行有框架、拒绝说原因。openvpp-dispatch/strategy包交付三个组件：规则模型（DispatchRule）、规则引擎（RuleEngine）、执行框架（StrategyExecutor），8 项代表性单测。图 1：四道准入关与目标接线。合法入参前提下，场景匹配、能力上限、涉控边界、代理有效依次求值；任一关拒绝均带原因返回调度侧。全关通过只返