上海交大造11724个多机器人协作场景：资源冲突和碰撞怎么解

想象一下：你和三个朋友一起装修新家，你负责去厨房找冰箱的位置，另一个人去客厅挪沙发，第三个人在卧室等着，得等你把冰箱的事办完才能动。听起来不难，可只要其中一个人突然提前离岗，或者两个人同时往一个门口挤，整个计划就乱了。

上海交通大学的研究者们盯上的正是这个问题。他们发现，过去几年机器人导航领域一直在闷头解决「一个机器人加一句话」这种最简单的组合——一个机器人，听一句指令，走到一个地方，这叫做视觉语言导航。

视觉语言导航*：机器人听懂一句自然语言指令（比如「走到客厅的沙发旁边」），然后在真实或模拟环境里自己找路走过去。

这个方向进步确实快，可现实世界从来不是一个人干完所有事。装修、仓库分拣、灾难救援，都得靠团队协作，需要几个机器人同时行动、互相等待、避免撞车。问题是，把单智能体导航直接扩展到多智能体，远比看起来复杂。

这篇论文的核心问题，恰恰出在这里。

**现有的多智能体研究，要么环境太假，要么约束太简单。**

先说环境假的那一类。研究者发现，不少做LLM多智能体规划的工作，任务结构在纸面上画得很漂亮，用有向无环图表示任务之间的先后关系，执行层面却严重作弊：要么直接调用模拟器提供的「瞬移到目标点」这种上帝视角API，要么提前把整个房间扫描建图完毕才开始规划。这就好比两个人搬家前，先把新房子的3D模型完整扫描一遍，家具位置、门的宽度全部标注清楚，然后再谈「分工合作」。分工逻辑能设计得很精巧，可一旦换到完全没见过的新房子，这套系统立刻失灵，因为它从来没真正学会「看着陌生环境自己找路」。

还有一类做法，是把VLN直接往多智能体方向扩，CoNavBench、Co-VLN都属此类。让机器人在陌生环境里跑起来，这条路子是对的。问题出在对协作的设定上，太单薄了，大多停在小队接力，或者你瞅一眼我拍到的画面这种程度。论文点出一个关键数据：现有多智能体VLN基准中，任务依赖关系几乎清一色是链式的——A干完B才能动，B干完C才能动，一条线排到底。可现实中的协作要绕得多：A得等B和C都收工才能接着干，B中途还得替A守住一个位置不能撤，C做完要同时把两个人的后续解锁。这种网状约束，以前的基准压根没碰过，也没有任何指标去衡量机器人之间会不会撞上。

这篇论文把两条路线的优点捏到了一起，还顺手补上了两边都没解决的「资源冲突」和「物理碰撞」问题。他们管这个新任务叫系统性多智能体视觉语言导航，数据集起名MAVLN，一共造出11724个任务场景，铺在145个真实扫描的室内场景里，支持最多四个机器人同时协作。

接下来一步一步拆开看，他们到底是怎么把这件事做成的。

任务怎么定义：除了「谁先谁后」，还得管「谁得等着」

要理解这篇论文的创新，得先搞懂他们是怎么重新定义「多智能体协作任务」的。

以往讲任务依赖，说的多是时间上的先后：A完事，B才能上。现实协作却还压着另一种更不显眼的约束——资源约束。论文给出了两种具体形态。

第一种叫持有链。

持有链*：只要某个子任务要求「拿着东西」，接下它的机器人就多背了一项任务——此后它只能去干这件东西的「消费者」子任务，中间不许跑去忙别的，直到把东西交出去。

想象你去快递柜取了一个大箱子，箱子还没送到该去的地方，你不可能顺路再去买杯咖啡，只能老老实实把箱子送到目的地，这期间你被这个箱子「绑定」了。不设置持有链约束会怎样？机器人取完包裹后，系统判断它「空闲」就派它去干别的任务，结果包裹永远送不到该去的地方，整个任务链条断掉。

第二种叫在场锁。

在场锁*：某个子任务要求机器人完成后必须留在原地，一直等到团队里另一个成员完成了特定的子任务，才能解除限制离开。

这就像你去医院挂号排队，护士让你「在这儿等着别走，等医生那边准备好了会通知你」。没有这个机制会怎样？机器人办完事立刻走开，等需要它的队友赶到时，它人已经不在了，前面的工作全部白费。论文统计显示，在他们造的任务里，92.9%的任务都包含持有链，28.3%包含在场锁，还有26.3%的任务同时具备两种约束，只有5.1%的任务简化成了纯粹的「先后顺序」图。这意味着，一个系统如果只会处理简单的依赖关系，在真实的多智能体任务面前，大部分时间都会出错。

**依赖约束管的是「什么时候能完成」，资源约束管的是「完成之后身体能不能动」，这是两件完全独立的事。**

这个区分很要命，调度系统设计的难易程度全看它。一个只认得先后的调度器，碰上「你得先完成A，但完成A之后你还不能走」这种局面就束手无策了。

数据从哪来：一条四阶段的自动化流水线

任务怎么定义清楚了，下一个问题是：这么复杂的任务，数据打哪儿来？靠人工标注显然不现实，11724个场景一个个手写，谁也扛不住。研究团队于是搭了一条自动化的生成流水线，交给大语言模型来做，但又不放手让它随意编，否则生成的任务很可能在真实环境里根本执行不了。

整条流水线分成四个阶段。

整条流程的头一个环节，叫扎根式场景理解。

具体做法是：视觉语言模型先看机器人在环境各处拍下的全景图，再结合物体检测给出的语义信息，逐个视角说清画面里有哪些物体，最后把各视角的零散描述拼成“这片区域属于什么房间、里面放了什么”的整体判断。

这么做的用意很明确——保证后续生成的每一条指令，都落在真实存在、真能走到的物体上，避免模型凭空编出一张“书桌”，而环境里压根没有。论文为此设了四道关卡：物体离机器人够不够近、语义分割图里是否真能看到它、可见面积够不够大、机器人能不能真正走到它跟前。打个比方，动笔写菜谱之前，先打开厨房冰箱看一眼，确认食材确实在，而不是照着菜谱想象橱柜里该有什么。

接下来是多样化任务合成。系统会为每个场景配一个贴切的“家庭画像”，比如有小孩的家庭、几代人同住的家庭、饮食上有特殊要求的家庭，这些画像本身就自带协作需求。有小孩的家庭，容易冒出“总得有人盯着孩子”这类在场锁需求；轮班工作的家庭，则容易产生时间错开的协作需求。画像和场景信息齐了，大语言模型就下场“编剧”，构思具体的任务情节和子任务清单。

第三个环节是任务精炼，也是整条流水线里筛得最狠的一关。系统得把草稿中每个子任务目标精确落到场景里某个具体观测点上，同时重新计算整个任务的最短完成时间，反复调整分工和顺序，好让团队用最短时间把活干完。论文统计显示，这一步的留存率只有45.39%，也就是说超过一半的草稿要么在空间上落不了地，要么调度后发现效率太差，被直接丢弃。

最后一个环节是验证式指令渲染。视觉语言模型会重新过一遍每条指令，核对描述的细节与真实画面是否一致，把幻觉或错误描述改掉，再把核验过的原子指令拼成完整的任务说明。整套流程走完后还有一道“回环检验”：另有一个大语言模型只看最终生成的指令文字，试着推演整个团队该按什么顺序到达各处，再拿推演结果去比对真实的任务约束，对不上就退回重做。这道检验的意义在于，仅凭文字描述就能唯一锁定一种正确执行方案，不会留下“这句话到底指什么”的歧义。

从最初的13747份草稿，到最终发布的3908个任务，整体保留率为28.43%。研究者特意点明，流失最多的地方在程序化的几何与调度检查，而非大语言模型的主观判断，这说明留下来的数据都经过了客观约束的硬性验证，不是硬凑出来的。

三种下达方式：从分工明确到身份全隐

针对同一个任务，研究者还设计了三种不同的“说法”，用来模拟现实中人们下指令时的不同习惯。

去中心化版本给每个机器人单独下一条指令，讲明它该干什么，每个子任务只许指定的机器人执行。中心化版本把整个团队的任务揉成一条完整指令，虽然也提到“谁去做什么”，但执行层面不再设限，任何机器人都能接手任何子任务。中心化隐式版本最彻底，把所有身份归属信息统统抹掉，机器人团队得自己从一整段话里推断出谁该干什么。

这好比三种开会方式。第一种，老板挨个给员工发邮件，写清你负责哪块。第二种，会上说明整体计划，顺带提了谁管什么，但谁想抢着干也可以。第三种，老板只念了一遍任务清单，一个字没提谁该干什么，全凭员工自己商量着分。实验数据印证了这条难度梯度：中心化隐式设定下，表现最好的调度器成功率也只有5.4到8左右，明显低于去中心化版本的7到8点多。原因很直白——系统既要读懂约束，又得多做一步“谁该做什么”的推理，两件事叠在一起，出错概率自然更高。

TRISS系统：机器人团队如何真正协作

数据集有了，接下来的问题是怎么把任务解掉。研究者设计了一套叫TRISS的系统，分成调度、规划、执行三个模块。

第一块：大语言模型充当“项目经理”

调度器负责把一整段任务指令拆成一条条具体的原子导航指令。

所谓原子导航指令，指的是一次完整的“去哪、找什么”的描述，既不含到达之后要做的动作，也不含“等谁完成”这类协调性话语。

拆完之后，系统还得动态决定每一轮把哪些指令派给哪个机器人。这里有个很巧的设计：即便A的任务依赖B先完成，A照样可以提前动身往目的地走，因为“走到那里”本身不违反任何依赖关系，真正受限的是“到达后能不能宣布完成”。论文把这个机制称为预分配，靠提前派发任务，把原本白白耗掉的等待时间变成了有效的赶路时间。

这就像你和同事约好，你负责的环节要等他签字才能往下走，但你完全可以先到他办公室门口候着，而不是坐在工位上干等通知再出发。实验数据证明了它的价值：去掉预分配机制后，完成同样任务所需的时间步数从215步涨到261步，多了21%。放到真实场景里调度一支救援队，这意味着每次任务都要白白拖长近四分之一的时间，长期累积下来代价相当可观。

第二块：所有机器人共用一张不断生长的地图

这是整篇论文里我认为设计思路最有意思的地方。单个机器人导航时，通常靠自己边走边建一张地图，这种地图叫拓扑地图。

拓扑地图用节点表示机器人到过或打算去的地点，用边表示这些地点之间能否直接走通，整体构成一张抽象的路线图，而非精确到厘米的几何地图。

TRISS的做法是让团队里所有机器人共用同一张拓扑地图。你或许会问，这有什么稀奇，不就是把地图共享一下。可细想背后的逻辑：一个机器人探索过的区域，另一个从没去过的机器人立刻就能“看见”这片区域的信息，不必亲自跑一遍重新发现。

四个人被派进一座废弃工厂找东西，每人走过的房间都实时同步给另外三个人。要是没这套共享，会怎样？各走各的，一遍遍踏进同一片区域，时间全耗在重复路线上。论文统计的数字正好把这种浪费摆了出来：团队连续执行子任务时，总行走距离里平均有约四分之一是重复走过的老路；任务拉得越长，这个比例还往上走。换句话说，“重复行走的距离”直接量出了共享记忆能省下多少冤枉路。

实验也印证了这点。把共享地图关掉，任务成功率从9.1%滑到6.2%，路径效率指标从4.0降到3.0。数字看着不大，可原本成功率就低，3个百分点相当于把本就不多的成功案例又削掉了三分之一。

地图的维护也有门道。多个机器人会同时往同一张地图上提新的探索点，系统因此设计了一套位置匹配机制，判断不同机器人报出的“新地点”是不是其实指向同一处，免得一个地方被记成好几个节点，地图越建越乱。另外，系统还加了一个失败验证排除机制：某个机器人朝预测的新地点走，走了半天位置没动，这次失败就被记下来，告诉全队“这个方向不通”，别的队友不用再去踩同一个坑。

### 第三块：避免大家在同一个门口撞车

调度和规划做得再好，真走起来还是可能撞上。四个人同时往一扇窄门里挤，结果谁也过不去。TRISS拿两层机制来解这个问题。

头一层是冲突无关的目标分配。两个机器人同时盯上同一个落脚点时，系统用二分图最优匹配的算法重新分派，让整体收益最大，而不是放任双方硬抢。第二层是基于冲突的路径搜索，管的是行进途中路线会不会在某个时间点撞上；一旦发现冲突就重规划一条绕行路线，甚至允许某个机器人原地等一等，让别人先过。

代价和收益，论文写得很清楚。两层机制都关闭时，机器人之间的冲突指标是2.2，这个数衡量的是任意两个机器人距离过近的时间占比。只开冲突无关分配，降到1.4；再加上基于冲突的路径搜索，进一步降到0.8。代价是执行时间从1230步涨到1588步，多出358步。说到底这就是个很现实的取舍：跑得快，容易撞；绕点路，更安全。没有免费的午餐。

实验结果说了什么：成功率个位数背后的真相

这篇论文最实在的地方，是没把结果包装成“我们搞定了多智能体导航”。真实数据相当扎眼。

调度和导航都换成理想化的“上帝视角”组件时，TRISS能做到100%成功率，只需215步左右。可一旦导航换成TRISS自己训练的真实导航模型，成功率马上从99.6%掉到5.2%。这个落差不是TRISS独有的，研究者专门拿另一个经典单智能体导航模型ETPNav

ETPNav* 原本是为单智能体视觉语言导航打造的拓扑规划模型，论文作者在 MAVLN 数据集上对它重新训练，随后当作对比基准使用。

来对比，ETPNav在同样任务上成功率只有2.8%。这说明问题不在TRISS设计得差，而是多智能体视觉语言导航这个任务本身，对导航模型的要求就比单智能体设定苛刻得多。

调度器换成真实的大语言模型后，比如阿里的通义千问系列模型Qwen3.6或谷歌的Gemma4，成功率进一步滑到个位数：去中心化设定下大约7到9个百分点，中心化隐式设定下只有5到7个百分点。不过这不等于大语言模型调度器没用。论文做了对照：调度器随机乱发指令或按顺序硬发指令，成功率会跌到接近0或2到3个百分点，远低于用大语言模型推理之后的结果。可见现有系统的瓶颈主要卡在导航规划这一环，调度逻辑本身并非完全无效。

论文还专门做了一轮“地毯式”的消融实验，把每个判断是否要双尺度推理

双尺度推理*：规划下一步走向时，导航规划器会同时从两种粒度入手——粗粒度上，它站在整张地图的层面判断大方向；细粒度上，它则依据当前具体视角决定眼前这一步该朝哪边迈。两种判断会动态融合，最终形成决定。

去掉之后，导航成功率直接从9.1%掉到0%，几乎彻底失效。研究者的解释是：共享地图意味着每一步要考虑的候选节点数量会随团队规模急剧膨胀，只靠粗粒度的全局判断，噪声会被无限放大，必须用细粒度的局部观察来锚定注意力。这不是沿袭前人设计的风格选择，而是多智能体场景下的硬性需求。

下面这张表格汇总了几个关键的对比实验，数字背后的落差一目了然。

| 配置 | 成功率(验证集) | 成功率(测试集) | 耗时步数 |

|---|---|---|---|

| 理想调度+理想导航 | **100.0%** | **100.0%** | 215 |

| 理想调度+真实导航(TRISS) | 9.1% | 9.3% | 1588 |

| 单机器人执行(理想导航) | 67.1% | 69.1% | 412 |

| Qwen3.6调度+真实导航 | 7.3% | 7.9% | 1613 |

| 随机调度+真实导航 | 0.3% | 0.2% | 1621 |

单机器人执行那一行是表里最该盯住的：导航条件即使理想化，一个机器人把全部任务跑完仍要412步，四个机器人协作在理想状态下只需215步，差了将近一倍。团队协作带来的效率提升是实打实的，问题出在眼下的导航能力上，它把后腿拖得很明显。

论文另外测了一件事——让大语言模型直接看图走路，充当“零样本导航员”。效果比经过训练的专用导航模型低了8个百分点左右，可耗时和冲突这两项指标反倒更低。研究者点得很准：大语言模型倾向于提前放弃，任务被过早终止，并不是真的走得更高效。看起来省时间的方案，背地里可能是它压根没把任务好好完成。

写在后面

把这篇论文读完，让我意外的不是TRISS系统设计得多精巧，而是那个个位数的成功率。造数据集、设计调度和执行机制，团队花了很大力气，最后把成功率原原本本摆出来，只有个位数的百分点，这种诚实本身就值得说一说。

不少论文写到实验部分，会想办法把数字包装得好看些，挑表现最好的子集来展示，或者在叙述里把短板淡化掉。这篇的做法相反，专门设了一整节局限性分析，拿理想化的规划器去对比真实训练出来的规划器。结果显示，即便目标选择完全正确，路径规划的能力上限也被死死卡在不到90%，离饱和还远。把自己的天花板明明白白写出来，反而让人更相信这个基准测试是认真的。

另一个让我停下来想了想的细节是，论文提到团队执行任务时，大约四分之一的行走距离花在重复走已经走过的路上。这个数字暴露的问题更深：当前的导航系统，单智能体也好多智能体也好，骨子里都还没真正学会“记住自己走过哪里”。共享地图能缓解队友之间的重复探索，可每个机器人自己走回头路这件事，论文并没有完全解决。

还有一处值得细品：论文专门把“任务完成了多少个子任务”和“任务是不是按照约束正确完成的”分成两件事。很多系统的失败，不是机器人没走到地方，而是走到了地方，却违反了某个在场锁或者持有链约束，整个任务因此被判失败。这意味着未来真正要攻克的难题，可能不只是“让机器人认路更准”，而是“让机器人理解自己此刻处于什么协作状态里，知道自己能不能走开”。这更接近对自身角色和责任的持续感知，而不只是一个纯粹的空间导航问题。

再往前推一步，我很好奇的是：团队规模从四个机器人扩到几十个、上百个，现在这套基于共享拓扑地图和中心化调度的架构还能不能扛住。候选节点数量会随团队规模指数级增长，论文里已经提到，为了控制计算量，不得不限定每个机器人只能看到自己走过的区域加上邻近的前沿节点。四个机器人的规模下这个限制还算合理，再往上会不会变成新的瓶颈，值得继续追问。

Q&A

Q1：MAVLN数据集是什么？

上海交通大学团队提出了多智能体视觉语言导航基准 MAVLN：145 个真实室内场景、11724 个任务场景，最多支持四个机器人协同；导航任务里第一次出现依赖约束、资源约束和冲突测量这几类设定。

Q2：TRISS系统是怎么工作的？

TRISS 分成三块：大语言模型把任务拆成具体指令，再动态派给各个机器人；规划器依托共享拓扑地图，逐 step 决定往哪走；执行环节带冲突感知，防止机器人彼此撞上。

Q3：为什么多机器人导航任务的成功率这么低？

论文实验里，把理想化组件换成真实训练的导航模型之后，成功率从接近 100% 掉到个位数。瓶颈主要卡在导航规划这一步：目标选得再对，路径规划的能力也远没到饱和，当前方法离真正解决这个任务还差得远。