Transformer 改变了我们理解表示的方式。

图像可以表示为 patch，语言可以表示为词或子词 token，BEV 特征图也可以转换为空间 token。对于协同三维感知，这带来一个重要问题：

智能体能否通信紧凑 token 集，而不是 dense feature map？

1. 为什么 token 有用

Dense feature map 通信成本很高。如果每个智能体每一帧都发送所有空间位置的特征，带宽开销会迅速变大。

Token 提供了更灵活的表示。一个 token 可以表示：

BEV grid cell；
局部空间区域；
语义物体；
记忆单元；
不确定区域；
压缩场景元素。

因为 token 是离散单元，所以可以被选择、排序、合并、剪枝或按预算传输。

这使它非常适合通信受限感知。

2. Token 化 BEV 表示

自动驾驶中 BEV 表示常用，因为它与地面平面和规划任务对齐。

BEV 特征可以写作：

\[F \in \mathbb{R}^{H \times W \times C}.\]

将其展平后得到 token 集：

\[T=\{t_i\}_{i=1}^{N}, \quad t_i \in \mathbb{R}^{C}.\]

每个 token 对应一个空间区域。这样就可以使用 attention 进行融合：

\[\text{Attn}(Q,K,V)=\text{softmax}\left(\frac{QK^T}{\sqrt{d}}\right)V.\]

在协同感知中，ego agent 可以在空间对齐后 attend 到邻近 agent 的 token。

3. Token Selection

降低通信成本最直接的方法是 token selection。

给定 token 集，模型选择子集：

\[T' \subset T,\quad |T'|\leq B,\]

其中 (B) 是通信预算。

选择依据可以包括：

feature magnitude；
语义重要性；
不确定性；
attention score；
空间位置；
ego request；
对 occupancy 精度的预期贡献。

但 selection 的问题是未选择 token 会被丢弃。如果选择策略错误，重要信息可能完全丢失。

4. Token Merging

Token merging 通过合并相似或冗余 token 来减少数量。

与直接丢弃不同，merging 可以把低优先级 token 压缩为摘要：

\[\tilde{t}_j=\sum_{i\in \mathcal{G}_j}\alpha_i t_i.\]

许多 BEV 区域是冗余的，例如大面积空路面、静态背景和低不确定 free space。

同时，重要区域应该保留更高分辨率：

遮挡区域；
动态目标；
路口；
ego 轨迹附近区域；
被 ego request 指定的区域。

因此，token merging 应该是 content-aware 的。

5. Request-Aware Communication

在协同感知中，ego agent 不需要所有邻居的全部信息。它需要能改善自身场景理解的信息。

一种 request-aware 流程是：

ego agent 先预测初始 occupancy；
识别不确定或重要区域；
向邻居发送请求；
邻居保护 request-relevant tokens；
其他 token 被压缩或合并；
ego agent 融合收到的 token 并更新 occupancy。

这种设计让通信由 ego agent 的需求驱动，而不是 sender 单方面决定。

6. 通信预算

协同感知方法应在不同带宽预算下评估。

重要问题包括：

带宽下降时精度如何变化？
哪些区域从通信中收益最大？
严重压缩下是否仍然稳定？
通信策略能否适应场景复杂度？
位姿噪声和延迟下是否鲁棒？

对占用预测而言，我不仅关注总体 mIoU，也关注动态物体和遮挡区域的质量。

7. 开放问题

我目前关心的问题包括：

如何衡量 token importance？
token 应表示固定网格还是自适应区域？
merging 如何保留语义边界？
temporal memory 如何与通信结合？
能否用 occupancy supervision 端到端学习通信？
方法如何泛化到不同带宽？

这些问题会继续指导我的研究。

面向多智能体三维感知的 Token 通信