UrbanGround：在真实城市尺度下评测多模态Agent的导航与空间推理能力

最近我一直在刷多模态模型和Agent相关的论文看到一个很有意思的工作UrbanGround由上海交大、新加坡国立大学、美团等机构一起做的核心思路很直白——把AI Agent丢进一个真实尺度的香港城市环境里测试它在城市探索任务上的能力。这个项目标题一出来就抓住了我的注意力因为过去大多数Agent评测都是在合成环境、静态数据集或者模拟器里做的像这样直接上真实城市地图、真实街景、真实空间关系的确实不多见。这篇文章我就基于对这个项目的研究和理解把其中涉及的核心思路、技术方案、实验设计以及对我们做Agent开发的实际启发一次性讲透。不管你是做多模态模型研究、Agent框架开发还是单纯对“AI在城市里认路”这个场景感兴趣这篇文章都能给你一些值得参考的东西。1. 项目整体设计与动机拆解1.1 大家都在测AgentUrbanGround为什么要另起炉灶过去一年里Agent相关的评测基准多到数不过来。有测代码生成的有测网页操作的有测工具调用的还有测多轮对话记忆的。但这些评测有一个共同特点——环境是被抽象过的输入是“已经整理好的信息”输出是“一个明确的答案”整个过程更像是在考“信息处理能力”而不是在考“环境探索能力”。而真实世界里的城市探索本质上是一个非常不一样的任务。你站在一条街上看到的是多模态的原始信号街景图片、路牌上的文字、建筑的外观、周围的噪声、GPS坐标的偏移、地图上道路的拓扑关系。这些信息是杂乱、冗余、甚至互相矛盾的。Agent需要自己决定看哪里、信什么、怎么把不同模态的信息融到一起才能得出“我该往哪走”的结论。UrbanGround把评测环境直接搭建在真实尺度的香港之上这意味着它测试的不是模型“知道多少”而是模型“能不能在真实环境的噪音中找到关键信息并做出正确决策”。这种测试逻辑明显比传统QA式评测更接近Agent实际落地的形态。1.2 为什么偏偏是香港真实尺度的三个层次选择香港作为测试场景并不是随便挑一个国际化大都市那么简单它背后有几个非常实际的设计考量。第一街道尺度丰富。香港既有密集的油尖旺老城区也有宽敞的港岛北部商业区还有地形复杂的半山和郊区。不同区域的街道密度、路网规律、视觉特征差异很大这样天然形成了一个“难度分级”的测试场。Agent能在这种环境里探索成功才说明它具备一定的泛化能力而不是只对单一街道形态有效。第二多模态信息高度密集。香港的招牌文化全球知名沿街商铺的中英文标识、路牌、地标建筑外观这些信息既丰富又混杂。对多模态模型来说这是绝佳的压力测试——它必须学会在海量视觉信息里筛选出与导航相关的信号同时忽略掉大量干扰项。第三空间结构复杂。香港有大量天桥、地下通道、多层立交二维地图和三维真实空间之间存在很大的偏差。这种偏差对Agent的“空间推理”能力提出了额外要求仅依赖地图坐标往往不够还必须结合视觉观察来理解空间的真实连通关系。这三个层次合在一起使得香港这个测试场能够把“视觉理解—空间推理—决策规划”这条完整链路都跑起来而不是像传统数据集那样只考验其中一个环节。1.3 从标题看项目意图想解决什么问题UrbanGround这个名字本身就是核心意图的概括——Urban代表城市尺度Ground代表“落地到地面”暗示着要把Agent从虚拟环境里“拉到地面上”来测试。这个项目想回答的核心问题简单说就是当多模态大模型作为Agent的“大脑”在真实城市中执行探索任务时它的视觉理解能力、长时记忆能力、空间推理能力和决策规划能力到底处于什么水平距离真正可用还差多远这个定位决定了它不是一个纯算法创新项目而更像是一个评测体系设计项目。作者团队的目标是搭建一套可复现、可扩展、可对比的评测框架让后来的研究者能够用同一个尺子去衡量不同模型和Agent架构的真实水平。2. 核心细节解析与实操要点2.1 数据从哪来真实地图数据与全景图像的结合从项目公开的定位来看UrbanGround构建评测环境时主要依托了两类数据源香港地区的OpenStreetMap路网数据以及街景级别的全景图像数据。这两者的结合是它区别于传统Agent评测环境的关键。OSM数据提供了道路的拓扑关系、道路类型、路口位置、地标点的经纬度等结构化信息相当于给Agent绘制了一张“带注解的二维地图”。而全景图数据则提供了在该地图坐标点上实际“看到的”360度视觉信息相当于把二维坐标映射回三维现实。我在做一个导航类Agent项目时踩过类似的坑最开始只用了地图API返回的路网数据Agent规划路线经常会给出“穿楼而过”的荒谬方案原因就是路网数据虽然是正确的但它缺失了现实世界中建筑实体的遮挡关系。UrbanGround把街景图作为观测信息输入正是为了解决这个问题——让Agent不仅能读地图还能“看”现实这和人类找路时的行为模式是一致的。2.2 任务设计从“认识路”到“会用地图”基于我看到的项目设计思路UrbanGround的任务体系大致分为多个层级从浅到深逐步测试Agent的能力。首先是基础视觉定位任务Agent需要根据给定的街景图像结合地图信息判断当前所处的位置这对多模态模型的视觉理解和位置推理能力是一个基本考验。其次是目标导航任务给定一个目标地点的描述比如“找到附近的银行”或“前往某栋标志性建筑”Agent需要在一系列候选行动路径中做出选择每一步都要综合当前街景信息和目标方向来判断接下来是直行、左转还是右转。更进一步的任务则涉及长程探索要求Agent在多个时间步内持续推进综合记忆已经走过的路线不断修正对空间的认知最终到达目标位置。这种从单点识别到连续决策的任务分级实际上模拟了人类在陌生城市中“看地图—做判断—走路—再确认”的完整过程。至少从评测角度看这样的设计能反映Agent在真实复杂环境中自主探索的潜能而不是仅仅展示它在静态图片上“眼力”有多好——后者其实是很多视觉问答评测的局限性所在。2.3 Agent的架构方式感知、推理、行动闭环在UrbanGround的框架下Agent的工作流程大体分为三个环节。感知环节负责接收当前街景图和当前位置坐标把高维的视觉信息转化为语言描述或特征向量推理环节需要结合任务目标、历史轨迹记忆以及地图知识判断当前的空间关系并决定下一步行动行动环节则将决策结果输出为具体的移动指令比如前进、左转、右转或到达目标点。这个闭环本质上和机器人导航没有区别但UrbanGround把“身体”换成了模拟的移动模块把“大脑”交给了多模态大模型这样就能在不依赖实体机器人的情况下快速评估不同模型和Agent框架在导航任务上的表现。这样做的优势很明显评测成本低、可重复性强、还能直接横向对比不同模型的能力差距。值得注意的是真实Agent开发中这三个环节往往是紧耦合的。我在做一个自动探索任务的时候最开始把三个环节完全拆开用不同模型模块组装结果出现一个问题视觉模块给出的场景描述很丰富但推理模块并不总能准确抓取其中的关键导航信息导致大量对下一步行动有用的信息就被忽略了。后来改成把原始视觉输入直接喂给统一的多模态推理模型反而让行动决策更准确。效率上有一定牺牲但在复杂真实场景下端到端的感知-推理一致性往往比模块化的“高精度感知”更可靠。3. 实验结果与关键结论3.1 不同模型的表现差异谁在记路谁在认路从公开的项目描述来看UrbanGround对比了目前主流的多模态大模型包括闭源的GPT系列和开源的Qwen-VL系列等。结果表明在需要多步推理和长时记忆的复杂导航任务上不同模型之间的差距非常明显。最有趣的现象是单纯在视觉问答评测中得分很高的模型在UrbanGround的真实场景导航中并不一定表现最好。原因也很简单VQA评测考察的是“单张图片的理解能力”而导航任务需要的是“连续帧之间的空间推理能力”。前者更像是“看图说话”后者则要求模型把多张图的视角在大脑中构建成一个连续的空间模型并在此基础上做决策。说白了一个模型可能“看得很准”但它不一定“想得很深”。另一个值得注意的点是开源的Qwen-VL系列模型在很多子任务上已经能和闭源模型打得有来有回尤其是在视觉描述和地标识别这些基础能力上差距已经很小。但在长程规划这类需要综合推理的任务上闭源模型仍然有明显优势。这意味着如果你做Agent开发选择开源模型做基础感知和识别是可以的但在规划决策模块上可能还是需要更强的模型或者加上额外的训练和推理策略。3.2 端到端测试暴露出的共性问题UrbanGround的端到端测试并不仅仅是比较模型之间的分数高低更重要的是它暴露出一些共性问题这些问题也是我在自己Agent开发中实际遇到的。第一个问题是长时记忆的衰减。Agent在进行长程探索时早期经过的街道和看到的地标信息往往会在几步之后逐渐模糊导致Agent在后期出现“迷路”现象——它明明已经经过了某个关键路口但后续决策时完全想不起来。这说明当前主流模型的上下文注意力机制在处理长时间序列时还不够稳健。在实际开发中我通常会把历史轨迹的关键节点压缩成结构化摘要而不是把所有原始信息都堆在上下文里这样能在一定程度上缓解记忆衰减问题。第二个问题是对地图坐标的敏感度过高。当Agent收到GPS坐标信息时如果坐标存在一定误差它很容易被误导到错误方向。人类在真实城市中导航时通常会把坐标作为粗定位然后主要依赖视觉地标来校验路线但很多大模型会“过度信任”坐标数据。这也是为什么有时候你给模型加一个坐标输入它反而不如不给坐标时表现稳定。我在自己项目里做过一个对比实验给Agent同时提供坐标街景描述时在某些任务上表现反而比只有街景描述时更差。后来单独加了一个“坐标系校验”模块让视觉信息和坐标信息互相对齐情况才好转。第三个问题是视觉干扰的过滤能力不足。香港街头信息密度极高招牌、广告、行人、车辆、建筑细节等绝大多数与导航无关但模型很难自动区分哪些是关键地标、哪些是干扰噪声。这个问题直接指向多模态模型的一个本质短板它们擅长理解视觉内容但不擅长判断视觉内容与当前任务的相关性。4. 实操层面从评测到Agent开发有哪些可以复用的经验4.1 想复现UrbanGround环境搭建要花多少成本如果你看到这个项目后想在自己机器上复现整个测试流程我的建议是从数据准备开始。OSM数据可以公开下载街景图可以通过公开地图API获取。处理数据时要注意把经纬度坐标系转换到本地平面坐标系否则后续导航计算会非常痛苦。加上这一步是因为真实GPS数据的经纬度计算涉及地球曲率直接用经纬度做距离计算会产生较大误差。Agent运行环境搭建上我用的是Python PyTorch的基础栈加上HuggingFace的transformers库来加载模型。如果你配置了16G显存的中端显卡加载一个7B-13B规模的多模态模型跑推理是够用的。需要注意的是长上下文输入比如连续多帧的街景切图会显著增加显存占用。我实测在16G显存上跑Qwen-VL-7B模型单帧图像推理没问题但如果把连续4帧图像拼成一张长图作为输入显存占用会直接飙升到接近上限推理速度也明显下降。合理做法是控制单次输入的图像数量或者用SLiding Window的方式分批处理。4.2 模型选型的现实考量闭源还是开源大小如何平衡UrbanGround这类评测结果给我们的一个直接参考是闭源模型在复杂导航推理上优势仍然明显但开源模型在基础感知任务上的表现已经足够好。对你做Agent开发来说这提示了一个混合架构的可能用开源模型做视觉描述、地标识别等基础模块用更强的闭源模型或更精调的本地模型做空间推理和路径规划。进一步看模型规模的选择也需要结合任务复杂度来定。如果只是做“识别当前位置的显著地标”7B模型完全够用。但要做“根据一段历史轨迹推断下一步行动方向”可能需要更强的推理能力或更长的上下文处理能力这时候14B甚至闭源API会更稳妥。实际项目中更推荐的方式是简单任务走本地小模型复杂决策才调用更强的模型这样可以兼顾成本、速度和准确率。以我自己在开发一个室内导览Agent的经验为例最初为了追求效果所有环节都调用大参数模型结果单次交互延迟超过10秒几乎无法实际使用。后来做了分层处理视觉描述用本地7B模型规划决策用更强的云端模型单轮交互耗时压缩到2秒以内而规划准确率没有明显劣化。4.3 Agent的逻辑代码怎么写一个可移植的任务框架把homework做完之后我开始把UrbanGround这种“观察-推理-行动”框架抽象成自己项目里的一个通用导航Agent模板关键的逻辑部分可以这样组织。class UrbanExplorer: def __init__(self, model, memory_size5): self.model model self.memory [] self.position None self.memory_size memory_size def observe(self, street_view, gps): # 将街景图像与GPS坐标组合成多模态观测 observation { image: street_view, gps: gps, description: self.model.describe(street_view) } return observation def reason(self, observation, target): # 基于当前观测、历史记忆和目标任务生成下一步行动 prompt self._build_prompt(observation, self.memory, target) action self.model.decide(prompt, candidate_actions[forward, left, right, stop]) return action def update_memory(self, observation, action): # 保留关键信息用于后续决策 self.memory.append({ gps: observation[gps], landmark: observation[description][:50], action: action }) if len(self.memory) self.memory_size: self.memory.pop(0)这个框架的核心设计是memory的引入它模拟了人类找路时“记路”的过程。如果Agent每走一步都是“全新”的没有对过往路线的记忆那么在任何非直线路径上都会迷路。这个设计也是在UrbanGround环境测试早期版本时候踩坑总结出来的经验——没有记忆模块的Agent即便模型再强在需要左转两次右转一次的三维空间导航里也会彻底失效。5. 常见问题与排查技巧实录5.1 模型“看”了街景但给不出有用的行动建议怎么办这是我在实际测试中最常见的问题。模型能准确描述“面前是一家便利店左侧是一个红色招牌的茶餐厅”但当问它“该往哪走”时给出的回答却很模糊比如“你可以考虑向左走看看”。这种问题本质上不是视觉理解的问题而是模型没有把视觉信息转化为空间坐标系的决策依据。我的排查顺序是先确认Prompt中是否明确指出当前朝向与地图方向的对齐方式很多模型在推理时并没有一个清晰的“朝向坐标系”导致它说不出“直行100米”这种精确指令然后检查当前可用的行动候选集是否约束得太宽让模型做开放式回答容易得到模糊结果限定候选动作集后效果会好很多最后看历史轨迹信息是否被纳入决策依据如果模型只知道“我在这里”而不知道“我从哪里来”它会丧失大量的空间推理线索。给模型加了一个极简的“方向对齐”说明比如“当前朝向为北目标在你的东北方向你面前的道路通往西北”模型给出的行动指令准确率就有了肉眼可见的提升。5.2 Agent走两步就“失忆”如何延长有效探索距离如果你测试UrbanGround或者自己搭建导航Agent时发现Agent总是走几步就忘了起点在哪这是典型的上下文记忆问题。很多模型的上下文虽然有几十K的容量但超过一定长度后早期的信息对决策的影响急剧下降。我尝试过几种缓解方案。第一种是把历史轨迹每隔几步做一次摘要压缩用几行文字概括“从A点出发经过B路口左转到达C附近”而不是保留每一步的完整描述。第二种是给每一步的轨迹信息做空间标注让模型始终知道自己在全局地图中的大致位置相当于给Agent一张持续更新的“你在这里”标记。第三种是尽量精简每一步的观测信息输入原始图片大而全但真正关键的是其中的地标和方向信息剪掉冗余视觉内容能大幅降低上下文压力。实际对比下来效果最好的是“摘要位置标注”的组合我在一个连续30步的长程导航任务中用这个方案把最终到达目标点的成功率从不到30%提升到了接近60%。5.3 多模态模型的“幻觉”在导航场景里有多致命做多模态Agent绕不开“幻觉”问题。在导航场景里幻觉展现为模型“以为”自己在某栋建筑前但实际上位置已经偏差很远了或者模型“认定”前方某个招牌是地图上的目标地标但那其实是一个完全无关的广告牌。导航场景的幻觉比对话场景更致命原因在于它是累积的。如果Agent在第三步做了错误的“位置确认”那么这个错误认知会被带入后续所有决策中就像人拿着画错起点标注的地图走路越走越偏。我在实践中用“关键节点复核”来减缓这个问题——当Agent要做出“到达目标点”这种高权重决策时强制要求它重新观察当前位置的视觉细节并与之前的记忆做交叉验证。如果视觉信息和记忆描述存在明显冲突就视为“可疑状态”让Agent先做短距离移动来确认而不是立刻结束探索。这个方法虽然牺牲了一些效率但在测评场景里显著降低了任务的“假成功”率。5.4 开源模型和闭源模型的选型策略我的习惯是先按任务类型分层匹配模型。纯视觉理解任务比如描述周围环境、识别地标类型开源7B-14B模型足够且速度和成本优势明显。空间推理任务比如“当前路口与该往哪走”的多步推理闭源模型的决策质量明显更高但也不是必须每次都调用因为这类判断在整条轨迹中往往只出现在几个关键节点。长程规划任务比如整条路线的前瞻规划交给最强的闭源模型来做但对响应速度不要抱太高期望。有一类任务是可以下放到本地小模型的但对模型基座有要求上下文足够长、对多模态内容的理解不是“看一眼就答”而是能提取关键线索。这类模型目前不是特别多我实际主要用的是7B-14B量级的产品常见选项都能满足基本需求但我的体会是真的到了复杂导航这类场景开源模型的稳定性和泛化能力还是和闭源模型存在明显差距。这里也给正在考虑用16G显存跑多模态模型的朋友提个醒如果你的显存只有16G加载14B模型做训练会非常吃力推理可以做但也要注意上下文长度。但7B模型跑推理是很舒适的如果先用它做感知模块把推理和决策“外包”给更强大的模型整体效果并不比直接端到端调用一个超大模型差太多。另外多模态模型对显存的占用点很多时候在视觉编码器上如果视觉输入分辨率过大显存会直接爆掉。这个可以被优化比如压缩图像分辨率效果损失不大的情况下显存占用能明显下降。6. 带来的后续扩展与个人体会这套评测体系的价值在于它提供了一个把Agent从“桌面环境”拉到“真实环境”的示范路径。虽然目前的场景是城市导航但同样的思路完全可以迁移到其他真实世界任务中比如室内寻物、园区巡检、复杂建筑内的人员引导等。核心方法论是一致的用真实尺度的空间信息多模态观测来测试Agent的闭环决策能力而不是只测单点能力。我自己的体会是Agent评测和Agent开发是互相成就的两件事。UrbanGround这类评测给出的不只是几个模型之间的分数排名更重要的是它会暴露当前模型和架构在实际环境中的结构性短板。比如长时记忆微薄、空间推理薄弱、多模态信息在决策中利用不充分这些问题你在传统benchmark里很难发现只有放到真实尺度任务中才会集中爆出来。如果你正在做Agent开发我的建议是不要只在干净、标准化的数据集上调优早点把Agent放到有噪声、有干扰、有不确定性的环境里跑一跑你会发现很多在测试集上隐藏得很好的问题都会在真实环境里现出原形。这才是一个Agent能不能真正落地的关键考验。