基于Unity ML-Agents的自行车智能体自主导航避障训练实战

简介：面向智能交通与强化学习研究者，一套基于Unity ML-Agents release 15的智能自行车机器人仿真系统，聚焦于强化学习训练自行车智能体在复杂城市环境中的自主导航、避障与群体协同行为。相比单智能体方案，系统重点模拟真实交通中自行车群体相互影响与协调，适合探索多智能体决策、交通仿真及自动驾驶策略的研究者和学生使用。压缩包共566个文件，大小约34MB，内含onnx/pt模型、cs训练脚本、prefab预制体、asset场景与地形资源，以及训练过程tfevents日志等；场景覆盖环形路口、T形/X形交叉口等典型交通形态，便于多情景训练与验证。已有71人学习下载，配套交通场景定义、使用说明文档等辅助材料，可帮助用户从场景搭建、模型训练到结果分析的全流程快速上手。

1. 一个能自主导航避障的自行车智能体，凭什么要在Unity里训练

这套基于Unity ML-Agents release 15开发的智能自行车机器人仿真系统，最容易让人误解的是注意力被画面带走——场景里有路面、有障碍、有成群自行车，看着像交通演示，核心其实是强化学习训练闭环。项目把自行车智能体投进复杂交通场景，靠一轮轮试错学会自主导航与避障，最终模拟出贴近真实骑行的群体行为。

对做机器人决策、仿真系统或深度强化学习算法落地的人来说，它直接回应三个实际问题：训练环境怎么搭、奖励怎么设计、调参该盯哪些指标。我按版本对齐、场景搭建、PPO训练到交付验证这条链路拆开，新手能跟步骤走，熟手能直接对照参数改。

2. ML-Agents release 15 的架构拆解：先让智能体学会“表达自己”

在动手搭场景之前，得先搞清楚release 15这代ML-Agents是怎么把“自行车骑手”变成“可训练的智能体”的。很多项目死在不该死的地方：不是在训练阶段，而是在一开始就选错了版本，或者把观测空间定义得乱七八糟，导致训练曲线怎么调都救不回来。

2.1 release 15 在版本演进里的位置：锁定版本是复现的第一前提

ML-Agents作为Unity官方的强化学习扩展，从2018年开源到现在改过好几轮大结构。release 15这一代，基本是“Unity端包+Python端训练器”这个稳定双端结构的成熟期，大量公开项目都基于这代记录参数，网上能搜到的训练配置也大多是这一代的格式。

为什么偏偏要锁定release 15而不是直接用最新版？我踩过一次坑：拿到别人release 15的项目，直接升级到新版ML-Agents包，结果场景里的Behavior Parameters组件字段对不上，连训练时的通信端口配置都改了一轮。最新版把很多参数挪了位置、改了名字，旧配置不能无缝迁移。对于做仿真系统的人来说，策略是“凡是涉及复现，先对齐版本”，而不是追求新。

对齐版本的具体做法：在Unity里打开Package Manager，查看com.unity.ml-agents当前版本；然后在Python侧执行pip install mlagents，并确保mlagents版本与Unity侧属于同一release分支。release 15时代的Python端用法是mlagents-learn命令，你可以先不带参数跑一下验证环境通不通。版本对不齐时最典型的现象是Unity里按Play后Python端毫无反应，或者直接报握手错误，这不是代码问题，是两端版本不匹配。

2.2 把“骑自行车”拆成观测与动作：感知层的设计决定了训练上限

自行车智能体的核心是感知-决策循环。这一代ML-Agents的Agent模式把感知和动作统一成两步：CollectObservations收集状态，OnActionReceived消费动作。这意味着你必须先定义这个智能体“看什么”。

我一般推荐“向量观测+射线传感器”的组合，而不是直接上一路相机画面。像素观测在release 15时代训练成本极高，一帧画面就是成百上千维输入，收敛速度慢到让人怀疑人生。而射线感知方式，RayPerceptionSensor3D组件给你的是有明确物理意义的距离信息——左前方30度有车，距离2.3米；正前方有障碍，距离1.1米。这些信息对避障任务刚刚好。

向量观测至少要包含两类量：自车运动状态和目标相对位置。运动状态里，“unity物体速度怎么获取”是个必会操作：直接读刚体的velocity属性就行。需要注意Unity版本差异，release 15时代用GetComponent ().velocity，后来Unity 6改成了linearVelocity。写兼容代码时长个心眼。

using UnityEngine; using Unity.MLAgents; using Unity.MLAgents.Sensors; using Unity.MLAgents.Actuators; public class BikeRiderAgent : Agent { public Transform target; private Rigidbody rb; private float maxSpeed = 8f; public override void Initialize() { rb = GetComponent<Rigidbody>(); } public override void CollectObservations(VectorSensor sensor) { // 自车线速度，单位m/s；release 15时代用.velocity Vector3 velocity = rb.velocity; sensor.AddObservation(velocity); sensor.AddObservation(rb.transform.forward); // 目标点相对位置：有方向又有距离信息 Vector3 relativeTarget = target.position - transform.position; sensor.AddObservation(relativeTarget.normalized); sensor.AddObservation(relativeTarget.magnitude); } 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 * Time.fixedDeltaTime, 0f); rb.AddForce(transform.forward * throttle * maxSpeed, ForceMode.Acceleration); } }

这段代码暴露了一个细节：动作空间我选的是连续动作。转向是-1到1，油门是0到1。相比离散动作，连续控制在自行车这种需要平滑转向的场景里更容易学到自然轨迹。Discrete动作会让自行车做出“咔嗒咔嗒”的折线转弯，看起来非常不像真人骑行。

动作空间不是越宽越好。有些项目把刹车、踏板踩力和转向分开成三个独立动作，训练维度一下子涨上去，但智能体学不到联合控制。自行车群体仿真的重点在导航避障，不是极限操控，所以两个连续动作就够。真正的细节在决策频率：如果每个FixedUpdate都让Agent做决策，训练会慢而且动作抖动；一般做法是让DecisionRequester以固定步数决策，我常用decision period在4到8之间，让智能体有条不紊地改变方向，跟真人反应的惯性更接近。

2.3 奖励函数的三层写法：目标、避障、规则一个都不能少

奖励函数是整个训练里最像“玄学”的部分，但把它拆成三层结构，基本不会跑偏。

第一层是稀疏主奖励：到达目标点，给一个大的正奖励并结束Episode；撞上障碍或冲出边界，给一个大的负奖励并结束Episode。这层负责定义任务成败。

第二层是密集引导：每个step给一个微小的时间惩罚，比如-0.001，逼智能体尽快到达而不是原地耗时间；同时和障碍距离挂钩，靠近障碍物给一个小负奖励，用距离差来设计。密集引导不能让智能体学会什么，但能大幅加速探索。注意别把碰撞负奖励设得太绝对，否则智能体会找到一个“躺平”策略——停在那里不动就永远不会撞车，于是永远不扣碰撞分。

第三层是规则约束：自行车要贴近车道，偏离中心线给轻惩罚；逆行、闯红灯可以抽象成进入特定区域触发负奖励。这层是“模拟真实交通场景”的关键，没有这层训出来的是乱窜的智能体，有了这层才贴近群体交通语义。

在选择具体算法时，release 15内置的PPO基本是这类场景的默认答案。相比DDPG这类off-policy算法，PPO的实现稳定、超参敏感度低，更适合在多智能体的自行车群体里共享一套策略参数。这个选择不是追求性能最强，而是追求在复杂环境里训得出、跑得动。

3. 在Unity里把自行车场景搭出来：安装、建模与Behavior参数

这一章所有动作都围绕一个目标：让Unity场景里出现一群能通过ML-Agents和Python端通信的自行车智能体。你会发现有了release 15的包，整个搭建过程其实是“装配式”的，难点在理解每个组件之间的关系。

3.1 环境安装与版本对齐：Unity端、Python端一次配平

开始之前，先做一次环境体检。我遇到过不少同行直接装了新版ML-Agents就打开旧工程，结果Unity编辑器里报一堆API过时警告，训练端连不上。这里给一个可以照抄的检查流程。

# 确认Python端可用的mlagents命令 pip install mlagents mlagents-learn --help # 如果项目里自带requirements.txt，建议直接用 # pip install -r requirements.txt

安装完成后，打开Unity工程，在Edit > Project Settings里找到ML-Agents配置项，确认基础通信端口，例如5005。然后打开Package Manager，选中ML-Agents包，记下版本号。两端版本是否同代，以这个版本号为基准比对。

检查通过后，还需要处理一个Unity侧的网络通信设置：训练时Python端是服务端，Unity是客户端，两者通过网络端口通信。在某些网络环境下，Unity会弹出防火墙拦截，此时要给Unity编辑器放行局域网通信，否则Python端会一直卡在等待连接。这个细节和防火墙策略有关，不同机器表现不一样，但非常常见。

3.2 场景的最小集合：路面、碰撞体、目标点与自行车Prefab

在Unity中搭建场景时，不要一开始就追求“真实交通全景”。我建议先搭一个最小闭环场景：一段足够宽的路面、三五个静态障碍物、一个目标点、一辆自行车。

路面用内置的Plane就可以，关键是ProBuilder建出边界墙，避免自行车冲出路面后不知去向。给平面加上刚体（isKinematic）作为碰撞体，或者用Cube墙围一圈。这些表面必须带碰撞体，因为Agent的碰撞检测全靠它。

自行车Prefab的搭建是重点。一个典型的Prefab结构是：自行车车体（带Rigidbody）为根节点，上面挂Agent脚本、Behavior Parameters组件、Decision Requester组件、一个或多个RayPerceptionSensor3D组件。Rigidbody的质量设小一些，自行车整体质量在30kg量级比较合适，数值不必纠结精确，关键是别让前后轮独立物理模拟——那会引入稳定性问题。为了简化，我会把自行车当成一个质心较低的刚体，控制转向时不通过转动前轮而是直接旋转车体，这能让训练稳定得多。

Behavior Parameters是本次配置的核心组件。几个必填项：Behavior Name要唯一，我习惯用“BikeRider”；Vector Observation的Space Size要和CollectObservations里AddObservation的数量严格一致，多一个少一个都会在训练时报错；Action Space选Continuous，Action Size里Continuous Action Size填2。最后，训练完成后，.onnx模型会挂到这个组件的Model字段。

RayPerceptionSensor3D的配置在Inspector上就能完成。射线数我一般设6到8条，覆盖前方120度范围，检测层设为障碍物和目标点所在Layer。射线不是越多越好，每条射线都会加入观测向量，太多会让状态维数膨胀，影响训练速度。

这里还要聊一个多数新手忽略的细节：目标点检测不能靠Agent的碰撞体去撞，否则Episode的结束条件会被“路过”误触发。我用Reward逻辑来判断是否到达目标，而不是用碰撞体触发。见下面的C#片段。

public override void OnTriggerEnter(Collider other) { if (other.CompareTag("Obstacle")) { AddReward(-1f); EndEpisode(); } } public override void OnTriggerStay(Collider other) { if (other.CompareTag("Target")) { AddReward(1f); EndEpisode(); } }

这段代码里，障碍物碰撞用Trigger即可，不需要实际物理回弹，减少刚体碰撞计算量的同时逻辑也更干净。目标点的Tag判定要保证Trigger设置正确——碰撞体和目标点都勾上Is Trigger。如果忘了勾，OnTriggerEnter一辈子不会触发，智能体到达目标后也会继续傻跑。

3.3 多智能体环境：让自行车群体行为成真

真实交通场景里，不是一辆自行车在孤零零地骑车，而是一群自行车同时出现在路口、车道和障碍之间。ML-Agents的核心机制是：所有Agent挂在同一个Behavior下，就共享一个策略网络，同时、异步地产生经验。

实现群体行为的关键在Reset。每次Episode结束时，我需要把整个群体重置到合法状态。常见做法是写一个环境管理器脚本，负责生成出生点列表和目标点列表，每次重置时让每辆自行车从随机出生点出发，前往随机目标点。注意出生点之间要留出足够间距，否则多辆自行车诞生在同一位置，物理引擎会把它们弹开，产生初始混乱。

public class BikeEnvironment : MonoBehaviour { public GameObject bikePrefab; public Transform[] spawnPoints; public Transform[] targetPoints; public int bikeCount = 10; void Start() { for (int i = 0; i < bikeCount; i++) { var bike = Instantiate(bikePrefab, spawnPoints[i % spawnPoints.Length].position, Quaternion.identity); bike.GetComponent<BikeRiderAgent>().target = targetPoints[i % targetPoints.Length]; } } }

这段代码只是一个起点。真正完整的实现还需要在Agent内部记录自己的目标点引用，并在每次GroupReset时重新分配目标。群体行为的一个重要特征是多样性：如果所有智能体从同一个起点出发、去同一个目标，它们会学到同一条路径，群体行为就退化成“跑火车”。随机化起点和目标点，是让群体行为逼近真实交通的第一步。

我还会在场景里放入几辆“背景车”—用简单脚本沿着固定路线匀速移动的Cube车辆，充当动态障碍物。它们是真实交通场景里的变量，训练中期再加入这些动态障碍，能有效提升策略对复杂环境的适应能力。

4. 训练、监控与导出：让策略在复杂环境中收敛

训练这一步最大的风险是“跑起来了但不知道跑得对不对”。很多人用mlagents-learn启动训练后，盯着命令行看几分钟，只看到Reward在0附近摩擦，然后开始盲目调参。正确的做法是把注意力放在TensorBoard的曲线变化趋势上，先让代码跑通一次，再谈优化。

4.1 启动PPO训练：命令和6个必调超参数

release 15默认支持PPO和SAC两类训练器，自行车群体导航这个场景用PPO足够，默认使用PPO配置。启动命令很简单，但每一步都要对应好。

mlagents-learn config/bike_ppo.yaml --run-id=bike_v1

run-id是这次训练的唯一标识，会写进results目录。如果想继续一次训练，加--resume参数并复用同一个run-id即可。Unity场景运行起来后，按Play键开始训练，Python端会显示连接和训练信息。

bike_ppo.yaml里最值得提前吃透的6个参数：

behaviors: BikeRider: trainer_type: ppo hyperparameters: batch_size: 1024 buffer_size: 10240 learning_rate: 3.0e-4 beta: 5.0e-3 epsilon: 0.2 lambd: 0.95 num_epoch: 3 learning_rate_schedule: linear network_settings: normalize: true hidden_units: 256 num_layers: 2 reward_signals: extrinsic: gamma: 0.99 strength: 1.0 max_steps: 5000000 time_horizon: 64 summary_freq: 20000

batch_size是每次更新用的经验条数，1024是起步值；buffer_size是经验池容量，至少是batch_size的8到10倍，太小会让网络学不稳。learning_rate是策略更新的步长，常见范围1e-4到1e-3，太高策略会震荡，太低几百万步也没进展。beta是熵正则项系数，它负责保留探索力度，beta太小智能体容易过早固化动作，尤其这种多Agent群体任务，beta大一点能防止行为单一化。epsilon是PPO的裁剪范围，0.2是标准值，不用动。max_steps是整个训练的累计步数上限，自行车的导航避障任务起步建议5百万步，复杂交通场景再往上加。

这里有个常犯的错：把max_steps调得很小，比如50万步，然后发现训练结束后模型行为非常弱。自行车群体任务里，智能体要先学会直线骑，再学会转向，最后学会避障，是一个层层递进的学习过程，没有两三百万步的基础根本不现实。如果你时间紧，宁愿缩小场景复杂度，也不要把max_steps降到不合理的程度。

4.2 从TensorBoard曲线判断训练状态

训练启动后，在另一个终端执行：

tensorboard --logdir results

浏览器里打开控制台给到的地址。重点关注三条曲线。

第一条是Cumulative Reward。这条曲线的绝对数值意义不大，你要看方向和波动幅度。如果Reward在持续抬升，说明策略在变好；如果在某个平台期震荡很久还没有抬升迹象，优先检查奖励函数里是不是存在能让Agent“钻空子”的设计。第二条是Entropy。PPO的entropy曲线如果一开始就断崖式降到接近0，说明策略过早确定化，探索不足，这时候加大beta通常有效。第三条是Value Loss，正常情况下它会缓慢下降或保持平稳，如果它爆炸式上升，大概率是奖励信号不稳定或网络输入数值太大，这时候把normalize打开、检查观测值是否做归一化。

顺着曲线往下查，你会发现很多“参数调不动”的问题，其实根源在奖励定义或者观测设计上，而不是PPO本身。

4.3 模型导出与Unity内推理验证

训练到max_steps或者Reward进入稳定区后，就可以考虑导出。release 15给的标准做法是，训练完的模型会以.onnx格式存放在results/ /目录下。把生成的模型文件拖入Unity中Behavior Parameters组件的Model字段，然后关闭Python端训练器，直接在Unity里Play，就能看到智能体用训练出的策略做推理。

这里有个操作细节：在Unity里做推理验证时，如果Behavior Parameters的Behavior Type还是Default（训练模式），是看不到效果的，需要把Behavior Type切换到Inference Only。有些项目还会把代码里往Agent上加奖励的分支藏起来，避免推理阶段误触发AddReward。我的习惯是在Agent里加一个IsTraining标志位（或者直接通过Behavior Type判断），让推理阶段不调用EndEpisode。

5. 避坑指南：ML-Agents自行车仿真训练中的4个翻车点

训练自行车智能体，踩坑比看点成功经验有效得多。这一部分讲的是我最常遇到的4个问题，每一个都经历了完整排查过程。

5.1 版本不对齐：Python端提示连接失败，Unity端毫无反应

现象：Unity场景按Play后，mlagents-learn在命令行里一直显示等待连接，等十分钟也无动于衷。原因：这几乎是版本错配的典型信号。release 15这一代的通信协议在后续版本做过调整，两端版本不在同一分支时，连握手格式都匹配不上。解决：按前面的检查流程重新对齐版本。先看Unity侧包版本，再在Python侧安装对应的mlagents版本，然后重启Unity编辑器后再试。另外还要排查防火墙是否拦截了Unity进程，这个和网络环境有关，但排查顺序永远排在版本对齐之后。

5.2 奖励函数给得太野：智能体干脆躺平

现象：训练了20万步，智能体原地不动，Reward维持在一个不升也不降的数值。原因：稀疏主奖励和密集引导的系数失衡。如果step级别的负向惩罚太大，智能体很快就会学会“不动就不会扣分”这个最优解，比任何探索都划算。我早期就把时间惩罚设成-0.005，结果训练出来的自行车全在出生点装死。解决：先砍掉所有step级惩罚，只保留到达奖励和碰撞惩罚跑一轮，让智能体先动起来；动起来之后再逐步加回小惩罚系数，一旦发现Reward曲线滑坡，立即回退。这个流程走到最后，时间惩罚通常在-0.001这个量级。

5.3 开太多传感器：训练帧率低到没法忍受

现象：训练时CUDA利用率不高，但Unity端帧率只有个位数，训练像在看幻灯片。原因：Time.timeScale的timescale设置被拉高后，物理计算和决策频率不会自动降低；每帧要跑的RayPerception计算量叠加起来，成了帧率瓶颈。解决：先检查Time.timeScale是否设置在20倍甚至更高，把决策频率（Decision Requester）调低，让决策步数从每帧一次改成每4帧一次；再砍掉多余的射线感知方向，从12条减到8条内；最后统计一下场景里是否有多余的灯光和阴影，把实时阴影关掉。这些操作组合起来，帧率通常能有成倍提升。

5.4 模型在训练场景里表现很好，换个地图就翻车

现象：训练时Cumulative Reward曲线很好看，碰撞率也低；但把模型搬到另一张地图上推理，自行车频繁骑上马路牙子，避障行为完全变形。原因：过拟合场景。如果把目标点、出生点固定住了，智能体记住的是路径，不是策略。解决：训练前就把出生点和目标点随机化，训练中期混入动态障碍物，训练后期加入可配置的赛道变体。如果已经训完，补救的办法是把场景随机化之后用更低的learning_rate做少量步骤的继续训练，也就是finetune，比从零开始训要快很多。

这四个问题贯穿了版本、奖励、传感器和泛化四条线，基本覆盖了做这套系统时存活率最低的环节。另外还有一个小建议：每次修改配置后，记录下run-id和改动的参数，形成一张表格。强化学习训练是个黑匣子，没有记录的话，你甚至说不清当前这个模型是拿哪组参数训出来的。

6. 让仿真结果可信：多随机种子评估与训练前的第一习惯

训练收敛不等于可以交付。落地这套自行车群体仿真时，我坚持一个习惯：用多随机种子做评估。把同一个配置跑3到5次（run-id可以区分），每次使用不同的随机种子，然后统计到达率、平均到达时间、碰撞率这几个指标。只看单次训练的Reward曲线有幸存者偏差，多跑几次才能知道这套策略的平均水平，这个过程不复杂但极其重要。

另一个实用技巧是课程学习。自行车在空路上跑稳了，再引入静态障碍，最后加入动态交通流。在ML-Agents里不需要装额外的插件，你只需要准备多份config文件，分阶段训练，每个阶段用上一个阶段训出的模型作为初始权重继续训练。这比直接拿复杂场景硬训的收敛速度快，而且每个阶段学到的东西都能被保留住。

最后，交付前把事件统计落到文件里。我的做法是在Agent的EndEpisode位置统计到达、碰撞、超时三类结果，并把它们写到一份CSV里。这份CSV比任何曲线都能说明问题：你是不是真的模拟出了像样的自行车群体行为，碰撞占比多少，平均耗时多少，一目了然。

做完这套系统后，我最大的习惯变化是：改任何参数前先记录旧参数的曲线，而不是看完曲线就动手改。强化学习调参有很强的试错属性，后悔药只能靠记录来给。希望这些经验对你做这套自行车智能体仿真系统有帮助。

本文还有配套的精品资源，点击获取