基于生成式模型的Agentic空间认知评估框架解析

空间智能是最近几年大模型讨论里被频繁提到，但评估方式仍然混乱的能力维度。人类判断一个模型是否理解“桌子左边”“杯子前方”，不会要求它输出一组坐标，而是看它能否在真实或模拟环境中做出正确布局。浙江大学研究团队提出的一种 Agentic 空间认知评估框架，正是顺着这个思路：让生成式模型把空间理解“画”出来，而不是强迫 LLM 在文本里输出数值坐标。这个转变看起来只是从数值输出变成图像输出，背后却涉及任务定义、动作空间、评估指标和 Agent 循环设计的一系列调整。这篇文章会围绕这个框架思路，拆解它的设计动机、核心模块、一个简化版原型实现，以及落地时容易踩的坑。适合关注多模态大模型、具身智能、模型评估和 Agent 开发的同学阅读。

1. 为什么“输出坐标”这条评估路径走不远

1.1 LLM 用文本表达空间时的信息瓶颈

大语言模型本质上是把文本 token 序列映射成下一个 token 的概率分布。即使最强的 LLM，也只能在它学过的文本分布里“猜测”坐标数字。对于“把杯子放在桌子右侧 50 厘米处”这个问题，模型可能会回答“(154, 320)”，但它并不具备连续几何推理能力，它只是在文本统计规律里找到了一个看起来合理的数值。

问题在于，空间场景往往是连续的、关系型的。两把椅子之间的“中间位置”不是一个唯一坐标，而是一条线段；一个物体“在另一个物体前方”取决于观察角度、朝向和基准线。LLM 如果只能输出坐标，就必须把一组连续变化的空间关系压缩成若干个离散数字。这种压缩会丢失大量空间语义，比如“离桌子很近但没碰到”和“在桌子正前方 10 厘米”在坐标上可能只有很小的差异，但语义差别很大。

因此，如果想要评估一个模型是不是具备空间智能，应该给它一种更适合表达空间结构的方式——图像、布局、拓扑关系，而不是坐标数值。生成式模型擅长从语义描述生成视觉结构，正好可以在空间认知评估中充当“输出通道”。

1.2 坐标输出评估的五个具体问题

即使不考虑 LLM 的能力极限，强迫模型输出坐标来评估空间认知，工程上也非常别扭。以下五个问题在实际项目里最容易遇到。

这几点不是某个模型的问题，而是评估设计的问题。如果我们考核的重点是空间关系理解，就应该给模型一个能够自然表达关系的输出空间。坐标不是关系，坐标只是从关系推导出来的一种结果。

1.3 生成式输出把空间认知拉回可视世界

生成式模型有一个特点：它可以把一个描述性的语义空间转换成一个可被人类和算法反复查看的视觉空间。例如让模型“画”出桌子右侧有一个杯子，生成的图像即便不是真实照片，也能直观反映出左右关系、遮挡关系、远近尺度。

这种做法的本质是改变评估接口。

• 旧接口：模型输出坐标，评估器解析数字。
• 新接口：模型输出动作或语义元素，生成式模型渲染成场景，评估器观察场景。

把空间认知评估从“数字比较”变成“场景生成与场景理解”，能同时测两种能力：模型是否理解了空间语义，以及模型是否能把自己的理解转换成可执行的空间结构。它也更接近人类认知心理实验中常用的“摆放任务”设计。

2. Agentic 空间认知评估框架的设计思路

2.1 整体流程：不是让模型直接回答，而是让模型在环境中“做”

传统评估是一次性问答：给定问题，取模型回答，和标准答案比较。Agentic 评估则不同，它把评估过程设计成一个多步交互闭环。

框架的核心流程可以概括为五步：

1. 任务管理器生成自然语言空间任务，例如“请把蓝色方块放到红色圆形上方”。
2. Agent 接收任务和当前场景状态，输出一个动作指令，而不是直接输出最终答案。
3. 生成式模型或空间模拟器执行该动作，将场景状态更新并渲染成图像或结构化场景图。
4. 评估器检查执行后的场景是否满足任务要求，并反馈给 Agent。
5. Agent 根据反馈继续尝试，直到满足终止条件。

这个流程的关键在于：空间任务不是靠一次完整答案来判定，而是靠一系列动作和中间结果来评估。这种范式天然适合 Agentic AI 的测试场景，因为 Agent 的每一步决策都可能影响最终布局。

伪代码形式的整体流程如下：

def run_evaluation(task, agent, renderer, evaluator, max_steps=5): 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_factory=list) 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], fill=obj.color, outline="black") 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(f"unsupported 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 = f"relation {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_steps=3): scene = Scene() scene.objects.append(SceneObject(name="table", category="table", x=120, y=128, width=60, height=20, color="brown")) 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(name=action["object"], category="cup", x=ox, y=oy, color="gray")) done, score, feedback = evaluate_scene(scene, task) if done: img = render_scene(scene) img.save(f"result_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 可能把一个物体放错位置，之后必须允许它重新移动或删除，否则评估只能测一次摆放能力，测不了修正能力。

常见动作空间如下：

4.2 评估指标

评估指标不能只看“最终有没有成功”，还要看过程质量。建议记录以下几类指标。

其中“修正成功率”是 Agentic 评估独有的指标，传统坐标问答无法测试。这个指标能反映模型的空间推理是否具有闭环能力。

4.3 关键参数表

原型实现中有几个影响评估结果的关键参数，需要根据任务复杂度设置。

4.4 与坐标输出评估的对比

下面的对比表可以帮你快速向团队解释为什么新的框架值得做。

如果只是验证一个模型能不能记住图片中的大概坐标，坐标输出够用。但如果目标是评估“空间智能”本身，Agentic 生成式评估明显更合理。

5. 运行验证与结果解读

5.1 最小验证用例

用上一节的原型跑三个任务：

1. 放置：把 cup 放到 table 右侧。
2. 移动：把 box 移到 circle 上方。
3. 多约束：把 lamp 放到 desk 左边，并且离 wall 至少 40 像素。

每个任务跑 10 次，记录成功率、平均步数、动作合法率。

5.2 预期输出

正常通过时，运行日志大概长这样：

task 1: solved=True, steps=1, score=1.0, legal_rate=1.0 task 2: solved=True, steps=2, score=1.0, legal_rate=1.0 task 3: solved=False, steps=5, score=0.6, legal_rate=0.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，观察它在多步空间任务里会暴露哪些问题。这一步做完，再讨论生成式图像和更复杂的评估指标，思路会清晰得多。