简介：这是一份基于Unity与MLAgents框架的自动驾驶训练系统源码，面向自动驾驶、强化学习方向的开发者与研究者，也适合希望借助虚拟环境快速掌握智能车辆训练方法的初学者。项目完整覆盖了Unity环境搭建、Python模型训练与Windows环境推断三个环节，支持DDPG、PPO、TRPO等主流强化学习算法，并提供trainer.py训练脚本，可借助Linux服务器开展规模化训练。资源共199个文件，压缩包仅3.94MB：其中150个py脚本承担训练器、算法封装与数据处理，29张png图片记录场景截图和结果曲线，12个md文档整理项目说明与实验报告，另外还有4个pyc缓存、2个C#交互脚本和2个meta配置，便于Unity场景集成与部署，整体目录结构清晰。目前已有97人学习下载，适合复现MLAgents自动驾驶流程、参考源码进行实验对比，或在此基础上扩展新算法与仿真场景，快速上手虚拟环境下的智能车辆训练。
1. 用 Unity 和 ML-Agents 训练自动驾驶：一套开源方案能解决什么
很多人听到“自动驾驶训练系统”，第一反应是必须有庞大的车队、昂贵的仿真平台和成堆的激光雷达数据。但实际做下来你会发现，用 Unity 加 ML-Agents 这套开源组合，在普通游戏笔记本上就能完成从环境搭建、强化学习训练到模型导出部署的完整闭环。这个标题指的并不是什么遥不可及的研究项目，而是一份可以直接跑起来的源码工程：车辆模型、赛道场景、传感器配置、训练脚本全都在里面，你只需要把环境搭好，改一改自己关心的参数，就能训练出一个在固定场景内学会循迹、避障和刹车的决策策略。适合谁？适合想搞懂强化学习如何落地到真实物理环境的学生、刚入行的自动驾驶算法工程师，以及需要快速验证决策逻辑的中小团队。这套系统的本质是：用 Unity 的物理引擎当黑匣子，用 ML-Agents 的 PPO 算法教一个 Agent 从传感器输入学会油门、刹车和转向。
2. 为什么自动驾驶训练系统要选 Unity + ML-Agents：架构和选型理由
2.1 仿真环境为什么是决策模型训练的刚需
强化学习训练自动驾驶策略，最怕的是让模型在真实世界里“试错”。一次碰撞可能就是几万块的维修成本，而模拟环境里碰撞只是重置一下车辆位置。Unity 的价值不只是画一个好看的 3D 场景，它带有一套物理引擎来处理车辆动力学，包括摩擦力、重心偏移、碰撞响应，这些是决策模型真正依赖的“手感”。相比之下，纯逻辑层面的仿真（比如用 Python 写一个二维格子世界）学出来的策略天然和真实车辆行为脱节。
选型时常见做法是在 Unity、Gazebo、AirSim、CARLA 之间做对比。Unity 的优势在于编辑器成熟、大规模场景加载快、传感器组件直接拖拽配置，社区里针对 ML-Agents 的训练管线是成体系的。另一个现实因素是门槛，Unity 本身免费，ML-Agents 的训练端基于 Python 和 PyTorch，不需要额外买授权，对于预算有限的团队来说，这是能持续迭代的路线。它固然不如 CARLA 那样自带高精度传感器模型，但胜在改造成本低、场景定制自由度高，一份源码拿过来，半天就能把训练语句跑起来。
2.2 ML-Agents 的核心工作流：Agent、Behavior、Sensor、Reward 四件套
ML-Agents 框架把强化学习的各个环节做成了 Unity 组件，理解这套源码的钥匙就是搞清四个概念。Agent 是学习者，等同于强化学习里的 Actor，它挂在车辆 GameObject 上，负责收集观察、执行动作、接收奖励。Behavior 是 Agent 和训练器之间的通信配置，决定了对这个 Agent 用什么样的决策频率和动作模式。Sensor 是输入通道，可以是射线传感器、摄像头，也可以是自定义的向量观察。Reward 则由你在 Agent 脚本里写逻辑来驱动，这也是整个系统里最影响训练效果的部分。
一辆自动驾驶车辆挂上 Agent 组件后，训练流程是：Unity 环境里每走一步，Sensor 把前方路况编码成 Observation，Agent 把 Observation 传给 Python 侧的训练器，训练器通过当前策略神经网络算出一个动作（通常是方向盘角度和油门大小），返回给 Unity 执行，然后根据车辆状态（是否偏离、是否碰撞、是否到达）给一个 Reward，再把这组数据存进经验池用于更新策略。整个循环以固定频率跑，直到策略收敛。源码包里已经有这一整套预设，你要改的只是上车、传感器参数、奖励权重和训练超参。
2.3 传感器选型：射线阵列、视觉相机还是激光雷达扫描
自动驾驶训练系统的传感器方案直接决定观察空间的维度，也决定训练速度和最终策略的泛化能力。源码包里常用的有三种，各有适用边界。RayPerceptionSensor 3D 是性价比最高的起步配置，它在车头/车周发射一圈射线，检测与障碍物的距离和命中标签，把连续的 3D 空间压成几十上百维的一维数组，训练稳定且速度极快。CameraSensor 走的是视觉路线，把屏幕画面渲染成图像作为输入，更接近真实自动驾驶的视觉感知形态，但观察维度膨胀到几十万维，训练慢、对 GPU 显存要求高，通常需要额外的视觉编码器配合使用。雷达模拟则通过大量射线带噪声参数模拟点云，是对真实传感器最忠实的一类，但训练成本也最贵。
我一般建议新手或者只有普通游戏显卡的开发者，优先把射线阵列作为主传感器，原因很实在：PPO 算法在低维连续观察下收敛极快，很多问题（比如奖励设置错了、碰撞检测没生效）能在半小时内暴露，不会因为训练时间太长而隐藏真实原因。等基线策略跑通，再换视觉输入不迟。传感器维度对训练时间的影响，用表格看更直观：
| 传感器方案 | 观察维度 | 训练速度 | 部署真实度 | 适用阶段 |
|---|---|---|---|---|
| RayPerception 3D | 低（几十到几百） | 快 | 中 | 基线策略、奖励调优 |
| CameraSensor | 高（几万到几十万） | 慢 | 高 | 视觉感知专项验证 |
| 射线+相机融合 | 中高 | 中 | 高 | 最终效果打磨 |
从这套源码的实际布局看，绝大多数训练配置默认走是多射线方案，训练脚本里同时保留了对 CameraSensor 的抽象接口，方便后续切换。
3. 把源码跑通：从环境搭建到训练曲线出现，再到模型导出
3.1 环境对齐：Unity 版本、Python 包和 mlagents-learn 的版本匹配
拿到这套源码，第一件事不是打开工程，而是先把训练链路两侧环境对齐。左侧是 Unity 编辑器，右侧是 Python 训练器。两边的通信依赖一个版本匹配的协议，Unity 侧用的是 com.unity.ml-agents 包，Python 侧是 mlagents 库和 mlagents-envs 库，只要三者主版本不匹配，最常见的报错就是 gRPC 握手失败或消息格式不兼容。
常见做法是先建一个干净的环境来装依赖，避免污染已有环境。Python 侧安装命令我会固定写成先升级 pip 再装包，这样能少踩很多依赖冲突的坑。安装完成后，用mlagents-learn --help验证命令行是否可用，同时确认 Unity 包在 Package Manager 里的版本号能和 Python 侧对应上。这一条别跳过，源码包再多，版本对不上也是白搭。
python -m venv mlagents_env source mlagents_env/bin/activate # Windows 下改用 mlagents_env\Scripts\activate pip install --upgrade pip pip install mlagents==0.30.0 mlagents-envs==0.30.0 mlagents-learn --help逻辑说明：这条命令创建了一个独立的虚拟环境，专门用于 ML-Agents 训练。mlagents==0.30.0是训练器主包，mlagents-envs是负责和 Unity 通信的桥接层，所有训练命令最终都通过mlagents-learn入口发起。参数说明：如果你手里的 Unity 包版本更高或更低，Python 包版本要跟着换到同一主版本号，我这边实测 0.28.0 到 0.30.0 之间的小版本在训练协议上略有差异，最稳的做法是打开 Unity Package Manager 看实际安装的 ML-Agents 包版本，再倒推 Python 侧版本。
3.2 在 Unity 里跑起自动驾驶场景：场景加载前的检查清单
源码工程在 Unity 里打开后，一般包含一个或多个训练场景。如果直接用默认场景就能看到车辆、道路和起点终点标记，说明工程结构完整。但直接点 Play 之前，建议先过三个检查项，这能帮你省掉至少两小时的无效训练。第一，场景里有没有且仅有一个 active 的 Training Mode 配置，比如哪个 GameObject 被标记为训练源。第二，车辆上是否挂了 Agent 脚本和至少一个 Sensor，如果射线传感器没挂，Agent 永远只会输出默认动作。第三，检查地面和道路的碰撞体层级，确保车辆不会一开始就穿透地面。
我一般会额外做一件事：先把 Time.timeScale 调成 1 跑几秒确定性观看车辆行为。如果车辆在没有任何训练的情况下原地不动或缓慢滑行，说明状态正常；如果直接飞出去，那大概率是刚体组件的质量和阻力参数不对。源码包里的车辆刚体配置通常已经给了一组合理初值，但换了场景或改了车辆模型后必须重新检查。建议用下面的 C# 脚本在 Inspector 上快速确认关键参数，不需要改代码，只是读取状态。
// QuickDiagnostics.cs 挂到车辆根节点上用于启动前的状态检查 using UnityEngine; public class QuickDiagnostics : MonoBehaviour { private Rigidbody rb; void Start() { rb = GetComponent<Rigidbody>(); Debug.Log("Mass: " + rb.mass); Debug.Log("Drag: " + rb.drag); // 如果质量接近 0 或者阻力为负，物理引擎可能给出诡异行为 } }逻辑说明：这段代码只是一个诊断工具，它在场景启动时读取车辆刚体的质量和阻力值并输出到 Console 窗口。参数说明：自动驾驶车辆的刚体质量一般在 800 到 1500 之间，阻力值取 0.05 到 0.2 左右，如果数值偏离太远，训练出来的策略会偏向极端操作。这条检查的目的不是调优，而是排除物理参数错乱导致的训练无用功。
3.3 Agent 脚本解读：CollectObservations、OnActionReceived 和 Heuristic
这套源码的核心逻辑集中在 VehicleAgent.cs 里，理解它的三个重写方法就掌握了整个训练系统的数据流。CollectObservations 把当前帧的传感器信息和车辆自身状态拼成一维数组，包括前方射线测距结果、当前车速、和中心线的横向偏移，这是策略网络观察到的一切。OnActionReceived 接收训练器输出的动作数组，通常action[0]是方向盘转角，action[1]是油门/刹车踏板的合并值，脚本里再把这组数值映射到车辆转向系统实际的转动角度和驱动力。Heuristic 方法则是人肉接管用的，训练时可以按键盘控制车辆，用来确认场景物理手感是否合理。
下面是一段简化的 Agent 脚本骨架，真正源码里比这个复杂，但核心结构一致。
// VehicleAgent.cs 简化版本，展示训练数据流 using UnityEngine; using Unity.MLAgents; using Unity.MLAgents.Sensors; using Unity.MLAgents.Actuators; public class VehicleAgent : Agent { public Transform target; // 目标点 private Rigidbody rb; public override void Initialize() { rb = GetComponent<Rigidbody>(); } public override void CollectObservations(VectorSensor sensor) { // 传入当前速度向量和目标方向，速度值归一化到 [0,1] 区间 sensor.AddObservation(rb.linearVelocity.magnitude / 30f); Vector3 dirToTarget = (target.position - transform.position).normalized; sensor.AddObservation(transform.InverseTransformDirection(dirToTarget)); // 前方射线距离也可以在这里手动添加，如果传感器组件未启用 } public override void OnActionReceived(ActionBuffers actions) { float steer = Mathf.Clamp(actions.ContinuousActions[0], -1f, 1f); float throttle = Mathf.Clamp(actions.ContinuousActions[1], 0f, 1f); transform.Rotate(0f, steer * 2f, 0f); // 转向灵敏度系数 2 需按车辆尺寸调整 rb.AddForce(transform.forward * throttle * 800f); // 驱动力系数与刚体质量关联 } public override void Heuristic(in ActionBuffers actionsOut) { // 键盘控制方向：A/D 键或左右方向键 ActionSegment<float> continuousActions = actionsOut.ContinuousActions; continuousActions[0] = Input.GetAxis("Horizontal"); continuousActions[1] = Input.GetAxis("Vertical") > 0 ? 1f : 0f; } }逻辑说明：这段代码展示了 Agent 和环境的交互方式。CollectObservations里速度用了 30 作为归一化系数，因为车辆最高速度大约 30 m/s，这样网络输入保持在接近 [0,1] 的范围；目标方向用了InverseTransformDirection转到车辆自身坐标系，让网络学到的是“相对于车头往哪转”。OnActionReceived里的转向灵敏度系数和驱动力系数是跟车辆物理参数关联的，如果车辆质量、轮距变化，这两个系数必须同步调。Heuristic模式特别重要，它让你在训练前能用键盘手动开一遍车，如果手动驾驶都很难控制，说明车辆物理参数有问题，这时候启动训练只会得到更迷惑的结果。
3.4 启动训练：配置文件、命令行和 TensorBoard 观察确认
源码包内一般带一个 trainer_config.yaml 文件，训练前必须看一眼里面的max_steps和time_horizon是否合理。配置好后，先开 Unity 进入训练场景并点击 Play，再在终端启动训练命令。注意顺序不能反，必须先启动 Unity 然后运行mlagents-learn，因为 Unity 环境在等待训练器握手。
# trainer_config.yaml 自动驾驶任务常用训练配置 behaviors: VehicleBehavior: trainer_type: ppo hyperparameters: batch_size: 1024 buffer_size: 10240 learning_rate: 0.0003 beta: 0.005 epsilon: 0.2 lambd: 0.95 num_epoch: 3 learning_rate_schedule: linear network_settings: normalize: true hidden_units: 512 num_layers: 3 vis_encode_type: simple reward_signals: extrinsic: gamma: 0.99 strength: 1.0 max_steps: 500000 time_horizon: 64 summary_freq: 10000mlagents-learn trainer_config.yaml --run-id=autonomous_driving_v1 --port=5004逻辑说明：配置文件里batch_size1024 意味着每轮更新从经验池里取 1024 条样本；buffer_size10240 是经验池容量，相当于车辆行驶约 10 秒的步数总量。learning_rate 0.0003是 PPO 算法常用起点，训练后期会按learning_rate_schedule: linear线形下降到 0。beta 0.005是策略熵系数，数值越小策略越早确定性，但太大容易过早收敛，太小则探索不足。max_steps 500000表示训练总步数，对简单循迹任务大约需要跑 2 到 4 小时。summary_freq 10000决定每训练一万步记录一次统计指标，这个值别设太小，否则 TensorBoard 写入频繁反而拖慢训练。命令行里的--port=5004是训练器和 Unity 环境之间的通信端口，一般默认用 5004，如果被其他进程占用就换一个。
训练启动后，立刻在另一个终端进入同一虚拟环境启动 TensorBoard，观察Environment/Episode Reward和Policy/Loss两条曲线。前五分钟看到奖励在负值区域震荡不要慌，这是策略在探索阶段，关键是曲线整体要有上升趋势。如果二十分钟后奖励纹丝不动且始终在某个负值平台，大概率是奖励逻辑或传感器配置问题，不是训练步数不够。
3.5 模型导出与部署：从 .onnx 到 Unity 内推理
训练完成后，产物在runs/autonomous_driving_v1目录里，需要导出为 ONNX 格式才能在 Unity 内直接推理。ML-Agents 提供了现成的导出命令，导出后得到一个.onnx文件，把它拖进 Unity 工程，挂到 Agent 脚本上，再把 Behavior Parameters 的 Behavior Type 改成 Inference Only，车辆就能脱离 Python 训练器自主驾驶。这一步是从训练系统走向可演示/可测试的关键一环。
mlagents-learn trainer_config.yaml --run-id=autonomous_driving_v1 \ --resume --export逻辑说明：--resume让训练器恢复之前的训练状态，--export加上后会在训练结束时自动把模型导出为 ONNX 文件。实际上如果你不想再训练，也可以直接用python -m mlagents.trainers.onnx_utils之类脚本转换，但最省事是训练完成那一步顺手导出。参数说明：如果之前训练中断过，--resume可能因为时间戳不匹配报错，这时看看runs/下有没有checkpoint文件，如果没有就只能从头训练。导出 ONNX 后记得在 Unity 里做一次确定性验证：把车辆放到起点，关闭训练器，观察它是否能走完一圈。这个验证能暴露训练时被忽视的传感器配置差异。
4. 奖励函数和 PPO 超参：这套系统的核心旋钮
4.1 奖励塑形：稀疏奖励还是密集奖励，怎么设计梯度
自动驾驶任务天然适合密集奖励，因为每一步都能根据车辆状态给出反馈，稀疏奖励（比如只有到达终点才 +1）对 PPO 算法来说收敛慢到不可接受。源码包里的奖励设计通常包含三个部分：前进奖励奖励车辆向前移动的距离投影，方向奖励奖励车辆朝向目标点，碰撞惩罚在碰撞时给一个大的负信号并结束本回合。这三个部分叠加起来，车辆就有了“往前开、朝目标开、别装墙”的学习信号。
设计奖励函数最怕的是比例失衡。比如前进奖励给得太大，车辆会高速直冲但完全忽略转弯，最后频繁撞墙；方向奖励给得太大，车辆会原地打转不敢加速。我一般会把每步基础奖励控制在 0.01 到 0.1 的区间，碰撞惩罚定在 -1.0 以下，到达奖励在 +5.0 左右，这样的量级差能让 PPO 的回报信号不至于被某一项主导。源码包里已经有一套默认权重，但换场景务必重新测量：让车辆走直线，统计每步的平均奖励，如果超过 0.5 说明权重偏大，需要整体缩小。
// RewardManager.cs 辅助脚本，用于在每次决策结束后汇总奖励信号 using UnityEngine; using Unity.MLAgents; public class RewardManager : MonoBehaviour { private VehicleAgent agent; void Start() { agent = GetComponent<VehicleAgent>(); } public void GiveStepReward(float distanceForward, float angleToTarget) { float forwardReward = distanceForward * 0.1f; float directionReward = Mathf.Cos(angleToTarget) * 0.05f; // 方向奖励用余弦值保证在 [-1, 1] 内单调，车辆正对目标时奖励最大 agent.AddReward(forwardReward + directionReward); } public void OnCollision() { agent.AddReward(-1.0f); agent.EndEpisode(); } public void OnReachTarget() { agent.AddReward(5.0f); agent.EndEpisode(); } }逻辑说明：这段代码把奖励拆成两部分，distanceForward是车辆在自身前进方向上的位移投影，乘以 0.1 后作为基础步进奖励，鼓励车辆持续前进但不至于为此疯跑；angleToTarget是车辆朝向和目标方向的夹角，取余弦值能让奖励随角度线性变化（正对目标为 1，垂直为 0，背对为负）。碰撞和到达都用 EndEpisode 结束回合，区别是一个罚 -1，一个奖励 +5。参数说明：如果车辆在训练中频繁横向摆动，把方向奖励系数从 0.05 调低到 0.02；如果车辆不敢靠近障碍物，把碰撞惩罚从 -1.0 放宽到 -0.6，给策略多一点探索空间。
4.2 超参数先调这些：规模、学习率和探索系数的经验配置
训练不走寻常路，问题往往不在算法而在超参数脱离任务规模。PPO 在自动驾驶这类连续控制任务上的稳定区域并不算宽，四个参数最容易让新手翻车。batch_size决定每轮更新用的样本量，太小策略方差大，太大更新速度慢；buffer_size要和max_steps匹配，至少要能装下车辆跑完 3 到 5 个回合的经验；learning_rate是玄学程度最高的旋钮，0.0003 是我起步的默认值，低于这个值可以调高收敛速度，但超过 0.001 在多数驾驶任务上会直接发散；beta控制探索度，训练初期不要低于 0.003，后期如果奖励曲线平台化可以逐步降到 0.001 以下。
| 参数 | 默认值 | 调整方向 | 观察指标 |
|---|---|---|---|
| batch_size | 1024 | 调大让曲线更平滑 | Loss 方差 |
| buffer_size | 10240 | 调大保证经验多样性 | Episode Reward 稳定性 |
| learning_rate | 0.0003 | 调小防发散 | Policy Loss 是否爆炸 |
| beta | 0.005 | 调小促收敛 | Entropy 下降速度 |
| gamma | 0.99 | 调小让模型更短视 | 到达率/碰撞率 |
| time_horizon | 64 | 调大捕获长程决策 | 回合平均步数 |
参数说明：gamma 0.99是 PPO 常见的折扣因子，意味着模型把未来约 100 步内的奖励都纳入当前价值估计，对自动驾驶这种需要提前刹车减速的任务是合理设置，如果只做紧急避让这种短时决策任务可以降到 0.95。time_horizon决定 Agent 每隔多少步做一次价值估计，64 对应大约 1 秒多的驾驶时间。如果训练曲线显示价值估计震荡剧烈，把 64 提高到 128，代价是训练时间增加。
4.3 训练失败的模式识别：从 TensorBoard 曲线反推哪里出了问题
TensorBoard 里的曲线不会直接告诉你“奖励函数错了”，但组合特征能定位到大概率问题。第一种模式是 Episode Reward 缓慢上升后突然暴跌并长期无法恢复，这通常意味着策略陷入了局部最优，常见原因是batch_size太小导致每轮更新把好策略冲掉了，调大 2 倍观察是否恢复。第二种模式是 Policy Loss 持续增大但 Reward 停滞，这基本是learning_rate偏高，策略参数在最优附近反复横跳，降到 0.0001 试试。第三种模式是 Entropy 急剧下降接近 0，说明策略过早确定化，探索通道关闭，需要调大beta或引入噪声。
还有一种最迷惑的情况：Reward 曲线一路上升，但目测车辆在路上走 S 形甚至原地转圈。这是奖励设计里的方向分量权重不足，模型发现“只要前进就能得分”，于是用螺旋路径维持正奖励而不关心是否直线朝目标。解决办法是加大方向奖励的梯度贡献，同时检查前进奖励的系数——如果车辆只用很短时间就能转个圈刷前进分，说明前进奖励相对方向奖励过大，把前者的权重减半再训。
5. 自动驾驶训练系统的 5 个常见坑与排查记录
5.1 训练 30 分钟奖励纹丝不动：传感器没检测到任何标签
现象：训练开始后 Episode Reward 始终稳定在一个负常数值，Stepping 正常但策略毫无学习迹象。 原因：RayPerceptionSensor3D 的 Detectable Tags 列表里没有配置道路障碍物的 Tag，传感器发射的射线全部落空，观察向量全为 0。 解决：打开车辆挂载的传感器组件，确认 Detectable Tags 包含场景中所有需要感知的对象标签（通常是Obstacle、Ground、Target三类），然后重新训练。
5.2 车辆原地画圈不前进：方向奖励的符号错误
现象：训练过程中车辆始终在起点附近绕圈，偶尔能碰到路沿但从不远走。 原因：某个奖励项里的角度差计算用了带符号角度而非余弦相似度，模型学到的是“朝左转有奖励，朝右转有惩罚”，策略干脆原地左转刷分。 解决：把方向奖励改为Mathf.Cos(angle)，用余弦值替代绝对角度，这样左转右转在数值上对称，模型失去原地画圈的动力。
5.3 训练帧率极低但 GPU 占用不高：物理步和渲染步的竞争
现象：训练时 Unity 编辑器内 FPS 很高，但控制台显示每秒训练步数只有个位数。 原因：Fixed Timestep 设置过大，物理引擎每步计算耗时严重，Agent 决策频率被物理步拖累。很多源码为了视觉效果把 Time.timeScale 调成 10 倍速，但物理求解器的步长没有同步调整。 解决：把 Project Settings 中 Fixed Timestep 保持在 0.02（即 50Hz），Time.timeScale 调回 1，确认 Agent 的 Decision Period 为 1，让每次物理步都触发一次决策计算。
5.4 训练成绩优秀但部署后碰撞率飙升：域随机化只做了外观层
现象：训练曲线和早停验证都很完美，导出 ONNX 后放进同一场景 Inference Only 模式下碰撞率却超过 30%。 原因：训练时场景里只有固定光照、固定障碍物位置和固定路面摩擦，模型把位置记忆当成泛化能力，换一帧画面就失效。 解决：在训练场景的 Build Settings 里开启域随机化，至少覆盖障碍物位置偏移、路面摩擦力变化两个维度，如果车辆带视觉传感器还需随机光照强度，确保策略学到的是真正的驾驶逻辑而非画面记忆。
5.5 导出 ONNX 后车直接冲出赛道：Observe 标准化参数丢了
现象：Python 侧训练缩放到实际部署后，车辆动作明显比训练时剧烈，哪怕同样的输入也输出不同结果。 原因：ML-Agents 训练时对观察向量做normalize: true标准化，但导出的 ONNX 里只有网络权重，标准化所需的均值和方差没有一并导出，部署端拿到原始量级的观察输入直接进网络，输出动作自然溢出。 解决：导出 ONNX 前，把network_settings里的normalize改为false并重新训练，或者检查导出工具是否生成配套的标准化配置文件，确认部署端加载完整模型包而不是单独的网络权重。
6. 从能跑到好用：域随机化和课程学习的落地顺序
把一套自动驾驶训练系统从“能跑”做到“稳定泛化”，只调奖励函数是不够的，需要引入两层机制。先做域随机化再做课程学习，顺序不能反，因为域随机化解决的是感知带宽，课程学习解决的是探索效率。
域随机化的做法是在训练场景中让关键变量每次重置回合并随机变化。具体到自动驾驶，优先随机三个物理维度：障碍物的横向偏移（模拟旁车切入）、路面摩擦力（模拟雨天湿滑）、车辆初始朝向（模拟出弯姿态）。在 Unity 里写一个随机化脚本，在OnEpisodeBegin里对车辆和障碍物位置做随机偏移即可。课程学习则是把训练难度分级：第一阶段只跑直线且无障碍物，让模型先学会基本控制；第二阶段加入减速带和一个弯道，迫使策略学会转向与速度的协调；第三阶段放上随机障碍物，验证避障能力。ML-Agents 内置了 Curriculum 配置，在 YAML 里通过curriculum字段按训练进度切换参数区间。
训练完成后我的验证习惯是固定跑 100 个回合的 Heuristic 模式记录平均时长，再切换 Inference Only 跑同样 100 回合对比撞墙率。如果部署表现和手动控制差异明显，说明传感器或物理参数存在偏差，此时回到 5.4 和 5.5 两节排查。这个系统的天花板不在框架本身，而在于你能把场景做得多接近真实，把奖励设计得多符合驾驶直觉。我自己踩过最深的坑就是跳过域随机化直接出模型，结果在现场演示时换了个角度就翻车。后来养成习惯，每次训练前先写死随机种子做确定性验证，再开随机化训练，两条曲线对比心里才有底。希望帮到你。
本文还有配套的精品资源，点击获取
