4. 决策流编排语言入门：YAML/JSON 格式定义决策流、节点类型与属性配置

在额度策略工程中，决策流不再由硬编码实现，而是通过声明式语言（YAML 或 JSON）进行编排。这种方式将策略逻辑与代码解耦，使得策略分析师和风控工程师能够以接近自然语言的方式定义复杂的审批链路。本章将深入讲解决策流的核心结构、节点类型以及属性配置方法。

4.1 决策流的基本结构

一个标准的决策流定义文件通常包含三个顶层字段：metadata（元数据）、nodes（节点列表）和 edges（连线列表）。YAML 因其可读性高、支持注释，成为业界首选；JSON 则更适用于系统间传输。

字段 类型 说明 示例
metadata Object 定义决策流的名称、版本、描述、作者等元信息 name: credit_line_decision_v1
nodes Array 包含所有决策节点的列表，每个节点有唯一 id 和类型 id: node_001, type: rule
edges Array 定义节点之间的连接关系，包含 source、target 和条件 source: node_001, target: node_002
💡 最佳实践： 建议使用 YAML 作为策略定义语言。YAML 的缩进结构天然适合表达节点嵌套关系，且支持行内注释，便于团队协作评审。

4.2 核心节点类型与属性配置

额度决策流中的节点按功能可分为四大类：输入节点、规则节点、计算节点和输出节点。每种节点都有其专属的属性配置。

4.2.1 输入节点（Input Node）

决策流的起点，负责接收外部传入的变量，如用户ID、申请金额、征信报告数据等。通常配置变量映射和数据类型校验。

# YAML 示例：输入节点
nodes:
  - id: input_001
    type: input
    config:
      variables:
        - name: user_id
          type: string
          required: true
        - name: requested_amount
          type: number
          required: true
        - name: credit_score
          type: number
          required: false
          default: 0

4.2.2 规则节点（Rule Node）

核心判断单元，执行布尔逻辑运算。支持单条件、多条件组合（AND/OR）以及阈值比较。规则节点通常关联一个规则集 ID 或内联表达式。

# YAML 示例：规则节点
  - id: rule_001
    type: rule
    config:
      rule_set_id: "RS_1001"  # 引用外部规则集
      # 或使用内联规则
      inline_rules:
        - condition: "credit_score < 600"
          action: "reject"
        - condition: "credit_score >= 600 AND requested_amount <= 50000"
          action: "approve"

4.2.3 计算节点（Compute Node）

执行数学运算或数据转换，如额度计算、利率换算、收入负债比计算。支持调用内置函数或自定义脚本。

# YAML 示例：计算节点
  - id: compute_001
    type: compute
    config:
      expression: "min(requested_amount, credit_score * 100)"
      output_variable: "final_line_amount"

4.2.4 输出节点（Output Node）

决策流的终点，负责输出最终决策结果（通过/拒绝/人工审核）以及额度、利率等衍生变量。

# YAML 示例：输出节点
  - id: output_001
    type: output
    config:
      decision_field: "final_decision"
      output_fields:
        - name: "approved_amount"
          source: "final_line_amount"
        - name: "interest_rate"
          source: "calculated_rate"

4.3 节点通用属性与连线定义

所有节点共享一组通用属性，用于控制执行顺序、超时、重试和日志记录。连线则定义了节点间的流转路径，支持条件分支。

属性 适用节点 说明 示例值
id 所有 节点唯一标识 node_001
type 所有 节点类型 rule
timeout_ms 所有 节点执行超时时间（毫秒） 5000
retry_count compute 失败重试次数 2
log_level 所有 日志级别 INFO

连线（Edges）定义示例：

edges:
  - source: input_001
    target: rule_001
    condition: ""  # 无条件，直接流转
  - source: rule_001
    target: compute_001
    condition: "result == 'approve'"
  - source: rule_001
    target: output_001
    condition: "result == 'reject'"
🔑 关键点： 连线中的 condition 字段支持表达式引擎，可以引用上游节点的输出变量。空字符串表示无条件流转（默认路径）。

4.4 完整决策流示例（YAML）

以下是一个完整的额度审批决策流定义，包含输入、规则判断、额度计算和最终输出。

metadata:
  name: "quick_credit_line_v1"
  version: "1.0.0"
  description: "小额快速额度审批流程"

nodes:
  - id: input_data
    type: input
    config:
      variables:
        - name: user_id
          type: string
        - name: credit_score
          type: number
        - name: monthly_income
          type: number

  - id: check_credit
    type: rule
    config:
      inline_rules:
        - condition: "credit_score < 600"
          action: "reject"
        - condition: "credit_score >= 600"
          action: "proceed"

  - id: calculate_line
    type: compute
    config:
      expression: "min(monthly_income * 3, 100000)"
      output_variable: "line_amount"

  - id: final_decision
    type: output
    config:
      decision_field: "decision"
      output_fields:
        - name: "approved_line"
          source: "line_amount"

edges:
  - source: input_data
    target: check_credit
  - source: check_credit
    target: calculate_line
    condition: "result == 'proceed'"
  - source: check_credit
    target: final_decision
    condition: "result == 'reject'"
  - source: calculate_line
    target: final_decision
决策流节点类型与关系架构 决策流节点类型与关系架构 输入节点 Input 规则节点 Rule 计算节点 Compute 输出节点 Output 连线（Edges）与条件分支 • 无条件连线：source → target，直接流转 • 条件连线：source → target，仅当 condition 表达式为 true 时执行

4.5 JSON 格式对比与转换

虽然 YAML 是策略工程师的首选，但底层引擎通常将 YAML 编译为 JSON 执行。了解 JSON 格式有助于排查运行时问题。以下是同一决策流在两种格式下的对比。

特性 YAML JSON
可读性 高，缩进清晰，支持注释 中，括号密集，不支持注释
文件大小 较小（无冗余括号） 较大（键名需双引号）
解析速度 较慢（需解析缩进） 快（原生支持）
适用场景 策略编写、版本管理 运行时传输、存储
⚠️ 常见陷阱： YAML 对缩进极其敏感，禁止混用 Tab 和空格。建议统一使用 2 个空格缩进。在 JSON 中，所有字符串键必须使用双引号，末尾不能有逗号。
YAML 与 JSON 决策流结构对比 YAML 与 JSON 决策流结构对比 YAML 格式 metadata: name: flow_v1 nodes: - id: node_1 type: input - id: node_2 type: rule edges: - source: node_1 target: node_2 JSON 格式 { "metadata": { "name": "flow_v1" }, "nodes": [ {"id":"node_1","type":"input"}, {"id":"node_2","type":"rule"} ], "edges": [ {"source":"node_1","target":"node_2"} ] }

4.6 节点属性配置进阶：上下文与变量作用域

在复杂决策流中，节点之间需要共享数据。每个节点执行后，其输出变量会被写入一个全局上下文（Context）对象。后续节点可以通过 $context.variable_name 引用这些变量。

# 节点间变量传递示例
nodes:
  - id: compute_income_ratio
    type: compute
    config:
      expression: "monthly_income / total_debt"
      output_variable: "income_ratio"  # 写入上下文

  - id: check_ratio
    type: rule
    config:
      inline_rules:
        - condition: "$context.income_ratio > 0.4"
          action: "reject_high_risk"
📌 变量作用域规则： 所有节点共享同一个上下文。为避免命名冲突，建议采用命名空间前缀，如 input.user_id、rule.credit_result、compute.final_amount。

4.7 本章小结

  • 决策流由 metadata、nodes、edges 三部分组成，YAML 是推荐的编排语言。
  • 四种核心节点类型：输入、规则、计算、输出，各有专属配置属性。
  • 连线支持条件分支，通过 condition 表达式控制流转路径。
  • JSON 是运行时格式，YAML 是编写格式，两者可互相转换。
  • 变量通过全局上下文传递，注意命名规范以避免冲突。
← 上一章 📖 返回目录 下一章 →