从Isaac Gym到RK3566：双足机器人强化学习策略的完整部署实践

先交代一下背景Microduck是一台25厘米左右的小型双足机器人最初是在英伟达GPU上用强化学习在仿真里练出来的整套训练流程跑在Isaac Gym这类环境里。这篇文章记录的是我把它从“GPU上的数字模型”搬上RK3566实机泰山派的完整过程包括训练侧的东西、导出侧要注意的算子、实机上电后的调试以及我在这个过程中踩过的坑。 如果你手里也有一台类似的小型双足/四足机器人训练环境用的是NVIDIA GPU部署目标却是一块几瓦功耗的ARM板卡那这篇文章应该能帮你少走不少弯路。尤其是从“仿真能走”到“实物能站稳”中间的那段空白我会尽量把每个关键步骤都讲透。1. 项目全貌与部署路线设计1.1 Microduck是什么我为什么要做这块板子Microduck是那种看着小巧、实际牵涉面却很广的项目。整体身高25厘米级别双足构型每条腿通常有3个自由度全身加起来6个左右的关节电机。这类小机器人和工业机械臂有个明显区别它本身是不稳定系统站直了就得实时控制重心稍微偏一点就会倒。传统的做法是写PID/PD控制器把姿态稳住但Microduck这类项目从一开始就选择了强化学习路线让策略网络自己学习“怎么站、怎么走、怎么在被推一下之后恢复平衡”。我最初拿到这块板子时以为工作重点会是强化学习算法本身。做了几天才发现真正磨人的不是PPO算法的收敛问题而是整个部署链路没有任何一环是省心的。训练时我在英伟达GPU上用PyTorch训练功耗随便三四百瓦部署目标却是RK3566典型功耗5瓦以内CPU主频不高片上带NPU但跑双足控制这类策略网络根本用不上——因为RL策略推理本身是个很小的MLPNPU在这种场景反而没什么优势。这套“大算力训练、小算力部署”的路子几乎是所有具身智能项目都会遇到的共同命题。你把机器人做大了可以用工控机甚至机架式服务器当“大脑”但Microduck这个尺寸注定是边缘部署必须在板端解决。25厘米高的机器人注定不可能背一台GPU服务器到处跑所以RK3566这种板子就是一个很合适的选择。它的算力不算强但足够跑一个小的MLP控制策略同时还能跑Linux系统、接摄像头、走通信刚好卡在“啥都能干但啥都要抠一抠”的定位上。1.2 从英伟达GPU到RK3566一条完整的部署链路如果只把问题理解为“把模型从GPU拷到ARM板卡上跑”那实现起来其实很快——因为强化学习部署到实机时用的往往不是原版PyTorch模型而是转换后的ONNX或者RKNN格式。但这件事真正的链路拆开看大概有六段GPU端做仿真训练输出的是PyTorch权重文件从训练工程里抽出actor策略网络丢掉critic、丢掉训练用的均值方差只留纯推理图把PyTorch模型转成ONNX格式再根据RK3566的NPU情况决定是否转RKNN在RK3566上准备运行时环境包括系统镜像、Python/C推理库、传感器驱动、通信接口把控制策略和IMU/关节编码器数据打通让策略网络在板端实时跑起来实机联调调频率、调相位、调奖励函数与真实世界不一致带来的差异。这几段每一段都有独立的坑。比如PyTorch里很常见的Flatten、transpose算子在导出ONNX时可能正常但走到RKNN工具链时就会提示算子不支持又比如训练时IMU数据是理想仿真的但实机上IMU零漂、振动噪声、延迟都会让策略表现断崖式下降。所以在训练侧就要加入噪声、延迟、力扰动这些domain randomization否则模型还没上实机就已经“死”在仿真里了。1.3 为什么选RK3566而不是再租一台GPU服务器有人问我Microduck这种25厘米的机器人为什么不用树莓派也不用Jetson Orin Nano偏偏选了RK3566。这里面有成本、功耗和扩展性的多重考虑。RK3566板卡比如泰山派核心板加底板可能就一两百元功耗比Jetson低一个量级接口方面有PCIe、USB3.0、千兆网、MIPI-CSIGPIO/I2C/SPI/UART也齐全作为机器人的“小脑”完全够用。虽然它的CPU是四核Cortex-A55频率也就1.8GHz左右但在做纯CPU推理时跑一个十几层的小MLP单次推理实测在几十微秒到一百多微秒之间这个量级对控制频率来说是绰绰有余的。反过来如果你用Jetson Orin Nano或者更贵的板子算力确实更强但同样的机器人整机功耗、体积、成本都会往上走。用RK3566是非常典型的“低成本实现闭环”思路。它不是不能跑视觉大模型而是你不需要用牛刀杀鸡。Microduck的控制策略网络参数量通常不到几十万整个actor的FLOPs可能只是ResNet的一个零头把它硬塞到几百TOPS的算力平台上没有意义。我实际把整套策略部署上之后测过RK3566上纯C实现策略网络推理不做NPU加速一帧耗时大约40到80微秒哪怕是Python推理加numpy手写前向也就1毫秒上下。而双足机器人的控制频率一般在200到1000Hz也就是每帧周期1到5毫秒所以算力瓶颈根本没有真正的瓶颈在传感器读取、串口通信和控制线程的实时性上。2. GPU端训练环境与策略细节2.1 仿真环境与强化学习框架选型训练环境这块我看了当前机器人强化学习圈子的主流方案后选了Isaac Gym。这类环境的好处是能直接在GPU上做几千上万个并行环境的仿真批量采样速度非常快PPO这种on-policy算法最依赖的就是采样吞吐量没有GPU并行仿真训练一个双足行走策略可能要几天而用Isaac Gym之后基本几个小时能见到初步效果。具体硬件上我用的是一块NVIDIA RTX显卡显存至少12GB。如果你想训Microduck这种小型机器人显存要求不会特别夸张但并行环境数量如果上到4096甚至8192显存占用还是会涨得比较快。我在实际训练时把并行环境数设在2048到4096之间单卡显存占用大约6到10GB如果显存不够就降到1024个环境等待时间会明显变长。训练框架我建议直接用Legged Gym或者RLGym这类开源项目魔改。它们的核心逻辑都差不多定义机器人的URDF/MJCF模型在仿真环境里创建地形、设置初始姿态、定义奖励函数和终止条件然后并行采样交给PPO更新。网络上Microduck相关仓库也有现成训练代码你可以下载后把机器人的URDF和关节配置替换成自己的再根据实际硬件调一下关节阻尼、摩擦力、电机时间常数这些参数。2.2 训练参数、观测空间与奖励设计我第一次跑Microduck仿真时发现“站不稳”其实不是策略问题而是观测空间和奖励函数设计不合理。这个小双足机器人能观测的数据包括机身IMU的角速度、姿态用四元数或欧拉角关节角度、关节角速度再加上前一时刻的动作。把这些拼起来观测维度通常在30到50之间。动作空间就是6个关节的目标位置或目标速度增量维度很小。奖励函数这块踩过不少坑。初期阶段我模仿其他项目写“站立越高越好、机身姿态越水平越好、动作变化越小越好”结果策略学出了一个很猥琐的动作让机器人原地蹲下去因为蹲下时重心低、姿态误差也小奖励反而高。后来加了一条“目标高度惩罚”规定机身高度低于某个阈值时额外给大惩罚策略才老老实实学站立。另一个常见情况是“走起来很别扭”因为动作平滑惩罚的系数设置太大导致策略不敢动输出全是零调小之后又容易震荡所以这个系数需要反复试。实用经验是奖励不要急着叠加太多项先让机器人学会站再加行走目标最后加抗扰动。训练时要盯两个核心指标——平均奖励曲线是否还在上升、以及仿真里机器人能不能扛过整个episode时长。此外特别建议加入域随机化把摩擦力、电机强度、IMU噪声、控制延迟都加一点随机扰动。没有域随机化的策略上实机大概率会像喝醉了一样因为真实世界和仿真理想环境差距太大。2.3 一次完整训练的实验记录与导出前检查我跑的比较完整的一次训练记录大致是这样并行环境4096个PPO的clip范围0.2actor和critic都是三层MLP隐藏层256学习率1e-3训练步数2000万左右。刚开始几百步时机器人基本秒倒平均episode长度不到0.5秒随着训练推进大概到了200万步时机器人能站住一小会儿600万步之后开始能迈步800万到1500万步之间行走能力明显提升。最终策略在仿真里的成绩是平地直走基本不倒能从侧面承受一定大小的推力扰动。这个结果看着还算不错但每次训练结束我都会做一件很多人忽略的事用训练好的权重去跑若干次确定性推理同时把每一帧的观测均值、方差、奖励分量记录下来。为什么因为部署到实机时如果机器人走着走着突然朝一个方向猛冲或者疯狂抖动往往不是因为策略本身学得不好而是你得确认导出的模型和训练时用的模型在数学上完全一致且没有丢掉归一化层。强化学习策略网络在训练时一般会做observation normalization也就是把状态输入减去均值再除以标准差。均值方差是在训练过程中在线统计的部署时这些统计量必须原封不动地带过去。如果只在PyTorch里跑没问题导出成ONNX时却忘了把归一化层也固化进去实机上就会看到奖励函数明明是正常的但机器人的表现完全对不上——这就是所谓“遇到错误奖励但排查不到奖励问题”的一个常见来源。2.4 关于IQL离线强化学习的延展最近圈子很多人讨论IQLImplicit Q-Learning这类离线强化学习算法我其实也在关注。在线PPO训练虽然效果好但要求你有一块不错的NVIDIA GPU一直跑仿真而IQL这类离线算法的思路是不需要在线仿真直接用一批已经收集好的经验数据集训练策略。这样训练功耗低、训练时间也更快对没有多卡GPU的个人开发者来说是个友好方向。IQL的核心思想是不对超出数据集分布的动作做过高估计通过隐式Q函数让策略学习“只做数据里出现过的靠谱动作”。放在Microduck这种小机器人上一种很自然的应用方式是先用在线PPO或者人工遥控采集一批数据再用IQL做后训练或策略精修。部署导出流程其实和在线训练基本一样——保存的仍然是actor网络导出后照样走ONNX/RKNN路线。要注意的是IQL对数据集质量很敏感如果你采集的数据里大部分都是“机器人摔倒”“机器人站在原地不动”那学出来的策略也不会好用。本小节的建议是如果你预算不足、没有可长期占用的GPU研究一下离线强化学习是值得的但如果你只是想把Microduck快速跑起来老老实实在线PPO仍然是当前性价比最高的路径。3. 模型导出与边缘端适配3.1 部署时只需要的是策略网络不是整个训练模型强化学习训练出来的模型里通常包含actor和critic两个部分。actor负责根据观测输出动作critic负责评估状态价值只在训练阶段用。但很多人在导出时会搞混直接把整个checkpoint加载然后torch.onnx.export结果导出的模型里带了critic分支导致模型体积变大、算子变复杂甚至有些critic里用到的算子RKNN工具链根本不愿意支持。正确做法是先加载训练好的权重然后只取出actor网络。在Microduck这种场景里动作一般选确定性输出即actor网络的mean而不是再采样一个高斯分布。如果你训练时使用了log_std部署时必须丢掉采样环节否则实机上每次动作都会带随机噪声机器人轻则抖动重则直接摔倒。换句话说实机部署的策略应当是一个确定性的从观测到动作的映射。另外critic网络的输入输出维度和actor不同部署前建议把模型结构打印出来确认一下。我就是因为一开始没注意导出的ONNX里混了一个值为0的输入节点导致后面在板端推理时输入维度不匹配排查了很久才发现导出逻辑写错了。3.2 从PyTorch权重到RK3566能跑的格式PyTorch权重不能直接在RK3566上跑除非你在板卡上装PyTorch。理论上可以装但对RK3566来说太浪费了PyTorch的ARM版体积大、内存占用高而且很多算子并没有针对ARM做专门优化。更合理的路线是PyTorch - ONNX - RKNN。如果只跑CPUONNX Runtime也是不错的方案如果你想把某些层放到NPU则必须转成RKNN。导出ONNX的代码看起来很简单import torch import torch.nn as nn def export_actor_to_onnx(actor, obs_dim42, filemicroduck_actor.onnx): actor.eval() dummy_input torch.randn(1, obs_dim) torch.onnx.export( actor, dummy_input, file, input_names[obs], output_names[action], dynamic_axes{obs: {0: batch}, action: {0: batch}}, opset_version11, )但中间有几个容易被忽略的点第一actor网络里如果用了BatchNorm导出时会问你要不要将其固定下来必须选择固定也就是使用训练阶段累计的running_mean和running_var否则没有训练时的数据分布跑出来的结果就不对。第二opset_version不要追求太高RKNN工具链往往对新opset支持不够及时我这边稳定使用的是opset 11或12。第三导出之后一定要先用onnxruntime跑一遍和PyTorch相同的输入对比输出差异误差在1e-4级别才算正常。之后再把ONNX转成RKNN。这个转换在PC端用瑞芯微提供的rknn-toolkit2就可以做大概流程是加载ONNX模型配置量化方式设置目标平台为rk3566然后导出rknn文件。我个人在实际部署时并没有把所有层都塞进NPU因为RL策略网络层数不多CPU跑已经够快反而省去了量化精度损失的烦恼。3.3 量化和算子适配的取舍RK3566的NPU推理通常需要INT8量化才能发挥最大性能但这对RL策略来说可能是个陷阱。量化会带来精度损失而控制策略对动作输出的精度其实比较敏感。一个简单实验就能说明问题用原FP32 ONNX在实机上跑机器人站得还行用RKNN INT8量化后再跑机器人开始高频抖动或者动作幅度明显减弱。原因就是量化后的推理误差被机器人本体放大成了不稳定的反馈信号。怎么取舍我的建议是分场景看。如果策略模型比较大、对延迟要求很高迫不得已走NPU那要考虑量化校准数据集怎么选。校准数据应该尽量贴合真实部署时的观测分布不能拿一堆随机噪声去校准否则权重量化后的有效位数会浪费在无关分布上。如果模型很小、单次推理在CPU上只要几十微秒我建议直接保留FP32或FP16用CPU推理就好。Microduck的策略网络是典型的小模型CPU推理完全没有性能压力不必非走NPU不可。最后一步如果确实有某些层无法被RKNN工具链转换常见处理方式是先用onnxsimplifier对ONNX图做简化很多冗余算子比如Identity、多余的Cast可以在图优化阶段被消掉对于实在不支持的算子再考虑重写网络中用到的对应模块比如把注意力或者自定义激活函数替换成标准算子。3.4 状态归一化参数不能丢前面提到过observation normalization但这层太重要了必须单独再拎出来说一遍。许多双足强化学习项目里归一化的均值方差不是和actor网络一起保存的而是放在单独的buffer里。在PyTorch里推理时你通常是先对观测做归一化再输入actor但部署时如果只导出actor就必须在外部把归一化层的参数固化下来要么把它们作为actor的前置层一起导出要么在板端代码里先做一次(x - mean) / std再喂给模型。我建议直接把这个归一化操作写进actor的forward函数里再导出或者在ONNX前面拼接一个“归一化子图”这样到板端就少一个需要维护的步骤。我在实际部署时吃过这个亏训练时奖励正常、仿真里走得好好的导出后忘了带mean/std实机上机器人反应迟钝仿佛“梦游”。检查了很久才发现输入观测的尺度完全不对有些特征的量级被放大了几十倍。还有一个容易被忽视的点IMU数据的坐标系和仿真中的定义是否一致。如果你在仿真里用的重力方向是z轴向下但实机IMU装反了或者驱动输出的符号定义相反那么即使归一化参数对策略也会错乱。导出模型前一定要确认数据流每个环节的坐标系一致。4. RK3566实机运行环境搭建与踩坑4.1 系统镜像、root权限与开发板识别问题RK3566的开发板很多我这里用的是泰山派。买来第一件事是刷一个干净的系统镜像通常是Ubuntu或者Debian的ARM版本。刷机本身并不复杂但有一个很多新手都会卡住的问题板子插上USB后电脑提示识别到了rk3566设备但它是作为“ADB设备”出现的而不是烧录工具期望的“Rockusb设备”Loader模式。出现这种状况原因基本是设备没有进入烧录模式。正常流程是先按住板子上的maskrom按键或loader按键再给板上电让USB控制器进入下载模式。如果你只是直接用USB线连接板子系统正常启动后它自然会被识别成ADB设备——因为系统里的adbd服务起来了这不能用来烧录。解决办法很简单拔掉电源按住loader/maskrom键不松手插上USB线等待几秒后再松开这时候设备管理器里应该会刷新为Rockusb设备烧录工具就能识别了。root权限也是个绕不开的话题。RK3566默认镜像一般直接就是root用户或者可以方便地切换root。如果普通用户遇到权限问题常见的做法是adb root或者直接使用root账号登录。这个没什么好避讳的嵌入式Linux开发本来就需要拿到完整系统权限。拿到root之后建议立刻做两件事关掉不需要的开机自启服务释放CPU占用调高CPUfreq的governor为performance模式避免频率波动影响控制节拍。提示凡是涉及系统镜像烧录的操作请先确认你拿到的固件和板卡型号匹配尤其是DDR型号和存储介质EMMC还是SD卡不能选错否则有可能无法启动。4.2 控制线程的实时性与单核绑定RK3566虽然能跑Linux但它的实时性默认并不理想。Linux内核本身是分时调度系统控制线程可能被其它进程抢占造成偶发延迟。对双足机器人来说偶发延迟意味着什么意味着某个控制周期没有及时输出动作机器人就可能在那个瞬间失去平衡。我在实机调试时早期用普通线程跑200Hz控制循环肉眼可见机器人会“抖动一下”日志里也记录到个别控制周期延迟到了20毫秒以上。解决思路有三个层面。第一给控制线程设置高优先级用SCHED_FIFO这类实时调度策略第二将控制线程绑核到某个专用CPU核心避免内核把它在各个核心之间来回迁移第三减少同核上的其它负载比如把Wi-Fi、蓝牙、桌面环境等全部关掉。为了更彻底还可以在内核启动参数里加上isolcpus或者使用cpuset把某个核心完全隔离出来给控制线程用。如果你准备在RK3566上用Python写控制主循环需要特别小心Python的GC暂停和解释器GIL带来的不可控延迟。我实测Python的循环控制在低频50到100Hz还能用但如果目标是500Hz以上建议控制主循环用C写Python只负责配置加载和日志记录。很多Microduck开源方案的部署代码都会提供C版本就是为了规避这个问题。4.3 与下位机的通信串口、PWM与关节指令在部署链路中模型推理只占一小部分时间真正占时间的是“读传感器”和“发关节指令”的过程。Microduck的关节电机常见有两种驱动方式一种是普通PWM舵机由板卡输出PWM信号控制目标位置另一种是串行总线舵机或者带驱动的直流电机通过串口/CAN发送位置、速度指令并读取反馈。PWM舵机的优点是简单缺点是你很难读到关节角度只能“开环”地认为舵机转到了目标位置。这种情况下算法的状态输入里其实没有准确的关节角度只有目标位置控制效果会差很多。串行总线舵机要好一些能直接读到当前位置、电压、温度让控制闭环真正闭合。我调试时用的方案是串口与下位机通信先写一个简单的通信协议帧头、设备ID、指令类型、数据、校验。控制线程每周期做四件事读IMU、读关节角度、推理策略、通过串口发送关节目标位置。串口通信在Linux上也有“坑”。默认的串口驱动可能会有缓冲延迟你write之后数据不一定立刻发出。解决手段是设置串口的low_latency标志并关闭tty的流控。CAN接口同理需要配置好波特率并注意CAN帧的DLC对齐。实机跑起来之后我用示波器量了串口的发送间隔基本能稳定在5毫秒一次200Hz的控制频率对Microduck这种25厘米级别的机器人是够用的。5. 实机联调从GPU上的“数字翻跟头”到脚下真正站稳5.1 先做PD再做RL再谈鲁棒性我见过不少人把训练好的RL策略下载到实机就直接开跑结果机器人“啪”一下倒地然后他们开始怀疑策略不行。但在我看来实机联调的第一步不是RL而是一个简单的PD控制器。先用PD验证驱动、传感器、通信链路是否正常工作让每条腿的关节能转到指定角度、IMU数据能稳定读取、控制周期没有明显抖动。等到这些全部正常再切换RL策略。为什么一定要这样因为RL策略是端到端学习出来的控制律它的输入输出关系不像PD那样直观可控。如果底层驱动正负方向反了、关节零位偏了、IMU安装角度歪了PD控制器还能靠调试识别出来但RL策略会把这些错误当作“正常状态”的一部分去响应表现可能极其诡异你很难定位是模型问题还是硬件问题。所以哪怕你觉得PD很“传统”它依然是排查硬件最趁手的工具。在PD阶段我最先做的事情是给所有关节发一组正弦扫频指令观察关节响应是否平滑有没有卡顿、啸叫、抖动。然后让机器人保持一个矮蹲姿势测试重心和支撑脚的关系。最后接上遥控急停确保任何异常状态下都能立刻断电避免策略失控时烧坏舵机或撞坏结构件。5.2 训练奖励正常但实机抖动排查实录Microduck第一次切换RL策略跑起来时出现了一个很典型的症状仿真里跑步正常实机上却能站稳但站一会儿就会开始高频抖动随后朝一边摔倒。第一反应是PID增益问题但这个策略根本没有PID。然后怀疑控制频率不够但从日志看频率稳定在200Hz不像是这个问题。后来逐项排查发现问题出在IMU数据滤波上。仿真里的IMU数据是理想值没有加速度计噪声和陀螺仪零漂实机IMU却在每个控制周期都有细微的高频噪声。策略对机身角速度这个观测维度非常敏感IMU噪声直接变成了动作抖动。我在PD阶段没暴露这个问题是因为PD控制器的带宽低天然滤掉了一部分高频分量RL策略是纯比例式的状态映射对噪声几乎没有过滤能力。解决办法有两个方向一是在硬件层面选更好的IMU或者做振动隔离安装二是在软件层面加低通滤波或滑动平均。我用了一阶低通滤波截止频率设在30Hz左右同时把陀螺仪零漂在静止时校准掉。另一个“隐藏问题”是电机响应延迟仿真里我设的电机时间常数很小实机舵机却存在几十毫秒的响应延迟导致策略以为关节已经转到目标位置但实际还在路上。加上这个延迟补偿后机器人终于从“能站几秒”进步到“能持续站住并缓慢行走”。5.3 常见问题速查表症状可能原因解决思路板卡插上USB只识别成ADB板子没进入烧录模式按住loader/maskrom键再上电重新插USBroot权限操作失败系统普通用户权限不足adb root / 切换root账号 / 修改服务配置实机RL动作抖动IMU噪声、控制频率不足、量化误差低通滤波、提高控制频率、保留FP32推理机器人朝一个方向走偏IMU零漂未校准、关节零位偏移静止校准IMU重新标定关节中位模型导出后推理输出与PyTorch不一致导出了critic、丢掉了归一化层、量化精度损失只导出actor、固化归一化统计量、改用FP32控制偶发卡顿其它进程抢占CPU绑核、SCHED_FIFO、关Wi-Fi/桌面服务串口发送不稳定tty缓冲、流控开启设置low_latency关闭流控掉落时奖励异常但策略正常reward只在训练中用实机不受影响无需处理但需检查观测是否异常IQL数据集为空或质量差数据中大部分是失败样本混合人工遥控、在线PPO采集数据再精修5.4 我真正想强调的一支配平问题最后聊一点“偏经验”的东西。强化学习机器人部署和普通深度学习模型部署有一个特别不一样的地方它是一个闭环系统。模型推理的微小误差并不会在一次推理后就消失而是会进入下一帧的观测被系统自身放大或衰减。很多在单帧测试里看起来完全没问题的部署误差比如0.01弧度的角度差、1%的延时抖动在闭环里可能被放大成灾难性的摔倒。这提示我们不要只盯着单帧推理精度而要用整个“控制周期”的视角去评估部署质量。怎么评估让机器人带着遥测数据跑一段把实机观测序列记录下来然后在GPU仿真里用同样的观测序列做“开环回放”对比策略输出的动作是否一致也可以做“闭环回放”把仿真环境的初始状态设成和实机一样注入同样的扰动看仿真里的表现是否能复现实机。如果仿真里稳定、实机不稳那问题大概率出在观测质量或执行延迟上而不是策略本身。部署RL机器人给我最大的体会是强化学习本身在GPU上训练时显得“高大上”但真正让它落地靠的反而全是那些最朴素的工程手段——滤波、标定、线程优先级、通信协议、归一化参数导出。把这些做扎实了策略网络自然就站住了。经验就一句话“仿真里解决不了的实机上也解决不了实机上的问题大多不是强化学习的问题而是系统集成的问题。”如果有机会再做一次我会在一开始就准备一个完整的遥测系统把每一帧的观测、动作、控制周期、IMU原始数据全部记录下来而不是等出问题了才去补日志。这不只是为排查用的它还能给你下一轮训练提供真实数据往IQL这类离线强化学习的方向走用实机数据做策略精修才是让Microduck越跑越稳的最短路径。