VLA 语义下的导航信息注入：从 Prompt 到 Diffusion Condition

在自动驾驶轨迹规划中，导航信息回答了一个根本问题：车应该往哪走？ 没有它，模型只能对所有合理选项均匀采样——左转、直行、右转都可能出现。但这个问题的有趣之处在于导航信息是以什么形式、在模型的什么位置被注入和消费的。

当我们审视 2024-2026 年最新的端到端驾驶方法——尤其是基于 VLA（Vision-Language-Action）架构的系统——会发现一个清晰的层次结构：导航信号从一条文本指令出发，经过 prompt 编码、adapter 对齐、生成式条件注入，最终可能融入统一的空间 token 表征，甚至演变为视觉-语言导航（VLN）式的持续交互。每一层都对应不同的信息粒度和注入机制，也决定了导航能发挥多大的作用。

本文以 “导航信息的注入深度” 为组织线索，逐层剖析从 Prompt 到 Diffusion Condition 再到 Unified Token 的四层体系，并讨论 VLN 范式如何将导航从"条件信号"提升为"agent 与环境之间的对话"。

在自动驾驶轨迹规划中，导航信息回答了一个根本问题：车应该往哪走？ 没有它，模型只能对所有合理选项均匀采样——左转、直行、右转都可能出现。

业界商用导航 SDK（高德、腾讯地图、Google Routes、Mapbox、Apple Maps）输出的导航信息远比"左转/直行/右转"丰富，结构上也已经相当成熟：当前与前瞻 maneuver、辅助动作语义、车道级引导、路径航点。问题不在"导航信息从哪来"，而在 VLA 时代怎么把这些信号真正用起来——以什么形式、注入到模型的哪个位置、被哪一层消费。

当我们审视 2024-2026 年最新的端到端驾驶方法——尤其是基于 VLA（Vision-Language-Action）架构的系统——会发现一个清晰的层次结构：导航信号从一条文本指令出发，经过 prompt 编码、adapter 对齐、生成式条件注入，最终可能融入统一的空间 token 表征，甚至演变为视觉-语言导航（VLN）式的持续交互。每一层都对应不同的信息粒度和注入机制，也决定了导航能发挥多大的作用。

本文以 “导航信息的注入深度” 为组织线索，逐层剖析从 Prompt 到 Diffusion Condition 再到 Unified Token 的四层体系，并讨论 VLN 范式如何将导航从"条件信号"提升为"agent 与环境之间的对话"。

一、导航信息：业界 SDK 普遍提供 vs 学术公开集缺失

1.1 业界主流 SDK 普遍提供的五类信息

无论是高德、腾讯地图，还是 Google Routes、Mapbox、Apple Maps，商用导航 SDK 在车机端输出的导航帧远不止 {L, S, R} 那么粗糙。各家命名细节虽不同，但信息门类高度一致，可归为五类。

① 当前与前瞻 maneuver

当前路口的转向类型 + 距离前方路口的距离，再加上下两个路口的转向类型 + 距离。基本 maneuver 通常是十余类枚举：左转 / 右转 / 左转调头 / 直行 / 靠左 / 靠右 / 进环岛 / 离环岛 / 减速行驶 等。

这构成一条短时域前瞻链：模型不仅知道"当前要左转"，还知道"下一个路口直行 250m 后右转"。前瞻信号在 nuPlan / nuScenes / NAVSIM 的 {L, S, R} 标注里完全没有。

② 辅助动作语义

主 maneuver 没有承担的细分场景动作，独立的辅助枚举字段，覆盖 50+ 种：进入主路 / 辅路 / 高速 / 匝道 / 隧道、进入左/右转专用道、到达航道 / 收费站 / 服务区 / 充电站 / 目的地、绕环岛左转/右转/直行、到达复杂路口走第 N 出口 等。

这一层是工业导航长期积累的、针对真实路况的高层决策语义——“到达复杂路口走右边第三出口"这种描述，是 mainAction 表达不出的。

③ 车道级引导

前方路口最多 16 条车道，每条车道带有三组并列字段：

• 物理类型：直行 / 左转 / 直行+左转 / 右转 / 左掉头 / 公交车道 / 可变车道 / 潮汐车道 等 26 类枚举
• 导航许可：1 = 可走，0 = 不可走，特定值（如 255）= 导航不让走
• 推荐车道：综合时长 / 距离 / 复杂度后推荐的最佳车道

三个字段的组合回答了一个比 maneuver 更细的问题：前方路口，应该走哪条车道？ 这把决策空间从"所有可能的轨迹"压窄到"特定车道内的轨迹子空间”，是密度最高的导航信号。

④ 路径航点 Waypoints

车体坐标系下导航引擎已经规划好的路径稀疏采样，每点为 $(x, y, \text{heading})$，$N$ 为自车前向采样数。粒度上恰好介于 GoalFlow 的目标点 $(x_g, y_g)$（过粗，无形状）和 DiffusionPlanner 的 2000D 高维 route lanes（过冗余）之间。

⑤ 全局信息

距目的地距离、当前 action 所在 link id 等——通常用于条件门控（是否接近终点、是否切换路段）。

1.2 学术公开数据集只暴露这五类的极简子集

主流公开 benchmark 在数据采集环节就没有接入实时导航 SDK，nuPlan / nuScenes / NAVSIM 的 navigation label 在生产 pipeline 里只产出简化命令或几何路线，完整 navi 信息从源头缺失。这不是后期评测裁剪，而是数据集本身没有这些字段。

这意味着：真正消费完整 navi（车道引导、辅助动作语义、多步前瞻）的 VLA 研究当前只能在私有数据集上做——量产车端的数据采集 pipeline 是少数能同时拿到完整 SDK 输入与同步感知/规划信号的来源。

1.3 这种落差为什么存在

这一缺失由四个系统性原因共同决定：

数据采集层面的根因。 公开数据集 nuPlan / nuScenes / NAVSIM 在标注时没有接入在线导航 SDK 的实时输出——这需要 API key、时间戳对齐、WGS84↔车体坐标转换、与感知/规划的同步采集等一整套工程基础设施。开源 benchmark 没有这套设施，学术研究只能用 benchmark 给的字段。

技术路径依赖。 UniAD 2023 年定义了 {L, S, R} 接口后，大量后续工作在此接口上刷 SOTA。引入更丰富的 navi schema 需要重做数据 pipeline，破坏与已有方法的可比性——社区陷入局部最优。

评估指标的盲区。 PDMS、L2、Collision Rate 等主流指标无法区分"用 cmd 三分类"和"用 lane guidance"的决策质量差异——两种输入下指标可以相同，但下游模型在真实路口的行为质量可能差很多，评估体系看不到。

端到端意识形态的自我约束。 引入结构化枚举看起来像"手工特征工程的退步"。但条件变量的表达能力直接决定条件分布的学习难度。把领域知识以结构化形式注入条件空间，本质上是在降低学习难度、提升样本效率，而非削弱端到端属性。

1.4 学术界正在尝试的绕过路线

学术界要追赶完整 navi 的消费，目前能看到三条路径：

反向重建车道引导。 ONR / OMA-MAT (ICLR 2026) [14] 从 SD 地图（道路级）+ 在线感知地图精炼出车道向量作为导航原语，构建了 30K 场景 260 万条标注的数据集，推理延迟 34ms。它没有依赖在线 SDK，而是从感知端"反向重建"车道级引导——绕开"公开集没采集"的限制。

工业论文中的间接使用。 SGDrive (CVPR 2026) [15] 的 Scene-Agent-Goal 层次化框架显式区分 Goal Primitives（对应 maneuver / 前瞻）和 Scene Primitives（对应车道引导）；带工业背景的 ReflectDrive、DiffusionPlanner 等也能在私有集上消费完整 navi——但通常不公开 schema 细节。

地图语义枚举的编码方案。 SDTagNet (NeurIPS 2025) [16] 用 BERT 编码 OpenStreetMap 的文本标签（highway type、lanes count、oneway、maxspeed 等），证明地图语义枚举可以被神经表示有效捕获——为业界 SDK 输出的各类 maneuver / lane 枚举提供了直接的编码方案参考。

公开 benchmark 追加 navi 标注的工作目前尚未见到主流推进。

1.5 一个相邻方向：让空间信息成为一等公民

2026 年 SpaceDrive（CVPR 2026, Mercedes-Benz & Tübingen）[6] 提出了一个颠覆性思路：让所有空间坐标共享同一个位置编码器，不再区分"导航信息"和"其他空间信息"。

SpaceDrive 设计了统一的 3D Sine-Cosine PE 接口，同时服务于三个模态：

• 视觉侧：图像 patch 经冻结单目深度估计器做 3D 投影后，由同一 3D Sin-Cos PE 编码，注入视觉特征（可学习系数 $\alpha$ 归一化）
• 文本侧：扫描 prompt 中的数字表达式，抽取坐标数值，由同一 PE 编码器转换，替换原文本数字 token，插入特殊标记 ⟨IND⟩
• 输出侧：解码时遇到 ⟨IND⟩ 标记，将该位置 hidden state 送入 PE decoder，用 Huber loss 回归连续坐标

1
2
3
4
5

# SpaceDrive 文本侧的坐标感知示例
text = "The ego vehicle is at (30.5, -12.3). Turn towards (35.0, -10.0)."
# → tokenizer 后扫描数字 → 提取 (30.5, -12.3), (35.0, -10.0)
# → 用 3D Sin-Cos PE 编码替换原数字 token → 标记 ⟨IND⟩
# → 模型学习在统一的坐标系中推理

消融实验表明 3D Sin-Cos PE 在 AD 任务上显著优于 MLP PE 和 RoPE。闭环评测：Driving Score 78.02, Success Rate 55.11%（对比 base model 纯文本生成的成功率 <10%）。

SpaceDrive 的核心论断值得引用原文：“Spatial information is not a secondary description of semantics — it is a first-class citizen in autonomous driving.” 这条路线对 §五（导航 Token 化）有直接启发：在 VLA 时代，导航信息不应该是一种"特殊处理的条件信号"，而应该是所有空间模态共享的基础设施。

二、第一层注入：Prompt 级别的意图编码

在 VLA 体系中，导航首先是一条文本指令。它进入模型的第一个接口是 System Prompt —— 这是整个注入链中最浅、最直接、也是信息损失最大的一层。

2.1 VLA Prompt 中的导航模板

典型的 VLA driving agent 将导航指令嵌入一个多段式 prompt 结构中：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

[SYSTEM] You are an autonomous driving agent operating in urban environment.
        Your task is to generate safe and efficient driving actions.
        You must follow traffic rules and prioritize passenger safety.

[SCENE]
<image_tokens_from_front_camera>
<image_tokens_from_left_camera>

[VEHICLE_STATE]
Speed: 12.3 m/s | Heading: NE (45°) | Position: (30.5, -12.3)
Steering angle: 2.1° | Throttle: 0.35

[NAVIGATION_COMMAND]
Turn left at the upcoming intersection.

[ACTION_HISTORY]
t-3: accelerate(0.32) + steer_left(1.8°)
t-2: accelerate(0.28) + steer_left(1.2°)
t-1: maintain_speed(0.05) + steer_left(0.6°)

[NEXT_ACTION]
___

在这个模板中，导航指令 [NAVIGATION_COMMAND] 只是多个输入段之一。它与场景图像、车辆状态、历史动作共同构成完整的 context window。模型需要从这个上下文中自行提取导航意图并据此生成下一步动作。

2.2 从文本到隐空间的第一次转换

当这段 prompt 进入 VLM 时，导航文本经历以下变换：

此时导航信息变成了一个 token embedding 序列。它在完整输入序列中的相对位置会显著影响模型对它的关注程度：

OpenDriveVLA [3] 采用了一种更精细的策略：分层视觉-语言对齐（Hierarchical Vision-Language Alignment）——先将视觉表示和导航 embedding 分别投影到一个统一的语义空间中，再送入自回归解码器。这相当于在标准 text encoder 之后增加了一层专门的跨模态适配。

2.3 这一层的边界

Prompt 层注入的能力边界非常清晰：

它能做的：传达高层意图（“左转”、“去商场”、“靠边停车”）。对于人类驾驶员来说，这就够了——一句口头指令足以完成大部分日常导航。

它不能做的：精确的空间约束。Prompt 无法有效传达"保持距路边 0.5m"这类厘米级需求，也无法让模型理解"这条路的曲率半径导致需要提前 2 秒减速"这类动力学约束。原因很简单——纯文本的信息密度太低，且 VLM 的 text encoder 本身不是为空间推理设计的。

这就是为什么我们需要更深层的注入机制：当 Prompt 的信息密度不够时，Adapter 层提供跨模态对齐；当 Adapter 的粒度不够时，Diffusion Condition 提供分布级的控制。

三、第二层注入：Adapter 与跨模态对齐

当纯文本 prompt 无法承载足够的导航精度时，Adapter 层成为桥梁——它连接导航信号与模型的内部表征空间，实现细粒度的跨模态对齐。

3.1 为什么需要 Adapter？

两个基本的 gap 驱动了对 adapter 层的需求：

Domain Gap。 主流 VLM（Qwen-VL、LLaVA 等）在通用图文数据上预训练，几乎没见过驾驶场景。直接将驾驶相关的导航信号喂给预训练 VLM，相当于让一个只读过百科全书的人去开车——知识结构不匹配。

Modality Gap。 导航信号（无论是离散命令、坐标还是自然语言）和视觉特征（来自 camera image 的 patch embeddings）来自完全不同的模态。它们在预训练的 embedding space 中可能是正交甚至冲突的——“左转"这个词 embedding 的方向，和"左侧车道线"这个视觉特征的方向，未必有任何内在关联。

Adapter（特别是 LoRA）以极低的参数成本解决这两个问题。SpaceDrive [6] 在 Qwen2.5-VL-7B 上仅用了 Rank-16 LoRA（约 10.09M 可学习参数） 就实现了有效的驾驶适配——这不到 base model 参数量的 0.15%。

3.2 LoRA 导航注入的具体模式

LoRA 注入导航的核心思想是：在不修改预训练权重的前提下，为导航信号开辟专属的信息通路。

最常见的注入位置是 Transformer Attention 层的 QKV 投影矩阵：

其中 $\Delta W_q = B_A B_B$ 是 LoRA 的低秩分解（$B_A \in \mathbb{R}^{d \times r}, B_B \in \mathbb{R}^{r \times d}, r \ll d$）。导航信息通过以下方式参与调制：

1
2
3
4
5
6

class NaviAwareLoRALayer:
    def forward(self, x, navi_emb):
        q_base = self.q_proj(x)                    # 原始查询
        q_lora = self.lora_a(navi_emb) @ self.lora_b # 导航调制的增量
        q = q_base + q_lora                         # 导航偏置注意力方向
        return attention(q, k, v)

SpaceDrive 的做法更具结构性：它的 LoRA 注入到 3D PE 编码器中而非直接调制 attention——使预训练 VLM 学会将数值坐标正确地映射到内部的空间表征空间。这意味着导航坐标真正被模型理解为空间位置的信号，而非"被读进去的文字”。

3.3 Cross-Attention 融合：SSR 的 SE 层深度解析

如果说 LoRA 是"轻量级手术刀"，Cross-Attention 就是"重型推土机"——它能将导航信息以最高的保真度融合进场景表征中。

SSR（Navigation-Guided Sparse Scene Representation, ICLR 2025）[7] 提供了目前最清晰的分析案例。它的核心创新是将导航信息通过 SE（Squeeze-and-Excitation）层注入密集 BEV 特征，再用 TokenLearner 在导航引导下做稀疏采样。

第一步：SE 层将导航注入 BEV

其中 $\mathbf{B}_t$ 是 $100 \times 100$ 的密集 BEV 特征图（10,000 个空间位置 × $C$ 个通道），$\text{cmd} \in \{\text{left}, \text{right}, \text{straight}\}$ 是高层导航命令。

SE 操作的实质是根据导航命令产生一组通道权重 $\mathbf{w} \in \mathbb{R}^C$，然后逐通道加权 BEV 特征：

直觉上：当 cmd = “turn left” 时，描述"左侧区域"的特征通道获得更高权重；当 cmd = “straight” 时，前方通道被放大。导航在这里扮演的是聚光灯而非方向盘的角色——它告诉模型"你应该看哪里"。

第二步：TokenLearner 从 10K 格子中选出 16 个 Token

16 个可学习的 scene query $\{q_i\}_{i=1}^{16}$ 通过空间注意力从导航过滤后的 BEV 中聚合信息：

其中 $\varpi_i$ 是第 $i$ 个 query 生成的空间注意力图，$\rho$ 是池化操作。由于输入 BEV 已经是导航感知的，不同 cmd 下同一个 query 关注的区域会自动偏移。

最终结果：10,000 个 BEV 格子被压缩为 16 个稀疏 scene token（256D each），压缩率 625×，且 ST L（Scene Token Learner）模块仅占总推理时间的 7.8%。

SSR 的导航过滤流水线：

flowchart LR
    subgraph Input ["输入层"]
        BEV["Dense BEV
100×100 = 10,000 grids"]
        CMD["cmd ∈ {L,S,R}"]
    end
    subgraph Filter ["导航过滤"]
        SE["SE Layer
B_t → B_t^{navi}
channel-wise modulation"]
    end
    subgraph Compress ["压缩"]
        ST["Scene TokenLearner
Navi-guided selection
16 sparse tokens"]
    end
    subgraph Output ["规划"]
        WP["Waypoint Decoder
Cross-Attn(W, S_t, S_t)"]
    end
    CMD --> SE
    BEV --> SE --> ST --> WP
    style Input fill:#f8f9fa,stroke:#999,color:#555
    style Filter fill:#fef5e7,stroke:#e67e22,color:#d35400
    style Compress fill:#e8f6ef,stroke:#27ae60,color:#1e8449
    style Output fill:#ebf5fb,stroke:#3498db,color:#2980b9

消融实验：导航到底贡献了什么？

SSR 的消融实验给出了一个反直觉却极具说服力的答案：

移除导航后直行碰撞率翻了近三倍。 这个数字揭示了一个深层洞察：导航的主要价值在于帮助模型忽略不相关的信息。 直行时不需要考虑左右转弯的可能性，导航信号通过 SE 层抑制了这些无关特征的响应，使得模型能将全部注意力集中在正确的驾驶模式上。

更有趣的是，SSR 发现 64 个 scene token 反而比 16 个表现更差（碰撞率从 0.15% 升至 0.41%）——证明在导航引导下，密集不代表更好，噪声 token 会伤害决策质量。

从三分类到车道级：SE 层的增强方向

SSR 的原始设计使用 cmd ∈ {left, right, straight} 作为 SE 层的输入。但结合§1.5讨论的工业级导航帧，一个自然的问题是：如果将 SE 层的三分类输入替换为完整的车道级导航信号，滤波效果能提升多少？

考虑以下**多头增强SE层（Multi-Head Enhanced SE）**的设计：

与原始单头SE的本质区别在于信息粒度的分化：

其中 Head-LaneMask 是最关键的增量：它回答的是BEV空间中哪些位置是合法驾驶区域，而非"哪些特征通道更重要"。当 lane_navi = [0, 1, 1, 0] 时，第1条和第4条车道对应的BEV区域被直接gating掉——模型在这些区域上的特征响应被置零或大幅衰减。

这种设计与ONR/MAT [14] 形成互补：

• ONR/MAT：从SD地图+在线感知推断出车道向量（自下而上）
• 增强SE层：从导航引擎直接获取车道级字段并注入BEV（自上而下）
• 两者可以串联使用：ONR提供无HD Map区域的车道推断，SE层消费车道信息做空间约束

核心洞察： SSR证明导航的价值主要在于信息过滤而非方向指引。车道级导航将这个过滤从粗糙的"左/右/直"三档，精细化到"前方4条车道中只有中间2条可走"的空间级约束——这不仅是量的增加，更是质的跃迁：从语义调制到几何裁剪。

3.4 导航引导的场景压缩作为通用模式

SSR 的 SE + TokenLearner 不应被视为特例。它代表了一种通用的设计模式：

任何拥有密集场景表征（BEV features / VLM visual tokens / KV Cache）且有导航信号的系统，都可以借鉴这一模式。关键要素只有两个：

1. 一个导航感知的滤波操作（SE 层只是其中一种实现，attention bias、FiLM、gating 都可以）
2. 一个稀疏化机制（TokenLearner / Top-K selection / learned clustering）

四、第三层注入：Diffusion / Flow Matching 条件下的导航消费

在生成式规划器中，导航不再是辅助信息——它是控制轨迹概率分布形状的核心旋钮。这一层的注入深度远超 Prompt 或 Adapter：导航直接参与每一个去噪步骤的条件化过程。

关于扩散时间步 τ 的详细机制（τ 如何编码、如何通过 AdaLN/Concat/FinalLayer 消费），参见前文第三节「τ：扩散与流匹配的时间条件」。本节聚焦于 τ 之上的导航条件——即导航如何回答"往哪走"的问题，而 τ 回答的是"做多强"的问题。

4.1 方向调制型：DiffusionPlanner 的加法融合

DiffusionPlanner（ICLR 2025 Oral）[5] 提供了最清晰的导航-扩散条件融合范例。其核心设计是将导航编码与时间步嵌入在同一个向量空间中相加：

这个联合条件向量 $y$ 统一送入 AdaLN 调制通道，渗透每一个 DiT Block。

RouteEncoder 的实现细节值得展开——它是如何把 2000 维的路线数据压缩到 192 维的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

class RouteEncoder:
    """25 routes × 20 pts × 4 dim(x,y,cosθ,sinθ) → 192D vector"""

    def forward(self, route_lanes):          # [B, 25, 20, 12]
        x = route_lanes[..., :4]             # 只取几何坐标: [B, 25, 20, 4]
        x = self.channel_mlp(x)              # 4D → 64D: [B, 25, 20, 64]
        x = x.transpose(1, 2)                # 重排: [B, 20, 25, 64]
        x = self.token_mlp(x)                # 500 tokens → 32: [B, 20, 32, 64]
        x = self.mixer(x)                    # MixerBlock: 交叉混合
        x = x.mean(dim=[1, 2])               # Mean Pooling: [B, 64]
        x = self.project(x)                  # 64D → 192D: [B, 192]
        return x                              # Navigation embedding

注意几个精妙的设计选择：

• 用 $(\cos\theta, \sin\theta)$ 表示航向角而非单一 $\theta$，避免 ±π 的不连续性（与扩散过程的平滑性兼容）
• 先做 channel 方向的 MLP（4→64），再做 token 方向的降采样（500→32），而非反之——因为相邻点的坐标变化比同一点的多属性变化更平缓，token 降采样引入的信息损失更小
• 最终 Mean Pooling 而非 CLS token —— 路线的每一段都可能包含关键的转向信息，均值比单点更能保留全局拓扑

为什么是加法？ 这源于 τ 和导航的语义互补性：

加法意味着两者在同一向量空间线性叠加，再通过后续的非线性 MLP（SiLU 后接 Linear）产生隐式交互项。直觉就是："在当前噪声水平下，沿导航方向做相应强度的修正"。而这个设计的工程美感在于：adaLN_modulation 的输入输出维度不变，导航信息零额外参数地搭上了 τ 的便车。

4.2 锚点引导型：DiffusionDrive 的隐式导航

DiffusionDrive（CVPR 2025）[8] 走了一条完全不同的路——它从不显式接收导航输入。导航信息被隐式编码在锚点轨迹（anchor trajectories）的分布中。

具体流程：

1. 用 K-Means 在训练集专家轨迹上聚类得到 20 个锚点轨迹
2. 每个锚点天然代表一种典型驾驶意图（左转簇、直行簇、右转簇、变道簇等）
3. 推理时，根据当前导航命令选择对应的锚点子集
4. 截断扩散（Truncated Diffusion）：前向过程的起点从纯噪声改为锚点附近的加噪版本
5. 搜索空间从"所有可能的轨迹"急剧缩减为"锚点附近的变体"

其中 $a_T < 1$ 是截断系数。当 $a_T$ 接近 1 时，起点接近锚点本身，只需 2 步去噪即可获得高质量轨迹，推理速度达到 45 FPS（9× 快于标准扩散的 ~5 FPS）。

这是隐式导航的典范——锚点本身就是由训练数据中的导航标签（每条轨迹对应的高层命令）驱动聚类形成的。模型不需要在运行时"理解"导航指令，只需要"选择正确的模式"。NAVSIM v1 上 DiffusionDrive 取得 88.1 PDMS，后续 DiffusionDriveV2（2025.12）加入 RL 约束（GRPO + 乘性噪声）进一步提升至 91.2 PDMS [9]。

4.3 目标驱动型：GoalFlow 的解耦设计

如果将导航信息压缩到物理极限，一个二维坐标就够了。GoalFlow（CVPR 2025）[4] 将导航简化为目标点 $(x_g, y_g)$，然后通过两阶段解耦设计分别处理"去哪"和"怎么去"：

• GoalConstructor：根据当前场景和任务类型确定目标点。这是一个相对简单的模块，可以用规则或轻量网络实现。
• Flow Matching Generator：给定目标点条件，用单步 Flow Matching 生成轨迹。

仅需 1 步 ODE 积分即可完成生成，NAVSIM v1 上达到 90.3 PDMS。GoalFlow 的优雅之处在于它证明了：如果解耦得当，导航条件可以极度简洁而不损失性能。

4.4 Classifier-Free Guidance 中的导航调节

无论哪种条件注入方式，Classifier-Free Guidance (CFG) 都提供了一个运行时的"导航强度旋钮"：

其中 $c$ 包含导航条件。引导强度 $w$ 的调节效果：

CFG 是扩散规划器独有的运行时可控性优势——传统回归方法一旦训练完成，行为就固定了；而扩散方法可以在部署时动态调整导航服从度。

4.5 四种 Diffusion 条件注入范式对比

四种范式代表了导航信息进入扩散过程的不同"入口位置"，从最浅层的输出偏移到最深层的噪声调制：

注入越深（靠近噪声），导航对生成过程的控制力越强，但可解释性和调试难度也越高。 DiP 的 AdaLN 方案在四个方法中渗透最深（每一个 Transformer block 都受导航影响），而 DD/GF 的锚点和目标点方案更接近"软条件"——引导方向但不强制。SSR 则走了一条不同的路：不过问扩散过程本身，而是在场景表征阶段就完成导航过滤。

flowchart LR
    subgraph Shallow ["浅层注入 · 低延迟"]
        GF["③ Goal
1-Step FM"]
        DD["② Anchor
2-Step"]
    end
    subgraph Deep ["深层注入 · 强控制"]
        SSR["④ Attn Filter
Sparse Tokens"]
        DP["① Direction
AdaLN every block"]
    end
    GF -.->|"解耦"| Deep
    DD -.->|"速度"| Deep
    style Shallow fill:#e8f6ef,stroke:#27ae60,color:#1e8449
    style Deep fill:#fdf2f2,stroke:#e74c3c,color:#c0392b

五、第四层注入：导航 Token 化与统一空间表征

前面三层（Prompt → Adapter → Diffusion Condition）各自解决了不同粒度的导航注入问题。但 2025-2026 年的前沿趋势显示，一个更深层的转变正在发生：导航被压缩为紧凑 token 后，成为 VLM 序列的一等公民，不再是被"注入"的外部信号——甚至在最新的范式中，连"导航"这个概念本身都在消融。

5.1 动机：为什么需要 Token 化？

三个现实约束驱动了导航 token 化的需求：

1. Context Window 有限。VLM 的有效上下文通常在 4K–32K tokens 之间。一张高清图像就可能消耗数千个 visual tokens，留给导航的空间极其有限。
2. 冗余度极高。HD Map 的一条直线段可能有几十个采样点，但它们编码的信息只有一个——“向前延伸 X 米”。
3. 延迟预算紧张。每多一个 token 就多一次 attention 计算。在 <100ms 的规划周期内，每个 token 都很昂贵。

5.2 连续压缩：MLP-Mixer 式路线编码

目前实际存在的路线压缩方法中，DiffusionPlanner 的 RouteEncoder（已在第四章详述）是最具代表性的连续压缩方案：

业界没有采用 VAE（变分自编码器）来压缩路线，原因有几方面：

1. 路线数据的本质很简单——几百个 $(x,y,\theta)$ 坐标点，不需要像图像那样复杂的 latent space 来建模
2. 规划任务只需要编码后的向量做条件化输入，不需要解码还原原始路线（没有重建需求）
3. MLP-Mixer 已经足够高效、可微分、端到端可训练

5.3 离散 Token 化：面向 LLM 架构的路线

当底层架构从 DiT 转向类 LLM 的 Decoder-only Transformer 时，离散 token 化成为更自然的选择——因为它天然兼容 autoregressive 生成范式。

MotionLM（ICCV 2023）[[10]](#ref10） 开创性地将连续轨迹空间离散化为有限词汇表：

• X/Y 方向位移各划分为 128 个区间
• Verlet-wrapped 增量（利用运动学约束减少 vocab size）各 13 个可能值
• 动作空间：13 × 13 = 169 个离散动作类别
• Teacher-Force 训练 + Cross-Entropy 分类 + KMeans 聚类输出 6 条候选轨迹

DriveGPT（ICML 2025）[[11]](#ref11） 继承了 MotionLM 的离散动作空间并将其扩展到 1.4B 参数规模——证明离散 token 化方案可以随模型规模线性扩展。

ReflectDrive-2（Li Auto, 2026）[[12]](#ref12） 则将离散化推向新高度：轨迹被 token 化为码本索引序列（8 waypoints × 2 tokens/waypoint = 16 tokens），配合 RL fine-tuning 和 AutoEdit 自修正机制，best-of-6 采样达到 94.8 PDMS——与人类参考水平持平。

三种离散化方案的共同趋势：轨迹空间被量化为有限码本后，分布建模从连续密度估计变为分类问题——这使得 DPO、RLHF 等 LLM 训练技术可以直接迁移到驾驶规划中。

5.4 SpaceDrive 的统一 3D PE：打破模态边界

第五章开头提到的 SpaceDrive（CVPR 2026）[6] 代表了导航 token 化的终极形态：不再有独立的"导航编码器"——所有空间信息（包括导航坐标）共享同一个 3D Positional Encoder。

其架构的三路统一设计：

SpaceDrive: 统一 3D PE 架构

flowchart TD
    L4["Layer 4: VLN Interaction
持续对话与协商"] -->|"最深·最灵活"| L3["Layer 3: Unified Space Token
紧凑 token → 一等公民"]
    L3 -->|"高效·模态统一"| L2["Layer 2: Adapter Alignment
跨模态特征对齐"]
    L2 -->|"精准·已成熟"| L1["Layer 1: Prompt / Text
VLA 入口 · 最低延迟"]
    style L4 fill:#f5eef8,stroke:#9b59b6,color:#8e44ad
    style L3 fill:#ebf5fb,stroke:#3498db,color:#2980b9
    style L2 fill:#fef5e7,stroke:#e67e22,color:#d35400
    style L1 fill:#e8f6ef,stroke:#27ae60,color:#1e8449

flowchart TD
    A["导航信息来源是什么？"] --> B["离散命令
L/S/R"]
    A --> C["自然语言指令"]
    A --> D["目标点或坐标"]
    A --> E["高精地图路线"]

    B --> B1["方案: 直接拼接 + One-Hot
OK VAD/UniAD 已验证
NG 仅适用简单场景"]

    C --> C1["方案: VLA Prompt
OK 开放域兼容
NG 需 VLM 语义理解
→ 如需精确空间约束，叠加 Layer 2"]

    D --> D1["方案: GoalCondition
OK GoalFlow: 90.3 PDMS
OK 最简条件
NG 缺少路径约束"]

    E --> E1{"底层架构是什么？"}
    E1 --> F["DiT / UNet"]
    E1 --> G["VLM / LLM-based"]
    E1 --> H["BEV + Decoder"]

    F --> F1["方案: RouteEncoder + AdaLN
OK DiP: 零额外参数
OK 全局渗透最深
→ ICLR'25 Oral 方法"]

    G --> G1["方案: LoRA / 统一 PE
OK SpaceDrive: DS 78.02
OK 打破模态边界
→ CVPR'26 最新范式"]

    H --> H1["方案: SE + TokenLearner
OK SSR: 碰撞率 ↓66%
OK 625× 场景压缩
→ ICLR'25 方法"]

    B1 & C1 & D1 & F1 & G1 & H1 --> Z["最终建议:
简单场景 → Layer 1+GoalPoint
复杂城市 → Layer 2+③⑤结构化原语(增强SE)
端到端 VLA → Layer 1+⑥(统一PE)
生成式规划 → Layer 3(Diffusion Cond)
量产部署 → Layer 2 + ⑤在线导航API帧
具身智能/机器人 → Layer 4 (VLN)"]