CoNavBench: Collaborative Long-Horizon Vision-Language Navigation Benchmark¶

会议: ICLR 2026
OpenReview: https://openreview.net/forum?id=bMrH2PFMsi
代码: 待确认
领域: 机器人 / 具身导航 / 视觉语言导航 Benchmark
关键词: 协作导航, 视觉语言导航, 长程任务, 多机器人, 数据生成平台

一句话总结¶

CoNavBench 是首个面向"多机器人协作"的视觉语言导航（VLN）基准，包含 4048 条单机/协作任务，并配套一个图接地的自动数据生成平台 NavCraft（双阶段智能体 + 场景图 + 效率工具库），用一个微调的 Qwen2.5-VL-3B 作为参考策略，证明协作分解能把步级任务成功率相对提升 18.11%。

研究背景与动机¶

领域现状：视觉语言导航（VLN）研究的主流是"单智能体、按指令逐步执行"的范式——从 R2R 的全景图逐点跟随，到 VLN-CE 的连续控制，再到 LHPR-VLN/GOAT-Bench 这类长程、多阶段、跨多回合的任务，难度在涨，但参与者始终是一个机器人。

现有痛点：真实部署里（家政、仓储、并行工作流）往往有多个机器人可用，但现有数据集与评测协议默认单智能体，这带来两个后果：一是掩盖了协作机会——本可以并行的子任务被强制串行，长程任务被一条轨迹从头跑到尾，造成长延迟和空等；二是忽略了机器人间的相互干扰——拥堵、交接（handoff）错误、汇合（rendezvous）时机这些只有多机才会出现的难题，单智能体形式化根本碰不到。

核心矛盾：协作 VLN 的价值（更短的总完工时间 makespan、靠并行与角色分工带来的鲁棒性）和它的新挑战（拥堵、交接、汇合定时）是绑定的，而现有的基准既不提供"为协作而生"的任务，也不提供能量化干扰的标注，于是这个方向无从系统评测。

本文目标：作者把协作 VLN 拆成三个递进的难题：(i) 可协作的任务合成——构造带明确阶段边界和跨房间依赖、真有协作收益的长程单机基础任务；(ii) 无冲突的团队调度——把单机任务抬升成带角色分配、时序、汇合点的多机方案；(iii) 回环内的效率优化——给定可行方案，估计团队级时间、预判瓶颈、给出可执行的修复建议。

切入角度：与其让 LLM 智能体继续当"导航器"（grounding 观测、产出子目标），不如把它当成数据生成与调度引擎——让一个分层智能体在带语义的场景图上合成任务、分配角色、产出团队感知的调度。场景图在回路里能做可达性检查、估行程时间、评估干扰，从而避免每步都跑全物理仿真。

核心 idea：用"场景图接地的双阶段智能体（NavCraft-S 生单机基础任务 → NavCraft-C 抬升为协作调度）+ 图上效率工具库"自动、可扩展地生成协作 VLN 任务，构成 CoNavBench 基准，并验证协作分解确实能缩短 makespan、提升可靠性。

方法详解¶

整体框架¶

CoNavBench 这篇工作有两层产出：一个基准（4048 条单机/协作任务 + 协作类型 taxonomy + 图级标注）和一个生成这个基准的平台 NavCraft。读懂这篇笔记的关键是搞清 NavCraft 这条流水线——它接收一个 Habitat-Sim 的连通图，先做语义化（把每个节点标成房间类型），再用双阶段智能体在这张图上"先单机后协作"地长出任务，每一步都靠一个图上效率工具库做可行性校验和效率建议。

具体地，NavCraft 分四段：① 场景图生成——给 Habitat 连通图 $G=(V,E)$ 的每个节点打房间类型标签，经过四道由粗到细的修正得到语义图；② NavCraft-S——在语义图上采样"起点 $s$ → 目标物所在区域 $t$ → 终点 $e$"三元组，做跨房间可行性校验，合成单机长程基础任务；③ NavCraft-C——判断协作是否划算，若划算则固定一种交接类型，把单机方案抬升成双机调度；④ 效率工具库——贯穿前三段，把语言意图翻译成对距离/通道宽度/遮挡/占用的数值约束，校验可达性与干扰、估时间、给建议，形成闭环。最后作者用 Qwen2.5-VL-3B 微调出一个协作参考策略，在 Habitat3 连续仿真里执行评测。任务以高层指令"在 X 找物体 A，送到 Y"为模板，协作版把它拆成"一个机器人取物并送到中继点，另一个接力送达终点"。

关键设计¶

1. 四道修正的语义场景图：把几何连通图变成可推理协作的"房间地图"

协作调度需要知道每个位置"是哪种房间"才能编排跨房间任务，但 Habitat 连通图只有几何位置和拓扑，没有语义。作者用四道由粗到细的标注流程逐步把节点标成房间类型。第一道实例近邻投票（IPV）：对节点 $i$ 在地平面上找 $k$ 个最近的已标注物体（默认 $k=3$），取多数房间类作为初始标签 $\hat r^{(0)}_i = \arg\max_c \sum_{m\in N_k(i)} \mathbb{1}[r(m)=c]$。第二道邻域一致性（NC）：门口等狭窄通道容易出现孤立误标，于是只在"节点度适中（$2\le \deg(i)\le 4$）且其标签与所有邻居都不一致"时，才把它改成最近邻居的标签——两个守卫条件同时成立才动手，避免过度平滑。第三道连通性修复：墙体等结构障碍会把同一类房间割成多个碎片岛，作者在连通分量层面操作，对每个类只保留最大连通分量，剩下的孤立分量若不挨着别的类就删除、否则整块并入边界最近的相邻类。第四道图上下文打标：仍是 Unknown 的少数模糊区域，用相邻房间类型直方图 + 区域内 top-5 物体名喂给一个轻量指令模型（GPT-4o mini）补一个最合理的类型。这套"先投票、再局部纠偏、再连通修复、最后兜底"的设计，让纯几何图变成了能支撑跨房间任务编排的语义蓝图。

2. NavCraft-S：合成"为协作准备好"的单机长程基础任务

协作的前提是基础任务本身够长、跨房间、有可被拆解的阶段——如果任务一步就到，就没有协作空间。NavCraft-S 在房间标注图上采样可行三元组 $(s,t,e)$。它先做画像条件采样：注入一个轻量角色画像 $\pi$（年龄/职业/生活方式），只用作多个等价候选物体/终点之间的 tie-breaker，绝不凌驾于可行性之上，目的是在不依赖手工先验的情况下增加任务多样性和措辞多样性。然后做可行性校验：把任务的两段腿 $s\to t$ 和 $t\to e$ 都放到区域图上检查，要求每段都连通且跳数足够长。作者定义 $L(u,v)$ 为区域图上的跳距，引入跳数阈值 $\tau\ge 1$（CoNavBench 设 $\tau=2$）控制最小跨房间幅度，单段合法条件为 $\text{leg\_ok}(u,v):=\text{conn}(u,v)\wedge L(u,v)\ge\max\{2,\tau\}$，整体合法为 $\text{valid}:=\text{leg\_ok}(s,t)\wedge\text{leg\_ok}(t,e)$。$\tau$ 越大越鼓励长程规划。合法后把两段腿的最短路拼接、压缩同区域的连续节点得到区域级转移路径。这一步保证生成的每条基础任务"真的跨房间、真的有阶段"，从源头给协作留出空间。

3. NavCraft-C：用"严格缩短主机器人路程"作硬门槛的协作抬升

有了单机基础任务，NavCraft-C 决定要不要、以及怎么引入第二个机器人。它先用类型抽象把协作收敛成两种交接模式，从而把"是否协作"的推理和具体运动原语解耦：Type A1——协作者在 $t$ 取物、在中转区 $x$ 交接、主机器人从 $x$ 送到 $e$；Type A2——主机器人在 $t$ 取物、在 $x$ 交接、协作者从 $x$ 送到 $e$。为了量化路程，作者在 Habitat 连通图基础上构建增广度量图 $G^+$：边权用 2D 欧氏距离，把锚点（终点资产 $a_e$、候选中转资产 $a_x$）按物理位置插入并连到最近可导航节点，统一用 $d(x,y)=\text{dist}_{G^+}(x,y)$ 度量。核心是协作接受准则：先算主机器人单干时承担的路程 $C_{\text{solo}}=d(s,o)+d(o,a_e)$，再算两种协作下主机器人承担的负载 $J^{A1}_{r1}=d(s,a_x)+d(a_x,a_e)$、$J^{A2}_{r1}=d(s,t)+d(t,a_x)$，只有当 $\min\{J^{A1}_{r1},J^{A2}_{r1}\}<C_{\text{solo}}$（引入协作严格缩短主机器人自身路程）才接受协作，并报告改善比 $\alpha=\min\{J^{A1}_{r1},J^{A2}_{r1}\}/C_{\text{solo}}$。候选还须过场景图守卫：$x\ne t$ 且 $a_x$ 存在、两机都能在 $G^+$ 里到达 $x$、协作者起点对 $(t,x)$ 满足非相邻与连通规则。规划器迭代提候选并记录 $\alpha<1$ 的方案。这个"只在真划算时才协作"的硬门槛，避免了生成大量"为协作而协作"的无效任务。

4. 图上效率工具库 + 参考策略：闭环校验与可执行评测基线

前三段的可达性检查、行程估时、干扰评估都由一个图上效率工具库支撑：它把语言意图翻译成对距离、通道宽度、遮挡、占用率的数值约束，验证可达性与干扰、估时间，然后对子目标分配、汇合定时、协作者部署、路线修订给出建议，智能体在闭环里消费这些建议——这样既保住准确性，又避免每步跑全物理 rollout 的昂贵开销。在数据生成智能体的选型上，作者横评了 Google/Claude/OpenAI 多个 API 模型的生成成功率、协作增益和成本，最终选 GPT-4o-mini（协作生成 SR 26.56%、平均协作增益 25.12%、单样本约 $0.360，是 4o 的 $5.242 的 1/14），在质量与价格间取平衡来规模化合成。基准侧则提供一个参考策略栈：用 Qwen2.5-VL-3B（视觉特征由冻结的 EVA-CLIP-02-LARGE ViT 抽取，只全参微调非视觉模块），证明在 CoNavBench 上训练的协作策略能比单机对手缩短 makespan、提升可靠性。

一个完整示例¶

以"在卧室找到杯子，送到客厅"为例走一遍：NavCraft-S 先在语义图上采样三元组——起点 $s$=书房、目标物区域 $t$=卧室、终点 $e$=客厅，校验 $s\to t$ 与 $t\to e$ 两段腿都连通且各 $\ge 2$ 跳，拼接最短路得到区域转移序列。NavCraft-C 接手：算主机器人单干路程 $C_{\text{solo}}$（书房→卧室取杯→客厅），再找一个走廊中转点 $x$，发现 Type A1（协作者去卧室取杯、走廊交接、主机器人送客厅）下主机器人只需走 $d(s,x)+d(x,a_e)$，比 $C_{\text{solo}}$ 短、$\alpha<1$，于是接受协作并固定为 A1。效率工具库校验两机都能到 $x$、走廊不拥堵、汇合时间可行，最后生成一条"两机接力 + 走廊交接"的协作任务，配上图级标注（成功阈值、makespan、干扰时间）。可见整条流水线产出的是一条有明确交接点、可量化效率的协作 episode，而非随意拼凑的多机轨迹。

实验关键数据¶

基准统计与主实验¶

CoNavBench 含 4048 条 episode（2436 单机 + 1612 协作），相比 R2R/REVERIE/VLN-CE/LHPR-VLN 等清一色单机基准，它是首个 Multi-agent VLN 基准，平均协作增益约 21.08%（跨类别约 20%）。评测在 Habitat3 连续仿真里进行，用 Fetch 与 Spot 两种异构机器人，场景来自 HM3D 的 216 个室内重建。指标包括 SR（成功率，1.0m 阈值）、SPL（路径长度加权成功率）、NE（导航误差，越低越好），以及从 LH-VLN 引入的 ICR/ISR（子任务独立完成率）和 CSR（条件成功率，须前序子任务全成功）。

单机任务（High-level / Step-by-step）：

方法	类型	SR↑	SPL↑	ISR↑	CSR↑	NE↓
Random	-	0.00/1.26	0.00/1.26	1.61/1.26	1.21/1.26	7.25/7.56
Qwen2.5-VL-3B	Zero-shot	4.30/10.41	0.98/2.55	14.25/10.41	16.10/10.41	6.91/7.80
Qwen2.5-VL-3B	Finetuned	12.90/29.65	6.08/13.81	23.92/29.65	26.22/29.65	6.40/6.74
Qwen2.5-VL-7B	Finetuned	10.22/22.40	4.93/12.57	22.58/22.40	22.45/22.40	6.39/7.46

协作任务（High-level / Step-by-step）：

方法	类型	SR↑	SPL↑	NE↓
Qwen2.5-VL-3B	Finetuned	11.11/35.02	4.82/16.88	6.55/5.79
Qwen2.5-VL-7B	Finetuned	11.65/29.78	6.24/16.56	6.74/6.20

关键对比：在 step-by-step 协议下，微调 3B 的 SR 从单机 29.65% 升到协作 35.02%（相对 +18.11%，即论文摘要里的"18.11% step-level success"），7B 从 22.40% 升到 29.78%、SPL 从 12.57 升到 16.56、NE 下降——印证了"把长程多阶段指令拆成单阶段子任务、缩短决策视野"的设计确实提升局部能力。

消融：数据生成智能体选型¶

作者横评不同 API 模型当数据生成智能体（成功率指任务生成成功率）：

智能体	单机生成 SR↑	协作增益(Avg)↑	成本($)↓
Gemini 2.0-flash	47%	22.32%	0.265
Claude 3.5-haiku	51%	37.06%	1.142
GPT-4o	77%	21.07%	5.242
GPT-4o-mini	64%	25.12%	0.360

关键发现¶

协作分解在步级协议上稳定增益，但高层端到端增益小甚至略降：高层任务里测试时的中继规划引入中间交接点和辅助措辞，会造成轻微的视觉-语言失配；加上高层完成本身难（成功跨阶段复合、早期错误传播、状态同步与重定位的协调开销扩大有效搜索空间）。
7B 不超 3B 是欠训而非本质限制：在当前数据预算下 7B 没超过 3B，但单看协作设定 7B 自身仍获益（SR 22.40%→29.78%），说明多智能体分解可靠地提升局部能力，即便模型容量没被充分利用。
生成智能体的能力与成本权衡明显：弱智能体（Claude-3.5-haiku 协作相对增益 50.07%）能从任务分解获益但绝对成功率极低（3.90%）；GPT-4o 绝对最强（单机 77%）但贵；GPT-4o-mini 在质量/价格间最平衡，故被选为最终数据生成智能体。

亮点与洞察¶

把 LLM 智能体从"导航器"改造成"数据生成与调度引擎"：这是和以往 VLN 用 LLM 当 navigator 的最大分野——用分层智能体合成可协作的长程任务、分配角色、产出团队感知调度，绕开了"协作 VLN 没有训练/评测数据"的根本瓶颈。
协作接受准则用"严格缩短主机器人路程"当硬门槛：$\min\{J^{A1}_{r1},J^{A2}_{r1}\}<C_{\text{solo}}$ 这个简洁判据保证生成的协作任务真有效率收益，避免了"为协作而协作"的噪声样本，这个思路可迁移到任何"自动判断是否值得引入额外资源"的数据合成场景。
场景图在回路里替代全物理 rollout：用图上工具库做可达性/干扰/估时，既保住物理合理性又省掉每步跑仿真的开销，是把"昂贵的具身校验"近似成"廉价的图计算"的实用工程范式。
四道由粗到细的场景图标注（投票→局部纠偏→连通修复→上下文兜底）本身是一套可复用的"几何图语义化"配方，对任何需要把连通图标成语义区域的具身任务都有参考价值。

局限与展望¶

数据生成依赖 GPT API 模型：会引入风格偏置、且复现性对后端更新敏感；作者提出下一步训练/蒸馏一个 CoNavBench 专用开源 LLM，并用 batching/caching/图上剪枝提吞吐。
只覆盖两机接力：NavCraft-C 目前只针对 HM3D 室内场景的双机 relay 模式，三机及以上、更丰富的协作模式覆盖有限，部分受限于场景尺寸。
绝对性能仍低：即便微调后高层 SR 也仅约 11-13%，说明基准很难、留了大量提升空间；但也意味着当前参考策略离实用还远，基准的区分度主要靠 step-by-step 协议体现，高层端到端评测的可靠性需谨慎解读。
协作类型 taxonomy 较窄：只有 A1/A2 两种交接模式，难以覆盖真实多机协作里的并行探索、动态重分配等更复杂模式。

评分¶

新颖性: ⭐⭐⭐⭐⭐ 首个协作 VLN 基准 + 把 LLM 当数据生成/调度引擎，填补明确空白。
实验充分度: ⭐⭐⭐⭐ 单机/协作双协议 + 生成智能体横评较完整，但参考策略单一、绝对性能低、协作类型仅两种。
写作质量: ⭐⭐⭐⭐ NavCraft 流水线讲得清晰、公式齐全；部分指标命名（ISR/ICR）和 18.11% 的措辞略含糊。
价值: ⭐⭐⭐⭐⭐ 为协作具身导航这个方向提供了可扩展的数据平台和评测标准，社区价值高。