空间记忆与地图表示调研报告：从绝对坐标到相对空间关系

Runqing Xu  |  2026年7月2日（2026-07-07更新第九节）

一、调研背景与目标

在具身智能体的室内导航任务中，基于绝对坐标的空间理解体系面临固有局限：对建图精度高度依赖、难以处理动态环境变化、且与自然语言指令之间存在语义鸿沟。相比之下，人类主要依靠周围物体和空间关系（如"桌子旁边"、"厨房对面的房间"）来理解和描述位置，这种相对空间关系理解体系更具鲁棒性和灵活性。本报告围绕"如何从绝对坐标体系转向相对空间关系体系"这一核心问题，从语义地图表示、空间认知定位、Planner消费模式、空间关系建模、代表性系统五个方向，调研了15篇代表性工作。

本报告系统调研了15篇代表性工作，覆盖语义地图与embedding表示（ConceptGraphs、VLMaps、CLIP-Fields）、空间认知与非几何定位（SceneGraphLoc、RoboHop、SPACE Benchmark）、Planner消费地图（SayPlan、SG-Nav、MapGPT、MapNav）、空间关系建模（SpatialVLM、SR-Nav、HRON）、代表性端到端系统（3D-Mem、ESCA）五个方向，为技术选型和系统设计提供决策依据。

---

二、核心结论

问题1：有没有不依赖传统地图或精确坐标的空间表示方案？

结论：有，且已形成三条成熟技术路线。

• 路线A：语义embedding地图。 VLMaps将CLIP/LSeg的稠密pixel embedding融合到2D栅格地图中，每个栅格存储连续语义向量而非离散标签，支持开放词汇查询（pixel accuracy 92.3%）。CLIP-Fields更进一步，用隐式神经场将CLIP+SBERT embedding编码到3D坐标上，理论上支持任意精度的连续3D查询。两者均不依赖预定义类别，查询时只需计算文本embedding与地图embedding的相似度。
• 路线B：物体级3D场景图。 ConceptGraphs以物体为节点、空间关系为边构建图结构，每个节点携带CLIP特征、自然语言描述和3D包围盒。节点级粒度相比逐像素表示大幅降低存储开销，图结构天然编码"on"、"in"、"next to"等相对空间关系。SG-Nav在此基础上增加了group和room两个层级，形成object-group-room三层结构。
• 路线C：纯拓扑图。 RoboHop和MapGPT证明了完全不需要3D坐标也能支持导航——RoboHop以图像segment为节点、帧内/帧间关联为边构建纯拓扑图；MapGPT将拓扑连接关系表述为"Place X is connected with Places Y, Z"的自然语言，完全去坐标化。MapGPT的消融实验明确表明：引入GPS坐标反而降低性能（SR从44.9%降至41.2%），而纯拓扑文本地图带来显著提升。

问题2：有没有基于空间认知而非几何定位的方案？

结论：有，但必须清醒认识VLM空间认知能力的严重不足。

SceneGraphLoc证明了场景图可以作为极其紧凑的定位参考——仅5.4MB存储即可替代5720.3MB的图像数据库，存储压缩1000倍，检索速度快1000倍以上。RoboHop更激进地证明了纯拓扑表示（无任何度量坐标）即可支持导航规划。

但SPACE Benchmark（ICLR 2025）揭示了一个结构性问题：该基准测试时的前沿VLM（GPT-4o、Claude 3.5 Sonnet等）在第一人称视角下的大尺度空间认知任务中接近随机水平（GPT-4o仅23.0%，chance为15.0%）。Mental rotation、perspective taking等核心空间认知能力均接近随机。尽管此后模型能力有所提升，但这一结论指向的是VLM架构层面的固有短板——空间认知并非简单的语义理解，而需要专门的空间推理机制。因此，不宜将空间推理直接委托给通用VLM，应当构建显式的外部空间表示作为辅助。

一个重要发现是：VLM在纯文本呈现下的空间认知显著优于多模态呈现（Claude 3.5: 文本64.5% vs 多模态43.8%），这为将空间信息结构化为文本/符号表示后再交给LLM处理的技术路线提供了有力支持。

问题3：Planner如何利用地图？

结论：主流消费模式有四种，文本序列化是当前最优解。

SayPlan的collapse-and-expand机制特别值得关注：通过层级折叠将6731 tokens压缩至878 tokens（压缩86.9%），在保证LLM可消费性的同时解决了大场景的扩展性问题。SG-Nav的层级Chain-of-Thought prompting证明了结构化场景图比扁平文本列表更有效（SR提升+3.7%）。

MapNav提出了一个值得关注的思路：在语义地图上叠加物体名称的文字标注以提升VLM的理解能力。但需注意，该工作在实际复现中效果远低于论文报告的数值，其方案更适合作为思路参考而非直接工程借鉴。

问题4：如何建模空间关系（前后左右相邻连通）？

结论：多维关系编码（拓扑+方向+距离）效果最佳，拓扑关系是最关键的维度。

SR-Nav的DSRG提出了最完整的空间关系编码方案，同时编码三种维度：拓扑关系（包含、连接）、方向关系（相对角度方位）、距离关系（欧氏距离量化）。消融实验表明拓扑关系对性能影响最大（去除后SR降5.6%），距离次之（降2.3%），方向最小（降1.0%）。

SpatialVLM通过20亿条自动生成的spatial VQA数据训练VLM，使其具备定性空间判断能力（75.2% accuracy），证明了"A在B左边"等定性描述的可行性。但定量距离估计精度有限（仅37.2%在GT的半到两倍范围内），不足以支撑精确控制。

HRON的层次化关系设计（object-onTop/inside/under-furniture-inRoom-room-roomConnected-room）为我们提供了可直接借鉴的关系谓词体系。其实验证明：场景图+任务驱动注意力的SR（0.879）远超2D语义地图（0.554），为场景图路线提供了定量支撑。

问题5：代表性系统总结

系统一：SG-Nav（在线场景图 + 层级CoT导航）

SG-Nav是将场景图与LLM结合进行导航的最完整工程落地方案。感知端在线构建object-group-room三层场景图，增量式更新边关系；决策端将场景图切分为子图，通过层级Chain-of-Thought引导LLM逐层推理目标位置；验证端通过Re-perception机制利用场景图上下文过滤检测误报。在三个benchmark上以zero-shot方式超越此前所有zero-shot方法（MP3D SR 40.2%，超越supervised方法SemEXP的36.0%）。

系统二：SR-Nav（空间关系图 + 双模块协同）

SR-Nav将空间关系建模提升到最高水平。其DSRG融合LLM生成的经验性空间先验与在线感知观测，同时服务于感知校正（RAMM模块通过空间关系一致性检验甄别FP/FN）和导航规划（DRPM模块将关系路径转化为语义导航线索）。在HM3D上达到58.3% SR，比SG-Nav高4.4%，同时推理速度快8.7倍。

系统三：3D-Mem（视觉快照记忆 + VLM直接推理）

3D-Mem挑战了场景图范式，提出用精选的多视角快照图像替代图结构作为空间记忆。通过Co-Visibility Clustering选出信息密度最高的代表帧，让VLM直接在图像上推理空间关系。在需要精细空间判断的任务上（如"扶手椅前方是否有足够空间"）显著优于ConceptGraphs的文本化场景图（spatial understanding: 43.4 vs 32.9）。

---

三、全景对比

---

四、方向1：语义地图与embedding表示

4.1 问题定义

传统语义地图将每个栅格标注为预定义类别集合中的离散标签（如40类Matterport类别），这种封闭词汇的表示无法应对开放世界中的新物体和新概念。方向1探索的核心问题是：如何构建一种语义丰富、支持开放词汇查询、且能有效服务于下游规划任务的空间表示？

4.2 现有方案对比

三者构成了一条清晰的演进线索：VLMaps的2D像素级栅格 -> CLIP-Fields的3D点级神经场 -> ConceptGraphs的3D物体级场景图，表示粒度逐步提升，从稠密底层特征走向结构化高层语义。

4.3 系统设计启示

1. 推荐采用ConceptGraphs的物体级场景图路线。 物体级粒度与人类的空间认知方式最为接近——人类记住的是"桌子上有杯子"，而非"坐标(3.2, 5.1)处有embedding向量"。图结构天然支持相对空间关系的编码，且JSON序列化后可直接供LLM消费。
2. 保留VLMaps的embedding查询能力作为底层检索引擎。 当需要回答"哪里有红色的东西"这类细粒度查询时，embedding相似度检索比遍历场景图节点描述更高效。可以在场景图节点中保留CLIP embedding作为属性。
3. CLIP-Fields的隐式表示不适合在线场景。 场景级训练无法支持增量更新，且查询需要遍历全场景点，不适合实时系统。但其"将多模态embedding编码到空间坐标"的理念可以借鉴。

4.4 推荐关键图

---

五、方向2：空间认知与非几何定位

5.1 问题定义

传统定位方案依赖精确的6DoF位姿估计和大规模图像/点云数据库，存储和计算代价高昂。方向2探索的问题是：能否像人类一样，通过识别周围物体和理解空间关系来判断"我在哪里"，而非依赖精确坐标？更根本地，当前的VLM到底具备多少空间认知能力？

5.2 现有方案对比

5.3 系统设计启示

1. SPACE Benchmark的结论是最重要的警示：不能将空间推理委托给VLM。 所有前沿VLM在egocentric image模式下的大尺度空间认知接近随机水平。这意味着必须构建显式的外部空间表示（场景图或拓扑图），而非期望VLM通过"看"就能理解空间。
2. 文本/符号表示优于视觉表示。 SPACE的数据清晰表明，将空间信息结构化为文本后再交给LLM，效果显著优于直接输入图像。这直接验证了通过场景图等符号化表示来桥接VLM与空间推理的技术路线。
3. RoboHop的纯拓扑方案可作为轻量级备选。 在不需要精确位置但需要快速部署的场景中，RoboHop的segment-as-node拓扑图提供了一种零样本、不需要训练策略的导航方案。
4. SceneGraphLoc的多模态融合框架值得借鉴。 其将几何（点云）、语义（类别、属性）、拓扑（关系）和视觉（图像）信息融合到统一的节点embedding中的设计，为构建丰富的空间表示提供了参考。

5.4 推荐关键图

---

六、方向3：Planner如何消费地图

6.1 问题定义

构建好的空间表示如何被Planner有效消费，是决定整体系统性能的关键接口。方向3探索的问题是：LLM/VLM-based Planner应该以什么形式接收空间信息？文本序列化、视觉输入、代码生成、还是其他方式？

6.2 现有方案对比

四种消费模式的核心差异在于信息传递的"接口层"：SayPlan和SG-Nav通过文本序列化保留了图结构信息；MapGPT彻底去结构化，只保留拓扑连接的文本描述；MapNav则走视觉路线，让VLM直接"看"地图图像，但其实际复现效果不佳，"文字标注提升VLM地图理解"的思路仍有价值，工程落地需谨慎。

6.3 系统设计启示

1. 推荐采用分层文本序列化作为主消费接口。 SG-Nav的实验证明层级CoT比扁平文本列表提升3.7% SR，SayPlan证明层级折叠可将token压缩86.9%。
2. MapGPT的去坐标化提供了有力的实验支撑。 坐标输入反而降低性能（SR降1.4%）的实验结果，表明从绝对坐标向相对空间关系转型在技术上是合理的。
3. MapNav的文字标注思路可作为参考。 在顶视图上叠加物体名称文字标签的方向是合理的，但该方案在实际复现中效果有限，不宜直接采信论文数据，需结合具体场景验证。
4. 迭代验证机制是保证可执行性的关键。 SayPlan的Scene Graph Simulator验证+迭代重规划将长程任务可执行率从13.3%提升到86.6%。

6.4 推荐关键图

---

七、方向4：空间关系建模

7.1 问题定义

从绝对坐标转向相对空间关系，核心技术挑战是：如何有效建模前后、左右、相邻、连通、包含等空间关系？这些关系应以什么形式编码，以便被Planner消费？VLM能在多大程度上理解这些关系？

7.2 现有方案对比

7.3 系统设计启示

1. 采用SR-Nav的三维关系编码方案。 拓扑关系（包含、连通）+ 方向关系（相对方位）+ 距离关系（粗略量化）的三元组表示，与类人空间理解的目标高度契合。
2. LLM先验+在线更新的双源融合策略可直接复用。 在进入新环境前，用LLM生成目标物体的空间关系先验，然后在探索中用实际观测逐步修正。
3. HRON的实验为场景图路线提供了定量支撑。 场景图+任务驱动注意力（SR 0.879）远超2D语义地图（0.554），且纯场景图无注意力（0.458）反而不如无场景图（0.586），说明信息过滤机制至关重要。
4. SpatialVLM证明了定性空间推理的可行性但定量精度不足。 "A在B左边""A比B高"等定性描述可以作为有效的空间表征（75.2% accuracy），但距离估计精度有限。

7.4 推荐关键图

---

八、方向5：代表性端到端系统

8.1 问题定义

上述四个方向分别解决了空间表示、认知定位、Planner消费和关系建模的子问题。方向5关注的是：当这些模块组合为端到端系统时，哪些是真正的瓶颈？场景图是否是最佳方案？

8.2 3D-Mem：挑战场景图范式

3D-Mem对场景图提出了有力的质疑：当需要回答"扶手椅前面是否有足够空间放咖啡桌"时，场景图只能提供"chair near sofa"这样的粗糙文本，无法度量空间余量或判断朝向性关系。3D-Mem的替代方案是：通过Co-Visibility Clustering选出信息密度最高的多视角快照图像，让VLM直接在图像上进行视觉推理。

实验表明，3D-Mem在spatial understanding类问题上显著优于ConceptGraphs（A-EQA: 43.4 vs 32.9），在GOAT-Bench终身导航上SR达69.1%。但3D-Mem并非完全抛弃结构化信息：它仍然维护底层物体集合作为索引，本质上是"结构化索引+视觉快照"的混合架构。

8.3 ESCA：感知是瓶颈而非规划

ESCA提供了最具冲击力的实证发现：在60个EB-Navigation任务中，69%的失败源于感知错误（hallucination + 误识别），仅11%源于推理错误，20%源于规划错误。引入ESCA的结构化scene graph增强后，感知错误降至30%，InternVL-2.5（开源38B）的性能超越了GPT-4o基线。

ESCA的核心设计是Selective Grounding：不将完整scene graph注入MLLM（这可能反而降低性能），而是根据任务instruction选择性地提取相关子集。

8.4 系统设计启示

1. "场景图+视觉快照"的混合架构是最佳方案。 3D-Mem证明了视觉快照在精细空间推理上的优势，但场景图在跨区域推理、长程规划和快速检索上不可替代。
2. 优先投入感知模块的改善。 ESCA的69%感知错误比例表明，在Planner不变的情况下，改善感知能力的ROI远高于改善规划。
3. Selective Grounding原则应贯穿系统设计。 不论是场景图还是视觉快照，都不应无差别地全量传递给Planner。

8.5 推荐关键图

---

九、整体建议与实施路线

2026-07-07更新：本节新增完整证据链（9.1）与2025–2026定向补充检索（9.2）；空间表示方案（9.3）与Planner消费接口（9.4）维持原判断不变。方案落地遵循两条工程约束：其一，现有系统模块多、耦合度高，方案必须简单、零训练、可解耦；其二，MapNav经实际复现证实效果远低于论文口径，"视觉地图作为主输入通道"已被第一手实验排除。9.5–9.11为代码级落地方案：基于对HOV-SG、MoMa-LLM、SG-Nav/UniGoal、3D-Mem、SceneGraphLoc开源仓库的逐文件核查，给出关键实现问题的结论速答（9.5）、重定位实现（9.6）、三层表示的逐层落地（9.7–9.9）、消费接口实现（9.10）与实施顺序（9.11）。

9.1 完整证据链：为什么主干是文本场景图

以下五环构成从问题到选型的完整推理链，每一环由文献定量证据（以及我们的第一手复现证据）支撑。任何一环被新证据推翻，都应触发方案复审。

1. 环1：空间推理不能委托给VLM，必须外置显式空间表示。 SPACE（ICLR 2025）：前沿VLM在第一人称大尺度空间认知上接近随机水平（GPT-4o 23.0%，chance 15.0%），mental rotation、perspective taking等核心能力接近随机。⇒ 环境结构必须由外部模块显式维护，VLM只消费、不推断。
2. 环2：同样的空间信息，文本/符号呈现显著优于视觉呈现。 文献证据：SPACE中Claude 3.5纯文本64.5% vs 多模态43.8%（+20.7pt）。第一手证据：我们复现了MapNav（带文字标注的语义顶视图直接输入VLM），实际效果远低于论文报告。⇒ 主输入通道必须是文本；顶视图只作辅助通道，不作主干。
3. 环3：文本中不应放精确坐标，应放模糊的相对关系。 MapGPT消融：在prompt中注入坐标反而使SR从44.9%降至41.2%，纯拓扑文本地图最优（47.7%）；SpatialVLM：定性空间判断可用（75.2%），定量距离估计不可靠（仅37.2%落在GT的0.5–2倍内）。⇒ 给planner"连通/归属/相邻/大致方位"级别的定性关系；精确定量留在底层导航栈内部，不进prompt。
4. 环4：文本形式中，层级场景图优于扁平列表和二维语义地图，且必须配任务过滤。 HRON：场景图+任务驱动注意力SR 0.879，远超二维语义地图0.554；但无过滤的场景图（0.458）反而低于不用场景图（0.586）。SG-Nav：层级CoT较扁平文本+3.7pt（MP3D 40.2%超越supervised方法SemEXP的36.0%，HM3D 54.0%）。SayPlan：层级折叠将token压缩86.9%（6731→878），"规划-验证-重规划"将长程可执行率从13.3%提升到86.6%。ESCA：selective grounding将感知错误从69%降到30%。SR-Nav消融给出关系边优先级：拓扑（去除后SR降5.6）> 距离（降2.3）> 方向（降1.0）。⇒ 层级化、按需展开、任务过滤是设计的组成部分而非可选项；关系边优先做拓扑（房间连通、物体归属）。
5. 环5：文本场景图有两个已知短板，各有低成本兜底，不动摇主干。 短板一，精细空间判断：3D-Mem证明视觉快照优于文本化场景图（spatial understanding 43.4 vs 32.9）——兜底：节点保留代表帧，需要时回退视觉推理。短板二，感知级联：ESCA证明69%的失败来自感知错误——兜底：节点携带证据帧与置信度，错误可追溯、可校验。

9.2 定向补充检索：2025–2026文本场景图新进展

针对"文本场景图是否有更新、更好的工作"做了定向检索（2026-07）。结论：该路线仍是zero-shot具身导航的主流并持续获得顶会背书，且新工作的演进方向与本报告9.3/9.4的设计收敛——没有工作退回精确坐标或纯视觉地图路线。

采信原则（MapNav的教训）：上表数字均为论文自报。UniGoal/CogNav为顶会工作且CogNav有真机验证，可信度较高；MSGNav/KeySG/Structured Interfaces为preprint且我们未复现，仅作方向参考——任何机制进入系统前先做最小复现验证。

9.3 选定的空间表示方案

维持v1的三层混合方案不变（9.2的新工作进一步支持该设计）。落地前提是复用现有资产：HOV-SG/HMSG已产出floor-room-object层级结构与物体best_view关键帧，二维顶视图已封装为topdown skill，房间连通关系可从现有nav_graph导出——三层表示中没有需要从零新建的建图组件，唯一新增开发是"HMSG→文本序列化器 + 规则关系边"。

第一层：层级场景图（核心骨架）。 参考SG-Nav和SayPlan的设计，沿用HMSG已有的floor-room-object层级（zone层可后置）。节点属性包含语义类别、自然语言描述、CLIP embedding、置信度分数（HMSG节点已具备类别与CLIP特征）。节点间的边编码三种空间关系（参考SR-Nav）：拓扑关系（包含、连通）、方向关系（前后左右）、距离关系（近/中/远的粗略量化）——全部由包围盒几何规则计算，零训练。这种表示不依赖绝对坐标，而是用相对空间关系描述物体和区域之间的关系。

第二层：拓扑连接索引（导航支撑）。 在场景图之上维护区域间的拓扑连接关系（哪些区域可以直接通行），支持Dijkstra等经典路径规划算法；房间连通关系从现有nav_graph直接导出，无需新建。保留轻量级的度量信息（如区域间的步数/距离估计）以支持路径长度估算。

第三层：视觉快照缓存（精细推理）。 参考3D-Mem的Memory Snapshot设计，为每个功能区域维护少量代表性快照。初版直接复用HMSG节点已有的best_view关键帧（每房间1–2张），Co-Visibility Clustering选帧作为后续优化。当Planner需要精细空间判断时（如"沙发前方是否有足够空间"），回退到视觉快照让VLM直接推理。

9.4 Planner消费接口

维持v1设计。查询式接口与现有skill机制天然契合（find_object_candidates、topdown本身就是查询式工具，场景图接口与之并列注册即可）；Structured Interfaces（2025）也从文献侧印证了"按需查询优于全量序列化"的方向。本节为设计层描述，代码级实现（prompt模板、skill定义、触发规则与降级路径）见9.10。

主接口：分层文本序列化。 将场景图序列化为层级JSON，参考SayPlan的collapse-expand机制实现按需展开。默认情况下只暴露room级别的拓扑结构和当前所在room的详细内容，Planner可以通过API调用展开其他room的内容。每个物体节点的序列化格式为：{id, category, description, spatial_relations: [{target, relation_type, direction, distance}], zone, room}。

辅助接口：相对空间查询API。 参考VLMaps的导航原语设计，封装一组空间查询函数：get_objects_in(room/zone)、get_relation(objA, objB)（返回方向和距离）、get_path_between(roomA, roomB)（返回拓扑路径）、get_nearest(category, reference_object)。

回退接口：视觉快照推理。 当文本序列化的空间信息不足以支持决策时，Planner可以请求调取特定区域的视觉快照，让VLM在图像上直接推理。

9.5 落地实现总览：关键实现问题速答

9.5–9.11给出9.3/9.4方案的代码级落地设计（2026-07-07补充调研）。方法是对HOV-SG、MoMa-LLM、SG-Nav/UniGoal、3D-Mem、SceneGraphLoc等开源仓库逐文件核查，可复用代码全部定位到文件与行号。落地中需要明确的11个关键实现问题，结论汇总如下：

四个参考工作分别是什么：为什么不存在"选一个repo"的问题

若把SG-Nav、SayPlan、SceneGraphLoc、3D-Mem理解为可择一作基座的同类候选repo，会导致选型误判——四者的形态和定位完全不同：

• SayPlan（CoRL 2023 oral）：方法论文，官方从未放出代码，社区能拿到的只有论文附录里的prompt设计。"用SayPlan"实际上等于"借它的prompt结构"——而这已有现成实现：MoMa-LLM仓库的JsonLLMEnv（llm_env.py L607-680）逐字复刻了SayPlan论文第50页的prompt，是目前最接近"SayPlan代码"的公开实现。其collapse-expand思想在本方案中落成"room级摘要+按需展开"。
• SG-Nav（NeurIPS 2024）：有代码，但形态是Habitat仿真里的zero-shot ObjectNav完整策略（自带在线建图、GLIP检测、本地ollama推理），依赖栈与现有系统完全不同，不可能整体接入。正确用法是复用三小块：图→文本序列化（3行）、子图prompt、物体关系判别规则——均已定位到行号（9.7、9.10）。
• SceneGraphLoc（ECCV 2024）：有代码+预训练权重，但它是在3RScan扫描域上训练的跨模态编码器，不是即插即用的定位器。其价值第一是架构证明（场景图可以替代图像库作定位参考），第二才是可选的二期升级件（9.6）。
• 3D-Mem（CVPR 2025）：有代码；其快照选帧算法是独立文件、可整体移植，但第一版用不上——HOV-SG自带代表帧（9.9）。

9.6 重定位的实现：观测物体集×场景图匹配（sg_locate）

问题形态的界定

调研确认以下判断成立：不存在现成的端到端"二维地图+VLM"重定位路线；主流定位方案仍是点云配准/在线SLAM；重定位若依赖全量topdown，则画图困难、标注过多又会使VLM过载；VLM直接看图定位不可行（SPACE，见9.1环1）。

由此得到一个问题形态上的关键结论："让VLM将当前观测帧和二维地图对应起来"应当放弃而非增强。二维topdown和文本场景图是同源的（都由HMSG渲染/序列化而来），既然VLM读结构化文本远好于读图（SPACE：文本64.5% vs 多模态43.8%），定位就应发生在结构化一侧——topdown保留给人看和进度监督，不承担定位。

输入信息：传感上不需要任何新输入。匹配的两端是：当前观测帧经系统已有detector得到的物体集合（可用runtime context里现成的近16帧做滑窗投票，提高稳健性）× HMSG的房间-物体结构。没有第三样东西。

SceneGraphLoc与HMSG的结合：思想先用、代码后置

SceneGraphLoc具备：官方代码+预训练权重（github: y9miao/VLSG，2024-09放出权重）；五模态节点编码+图像patch↔节点对比学习；R@1 81.5%，场景图存储较图像数据库压缩约1000倍（详见SceneGraphLoc精读）。直接接入有三个障碍：

1. 编码器在3RScan/ScanNet域上训练，迁移到实际部署场景有域差，效果需重新验证；
2. 它要求的节点输入（逐物体点云、图像patch、属性/关系标注）与HMSG字段不一致，需写适配器；
3. 引入训练/权重栈，违背本方案"零训练、可解耦"的第一原则。

第一版：零训练的sg_locate（约1天，实现SceneGraphLoc的架构思想）

1. 当前帧（或近N帧）detector输出物体集合O；
2. 对每个房间r打分：score(r) = α·类别重合(O, objects(r)) + β·CLIP相似度。类别重合采用TF-IDF式加权——稀有物体权重高（"冰箱"比"椅子"更能定位）；CLIP相似度用检测crop的embedding×节点embedding（HMSG已存，零新增计算源）；
3. 近N帧投票+连续性先验（上一次定位的房间及其连通邻居加分，复用9.8的房间图）；
4. 输出："you are in kitchen (floor 0), near fridge and sink"+置信度；低置信时如实返回"不确定，候选kitchen/dining room"，交给planner决定下一步（原地转身补观测，或调topdown人工确认）。

二期（若房间级精度不够）：写HMSG→VLSG输入格式的适配器，用其预训练编码器离线评测R@1，达标再上线做patch-to-node精匹配。

能力边界：sg_locate回答"在哪个房间、哪些物体附近"——即重定位目标"判断自身坐标或相对位置"中的后者；米级位姿仍由里程计/建图负责，不由VLM或匹配器估计。

与其他层的关系：重定位不是独立模块，它就是文本场景图上的一个查询（sg_locate skill，见9.10），复用9.8的房间归属函数，零新增数据结构；工作量并入9.11步骤5。

9.7 第一层落地：文本序列化器与节点schema

检索结论：没有现成repo，但缺口很小

经定向检索+逐仓库源码核查，不存在"基于HOV-SG改的、已实现图→文本序列化"的现成开源项目。HOV-SG官方库中LLM只用于两处：把用户指令解析成(floor, room, object)三元组（parse_hier_query），以及从物体列表推断房间类型；场景图本身从不进入LLM上下文，检索靠CLIP相似度逐层匹配。

但这不是坏消息——核查SOTA代码后发现，"图→文本"这一步在所有开源实现里都非常小。SG-Nav/UniGoal（同一作者组，代码相同）的完整实现只有3行：

# SG-Nav scenegraph.py L67-70 / UniGoal src/graph/graph.py L86-89
def graph_to_text(self, nodes, edges):
    nodes_text = ', '.join([node.caption for node in nodes])
    edges_text = ', '.join([f"{edge.node1.caption} {edge.relation} {edge.node2.caption}" for edge in edges])
    return f"Nodes: {nodes_text}. Edges: {edges_text}."

价值大的不是这几行，而是围绕它的子图选择、层级组织、prompt骨架——这些都有可复用对象：

落地方式：新写hmsg_serializer.py（约200行，独立纯函数模块）

不适配任何外部仓库，直接新写：

1. 输入：HOV-SG已落盘的graph/floors|rooms|objects/*.json+graph/nav_graph/global_nav_graph_graph.json（HOV-SG用nx.node_link_data存的标准JSON，navigation_graph.py L1228-1240）；
2. 处理：丢弃embedding/点云字段→计算规则关系边（物体归属房间已有；物体间near/on由包围盒vertices几何判断）→拼装层级JSON；
3. 输出（默认room级折叠，即9.4主接口的具体化）：

{
  "floors": [
    {"floor_id": 0, "rooms": [
      {"room_id": "0_3", "name": "kitchen",
       "connects_to": [{"room": "0_5", "via": "doorway", "distance": "near"}],
       "objects_summary": "fridge, sink, 2 chairs, dining table",
       "objects": "<按需展开：[{id, name, relations:[{target, type}]}]>"}
    ]}
  ],
  "inter_floor": [{"from": 0, "to": 1, "via": "staircase", "position_hint": "room 0_1"}]
}

4. 暴露为查询式skill（与find_object_candidates、topdown并列注册），即9.10的sg_query(scope="summary"|room_id, expand, include_snapshot)。

工作量约1–2天，比读懂并适配任何一个外部仓库都便宜，且不与建图代码产生耦合（单向读json）。

节点的定义：参考工作对比与本方案schema

SG-Nav和SayPlan的"节点"不是同一种东西，也都不等于本方案需要的节点——这是"选哪个repo"不成立的根本原因：

本方案的节点/边schema（即序列化器的输出契约）：

floor 节点  {floor_id, name: "floor 0"}
room 节点   {room_id: "0_3", name: "kitchen"（由物体清单推断，可人工校正）,
             floor_id, objects_summary: "fridge, sink, 2 chairs",
             connects_to: [...], snapshots: [快照索引，见9.9]}
object 节点 {object_id, name（开放词汇类别）, room_id,
             relations: [{target, type: near|on|above|under}],
             best_view: {快照索引，见9.9}, confidence}
不进文本、只留在 meta：CLIP embedding、包围盒 vertices、点云、位姿坐标

边只有三类：①层级归属floor⊃room⊃object（HMSG create_graph已有）；②房间连通connects_to（doorway/staircase，9.8派生）；③物体空间关系relations（包围盒几何规则：水平距离阈值→near，垂直相接且投影包含→on/above/under）。对应SR-Nav三类关系中优先级最高的拓扑+粗方向（9.1环4的消融依据）。

高度的处理：不需要把二维拓扑扩展为三维拓扑。高度在两处已天然存在：物体包围盒本来就是3D的（vertices 8点），on/above/under直接由高度差规则算出；可通行拓扑保持"每层一张2D Voronoi图+楼梯边"的2.5D结构（HOV-SG已实现，见9.8）。把可通行拓扑升到三维体素只在自由飞行（无人机）场景才必要，室内轮式/足式机器人不需要。

9.8 第二层落地：拓扑连接索引与多楼层

两个关键问题的结论：

• 文本图已有空间关系边，是否还需要拓扑连接作为单独一层？——不需要独立数据层。房间连通本来就是文本图边集的一个子类（connects_to）。9.3称其为"第二层"只是强调用途：同一批边额外导出一张只含房间节点的小networkx图，供nx.shortest_path做跨房间/跨楼层路径。一份派生代码、两个输出出口（文本句子进prompt；小图算路径），没有第二套需要维护的数据结构。
• 现有HMSG是否已有拓扑连接？——米级有、房间级没有。nav graph已含同层可通行连接和跨层楼梯连接（证据见下）；但场景图本体（create_graph）只有floor→room→object层级边，没有"厨房↔客厅"这类房间连通边。缺口正好是下面约100行派生代码。

参考工作方面，最贴合的是MoMa-LLM room_graph.py（Voronoi房间图+门→两侧房间连通，L83-127，可参考重写）；概念上同Hydra（MIT-SPARK）场景图的places→rooms层，但无需引入其技术栈。

楼层不用加属性，它在HOV-SG中已是一等公民，证据：

1. 层级第一层就是floor：Room.floor_id已存在并持久化（room.py L29、L226）；
2. nav graph节点键本身含楼层：(row, col, floor_id)+height属性（navigation_graph.py get_voronoi_graph L448起）；
3. 跨楼层连接已完整实现（graph.py create_nav_graph L846-895）：每层建Voronoi自由空间图get_floor_graph→楼梯点云建楼梯图get_stairs_graph_with_poses_v2→楼梯图与本层图连接connect_stairs_and_floor_graphs→相邻楼层互连connect_voronoi_graphs→全局图落盘nav_graph/global_nav_graph_graph.json。

真正缺的是房间级连通边——nav graph是米级路点图（数千节点），不能直接进prompt；文本层需要的是"厨房↔客厅连通"这种房间图。派生规则（新写derive_room_edges.py，约100行，全规则零训练）：

1. 节点归属：把global nav graph每个节点按XZ位置归属到最近房间（点到房间点云2D投影的最近距离；HOV-SG给相机位姿归属房间用的就是这个算法，graph_utils.py compute_room_embeddings L96-112，可直接搬）；
2. 楼内连通：凡一条nav边的两端属于不同房间→这两个房间连通，边中点即"门口/通道"的位置提示；
3. 跨层连通：楼梯子图两端节点的归属→floor i↔floor j via staircase边；
4. 模糊距离：房间对之间用nav graph最短路长度，按MoMa-LLM的3/10/20米阈值量化成very close/near/far/distant，不输出数值。

文本形式（进prompt的只有这两类句子）：

kitchen (room 0_3) connects to: living room (0_5, doorway), hallway (0_2, doorway)
floor 0 connects to floor 1 via staircase (near room 0_1)

跨房间路径规划在房间图上做nx.shortest_path，返回房间序列文本；米级执行仍由底层nav graph / move_to_world负责，不进prompt。

9.9 第三层落地：视觉快照缓存

房间级快照：HOV-SG建图时已经选好帧

建图时compute_room_embeddings（graph_utils.py L52-112）已经完成：所有帧按相机位姿归属房间→每房间对帧的CLIP embedding做k-means→选5个代表帧，帧号写入room.represent_images（graph.py L551-570）并持久化到房间json（room.py L232）。

缺口只有一个：存的是帧号（数据集索引），没有把图片导出。需要改两处：

1. 建图管线末尾加约10行：按represent_images帧号从数据集导出RGB（可带位姿）到graph/snapshots/room_<id>_<k>.jpg，并写一份snapshots/index.json：

{"0_3": [{"frame_id": 1280, "image": "room_0_3_0.jpg", "pose": [...], "visible_objects": ["fridge", "sink"]}]}

2. 查询skill加参数include_snapshot=true：按room_id返回1–3张图给VLM。

物体级快照

系统已有best_view机制（导航目标位姿用的就是物体best_view的RGB pose），把best_view的帧号/位姿/crop路径补进object json即可，供"到达目标附近后做精细确认"时调用。

节点的快照索引属性设计

与9.7的节点schema对应，字段级设计：

• room节点：snapshots: [{frame_id, image: "snapshots/room_0_3_0.jpg", pose, visible_objects: [...]}]——内容即上文导出的index.json按room_id合并进序列化输出；
• object节点：best_view: {frame_id, image, pose}——建图末尾把帧号/路径补写进object json；
• 文本序列化时只输出"有无快照"的标记（如snapshots: 3 available），图片本体绝不进常驻上下文，仅在include_snapshot=true时按需返回（呈现格式见9.10 P3）；
• repo选择：第一版不需要任何外部repo——帧是HOV-SG建图时自己选好的；3D-Mem仅作为二期选帧算法升级（见下，独立文件可整体移植）。

升级选项（第一版不做）：3D-Mem的物体覆盖导向选帧

HOV-SG的k-means是"外观代表性"选帧；3D-Mem是"物体覆盖"选帧，更适合精细空间判断：数据结构SnapShot{image, obs_point, full_obj_list{obj_id:conf}, cluster[obj_ids]}（src/tsdf_planner.py L59-70）；对物体中心做bisecting k-means空间聚类（src/hierarchy_clustering.py L283-462，独立文件）；每簇选帧规则select_frame（L296-318，20行）——帧的可见物体集⊇簇物体集，按"看到物体最多、置信度和最高、优先沿用已选帧"排序。

使用规则（防过载）：快照是回退通道——仅当文本场景图不足以决策（空间余量、外观、朝向类问题）时按room_id调取，每次≤3张；不做全量常驻输入（HRON/ESCA的信息过载教训，见9.1环4/环5）。

9.10 消费接口落地：常驻摘要+查询skill族+快照回退

五种消费模式的代码证据

对开源系统"文本场景图如何被LLM/VLM实际消费"的逐仓库核查结果：

四条共性设计定则（上述系统全部遵守）：

1. 图文本的第一作用是给LLM一个可引用的名字空间——动作/工具参数必须是图里出现过的节点名，杜绝幻觉目标；
2. 全量图从不进上下文——要么房间级摘要常驻+按需展开（MoMa-LLM/SayPlan），要么skill内部临时构造局部子图文本（SG-Nav）；
3. LLM输出强约束（一个函数调用/编号/0–1值），并有解析失败兜底；
4. 执行反馈以文本回注下一轮（env feedback+带成败标记的动作历史）——现有ToolResult机制天然满足，无需新做。

P1 常驻摘要（注入runtime context，MoMa-LLM范式）

[Building Map Summary]
You are in: living room (floor 0).
floor 0: living room [sofa, tv, 2 chairs], kitchen [fridge, sink, dining table], hallway [...]
floor 1: bedroom [bed, wardrobe], bathroom [...]
Connectivity: living room<->kitchen (doorway, very close); hallway<->staircase;
              floor 0<->floor 1 via staircase.
(These are the only valid room/object names. Use sg_query(room) for details.)

• NL行格式而非JSON（MoMa-LLM主方法 vs JSON基线的选择；MapGPT结论同向）；末行显式声明"名字空间"规则（定则1）；
• 生成：hmsg_serializer的summary模式，每episode注入一次；HMSG为离线图，episode内不刷新（增量建图上线后改为"房间集合变化才重算"）；
• token预算：约20房间×约20 token+连通约100 token≈500–800 token一次性成本；
• "You are in"行由位姿→房间归属（9.8的节点归属函数）维护，sg_locate结果可覆写。

P2 查询skill族（与现有skill并列注册，LLM按需调用）

9.4辅助接口的查询函数族在实现层收敛为四个skill：get_objects_in→sg_query、get_relation/get_nearest→sg_find、get_path_between→sg_path，并新增sg_locate承担9.6的重定位：

• 硬性规则：数值坐标只进meta json（供skill链路），文本部分绝不含坐标（9.1环3：MapGPT坐标消融）；
• sg_find与find_object_candidates过渡期并存A/B，稳定后合并；
• system prompt增补使用优先级："找目标→sg_find；跨房间/楼层规划→先sg_path；不确定自身位置→sg_locate；仅当需判断空间余量/外观/朝向→include_snapshot"。

P3 快照回退（3D-Mem呈现范式）

• sg_query(room, include_snapshot=true)返回≤3张房间代表帧，每张图后紧跟一行可见物体清单；快照多于3张时按指令关键词与可见物体求交做最简prefilter；
• 对VLM的问法用强约束选择式（"哪张图包含目标？回答图片编号"），不开放自由描述。

访问时机、取回内容与格式：触发规则表

参考工作与repo：消费侧没有可整体采用的repo——上表五家的消费逻辑都与各自的策略或仿真环境耦合。最接近可直接参考的模板是MoMa-LLM的_create_prompt（P1常驻摘要即按它重写）；SayPlan无开源代码，其prompt形态经MoMa-LLM JsonLLMEnv复刻，可作对照参考。

降级路径（对应系统脆弱性约束）：sg_*任一失败→ToolResult返回明确错误文本，agent自然回退到find_object_candidates/topdown/VLN；摘要生成失败→不注入，系统等价于现状。每个组件独立可开关。

新增验证用例（叠加在现有replan、VLN切换回归用例上）：①跨楼层指令（"去二楼卧室拿…"）→验证P1摘要+sg_path；②相对关系指令（"冰箱旁边的桌子上…"）→验证sg_query关系三元组；③位置迷失（导航漂移后要求"先确定你在哪"）→验证sg_locate。

9.11 实施顺序与工作量

四条工程原则贯穿所有步骤（对应系统模块多、耦合度高的约束）：零训练（只用规则与现成VLM）；规则先行（关系边由包围盒几何计算，不引入学习模型）；单向数据流（建图→序列化→planner，不反向耦合）；新增件皆为独立skill/纯函数（可单测、可开关，失败可降级回现有链路）。

任务过滤机制（9.1环4与9.12风险2的要求）已内嵌于上述步骤、不单列：P1摘要默认room级折叠（物体细节不进常驻上下文）、P3快照按指令关键词prefilter；若token仍超限，再引入ESCA selective grounding式的任务相关子图提取（后置项）。

明确不做：VLM微调（SpatialVLM式）、GNN/RL（HRON式）、复杂感知校正模块（SR-Nav RAMM式）、图数据库与查询语言（Structured Interfaces式，当前规模不需要）、从零重建建图栈（ConceptGraphs开源实现仅作参考）。

9.12 风险与注意事项

1. VLM空间认知能力的天花板（SPACE Benchmark）。 不能过度依赖VLM的空间推理能力。凡涉及"如果我在A处面向B，C在我的什么方向"这类推理，必须由专门的几何计算模块处理，不能委托给VLM。
2. 场景图的信息过载风险（HRON）。 HRON的实验表明：朴素引入场景图（无注意力机制）的SR（0.458）甚至低于不使用场景图（0.586）。务必配备任务驱动的注意力或过滤机制。
3. 感知质量的级联效应（ESCA）。 69%的失败来自感知错误——一个错误的物体检测会导致场景图中出现错误节点，进而导致错误的空间关系推断，最终导致规划失败。
4. 定量空间估计的不可靠性（SpatialVLM）。 VLM的距离估计仅37.2%在GT的半到两倍范围内。不要基于VLM的距离估计做精确运动控制。
5. LLM空间先验的局限性（SR-Nav在MP3D上的表现）。 若后续引入"LLM生成空间先验"机制，需注意物体类别增多时先验质量下降；在线观测与先验冲突时应果断采信观测。
6. 在线构建的实时性挑战。 真机部署时的计算延迟可能成为瓶颈。序列化器设计须支持局部增量更新，避免依赖全图重建；更新可采用异步策略。
7. 论文口径与实测的差距（MapNav第一手教训）。 本报告引用数字均为论文自报，宣称收益可能无法兑现。机制采纳优先级：顶会+真机 > 顶会仿真 > preprint；任何preprint机制进入系统前先做最小复现。