自动驾驶技术架构发展历程简介——从“规则驱动”到“数据驱动”架构到底在演进什么聊自动驾驶很多人都喜欢一上来就摆激光雷达数量、芯片算力、传感器方案但我自己这几年看下来真正决定一辆自动驾驶车能不能跑得稳、跑得远、跑得省的核心其实是藏在背后的那一套技术架构。架构这个词听起来很虚但它直接决定了系统怎么感知世界、怎么做决策、怎么执行控制以及在遇到极端情况时是“从容应对”还是“瞬间懵掉”。这篇文章想跟你认真梳理一下自动驾驶技术架构的发展历程。我会尽量把“为什么当年要那样设计”“后来又为什么要推翻重来”这些底层逻辑讲透也会穿插一些我在实际项目里踩过的坑和观察到的行业细节。无论你是刚入行的工程师还是想系统了解自动驾驶的产品经理、学生这篇文章都能给你画出一条比较清晰的演进脉络帮你理解今天市面上那些五花八门的方案其实都是在解决同一组核心矛盾。1. 早年模块化流水线架构感知、决策、执行各管一段1.1 为什么最初的架构像一条工厂流水线自动驾驶技术刚起步的时候业内普遍采用的就是一套非常朴素的模块化流水线。这套架构的思路可以概括成四个大字分而治之。既然开车这件事太复杂那就把它拆成一段一段的子任务每个模块只负责一件事模块之间用固定的接口把数据串起来。典型的分层方式是这样的最底层是传感器负责采集原始数据往上一层是感知模块负责从数据里识别出车、人、路、交通标志之类的目标再往上是定位模块告诉系统“我在哪里”然后是决策规划模块负责判断下一步往哪走最后是控制执行模块把规划好的轨迹变成方向盘和油门的动作。每个模块各司其职像流水线上不同的工位上一道的输出就是下一道的输入。这套架构在当年几乎是必然的选择。原因很简单早期的人工智能和机器学习能力远没有今天这么强感知部分用的是很多基于几何和统计的手工特征方法决策部分更是基本靠人类专家手写规则比如“红灯亮了就停车”“前车距离小于10米就减速”。如果不做模块化拆分一个试图包揽所有事情的单一系统在当时根本写不出来也没法调试。1.2 流水线架构的真正优势可解释性和可调试性现在回头看模块化流水线架构最宝贵的地方不在于它的性能而在于它的可解释性和可调试性。一辆车在路上出了个奇怪的问题工程师可以顺着数据流一层层排查是感知没看到障碍物还是定位跳变还是规划模块计算出了超出物理极限的轨迹每一步都有清晰的输入输出边界定位问题相对容易。我记得早年间在某个测试项目里遇到过系统在匝道口频繁刹停的情况。如果是一个端到端的黑盒系统这种问题排查起来会非常痛苦但在模块化架构下我们很快就通过回放日志确认是感知模块在特定角度下把路侧的护栏误识别成了静止障碍物于是针对感知的模型做数据补充问题就解决了。这种“哪里坏了修哪里”的体验在工程开发的早期阶段简直是救命稻草。不过这套架构的天花板也肉眼可见。它是典型的长尾问题放大器因为感知和决策之间的接口需要传递的信息是非常高层的抽象比如“这里有辆车”但实际驾驶中需要关心的是这辆车有没有打转向灯、它的轮速是不是在变化、驾驶员是不是在看手机——很多细腻的信息在接口层就被丢掉了。而且整套系统的性能上限被最弱的模块卡住规则写多了又会互相矛盾维护成本越来越高。业内逐渐意识到这条路继续走下去迟早要撞墙。2. 深度学习登场架构在“插桩”与“推倒重来”之间震荡2.1 感知模块被深度神经网络替换的过程那堵墙真正被撞出裂缝是深度学习开始大规模落地之后的事。2015年前后卷积神经网络在图像识别上的表现碾压了所有传统方法自动驾驶团队几乎是一夜之间反应过来感知模块应该全面拥抱神经网络。于是最初的那条流水线开始被“插桩式”改造。感知模块里的目标检测、车道线识别、语义分割这些子任务一个接一个换成了深度学习模型。换完之后效果是立竿见影的——识别的准确率、召回率都大幅提升很多以前靠手工特征搞不定的场景比如雨天、逆光、树影斑驳的路面神经网络的表现都稳定得多。但这里就出现了一个很微妙的错位。感知模块的输出还是按照老接口设计的它给决策模块传递的还是“目标ID类别速度位置”这一套结构化信息。也就是说虽然感知模块内部变得智能了但它和决策模块之间的“翻译方式”并没有变。这就好比你把一台老式收音机的喇叭换成了顶级音响但功放和音源接口还是原来的老规格音质的提升始终是会打折扣的。2.2 决策规则越来越写不动预测模块开始崛起决策部分的问题更严重。规则驱动的决策系统一开始感觉还挺好用随着测试里程的增加、场景的丰富需要写的规则数量呈爆炸式增长。处理一个十字路口左转要考虑对向直行车的让行逻辑、行人的过街意图、左转盲区的非机动车——每增加一个城市就增加一批本地化的道路规则和驾驶习惯规则之间还会互相打架。我们当时内部流传一句玩笑话规则系统就像一锅粥你每加一条规则就要搅一搅整锅粥搅的次数多了粥就糊了。更要命的是很多驾驶场景本质上是在处理不确定性。比如前车刹车灯亮了它到底是准备减速转弯还是要停下来旁边的摩托车是想并线还是想超车这些问题没有唯一正确答案只能估计概率。传统规则系统在这个层面是弱项于是架构里又长出了一个新模块预测模块。它专门负责根据感知历史和道路结构输出其他交通参与者的意图分布和未来轨迹。预测模块的出现其实已经是一次架构上的重大调整。因为它意味着系统的核心数据流从原来的“感知→决策→控制”单链条变成了“感知→预测→决策→控制”的新链条而且预测结果不是一条轨迹而是一堆带概率的候选轨迹。决策规划模块的使用方式也随之改变要在候选轨迹集合上做优化搜索。整个系统的复杂度又上了一个台阶。2.3 模块化架构的“接口损耗”问题逐渐成为焦点到了这个阶段业内对模块化架构的不满开始集中在两个字损耗。每经过一次模块间的抽象接口就会损失一部分信息每一次要传递的信息如果定义得不完整就会有不确定性被忽略。感知模型明明能输出非常丰富的特征表达但决策模块拿到的只是被压缩过的抽象结果预测模块明明能算出复杂的交互概率但规划模块往往只取了概率最高的那一两条轨迹来用。这就像一群人玩传话游戏每传一次都会丢掉一些细节等到最后一个人听到的时候信息已经严重失真。自动驾驶场景里失真的信息就可能意味着安全事故。于是一个大胆的想法开始浮出水面既然神经网络这么强能不能别搞这么多模块了直接把传感器原始数据喂给一个巨大的网络让它自己输出控制指令3. 端到端架构用一个模型吃下全局也把问题从“写规则”变成“喂数据”3.1 端到端的两种技术路线端到端架构的核心想法非常激进取消模块化流水线里所有的中间抽象让原始传感器数据直接输入一个巨大的神经网络网络直接输出方向盘转角、油门和刹车指令。这是对传统“分而治之”思想的彻底反叛属于“把问题整体丢给学习算法”。但“端到端”这个词在实际落地中其实有两条不同的路线经常被混为一谈。一条是“直接学习控制量”路线网络真的从头到尾吃像素/点云直接输出方向盘角度。这条路学术界很早就有探索但真正上车之后发现困难重重——丧失了所有的可解释性出了事故连原因都查不明白而且对训练数据的需求量惊人人类驾驶数据里大量时间是“直线平稳行驶”真正的高价值困难场景占比极低直接学习控制量根本喂不饱。另一条是“场景理解可微决策”路线也是目前主流玩家实际采用的。它的架构是感知部分依然用神经网络输出丰富的中间表征包括目标、地图结构、占用栅格等但不再把这些表征翻译成面向人类的抽象结果而是作为一个整体特征张量直接传入一个可微的决策规划网络最终输出轨迹或控制指令。关键在于从感知到决策的整个链路是联合训练的中间的“接口”不再是人为定义的而是网络自己学出来的。3.2 端到端架构解决的核心痛点信息无损传递为什么端到端架构这么有吸引力说白了它解决了我在第2章末尾提到的那个“接口损耗”问题。在模块化架构里感知、预测、规划各训练各的中间接口全是人工设计的而端到端架构里网络被允许自主决定“我要保留哪些信息、在哪个抽象层级上做决策”。举个例子。一辆自行车在路口闯了红灯斜穿过来传统模块化架构里预测模块可能把它的意图估计为“直线行驶”规划模块就按正常让行逻辑处理但实际上骑车人全程都在观察车辆动向他可能会犹豫、会减速、会变向。这种微妙的交互行为在传统架构里需要人为设计非常复杂的交互模型才能表达而且表达得还不好。端到端架构则可以理论上从数据里学到这种交互动力学因为它不再把一个目标简化成“类别速度位置”而是可以使用更丰富的表征来做判断。这一点被业内普遍看作是端到端架构在复杂城市驾驶场景里表现更好的根本原因。也是为什么最近几年几乎每一家头部自动驾驶公司都在向端到端架构转型——包括某Robotaxi公司和某头部车企的量产智驾系统。底层逻辑都是同一个把信息传递的损失降到最低把规则工程的手工成本消掉。3.3 端到端架构的代价可解释性变差、数据需求陡增但是端到端架构绝不是银弹它付出了非常现实的两个代价。第一个代价是可解释性断崖式下降。以前出了事故工程师能顺着模块链路找到“感知漏检”还是“规划失职”现在面对一个巨大的神经网络你只能知道“输入是这样输出是那样”中间发生了什么几乎是个黑盒。虽然可以通过可解释性分析工具去窥探网络内部关注了什么特征但在严格的安全认证和事故溯源场景里这远远不够。业内现在都在做“可解释的端到端”即在端到端框架里加入一些可被人类理解的中间监督头但那又在一定程度上回到了模块化的老路。这个矛盾至今没有完美解法。第二个代价是数据需求陡增。端到端网络把以前需要人类工程师写的规则全部变成了需要从数据里学到的分布。数据从哪里来一是海量的真实路采数据二是仿真生成的驾驶场景。很多公司都在建“数据闭环”系统专门把路测中发现的困难场景自动挖掘出来回流到训练集里再触发新一轮训练和验证。这个飞轮转得好不好直接决定了端到端系统的能力上限。我当时参与的一个项目在转向端到端架构时最大的感受就是“从写代码变成了养猪”——你得花大量力气去伺候数据管道、数据清洗、场景挖掘、标注质量模型本身反而像一头等着被喂大的猪你喂什么质量的料它长成什么质量的肉。这个比喻糙了点但道理是真的。4. 多传感器融合与车路云一体化系统工程层面的补全与延展4.1 传感器架构从单车智能向多源融合演进聊完算法层面的架构演进再看传感器架构你会发现它其实走了一条相似的路线从单一依赖到多源冗余、从“各算各的”到“深度融合”。最早的自动驾驶系统主要靠摄像头后来发现摄像头在黑夜、强光、雨雾里表现不稳于是加上了激光雷达提供精确距离信息又加上了毫米波雷达应对恶劣天气。但传感器多了之后新的问题出现了这些传感器的坐标系不同、采样频率不同、置信度不同怎么把信息合到一起早期的做法叫“后融合”也就是每个传感器分别做感知再把各自的感知结果目标列表综合起来。这种做法实现简单但本质上还是在做目标级的抽象融合又会丢掉很多底层信息而且不同传感器感知同一目标时的输出可能互相矛盾融合算法很难处理。后来逐步演进到“前融合”或叫“特征级融合”核心思路是在神经网络层面把多个传感器在特征层面就对齐并融合。比如把激光雷达点云投影到图像坐标系里或者使用鸟瞰视角把不同传感器的特征统一到同一空间网格上让网络自己学习如何综合利用各种信号。特征级融合的效果显著好于后融合因为它允许网络发现传感器之间互补的信息——比如摄像头看到“这是一块蓝色反光的东西”激光雷达同时得知“这是一个距离20米、高度0.5米的固体”两者在特征层面结合就比任何一个单独判断都可靠。从工程角度看前融合最大的难点是传感器标定和时间同步。摄像头和激光雷达的坐标系外参只要有厘米级的偏差特征对齐就会出问题融合模型的效果会全面劣化。我在实际项目里有相当一部分时间都耗在标定验证和时间戳对齐上。很多团队在模型结构上千挑万选最后效果不好一查往往是标定数据在某些角落已经产生了漂移。4.2 车路云一体化的架构理念单车智能的边界补充单车智能无论怎么卷都是戴着镣铐跳舞。它有物理边界传感器视野有限超过200米的路况就看不清了感知存在盲区被大车遮挡的行人、弯道后的逆行车辆单车根本无从知晓算力有限车端不可能塞进无限大的模型。所以行业里逐渐形成了一种系统工程层面的架构延展——车路云一体化。它把“路侧感知设备”摄像头、毫米波雷达、激光雷达等部署在路口和高风险路段通过路侧计算单元对道路环境做感知再通过无线通信把结果下发给经过的智能车辆云端则负责全局调度、地图更新、数据汇聚和模型训练。这样等于给单车装上了一双“上帝视角的眼睛”能看见拐角后面的事情。车路云一体化架构说白了就是在“车-路-云”之间构建一套分层的数据和决策体系。它的价值在城市交通治理场景里尤其明显绿波车速引导、交叉口碰撞预警、行人盲区提醒、特殊车辆优先通行这些都是单车智能很难独立解决的问题但在路侧感知的帮助下可以做得非常可靠。4.3 车路协同为什么推进得比预期的慢标准化与成本博弈不过从我接触的情况来看车路云一体的落地难度远超技术本身。最大的问题有两个。一是标准化的互通协议。路侧设备由不同厂商提供边缘计算单元的接口和消息格式五花八门车端系统怎么做到“接入任何一个城市的路侧系统都能理解对方在说什么”这需要行业级的统一标准但标准的制定和落地本身就是一场漫长的博弈牵涉到设备商、通信商、车企、地方政府等多方的利益协调进展缓慢。二是成本问题。路侧设备的安装、维护、通信费用要由谁承担对地方政府来说这是一笔持续性的公共支出如果没有清晰的投资回报路径很难长期大规模铺开。很多城市做示范项目时很积极但示范结束之后设备维护就跟不上了导致路侧数据质量波动很大。所以我的看法是车路云一体化在架构上是个必然方向但在商业逻辑上还需要等待一个更成熟的平衡点。短期内单车智能的能力提升仍然是行业的主赛道路侧能力则更像是“可选的强心剂”。5. 架构演进的底层逻辑性能、成本与可验证性的三角博弈5.1 从“写规则”到“费数据”开发模式发生了根本改变把前面几代架构放在一起看你会发现一个非常清晰的趋势人类工程师从“写规则的人”变成了“养模型的人”。以前的核心能力是定义规则逻辑、设计状态机、处理边界条件现在的核心能力是设计数据管道、做场景挖掘、清洗标注数据、评估模型回归指标。我自己刚接触自动驾驶时花了很多时间写决策逻辑那种“把驾驶经验变成代码”的成就感确实很爽。但今天再回头看当初写的那些规则在复杂交互场景面前确实力不从心。并不是说规则就完全没用了实际上到今天安全兜底逻辑依然大量依赖规则比如“碰撞时间低于阈值必须紧急制动”这类底层安全判断你不能指望一个模型在那种紧急时刻还靠谱。更准确的描述是规则的层级在向上移动从“决策执行层”上移到了“安全监控层”。这个改变背后的推动力其实是整个行业对“可验证性”的理解发生变化。以前验证规则系统靠的是穷举场景工程师写完规则后一条条测试现在验证数据驱动系统靠的是大规模测试集、仿真场景库和里程统计。你会慢慢习惯用统计学思维思考问题不再追求“每一个case都完美”而是追求“整体风险可控、长尾覆盖持续提升”。5.2 为什么今天的头部方案普遍是“端到端为主规则兜底”的混合形态如果你去看今天行业里真正规模落地的方案几乎没有哪家是“纯端到端”或者“纯规则”的鹅卵石一样的存在。大家普遍采用的是混合架构端到端网络负责绝大部分驾驶决策规则和监控系统负责安全兜底和行为约束。为什么因为纯规则的架构天花板太低纯端到端的架构风险不可控。这就像你雇了一个天分极高的年轻司机他大部分时间开得比你我都好但如果他某天状态异常、做出让你意想不到的操作你的安全底线在哪里规则兜底就是那个“无论如何都要拉出来的手刹”。这种混合形态也体现在工程实现里的很多细节。比如端到端网络输出的轨迹要经过一个约束检查模块确认不会压线、不会碰撞、不会超出车辆物理极限一旦违反就会触发安全响应。再比如端到端系统预测失败时系统会降级到预设的安全模式而不是像模块化系统那样直接崩溃或者不知所措。业内很多“脑洞大开”的端到端Demo都只是在特定测试环境里跑得顺一上路就露馅差距就在这里——不是模型本身差了而是缺乏完善的安全兜底架构。5.3 架构选择没有银弹关键看落地场景和商业目标最后想聊一个很多读者容易忽略的点架构没有绝对的好坏只有是否匹配落地场景和商业目标。L4级Robotaxi对安全性和长尾场景覆盖率要求极高它倾向于投入更重的传感器方案、更复杂的冗余架构、更强的算力平台因为它要替代的是“人类职业司机”可靠性标准非常严苛。乘用车量产智驾则不同它对成本极度敏感传感器数量要尽量少、芯片算力要尽量省、架构要能在千万级出货量下保持一致体验所以更倾向于视觉为主、端到端加轻量规则兜底、传感器融合以特征级融合为主但控制在合理算力消耗内。还有一个常常被忽视的维度是团队和组织架构。模块化架构对应的是“感知组、预测组、规划组、控制组”这样清晰的组织边界端到端架构则要求算法团队有更强的跨模块整合能力甚至要重新设计团队的协作方式。很多公司架构转型困难真正的问题往往不在技术上而在组织惯性上。回想这些年走过的路我的体会特别深的一点是自动驾驶的技术架构演进看起来是技术和模型的迭代实际上背后是一整套工程思维、组织方式、商业逻辑的共同进化。每一代架构都在性能、成本、可验证性之间做取舍不同的是各自寻找新的平衡点。如果你正在考虑进入这个领域或者正在为手头的项目做技术选型我的建议是不要盲目追逐热度最高的名词先想清楚你的应用场景、你的资源禀赋、你能接受的风险边界。架构是被这些问题塑造出来的结果而不是需要仰望的圣杯。6. 写在后面这篇梳理从模块化流水线开始一直聊到端到端加车路云一体化的当下图景中间其实略过了很多细节比如BEV感知如何统一多传感器特征、Occupancy Network如何解决通用障碍物问题、大模型如何进化为自动驾驶“世界模型”等这些都是可以在后续单独展开的大话题。作为个人观察我觉得接下来的几年会是自动驾驶架构“收敛”与“分化”并行的阶段。收敛是指端到端加规则兜底、再加数据闭环这套打法会成为行业主流范式各家的技术栈会越来越像分化则体现在应用场景上Robotaxi、干线物流、城市配送、量产智驾面对的成本约束和安全要求完全不同系统的细节设计和冗余策略会逐步分化出各自的形态。架构这东西最有趣的地方在于它从来不只是一张技术图纸而是一面镜子照出了设计者对问题本质的理解、对风险的权衡取舍以及对“自动驾驶到底应该更像一个逻辑推理系统还是一个更像人的行为系统”这个根本问题的态度。希望这篇梳理能给你带来一些参考。如果有问题欢迎在评论区聊聊你们在实际项目里遇到的架构取舍我挺好奇不同场景下的解法会有什么差异。