真机在线策略学习系统：从仿真到部署的强化学习闭环设计与工程实践

先说个我自己的经历。前两年在一条自动化产线上做视觉抓取项目仿真环境里策略的评价指标已经非常漂亮放到真机测试的第一天就抓飞了两个料盒其中一个还差点砸到防护栏。当时第一反应是参数没调好后来才意识到问题根子不在某个参数而是整个系统缺了一条“真机数据回流并持续优化策略”的链路。模型上线之后就不再更新环境一变性能就崩。这也是为什么我现在看到 RLinf-USER 这类“真机在线策略学习系统”会格外关注。它解决的不是“怎么把模型训好”而是“模型部署到真实环境后如何安全地边运行、边积累经验、边更新策略”。RLinf-USER 这个名字拆开看也很有意思RL 好理解强化学习inf 我倾向于理解为推理/部署链路inference 或 deployment infrastructureUSER 代表真实用户场景。合起来就是一套面向真实场景、把强化学习推理与在线训练打通的系统。这篇文章我想从工程落地的角度把这类系统背后要解决的核心问题拆开聊一遍为什么需要真机在线学习、闭环架构怎么搭、数据飞轮怎么设计、安全边界怎么画、策略更新怎么才不崩、收益怎么评估。无论你是做机器人控制、工业自动化还是搞具身智能、在线决策系统应该都能找到能直接抄走的经验。1. 为什么仿真里 SOTA 的策略上真机就翻车在线学习的起点1.1 sim-to-real gap 不是玄学是数据分布偏移很多人以为 sim-to-real gap 是仿真器不够精细其实不全对。仿真做得再细光照、摩擦、材质、装配公差这些变量也不可能枚举完整即使你用 domain randomization 把颜色、纹理、物理参数都随机化也仍然覆盖不了真机系统随着时间产生的变化——关节磨损后摩擦力变了、电机发热后响应曲线变了、传送带上工件的到达节拍漂了这些是仿真建模阶段根本想不到的。从概率角度看仿真和真机的差距本质上是状态分布和动力学分布的偏移。你用一个离线仿真数据集训练出一个策略这个策略只能保证在训练分布附近表现好。上了真机观测分布一旦偏离训练分布策略给出来的动作自然不可信。很多团队为了提高鲁棒性在仿真里疯狂加大随机化力度但现实世界的“开集”特性决定了无论仿真怎么加噪总会有分布外的 corner case。1.2 部署只是开始环境会漂移策略必须跟着变传统 ML 系统有个概念叫 concept drift在线学习本来就是应对漂移的常见手段。到强化学习场景这个需求更迫切因为强化学习策略不仅受环境漂移影响它本身还会改变环境的状态分布——一个动作没做好整个轨迹都偏了后续一连串状态全变了。所以真正的系统设计思路应该是部署不是训练的终点而是训练的一个新阶段。RLinf-USER 这类系统把“真机运行”当作持续的数据采集通道把每一次成功或失败都变成一条带标注的经验样本再定期用这些新经验去微调或重训策略。这样做的好处非常直接策略始终对齐当前真实环境的数据分布而不是停留在几个月前的仿真分布上。用个不恰当但好理解的类比传统仿真训练像是“题库刷题”你刷的题再全考试时遇到新题还是可能懵真机在线学习则更像“边做题边把错题回收、定期重做”考场上碰到的题目风格变了你的解题策略也跟着变。1.3 哪些任务最需要真机在线学习不是所有强化学习任务都适合真机在线学习。我目前看到的典型受益场景大多具备三个特征场景特征典型任务举例为什么在线学习有价值任务半结构化但状态组合多机械臂抓取、分拣、装配仿真训不完所有摆放组合真机数据能持续补齐长尾环境存在周期性或趋势性漂移户外移动、物流仓储、巡检光照/季节/设备磨损变化离线策略很快过时试错成本和容错阈值可控工业分拣、服务机器人导航只要安全层兜底允许少量次优行为换取策略提升反过来医生手术机器人这类试错成本极高的场景现阶段谁也不敢让它在线自由探索那是另一套逻辑后面再细说。2. 真机在线策略学习系统的骨架训练、部署、回流如何闭环2.1 一条轨迹从真机流回训练端需要经历什么先快速过一遍 RLinf-USER 式系统的基本数据流方便后面展开。真机端运行一个 rollout worker它装载当前发布版本的策略模型按控制周期做推理并下发动作指令。每一步的观测、动作、奖励信号、以及额外的运行元数据安全层是否触发、是否有人工接管、是否发生异常告警被一起打包成一条轨迹样本。轨迹样本通过消息通道传输到数据存储层落地保存。真机数据每一帧都贵所以通常不做实时丢弃。训练端定期从经验池中采样结合精心设计的奖励信号进行策略更新。新模型产出后先走离线评测门禁再灰度部署到真机端替代旧模型开始新一轮数据采集。这个循环如果画出来就是一条“采集—回流—训练—评测—部署—再采集”的飞轮。和纯离线训练相比多出来的最关键环节有两个一是回流阶段必须带安全相关的元数据二是发布阶段必须设置门禁与回滚机制。这两点任何一环缺了飞轮转不了几圈就会出事故。2.2 为什么不能做成同步在线更新而要异步发布我见过不少团队最初图省事想做成“每跑几步就用最新数据在线梯度更新”以为这样最实时。真在真机上试过就知道这条路基本走不通。原因有三个。第一真机数据产生速率极低。仿真一秒钟能跑几百条轨迹真机一条完整任务可能就要几十秒到几分钟。在这么稀疏的数据下做频繁更新梯度噪声极大基本等于瞎跳。第二同一时间只有一份正在执行的策略它产出的数据反映的是旧策略的行为分布。如果拿到几条样本就立刻更新参数很容易陷入局部震荡。异步架构里learner 和 rollout worker 解耦训练端可以攒够一批足够多样化的样本再做一次相对稳定的更新而不是被单条样本牵着走。第三也是最重要的同步更新意味着模型参数每一秒都可能变安全和评测机制完全没法介入。没人敢在一个正在执行任务的机械臂上每秒钟换一次网络权重。所以成熟的做法一定是数据异步回流、策略定期发布。也就是第2.1节里那条环形链路中训练端与采集端之间用队列解耦新模型必须经过门禁评测和灰度发布才能重新回到真机。2.3 各模块的职责边界与工程选型还是按 RLinf-USER 这类系统常见的工程分层来拆一下我列一张对应的表每行都写清楚模块做什么、容易踩什么坑。模块核心职责容易踩的坑可参考的选型思路真机采集端执行策略推理、采集轨迹、执行安全保护数据采集协议不规范轨迹字段缺失统一 protobuf 轨迹协议强制记录安全事件标记数据回流与存储轨迹落地、元数据管理、长期存储把真机数据当仿真数据直接覆写覆盖版本化对象存储按任务/场景/日期分桶训练端从经验池采样、更新策略、维护评估指标采样分布失衡只学到最近几天场景分层采样 锚定集兜底策略版本管理记录模型参数、训练数据、评估结果、准入/回滚版本信息不完整回滚找不到对应配置每次模型登记类似 model card 的完整 metadata评测与门禁服务发布前自动跑评测集判断是否允许发布评测场景与真实业务分布脱节评测集从真机历史数据中按场景维护安全守护进程硬性约束检测、异常检测、急停联动与训练链路断开安全事件不回流与数据采集端同步打点形成安全日志工程选型上我多说一句真机场景的数据量通常远小于互联网大数据量场景没必要一上来就上重型消息队列。Redis Stream 或者 Nats JetStream 这类轻量方案往往更合适先把闭环跑通再按需升级。真机离线数据的长期存储倒是要认真做这部分数据未来是做评估集、搜索回溯和再训练的基础资产宁可多存不可丢。3. 真机数据太贵了数据飞轮怎么设计才能让每个 episode 都值钱3.1 真机上一条轨迹该记录哪些额外信息在仿真里跑一条轨迹我们通常只关心 observation、action、reward、done 这四个字段就够了不满意可以重跑。真实环境不行一条轨迹要占用真实时间、真实设备、真实人工关注成本所以每条真机轨迹记录的信息必须比仿真更多否则白跑。结合我在产线和移动机器人项目上的经验建议至少补充这几类元数据安全事件标记当前时刻安全层是否被触发、是否发生过人工接管、是否触发过急停。异常状态片段运行过程中有没有出现传感器断流、动作超时、速度跳变等异常。人为评价标签一段任务结束后由操作员打标是成功、失败、可接受次优还是实验性行为。环境上下文诸如光照强度、负载重量、工位编号、时间戳这类可用于场景聚类的外部变量。这些额外信息不只是为了事后审计它们本身就是训练信号。安全层触发标记实际上指出了“策略试图做一件违反安全边界的事”人工接管标记则说明“你的策略在这个状态下给的解是操作员不满意的”。把这些信息填充到经验池里模型就能学会在分布边缘绕开危险行为而不只是靠稀疏奖励硬猜。3.2 奖励信号从哪来规则、奖励模型与干预信号真机在线学习最棘手的问题之一是奖励信号稀疏或缺失。工业场景里你不可能让操作员给机器人每一步打个分连续轨迹标注的成本高到不现实。通常实用的方案是三层递进。第一层优先用规则从业务系统的实际输出中自动生成奖励。比如分拣任务里可以用出口传感器是否检测到目标物、夹爪力控读数是否在目标区间、工位完成信号是否触发这些信号本质上是现场系统里已经存在的反馈不是额外造出来的。这类设备级信号有几个就用几个不追求积分奖励函数的完美关键是提供一个梯度方向。第二层对无法由规则覆盖的中间过程可以训练一个奖励预测模型。用历史轨迹加上人工事后批量标注的结果学习一个从观测到“任务质量预期”的映射。这种模型不需要精度极高只要能区分“这轮大概率偏了”和“这轮方向是对的”就足够支撑训练。第三层别忽略干预信号。在 RLinf-USER 这类系统的实践中操作员是否介入、安全层是否触发本身就是很好的惩罚信号。可以用一个奖励项来惩罚人为接管发生的频率相当于告诉策略“你让人类出手的次数越少越好”。这比硬调动作约束柔和得多也更符合真实工程需要。3.3 经验池不只是缓存场景分层、时效衰减与锚定集很多人把经验池等同于一个时序缓存按时间存进去再按时间取出来。在真机场景里这样设计效果会很差。真机数据的场景分布天然是不均匀的。一个分拣任务可能在90%的时间里都是同一种整齐摆放的工件只有10%是乱序堆叠但这10%恰恰是最有价值的长尾数据。经验池如果只按时间顺序均匀抽样训练会被高频简单场景淹没。更合理的做法是按场景分层分桶抽样的同时保证每个场景桶里都有一部分样本进入训练批次。另外还要给数据加上时效权重。当前策略的表现主要受最近一段环境状态影响太久之前的数据可能包含已经失效的环境规律但如果完全丢弃旧数据又可能灾难性遗忘。经验池里可以设一个时效衰减系数让采样概率随时间回落同时保留一定比例的长期锚定样本确保核心能力不退化。锚定集这个概念值得单独提一下。它不是一个训练数据集而是一个覆盖了各难度等级、各场景类型的固定评估集。每次策略更新后先用锚定集做一次快速验证看这个新模型有没有在解决新问题的同时弄丢了老技能。这个做法相当于给“边学新东西边忘旧东西”的问题上了一道保险。4. 部署推理链路里那些容易被忽略但致命的工程细节4.1 延迟预算策略推理在一个控制周期里只该占多少真机在线策略学习系统里模型推理往往不是瓶颈但推理延迟的稳定性很容易被忽略。通常一个机器人控制回路都有固定周期比如典型机械臂控制周期在 8ms 到 20ms 之间移动机器人可能宽松到 50ms。整个控制周期里要留给感知、状态估计、策略推理、安全校验和执行指令传输的时间。策略推理如果占掉超过周期一半的预算其他环节就会被严重压缩最终导致整个控制回路不稳定。所以在线学习的模型不能只考虑训练精度还要考虑端侧推理约束。实际操作中如果策略网络是一个多层感知机加编码器输入输出维度不高单次前向大概只需要几毫秒一般可以通过 ONNX Runtime 或 TensorRT 部署在工控机或嵌入式设备上。如果策略依赖高分辨率视觉输入需要先用一个轻量编码器做特征提取再进入策略网络不要直接把原始图像塞进一个大模型里跑实时控制。下表是我常用的端侧选型思路硬件平台推理引擎典型单次耗时区间注意事项Jetson Orin 系列TensorRT2~8ms需要校准量化float16 精度下一般可控普通 x86 工控机ONNX Runtime3~10ms注意 CPU 亲和性和线程池抖动更高性能工作站TensorRT / Triton1~5ms如果走云端必须评估网络抖动不建议核心控制环依赖控制回路里我自己的经验是要专门监控“推理时延的最大值”而不是只看平均值。很多偶发卡顿平时不体现一旦真机上出现一次超过控制周期的推理延迟带来的可能就是动作突变。4.2 归一化参数不一致最隐蔽的模型行为漂移这一步我不知道坑了多少团队。策略网络训练时几乎一定会做观测归一化把状态减去均值除以标准差。仿真训练时这套均值和标准差是从仿真数据统计出来的部署到真机后如果模型包里没有带上这些归一化参数或者在线更新时归一化参数被覆盖成新分布那策略看到的输入分布会完全乱掉行为表现会变得不可理喻。我见过一个真实案例模型本身没有变化只是有人在另一台机器上重新统计了一次归一化参数结果同一份模型在真机上从“正常”变成“疯狂抖动”。排查了很久才发现是归一化层参数不一致。处理方式包括两种。数据分布相对稳定的场景训练好模型后把归一化参数冻结作为模型包的一部分随版本发布不许在线更新时悄悄改动。环境持续漂移比较明显的场景则可以把归一化统计做成滚动更新的形式但要通过配置明确声明这个参数已变化并且发布前做离线校验。不要自作主张地让推理代码和训练代码共享同一套全局归一化变量这是最容易出事故的设计。4.3 新策略上线不是简单换模型灰度发布与平滑切换在线学习系统里模型更新不是“新模型杀旧模型”这样一刀切。策略行为分布一旦变化过大机器人的动作模式会突然改变这种突变在真实设备上是非常危险的。灰度发布可以参考互联网服务的思路但要做改造。比较实用的做法是先在少数几台设备或少数几个固定任务上跑新策略收集足够多的安全指标后再扩大到全量。单台设备数量少的情况下可以考虑“时间灰度”例如新策略每轮任务先跑 10 个回合评估安全层触发率和人为接管率全部达标再切换。还有一个细节是策略切换过程本身要平滑。新旧策略如果行为差异很大可以在部署层做一段时间的动作插值让执行动作 (1 - α) × 旧策略动作 α × 新策略动作α 从 0 慢慢升到 1。这种“软切换”能避免机器人因为策略突然替换而发生剧烈的关节加速度跳变。这里要注意的是插值期不要做训练数据的采集因为此时执行的动作并不完全来自某个单一策略数据标记会失真。5. 真机试错的边界安全层与探索策略怎么共存5.1 先定安全边界再谈策略优化真机在线学习和仿真训练有一点本质不同仿真里你允许策略随便试错试错成本只是算力真机上策略随便试错代价可能是设备损坏甚至人员受伤。所以安全层必须独立于策略网络存在并且永远拥有最终控制权。我建议把安全层设计成一套确定性规则系统而不是再训练一个神经网络来判断。逻辑很简单安全是底线问题底线的可靠性不能依赖“概率是否正确”。位置限位、速度限幅、力矩限制、关节角度边界以及末端执行器是否进入禁区这些都应该用状态机加阈值检查来实现。策略网络输出的动作先经过安全层如果安全层判断越界就截断或修正这个动作而不是真接执行。安全层要记录每一次拦截行为并把拦截数据回流到训练端这部分数据是策略改进的重要依据。5.2 探索不是“加随机”而是“受约束地偏离”强化学习一定有探索但在线系统的探索策略需要和安全层联动。传统 RL 算法里常见的做法是在动作空间加高斯噪声这类无差别随机扰动在仿真里问题不大在真机上就非常麻烦噪声经常会驱动策略靠近安全边界然后被安全层截断导致模型永远学不到安全层纠正后的真实动作分布。一种可行的替代思路是把探索扰动看成一个独立的输入信号它先和安全层检查逻辑结合只有通过安全检查的探索分量才真正叠加到动作上。也就是说探索的目标不是让机器人“乱动”而是“在安全边界允许的范围内偏离当前策略”。这个偏离幅度还可以根据机器人所处状态的风险等级自动调节比如靠近障碍物时噪声幅度变小空旷区域时噪声幅度可以大一些。实际项目中更稳妥的做法是探索主要放在仿真环境里完成真机上线后先小幅降低探索噪声用相对保守的策略积累第一批数据当安全层触发率稳定下降后再逐步放开探索幅度。不要一上来就让真机策略处于高探索状态。5.3 状态异常识别与收尾动作不要让最后一个动作毁掉整个迭代真机在线学习除了常规安全约束还需要处理一个容易被忽略的问题——模型遇见了它从未见过的观测状态或者自身参数更新后出现了异常输出。这种情况下继续执行策略动作风险非常高。所以系统里至少要有一个独立的异常监控模块实时计算当前观测与经验池中历史观测的分布距离并检测连续几步动作是否存在异常跳变。一旦发现分布距离过大或动作跳变量超过阈值立即切换到一个预设的保守策略或者触发人工接管而不是让当前模型继续操控设备。这个逻辑在软件层必须做到所有热更新和模型发布流程之外持续运行。动作跳变检测有一个细节阈值不要用手工拍脑袋定死最好在模型发布前跑一遍离线对比看新旧模型在相同历史轨迹输入下的动作输出差异由此推算需要多少阈值才能容忍正常差异同时识别异常。如果新旧模型本身差异就大说明训练步长走大了正确动作不是调高异常检测阈值而是让训练过程更保守。6. 策略更新为什么容易学崩在线训练稳定性与发布门禁6.1 更新崩溃的底层原因目标策略漂移与价值高估真机在线策略学习多数组件都可能出问题但最让人头皮发麻的往往是策略更新本身学崩了。具体表现通常是新模型上线后连续几个 episode 表现都很差甚至比旧模型差了一大截回滚之后还找不到明确原因。从算法原理上拆在线场景的更新不稳定主要来自两个因素。一是目标策略漂移。真机数据永远是由某个“老版本策略”采集的当训练端拿这批老数据更新策略时如果更新步长太大新旧策略的分布差异会迅速拉大重要性采样比率的方差随之暴涨最终导致 loss 爆炸。仿真里 PPO 能容忍相对激进的更新步长因为数据可以重采真机数据是老策略采的没法重采这就对策略更新的保守程度提出了更高要求。二是价值函数高估。Critic 网络在使用自举更新时天然存在高估偏差这种偏差在数据分布变化频繁的在线场景会被放大。一旦价值估计偏了策略梯度方向就会跟着偏离形成恶性循环。PPO 类的 clip 机制对这个问题有一定抑制但不够彻底。实际项目中我更愿意同时叠加保守的离线学习约束比如对策略更新前后的 KL 散度设硬上限超过就提前停止本轮更新。简单说如下策略更新幅度必须显式约束只靠 PPO 的 clip 阈值不够。Critic 网络需要独立的早停机制价值函数 loss 异常上升时不要继续用这批数据训练。每一轮在线更新结束都要跑锚定集回归避免顾此失彼。6.2 发布门禁新模型上线之前先过这几关在我现在做过的真机在线学习系统里模型版本从训练端出来之后不能直接上真机必须先经过一个自动化的门禁服务。门禁是纯规则的没有人为拍板的空间这样才能保证策略迭代过程的一致性和安全性。下面是一份示意性的门禁配置gate: safety_event_rate: max: 0.01 # 安全层触发率不超过 1% human_intervention_interval: min: 20 # 平均人工接管间隔不低于 20 个回合 action_delta_ratio: max: 0.15 # 新旧模型在锚定集上平均单步动作差异不超过 15% anchor_success_ratio: min: 0.90 # 锚定集成功率不低于 0.90 entropy_lower_bound: min: 0.80 # 决策熵不低于 0.8防止策略过早收敛 critic_loss_trend: max: rising_limit # critic loss 最近 N 轮不能持续上升这里的数字只是示例不同任务的量级完全不同。但有几类门禁指标是通用的安全指标、行为差异指标、能力回归指标、置信度指标。所有门禁全部通过模型才能进入灰度发布通道。门禁原理并不复杂但从系统设计上说非常关键。它相当于给“训练飞轮”装了一个刹车防止有人训练参数调激进后把一个半成品策略推上真机。尤其是动作差异门禁我要特别提一句如果新旧模型在锚定集上的动作差异过大哪怕新模型离线指标更好也需要谨慎。因为动作差异大意味着策略行为模式跨了比较大的台阶真机上可能出现训练分布里看不出的问题。6.3 在线训练超参怎么调一个稳定起步的配置思路很多团队把在线训练的超参直接照搬仿真这在我看是最容易踩的坑。仿真理想要的是“快”在线真机要的是“稳”是“每轮更新都在前进而不是大起大落”。以下是我自己项目里冷启动时常用的一组策略不一定最优但至少稳定。更新频率上不要攒到几十条轨迹就急着训练。建议至少等经验池积累到能覆盖足够多的场景类型后再做一轮更新。每次训练的迭代轮数要明确设上限比如 10 到 20 轮不要等 loss 收敛到很小才停因为在线数据的分布非平稳过度拟合最近数据是常态。学习率和 clip 阈值都比单独的仿真任务设置更小。比如 PPO 的 clip 参数从常用的 0.2 降为 0.1 或 0.15学习率可以从 3e-4 降到 1e-4 附近。每轮更新时额外做一步新旧策略的 KL 约束检查如果 KL 超过设定上限这一轮训练就要提前中断并降低后续学习率。熵系数也要盯住。在线训练时模型很容易突然变得过于自信策略熵直线下降这种模型看起来能做出明确决策实际上已经失去了对未知局面的适应能力。训练日志里如果发现策略熵低于某一个下限不要急着继续更新应该先检查是不是数据分布太单一或是奖励尺度放大导致 loss 权重失衡。7. 效果怎么衡量成功率高不代表系统好成本账也要算清7.1 别再只盯成功率多维指标才有解释力真机在线学习系统上线后怎么判断它到底有没有用只看“任务成功率”很容易误判。原因是成功率是一个终局指标它不反映过程中消耗了多少人工干预、发生了多少次安全层拦截、以及每次策略更新是稳住了还是大起大落。建议至少维护四个维度的指标。维度指标说明任务层成功率、完成质量分最终效果但反馈滞后安全层安全层触发率、人工接管次数反映策略是否在安全边界附近试探稳定性策略回滚率、单步动作变化率反映训练过程是否健康成本层每轮更新消耗的数据量、占用的真机时间决定这个系统长期投入产出比这里我想强调“安全层触发率”。这个指标很灵敏如果某次策略更新后安全层触发率从 0.5% 突然升到 5%哪怕成功率还没下降也已经说明新策略的行为模式在向危险方向漂移。成功率由于反馈滞后可能要再过几十个回合才能体现出来而安全层触发率几乎是立即可见的。7.2 收益测算示例一个技能从 60 分到 90 分需要付出什么以假想的分拣项目为例。一个机械臂在仿真预训练之后直接部署到一条真实产线初始成功率大概在 70% 左右人工干预频率一小时两三次安全层偶发触发。随后引入类似的在线策略学习闭环用真机数据持续微调模型大概经过两周、累计几千条真实轨迹之后成功率逐渐上升到 90% 上下人工干预频率下降到一小时不到一次。到这一步系统的价值已经非常好算人工成本下降、节拍提高、损耗降低。但这个过程中要付出的代价也不小。第一周模型性能有明显波动成功率一度从 70% 掉到 60% 以下后来通过回滚旧版本并限制更新幅度才稳住。这说明在线学习不是“免费的持续优化”它需要有人盯守、有门禁兜底、有回滚通道。如果预算里没有安排这些前提收益测算就不能只看最终成功率。我一般会建议团队在立项时给自己画一条“回落容忍线”想清楚策略中途变差能不能接受如果不能接受需要准备多少人工干预资源来兜底。7.3 哪些项目不适合真机在线学习果断放弃真机在线学习不是银弹。我自己判断一个项目适不适合会先回答下面几个问题反馈周期是否太长。一个回合如果跑完要几小时甚至几天那在线数据积累的速度完全撑不起模型迭代不如先把精力花在更好的仿真建模上。失败成本是否不可接受。像手术、核心设备的危险工艺段一旦一次失败就损失巨大再怎么用高安全阈值约束现阶段也不适合直接用在线强化学习去试。状态是否可完全观测。真机在线学习非常依赖状态估计的准确性如果环境里大量信息根本观测不到策略看到的状态分布和真实状态分布严重不一致在线学习只会让模型记住错误的关联。如果这三个问题里有两个以上踩中了我建议先不要上真机在线学习系统而是老老实实做仿真预训练加人工规则兜底。8. 如果你想做同类型系统这4件事越早落地越好8.1 安全事件日志从第一天就开始结构化管理很多团队做在线学习系统时把所有精力先投入到训练和模型迭代上安全层只在现场用一台工控机跑着没有做结构化日志。等到策略学崩或发生异常时才发现完全无法回溯“当时策略为什么要输出这个动作、安全层拦了什么、操作员做了什么”。安全日志和轨迹日志必须同构、同时间线、可联合回放这是一个系统能不能在“事故后复盘并改进”的分水岭。8.2 先蒸馏出一个适合实时推理的小模型真机在线学习的模型不能只追求训练精度还要看能不能在控制周期内跑完。不要把仿真里的超大网络直接搬到真机上然后期望在线训练能弥补端侧算力缺口。比较高效的路径是仿真里先用大模型把任务能力训出来再蒸馏成一个真机端可实时推理的小模型然后用真机在线数据持续微调这个小模型。这样训练端的算力预算和端侧延迟预算可以分开控制在集群上用大模型辅助标注和奖励设计在端上用轻量模型做执行两边各司其职。8.3 把离线回放评测集当作最高优先级的资产真机数据太贵而且不可能随时重测。所以平时每次真机运行后都要把轨迹按场景质量分层筛选出一批具备代表性的数据组成锚定评测集留着评估后续每个模型版本。这个评测集的建设优先级应该高于模型训练本身。因为没有它你没有办法判断一个候选策略上线前到底行不行只能“先上真机看效果”这是拿设备安全开玩笑。8.4 模型回滚必须是一条低摩擦的常规路径在线学习系统里模型版本回滚不是失败处理而是日常发布流程的一部分。每个版本的模型包都要包含参数权重、归一化参数、训练数据统计信息、门禁评测结果、上线时间和对应代码版本。回滚操作必须能做到“点一个按钮就回到上一个已知良好版本”并且回滚后要自动补采集一段时间数据确认环境没有变化导致旧版本也不适用。很多团队前期图省事把所有版本管理都放本地文件夹里乱放一旦出问题连自己都找不回来这是最不应该出现的基建缺失。我个人的体会是真机在线策略学习系统真正难的不是强化学习算法本身而是把“数据采集、安全兜底、模型发布、评估回滚”这一整套工程机制打磨到能稳定自动运转。你在仿真里可以接受算法偶尔抽风在真机上不行。把上面这些链路从第一天就搭好后面做策略迭代才会越来越顺否则大概率会一直陷入“调参—上线—出问题—回滚”的循环里出不来。