76 次导航，76 次成功。18 次抓取，9 次成功。同一套系统、同一台机器人、同一张地图，两个环节的成功率一个是 100%，一个正好一半。这是我在读这篇论文时最先记下来的两个数，因为它们把“自主移动操作”这件事的难点摆得非常直白：机器人知道该往哪走，也知道目标在哪，能不能成，卡在了最后一手。

这篇论文把一套基础模型驱动的 3D 场景图系统推到能真的上机器人的程度，再用五个真实场景、十次全自主重排任务、二十件开放词表物体，把“这张图能撑起多长的自主管线”量化到每个环节。系统叫 FOUND-IT++，输入只有一台未标定的单目相机，不需要深度、双目或标定板；输出是分三层的图：物体层、地点层、区域层。

我认为它值得工程侧认真看的地方，不在于“场景图能建出来”——前一版已经证明了实时成图——而在于它回答了一个更硬的问题：这张图被规划器和抓取器消费的时候，哪一层是能信 100%、哪一层只能信一半，以及为什么。下面我按“为什么要图、图怎么长出来、图怎么更新、策略怎么读图、实测与基线、边界”的顺序走一遍。

点云告诉你哪里有东西，场景图告诉你那是什么

先说清楚为什么移动操作不能只靠点云或者占据栅格。点云把几何摆得很清楚：哪里有东西、哪里是空的、障碍多高。但一次“把被移动的易拉罐放回原位”的任务里，机器人真正要回答的是另外几个问题：这个位置在原来那张图里对应哪一件具体的物体？它属于哪个房间或区域？我能从哪条缝隙走过去？它现在的位置和我记忆里的差别是不是“被搬走了”？抓它的时候那个点云的尺度是米制吗？

这些问题里只有最后一个跟几何直接相关，其余都需要“结构”：3D 场景图把度量信息与语义信息压进一个层次结构，物体挂在某个地点上，地点落在某个区域里，每个节点同时带位置与语义。但论文在相关工作里点得很直接：经典场景图系统虽然做过大量整机演示，却普遍要求已标定的传感器、深度或双目输入，而且管线复杂、难以维护；另一条线是几何基础模型带来的变化——单目、未标定的 RGB 图像就能估出相机位姿与三维几何，于是一批即插即用的 SLAM 系统出现了。

前作 FOUND-IT 就是把这条线接到场景理解上，建出了第一个基于几何基础模型的实时、任务驱动、开放词表的层次化 3D 场景图。但它只验证了“能在遥操作的机器人上实时成图”，离长程自主任务还差三件实事：物体记忆与几何要准到能支撑抓取；地点层要能实时导航；定位要以可接受的延迟与精度支撑移动操作。这篇论文补的就是这三块，顺手把多会话建图与物体被移动的检测也接进来。

而这张图本身分三层，我认为理解它最快的方式，是把它看成三个不同粒度的“检索索引”，而不是一张越来越细的地图。

最上面是物体层，开放词表，而且它不是我一开始以为的“建图时顺便把东西都分割好存起来”。它是在查询时才从视觉记忆里抽出来的：机器人用自然语言问“易拉罐”，系统才去找、才去分割、才把它变成稠密点云存进缓存。更细的一点是粒度按任务定义——同样一片衣服，任务粗的时候可以算“一堆衣服”这一个物体，任务细的时候可以每件衣服各算一个。这个设计的好处很实际：内存与时间只花在被问过的东西上，而且换任务不需要重建图。

中间是地点层，也就是 places。它不是一张占据栅格，而是把可通行区域离散成一块块方形 tile，每个 tile 存一个 von Mises-Fisher 语义分布。语义存在 tile 上，于是“厨房”这类开放词表查询可以先命中一批语义相近的 tile，再把它们聚成区域——这就是最上面的区域层，对应房间或户外场地。

图里的颜色值得单独记一下：绿色是机器人敢走的节点，红色是危险区，黑色是终点与不可通行的地方，黄色是尚未探索。灰度散点是稀疏点云，机器人模型旁边那条黑线是规划出来的轨迹，黄色框标的是物体原来的位置，绿色框是被移动过之后的物体（图 1）。一张图里同时有“语义在哪、路怎么走、东西动过没有”三件事，这就是它和纯点云地图最本质的区别。

图 1｜工作室场景里建出来的图：绿色是机器人敢走的 tile，红色是靠近边界、障碍或终点的危险区，黑色是终点与不可通行处，配上的灰度散点是稀疏点云；黄色框是物体原来所在的位置，绿色框是被移动过的物体，黑线是规划出的到目标 D 的轨迹。

一次查询一百毫秒：从一句话到一个三维物体

查询通路不长，但每一步的取舍都值得记。底层的几何骨干是 VGGT-SLAM 2.0，一个 submap 式的稠密 SLAM：按视差挑关键帧，攒够目标数量后一起送进 VGGT，得到每帧的位姿与深度，再把深度反投影成三维重建。FOUND-IT 在这套骨干上给 VGGT 加了一个地面分割头，专门用来长出地点层。

物体查询的顺序是：用 Perception Encoder 的语义嵌入在关键帧里找余弦相似度最高的那一帧，把它交给 SAM 3 出物体掩码，再用这一帧估计出的深度把掩码反投影成稠密点云。单次查询大约 100 毫秒，结果进缓存，之后再问同一个物体就直接返回；如果发生回环，缓存里物体的位置也会跟着一起搬动——这一点对机载任务很关键，因为位姿修正之后，记忆里的物体不能还停在旧坐标上。

为了不让内存和时间爆掉，整张图的点云保持稀疏，只有被查询过的物体才保留稠密点。这个“稀疏底图 + 稠密物体”的分工，是这类系统能上机载算力的前提之一。机载实验里二十个物体全部检测正确（图 2 上排是这些物体在点云里的形状与包围框，黄色为原位置、绿色为被移动后；下排是它们在场景中的位置）。

还有一个副作用要提前说：物体是从单张关键帧的分割掩码升到三维的，它的边界天然带着那一个视角的误差——这一点后面讲抓取与变化检测时会重新出现。

图 2｜上排是四个物体在点云里的形状与包围框（黄色为原位置、绿色为被移动后），下排 A 到 D 是它们在场景中的位置——重排任务要搬的就是这四件东西。

为了上机器人，几何和位姿动了三处手术

这套系统能从“演示”变成“机载闭环”，靠的是三处不算起眼但决定性的改造。

**第一处是换骨干。**默认的几何基础模型换成 VGGT-Ω，并为它重新训练了地点层用的地面分割头；同时把送进模型的图像缩到 256 像素。按论文的消融，这一步换来的是速度上的实质提升，而精度只降了一点：在 Replica 上跑完整场景图管线，同一块 3090 上，用 VGGT 的版本是 5.5 fps、用 VGGT-Ω 的默认版本是 8.2 fps，作者把这写成“49% 的速度提升”。

**第二处是回环 submap 从两帧扩到四帧。**原来的回环只用查询帧和被检索到的帧；但实践中这两帧可能视差很小，几何基础模型的估计会退化。于是改成除了这两帧，再各自补上最近的一个关键帧，给模型更好的多视角上下文。这个改动很小，但它修的是一个会静默出错的路径。

第三处是位姿频率与尺度。跟轨迹需要高频位姿，而基础模型的位姿是“每处理一个 submap 才出一批”。做法是把上一个 submap 里最近关键帧的位姿用轮式里程计前向传播出去，并明确这些位姿不进 VGGT-SLAM 2.0 的因子图——只用于跟轨迹，不污染优化。尺度是另一件事：单目图天生没有米制尺度，作者用出发后前三米行程里视觉位姿与轮式里程计位姿的差估出缩放，把整张图拉到米制。

我最认可的是第三条的分工：里程计只承担“高频”，不承担“精确”，因子图只吃视觉估计。这种把两种传感器各自放在擅长位置上的写法，比“把里程计因子也塞进优化里”稳得多，也解释了为什么加了这么多功能，位姿精度只差半厘米。

地点层的四色分类：把“可通行”变成“敢走”

如果这篇论文只让我带走一个设计，我会选地点层的分类。原来的 FOUND-IT 只记录“可通行”的区域，也就是地面被观测到、没有明显障碍的地方；但对一台有体积的移动操作机器人来说，“可通行”和“我敢开过去”是两件事——桌子边缘和门框之间的缝，人可以看见是空的，机器人开过去会撞。

FOUND-IT++ 把每个 place 节点分到四类之一：terminal（黑）、unexplored（黄）、hazardous（红）、safe（绿）。判定顺序是：先判 frontier，邻居少于五个、或者到邻居的边之间的最小夹角大于 100 度（也就是在图的外边界上），就算 frontier 节点；frontier 节点如果靠近点云边界就算 terminal，否则算 unexplored。非 frontier 的节点，只要它到任意一个 frontier 节点的距离小于 d_robot 就判为 hazardous，否则为 safe。本文里 d_robot 取 45 厘米，对应机器人尺寸给出的安全半径。规划只在 safe 节点上做。

我认为这个 45 厘米是全文最划算的一个数字。它没有引入新的传感器、也没有改优化，只是把机器人的物理尺寸塞进了图的节点标签里，于是一张纯几何的地面图立刻变成了“可导航性图”。图里红色危险区沿着每一张桌子的边缘铺开那一圈，就是这 45 厘米被显式画出来的样子（图 3）。

地点层还有两个必须修的毛病。一是原版不能删 tile，而 submap 是在局部观测下建出来的，后面的视角可能看到新障碍、把已有节点变得不可通行；现在的做法是每次规划都对整张图重算被遮挡的 tile（把三维点投影进 tile 判碰撞），而不是只在单个 submap 内检查。二是合并与建边原来解耦：两个相邻的已有节点可能因为后续节点都并进了别处而一直不连通。现在存活节点会继承被合并节点的边，语义统计仍归最老的节点，但拓扑边继承使用全部可用邻居。

图 3｜五个场景中的两个：places 层被离散成四色方块，机器人模型旁边的黑实线就是 Dijkstra 在安全节点上算出的轨迹，A 到 D 是四个被文本查询到的物体。

图怎么更新：把整张图存下来，把时间压进 submap

长程任务绕不开两件事：一次建不完的图怎么续，以及场景变了怎么知道。这两块 FOUND-IT 之前都没做。

多会话建图的做法很干脆：整张场景图（包括物体缓存）可以直接存盘，之后机器人把会话加载回来、接着建图，系统会把当前图锚定到一个任意参考上，一旦检测到当前图与已存会话之间的回环，就用这个回环把当前图配准到已存会话上。代价写得很清楚：每个会话约 520 MB，其中 230 MB 是关键帧、存在磁盘上，所以加载一个会话大约需要 290 MB 内存。橙色第一段、蓝色第二段的那张拼图就是这么来的（图 4）。

变化检测是这套系统里我最想抄的一段，因为它几乎没花额外的成本。首先是任务驱动：只有与机器人任务相关的物体才检测变化。论文举的例子很到位——一台做车间维护的机器人需要跟踪工具的变化，但可能不关心工作台上的纸张有没有被翻动。所以要检测什么，本身就是任务给定的。

具体分两类。检测“消失”：对缓存里的每个物体，把它的包围框角点投影到当前相机视角，看它理论上该不该出现在画面里；如果该出现，就用它的标签在当前帧上问一次 SAM 3，检不到就判为消失。**检测“新增”**难一些，因为机器人不知道新东西在哪：给每个 submap 打上时间戳，对缓存里每一个文本查询记住它最后一次被查询的时间，只在此后新建的 submap 里检索——关键帧按与查询的余弦得分排序、跳过已经看到过缓存物体的帧、跑 SAM 3 判断有没有新检测，一旦检不到就停止搜索。

论文特意强调这套方法不需要真值掩码、不需要深度输入、也不需要复杂的时序物体跟踪。我认为“把时间戳压进 submap”这个动作是这里最省的一步——RGB 帧本来就要为底层 SLAM 存在磁盘上，于是时间维度的增量检索几乎免费。

图 4｜两次建图会话拼成一张图：橙色是第一段轨迹，蓝色是隔一段时间重新加载会话后的第二段轨迹，两段在检测到回环后对齐成全局一致的图，物体缓存也随之搬过去。

策略怎么从图里取信息：终点、路径、抓取点

图最终要落在三个消费者手里：任务层选目标、规划层出路径、抓取层出点云。论文里的分工很清楚。

选目标可以用区域层。演示里机器人被要求去“休息区（Lounge Area）”，系统先按语义查询把该区域的 tile 找出来，再在其中取一块中心的安全 tile 作为终点，然后规划并走过去（图 5 里蓝色 tile 就是命中的区域，虚线是生成的轨迹，下方两张分别是出发点和抵达现场）。这里没有额外的房间标注，终点是从图里算出来的。

出路径是在地点层上用 Dijkstra 搜，跟踪用改造过的纯追踪（pure pursuit）平滑跟航点。

抓取点这一段最能体现“图给目标、观测给几何”的思路：机器人走到目标附近后，并不直接拿全局图里那份物体点云去抓，而是在当前帧重新用 SAM 3 查一次这个物体，得到一份局部点云——对全局漂移更鲁棒，但仍依赖系统把二维掩码升到三维。拿到点云后走解析式对跖抓取：算法向、采样夹爪面垂直于某个法向的构型、剔除与物体或地面相交的候选、按“朝上优先、易够到优先”打分，最后用阻抗控制沿平滑任务空间轨迹、经过预抓取位姿执行。

闭环细节也写得很实：到达抓取或放置位置时会强制触发一次回环，把自身位置修正到距物体 45 厘米的目标距离；抓取失败会自动重试；执行中如果检测不到物体，会后退 2 厘米重试，或者退回使用缓存里的点云。这些兜底动作在论文里只是一句话，但它们是“50% 抓取成功率”这个数字能出现在一张还能跑完十次任务的表里的原因。

图 5｜机器人被要求去“休息区”：蓝色 tile 是语义查询命中的区域，虚线是自动生成的轨迹；下方两张是出发点 A 与到达后的休息区 B，终点取该区域内一块中心安全 tile。

十次重排任务：七道关卡，每一道都有数字

整机实验的平台是 Cobot Magic 移动操作机器人，FOUND-IT++ 跑在机载的 Jetson Thor 上，submap 大小固定为 8，所有机载实验共用同一套参数。任务是被移动物体放回原位：先遥操作建图，然后查询一组开放词表物体，接着由实验者交换两件物体的位置，剩下的全部自主——机器人依次巡查缓存里的物体、判断哪些消失了、再去找新增的位置、抓起来、送到原位置放下。

规模是五个场景（Office Lounge、Lobby、Living Room、Office、Workshop），每个场景四件物体，合计二十件不重复物体；每次任务实验者交换两件，每个场景跑两遍，于是二十件物体各被搬动一次，共十次任务。每次重排需要八次导航：四次巡查缓存物体、两次去抓、两次去放。

结果按环节拆开，这张表我认为是全文最有价值的一张：

环节	成功率	成功/总数
地点层规划与导航到物体	100%	76/76
到达物体（最终接近）	84%	64/76
查询物体（全部缓存成功）	100%	40/40
检测消失	100%	20/20
检测新增位置	90%	18/20
抓取	50%	9/18
放置	94%	17/18

读这张表要按环节顺序读。规划与导航是满分：地点层给出的路径在 76 次里全部被走通，作者归功于四色分类 + 安全半径这套设计。掉到 84% 的是“到达物体的最终接近”，典型失败是机器人离桌子太近；根因是单目 submap 系统拿不到高频深度做局部障碍检测——不是规划错了，是执行时最后一米没有近距感知。查询 40/40、检测消失 20/20、检测新增只错两次。抓取掉到一半，原因同样是缺少主动深度形成的抓取闭环，加上抓取策略比较简单。

我特别想强调一个容易被忽略的细节：抓取的分母是 18 而不是 20，放置的分母也是 18。也就是说，这两项统计的是“真的走到了抓取那一步”的次数，而不是全部任务。把分母写清楚这件事本身，就比只报一个“任务成功率”诚实得多。五个场景里的另一个证据是：不同户型下图的样子差别很大，安全通道的宽窄、危险区围着桌子的形状都不一样，但轨迹都能算出来（图 6 是其中另外两个场景）。

图 6｜另外两个场景：绿色安全区只长在障碍之间留出的通道上，红色危险区沿着每张桌子的边缘铺开，这条边界就是机器人尺寸 45 厘米的余量被显式画进图里的结果。

三张基线表：一次换速度，一次换精度，一次换两样

除了整机任务，论文还有三组定量对照，各自回答一个不同的问题。

变化检测用 3RScan 的验证集，110 对室内场景，对照一个同目标的开源方法。为了只考变化检测本身，两边都给了真值位姿与深度。只统计“出现过的物体”，判定为真阳的条件是识别正确且估计位置在真值质心一米以内。“Where’s-my-glasses”的召回是 0.228、精确率 0.062，FOUND-IT++ 是 0.408 和 0.064——召回接近翻倍，精确率几乎持平。精确率两边都低，作者给的原因是：大件家具会被识别成多个物体，从而登记出虚假的变化。

语义物体检测在 Replica 的八个场景上，跑的是完整场景图管线（几何、物体、地点、区域全算进去），同一块 3090 上比：

方法	mAcc	F-mIoU	fps
FOUND-IT	59.00	57.86	6.3
FOUND-IT++（VGGT）	57.49	56.63	5.5
FOUND-IT++（VGGT-Ω，默认）	55.05	53.58	8.2
FOUND-IT++（VGGT-Ω + 轻量视觉编码器）	48.67	52.08	9.8

这组数字的读法是“用一点精度换速度”。同一套 VGGT 下，加了那么多功能之后 mAcc 从 59.00 掉到 57.49、fps 从 6.3 掉到 5.5；换成 VGGT-Ω 后 fps 升到 8.2、mAcc 掉到 55.05。表里还有一行更快的配置（换轻量视觉编码器，9.8 fps），作者明说不设为默认，因为物体检测稳健性不如原来。另外要记住：FOUND-IT 与 FOUND-IT++ 是这张表里唯二不用真值位姿与真值深度的方法，其余数字不是同一条件下得到的。

位姿在 TUM RGB-D 上做消融，只跑几何部分、关掉物体层与地点层，同一块 3090 上比绝对轨迹误差的平均值：MASt3R-SLAM 0.060 米 / 7.2 fps，VGGT-SLAM 2.0 0.041 米 / 8.4 fps，FOUND-IT 0.030 米 / 6.4 fps，FOUND-IT++（VGGT）0.035 米 / 6.2 fps，FOUND-IT++（VGGT-Ω）0.054 米 / 19.5 fps。

结论有两层。第一层：同一套几何基础模型下，FOUND-IT++ 与 FOUND-IT 的平均误差只差半厘米——说明为机载集成加的那些特性（四帧回环、里程计传播、全图重算 tile）没有拖累精度。第二层：换 VGGT-Ω 换来约三倍速度，代价是平均位姿误差从 3 厘米量级退到 5 厘米量级。这个交换值不值取决于任务：导航够用（tile 边长远大于 5 厘米），抓取则要靠前三米那一次尺度标定与抓取前的局部重查兜底。

我认为最有价值的发现

这篇论文真正有价值的发现不是“场景图能支撑移动操作”这个结论，而是它把这句话拆成了可核对的环节，并且显示出各环节与表示层之间的结构性对应。

具体说：凡是只依赖“图里有没有这条信息”的环节，成功率都接近满分——规划与导航 76/76、物体查询 40/40、检测消失 20/20。凡是依赖“执行时还要有另一样东西”的环节，成功率就掉下来——最终接近 84% 和抓取 50% 都卡在同一件事上：单目 submap 系统拿不到高频深度来做局部闭环。而检测新增的 90%，掉的那两次也与几何估计的精度有关。

换句话说，这张图的上限不是由图的表达能力决定的，而是由“哪一层信息能被下游以什么频率、什么精度拿到”决定的。这个判断对做系统的人很好用：如果你的机器人已经有深度或双目，这张图的语义层可以直接用，掉分的两环会明显好转；如果你坚持单目，那么设计验收指标时就必须把“接近”和“抓取”单独列出来，否则一个笼统的任务成功率会把这 50% 藏起来。

另一个我很认可的处理是：论文没有把变化检测做成一个追求真实感的完整系统，而是给出了一个“投影 + 同标签复查”的最小实现，然后在标准数据集上用与基线相同的输入条件比召回。这个做法把“方法有效”和“端到端系统很强”这两件事分开了，读者能各取所需。

适用边界：作者自己划的三条线

论文在讨论部分主动交代了这套表示作为机器人空间记忆的短板，我认为写得比多数系统论文都实在。

**第一条是局部避障。**单目 submap 系统没有高频深度，作者说这是它观察到的主要缺点，直接后果就是接近物体时偶发碰撞（对应表里 84% 的到达成功率）。补救方向有两条：直接用深度；或者在当前 submap 上做局部的避障与重规划，继续留在单目体系内。

**第二条是尺度漂移。**它同时限制能建多大的场景和抓取时点云的精度——抓取需要尺度准确的点云。当前的补法是抓取前用三米行程的轮式里程计与视觉位姿求缩放；另一条思路是利用机器人已知的 URDF，从相机离地高度反推米制尺度，但作者指出这会把地图的误差耦合进最终点云。

**第三条是语义推理的视角限制。**图里能做的推理是有限的：给定物体位置与包围框，可以回答“遥控器是否在柜台上”这类关系问题；但系统在语义上只用单张图像——一次 SAM 3、或者一次视觉语言模型——而人可以把多个视角紧耦合在一起推理。作者把这句写成了开放问题，而不是当成已解决。

还有几处边界适合我自己补上。实验全在室内五个场景、二十件物体上做，论文未给出户外、大尺度或强动态场景的结果。变化检测那一组为聚焦方法本身给了真值位姿与深度，所以 0.408 的召回不是端到端数字。抓取 50% 是在简单策略、没有主动深度闭环下的数字，作者也说抓取本身不是重点。另外“第一个能在机器人本体上跑的基础模型驱动 3D 场景图”是论文自己的表述，对应的是这类表示的机载闭环，不是场景图方向本身。

我读完之后的几点提炼

**第一，按消费者设计图的接口。**这套系统里最有效的两个设计都不是“建图更准”，而是“给下游省事”：给规划器的是四色节点标签（能不能走），给抓取器的是当前帧重查出来的物体点云（准不准）。如果你的图只交付一个统一的点云加语义，下游每一步都要自己重新判断一遍，误差会层层叠加。

第二，变化检测可以极便宜地做。“把缓存包围框投影到当前帧，再用同一个标签问一次分割模型，检不到就算消失”这个套路，几乎不需要额外基础设施：帧本来就在磁盘上，标签本来就有，分割模型本来就在管线里。做长期部署的团队可以直接照搬这个思路，再按任务决定要不要跟踪“新增”。

**第三，尺度是单目方案躲不开的隐藏成本。**只要下游有抓取，图就必须是米制的。这篇的做法是把尺度标定藏进正常行驶的前三米里，用轮式里程计做一次性对齐——不增加任何额外动作，也不往优化里塞因子。这个模式适用于任何“已有里程计的单目系统”。

**第四，验收指标要拆到环节，并且把分母写出来。**76/76、40/40、20/20 与 9/18 放在一张表里，读者立刻知道瓶颈在抓取而不在地图。如果只报一个十次任务成功几次，这张表承载的信息会全部消失，而恰恰是这些分环节的数字，才让人相信那张图是真的可用的。

结语

这篇论文做的其实是一次交付验收：把一张“能实时建出来”的场景图交到真实机器人手上，让它自己找物体、判断变化、走过去、抓起来、放回去，并把每一步的成功率摆出来。结果是这张图在最依赖“结构”的环节上满分，在最依赖“近距感知”的环节上只剩一半。这个分布比任何单一的“可行”结论都有用：它告诉你这类空间记忆现在能承担什么，以及下一步该把算力和传感器加在哪儿。