自动驾驶决策算法实战:行为决策、轨迹规划与博弈交互的工程思考
1. 从感知到决策自动驾驶真正的分水岭在哪里很多人聊自动驾驶第一反应都是激光雷达、摄像头像素、算力多少TOPS好像只要传感器够多、芯片够强车就能自己开。但真正在一线做过系统的人都知道感知决定的是“能不能看见”决策决定的才是“敢不敢走、怎么走”。我见过太多Demo感知模块在屏幕上把车道线、车辆、行人画得漂漂亮亮可一进复杂路口决策模块就开始犹豫、抖动、甚至做出反直觉的操作。问题往往不出在模型精度上而出在决策逻辑的设计思路上。这篇内容我想聊的是自动驾驶决策算法背后的思考方式不是泛泛而谈概念而是把我在实际项目中反复推演过的东西摊开来讲。核心关键词包括行为决策、轨迹规划、博弈交互、规则与学习融合、安全冗余。如果你正在做自动驾驶相关开发或者对机器人决策感兴趣又或者只是想知道“为什么自动驾驶看起来聪明实际却经常犯傻”那这篇内容应该能给你一些不一样的视角。决策算法的本质是在不确定环境下做出一系列“可解释、可验证、可兜底”的选择。它不像感知那样有明确的真值可以标注也不像控制那样有清晰的数学方程可以推导。决策处在中间地带既要理解世界又要输出动作还要对结果负责。这个位置决定了它天然就是整个系统里最难啃的骨头之一。2. 决策模块到底在解决什么问题拆解三层任务结构2.1 第一层行为选择——走还是等最顶层的决策是行为选择说白了就是“接下来这几秒我打算干什么”。是跟车、变道、超车、让行、还是停车等待这个层面的输出通常是一个离散的意图标签比如“保持车道”“向左变道”“减速让行”。听起来简单但实际场景里行为选择往往是最容易出问题的地方。我举个实际遇到的例子。在一个无保护左转路口自车需要判断对向直行车辆的距离和速度决定是抢在它前面转过去还是等它过去再转。如果决策模块只根据“距离大于50米就转”这种硬规则那遇到一个加速冲过来的车就很容易出事。但如果规则太保守又会导致车辆在路口长时间等待影响通行效率。这里的核心矛盾是行为选择必须在安全与效率之间找到一个动态平衡点而这个平衡点会随着场景、交通流、甚至天气变化而漂移。实际工程中行为选择通常用状态机或者行为树来实现。状态机的好处是逻辑清晰、可解释性强每个状态对应一种行为模式状态之间的迁移条件可以写得很明确。但状态机的缺点是扩展性差场景一多状态数量爆炸迁移条件互相耦合改一处可能影响一片。行为树稍微好一些模块化程度更高但本质上还是人工设计规则面对长尾场景依然吃力。2.2 第二层轨迹生成——怎么走行为选择确定之后下一步就是生成具体的行驶轨迹。轨迹是一串带时间戳的位姿点包含位置、速度、加速度、曲率等信息。这个层面的挑战在于轨迹不仅要满足车辆动力学约束还要满足舒适性、安全性、合法性等多重目标。我见过不少团队在这一步偷懒直接用多项式或者贝塞尔曲线拟合一条平滑路径就完事了。结果就是车辆在避障时轨迹虽然平滑但要么离障碍物太近让人捏把汗要么绕行幅度太大像在画龙。好的轨迹生成应该是在一个约束优化框架下进行的把障碍物距离、车道边界、速度限制、加速度上限都作为约束条件把舒适性和效率作为优化目标求解出一条既安全又自然的轨迹。这里有个经验轨迹生成的时间粒度很关键。太粗了控制模块跟不上太细了计算量爆炸。我一般建议规划周期在100毫秒左右轨迹点间隔在0.1到0.2秒之间这样既能保证实时性又能给控制留出足够的平滑空间。2.3 第三层反馈修正——走偏了怎么办轨迹生成出来之后并不是就万事大吉了。实际执行过程中控制误差、环境变化、其他交通参与者行为变化都会导致实际轨迹偏离预期。这时候就需要一个反馈修正机制实时评估偏差并决定是否重新规划。这个层面最容易被忽视。很多团队把精力都花在“怎么规划一条完美轨迹”上却没想过“如果执行不到位怎么办”。我的做法是设置一个偏差监控器持续比较实际轨迹和规划轨迹的横向和纵向偏差。如果偏差超过阈值就触发重规划如果偏差在可接受范围内就通过控制模块微调避免频繁重规划带来的抖动。这三层任务结构不是孤立的而是紧密耦合的。行为选择影响轨迹生成的空间轨迹生成的结果又反过来影响行为选择的可行性。实际系统中这三层往往需要在不同时间尺度上并行运行行为选择周期可以长一些比如500毫秒一次轨迹生成周期短一些100毫秒一次反馈修正则要更快可能20毫秒就要跑一次。3. 规则派与学习派决策算法两条路线的真实较量3.1 规则方法的优势与天花板规则方法在自动驾驶决策里一直是主流尤其是量产项目上。原因很简单可解释、可验证、可追溯。每一条规则背后都有明确的逻辑出了问题可以定位到具体是哪条规则触发的也方便做形式化验证。比如“前方车辆距离小于安全距离且相对速度为正则减速”这种规则写出来谁都看得懂测试起来也容易构造用例。但规则方法的天花板也很明显。首先是场景覆盖问题长尾场景无穷无尽靠人工写规则永远写不完。其次是规则冲突问题当多条规则同时触发且给出矛盾指令时怎么仲裁我见过一个项目规则表写了上千条结果在某个路口三条规则同时激活两条说走一条说停系统直接卡死。最后是参数调优问题规则里的阈值参数往往需要大量路测数据来标定调一个参数可能影响十几个场景的表现牵一发而动全身。我的经验是规则方法适合处理结构化程度高、边界清晰的场景比如高速巡航、车道保持、简单跟车。这些场景规则明确用状态机就能覆盖得很好。但一旦进入城市复杂路口、人车混流区域规则方法就力不从心了。3.2 学习方法的潜力与风险学习方法尤其是强化学习和模仿学习这几年在决策领域很热。理论上只要数据够多、模型够大就能学到人类驾驶员的决策模式甚至超越人类。实际项目中我也尝试过用模仿学习从大量人类驾驶数据中训练决策模型效果确实有惊艳的时候比如在拥堵跟车时模型能学到那种“蠕行”的微妙节奏比规则方法自然得多。但学习方法的坑也很多。首先是安全兜底问题神经网络是个黑盒你没法保证它在所有情况下都做出安全决策。万一遇到一个训练集中没出现过的极端场景模型可能输出一个完全离谱的动作。其次是分布偏移问题训练数据里的场景分布和实际部署时的场景分布往往不一致模型在训练集上表现很好一上路就拉胯。最后是验证困难问题你怎么证明一个神经网络决策模型是安全的靠大量测试那要测多少公里才够我目前的看法是学习方法可以作为规则方法的补充在规则覆盖不到的场景里提供“软决策”建议但最终的安全兜底还是得靠规则。也就是说学习负责“聪明”规则负责“安全”两者不是替代关系而是互补关系。3.3 融合思路分层决策架构的实践基于上面的分析我在实际项目中倾向于采用分层决策架构。上层用学习方法做行为选择输出一个意图分布或者候选行为集合中层用规则方法做安全校验和可行性筛选把不安全的、违反交通规则的候选行为过滤掉下层用优化方法生成具体轨迹。这种架构的好处是既保留了学习方法的灵活性和场景适应能力又通过规则层保证了安全底线。具体实现上上层可以用一个轻量级的神经网络输入是感知结果和地图信息输出是几个候选行为的概率。中层维护一个规则库每条规则对应一个安全约束比如“不得与前方车辆距离小于2米”“不得在红灯时进入路口”等。下层用模型预测控制或者二次规划来生成轨迹。这里有个关键点规则层的约束必须是硬约束不能被学习层的输出覆盖。也就是说如果学习层建议变道但规则层判断当前变道不安全那就必须否决。这个否决机制是安全冗余的核心不能妥协。4. 博弈与交互当决策遇到其他有思想的参与者4.1 为什么预测不准是常态自动驾驶决策最难的地方不是自车怎么动而是别人怎么动。其他车辆、行人、骑行者他们都是独立的决策主体有自己的意图和策略。你预测他直行他可能突然变道你预测他让行他可能一脚油门冲过去。预测不准是常态预测准了才是运气。我刚开始做决策时总想着把预测模块做得越准越好后来发现这条路走不通。因为交通参与者的行为本质上是博弈的结果不是物理规律决定的。一个人过马路他也在判断你让不让你减速了他可能就加速通过你加速了他可能就停下等待。这种相互依赖的关系用单纯的预测模型是搞不定的。4.2 博弈论在决策中的落地方式博弈论提供了分析这种交互场景的数学框架。最常用的是序贯博弈和部分可观测马尔可夫博弈。简单说就是把自车和其他交通参与者都看作理性玩家每个人根据自己的收益函数选择策略最终达到一个均衡。实际落地时完全理性的假设太强了因为现实中很多驾驶员并不理性。所以我会引入有限理性的概念假设其他参与者只在一定范围内优化自己的收益同时考虑他们的行为不确定性。具体做法是为每个交通参与者建立一个简化的收益模型包括通行效率、安全距离、舒适度等因子然后用逆向归纳或者迭代最优响应来求解近似均衡。举个例子在无保护左转场景中自车和对向直行车构成一个博弈。自车的收益是尽快完成左转对向车的收益是保持速度通过路口。如果自车选择“抢行”对向车选择“不让”那就可能碰撞双方收益都极低。如果自车选择“等待”对向车选择“通过”那对向车收益高自车收益低。均衡点往往在“自车缓慢逼近试探对向车根据自车动作决定让或不让”这个动态过程中产生。4.3 交互式决策的工程实现细节工程上实现博弈决策不可能真的去解一个完整的博弈均衡计算量太大。我的做法是场景抽象加策略库匹配。先把当前场景抽象成几个关键特征比如相对距离、相对速度、道路结构、交通规则优先级等然后从一个预定义的策略库里匹配最合适的交互策略。策略库里的策略是离线设计好的每个策略对应一种典型的交互模式比如“激进抢行”“保守等待”“试探性逼近”“交替通行”等。每个策略都有明确的触发条件和退出条件以及对应的轨迹生成参数。在线运行时决策模块根据场景特征选择策略然后交给轨迹生成模块执行。这种做法的好处是计算量可控逻辑清晰而且策略库可以不断扩充。缺点是策略库覆盖不到的场景依然存在需要人工介入补充。我的经验是策略库不需要覆盖所有场景只需要覆盖高频场景和已知的危险场景剩下的长尾场景靠安全兜底规则来处理。5. 安全冗余与兜底机制决策算法的最后一道防线5.1 安全边界的设计原则决策算法再聪明也不能保证100%不出错。所以必须有一套独立的安全冗余机制在决策模块失效或者输出不合理时接管控制。这套机制的设计原则是简单、保守、可验证。简单意味着逻辑不能太复杂最好是基于几何和物理的硬约束比如“与任何障碍物的距离不得小于某个阈值”“减速度不得超过某个上限”。保守意味着宁可误刹也不能漏刹宁可停车也不能冒险。可验证意味着这套机制的行为可以被形式化证明或者在有限测试用例下穷举验证。我通常会把安全冗余设计成一个独立的模块和主决策模块并行运行。主决策模块输出轨迹后安全冗余模块会检查这条轨迹是否满足所有安全约束。如果不满足就触发紧急制动或者最小风险策略。这个检查过程必须是确定性的不能依赖任何学习模型。5.2 最小风险策略的触发逻辑最小风险策略是指当系统遇到无法处理的场景时采取的最保守动作通常是靠边停车或者在本车道内减速停车。触发条件包括感知模块置信度低于阈值、决策模块输出矛盾、通信超时、硬件故障等。触发逻辑的设计要避免两个极端一是过于敏感稍微有点风吹草动就触发导致车辆频繁急刹体验极差二是过于迟钝真正需要接管时已经来不及了。我的做法是设置多级触发阈值一级触发时先降级功能比如从自动驾驶降级到辅助驾驶提醒驾驶员接管二级触发时才执行最小风险策略。这样既给了驾驶员反应时间又保证了最终安全。5.3 冗余决策的仲裁机制如果系统里有两个独立的决策模块一个基于规则一个基于学习它们输出不一致时怎么办这就需要仲裁机制。我的仲裁逻辑是安全优先、规则优先。如果规则模块判断某个动作不安全无论学习模块怎么建议都直接否决。如果规则模块没有明确判断那就看学习模块的置信度置信度高就采纳置信度低就降级到保守策略。仲裁机制的关键是优先级明确、切换平滑。优先级明确意味着不能有模棱两可的情况每个模块的权限边界要清晰。切换平滑意味着从一种决策模式切换到另一种时不能有突兀的动作变化否则乘客会感到不适甚至恐慌。6. 从仿真到实车决策算法落地的那些坑6.1 仿真环境与真实世界的差距仿真在决策算法开发中不可或缺但仿真和真实世界的差距是巨大的。仿真里的其他车辆都是按规则行驶的真实世界里却有加塞、闯红灯、逆行等各种意外。仿真里的感知是完美的真实世界里感知有噪声、有漏检、有误检。仿真里的时间是离散的真实世界是连续的。我踩过的一个坑是在仿真里调好的决策参数上车后完全不能用。仿真里跟车距离设成2秒时距运行得很好实车上发现前车经常突然减速2秒根本不够得加到2.5秒甚至3秒。仿真里变道时机判断很准实车上因为感知延迟和定位误差变道时经常发现旁边车道其实有车。所以我的建议是仿真用来做回归测试和极端场景验证参数调优一定要在实车上做。仿真可以帮你快速发现逻辑错误但不能替代实车测试。6.2 数据闭环与场景挖掘决策算法的迭代离不开数据。但数据不是越多越好关键是要有场景代表性。我见过团队收集了几十万公里数据结果里面90%都是高速巡航真正有价值的复杂路口场景少得可怜。这样的数据对决策算法提升帮助有限。有效的做法是建立场景挖掘流水线从海量数据中自动识别出有价值的场景比如急刹车、近距离切入、行人横穿、无保护左转等。然后对这些场景进行标注和分类形成场景库。决策算法的测试和训练都围绕这个场景库来进行确保覆盖关键场景。场景挖掘的另一个作用是发现决策算法的盲区。有些场景可能开发人员从来没想过但实际路上就是会遇到。通过数据挖掘把这些场景找出来补充到测试用例里才能不断提升算法的鲁棒性。6.3 实车测试中的决策异常排查实车测试时决策异常是最难排查的因为决策模块的输入输出都是高维的不像感知那样有图像可以看。我的排查思路是分层定位、逐级回溯。先看行为选择层输出是否合理如果行为选择就不对那问题在上层。再看轨迹生成层轨迹是否满足约束如果轨迹不合理那问题在中层。最后看反馈修正层是否有异常的重规划如果频繁重规划那可能是偏差监控阈值设得太敏感。排查时一定要有完整的日志记录包括每一帧的输入特征、中间变量、输出结果。我习惯在决策模块里埋很多日志点虽然会增加一点计算开销但排查问题时能省大量时间。另外可视化工具也很重要把决策过程画出来比看日志直观得多。7. 我对决策算法未来演进的一些个人判断决策算法接下来会往哪个方向走我的判断是规则与学习的深度融合会成为主流。纯规则走不通纯学习也不敢用只有把两者的优势结合起来才能既保证安全又提升智能。具体来说我预计会看到更多可微分决策的工作就是把规则约束嵌入到神经网络训练过程中让网络在学习决策的同时自动满足安全约束。另一个方向是分层强化学习上层学行为选择下层学轨迹生成中间用安全规则做约束。这些方向目前都有研究但离量产还有距离。从工程角度看我觉得决策算法的评价体系也需要升级。现在大家主要看接管率、碰撞率这些指标但这些指标太粗了。应该引入更细粒度的指标比如决策一致性、交互合理性、乘客舒适度等才能更全面地衡量决策算法的好坏。最后说一点个人体会决策算法做久了会越来越觉得它不像纯技术问题更像是一个工程判断与价值取舍的问题。安全与效率怎么平衡保守与激进怎么选择这些没有标准答案取决于你的产品定位和用户群体。技术只是工具真正难的是想清楚你要什么。