多控制节点

当一个任务需要同时调节多个执行器时，可以在同一个策略阶段指定多个控制节点，并用共享奖励联合优化。本页以加热器和风机为例，说明动作定义、配置、训练以及部署时的输出对应关系。

使用场景

多个执行器往往影响同一个业务目标。加热器提高温度，风机改变散热速度，两者都会消耗能量；分别优化各自的局部目标，可能出现一边加热、一边强制散热的情况。共享奖励可以让策略同时考虑温度偏差和总能耗。

类似需求还包括多个阀门协同调节流量、多个关节协调运动，以及供暖与通风联合控制。每个控制量都应有明确的观测、物理边界和执行时刻。

如果多个动作始终具有相同的观测与模型结构，也可以像机器人控制一样，用一个多维动作节点表示。本功能适用于需要按名称分别定义动作节点的任务。

示例：联合调节加热器与风机

示例数据位于 examples/thermal_workflows/，控制目标是接近 22°C，并考虑能耗。

节点	作用	范围	可读取的信息
heater	控制加热功率 4 × heater kW	[0,1]	当前温度、环境温度、负载
fan	调节与环境的换热	[0,1]	当前温度、环境温度、负载

两个动作共同作用于温度过程。世界模型使用温度、加热功率、风机和外扰预测下一温度，策略再根据预测得到的跟踪误差与动作能耗学习协调方式。

本例的两个动作节点并行读取同一组观测，风机不读取本步新生成的加热命令。这对应给定观测下的两个条件独立动作分布，业务上的耦合通过世界模型和共享奖励体现。

配置动作节点与共享奖励

声明动作与训练阶段

完整配置为 examples/thermal_workflows/multi_ppo.yaml。以下是其中控制图的节点片段：

# graphs.control.nodes 下的片段
heater:
  inputs: [temperature, ambient, load]
  network: {backbone: mlp, hidden_dims: [16], activation: tanh}
  output_dist: tanh_normal
fan:
  inputs: [temperature, ambient, load]
  network: {backbone: mlp, hidden_dims: [16], activation: tanh}
  output_dist: tanh_normal

列定义分别给两个动作设置 [0,1] 边界。世界模型在环境图上训练，策略阶段切换到包含两个动作节点的控制图，并继承已学到的温度模型。

# 策略阶段 hyperparameters 下的片段
policy_nodes: [heater, fan]
reward:
  path: reward.py
  function: get_training_reward

policy_nodes 列出需要联合更新的动作节点。两个节点共同优化一个奖励，PPO/SAC 使用它们的联合动作信息更新策略。

用业务目标定义奖励

示例的训练奖励包含温度跟踪和能耗：

tracking = ((next_temperature - 22) / 2)²
energy   = (4*heater + 0.2*fan²) / 4.2
reward   = -(tracking + 0.1*energy)

2°C 与 4.2 kW 分别用于归一化温差和功率。温度为 24°C、两个动作为 1 时，tracking 和 energy 均为 1，奖励为 −1.1。温度接近目标且能耗更低的动作组合获得更高奖励。

需要总功率限制时

若业务要求总功率尽量不超过 3 kW，可在自己的奖励文件中增加超限代价。下面是可选示例，使用时把策略阶段的 reward.function 改为该函数名：

def get_power_limited_reward(data):
    tracking = ((data["next_temperature"] - 22.0) / 2.0).square()
    power = 4.0 * data["heater"] + 0.2 * data["fan"].square()
    energy = power / 4.2
    excess = ((power - 3.0) / 1.0).clamp_min(0.0).square()
    return -(tracking + 0.1 * energy + 0.5 * excess)

输入输出均采用原始物理空间的 [B,1] 张量。next_temperature 是模型在动作后的预测，用于训练奖励。上述条件下奖励为 −1.82；3 kW、1 kW 尺度和 0.5 权重应按实际设备调整。

奖励中的功率超限项是软惩罚。必须逐步满足的设备限制，还应由动作边界和业务执行规则保证。需要平滑动作时，将上一实际执行动作纳入训练状态，再定义动作变化代价。

训练并比较控制效果

在仓库根目录运行；已有示例数据时跳过生成步骤，重新生成会覆盖示例数据。

python examples/thermal_workflows/prepare_data.py
revive validate --config examples/thermal_workflows/multi_ppo.yaml
revive train --config examples/thermal_workflows/multi_ppo.yaml --run-id thermal_joint

配置先训练 2 轮世界模型，再训练 1 轮 PPO，用于完成联合动作流程。结果保存在 示例目录下的 logs/thermal_joint/，其中 models/env.pt 用于预测，models/policy.pt 输出两个动作。

从报告核对策略阶段的奖励和两个动作的范围。正式比较时固定初态、外扰、评估时长和训练规模，分别统计温度跟踪、能耗、动作变化及超限量。可以与现有固定规则比较，判断联合控制是否带来符合业务目标的改善。

读取动作与部署

原生策略接口返回以动作名称为键的字典：heater 与 fan 各为 [B,1]。调用方应按名称分别传给对应执行器，执行周期与训练数据保持一致。

revive export --artifact examples/thermal_workflows/logs/thermal_joint/models/policy.pt \
  --project examples/thermal_workflows

ONNX 输出顺序以部署文件包的 output_specs 为准，本例为 fan, heater。读取匿名拼接向量时按该说明拆分，不能直接采用 policy_nodes 的书写顺序。模型加载与动作推理代码见使用与部署模型。

支持范围与常见问题

本页采用两个独立连续动作节点加共享奖励，适用于当前 PPO/SAC 训练路径。若让风机读取本步加热动作，就形成串联的条件分布；当前无状态 PPO/SAC 路径尚不支持这种串联训练配置。能够顺序执行图上的推理，不代表该配置可以直接用于随机策略训练。

现象	处理方法
只有一个动作发生变化	检查 policy_nodes 是否列出全部目标节点及奖励是否覆盖两种动作
两个动作在设备端对应错误	原生接口按名称读取，ONNX 按 output_specs 拆分
控温改善但能耗明显增加	分别查看跟踪与能耗分项，调整权重后重新比较
希望动作更平滑	接入上一实际动作的状态，再加入变化代价
串联动作训练不受支持	使用并行动作加共享奖励，或重新设计动作表示