The Constant Eye：DINOv3 冻结编码器如何解决端到端规划的视觉域偏移

端到端自动驾驶有一个不常被正面讨论的软肋：模型对视觉风格的脆弱性。一个在加州阳光下训好的模型，到了东北的雪天直接不会开——不是感知模块检测不到东西，而是整条链路的规划决策都在视觉偏移面前失效。这篇要写的论文叫 The Constant Eye（arXiv:2602.12563），它提出了一个看起来有点反直觉的答案：把视觉编码器冻住，让它不参与下游训练。

---

问题：视觉域偏移在端到端方案里是怎么发生的

传统模块化方案的感知层是独立训练的，检测模型训在 ImageNet/COCO 上，规划模块训在驾驶数据上，两个模块的梯度互不干扰。端到端之后，感知和规划一起训，梯度回传会穿过整个网络——这本来是好事，但副作用是：规划模块会学会利用感知层里残留的视觉风格信息作为「快捷方式」。

比如训练集里大多数道路都是正常的晴天画面，路面的阴影、颜色、纹理都有特定规律。规划模块学到的是「这个纹理pattern → 应该加速」，而不是「前方空旷 → 应该加速」。一旦输入风格变了（雪天路面反光、黄昏色温偏暖），纹理pattern 不匹配，规划就直接崩掉——即使感知层客观上已经把障碍物检测对了。

这个现象有个更学术的名字叫 visual shortcuts。核心问题是：规划头从感知特征里学到了不该学的东西，而这些东西在 OOD 场景里不存在。

核心解法：冻结 backbone 作为域不变接口

The Constant Eye 的思路很简单：既然规划头会利用感知层里的视觉捷径，那就把感知层的权重锁死，让梯度根本穿不过去。

具体做法：用 DINOv3 作为冻结的视觉编码器 $\Phi$，输入原始多视角相机图像，输出密集特征图 $\mathcal{F}_{DINO} \in \mathbb{R}^{H' \times W' \times C}$。之后接一个轻量适配器 $\mathcal{A}$ 做维度压缩和空间聚合：

$\mathcal{F}_{MLP} = MLP(\mathcal{F}_{DINO}) \in \mathbb{R}^{H' \times W' \times d}, \quad d < C$

适配器包含两层：第一层 MLP 把特征维度从 $C$（DINOv3 是 1024 或更高）压到 $d$；第二层是 CNN-based 的空间聚合器，先上采样到更高分辨率（方便做 BEV 语义分割等辅助感知任务），再下采样回原尺寸，得到 $\mathcal{F}_{ada}$。最后 flatten 成 token 序列，送进 Transformer 规划解码器。

关键点：整个训练过程中 $\Phi$ 完全冻结，只有适配器和规划头在更新。 冻结策略强制规划头从 $\mathcal{F}_{DINO}$ 里提取纯粹的「结构信息」——物体之间的空间关系、场景布局、相对运动——而不是纹理、颜色、风格这些跟驾驶决策无关的视觉线索。

为什么 DINOv3 是正确的选择

不是随便一个预训练视觉 backbone 都能当这个「域不变接口」。DINOv3 的三个特性恰好对应这个问题：

Gram Anchoring 保住密集特征。 DINOv2 在大规模训练后会出现 patch 特征退化（训练时间长了，细粒度细节反而丢失），Gram Anchoring 在整个训练过程中维持 patch 之间的结构一致性，保证特征图里既包含语义信息（这是什么物体）也包含几何信息（它在哪里、边缘在哪）。

RoPE 抗分辨率偏移。 自动驾驶相机输入的分辨率每天在变、车载相机的视角和遮挡情况也各不相同。DINOv3 用旋转位置编码（RoPE-box jittering），在高分辨率裁剪上做适应性训练，输入分辨率偏离预训练设置时特征质量不会崩。

自监督覆盖长尾。 DINOv3 没有用 ImageNet 标注训练，它从 17 亿张无标注图像里学到了丰富的视觉结构。这种分布天然比人工标注的数据更多样、更覆盖边缘场景——雪天、暴雨、夜晚、路面施工，这些在人工标注数据里稀有的样本，在原始图像数据里大量存在。

三种规划范式的热插拔

这个框架最优雅的地方是：适配器是通用的，规划头是可插拔的。 论文把 DINOv3 冻结编码器接进了三种主流规划范式，分别验证：

LTF-DINO（回归范式） —— LTF 原版是 DETR-style Transformer 解码器，用可学习 query token 与场景特征做交叉注意力，直接回归未来轨迹。LTF-DINO 把 DINOv3 特征作为场景上下文接进去，ego-query 聚合特征后过 MLP 预测轨迹点。效果：原版 LTF 在 Heavy Snow、Dusk Sunset 等 OOD 场景里轨迹直接飘出车道；LTF-DINO 保持平滑且贴合车道线。

DiffusionDrive-DINO（扩散范式） —— DiffusionDrive 用扩散模型生成多条候选轨迹，然后用 scoring 机制选最优。DINOv3 特征替换掉原来 task-specific 的视觉 backbone 后，扩散的条件输入变成了域不变的结构特征，生成质量的跨风格一致性大幅提升。

GTRS-Dense-DINO（评分范式） —— GTRS-Dense 是「感知-评分」架构，每个 query 聚合场景信息后输出轨迹和对应的置信度。DINO-DINO 版本里，GTRS-Dense-DINO 在 OOD 场景下注意力依然锁定关键物体（原车、前方行人），而原版的注意力在风格偏移后变得散乱。

三个范式的 adapter 是同一个架构（4层MLP + CNN aggregator），只是每个规划头接的是各自独立的适配器实例。这说明 DINOv3 的特征接口是足够通用的，不是专为某一种规划架构设计的。

量化结果：冻结比微调更有效

最有说服力的证据来自消融实验。原论文 Table II 的结论非常明确：端到端微调 DINOv3 backbone（允许梯度回传更新编码器）在 navtest（标准场景）上比冻结稍好一点点，但在 OOD 场景上性能反而下降。

这背后的逻辑是：微调编码器会重新适应训练集的视觉分布，规划头会再次学到 visual shortcuts——只是换了套 shortcuts，本质问题没有解决。冻结才是正解：编码器永远提供一致的域不变特征，规划头被迫学会「看结构而不是看纹理」。

量化上看，OOD 性能对比：

方法	Origin（LTF 原版）	Heavy Snow	Dusk Sunset	整体 OOD Drop
Base（LTF 原版）	高	大幅下降	大幅下降	~40%
Domain Randomization	中	部分恢复	部分恢复	~25%
LTF-DINO（冻结）	高	基本持平	基本持平	~3%

接入成本：约 2M 参数

从工程角度，DINOv3 冻结编码器的接入成本极低：

• 适配器可训练参数约 2M，相比 7B 的 backbone 可以忽略不计
• 推理时 DINOv3 前向传播的计算量是大头，但它是纯视觉 encoder，可以跟规划头异步推理
• DINOv3 ViT-L 蒸馏版（300M 参数）可以在消费级 GPU 上跑，适合非量产的研究场景

这比重新训一个 task-specific backbone 便宜了不止一个量级。

和上篇的衔接

上篇 Harness 写到 2026 年选 AI 编程 Agent 要先看壳。自动驾驶的视觉系统也存在类似的「编码器 vs 上游」的取舍问题：模型趋同之后，真正的差异在感知层怎么接、怎么训。The Constant Eye 给出的方向是把感知层锁死，让规划层只依赖结构信息——这本质上是自动驾驶版的「看壳还是看模型」。

不过只解决 OOD 鲁棒性还不够。感知层的冻结编码器是「让模型看见什么」，但端到端方案里还有另一块硬骨头：数据从哪来——长尾场景的训练数据怎么规模化采集？仿真的画面怎么变成训练可用的真实数据？这就是下篇要写的 DINOv3 在自动驾驶领域的另一条路径：从仿真数据生成（Sim-to-Real）里扮演结构桥接角色。

---

论文：The Constant Eye: Benchmarking and Bridging Appearance Robustness in Autonomous Driving（arXiv:2602.12563, 2026-02）