最近在做多模态大模型的空间理解评测时有一个很直观的体会让模型用坐标描述“桌子左边有一个杯子”和让模型真正理解“桌子和杯子的空间关系”完全是两回事。坐标可以背空间关系不能背。所以当我看到“让生成式模型画出空间智能而不是强迫 LLM 输出坐标”这个思路时第一反应是这个方向切得很准。浙江大学提出的 Agentic 空间认知评估框架核心思想就是把“让模型输出坐标”改成“让模型画出来”。这个转变看起来只是评测方式变了背后其实对应了一整套评测哲学的重构。本文会围绕这套 Agentic 空间认知评估框架展开先拆解为什么坐标式评测不可靠再说明生成式模型为什么更适合承担空间认知评估任务然后给出一个可落地的框架设计思路和最小实现示例最后聊聊评测指标设计、常见坑点以及工程化建议。适合正在做多模态大模型评测、Agent 应用开发、空间智能方向研究的读者。1. 为什么“输出坐标”不能证明模型具备空间认知1.1 坐标答案的本质是“能力代理”在传统空间评测里最省事的做法是给模型一张图然后问它“图像中红色物体的中心点坐标是多少”“请输出目标检测框的四个顶点坐标。”这类任务看起来是在测空间理解实际上测的是两件事的叠加模型是否有能力从图像里定位目标模型是否能准确输出数值坐标。但问题在于坐标只是一个“能力代理”proxy它并不等于空间认知本身。一个模型完全可以“蒙对”坐标。当图片中出现多个相似物体、遮挡关系复杂、视角变化剧烈时坐标数值的微小误差并不会改变人对空间关系的判断但坐标评测会直接判错。反过来模型也可能真的理解了空间关系却因为坐标回归精度不够而丢分。1.2 坐标式评测的三大缺陷第一个缺陷是“不连续”。空间关系是连续的概念但坐标评测把问题强制离散化了。左边、右边、上方、下方、嵌套、遮挡、环绕……这些空间关系很难用四个数值完整表达。第二个缺陷是“不可迁移”。一个模型在 A 数据集的坐标任务上得分很高不代表它在真实场景中能完成导航、布局、物体摆放这类任务。因为坐标是一个中间表示不是最终能力。第三个缺陷是“不适合评估生成式模型”。现在的生成式模型擅长的是分布建模和内容生成你要它输出一个精确到小数点的坐标本质上是在用一个它不擅长的接口去测一个它擅长的能力测出来的结果自然偏低也自然不公平。1.3 从“数值化”到“可视化”的评测转向既然坐标不适合作为空间认知的评测接口那什么适合答案是让模型“画”出来。把空间认知任务设计成“需要生成视觉内容才能完成”的任务。比如给它一段空间描述让它生成对应场景图给它一张场景图让它画出从 A 到 B 的路线给它一个布局描述让它画出家具摆放俯视图。这种评测方式的好处是空间关系不再被压缩成数值而是以视觉形式直接呈现。模型对空间的理解是否准确看生成结果就知道。这比坐标评测更接近“空间认知”的本质。2. Agentic 空间认知评估框架的核心思想2.1 什么是 Agentic 评估Agentic智能体式评估指的是评测过程不再是一次性的“提问—回答”而是由 Agent 自主完成“感知—规划—调用工具—生成结果—自我校验”的完整闭环。在空间认知评估中Agent 扮演的是一个“被测试者”角色它需要调动自身能力和外部工具来完成空间推理任务。举个例子传统评测是这样用户输入图中有几个物体 模型输出3 个。Agentic 评测是这样用户输入请判断图中有几个物体并说明判断依据。 Agent 动作调用视觉模型提取目标 → 调用空间关系模型分析布局 → 生成带标注的图 → 输出结论。两者的本质区别在于传统评测只测“最终答案”Agentic 评测测的是“完成任务的整个过程”。2.2 为什么要把生成式模型放进评估闭环这个框架把生成式模型作为“画图工具”放入 Agent 的工具集核心目的有三个。第一生成式模型能提供连续的空间表达。它生成的图像天然包含空间布局信息不需要把空间关系强行压缩成坐标。第二生成式模型能与 LLM 互补。LLM 负责语言理解和规划生成式模型负责视觉呈现和空间推理两者配合才能完整回答空间问题。第三生成式模型的输出可以被二次评估。生成的图像可以被目标检测模型、分割模型或者人类标注者再次分析从而形成“生成—评估—反馈—再生成”的闭环。2.3 框架的三层结构按照常见的设计思路这个评估框架可以拆成三层第一层是任务层负责定义空间认知任务比如空间关系判断、路径规划、布局生成、心理旋转Mental Rotation等。第二层是智能体层由一个或多个 Agent 组成负责理解任务、拆解步骤、调用工具。第三层是评估层负责对 Agent 的生成结果进行评分既包括视觉相似度等自动指标也包括人类评估。三层之间的关系是任务层定义“测什么”智能体层定义“怎么答”评估层定义“怎么判”。3. 框架整体架构与关键技术拆解3.1 一个典型的 Agentic 空间评估流程下面用一个具体的任务来说明整个框架的运作流程。假设评测任务是给定一张客厅场景图请规划一条从门口到沙发的路线并以可视化方式输出。整个流程可以拆成六个步骤任务解析LLM 理解任务目标识别出需要完成“路径规划”和“可视化输出”两个子任务。场景感知Agent 调用视觉理解模型VLM提取场景中的关键物体及其位置。路径规划Agent 基于物体位置关系规划一条避开障碍物的可行路线。工具调用Agent 调用生成式模型把路径绘制到场景图上。结果校验Agent 检查生成的图像是否符合约束条件比如路径是否经过障碍物。输出与评估把最终图像交给评估层进行评分。在这个流程中LLM 是“大脑”生成式模型是“手”而评估层是“考官”。三者缺一不可。3.2 关键组件Agent 的工具调用能力Agentic 评估框架对 Agent 的最大考验是工具调用能力。Agent 需要知道什么时候该调用生成模型调用哪个生成模型传入什么参数如何解析生成结果。这些能力本质上依赖 LLM 的函数调用Function Calling机制。当前主流 LLM 框架都支持通过工具定义Tool Schema来让模型调用外部能力。下面是一段工具定义的示意代码展示了如何把生成式模型封装成一个 Agent 可调用的工具# 文件路径agent_tools.py from typing import Dict, Any SPATIAL_GENERATION_TOOL { type: function, function: { name: generate_spatial_scene, description: 根据空间描述生成对应的场景图像用于空间认知任务的视觉化输出。, parameters: { type: object, properties: { scene_description: { type: string, description: 空间场景的结构化描述例如圆的左侧有一个正方形正方形内部有一个三角形。 }, style: { type: string, enum: [top_down, front_view, schematic], description: 生成图像的视角风格top_down 表示俯视图schematic 表示示意图。 } }, required: [scene_description, style] } } }这段代码的核心是给 LLM 一个清晰的工具接口说明。模型看到这个工具定义后就知道在遇到“请画出空间布局”这类任务时可以调用generate_spatial_scene来完成任务。3.3 关键组件多轮自我校验空间认知任务有一个特点一次生成往往不够准确。Agent 需要根据生成结果进行自我校验和修正。比如 Agent 第一次生成的路径图穿过了沙发那么它应该能“看出”这个问题然后重新规划路径。这种自我校验能力正是 Agentic 评估和传统评测最大的区别。实现自我校验的常见做法是在 Agent 的循环中加入一个“评估节点”。Agent 生成图像后先不直接输出而是自己调用一个视觉分析工具检查生成结果是否满足约束。生成图像 → 视觉检查 → 是否满足约束 ↑ │ └──── 不满足重新生成 ┘ 满足 → 输出最终结果这个循环可以用一个简单的 Python 骨架来实现。# 文件路径agent_loop.py from typing import Optional def spatial_agent_loop( task: str, max_iterations: int 3, verbose: bool True ) - Optional[str]: 空间认知 Agent 主循环理解任务 → 生成结果 → 自我校验 → 输出。 参数说明 - task: 空间认知任务描述 - max_iterations: 最大迭代次数防止 Agent 陷入死循环 - verbose: 是否打印中间过程 current_task task for step in range(max_iterations): if verbose: print(f 迭代 {step 1} ) # 第 1 步LLM 理解任务生成绘图指令 draw_instruction call_llm( promptf请根据以下任务生成绘图指令{current_task} ) # 第 2 步调用生成式模型画图 generated_image call_generation_model(draw_instruction) # 第 3 步调用视觉检查工具判断结果是否满足约束 check_result call_visual_checker( imagegenerated_image, constrainttask ) if check_result[is_valid]: if verbose: print(校验通过输出结果。) return generated_image # 第 4 步不满足约束把检查反馈并入任务重新规划 current_task f 原始任务{task} 前一次生成结果不满足约束原因如下 {check_result[reason]} 请修正后重新生成。 if verbose: print(达到最大迭代次数返回最后一次生成结果。) return generated_image这个骨架展示了 Agentic 评估的核心循环生成、校验、反馈、再生成。实际项目中call_llm、call_generation_model、call_visual_checker这三个函数需要根据你选择的模型和框架来具体实现。3.4 Agent 记忆跨任务的空间上下文管理空间认知评估还有一个容易被忽视的点Agent 可能需要跨任务积累上下文。比如评测任务包含多个子问题前一个子问题得到的场景布局可能会影响后一个子问题的判断。这种情况下Agent 需要有一个记忆模块用来存储已经生成的空间信息。常见做法是维护一个上下文列表每次交互时把历史信息注入到提示词中。# 文件路径agent_memory.py from typing import List, Dict class SpatialMemory: 空间上下文记忆用于跨任务保存空间状态。 def __init__(self, max_length: int 5) - None: self.history: List[Dict] [] self.max_length max_length def add(self, role: str, content: str) - None: self.history.append({role: role, content: content}) # 控制上下文长度避免超出模型输入限制 if len(self.history) self.max_length: self.history.pop(0) def build_prompt(self, current_task: str) - str: if not self.history: return current_task memory_block \n.join( f{item[role]}: {item[content]} for item in self.history ) return f历史空间信息\n{memory_block}\n\n当前任务{current_task}在实际评测中记忆模块的设计需要特别注意长度控制。空间描述通常比较冗长如果不对历史长度做限制很容易超出 LLM 的上下文窗口。4. 评估任务设计到底应该“画”什么4.1 空间认知能力的维度拆解要让生成式模型“画”出空间智能首先得想清楚空间智能包含哪些维度。根据认知科学和计算机视觉的常见分类空间认知能力至少包含以下几个方面。空间感知识别物体之间的位置关系比如“杯子在桌子的左边”。空间推理基于已知空间关系推断未知关系比如“A 在 B 的左边B 在 C 的左边那么 A 在 C 的左边”。心理旋转在脑海中旋转物体判断旋转后是否与原物体一致。路径规划在存在障碍物的场景中规划可行路线。布局生成根据约束条件生成合理的空间布局。空间记忆记住场景中的物体位置并在后续任务中使用。每个维度都可以设计成“画图”任务。4.2 任务示例空间关系可视化这是最简单的一类任务。给定一段多物体空间关系的文本描述要求模型生成对应的示意图。示例输入描述一个红色圆形位于画面中央蓝色三角形位于红色圆形的左上方绿色正方形位于红色圆形的右下方且绿色正方形与红色圆形有部分重叠。示例输出一张符合上述空间关系的示意图。这个任务看起来简单但实际上很考验模型的组合能力。模型需要在文本理解、空间关系解析、布局规划、图形渲染四个环节都做到基本正确才能生成符合要求的图像。4.3 任务示例自然语言驱动的布局生成这个任务更接近真实应用场景。输入是一段自然语言描述要求模型生成布局图。示例输入请设计一个单人办公室的俯视布局图要求 1. 办公桌靠窗放置椅子面向办公桌 2. 书柜靠门对面的墙 3. 茶几和沙发放在房间中间区域 4. 所有家具之间留出不少于 80 厘米的通道。这个任务的难点在于模型需要把文本描述中的相对位置、朝向、间距等约束全部转换为视觉元素。任何一条约束理解偏差都会导致最终布局不合理。4.4 任务示例空间差异检测与修正这是更进阶的一类任务重点考察模型的比较和修正能力。示例输入图 A 是一张标准场景图图 B 与图 A 存在三处空间关系差异。请找出差异并生成一张修正后的图 B。这个任务要求模型同时具备空间记忆、差异检测和重新生成的能力。如果 Agent 没有记忆模块很难完成这种涉及图像对比的任务。这也是为什么 Agentic 框架在这里比单次生成的评测方式更有优势。5. 评测指标设计画得好不好怎么打分5.1 为什么不能只看“像不像”生成式模型评估的老问题是图像生成质量不可控随机性很强。如果直接用像素级指标如 PSNR、SSIM来打分会带来两个问题。像素相似不等于空间正确。模型完全可以生成一张风格不同但空间关系正确的图像素级指标会给低分。空间正确不等于像素相似。同样两个物体位置放对了但颜色有差异像素级指标也会误判。所以评估空间认知能力必须设计专门的指标而不是套用通用图像质量指标。5.2 结构化空间指标最直观的做法是把生成图像转换成结构化表示再与标准答案做比较。具体流程是先用目标检测模型或分割模型对生成图像进行解析提取出所有物体及其位置把物体位置转换成空间关系三元组例如(杯子, 在左边, 桌子)与标准答案的空间关系三元组集合做匹配。这种方式的优点是评估对象是空间关系本身而不是像素。缺点是依赖检测模型的精度检测错一个物体评估结果就会偏差。下面是一段空间关系三元组匹配的示例代码# 文件路径spatial_metric.py from typing import List, Set, Tuple # 空间关系三元组格式(主体, 关系, 客体) SpatialTriple Tuple[str, str, str] def extract_triples_from_image(image_path: str) - Set[SpatialTriple]: 从图像中提取空间关系三元组。 实际项目中这里会调用目标检测和空间关系识别模型 此处只给出流程示意。 # objects detect_objects(image_path) # relations recognize_spatial_relations(objects) # return relations raise NotImplementedError(请接入实际的目标检测与空间关系识别模型) def compute_spatial_precision( pred_triples: Set[SpatialTriple], gold_triples: Set[SpatialTriple] ) - float: 计算空间关系精度。 if not pred_triples: return 0.0 correct len(pred_triples gold_triples) return correct / len(pred_triples) def compute_spatial_recall( pred_triples: Set[SpatialTriple], gold_triples: Set[SpatialTriple] ) - float: 计算空间关系召回率。 if not gold_triples: return 0.0 correct len(pred_triples gold_triples) return correct / len(gold_triples) def compute_f1(precision: float, recall: float) - float: 计算 F1 分数。 if precision recall 0: return 0.0 return 2 * precision * recall / (precision recall)这套指标的核心思想是先把生成结果解析成可比较的结构化数据再计算精度、召回率和 F1。这样即使两张图的视觉风格完全不同只要空间关系一致也能得到满分。5.3 约束满足率对于布局生成类任务可以设计“约束满足率”指标。把任务描述中的每一条空间约束单独拆出来逐条判断生成结果是否满足。举个例子前面提到的办公室布局任务包含四条约束。评估时逐条检查办公桌是否靠窗书柜是否靠门对面的墙茶几和沙发是否在中间区域通道是否足够宽。每满足一条得 25 分最后汇总成百分比。这种方式对评估对象更友好因为每条约束的得分是清晰的模型也能通过反馈知道哪里错了。5.4 人类评估作为兜底自动指标有它的局限性尤其是当生成图像比较抽象时检测模型可能根本无法工作。这时候就需要人类评估兜底。人类评估建议采用“成对比较”的方式而不是让评估者打绝对分。把标准答案图和模型生成图放在一起让评估者判断哪张图的空间关系更符合任务描述两张图的空间关系是否正确空间关系的错误严重程度轻微偏差、明显错误、完全无关。成对比较比打分的稳定性更高评估者之间的分歧也更小。6. 一个最小可复现的实验思路6.1 环境准备考虑到这是一个偏研究性质的方向本文给出一个不需要特定硬件也能跑通的最小实验思路。实际环境按你的项目情况调整。建议环境Python 3.9 及以上任意支持函数调用的 LLM API各家大模型均可按实际购买或开源部署情况选择任意的文生图模型 API 或本地部署的 Stable Diffusion用于目标检测的开源库例如 Ultralytics YOLO 或使用云端视觉 API。版本说明当前大模型和图像生成模型迭代速度很快建议以你实际使用的模型版本为准不要锁死特定版本号。6.2 任务定义为了便于快速验证这里做一个最简单的空间关系可视化任务输入一句话空间描述例如“绿色圆形在红色正方形的左边”。 输出一张符合描述的简单几何图形示意图。这个任务的特点是物体种类少、空间关系单一、生成难度低。适合用来验证“生成式模型 Agent”的链路是否通畅。6.3 核心链路实现下面用伪代码加说明的方式给出整个链路。这里的llm_client和generation_client需要替换成你实际接入的模型客户端。# 文件路径spatial_eval_demo.py from typing import Optional class SpatialEvalDemo: 最小空间认知评估 Demo。 def __init__(self, llm_client, generation_client, visual_checkerNone): self.llm llm_client self.generator generation_client self.checker visual_checker def parse_spatial_description(self, description: str) - str: 让 LLM 把自然语言描述解析成结构化的绘图指令。 例如把“绿色圆形在红色正方形的左边”解析成 left of red square, green circle, centered vertically prompt f 你是一个空间场景解析器。请把用户输入的空间描述转换成 可用于文生图模型的结构化英文指令。 只输出指令本身不要输出其他内容。 用户描述{description} return self.llm.chat(prompt) def generate_scene(self, draw_instruction: str) - str: 调用文生图模型生成场景图返回图片路径或 URL。 return self.generator.generate(draw_instruction) def check_scene(self, image_path: str, original_description: str) - bool: 调用视觉检查器验证生成图像的空间关系是否满足描述。 如果没配置检查器则跳过校验直接返回 True。 if self.checker is None: print(未配置视觉检查器跳过校验。) return True return self.checker.verify(image_path, original_description) def run(self, description: str) - Optional[str]: 执行完整评估链路。 instruction self.parse_spatial_description(description) print(f解析后的绘图指令{instruction}) image_path self.generate_scene(instruction) print(f生成图像{image_path}) is_valid self.check_scene(image_path, description) print(f空间关系校验结果{is_valid}) return image_path if is_valid else None # 使用示例 if __name__ __main__: # 下面这行需要替换为实际的模型客户端 demo SpatialEvalDemo( llm_clientNone, generation_clientNone, visual_checkerNone ) result demo.run(绿色圆形在红色正方形的左边)这段代码不是完整可运行的成品而是一个流程骨架。实际接入时需要把llm_client、generation_client、visual_checker三个对象实现出来。6.4 从 Demo 到真实评估上面的 Demo 只覆盖了“生成”环节还没有覆盖“评分”环节。要把它扩展成真正的评估框架需要补充两件事。第一批量测试集。准备一组空间描述作为标准测试集每条描述对应一张标准答案图。第二自动评分器。对模型生成的图像进行空间关系解析与标准答案对比计算精度、召回率和 F1。评分器可以复用 5.2 节里的三元组匹配思路。7. 实现过程中常见问题与排查思路7.1 生成图像与描述不符问题现象常见原因解决思路生成的图像完全不符合描述文生图模型对复杂空间关系的理解不足拆分描述使用更简单的句式和稳定的关键词物体位置正确但风格不对绘图指令过短缺少风格约束在指令中补充“schematic”“minimalist”等风格词多次生成结果差异大文生图模型随机性较强固定随机种子或使用多次采样投票策略这个问题的高频根因是“LLM 解析出来的绘图指令不够准确”。排查时先打印解析出的指令人工判断指令是否有歧义。如果指令本身有误优化空间解析的 Prompt如果指令正确但图像不对问题出在文生图模型侧。7.2 Agent 工具调用失败问题现象常见原因解决思路Agent 不调用生成工具而是直接输出文本工具描述不清晰或模型不支持函数调用检查工具 Schema明确说明“必须调用工具才能完成”Agent 传参格式错误参数 Schema 定义不严格在参数 Schema 中增加默认值和 enum 约束工具返回结果无法被 Agent 理解返回格式不是模型友好的结构化格式工具返回 JSON并在指令中说明返回结构工具调用问题排查时建议先把工具返回内容打印出来看 LLM 是否能“看到”工具的结果。很多 Agent 框架中工具结果需要注入后续的消息列表如果注入逻辑写错模型就看不到工具输出。7.3 校验环节失效问题现象常见原因解决思路视觉检查器误判率高检查器模型能力不足换更强的视觉模型或对检查器做针对性的 Prompt 优化校验反馈无法引导 Agent 修正反馈信息过于模糊把校验结果转化为具体修改建议例如“绿色圆形应向左移动 20%”迭代次数耗尽仍未通过任务本身超出模型能力边界增加最大迭代次数或干脆记录失败案例不强行让模型生成这里要特别提醒不要为了“让评测通过”而无限放宽校验条件。评估框架的价值恰恰在于能发现模型的能力边界。如果所有任务都被放行评测就失去了意义。7.4 部署环境问题一个经常被问到的问题是LLM 和文生图模型必须部署在同一台电脑上吗答案是否定的。Agentic 评估框架本身就是分布式的。LLM、文生图模型、视觉检查器完全可以是三个独立的服务通过 API 通信。关键点是各服务之间网络连通延迟在可接受范围接口格式一致有超时和重试机制。换句话说只要 API 通信顺畅LLM 在云端、文生图模型在本地方便 GPU 集群部署是完全没有问题的。8. 最佳实践与工程化建议8.1 任务设计要“可判”设计空间认知评测任务时最核心的原则是“可判”。即每一个任务的答案必须是可以明确判断对错的。容易出现的问题是任务描述过于开放导致生成结果五花八门评估者无法统一标准。比如“画一张漂亮的空间布局图”就是典型的不可判任务。可判任务有两个特征有明确的空间关系约束比如“A 在 B 的左上方”有明确的评估标准比如“可通过三元组匹配打分”。在写任务描述时建议仿照单元测试的思维每个任务对应一个或多个“断言”每个断言都能独立判断真伪。8.2 Prompt 设计要“结构化”空间认知任务的 Prompt 不能是简单的自然语言建议采用结构化格式。一个好的空间任务 Prompt 应该包含任务背景告诉模型这是什么场景输入说明明确给出空间描述或参考图约束条件逐条列出必须满足的空间关系输出格式指定图像风格、视角等。结构化 Prompt 能显著降低模型的解析错误率也方便后续把描述转换为自动化评分规则。8.3 链路设计要“可观测”Agentic 评估链路涉及多个服务调用如果中间某一环出错排查起来很费劲。因此日志和中间产物保存非常重要。建议在每个关键节点保存中间结果LLM 解析出的指令生成模型的 Prompt生成的原始图像校验器的输出结果。这些中间产物既能用于排查问题也能作为后续优化模型 Prompt 的训练数据。8.4 评测数据要“防泄露”做评估框架时一个容易被忽略的风险是数据泄露。如果评测用的空间描述是通过大语言模型自动生成的而这些描述恰好又出现在模型训练数据中评测就会失真。建议从零构造评测数据而不是从公开数据集中抽取对评测集做去重校验定期更新评测集防止模型过拟合。8.5 自动化 pipeline 要“留有人工接口”纯自动化的评估有它的盲区特别是生成式模型的输出带有随机性自动评分器可能给出误导性的高分或低分。工程化建议是自动评估为主人工抽检为辅。对自动评分结果为“边界情况”的样本加入人工复核队列。9. 总结与下一步学习方向这篇文章从一个核心问题出发坐标式评测为什么测不出真正的空间认知能力然后解释了浙江大学提出的 Agentic 空间认知评估框架的思路转变接着拆解了框架的架构、任务设计、评估指标以及最小实现流程。简单回顾一下关键点“输出坐标”是一个能力代理不是能力本身用它评估空间认知有天然缺陷。让生成式模型“画”出空间关系更接近空间认知的本质。Agentic 评估框架通过“感知—规划—生成—校验—修正”的闭环比单次生成评测更可靠。评估指标应该基于结构化空间关系而不是像素相似度。工程实现上要重点关注任务可判性、Prompt 结构化、链路可观测性和数据防泄露。如果你准备往这个方向深入下一步建议按这样的顺序推进先复现一个最小的生成式空间关系可视化 Demo再接入视觉检查器形成闭环然后设计一个 50 到 100 条规模的评测集最后把评估维度扩展到心理旋转、路径规划等复杂任务。空间智能是通往通用人工智能的重要拼图。让模型“画”出它的理解既是对模型能力的测试也是推动多模态大模型持续进化的有效方式。希望这篇文章能为你的工作带来一些启发。如果你正在做类似的方向欢迎在实践中验证这些思路并根据你的具体场景调整任务设计和评估指标。