1. 问题本质决策算法不等于AI模型先说一个我踩过很久的坑。早年做自动驾驶项目时团队里一提到决策算法所有人第一反应就是上深度学习模型——端到端、强化学习、模仿学习各种高大上的词往项目申报书写。结果实车跑起来低速园区场景还行一上开放道路车辆行为跟老司机完全不沾边该让不让、该抢不抢、变道犹豫得像科目二考生。后来我才慢慢想明白一个事自动驾驶的决策算法本质上不是在选模型而是在定义驾驶行为。你希望这辆车像一个开了十年出租的老师傅还是一个遵纪守法但略显死板的新手这个定义一旦定下来后续所有技术选型才有讨论的前提。这篇文章我想认真聊聊我对决策算法的完整思考路径包括底层逻辑、架构分工、具体实操里容易忽略的细节以及我实际测试中遇到的那些教科书上不会写的坑。内容偏向工程视角适合做系统集成、算法部署、或者正在从感知阶段往决策阶段过渡的团队参考。1.1 为什么决策是自动驾驶里最拧巴的一环感知算法再复杂目标很单一把传感器数据变成结构化信息。控制算法再精妙目标也很明确把轨迹跟踪误差压下去。但决策算法夹在中间它要同时回应两件事——我想怎么开和别人会怎么开。前者是自车意图后者是对周围交通参与者的预测。这俩常常打架。举个例子你打算向左变道后视镜里看到一辆车正在加速逼近按照交规你应该放弃变道但按照博弈论你应该加速完成变道——因为对方加速通常意味着他不想让你插进来这时候你犹豫反而更危险。这种两难局面在结构化道路上的测试场景里层出不穷。决策算法如果只按规则表查表处理不了这种博弈如果只按概率模型算又在极端场景下缺乏可解释性。这就是它拧巴的根源。1.2 决策算法的能力边界要先想清楚很多团队在立项时把决策算法的能力边界划得太宽恨不得一个模块解决预测、规划、控制、甚至高精地图匹配。我的建议是先把决策层的职责做窄再做深。决策层核心只回答三个问题当前场景下我该执行什么驾驶行为跟车、巡航、变道、绕障、靠边停车、紧急制动等在多个可行行为之间如何做选择优先级、代价、安全余量一旦行为确定如何在时间轴上给规划层输出一个行为约束窗口比如变道需要在3秒内完成车速允许波动范围等。至于轨迹怎么平滑、曲率怎么约束、PID参数怎么调那是规划和控制层的事。把决策层从全知全能的神坛上拉下来整个系统才容易收敛。2. 架构分工决策算法在自动驾驶系统里的真实位置很多文章喜欢画一张大而全的自动驾驶系统架构图感知、预测、规划、控制、地图、定位一圈围起来然后说决策算法在中间。这种图没错但对工程落地没有指导意义。我更喜欢从行为产生链路来理解决策算法的作用位置。2.1 从感知到执行的完整数据链路一辆自动驾驶车在路上行驶时数据流是这样的传感器摄像头、激光雷达、毫米波雷达采集原始数据感知模块输出障碍物列表、车道线信息、交通标志识别结果预测模块输出周围车辆/行人的未来轨迹概率分布决策模块接收以上信息结合路由规划给出的宏观行驶方向把宏观路线翻译成微观驾驶行为规划模块在决策给出的行为约束下生成具体轨迹控制模块把轨迹转换成方向盘转角、油门刹车指令执行机构完成物理动作。这个链路里决策算法是唯一一个既要向上理解意图、又要向下约束动作的中间层。它不像感知那样有统一的评价指标mAP、IoU也不像控制那样有明确的跟踪误差指标横向偏差、纵向偏差它的评价往往是这个行为开着像不像人、安不安全、顺不顺。2.2 决策层与前向预测的关系不是谁依赖谁而是互相校验不少做决策的人习惯把预测结果当输入直接喂给策略模型。比如预测模块说前车有80%的概率会变道决策模块就直接按变道来处理。这在大多数情况下没问题但有个隐患预测模块本身也可能是错的决策层需要有自己的判断逻辑来校验预测合理性。具体来说我建议决策模块保留两个底层的安全兜底机制第一层是保守假设预测说是80%变道决策里按可能变道也可能不变道同时准备两套行为预案第二层是时间窗口如果一个行为决策超过N秒仍然模棱两可强制降级到最安全的行为比如减速让行。这种设计虽然牺牲了一点效率但换来了系统在预测错误情况下的安全性。在真实道路测试里预测给出的概率本身很多就是统计模型从有限数据里学的边界情况根本没法穷举没有兜底机制就是在赌运气。2.3 决策输出如何约束规划层决策算法跟规划层的接口设计是工程上最容易扯皮的点。我见过一个项目决策层把向左变道的点位直接发给规划层规划层认为这是死命令强行生成了变道轨迹。结果是决策层早已发现后车加速逼近想取消变道但规划层还在执行旧指令系统就出现了约0.5秒的反悔真空期。原因就是两层的交互语义没定义清楚。搞了好几个项目之后我倾向于如下接口设计决策层输出的不是具体坐标点而是一个行为意图约束条件的结构体约束条件包括可行时间窗口、速度允许区间、横向偏移限制、取消条件定义规划层在约束范围内有自由发挥空间并定期向决策层反馈执行状态当决策层改变行为意图时通过一个取消令牌机制通知规划层立即停止旧行为、切换新行为。这套接口设计让决策与规划之间从命令-执行关系变成了契约-协作关系。实车测试里行为切换的响应速度明显提升反悔真空期从0.5秒降到了0.1秒以内。3. 技术选型规则、搜索、监督学习、强化学习的真实分工关于决策算法的技术路线选择行业内吵了很多年各有各的拥趸。我不站队但我可以说说在真实项目里我倾向于什么样的混合架构。3.1 规则决策下限的守护者永远不能丢纯规则决策有限状态机、决策树、逻辑判断虽然听起来不够智能但它是自动驾驶安全性的最后防线。原因很简单规则是确定性逻辑输入一样输出永远一样可测试性最强。实际项目中我始终保留一个轻量级规则决策作为安全兜底模块常驻后台运行。它不负责日常的优雅驾驶只负责检测当前行为是否越过了安全边界一旦触发边界条件比如与前车距离小于阈值、侧方车辆侵入安全区立即强制切换行为。这套设计的好处是无论前面的AI策略模型出了什么幺蛾子车辆都不会突破物理安全的底线。有一说一我做过几次关闭规则兜底、只靠策略模型的测试结果都在一些边缘case上让人后脊背发凉——AI模型在分布外场景的泛化能力远没有想象中可靠。3.2 搜索与优化类方法保守但有效对决策问题进行搜索比如蒙特卡洛树搜索、状态格搜索或者建模成优化问题在学术界看起来很稳工程上落地却很考验算力和调参水平。核心思路是把决策变成在有限行为空间中搜索一条最优路径。每个候选行为通过一个代价函数来打分代价项包括安全性代价碰撞风险、效率代价通行时间、舒适性代价加速度冲击等。搜索类方法在低速园区、结构化停车场景里表现很好因为行为空间有限、计算量可控。但到了开放道路面对高速动态交通流状态空间爆炸会导致搜索时间不可控。我个人的经验是搜索类方法适合在封闭或半封闭场景中做主要决策方法在开放道路场景中做局部行为的精细化决策比如变道时机、跟车距离调整。3.3 监督学习从人类驾驶数据中快速起步用大量人类驾驶数据训练一个行为克隆模型输入是环境特征自车状态、周围障碍物、道路结构输出是驾驶行为标签。这种方法启动快、效果下线不低特别适合在项目初期快速得到一个能用的决策模块。但必须承认它的天花板也很明显行为克隆学习的是数据里的统计相关性不是因果逻辑。一旦遇到训练分布之外的长尾场景比如前车突然掉落货物、对向车逆行模型的反应就会很迷。在项目里我一般把监督学习模型当成策略候选生成器让它给出几种候选行为再由规则或者说理层做最终裁决。别让它直接作为唯一决策来源。3.4 强化学习方向正确但别期望上线即能用强化学习用环境奖励信号来学习决策策略理论上可以获得比人类更优的驾驶行为也是我很看好的长期方向。但这里要泼一盆冷水当前强化学习在自动驾驶决策中的落地绝大多数还停留在仿真环境里。原因很直接安全约束真实道路上让RL智能体自由探索试错成本不可接受奖励设计难驾驶行为是多目标优化安全、效率、舒适、合规怎么加权本身就是一个难题仿真与现实的差距仿真里的传感器噪声、物理动力学模型再逼真到了实车上还是会有各种假人假事。我的实践是用强化学习在仿真环境里离线训练出一个行为建议器再把它的输出和规则决策树融合。融合方式很简单规则决策判断安全性RL建议器在安全的行为集合里选一个更高效或者更像人的。这个策略既不激进也不迟钝效果还不错。3.5 各技术路线对比速查技术路线优势劣势我推荐的适用场景规则决策确定性高、可解释性强、开发调试快场景覆盖有限、维护成本随复杂度上升安全兜底、低速封闭场景、行为约束搜索/优化可全局寻优、结果可解释算力消耗大、实时性难保障停车泊车、低速园区、局部精细化决策监督学习数据驱动、开发快泛化能力弱、可解释性差行为候选生成、策略预筛强化学习能学到非直觉策略训练难度大、实车部署风险高仿真预研、离线行为建议4. 决策算法的关键要素安全、效率、舒适性、可解释性的平衡术这一节我想展开聊聊决策算法的目标函数怎么设计。目标函数设计得对不对直接决定了车辆开起来是人是鬼。4.1 安全性的真实定义不是不碰撞而是留有安全余量新手做决策算法时最喜欢把安全定义为不碰撞。这会在工程上带来一个致命后果算法会把碰撞当作唯一的终极惩罚项只要不碰撞怎么做都行。结果就是车辆贴着前车屁股走、贴着护栏变道、用极限加速度制动——不撞但吓死。我更推荐把安全定义为可量化的安全余量。比如纵向安全自车在当前速度下即使前车突然全力制动自车也有足够的跟车距离通过减速避免碰撞横向安全变道时目标车道后方车辆在自车变道期间不需要采取紧急避让动作安全包络把自车膨胀一个虚拟安全边界通常是根据速度动态调整的任何障碍物都不得侵入这个边界。这样定义之后安全就不是一个二元结果而是一个可以连续优化的目标。决策算法可以稍微冒一点险来提高效率但前提是安全余量始终保持在阈值以上。4.2 效率目标别把早到作为唯一指标通行效率是决策算法另一个重要目标但直接优化到达时间最短很容易引发激进驾驶。我见过的实际案例某团队把到达时间作为目标函数主要权重项结果车辆在高速上频繁变道、频繁加速测试人员坐得直晕车。最后数据分析发现全行程到达时间只比正常驾驶快了约3分钟但横向加速度超过舒适阈值的频次提高了一倍多。更合理的做法是把效率目标拆成局部时间损失和全局行程进度两级。局部效率鼓励车辆在跟车、过路口时减少不必要的时间损失全局效率由路由规划层控制决策层不直接优化到达时间。这样效率目标就被约束在一个相对理性的范围内。4.3 舒适性用加速度和冲击度来约束驾驶风格坐过网约车的都知道同一个路段不同司机开起来的体感完全不同。舒适的驾驶风格可以在决策算法里用两个指标来度量化加速度横向加速度一般控制在0.3g以下纵向加速度控制在0.2~0.25g以下冲击度加加速度加速度的变化率控制在每秒不超过0.2~0.3g。决策算法在生成候选行为时可以预计算每个行为的加速度曲线和冲击度曲线超过舒适性阈值的直接过滤掉。不要等到规划层再去限幅——那时候行为已经定死强制限幅会让轨迹变得很生硬。4.4 可解释性事故追责和数据闭环的刚需在自动驾驶行业待久了你会发现一个问题模型可以黑盒系统不能黑盒。如果车辆在事故中做出了一个匪夷所思的决策工程师需要快速回答三个问题当时环境是什么状态决策模块为什么选择这个行为是哪个输入导致了决策改变。如果决策算法是纯端到端的神经网络这些问题几乎无法回答。所以我一直建议在决策模块中保留一个决策日志模块实时记录关键输入特征、候选行为集合、每个候选的打分结果、最终选定的行为及其理由。不要小看这个日志系统。后来我在多次实际测试中都是靠这个日志快速定位到问题——比如有一次车辆在高速匝道上突然急刹查日志发现是预测模块把路侧护栏误识别成了静止障碍物决策层根据规则不得不触发紧急制动。如果没有决策日志这个问题排查至少要多花两三天时间而且大概率要靠到处打日志去猜。5. 实操拆解如何构造一个行为决策模块理论讲了一大堆最终还是要落到工程实现上。我以自己项目里一个比较典型的行为决策模块为例拆解一下具体实现过程。这个模块应用于城市开放道路支持跟车、巡航、变道、掉头、靠边停车等常见行为。5.1 候选行为集的构造与过滤第一步是枚举所有在当前场景下理论上可行的驾驶行为。这一步不需要太智能粗暴一点反而好。比如保持当前车道匀速/加减速向左/向右变道减速让行或停车等待加速汇入或超越慢车靠边停车或掉头仅在特定道路条件下。每个候选行为自带一组必要条件。比如变道需要满足以下条件目标车道存在、目标车道后方无高速接近车辆、自车与目标车道前车有足够间距、道路标线允许变道。构造完候选集后逐个检查必要条件不符合的直接丢弃。这一步能把行为空间从几十个压缩到两三个为后续精细化打分降低计算压力。5.2 代价函数的设计细节对过滤后的候选行为我用一个加权代价函数来打分。代价项和权重如下这些权重是我经过实车测试反复调整得到的代价项初始权重调整说明安全余量不足0.35优先级最高只要安全余量低于阈值就尽量不选效率损失0.25预计时间损失越大代价越高舒适性代价0.2预测加速度/冲击度超阈值的代价路径跟随难度0.1行为执行时控制层可能需要更高精度违规/风险代价0.1压实线、越实线、进入禁行区等一种比较实用的思路是先把安全余量不足的候选行为直接过滤掉不在代价函数里参与比较。因为一次碰撞带来的损失远大于任何效率收益权重再高也表达不了这种一票否决的特性。5.3 决策协商机制多行为并行评估与仲裁在真实道路测试里有一个容易翻车的情况两个候选行为得分非常接近。比如继续跟车代价是0.72向左变道代价是0.70差0.02就让人纠结。我的做法是引入一个行为切换滞后机制。只有当新候选行为的得分比当前行为低超过一个阈值比如0.05时才允许切换。这个阈值可以有效防止行为频繁抖动。没有滞后机制的话车辆会在两条车道之间反复横跳测试视频看着还能忍实车体验极差。如果确实出现两个行为的代价差始终在阈值内的拉锯场景我统一处理为保持当前行为。规则很简单不确定的时候保持正在做的、规避新风险。这跟人类驾驶经验其实是一致的犹豫不决时稳住往往比乱动更安全。5.4 与下游规划的实际对接方式决策层选出一个最优行为后怎么交付给规划层工程上有许多细节稍有不慎就会出问题。我采用的对接结构如下决策输出示例 behavior: 向左变道至左二车道 time_window: [1.2s, 3.0s]即需要在3秒内开始并完成 speed_range: [40km/h, 60km/h] cancel_condition: 目标车道后方来车距离进入400m以内取消 minor_adjustment: 允许规划层在横向偏移量±0.3m内自适应规划层在这个约束下自行生成贝塞尔曲线或样条曲线。当决策层要变更行为时通过取消令牌通知规划层停止当前轨迹生成重新以最新行为指令作为输入去生成新轨迹。这里还要强调一下决策输出中时间窗口和速度区间是约束不是目标。约束给的是空间目标给的是方向。规划层需要的是在空间里找一条最优解而不是机械执行决策层给的数值。5.5 数据闭环让决策算法持续迭代的关键决策算法的迭代依赖真实场景数据尤其是bad case。我每次实车测试后都会把触发紧急制动、频繁变道、突然加速等情况的片段自动录制下来连同摄像头、激光雷达、决策日志一起打包回传构成一个决策问题库。然后定期用这些问题片段重构仿真场景回放问题行为调试策略参数。这个过程听起来不复杂但非常耗时因为你要去还原当时的完整场景重新输入给候选决策算法观察它是否能避免错误行为。我比较推荐的做法是在仿真回放过程中同时对两个版本的算法跑对比测试线上出问题的版本和正在调整的新版本。让两者面对同样的历史场景比较行为差异和代价差异来判断新策略是否真的有效。这种方式比只看离线测试集上的指标靠谱得多。6. 实车测试中的高频路况决策算法最容易被问住的瞬间决策算法看书是一回事上路又是另一回事。下面这几个场景我几乎每次在项目实测现场都会遇到也是决策算法最容易暴露短板的地方。整理成一个速查表方便大家对照自查。6.1 常见疑难场景速查表场景决策难点我踩过的坑最终的解决方向汇入拥堵匝道何时加速汇入何时减速等待决策过急导致与主线车距不足触发紧急制动引入汇入博弈代价预测对目标车道后方车辆意图做快速判定无保护左转对向直行车流中找缝隙从众心理让算法尝试过窄间隙惊险在决策中加入最小时间间隙约束宁可多等一个周期电动自行车突窜非结构化交通参与者的轨迹预测预测模块把骑车人轨迹当成直线完全没预案决策层对所有小目标增加保守减速倾向减少夜间/遮挡情况下的虚拟碰撞高速前车急刹紧急情况下选变道还是重刹算法优先变道但未检查相邻车道规则兜底模块在紧急情况下优先保纵向安全再考虑变道连续施工改道复杂标线、临时桩桶的语义理解决策层把临时桩桶当障碍物反复报警融合地图层的临时改道信息决策层增加施工区低速模式6.2 三个每个人都会遇到的经典现场第一个经典现场是被加塞时要不要让。前车突然打灯变道进你的车道此时决策算法要在不到0.5秒内判断是减速让行还是保持速度不让。我的经验是如果对方车头已经进入自车车道超过三分之一建议直接让行并拉开跟车距离。这不仅是安全考虑也符合多数交通环境下的社会默契。决策算法里写一个简单判断条件就够用了侵入比例小于阈值且相对速度较高保持不让否则让行。第二个经典现场是绿灯闪烁时的过路口决策。如果距离停车线还远果断减速准备停车如果已经很接近停车线且速度不快直接匀速通过。最怕的就是决策层在犹豫加速一下又刹车一下后车司机会直接怼喇叭。我测试时发现引入一个简单的基于最大可用减速度的临界距离判断这个问题就能解决得比较好。第三个经典现场是前方慢车占道是否可以借用对向车道超车。这个场景在封闭道路上很少见但在乡村道路、园区内部道路很常见。我目前的处理方式是如果道路中央无实线且对向视野良好允许有限时间借道超车如果对向有遮挡或道路湿滑强制保持跟车。这个逻辑用规则就能表达不要复杂模型。7. 一些长期视角决策算法后续还能怎么演进前面聊的都是当下的工程实现最后我想聊聊我个人认为决策算法未来可能的演进方向。这一节的出发点不是站在演讲台上讲宏大叙事而是基于手上的项目觉得哪些方向值得投入。7.1 数据驱动的场景识别和规则生成目前很多决策模块的场景识别还是靠手写规则。随着积累的场景库越来越大是否可以自动从数据中归纳出场景模式比如自动发现前方慢车目标车道空旷后车距离远是高概率变道场景并自动生成对应的候选行为集和参数。这个方向我在内部做过一些原型验证结论是可做的前期投入会比较大。至少要有几万段带标注的驾驶场景片段然后做场景聚类、行为模式挖掘、规则自动提炼。如果能把这一步跑通决策模块的迭代速度会有量级提升。7.2 生态交互与社会行为建模未来自动驾驶要真正融入人类社会交通不仅要知道自车能做什么还要知道周围人会怎么看我的行为。乘客在车内看到的视角跟路人的视角完全不同。一个在车内看很平稳的变道在路边行人看来可能已经贴得很近了。所以我认为决策算法的一个重要演进方向是建立他人视角的反馈模型。模拟其他交通参与者看到我们车辆时的心理预期并反过来调整自车行为。这项技术真正落地可能还很遥远但值得提前布局。7.3 仿真到实车的联动迭代体系最后还想强调一下仿真与实车的协同。现在很多团队把仿真环境当成练兵场实车当成考场两者之间的鸿沟太大。我更倾向于构建一个场景回放-策略调整-仿真验证-实车确认的闭环体系实车数据采集后自动挖掘bad case生成仿真场景在仿真场景里迭代决策策略对改进后的策略批量回放历史场景排除回归问题最后再上实车做有限场景验证。这个体系一旦运转顺畅决策算法的迭代效率会很高而且越到后期坑越少。我们项目就是从频繁实车发现问题-回实验室调参-再上实车验证的循环逐渐变成了实车积累数据-仿真批量迭代-实车针对性验证的体系后者的开发节奏要舒服得多。8. 决策算法调试笔记本那些值得再重复的忠告写到最后我想把这几年来跟决策算法打交道时攒下的几笔小笔记拿出来分享一下。这些不一定写成论文但每一个都值过学费。8.1 先定义什么是开得好再讨论怎么算得好我见过太多项目一开始就投入大量人力做模型调参结果产品定义都还没想清楚。你要先想明白你的自动驾驶车辆是给什么样的用户用的是在什么道路上跑是更看重通行效率还是乘坐舒适这些问题不定义清楚决策算法的目标函数就是一锅粥。8.2 安全兜底模块永远要独立于策略模型不管策略模型多高级安全兜底模块都要独立存在。它的逻辑要足够简单简单到任何工程师都能直接审查代码。不要让复杂模型的输出直接控制系统执行层。这个结论我是一次深夜路测后彻底坚定的当时策略模型在某个罕见场景下给出了一个完全不符合常识的行为要不是规则兜底先一步介入测试车就要压到路肩上了。8.3 可解释性投资要趁早决策日志模块和可视化工具一定要在算法开发早期就搭好。等到后期再去补付出的成本要高出数倍因为很多早前决策已经无法复盘当时的环境上下文了。我比较推荐用一套简单的离线回放工具能够把每一帧的感知结果、预测结果、候选行为、代价分数、最终选择都叠在一张全景图里。这样分析bad case的效率会高非常多。8.4 小步快跑持续积累场景库决策算法没有毕业的一天。任何一套策略今天看着没问题明天换个城市、换个季节、换个时间段可能就会出现新问题。所以团队一定要有持续采集数据、持续发现问题、持续迭代策略的机制。这不是可选项是必选项。每次实车实验我都会把今天的决策日志导出来整理进问题库哪怕当天测试看起来很顺——有些问题要在海量统计之后才能暴露出来。这些年的经历让我越来越确信决策算法不是某一项技术的胜利而是工程系统思维的胜利。它需要把安全规则、数据模型、代价设计、接口协议、测试体系拧成一股绳。这个过程没有捷径但也不需要神话它——找到合适的团队踩准合适的节奏把每一个小问题都按工程方法去解决它就那么一步一步地变可用了。