1. 课程导入

在风控系统建设的早期，很多团队习惯把规则写进代码或配置表，用一串 if-else 完成判断。业务简单时这种方式足够直接，但一旦策略数量增长、渠道变多、客群分层细化，规则之间的依赖、优先级、灰度与回滚就会迅速失控。风控决策流编排与策略节点路由，正是为了解决“策略越来越多、决策越来越乱”这一核心矛盾而出现的工程方法。本课程的目标，是让你具备把复杂风控策略组织成可编排、可路由、可观测、可复盘的决策流的能力。

学习目标：你应当获得什么能力

• 理解决策流、策略节点、路由规则、执行上下文等核心概念，并能用统一语言描述风控决策过程。
• 掌握从业务策略到决策流模型的映射方法，能够把“先查什么、再判什么、命中后走哪条路”表达为可执行结构。
• 能够设计策略节点的输入输出契约，处理节点间的数据传递、短路、并行与兜底。
• 掌握策略节点路由的常见模式：顺序路由、条件路由、权重路由、灰度路由与降级路由。
• 具备对决策流进行调试、回放、监控与复盘的基本能力，能定位“为什么这笔订单走了这条策略”。

核心概念：决策流不是流程图，而是执行模型

决策流编排常被误解为“画一张流程图”。流程图只是表达方式，真正重要的是背后的执行模型。一个风控决策流至少包含四类要素：执行上下文、策略节点、路由规则和终止条件。执行上下文承载请求数据、外部查询结果、中间变量与最终决策；策略节点是原子判断或模型调用；路由规则决定节点执行顺序与分支走向；终止条件决定何时输出通过、拒绝、人工审核或二次验证。

为了更直观地理解节点、路由与上下文的关系，可以用下图表示一次决策请求在编排引擎中的流转：请求进入后先构建上下文，再按路由规则选择节点，节点执行后写回上下文，最终由终止条件决定输出。

整体框架：四层结构支撑可编排决策

本课程将围绕四层框架展开。第一层是数据与上下文层，解决“决策需要哪些数据、数据从哪里来、如何缓存与降级”。第二层是策略节点层，解决“每个判断如何封装、输入输出是什么、失败如何处理”。第三层是编排与路由层，解决“节点如何组合、条件如何分支、灰度与权重如何生效”。第四层是观测与治理层，解决“如何回放、如何监控、如何审计与复盘”。四层缺一不可，只做节点不做路由，决策流会退化为规则列表；只做路由不做观测，线上问题将难以定位。

实战价值：从“能跑”到“可解释、可演进”

决策流编排的实战价值体现在三个维度。其一是效率：策略以节点形式复用，新渠道接入只需调整路由，不必复制整套规则。其二是稳定：节点级超时、降级与兜底让局部故障不扩散，灰度路由让新策略小流量验证。其三是可解释：每次决策都有执行轨迹，能回答“命中了哪些节点、走了哪条分支、最终依据是什么”。在监管与审计要求日益严格的今天，可解释性不是加分项，而是底线能力。

常见误区：先避开这些坑，再谈编排

1. 把决策流当流程图。图只是表达，执行语义才是核心。没有明确节点契约和路由优先级，图再漂亮也无法落地。
2. 节点粒度过细或过粗。过细导致编排复杂、性能下降；过粗导致复用性差、变更影响面大。通常以“一个可独立测试、可独立降级的判断单元”为节点边界。
3. 忽略上下文污染。多个节点写同一字段、外部查询结果未做版本隔离，都会让决策结果不可复现。
4. 没有兜底路径。任何节点都可能超时或异常，决策流必须定义默认通过、默认拒绝或转人工的兜底策略。
5. 只上线不观测。没有执行日志与回放能力，策略调整就是盲调，线上问题只能靠猜。

# 一个简化的决策流执行日志示例
trace_id: 20240612-8f3a91
flow: order_risk_v3
context:
  order_amount: 12800
  user_level: gold
  device_risk: high
steps:
  - node: basic_check        result: pass
  - node: device_risk_check  result: hit
  - route: high_risk_branch  reason: device_risk == high
  - node: manual_review      result: pending
final_decision: manual_review

当你能够读懂这样一条轨迹，并据此判断路由是否合理、节点是否必要、兜底是否生效时，你就已经进入了风控决策流编排的实战状态。接下来，课程将沿着“概念—建模—编排—路由—观测—复盘”的路径逐步展开，帮助你把零散的风控规则，组织成一套真正可运营的决策系统。