从 9000 多篇投稿里拿到最佳论文，靠的不是某个新算子，而是一个架构哲学：让每一个感知模块都为最终的驾驶决策服务。这一篇是前四篇的汇合点。
这是读 UniAD 前必须想明白的问题。翻遍全文，你找不到一个石破天惊的新模块——BEV 编码用的是现成的 BEVFormer，检测跟踪借鉴 MOTR，建图借鉴 Panoptic SegFormer，注意力还是 Transformer 那一套。
它的贡献不在零件，在于怎么把零件组织起来。而这个组织方式回答了当时整个行业最纠结的一个问题：
自动驾驶要做的事很多——检测、跟踪、建图、预测、占据、规划。这些任务到底该怎么摆在一起？
各自独立训练？共享骨干并行输出？还是别的方式？这个问题在 2023 年之前没有公认答案，而它直接决定了整个系统的天花板。
UniAD 给出的答案，写在标题里：Planning-oriented（以规划为导向）。这五个字不是口号，是一套可以落地检验的架构原则——系统里的每个模块，都必须为最终的规划输出服务；不服务于规划的任务，不该存在。
论文的一句话概括值得记住：感知是为了更好地预测，预测是为了更好地规划。所有任务不是平行的，而是层层递进的。
要理解 UniAD 的价值，得先看清它在反对什么。
方案 (a) 像微服务之间传 JSON——接口清晰但信息有损，上游改了下游要跟着改，出了问题层层甩锅。
方案 (b) 像几个服务共用一个数据库但互不调用——省了资源，但没有协同。
方案 (c) 像一个进程内传对象引用，而且整条链路可以端到端做性能归因——上游的每一点改动，都能直接看到对最终结果的影响，并据此自动优化。
论文的消融实验专门验证了这一点：UniAD 显著优于朴素的多任务学习方案，尤其在预测和规划任务上。这说明"把多个任务放在一起训练"本身不会自动变好，关键在于任务之间的信息传递方式和层级结构设计。
整个 UniAD 用一句话概括：6 个摄像头图像作为输入，经过 5 个任务模块层层递进，最终输出安全的驾驶轨迹。
| 模块 | 做什么 | 输出的 query | 为规划提供什么 |
|---|---|---|---|
| TrackFormer | 检测 + 跨帧跟踪 | Agent Query | 周围有哪些车/人，它们是谁 |
| MapFormer | 在线建图 | Map Query | 路在哪、车道怎么走 |
| MotionFormer | 预测他车未来轨迹 | Motion Query | 它们接下来会怎么动 |
| OccFormer | 预测未来占据栅格 | 占据概率图 | 未来哪些地方不能去 |
| Planner | 规划自车轨迹 | 轨迹点 | 最终答案 |
图里最左边那个 BEVFormer 就是你第一篇深度拆解的内容——它在 UniAD 里充当"眼睛"，把 6 路相机压成 200×200×256 的 BEV 特征。UniAD 是建在 BEVFormer 之上的，这也是为什么当初先讲 BEVFormer 是对的顺序。
UniAD 最核心的设计是"用统一的 query 接口串联所有模块"。这个演示让你看清每个模块的上下游关系。点击任意模块，会高亮它的输入来源和输出去向。
从 TrackFormer 一路点到 Planner，你会看到 query 像接力棒一样传递：感知层的 query 传给预测层，预测层的 query 传给规划层。
而且这些 query 都是可学习的——规划做得不好，梯度会一路回传，逼着前面的跟踪和建图调整自己的表示，去输出"对规划更有用"的信息，而不只是"检测得更准"的信息。这就是 planning-oriented 的技术实现。
传统跟踪是"先检测，再用匈牙利算法把前后帧的框匹配起来"——检测和跟踪是两步，中间靠手写规则关联。
TrackFormer 用两类 query 把这件事变成一步：
妙处在于：同一个 Track Query 在多帧中始终对应同一个物体，跟踪身份天然保持，不需要额外的匹配算法。
看球赛时，Detection Query 是盯着替补席看谁上场的人，Track Query 是每人负责紧盯一名已在场球员的人。球员被人群短暂挡住时，负责他的那个人不会立刻放弃——这就是论文里的"生命周期机制"：目标被短暂遮挡时 query 不会立即消失，而是保持一段时间，避免跟踪中断。
传统方案依赖高精地图：提前用测绘车把每条车道线厘米级采集好，车上跑的时候直接读。问题是成本极高、更新滞后、没测绘过的路就不能开。
MapFormer 直接从 BEV 特征里"看"出路面信息——车道、可行驶区域、分隔线、人行横道。这就是所谓的"无图驾驶"能力。
它输出的 Map Query 不只是给人看的地图，更重要的是传给 MotionFormer 当作预测的依据——因为车会沿着车道开，知道车道走向才能预测得准。
这是 UniAD 最精妙的模块之一。预测一辆车接下来怎么走，要同时考虑三件事：
车辆之间互相影响。前车刹车，后车也得刹。密集车流里每辆车的动作都受周围车约束。
车辆沿车道行驶。知道车道往哪拐，才能预测车会往哪拐——这就是 MapFormer 的 query 必须传进来的原因。
每条候选轨迹都有一个终点意图。模型围绕预测的目标点做局部注意力，让轨迹终点更准。
而且有个关键设计：自车也被当作一个 agent 放进 MotionFormer 里联合建模。这样自车的未来和他车的未来是一起预测出来的，天然考虑了"我这样走，别人会怎么反应"。
你运球突破时，同时在算三件事：队友和对手的位置（Agent-Agent）、球场边界和三秒区在哪（Agent-Map）、我想突到哪个位置出手（目标点）。MotionFormer 用注意力机制把这三种考量同时建模，而不是像传统方法那样写一堆 if-else 规则。
输出是每个 agent 的 K 条候选轨迹——因为未来本身是多可能的：前面那辆车可能直行也可能变道，模型不做单一承诺，而是给出多个可能性及其概率。这个"保留不确定性"的思路，和你上一篇 LSS 里深度分布的做法是同一个哲学。
这是很多人读 UniAD 时的困惑：MotionFormer 已经预测了周围车辆的未来轨迹，为什么还要专门再做一个占据预测？
MotionFormer 只能预测被跟踪到的目标——也就是检测器认识、并且分配了 Track Query 的那些物体（车、人、自行车）。
但路上还有大量"不在类别表里"的东西：路边一排停着的车、掉落的货物、施工围挡、侧翻的卡车、突然出现的异形障碍物。检测器没有对应类别，就不会产生 Track Query，MotionFormer 也就无从预测。
而这些东西照样会撞车。
OccFormer 的解法是绕开"识别"这一步：不管那是什么东西，只回答"未来某个时刻，BEV 网格上这一格会不会被占据"。
论文的消融实验证明了这个设计的价值：同时使用 MotionFormer 和 OccFormer，比单独使用任何一个都更好。两者信息互补——一个提供精确的"谁会去哪"，一个提供兜底的"哪里不能去"。
特斯拉 FSD 主推的 Occupancy Network 走的就是这个思路，而且推得更极致——几乎完全用占据表示取代 3D 框检测。理由正是这一节讲的：真实道路上的长尾障碍物永远列举不完，与其拼命扩充类别表，不如直接建模"空间被占没被占"。
你之前读到的"FSD v14 一段式端到端"，感知侧的核心表示就是这个。
Planner 用一个特殊的 Ego Query（自车查询向量）去"询问"前面所有模块产生的信息：
然后输出自车未来的轨迹。但光模仿人类驾驶还不够——模仿学习有个天然缺陷：它只学会了"人类一般怎么开"，没学会"什么绝对不能做"。
UniAD 在规划阶段加了一个碰撞损失：把规划出的轨迹和 OccFormer 预测的未来占据栅格做比对，如果轨迹经过了高占据概率的格子，就重罚。
# 规划损失 = 模仿损失 + 碰撞损失
模仿损失: 让规划轨迹尽量接近人类专家的真实驾驶轨迹
# 学会「一般怎么开」
碰撞损失: 惩罚轨迹与预测占据栅格的重叠
# 学会「什么绝对不能做」
# 关键：碰撞损失的梯度会一路回传到 OccFormer 甚至 BEV 编码器
# 逼着感知层去关注「对避免碰撞重要」的区域感知模块的训练信号不只来自"检测得准不准"，还来自"最终有没有撞车"。
这意味着 UniAD 的感知层会自发地更关注那些对安全驾驶关键的目标——正前方的车比路边远处的车重要，即使后者检测起来同样简单。传统的模块化流水线做不到这一点，因为感知模块根本收不到规划的反馈。
提出一个架构容易，证明"每个部件都真的有用"才难。UniAD 的消融实验是全文最硬的证据，也是最值得学的科研方法。
移除 TrackFormer 或 MapFormer 之后，运动预测性能显著下降。
这验证了那句"感知是为了更好地预测"不是空话——预测确实需要感知提供的 agent 身份和地图结构。
统一使用 MotionFormer + OccFormer，比单独使用任何一个都更好。
证明了第 5 节讲的互补性：精确轨迹 + 兜底占据，缺一不可。
UniAD 显著优于朴素的多任务学习方案，尤其在预测和规划任务上。
这是全文最重要的结论：不是把多个任务放在一起训练就能变好，关键在于任务之间的信息传递方式和层级结构设计。
| 任务 | 指标 | UniAD 数值 | 含义 |
|---|---|---|---|
| 跟踪 | AMOTA | 0.390 | 跟踪准确率 |
| 运动预测 | minADE | 0.71m | 预测轨迹与真实的最小平均偏差 |
| 占据预测 | IoU-near | 63.4% | 近处区域的交并比 |
| 规划 | avg. Col | 0.31% | 平均碰撞率（越低越好） |
UniAD 不是一上来就端到端训所有模块，而是分两阶段：
如果一开始就全部一起训，感知还没学好，就在给预测和规划模块喂垃圾信息，导致训练极不稳定。就像盖楼，地基没打好就往上建，肯定要塌。
这个细节对你复现很关键——跳过第一阶段直接端到端训，大概率训不出论文的指标。你项目里那份 UniAD 学习指南里也强调了这一点。
把你读过的五篇串起来看，UniAD 的位置就非常清楚了：
| 论文 | 贡献 | 在 UniAD 里的角色 |
|---|---|---|
| Transformer | Q/K/V 查询-匹配-聚合范式 | 所有模块的底层机制 |
| ViT | 图像可以变成 token 序列 | 视觉侧 token 化的理论基础 |
| LSS | BEV 表示的价值 + 几何路线 | 确立了 BEV 这个中间表示 |
| BEVFormer | 用注意力做 BEV，含时序 | 直接作为 UniAD 的 BEV 编码器 |
| UniAD | 用 query 串联全栈，为规划服务 | 把以上全部整合成完整系统 |
一句话总结这条演进：Transformer 给了工具，ViT 打通了视觉，LSS 确立了 BEV，BEVFormer 用新工具重做 BEV，UniAD 把 BEV 之上的整个驾驶栈串成一体。
UniAD 是里程碑，但不是终点。读完要能说出它的问题在哪：
"UniAD 的核心贡献是planning-oriented 的架构哲学——用可导的 query 接口把全栈串起来，让规划的梯度能回传到感知。它证明了层级递进优于并行多任务。但它的模块划分仍是人为设计的，计算也偏重；后续 VAD 解决了效率问题，而 FSD v14、小鹏 VLA 这类一段式端到端则把中间模块彻底隐式化。这三代的演进主线，是"人工设计的结构"不断让位于"数据学出来的结构"——这和 ViT 里 CNN 归纳偏置被数据规模取代，是同一个故事。"
不是"多加了规划模块"，而是所有模块为规划服务、规划梯度能反哺感知。要能说出它反对的是什么（传结果的流水线、平行的多任务）。
轨迹预测只覆盖已跟踪的已知类别，占据预测兜住异形/未知障碍物。这题也是理解 Tesla 占据网络的入口。
不看资料能画出来，说明架构真的通了。
这是复现时的实操关键，也是面试问"你实际跑过吗"时的验证点。
按论文清单，下一篇建议 VAD——它是 UniAD 的"量产化版本"，把栅格换成矢量、速度提升约 10 倍，也是理解小鹏/理想量产方案的最佳学术参照。你之前问过的"导航指令 one-hot 输入"就出自 VAD。