这次要聊的不是又一个“让 LLM 写代码、调工具”的 Agent 应用而是浙大研究团队提出的一个空间认知评估框架。它解决的是很多多模态模型评测里长期存在的一个别扭问题我们到底该怎样判断一个模型真的“理解”了空间关系这个框架的核心思路用标题里的一句话就能说清让生成式模型去“画”出空间智能而不是强迫 LLM 输出一堆“坐标”。也就是说与其让模型给出某个物体在哪几个像素之间不如让模型直接把场景布局、包围框、遮挡关系、空间顺序画出来按照生成结果来评估空间认知能力。再加上 Agentic 的循环方式模型可以在多轮观察、绘制、校验中逐步修正自己的空间理解。这类工作的价值在于它把空间认知评测从“语言游戏”拉回到“视觉生成”。坐标是一串数字数字可以靠猜测、靠统计规律、靠语言先验蒙出来但对空间的真正理解往往要在“画出来”这一步才暴露问题。这篇文章会从框架动机、核心组成、本地验证、接口调用、批量评估、性能观察、问题排查几个方面展开。如果你正准备评测开源视觉语言模型、图像生成模型的空间能力或者想在 ComfyUI / diffusers 这类生成流程里加入空间校验环节这篇文章可以直接作为一份落地参考。1. 核心能力速览能力项说明项目类型AI 模型空间认知评估框架 / 评测方法论提出单位浙江大学研究团队核心思路通过生成式模型输出空间可视化结果替代 LLM 输出坐标式答案评估对象LLM、视觉语言模型VLM、图像生成模型的空间推理能力关键机制Agentic 多轮“生成—校验—修正”循环输出形式带包围框的图像、布局草图、分割掩码、场景图等空间表示评估指标可对接 IoU、布局相似度、空间关系准确率等常见指标启动方式需以官方仓库/项目文档为准本文提供通用流程API 能力取决于开源实现版本可自行封装为 HTTP 服务批量任务可通过目录遍历脚本实现批量评估推荐硬件取决于底层生成模型通常建议 NVIDIA GPU显存按模型选择支持平台通常适用于 Linux / Windows / macOS需按模型依赖判断适合场景模型空间能力评测、Prompt 设计验证、生成结果质量筛选、空间数据标注辅助从当前公开资料看这个框架的完整代码仓库和具体参数并没有披露得很细。所以下面所有部署和验证步骤我会按“通用方案”来写既保留 Agentic 空间评估的流程完整度也保证你拿到任何类似项目时都能快速迁移。2. 为什么“输出坐标”不能准确评估空间认知先回到一个基础问题为什么很多评测喜欢让模型输出坐标最常见的原因是好量化。模型说“苹果在桌子的右上角”评测方就期望模型输出一个 bbox[x1, y1, x2, y2]。然后拿这个框跟标注数据算 IoU。这套逻辑看起来客观实际有四个明显的坑。第一坐标是“间接表达”。LLM 在训练时学到的坐标知识很多来自文本语料而不是图像像素。当模型说“物体中心在 (320, 240)”时它可能是在复述训练集中见过的描述而不是真正从图像特征里推理出位置。这样测出来的分数容易高估模型的空间推理能力。第二坐标的容错率不均匀。一个 512x512 的图像里中心区域 20 个像素的偏移可能不至于影响人对空间关系的判断但对 IoU 来说可能就是 0.5 和 0.8 的区别。坐标评估对阈值敏感评测结果经常因为后处理方式不同而剧烈变化。第三多对象关系难以用坐标表达。比如“书在杯子和电脑之间”模型要同时输出三个物体的坐标还要隐含“之间”这种拓扑关系。坐标本身只能给出位置不能直接表达遮挡、包含、左右顺序、前后关系。评测时往往要额外写一堆规则来解析坐标关系解析器本身又带来误差。第四模型可能“作弊”。空间关系描述在语言上常常有统计先验。比如“台灯在桌子上”这个组合在训练语料里高频出现模型不需要看图也能答对。坐标任务只要给一个合理分布的位置分数也不会太低。这导致很多空间评测变成了“语言先验测试”而不是视觉空间测试。所以浙大这个框架提出的方向是让模型把空间理解画出来。生成式输出包含更多的结构性信息比如物体边界、相互遮挡、布局顺序。画错了就是画错了很难靠语言先验蒙混过关。再加上 Agentic 的循环方式模型可以多次修正自己的输出最终得到的空间结果会更有参考价值。3. 框架核心组成与评估流程从标题和常见多模态评测框架的设计思路来看这个 Agentic 空间认知评估框架应该包含四个核心模块。3.1 空间任务生成器它负责把文本化的空间查询转换成可执行任务。例如输入“画一张图包含一个红色杯子、一个蓝色书书在杯子的左边”。任务生成器会把这句话拆解成对象列表、空间关系和画布要求。3.2 生成式空间表达模块这是整个框架的关键。模型不是输出坐标而是输出一张带有空间结构的图像或图层式表示。常见的表达方式有带包围框的标注图把每个对象用矩形框画出来并附带类别标签。布局草图用色块、剪影表示对象位置和大小不要求精细纹理。分割掩码像素级标出每个对象的区域能检测模型是否理解精确边界。场景图以节点和边描述对象、属性和关系适合作为评估的中间格式。3.3 Agentic 循环控制器框架内部会有一个多轮循环初始生成 → 自检 → 修正 → 再生成。具体包括模型先生成一次空间结果。评估模块检查生成结果与要求的空间关系是否一致。如果不一致把差距反馈给生成模块。模型修正自己的输出再次生成。这个过程可以类比于写代码时的“自测—报错—修复”。Agent 在这里并不是多智能体对话而是模型在空间生成任务上的自我迭代。3.4 评估打分模块最终评估层会把模型生成的空间结果与真值进行对比。可以使用的指标包括对象检测的一致性生成框是否完整覆盖对象。空间关系准确率左右、前后、上下、包含、遮挡等关系是否正确。布局相似度生成布局图与真值布局之间的结构距离。多轮修正率Agent 在第几轮能修正到正确结果这能反映模型的空间推理稳定性。从实际使用角度看这套流程最关键的创新点是把“空间认知”拆成“生成—校验—修正”三个可观测的环节。这样不仅能看到模型最终答对没有还能看到它在哪一步开始出错。4. 适用场景与使用边界4.1 适合谁用这个框架适合以下四类人大模型评测工程师需要评估视觉语言模型的空间推理能力又不想被坐标阈值和后处理逻辑干扰。图像生成应用开发者在做文生图、图生图、布局生成时需要验证模型是否真的理解对象之间的位置关系。Prompt 研究员想测试不同 Prompt 描述对空间生成结果的影响例如“左边”“靠近”“在……之间”这类词是否被模型正确处理。数据增强与筛选人员在合成数据或模型输出中用空间一致性作为筛选条件过滤掉布局混乱的生成图。4.2 不适合什么场景这个框架不适合作为精确定位工具。如果任务本身需要毫米级、像素级的坐标输出比如机械臂抓取、自动驾驶目标定位那么生成式“画框”的方式不够精确还是应该用专用检测模型或 SLAM 方案。另外如果底层生成模型能力较弱评估可能会频繁出现“画不完整”“缺对象”这类基础错误这时候区分的是生成能力而不是空间认知能力。建议在应用框架前先确认底层模型的生成能力达到基线水平。4.3 使用边界与合规提醒如果框架需要输入真实图像、人脸图像、受版权保护的素材或者用于生成包含名人、真实人物肖像的空间场景必须提前获得相应授权。测试数据如果要公开应做匿名化处理。涉及商业发布或模型商用评估时也要确认数据集和模型的开源许可。5. 本地验证环境准备因为没有官方仓库的具体依赖列表我给出的是通用环境检查清单。无论你最终拿到的是requirements.txt还是 Docker 镜像下面这些项目都建议提前确认。5.1 系统与运行时操作系统LinuxUbuntu 20.04/22.04最省心Windows 需要关注 CUDA 和编译工具。Python建议 3.10 或 3.11很多视觉项目在 3.12 上会有依赖编译问题。包管理建议使用conda或venv隔离环境。Git用于拉取项目代码。# 创建一个独立的虚拟环境示例名称spatial_eval python -m venv spatial_eval source spatial_eval/bin/activate # Linux/macOS # 或 spatial_eval\Scripts\activate # Windows5.2 GPU 与驱动如果框架底层依赖 PyTorch Transformers Diffusers那么建议 NVIDIA GPU并提前确认驱动版本和 CUDA 版本。显存大小取决于你选择的生成模型如果只是画布局草图、小分辨率包围框模型参数量小显存需求会低一些。如果要生成高分辨率分割掩码或精细场景图显存需求会明显上升。我建议先用小模型跑通流程再逐步放大。不要一开始就上大模型否则容易把“框架 bug”和“显存不足”混在一起排查。5.3 模型文件与数据目录建议按下面的目录结构组织文件project_root/ ├── checkpoints/ # 模型权重文件 ├── datasets/ # 空间评测数据 │ ├── images/ # 输入图像 │ ├── annotations/ # 真值标注 │ └── prompts/ # 空间关系测试文本 ├── outputs/ # 生成结果与评估结果 ├── scripts/ # 启动、测试、批量脚本 ├── logs/ # 运行日志 └── config/ └── eval_config.yaml # 评估配置模型权重、测试数据、输出结果分开管理能避免批量任务把磁盘写满后找不出原因。5.4 端口占用检查如果框架提供 WebUI 或 API 服务启动前先检查端口是否空闲。# Linux / macOS lsof -i :7860 # Windows netstat -ano | findstr :7860如果端口被占用可以通过启动参数换一个例如--port 7861。6. 部署与启动方式由于目前没有公开的一键启动包这里提供三种通用启动方式你拿到实际项目后可以按对应入口替换。6.1 命令行启动如果项目提供 CLI 入口通常会支持类似的参数# 示例启动一次空间评估任务 python run_eval.py \ --model_type diffusers \ --model_path ./checkpoints/your_model \ --prompt 一个红色杯子在桌子的左边一本书在杯子的右边 \ --output_dir ./outputs/sample \ --agent_steps 3具体参数名要以项目的 README 为准。启动后观察日志里是否出现“任务开始”“Agent step 1/3”“生成完成”“评估通过”之类的状态位。6.2 Python 接口方式如果你不想走命令行也可以在 Python 脚本中直接加载评估器。下面是通用模板from spatial_eval import AgenticSpatialEvaluator evaluator AgenticSpatialEvaluator( model_nameyour-diffusion-model, devicecuda:0, max_agent_steps3, ) prompt 画一个客厅沙发在中间茶几在沙发前面台灯在沙发左侧。 result evaluator.evaluate(prompt) print(空间关系判断, result.spatial_relations) print(一次通过, result.first_try_correct) print(最终通过, result.final_correct) print(修正轮数, result.correction_rounds)这套代码示例是我按照常见Agentic Evaluator接口风格写的不代表官方 API 就是如此。你在实际项目里要用实际的类名和函数名替换。6.3 通过 diffusers / ComfyUI 接入如果你的底层生成模型是 diffusers 生态也可以用 WebUI/ComfyUI 暴露的接口来替代自定义模型加载。思路是先通过 ComfyUI 工作流生成空间草图再用评估脚本读取输出图像计算空间一致性。# 示例把生成结果交给评估脚本 python score_layout.py \ --generated_image ./outputs/layout.png \ --annotation ./datasets/annotations/layout.json \ --metric iou这种方式适合不愿意改代码、只想知道“我的工作流生成出来的布局靠不靠谱”的 ComfyUI 玩家。把评估脚本接到工作流末尾就能批量给每张图打一个空间合理性分数。7. 功能测试与效果验证框架是否能用建议按下面的测试维度逐项验证。每个维度里我都给出输入示例、判断标准和失败排查方向。7.1 单对象定位测试测试目的确认模型能否把单个对象画在指定区域。输入示例在画布左侧画一个蓝色杯子占画布四分之一大小。操作步骤用基础提示词生成一张布局图。检查输出图中是否出现杯子。检查杯子的位置是否在画布左侧。检查杯子是否被画成蓝色尺寸是否接近四分之一。判断成功标准对象存在且位置正确。颜色、大小等属性基本符合描述。没有出现“杯子画对但颜色错误”这类属性解耦失败。常见失败原因提示词中“左侧”和“杯子”被模型忽略了其中之一。生成模型本身不具备空间归因能力杯子可能被画到画面中央。7.2 多对象相对位置测试输入示例图片里有三个物体一个花瓶在桌子中间一本书在花瓶左边一个水杯在花瓶右边。操作步骤生成图像。用检测模块或人工查看三个对象是否存在。检查对象之间的左右关系是否符合描述。如果框架支持自动评分直接输出关系准确率。判断成功标准三个对象全部存在。书在花瓶左侧水杯在花瓶右侧。对象之间没有互相覆盖到无法识别的程度。常见失败原因模型生成了多个花瓶或多余对象。对象位置正确但类别混淆比如把水杯画成了茶壶。Agent 第一次错误但第二轮修正后正确这种情况也代表一定空间修正能力。7.3 遮挡与包含关系测试输入示例一张桌子桌面上有一个打开的笔记本电脑笔记本电脑的屏幕上显示一个圆形图表圆形的右侧有文字。操作步骤让模型生成图像。检查笔记本是否在桌面上。检查图表是否在屏幕里。检查文字是否在图表右侧。判断成功标准包含关系成立屏幕内的元素没有被画到屏幕外。层级关系成立桌子在底层笔记本在上一层屏幕内容在最上层。对象之间没有出现明显错误遮挡。这个测试对很多生成模型来说难度较高。如果模型连“包含”都画不对说明空间认知能力确实存在短板。7.4 空间否定与复杂关系测试输入示例窗台上没有花瓶花盆在窗台下面窗户上方有一个挂钩挂钩上没有任何物品。这是一个对抗性较强的 Prompt。普通模型经常会把“没有”的对象也画出来。判断成功标准画面中没有花瓶。花盆出现在窗台下方。挂钩在窗户上方而且是空的。常见失败原因模型忽略否定词直接把花瓶画了出来。模型对“上方”“下方”理解成固定的绝对位置而不是相对窗户的位置。7.5 Agentic 多轮修正能力测试测试目的确认框架里的 Agent 循环是否真正生效而不只是机械地重复生成。操作步骤先用一个模型容易出错的提示词比如“在沙发和电视之间放一个落地灯”。查看第一轮生成结果。如果不正确给 Agent 反馈“落地灯应该位于沙发和电视之间而不是在沙发右侧。请重新绘制。”观察第二轮结果是否修正。预期结果第二轮比第一轮空间关系更准确。第三轮如果仍失败说明模型空间推理能力有限。判断成功标准修正轮数越少模型的空间修正能力越强。如果反复修正后仍然失败说明该模型不适合作为 Agentic 空间评估的底层生成器。8. 接口 API 与批量评估空间评估框架如果只停留在脚本层面接入真实业务会比较麻烦。更合理的方案是把它封装成 HTTP 服务前端或任务队列通过接口调用。8.1 启动一个评估服务假设项目或你自己封装的服务入口是app.py启动方式类似python app.py --host 127.0.0.1 --port 8000启动后访问http://127.0.0.1:8000/docs可以查看接口文档。如果没有 Swagger 文档可以直接用 curl 测试。8.2 请求与响应示例下面是一个通用的接口请求格式{ prompt: 一个红色杯子在桌子的左边一个蓝色书在桌子的右边, image_input: null, agent_steps: 3, output_size: [512, 512], return_visualization: true }对应的响应可能是{ task_id: task_0001, status: completed, final_image_url: /outputs/task_0001.png, spatial_score: 0.86, first_try_score: 0.72, correction_rounds: 1, errors: [] }实际字段名以项目接口文档为准。以上只是帮助理解交互逻辑。8.3 用 Python 批量调接口如果要对一批空间描述文本做批量评估推荐把输入放在一个 JSON 文件里逐条调用接口并把结果写回 JSON。import requests import json api_url http://127.0.0.1:8000/evaluate input_file assets/prompts.json output_file results.json with open(input_file, r, encodingutf-8) as f: prompts json.load(f) results [] for item in prompts: payload { prompt: item[prompt], agent_steps: 3, } try: resp requests.post(api_url, jsonpayload, timeout120) resp.raise_for_status() data resp.json() data[prompt_id] item.get(id) results.append(data) except Exception as exc: results.append({ prompt_id: item.get(id), status: failed, error: str(exc), }) with open(output_file, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) print(f批量完成共 {len(results)} 条失败数{sum(1 for r in results if r[status] failed)})注意超时时间要按模型生成速度设置不要用默认 5 秒。批量任务建议加失败重试机制。结果文件要保留原始 Prompt方便回溯。接口服务如果只在本机使用建议绑定127.0.0.1不要暴露到公网。8.4 目录级批量评估如果不想走 HTTP 服务也可以直接用脚本遍历目录。假设每个图片对应一个prompt.txtfrom pathlib import Path import json src_dir Path(./datasets/prompts/) out_dir Path(./outputs/batch/) out_dir.mkdir(parentsTrue, exist_okTrue) for prompt_file in sorted(src_dir.glob(*.txt)): prompt prompt_file.read_text(encodingutf-8).strip() result { prompt_file: prompt_file.name, prompt: prompt, status: pending } # 这里替换成实际评估函数 # result evaluator.evaluate(prompt) dst_file out_dir / (prompt_file.stem .json) dst_file.write_text(json.dumps(result, ensure_asciiFalse, indent2), encodingutf-8)这样即便中间某个 Prompt 报错也不会影响整个目录的继续处理。9. 资源占用与性能观察9.1 看显存和 GPU 占用如果你使用了 PyTorch 或 diffusers 类模型启动服务后可以用nvidia-smi实时观察watch -n 1 nvidia-smi重点关注GPU 显存使用率是否持续走高。是否有多个进程同时占用显存。生成完成后显存是否被释放还是仍然被常驻模型占住。如果显存占用一直不下降很可能是模型常驻内存。这种情况下如果批量任务较小可以每次调用后清掉缓存。import torch # 生成任务完成后释放显存缓存 torch.cuda.empty_cache()9.2 影响性能的关键因素空间评估任务的耗时主要由下面几个部分构成生成模型的分辨率。分辨率从 512 提升到 1024显存和耗时通常会翻倍甚至更多。生成步数。步数越多耗时越长。Agent 循环轮数。每轮都会重新生成一次如果模型反复出错总耗时就是“单次生成耗时 × 修正轮数”。批量数。同时生成多张图会显著提高显存占用但能提高吞吐。是否使用 VAE 后处理、是否启用 ControlNet 等附加模块。9.3 降低资源占用的策略如果 GPU 显存有限可以按顺序尝试降低输出分辨率例如从 1024x1024 降到 512x512。降低生成步数从 30 步降到 20 步。使用半精度加载torch_dtypetorch.float16。关闭 Agent 循环中多余的图像保存逻辑。控制批量数先跑batch_size1验证单条任务是否正常。使用 CPU 推理时调低分辨率并准备足够的内存速度不会太快但能验证流程是否通顺。9.4 端口和进程管理服务启动后如果端口被占会导致访问失败。建议使用专门的进程管理工具例如tmux或supervisor。如果出现多个残留 Python 进程需要先确认进程号再结束。# 查找占用的 GPU 进程 nvidia-smi --query-compute-appspid,used_memory --formatcsv # 结束进程PID 换成实际数字 kill -9 PID10. 常见问题与排查方法问题现象可能原因排查方式解决方案项目启动后提示缺少依赖Python 环境不干净或版本不一致查看报错中的包名与版本要求用pip install -r requirements.txt重新安装模型下载失败网络问题或镜像源不稳定检查下载日志、确认代理配置切换到国内镜像源或手动下载权重到checkpoints目录显存不足 OOM生成分辨率太高、批量数过大、模型太大观察nvidia-smi中进程占用降低分辨率、减少批量数、开启半精度Agent 循环没有生效反馈信息没有传回生成模块打印每一轮的输入提示词与输出结果检查 Agent 状态管理代码确保反馈拼接正确生成的图像里没有出现目标对象底层生成模型能力不足或提示词被截断单独用底层模型生成一次换更强的生成模型或简化提示词空间关系准确但对象属性错误模型存在属性解耦问题对比多个提示词输出在 Prompt 中把属性写得更明确接口返回超时单次生成耗时过长查看日志中耗时记录增加客户端请求超时时间或改用异步任务队列批量任务中途卡住某个 Prompt 触发生成异常查看卡住的任务时间戳给批处理脚本增加单条超时跳转逻辑端口访问不通服务未启动或端口被占用使用curl测试本地端口换端口或重启服务输出图像与真值完全不匹配数据标注与提示词不对应检查数据集的 Prompt 与标注 JSON统一数据格式检查 ID 是否对应找不到官方模型权重路径项目没有明确说明权重存放位置阅读 README 或检查开源仓库存量按文档下载权重并放到正确路径11. 最佳实践与使用建议11.1 先跑通最小案例第一次不要直接上全量数据集。先准备 5 个最简单的空间 Prompt跑通“生成—评估—输出结果”全流程。确认没有依赖问题、模型能出图、评估打分能正常落盘再扩大规模。11.2 建立可复现配置把模型路径、分辨率、步数、Agent 轮数、评估指标全部写进配置文件中。使用 YAML 或 JSON 都可以。后续每次跑实验只改配置不动代码。model: name: your-generation-model device: cuda:0 dtype: float16 generation: width: 512 height: 512 steps: 25 agent: max_rounds: 3 feedback_style: natural_language evaluation: metrics: [iou, layout_similarity] save_visualization: true11.3 日志和结果分离建议每一个评估任务生成一个独立目录里面保存原始 Prompt。每轮生成的图像。每轮生成后的评估分数。最终结果 JSON。报错信息。这样即使 Agent 在第 2 轮报错你也能知道问题出在哪个环节。11.4 自动化批量任务要加保护批量任务里每个 Prompt 都要有独立的 try/except 和超时控制。不能因为单条数据异常拖垮整个评估队列。对失败任务进行重试时建议最多重试 2 次。超过次数直接标记为失败并写入日志。11.5 注意模型和数据合规如果框架用于商业评测或生成图像包含人像、品牌 Logo、版权内容、敏感场景务必确认授权情况。评估数据如果要公开建议做脱敏处理。人物肖像、声音、可识别身份信息不能在未授权前提下进入生成和评估流程。12. 总结与下一步这个框架最值得尝试的点是它把“空间认知评估”从坐标数值比较变成了生成结果比较。坐标输出更接近“填空题”而生成式空间输出更接近“实操题”。后者虽然更难打分但测出来的东西更接近真实空间理解。如果你准备动手验证最先应该测的是“多对象相对位置”和“空间否定句”这两类任务。这两个场景最能暴露模型的真实空间推理短板也是 Agentic 修正机制最有发挥空间的地方。最容易踩的坑有三个一是底层生成模型能力不足导致评估结果分不清是“模型不会画”还是“模型不理解空间”建议先单独确认底层模型的基础能力二是没有给 Agent 循环写反馈拼接逻辑导致第二轮和第一轮完全相同三是批量任务缺少超时控制单条异常把整个队列卡死。后续可以继续扩展的方向包括把框架接入 ComfyUI 工作流作为文生图质量的自动筛选器把评估分数当作强化学习中的奖励信号用于微调空间理解能力强的生成模型或者把 Agent 循环的修正轨迹作为训练数据让模型学会自己发现自己画错了。这篇文章适合先收藏等你需要评测空间理解类模型时再按里面的验证流程跑一遍。先把小案例跑通再上批量任务空间认知评估这件事就可以做得很有说服力。