空间智能是最近几年大模型讨论里被频繁提到但评估方式仍然混乱的能力维度。人类判断一个模型是否理解“桌子左边”“杯子前方”不会要求它输出一组坐标而是看它能否在真实或模拟环境中做出正确布局。浙江大学研究团队提出的一种 Agentic 空间认知评估框架正是顺着这个思路让生成式模型把空间理解“画”出来而不是强迫 LLM 在文本里输出数值坐标。这个转变看起来只是从数值输出变成图像输出背后却涉及任务定义、动作空间、评估指标和 Agent 循环设计的一系列调整。这篇文章会围绕这个框架思路拆解它的设计动机、核心模块、一个简化版原型实现以及落地时容易踩的坑。适合关注多模态大模型、具身智能、模型评估和 Agent 开发的同学阅读。1. 为什么“输出坐标”这条评估路径走不远1.1 LLM 用文本表达空间时的信息瓶颈大语言模型本质上是把文本 token 序列映射成下一个 token 的概率分布。即使最强的 LLM也只能在它学过的文本分布里“猜测”坐标数字。对于“把杯子放在桌子右侧 50 厘米处”这个问题模型可能会回答“(154, 320)”但它并不具备连续几何推理能力它只是在文本统计规律里找到了一个看起来合理的数值。问题在于空间场景往往是连续的、关系型的。两把椅子之间的“中间位置”不是一个唯一坐标而是一条线段一个物体“在另一个物体前方”取决于观察角度、朝向和基准线。LLM 如果只能输出坐标就必须把一组连续变化的空间关系压缩成若干个离散数字。这种压缩会丢失大量空间语义比如“离桌子很近但没碰到”和“在桌子正前方 10 厘米”在坐标上可能只有很小的差异但语义差别很大。因此如果想要评估一个模型是不是具备空间智能应该给它一种更适合表达空间结构的方式——图像、布局、拓扑关系而不是坐标数值。生成式模型擅长从语义描述生成视觉结构正好可以在空间认知评估中充当“输出通道”。1.2 坐标输出评估的五个具体问题即使不考虑 LLM 的能力极限强迫模型输出坐标来评估空间认知工程上也非常别扭。以下五个问题在实际项目里最容易遇到。问题典型表现产生的原因数值精度不稳定模型多次尝试同一任务坐标相差很大LLM 生成数字只靠文本概率缺少规约和验证坐标基准难对齐模型认为的“左上角”和评估方实现的“左上角”不一致没有统一坐标系、缩放比例和原点定义空间关系无法直接体现坐标正确但摆放后互相遮挡、重叠坐标本身不包含物体尺寸、方向和碰撞约束评估粒度粗糙答案只能判对或错无法判断“接近正确”坐标距离阈值需要人工拍脑袋且不同任务语义不一致场景扩展性差换一张地图或换一种任务定义坐标体系就要重做坐标本质上是任务相关的局部编码不具备通用性这几点不是某个模型的问题而是评估设计的问题。如果我们考核的重点是空间关系理解就应该给模型一个能够自然表达关系的输出空间。坐标不是关系坐标只是从关系推导出来的一种结果。1.3 生成式输出把空间认知拉回可视世界生成式模型有一个特点它可以把一个描述性的语义空间转换成一个可被人类和算法反复查看的视觉空间。例如让模型“画”出桌子右侧有一个杯子生成的图像即便不是真实照片也能直观反映出左右关系、遮挡关系、远近尺度。这种做法的本质是改变评估接口。旧接口模型输出坐标评估器解析数字。新接口模型输出动作或语义元素生成式模型渲染成场景评估器观察场景。把空间认知评估从“数字比较”变成“场景生成与场景理解”能同时测两种能力模型是否理解了空间语义以及模型是否能把自己的理解转换成可执行的空间结构。它也更接近人类认知心理实验中常用的“摆放任务”设计。2. Agentic 空间认知评估框架的设计思路2.1 整体流程不是让模型直接回答而是让模型在环境中“做”传统评估是一次性问答给定问题取模型回答和标准答案比较。Agentic 评估则不同它把评估过程设计成一个多步交互闭环。框架的核心流程可以概括为五步任务管理器生成自然语言空间任务例如“请把蓝色方块放到红色圆形上方”。Agent 接收任务和当前场景状态输出一个动作指令而不是直接输出最终答案。生成式模型或空间模拟器执行该动作将场景状态更新并渲染成图像或结构化场景图。评估器检查执行后的场景是否满足任务要求并反馈给 Agent。Agent 根据反馈继续尝试直到满足终止条件。这个流程的关键在于空间任务不是靠一次完整答案来判定而是靠一系列动作和中间结果来评估。这种范式天然适合 Agentic AI 的测试场景因为 Agent 的每一步决策都可能影响最终布局。伪代码形式的整体流程如下def run_evaluation(task, agent, renderer, evaluator, max_steps5): state renderer.empty_state() for step in range(max_steps): action agent.generate_action(task, state.to_prompt()) state renderer.apply_action(state, action) scene renderer.render(state) is_done, score, feedback evaluator.evaluate(task, state, scene) if is_done: return {solved: True, score: score, steps: step 1, scene: scene} return {solved: False, score: score, steps: max_steps, scene: scene}在这个循环里Agent 不一定要是 LLM它可以是任何能输出动作的模型生成式模型在这里也不是为了“画得好看”而是把不可直接观察的空间状态变成可评估的视觉产物。2.2 四个核心模块任何 Agentic 空间认知评估框架都可以拆成四个模块任务管理器、Agent、渲染器、评估器。任务管理器负责构造任务集合。空间任务至少包括三类关系摆放A 在 B 的右侧、路径规划从起点走到终点并避开障碍、布局完成在限定区域内安排多个物体。在实际项目中任务管理器应该输出结构化任务描述而不能只给一句话因为机器解析“把球放到桌子的左边”时需要知道“桌子”有哪些候选实体、坐标系是什么、成功条件是什么。Agent 是待评估模型。它可以接收文本状态描述也可以接收渲染后的图像。在框架原型里通常先让 Agent 输出文本动作后续再扩展为直接输出图像操作。这里最大的设计约束是动作空间。如果动作空间仍然是“输出坐标”那就又回到了起点。推荐的做法是让 Agent 输出语义动作例如“move table left”或“place cube above circle”再由渲染器执行这些语义动作。渲染器把动作变成空间状态。最轻量的方式是使用规则模拟器物体用矩形框表示关系由几何计算决定。更接近前沿的方式是调用扩散模型生成图片例如用 Stable Diffusion 或 ComfyUI 工作流生成一张包含指定物体的场景图。渲染器不一定需要和 LLM 在同一台机器上两者可以通过 API 解耦但如果是在本地开发要注意显存、端口和工作流版本。评估器负责判断最终状态是否满足任务要求。它可以由规则计算、视觉模型识别或人工复核组成。规则计算速度快、可解释性强适合作为 ground truth视觉模型识别适合处理图像中的遮挡和模糊场景人工复核适合小样本评测。生产环境一般建议三层结合不能只依赖单一定性判断。2.3 为什么“Agentic”是这种评估方式的必要条件空间认知不是一次作答可以测完的。一个模型能正确回答“杯子在桌子右边”不代表它能在没有桌子的情况下自己规划出一个新杯子放在合适位置更不代表它能通过多步操作调整布局。使用 Agentic 方式可以让模型在尝试过程中暴露更多信息模型第一次动作是否正确。模型能否理解反馈并修正错误。模型面对开放空间时能否自主选择稳定路径。模型是否会在多余动作中破坏已有的正确布局。这些信息在一次性问答评估里全部丢失。Agentic 评估的价值不只是“多给模型几次机会”而是把空间认知从静态知识测试变成动态决策测试。Agentic AI 当前的一个核心挑战就是如何在长周期任务中保持目标一致性空间认知评估正好提供了一个非常适合检验 Agent 规划能力的环境。3. 从零搭建一个最小原型这一节实现一个简化版的原型。它不追求真实扩散模型渲染而是用一个规则渲染器先把框架跑通。真实项目里可以把 renderer 替换成 ComfyUI 或 Stable Diffusion 后端但原型阶段的重点是验证动作接口和评估逻辑。3.1 环境准备原型使用 Python 3.9核心依赖只有 Pillow 和 numpy。如果后续要接入真实生成式模型再按需要安装 diffusers、torch 或请求 ComfyUI API。python -m venv .venv source .venv/bin/activate pip install pillow numpy这里不把 PyTorch 作为前置依赖因为框架的价值在于评估逻辑不在于具体生成器。生产环境如果要接视觉生成模型通常需要单独部署一台带 GPU 的推理服务Agent 进程和渲染服务可以通过 HTTP 通信。也就是说LLM 和 ComfyUI 不要求必须在同一台电脑上但你需要约定好图片输入输出的格式和任务回调地址。3.2 定义空间场景和渲染器场景用一组矩形物体表示。每个物体有名称、类别、位置、尺寸和颜色。渲染器把物体绘制成一张 256x256 的图片用于后续可视化。from dataclasses import dataclass, field from typing import List, Dict dataclass class SceneObject: name: str category: str x: int 0 y: int 0 width: int 30 height: int 30 color: str blue dataclass class Scene: width: int 256 height: int 256 objects: List[SceneObject] field(default_factorylist) def to_prompt(self) - str: lines [] for obj in self.objects: lines.append(f{obj.name}({obj.category}): at {obj.x},{obj.y}) return \n.join(lines)渲染器可以先用 Pillow 画矩形框后续再替换成真实图片生成模型。from PIL import Image, ImageDraw def render_scene(scene: Scene) - Image.Image: img Image.new(RGB, (scene.width, scene.height), white) draw ImageDraw.Draw(img) for obj in scene.objects: x0 obj.x - obj.width // 2 y0 obj.y - obj.height // 2 x1 x0 obj.width y1 y0 obj.height draw.rectangle([x0, y0, x1, y1], fillobj.color, outlineblack) return img这个阶段只做基础绘制不做透视、遮挡和光照。评估逻辑必须能脱离视觉效果独立工作否则生成器的画风会影响评估结果。3.3 给 Agent 定义一套不依赖坐标的动作接口为了让评估框架严格避免“通过坐标作答”Agent 的动作接口只提供语义操作。示例动作集合包括place、move、remove。下面是一个动作格式action { action: place, object: cup, category: cup, relation_target: table, relation: to_the_right_of, distance: medium }注意这里没有 x/y 坐标。Agent 只需要描述“在什么位置放什么物体、相对谁是什么关系”坐标由渲染器依据规则计算。这样设计的原因很简单如果 Agent 仍然输出坐标那么生成式模型只是变成了一个后处理画图工具模型的空间认知仍然停留在数字猜测阶段。下面是一个简化的关系位置求解函数演示渲染器如何把语义关系转换为坐标def resolve_position(scene: Scene, target_name: str, relation: str, distance: str): target next(obj for obj in scene.objects if obj.name target_name) delta 40 if distance medium else 60 if relation to_the_right_of: return target.x delta, target.y if relation to_the_left_of: return target.x - delta, target.y if relation above: return target.x, target.y - delta if relation below: return target.x, target.y delta raise ValueError(funsupported relation: {relation})实际框架中关系计算会更复杂比如需要考虑物体尺寸、边界、朝向和多个约束条件。但核心原则一致Agent 产生语义意图坐标是环境层解析的产物。3.4 评估器实现评估器检查最终场景中物体之间的关系是否满足任务要求。这里用结构化关系检查作为 ground truth而不是直接让视觉模型判断。def evaluate_scene(scene: Scene, task: dict) - tuple[bool, float, str]: required task[target] relation required[relation] target_name required[target_object] obj_name required[object] try: obj next(o for o in scene.objects if o.name obj_name) target next(o for o in scene.objects if o.name target_name) except StopIteration: return False, 0.0, missing object or target obj_center (obj.x, obj.y) target_center (target.x, target.y) distance_threshold 60 if relation to_the_right_of: ok obj_center[0] target_center[0] distance_threshold success_score 1.0 if ok else 0.2 feedback right relation if ok else not enough to the right elif relation above: ok obj_center[1] target_center[1] - distance_threshold success_score 1.0 if ok else 0.2 feedback above relation if ok else not high enough else: ok False success_score 0.0 feedback frelation {relation} not implemented return ok, success_score, feedback评估器要返回三个值是否完成、奖励分数、反馈文本。Agent 的下一次动作可以依赖反馈文本进行修正。3.5 主流程和运行结果主流程把 Agent、渲染器、评估器串起来。下面的 Agent 是一个模拟实现假设它能调用任意 LLM 的对话补全接口但在原型里用固定逻辑代替。def mock_agent_action(task, scene_text, feedback): # 实际项目中这里调用 LLM输入 task scene_text feedback输出结构化动作 return { action: place, object: cup, category: cup, relation_target: table, relation: to_the_right_of, distance: medium, } def run(task, max_steps3): scene Scene() scene.objects.append(SceneObject(nametable, categorytable, x120, y128, width60, height20, colorbrown)) feedback for step in range(max_steps): action mock_agent_action(task, scene.to_prompt(), feedback) if action[action] place: ox, oy resolve_position(scene, action[relation_target], action[relation], action[distance]) scene.objects.append(SceneObject(nameaction[object], categorycup, xox, yoy, colorgray)) done, score, feedback evaluate_scene(scene, task) if done: img render_scene(scene) img.save(fresult_step_{step}.png) return {solved: True, steps: step 1, score: score, scene: scene} return {solved: False, steps: max_steps, score: score, scene: scene} task {target: {object: cup, target_object: table, relation: to_the_right_of}} result run(task) print(solved:, result[solved], score:, result[score], steps:, result[steps])运行后的预期结果中solved为 True场景渲染图片里桌子的右侧会出现一个灰色矩形杯表示关系满足。4. 评估指标和关键参数设计4.1 动作空间设计原则Agentic 空间评估最容易被忽略的是动作空间。设计动作空间时有三个原则第一动作必须是语义级的不能是像素级或坐标级。例如“place object A to the right of B”是好的动作而“set A.x 140, A.y 128”不是。后者会绕回坐标评估。第二动作集合必须覆盖常见空间任务的原子操作。至少包含放置、移动、删除、旋转和缩放。否则 Agent 无法完成复杂任务。第三动作必须可回滚。多步任务中Agent 可能把一个物体放错位置之后必须允许它重新移动或删除否则评估只能测一次摆放能力测不了修正能力。常见动作空间如下动作参数说明placeobject, relation_target, relation, distance生成一个新物体并放置在目标相对位置moveobject, relation_target, relation, distance移动已有物体到新关系位置removeobject删除已有物体rotateobject, angle旋转物体测试朝向理解set_constraintobject, min_distance_to, value设置空间约束适合复杂布局任务4.2 评估指标评估指标不能只看“最终有没有成功”还要看过程质量。建议记录以下几类指标。指标计算方式关注点任务成功率完成任务次数 / 总测试次数空间语义理解是否足够准确平均步数成功任务使用的总步数 / 成功任务数Agent 是否高效是否反复试错动作合法率合法动作次数 / 总动作次数是否输出越界、目标缺失等非法动作关系准确率满足目标关系数量 / 全部目标关系数量多约束任务下逐项拆解能力场景一致性多次运行同一任务的布局 IoU 或距离标准差模型是否稳定还是靠随机猜修正成功率第一次错误后第二次是否修正是否具备利用反馈调整的能力其中“修正成功率”是 Agentic 评估独有的指标传统坐标问答无法测试。这个指标能反映模型的空间推理是否具有闭环能力。4.3 关键参数表原型实现中有几个影响评估结果的关键参数需要根据任务复杂度设置。参数默认值影响调大影响调小影响max_steps5最大尝试步数容忍更多试错但可能隐藏低效策略更容易失败严格测试一次性决策能力distance_threshold60关系判断容差更宽松容易误判为“在右侧”更严格但可能因坐标解析误差而失败render_size256渲染分辨率图片更清晰生成成本更高节省资源但小物体可能看不清action_modesemantic动作输出格式可扩展复杂动作限制表达空间feedback_leveltext反馈粒度模型更容易修正错误反馈模糊模型难以定位问题4.4 与坐标输出评估的对比下面的对比表可以帮你快速向团队解释为什么新的框架值得做。维度坐标输出评估Agentic 生成式评估输出形式数字坐标语义动作 图像/场景测量能力数字记忆空间语义理解和决策可解释性坐标对错无法解释每一步动作可见可回放错误分析只能看偏差值能定位错在哪个关系或哪一步场景扩展换地图要重新定义坐标换任务只需改任务管理器工程复杂度低中高需要渲染器和状态管理如果只是验证一个模型能不能记住图片中的大概坐标坐标输出够用。但如果目标是评估“空间智能”本身Agentic 生成式评估明显更合理。5. 运行验证与结果解读5.1 最小验证用例用上一节的原型跑三个任务放置把 cup 放到 table 右侧。移动把 box 移到 circle 上方。多约束把 lamp 放到 desk 左边并且离 wall 至少 40 像素。每个任务跑 10 次记录成功率、平均步数、动作合法率。5.2 预期输出正常通过时运行日志大概长这样task 1: solvedTrue, steps1, score1.0, legal_rate1.0 task 2: solvedTrue, steps2, score1.0, legal_rate1.0 task 3: solvedFalse, steps5, score0.6, legal_rate0.8第三个任务失败可能有两个原因模型没有输出set_constraint动作或者约束关系解析器不支持。建议先检查任务是否设计得过于复杂再检查 Agent 是否理解动作空间。5.3 如何判断模型是真正理解还是猜对一个评估框架如果只报一个成功率很容易被随机策略干扰。要判断模型是否真正具备空间智能至少做三个对照实验。首先是动作空间消融。给 Agent 提供一个“随机动作”基线如果随机动作也能得高分说明评估器太宽松。正常情况下随机动作成功率应该远低于一个基础 LLM。其次是场景干扰。同一个任务换用不同尺寸、不同初始位置成功率如果急剧下降说明模型只是在记训练时的位置模式。最后是反事实任务。例如把“桌子右侧”改成“桌子右后方”模型如果仍然只知道“右”而忽略“后”就能暴露出对方向组合的薄弱理解。5.4 学习环境与生产环境的差异原型阶段用规则渲染器很容易跑通。生产中接入真实扩散模型做渲染时需要考虑几个额外问题。第一渲染服务建议独立部署。LLM 和 ComfyUI 不要求在同一台电脑上可以通过 API 调用。否则生成式模型的显存占用会影响 LLM 的批量推理。第二视觉评估不能替代结构化状态。生成图像可能因为画风问题导致视觉识别失败但结构化状态里的物体位置是可靠的。生产环境建议始终维护一个结构化状态表作为 ground truth视觉模型只用于额外一致性校验。第三评估任务需要版本管理。空间任务描述、动作空间、关系解析规则都会迭代任何改动都可能让历史评估结果不可比。最好给每次评估打上任务版本号。6. 常见问题与排查路径6.1 模型仍然输出坐标而不是语义动作现象Agent 返回的动作里出现x、y字段甚至直接输出一段带坐标的 JSON。原因Base LLM 训练数据里包含大量“位置信息用坐标表达”的示例模型默认沿用这种模式。如果 prompt 里没有明确约束动作空间模型倾向于回到坐标输出。排查方式打印 Agent 原始输出检查是否有坐标数字检查 prompt 是否给定了合法的动作枚举。解决方式在 prompt 中明确列出可用动作并给出几个语义动作示例。更稳妥的做法是使用工具调用或结构化输出让模型只能选择合法动作字段。对于不合法输出可以直接丢弃并要求重新生成。6.2 渲染器生成的内容不稳定同一动作两次结果不一致现象使用真实扩散模型生成图像时同一句话生成的布局每次差异很大评估结果不稳定。原因扩散模型本质上是采样过程随机种子会影响结果。而且文本生成图像模型对空间关系的表达能力有限可能导致“桌子右侧的杯子”被画成“桌子前面”。排查方式固定随机种子比较两次生成的差别检查 prompt 是否包含额外位置词查看渲染器是否对输出图像做了裁剪或后处理。解决方式原型阶段先用规则渲染器做评估视觉模型只做二次展示如果必须用扩散模型可对生成的图像做后处理约束比如根据语义分割结果把物体移动到目标区域。评估指标也要以结构化状态为主。6.3 Agent 来回重复无效动作步数耗尽现象模型在多个任务上不断输出相同或者相近的动作分数始终停留在低分。原因反馈文本太模糊模型无法判断应该修改哪个物体或者max_steps过大让模型有机会试错而不优化策略。排查方式在每一轮打印反馈文本和动作观察模型是否根据反馈改变动作检查动作空间是否缺少修正操作比如move和remove。解决方式增加反馈的定向性例如“cup 仍然在 table 上方需要向右移动”而不是只返回“失败”。也可以缩短max_steps强制模型提高首步质量对于需要长期规划的任务单独引入规划器模块。6.4 评估结果和人工判断不一致现象评估器认为任务未完成但人类看渲染图觉得布局合理或者反过来评估器判定成功但人类明显看出物体遮挡严重。原因规则评估器只检查了物体中心点距离关系没有检查遮挡、边界和碰撞或者评估器的容差过小。排查方式保存最终渲染图片和结构化状态逐项对照评估器的判断条件。解决方式评估器增加“碰撞检测”“遮挡检测”“边界检查”。例如物体矩形框相交比例超过一定阈值就降低分数。另一个重要做法是加入人工复核抽样定期检查评估器阈值是否合理。7. 最佳实践与扩展方向7.1 评估框架有效性检查清单在正式使用这套框架之前建议先回答以下问题动作空间是否完全排除了坐标输出渲染器是否维护一份结构化状态而不是只有图片评估器是否被随机动作基线验证过是否存在“只要随机放置一个物体就能成功”的简单任务是否考虑了遮挡、碰撞、边界等物理约束每轮是否给 Agent 提供了可执行的反馈是否固定了任务版本和渲染器版本如果这些问题的答案有任何一个是“否”评估结果都需要打折扣。7.2 空间任务设计清单生成高质量空间任务比实现框架本身更需要经验。设计任务时可以从下面几个维度逐步加码单关系 vs 多关系先测“A 在 B 右侧”再测“A 在 B 右侧且 C 在 A 下方”。静态 vs 动态先测“放一个物体”再测“移动一个物体并保持其他物体不动”。绝对 vs 相对先测“物体在区域右上角”再测“物体在另一个物体前方偏左”。无遮挡 vs 有遮挡先测“两个物体无重叠”再测“一个物体部分遮挡另一个物体时如何描述”。无歧义 vs 有歧义加入“之间”“靠近”等模糊概念测试模型是否能主动澄清或选择合理默认值。任务库建议按照难度分级每个级别至少 20 个任务保证评估稳定性。7.3 环境部署检查清单如果想在生产环境接入视觉生成模型部署前检查这些项LLM 服务和渲染服务是否通过 API 解耦两条服务之间是否有超时、重试和降级策略生成模型是否固定了模型版本、采样器和种子策略图片传输格式是 base64 还是文件 URL大小是否可控渲染服务是否具备 GPU 资源监控和排队机制是否保存了每轮动作、场景状态、渲染图片和评估日志方便回溯这里的平衡点是评估主链路尽量轻量重资源操作放到独立渲染服务。不要把视觉生成模型嵌进 Agent 的主推理链路否则一次评估的延迟和硬件成本都会难以接受。7.4 扩展方向Agentic 空间认知评估框架有两个自然延伸方向。第一个方向是具身智能。算法评估里“摆放杯子”可以迁移到机器人操作任务中。机器人收到语义指令后生成操作序列仿真器渲染场景或真实环境反馈传感器数据评估器判断是否完成任务。这种评估可以直接复用动作空间和结构化状态设计。第二个方向是训练数据增强。一旦评估框架稳定运行它生成的大量“任务-动作-场景-反馈”轨迹可以作为多模态模型的训练语料。把成功和失败的轨迹都保存下来再用 Agentic RAG 的方式在推理时检索相似空间布局实例可以让模型快速理解新场景。从更本质的角度看空间认知评估不应该停留在“模型能不能说出空间关系”的文本层面而应该测量“模型能不能在空间里做出正确决策”。浙大提出的这个方向核心贡献是让生成式模型成为空间语义的输出媒介让 LLM 的文本能力与空间推理能力解耦。实际落地时不需要一开始就追求真实图像生成先把动作空间、状态管理、关系评估器设计好再逐步接入更复杂的渲染后端会是一条更稳妥的路径。对刚接触这个方向的同学可以先从本文的规则渲染原型开始跑通一个任务再用自己的 LLM 替换 mock agent观察它在多步空间任务里会暴露哪些问题。这一步做完再讨论生成式图像和更复杂的评估指标思路会清晰得多。
基于生成式模型的Agentic空间认知评估框架解析
空间智能是最近几年大模型讨论里被频繁提到但评估方式仍然混乱的能力维度。人类判断一个模型是否理解“桌子左边”“杯子前方”不会要求它输出一组坐标而是看它能否在真实或模拟环境中做出正确布局。浙江大学研究团队提出的一种 Agentic 空间认知评估框架正是顺着这个思路让生成式模型把空间理解“画”出来而不是强迫 LLM 在文本里输出数值坐标。这个转变看起来只是从数值输出变成图像输出背后却涉及任务定义、动作空间、评估指标和 Agent 循环设计的一系列调整。这篇文章会围绕这个框架思路拆解它的设计动机、核心模块、一个简化版原型实现以及落地时容易踩的坑。适合关注多模态大模型、具身智能、模型评估和 Agent 开发的同学阅读。1. 为什么“输出坐标”这条评估路径走不远1.1 LLM 用文本表达空间时的信息瓶颈大语言模型本质上是把文本 token 序列映射成下一个 token 的概率分布。即使最强的 LLM也只能在它学过的文本分布里“猜测”坐标数字。对于“把杯子放在桌子右侧 50 厘米处”这个问题模型可能会回答“(154, 320)”但它并不具备连续几何推理能力它只是在文本统计规律里找到了一个看起来合理的数值。问题在于空间场景往往是连续的、关系型的。两把椅子之间的“中间位置”不是一个唯一坐标而是一条线段一个物体“在另一个物体前方”取决于观察角度、朝向和基准线。LLM 如果只能输出坐标就必须把一组连续变化的空间关系压缩成若干个离散数字。这种压缩会丢失大量空间语义比如“离桌子很近但没碰到”和“在桌子正前方 10 厘米”在坐标上可能只有很小的差异但语义差别很大。因此如果想要评估一个模型是不是具备空间智能应该给它一种更适合表达空间结构的方式——图像、布局、拓扑关系而不是坐标数值。生成式模型擅长从语义描述生成视觉结构正好可以在空间认知评估中充当“输出通道”。1.2 坐标输出评估的五个具体问题即使不考虑 LLM 的能力极限强迫模型输出坐标来评估空间认知工程上也非常别扭。以下五个问题在实际项目里最容易遇到。问题典型表现产生的原因数值精度不稳定模型多次尝试同一任务坐标相差很大LLM 生成数字只靠文本概率缺少规约和验证坐标基准难对齐模型认为的“左上角”和评估方实现的“左上角”不一致没有统一坐标系、缩放比例和原点定义空间关系无法直接体现坐标正确但摆放后互相遮挡、重叠坐标本身不包含物体尺寸、方向和碰撞约束评估粒度粗糙答案只能判对或错无法判断“接近正确”坐标距离阈值需要人工拍脑袋且不同任务语义不一致场景扩展性差换一张地图或换一种任务定义坐标体系就要重做坐标本质上是任务相关的局部编码不具备通用性这几点不是某个模型的问题而是评估设计的问题。如果我们考核的重点是空间关系理解就应该给模型一个能够自然表达关系的输出空间。坐标不是关系坐标只是从关系推导出来的一种结果。1.3 生成式输出把空间认知拉回可视世界生成式模型有一个特点它可以把一个描述性的语义空间转换成一个可被人类和算法反复查看的视觉空间。例如让模型“画”出桌子右侧有一个杯子生成的图像即便不是真实照片也能直观反映出左右关系、遮挡关系、远近尺度。这种做法的本质是改变评估接口。旧接口模型输出坐标评估器解析数字。新接口模型输出动作或语义元素生成式模型渲染成场景评估器观察场景。把空间认知评估从“数字比较”变成“场景生成与场景理解”能同时测两种能力模型是否理解了空间语义以及模型是否能把自己的理解转换成可执行的空间结构。它也更接近人类认知心理实验中常用的“摆放任务”设计。2. Agentic 空间认知评估框架的设计思路2.1 整体流程不是让模型直接回答而是让模型在环境中“做”传统评估是一次性问答给定问题取模型回答和标准答案比较。Agentic 评估则不同它把评估过程设计成一个多步交互闭环。框架的核心流程可以概括为五步任务管理器生成自然语言空间任务例如“请把蓝色方块放到红色圆形上方”。Agent 接收任务和当前场景状态输出一个动作指令而不是直接输出最终答案。生成式模型或空间模拟器执行该动作将场景状态更新并渲染成图像或结构化场景图。评估器检查执行后的场景是否满足任务要求并反馈给 Agent。Agent 根据反馈继续尝试直到满足终止条件。这个流程的关键在于空间任务不是靠一次完整答案来判定而是靠一系列动作和中间结果来评估。这种范式天然适合 Agentic AI 的测试场景因为 Agent 的每一步决策都可能影响最终布局。伪代码形式的整体流程如下def run_evaluation(task, agent, renderer, evaluator, max_steps5): state renderer.empty_state() for step in range(max_steps): action agent.generate_action(task, state.to_prompt()) state renderer.apply_action(state, action) scene renderer.render(state) is_done, score, feedback evaluator.evaluate(task, state, scene) if is_done: return {solved: True, score: score, steps: step 1, scene: scene} return {solved: False, score: score, steps: max_steps, scene: scene}在这个循环里Agent 不一定要是 LLM它可以是任何能输出动作的模型生成式模型在这里也不是为了“画得好看”而是把不可直接观察的空间状态变成可评估的视觉产物。2.2 四个核心模块任何 Agentic 空间认知评估框架都可以拆成四个模块任务管理器、Agent、渲染器、评估器。任务管理器负责构造任务集合。空间任务至少包括三类关系摆放A 在 B 的右侧、路径规划从起点走到终点并避开障碍、布局完成在限定区域内安排多个物体。在实际项目中任务管理器应该输出结构化任务描述而不能只给一句话因为机器解析“把球放到桌子的左边”时需要知道“桌子”有哪些候选实体、坐标系是什么、成功条件是什么。Agent 是待评估模型。它可以接收文本状态描述也可以接收渲染后的图像。在框架原型里通常先让 Agent 输出文本动作后续再扩展为直接输出图像操作。这里最大的设计约束是动作空间。如果动作空间仍然是“输出坐标”那就又回到了起点。推荐的做法是让 Agent 输出语义动作例如“move table left”或“place cube above circle”再由渲染器执行这些语义动作。渲染器把动作变成空间状态。最轻量的方式是使用规则模拟器物体用矩形框表示关系由几何计算决定。更接近前沿的方式是调用扩散模型生成图片例如用 Stable Diffusion 或 ComfyUI 工作流生成一张包含指定物体的场景图。渲染器不一定需要和 LLM 在同一台机器上两者可以通过 API 解耦但如果是在本地开发要注意显存、端口和工作流版本。评估器负责判断最终状态是否满足任务要求。它可以由规则计算、视觉模型识别或人工复核组成。规则计算速度快、可解释性强适合作为 ground truth视觉模型识别适合处理图像中的遮挡和模糊场景人工复核适合小样本评测。生产环境一般建议三层结合不能只依赖单一定性判断。2.3 为什么“Agentic”是这种评估方式的必要条件空间认知不是一次作答可以测完的。一个模型能正确回答“杯子在桌子右边”不代表它能在没有桌子的情况下自己规划出一个新杯子放在合适位置更不代表它能通过多步操作调整布局。使用 Agentic 方式可以让模型在尝试过程中暴露更多信息模型第一次动作是否正确。模型能否理解反馈并修正错误。模型面对开放空间时能否自主选择稳定路径。模型是否会在多余动作中破坏已有的正确布局。这些信息在一次性问答评估里全部丢失。Agentic 评估的价值不只是“多给模型几次机会”而是把空间认知从静态知识测试变成动态决策测试。Agentic AI 当前的一个核心挑战就是如何在长周期任务中保持目标一致性空间认知评估正好提供了一个非常适合检验 Agent 规划能力的环境。3. 从零搭建一个最小原型这一节实现一个简化版的原型。它不追求真实扩散模型渲染而是用一个规则渲染器先把框架跑通。真实项目里可以把 renderer 替换成 ComfyUI 或 Stable Diffusion 后端但原型阶段的重点是验证动作接口和评估逻辑。3.1 环境准备原型使用 Python 3.9核心依赖只有 Pillow 和 numpy。如果后续要接入真实生成式模型再按需要安装 diffusers、torch 或请求 ComfyUI API。python -m venv .venv source .venv/bin/activate pip install pillow numpy这里不把 PyTorch 作为前置依赖因为框架的价值在于评估逻辑不在于具体生成器。生产环境如果要接视觉生成模型通常需要单独部署一台带 GPU 的推理服务Agent 进程和渲染服务可以通过 HTTP 通信。也就是说LLM 和 ComfyUI 不要求必须在同一台电脑上但你需要约定好图片输入输出的格式和任务回调地址。3.2 定义空间场景和渲染器场景用一组矩形物体表示。每个物体有名称、类别、位置、尺寸和颜色。渲染器把物体绘制成一张 256x256 的图片用于后续可视化。from dataclasses import dataclass, field from typing import List, Dict dataclass class SceneObject: name: str category: str x: int 0 y: int 0 width: int 30 height: int 30 color: str blue dataclass class Scene: width: int 256 height: int 256 objects: List[SceneObject] field(default_factorylist) def to_prompt(self) - str: lines [] for obj in self.objects: lines.append(f{obj.name}({obj.category}): at {obj.x},{obj.y}) return \n.join(lines)渲染器可以先用 Pillow 画矩形框后续再替换成真实图片生成模型。from PIL import Image, ImageDraw def render_scene(scene: Scene) - Image.Image: img Image.new(RGB, (scene.width, scene.height), white) draw ImageDraw.Draw(img) for obj in scene.objects: x0 obj.x - obj.width // 2 y0 obj.y - obj.height // 2 x1 x0 obj.width y1 y0 obj.height draw.rectangle([x0, y0, x1, y1], fillobj.color, outlineblack) return img这个阶段只做基础绘制不做透视、遮挡和光照。评估逻辑必须能脱离视觉效果独立工作否则生成器的画风会影响评估结果。3.3 给 Agent 定义一套不依赖坐标的动作接口为了让评估框架严格避免“通过坐标作答”Agent 的动作接口只提供语义操作。示例动作集合包括place、move、remove。下面是一个动作格式action { action: place, object: cup, category: cup, relation_target: table, relation: to_the_right_of, distance: medium }注意这里没有 x/y 坐标。Agent 只需要描述“在什么位置放什么物体、相对谁是什么关系”坐标由渲染器依据规则计算。这样设计的原因很简单如果 Agent 仍然输出坐标那么生成式模型只是变成了一个后处理画图工具模型的空间认知仍然停留在数字猜测阶段。下面是一个简化的关系位置求解函数演示渲染器如何把语义关系转换为坐标def resolve_position(scene: Scene, target_name: str, relation: str, distance: str): target next(obj for obj in scene.objects if obj.name target_name) delta 40 if distance medium else 60 if relation to_the_right_of: return target.x delta, target.y if relation to_the_left_of: return target.x - delta, target.y if relation above: return target.x, target.y - delta if relation below: return target.x, target.y delta raise ValueError(funsupported relation: {relation})实际框架中关系计算会更复杂比如需要考虑物体尺寸、边界、朝向和多个约束条件。但核心原则一致Agent 产生语义意图坐标是环境层解析的产物。3.4 评估器实现评估器检查最终场景中物体之间的关系是否满足任务要求。这里用结构化关系检查作为 ground truth而不是直接让视觉模型判断。def evaluate_scene(scene: Scene, task: dict) - tuple[bool, float, str]: required task[target] relation required[relation] target_name required[target_object] obj_name required[object] try: obj next(o for o in scene.objects if o.name obj_name) target next(o for o in scene.objects if o.name target_name) except StopIteration: return False, 0.0, missing object or target obj_center (obj.x, obj.y) target_center (target.x, target.y) distance_threshold 60 if relation to_the_right_of: ok obj_center[0] target_center[0] distance_threshold success_score 1.0 if ok else 0.2 feedback right relation if ok else not enough to the right elif relation above: ok obj_center[1] target_center[1] - distance_threshold success_score 1.0 if ok else 0.2 feedback above relation if ok else not high enough else: ok False success_score 0.0 feedback frelation {relation} not implemented return ok, success_score, feedback评估器要返回三个值是否完成、奖励分数、反馈文本。Agent 的下一次动作可以依赖反馈文本进行修正。3.5 主流程和运行结果主流程把 Agent、渲染器、评估器串起来。下面的 Agent 是一个模拟实现假设它能调用任意 LLM 的对话补全接口但在原型里用固定逻辑代替。def mock_agent_action(task, scene_text, feedback): # 实际项目中这里调用 LLM输入 task scene_text feedback输出结构化动作 return { action: place, object: cup, category: cup, relation_target: table, relation: to_the_right_of, distance: medium, } def run(task, max_steps3): scene Scene() scene.objects.append(SceneObject(nametable, categorytable, x120, y128, width60, height20, colorbrown)) feedback for step in range(max_steps): action mock_agent_action(task, scene.to_prompt(), feedback) if action[action] place: ox, oy resolve_position(scene, action[relation_target], action[relation], action[distance]) scene.objects.append(SceneObject(nameaction[object], categorycup, xox, yoy, colorgray)) done, score, feedback evaluate_scene(scene, task) if done: img render_scene(scene) img.save(fresult_step_{step}.png) return {solved: True, steps: step 1, score: score, scene: scene} return {solved: False, steps: max_steps, score: score, scene: scene} task {target: {object: cup, target_object: table, relation: to_the_right_of}} result run(task) print(solved:, result[solved], score:, result[score], steps:, result[steps])运行后的预期结果中solved为 True场景渲染图片里桌子的右侧会出现一个灰色矩形杯表示关系满足。4. 评估指标和关键参数设计4.1 动作空间设计原则Agentic 空间评估最容易被忽略的是动作空间。设计动作空间时有三个原则第一动作必须是语义级的不能是像素级或坐标级。例如“place object A to the right of B”是好的动作而“set A.x 140, A.y 128”不是。后者会绕回坐标评估。第二动作集合必须覆盖常见空间任务的原子操作。至少包含放置、移动、删除、旋转和缩放。否则 Agent 无法完成复杂任务。第三动作必须可回滚。多步任务中Agent 可能把一个物体放错位置之后必须允许它重新移动或删除否则评估只能测一次摆放能力测不了修正能力。常见动作空间如下动作参数说明placeobject, relation_target, relation, distance生成一个新物体并放置在目标相对位置moveobject, relation_target, relation, distance移动已有物体到新关系位置removeobject删除已有物体rotateobject, angle旋转物体测试朝向理解set_constraintobject, min_distance_to, value设置空间约束适合复杂布局任务4.2 评估指标评估指标不能只看“最终有没有成功”还要看过程质量。建议记录以下几类指标。指标计算方式关注点任务成功率完成任务次数 / 总测试次数空间语义理解是否足够准确平均步数成功任务使用的总步数 / 成功任务数Agent 是否高效是否反复试错动作合法率合法动作次数 / 总动作次数是否输出越界、目标缺失等非法动作关系准确率满足目标关系数量 / 全部目标关系数量多约束任务下逐项拆解能力场景一致性多次运行同一任务的布局 IoU 或距离标准差模型是否稳定还是靠随机猜修正成功率第一次错误后第二次是否修正是否具备利用反馈调整的能力其中“修正成功率”是 Agentic 评估独有的指标传统坐标问答无法测试。这个指标能反映模型的空间推理是否具有闭环能力。4.3 关键参数表原型实现中有几个影响评估结果的关键参数需要根据任务复杂度设置。参数默认值影响调大影响调小影响max_steps5最大尝试步数容忍更多试错但可能隐藏低效策略更容易失败严格测试一次性决策能力distance_threshold60关系判断容差更宽松容易误判为“在右侧”更严格但可能因坐标解析误差而失败render_size256渲染分辨率图片更清晰生成成本更高节省资源但小物体可能看不清action_modesemantic动作输出格式可扩展复杂动作限制表达空间feedback_leveltext反馈粒度模型更容易修正错误反馈模糊模型难以定位问题4.4 与坐标输出评估的对比下面的对比表可以帮你快速向团队解释为什么新的框架值得做。维度坐标输出评估Agentic 生成式评估输出形式数字坐标语义动作 图像/场景测量能力数字记忆空间语义理解和决策可解释性坐标对错无法解释每一步动作可见可回放错误分析只能看偏差值能定位错在哪个关系或哪一步场景扩展换地图要重新定义坐标换任务只需改任务管理器工程复杂度低中高需要渲染器和状态管理如果只是验证一个模型能不能记住图片中的大概坐标坐标输出够用。但如果目标是评估“空间智能”本身Agentic 生成式评估明显更合理。5. 运行验证与结果解读5.1 最小验证用例用上一节的原型跑三个任务放置把 cup 放到 table 右侧。移动把 box 移到 circle 上方。多约束把 lamp 放到 desk 左边并且离 wall 至少 40 像素。每个任务跑 10 次记录成功率、平均步数、动作合法率。5.2 预期输出正常通过时运行日志大概长这样task 1: solvedTrue, steps1, score1.0, legal_rate1.0 task 2: solvedTrue, steps2, score1.0, legal_rate1.0 task 3: solvedFalse, steps5, score0.6, legal_rate0.8第三个任务失败可能有两个原因模型没有输出set_constraint动作或者约束关系解析器不支持。建议先检查任务是否设计得过于复杂再检查 Agent 是否理解动作空间。5.3 如何判断模型是真正理解还是猜对一个评估框架如果只报一个成功率很容易被随机策略干扰。要判断模型是否真正具备空间智能至少做三个对照实验。首先是动作空间消融。给 Agent 提供一个“随机动作”基线如果随机动作也能得高分说明评估器太宽松。正常情况下随机动作成功率应该远低于一个基础 LLM。其次是场景干扰。同一个任务换用不同尺寸、不同初始位置成功率如果急剧下降说明模型只是在记训练时的位置模式。最后是反事实任务。例如把“桌子右侧”改成“桌子右后方”模型如果仍然只知道“右”而忽略“后”就能暴露出对方向组合的薄弱理解。5.4 学习环境与生产环境的差异原型阶段用规则渲染器很容易跑通。生产中接入真实扩散模型做渲染时需要考虑几个额外问题。第一渲染服务建议独立部署。LLM 和 ComfyUI 不要求在同一台电脑上可以通过 API 调用。否则生成式模型的显存占用会影响 LLM 的批量推理。第二视觉评估不能替代结构化状态。生成图像可能因为画风问题导致视觉识别失败但结构化状态里的物体位置是可靠的。生产环境建议始终维护一个结构化状态表作为 ground truth视觉模型只用于额外一致性校验。第三评估任务需要版本管理。空间任务描述、动作空间、关系解析规则都会迭代任何改动都可能让历史评估结果不可比。最好给每次评估打上任务版本号。6. 常见问题与排查路径6.1 模型仍然输出坐标而不是语义动作现象Agent 返回的动作里出现x、y字段甚至直接输出一段带坐标的 JSON。原因Base LLM 训练数据里包含大量“位置信息用坐标表达”的示例模型默认沿用这种模式。如果 prompt 里没有明确约束动作空间模型倾向于回到坐标输出。排查方式打印 Agent 原始输出检查是否有坐标数字检查 prompt 是否给定了合法的动作枚举。解决方式在 prompt 中明确列出可用动作并给出几个语义动作示例。更稳妥的做法是使用工具调用或结构化输出让模型只能选择合法动作字段。对于不合法输出可以直接丢弃并要求重新生成。6.2 渲染器生成的内容不稳定同一动作两次结果不一致现象使用真实扩散模型生成图像时同一句话生成的布局每次差异很大评估结果不稳定。原因扩散模型本质上是采样过程随机种子会影响结果。而且文本生成图像模型对空间关系的表达能力有限可能导致“桌子右侧的杯子”被画成“桌子前面”。排查方式固定随机种子比较两次生成的差别检查 prompt 是否包含额外位置词查看渲染器是否对输出图像做了裁剪或后处理。解决方式原型阶段先用规则渲染器做评估视觉模型只做二次展示如果必须用扩散模型可对生成的图像做后处理约束比如根据语义分割结果把物体移动到目标区域。评估指标也要以结构化状态为主。6.3 Agent 来回重复无效动作步数耗尽现象模型在多个任务上不断输出相同或者相近的动作分数始终停留在低分。原因反馈文本太模糊模型无法判断应该修改哪个物体或者max_steps过大让模型有机会试错而不优化策略。排查方式在每一轮打印反馈文本和动作观察模型是否根据反馈改变动作检查动作空间是否缺少修正操作比如move和remove。解决方式增加反馈的定向性例如“cup 仍然在 table 上方需要向右移动”而不是只返回“失败”。也可以缩短max_steps强制模型提高首步质量对于需要长期规划的任务单独引入规划器模块。6.4 评估结果和人工判断不一致现象评估器认为任务未完成但人类看渲染图觉得布局合理或者反过来评估器判定成功但人类明显看出物体遮挡严重。原因规则评估器只检查了物体中心点距离关系没有检查遮挡、边界和碰撞或者评估器的容差过小。排查方式保存最终渲染图片和结构化状态逐项对照评估器的判断条件。解决方式评估器增加“碰撞检测”“遮挡检测”“边界检查”。例如物体矩形框相交比例超过一定阈值就降低分数。另一个重要做法是加入人工复核抽样定期检查评估器阈值是否合理。7. 最佳实践与扩展方向7.1 评估框架有效性检查清单在正式使用这套框架之前建议先回答以下问题动作空间是否完全排除了坐标输出渲染器是否维护一份结构化状态而不是只有图片评估器是否被随机动作基线验证过是否存在“只要随机放置一个物体就能成功”的简单任务是否考虑了遮挡、碰撞、边界等物理约束每轮是否给 Agent 提供了可执行的反馈是否固定了任务版本和渲染器版本如果这些问题的答案有任何一个是“否”评估结果都需要打折扣。7.2 空间任务设计清单生成高质量空间任务比实现框架本身更需要经验。设计任务时可以从下面几个维度逐步加码单关系 vs 多关系先测“A 在 B 右侧”再测“A 在 B 右侧且 C 在 A 下方”。静态 vs 动态先测“放一个物体”再测“移动一个物体并保持其他物体不动”。绝对 vs 相对先测“物体在区域右上角”再测“物体在另一个物体前方偏左”。无遮挡 vs 有遮挡先测“两个物体无重叠”再测“一个物体部分遮挡另一个物体时如何描述”。无歧义 vs 有歧义加入“之间”“靠近”等模糊概念测试模型是否能主动澄清或选择合理默认值。任务库建议按照难度分级每个级别至少 20 个任务保证评估稳定性。7.3 环境部署检查清单如果想在生产环境接入视觉生成模型部署前检查这些项LLM 服务和渲染服务是否通过 API 解耦两条服务之间是否有超时、重试和降级策略生成模型是否固定了模型版本、采样器和种子策略图片传输格式是 base64 还是文件 URL大小是否可控渲染服务是否具备 GPU 资源监控和排队机制是否保存了每轮动作、场景状态、渲染图片和评估日志方便回溯这里的平衡点是评估主链路尽量轻量重资源操作放到独立渲染服务。不要把视觉生成模型嵌进 Agent 的主推理链路否则一次评估的延迟和硬件成本都会难以接受。7.4 扩展方向Agentic 空间认知评估框架有两个自然延伸方向。第一个方向是具身智能。算法评估里“摆放杯子”可以迁移到机器人操作任务中。机器人收到语义指令后生成操作序列仿真器渲染场景或真实环境反馈传感器数据评估器判断是否完成任务。这种评估可以直接复用动作空间和结构化状态设计。第二个方向是训练数据增强。一旦评估框架稳定运行它生成的大量“任务-动作-场景-反馈”轨迹可以作为多模态模型的训练语料。把成功和失败的轨迹都保存下来再用 Agentic RAG 的方式在推理时检索相似空间布局实例可以让模型快速理解新场景。从更本质的角度看空间认知评估不应该停留在“模型能不能说出空间关系”的文本层面而应该测量“模型能不能在空间里做出正确决策”。浙大提出的这个方向核心贡献是让生成式模型成为空间语义的输出媒介让 LLM 的文本能力与空间推理能力解耦。实际落地时不需要一开始就追求真实图像生成先把动作空间、状态管理、关系评估器设计好再逐步接入更复杂的渲染后端会是一条更稳妥的路径。对刚接触这个方向的同学可以先从本文的规则渲染原型开始跑通一个任务再用自己的 LLM 替换 mock agent观察它在多步空间任务里会暴露哪些问题。这一步做完再讨论生成式图像和更复杂的评估指标思路会清晰得多。