自动驾驶架构演进：从模块化到端到端的技术路径与工程实践

1. 项目概述：Neolix的架构演进之路

最近和几个做自动驾驶的朋友聊天，大家都不约而同地提到了Neolix这家公司。不是因为它像Waymo或者Cruise那样在乘用车领域高歌猛进，而是它在特定场景下的商业化落地规模和背后的技术路线选择，让人不得不关注。Neolix，这家专注于无人配送车等低速封闭/半封闭场景的中国公司，正在经历一场从经典的“模块化”架构向“端到端”架构的深刻转型。这个转型，在我看来，不仅仅是技术栈的切换，更代表了自动驾驶行业在特定场景下，对成本、效率和可靠性平衡点的一次重新探索。

简单来说，传统的模块化自动驾驶就像一条分工明确的流水线：感知模块（眼睛）负责看路，识别车辆、行人、交通标志；定位与地图模块（大脑里的地图）告诉你现在在哪；预测模块（心理分析师）猜测其他交通参与者接下来想干嘛；规划模块（路径规划师）基于以上所有信息，规划出一条安全、舒适的行驶轨迹；最后控制模块（手脚）执行这个轨迹，控制方向盘、油门和刹车。这套架构逻辑清晰，可解释性强，每个模块都可以独立优化和调试。但问题也在于此：模块间的信息传递会有损失，误差会逐级累积，而且整个系统非常复杂、昂贵。

而端到端自动驾驶，则试图用一个大模型来“一口吃成个胖子”。你给模型输入传感器数据（比如摄像头图像、激光雷达点云），它直接输出控制指令（方向盘转角、油门刹车深度）。中间所有的感知、决策、规划过程，都隐含在这个巨大的神经网络里。这种架构的诱惑力在于它的“简洁”和潜在的高性能上限——理论上，模型可以学习到人类驾驶员那种综合的、直觉式的驾驶能力。Neolix的转型，正是从前者迈向后者的勇敢尝试。他们提出的“两阶段”端到端架构，据称已经支撑了超过17000辆车在300多个城市的运营，这个数字本身就值得深究其背后的技术逻辑。

2. 模块化架构的功与过：为什么需要改变？

在深入Neolix的端到端方案之前，我们有必要先理解模块化架构为何曾是主流，以及它又为何在今天面临挑战。我自己在早期参与自动驾驶项目时，就是典型的模块化思路，可以说对它的优缺点体会深刻。

2.1 模块化架构的核心优势：可控与可解释

模块化架构，或称“感知-预测-规划-控制”流水线，其最大的优点在于 可解释性和可控性 。每个模块都是一个相对独立的黑盒（或者灰盒），有明确的输入和输出。

• 感知模块 ：输出的是目标列表，包括边界框、类别、速度、朝向等。当系统误检一个行人时，我们可以清晰地定位是激光雷达点云聚类算法出了问题，还是摄像头视觉识别网络的置信度阈值设低了。
• 预测模块 ：输出的是其他车辆、行人未来几秒可能的轨迹分布。如果预测过于激进或保守，我们可以调整社会力模型参数或神经网络的结构。
• 规划模块 ：输出一条从A点到B点的时空轨迹。如果规划出的轨迹乘坐体验差（急刹、猛拐），我们可以调整代价函数中关于舒适度、安全距离的权重。

这种清晰的分层，使得 问题定位和迭代优化变得非常直接 。工程师可以针对性地“头痛医头，脚痛医脚”。例如，发现车辆在十字路口对横向穿行的自行车反应迟钝，我们可以单独优化预测模块对自行车运动模式的建模，或者调整规划模块在路口场景下的安全裕度，而不需要动辄重新训练一个万亿参数的大模型。

2.2 模块化架构的固有瓶颈：复杂性与误差累积

然而，正是这种“分工明确”，带来了难以逾越的瓶颈。我把它总结为“三座大山”。

第一座大山：系统复杂性爆炸。 一个完整的模块化自动驾驶系统，包含数十个甚至上百个子模块。每个模块都有自己的算法、参数、依赖库和硬件加速需求。维护这样一套系统的 集成、测试和部署成本极高 。任何一个模块的版本升级，都可能引发意想不到的连锁反应。我记得有一次，仅仅升级了感知模块中一个视觉骨干网络的版本，就导致规划模块因为输入的目标朝向角格式有细微变化而报错，排查了整整两天。

第二座大山：信息损失与误差累积。 这是模块化架构最本质的缺陷。感知模块为了追求实时性，往往会对原始传感器数据做大量的压缩和抽象。比如，将丰富的点云和像素信息，简化成一个个带属性的边界框。 边界框丢失了物体的形状细节、纹理信息、部分点云分布 。这些被丢弃的信息，可能对后续的预测和规划至关重要。例如，一个行人张开双臂的动作细节，在边界框表示中完全消失了，而这个动作可能预示着Ta要转向。误差会像滚雪球一样：感知的定位误差（±10厘米）会传递给预测，预测的不确定性会进一步放大，最终导致规划轨迹过于保守或不安全。

第三座大山：规则与学习的割裂。 在模块化架构中，规划和控制模块大量依赖 手写规则和启发