SceneActBench：让大模型在 3D 场景里动手做事，再按几何真值打分

为什么「看图说话」不够，要让 VLM 在 3D 场景里「动手做事」？

想象你在玩一款室内布置游戏：玩家拿到一张房间的俯视图，再拿到几张家具的照片，要把家具按俯视图的样子摆回原房间。这个任务包含两个隐含要求——玩家得能从俯视图反推每件家具的三维位置和朝向，还得能操控角色把这些家具一件件放到对的地方。它不是「看图说一句话」那么轻，而是「看完之后真动手操作，操作结果还要被一把尺子量出来」。

SceneActBench 想做的，就是这件事的评测版本。它由腾讯混元、清华、港科大等团队在 arXiv:2607.22393 提出，专门测一件事：让视觉语言模型（VLM）看到一组 3D 场景（PNG 视图或视频帧）后，能不能在该场景里「动手做事」——输出 GLB 场景、相机 JSON 位姿或动画 GLB 等 3D 工件，而不是说一段文字。SceneActBench

但为什么「看图说话」不够？已有的 3D-VQA 类基准（ScanQA、SQA3D、Spatial457）只让模型用文字描述场景，分数由文字答案和参考答案的相似度决定——模型从来没改过场景。另一些具身智能体基准（BlenderGym、3DCodeBench、EmbodiedBench）虽然让模型动手，但要么只针对单个对象，要么只看任务成功还是失败。这两类基准都没有同时满足三个条件：①多对象场景；②让模型真正执行一个结构化 3D 操作；③按几何真值量化打分。BlenderGymSceneActBench 专门补这个缺口——在论文 Table 1 对照表中，它是同时覆盖「多对象 + 可执行动作 + 几何打分」这三个维度的唯一一个基准。EmbodiedBench

先看一眼这件「考题」的真实形态：11 个当前最强的 VLM 配置在这套基准上拿到的 Overall 分数只落在 38.6 到 50.2 之间。

图注：11 条柱形代表 11 个 VLM 配置按 Overall 排序；每条柱由 5 个色块堆成，分别对应 5 个任务（每任务分数除以 5 后累加成 Overall）。基线为零，整体跨度 38.6–50.2，第一名与最后一名差不到 12 分。

也就是说，2026 年最强的几款 VLM——包括 Doubao Seed 2.0 Pro High、Claude Opus 4.6、GPT 5.4 Medium、Qwen 3.7 Plus、Gemini 3.1 Pro 等——在这件「看 3D 场景并按几何要求动手操作」的任务上，全都挤在不到 12 分的窄带里，没有真正拉开差距。这就是这张图想传递的第一条直觉：这件事目前对所有模型都很难。

SceneActBench 不是凭空出现的。在它之前，已经有两件事被验证是可行的。一是「LLM 直接生成 Blender Python 脚本来合成 3D 场景」——SceneCraft 在 ICML 2024 上展示了这条范式（给定一段文字，LLM 写脚本、用 GPT-V 自我检查渲染图），证明「语言模型 + 3D 渲染管线」是走得通的；二是「LLM 在游戏 / 仿真世界里主动操作」——Voyager 用 GPT-4 在 Minecraft 里终身学习、自动出题、积累代码技能库，VoxPoser 让 LLM 在体素网格上画价值图、机器人据此闭环执行。这两件前序工作加起来，奠定了 SceneActBench 的两个前提：LLM 能写代码、能操作 3D 空间。SceneCraftVoyagerVoxPoser

但前序工作没做的，是把这件事变成「标准化考题 + 几何打分」。SceneActBench 把 LLM 操作 3D 这条范式封装成了一个统一、可复现、可量化的基准——这也是它能被多个团队同时使用的关键。

5 种 3D 任务各在测什么能力？统一 inspect–act–render 循环如何把「看—想—动—看」串起来？

回到游戏类比。玩家拿到俯视图和家具后，每按一次键，画面就刷新一次；玩家看到刷新后的画面，再决定下一步按什么键。这个循环可以概括为「看 → 想 → 动 → 看」，是一个有时间步的 agent-environment 循环。SceneActBench 把这条范式标准化为 inspect–act–render 循环，每一类任务都共用同一套机制。

具体怎么用？5 种任务对应 5 种互补的 3D 能力：

这 5 个任务可以理解为：从「摆东西」「猜相机」「拆家具」「盖房子」到「复刻多物体同时运动」，覆盖了 3D 推理的五个主要类型。SceneActBench 把它们放在同一个共享 harness 里跑——

图注：SceneActBench 共享 inspect–act–render 循环。左：任务输入（PNG 视图 / 视频帧 / GLB 资产）。中：VLM agent 循环，按 inspect → execute Blender code → render → revise 四步推进，模型用 4 个 MCP 工具与 Blender 通信。右：任务输出（GLB / 动画 GLB / JSON 位姿）进入隐藏评估器，与隐藏的 3D 真值一次性比对，不向 agent 反馈任何分数。右侧面板列出 5 个任务各自的 Primary metric。

展开看左、中、右三块。左边是任务输入：PNG 视图或视频帧外加 GLB 资产（动态任务附视频帧）。中间是 VLM agent 循环：模型看到画面后，通过 4 个 MCP 工具去操作场景。4 个工具名字分别是 get_scene_info（查看场景概况）、get_object_info（查看某个对象的细节）、execute_blender_code（直接执行 Blender Python 代码改场景）、render_scene_view（从某个新视角渲染出图），Dynamic 任务再补一个 read_reference_frames 用来采样视频帧。模型在每一步 inspect（看）→ act（改）→ render（渲出来）→ revise（看渲出来的图、再决定改不改），直到任务步数预算用完或者模型主动停止。右边是隐藏评估器：模型最终输出的 GLB / JSON 拿去跟隐藏的 3D 真值比对，一次性得出分数，分数不反馈给 agent。

把这条循环映射到刚才的游戏类比，「玩家每按一次键 → 画面刷新 → 玩家再看 → 决定下一步按什么」就是 inspect–act–render，每按一次键相当于调用一次 execute_blender_code，每刷新一次画面相当于 render_scene_view；任务步数预算相当于玩家最多按几次键就强制收手。

看 Layout 任务的一张真实视觉卡，感受「输入—过程—输出—打分」具体长什么样：

图注：Layout 任务的 reference vs prediction 对照卡。左侧「Calibrated Evidence」是输入（DiningRoom-13034 单视图 + 几件放在原点的匿名 GLB）；中间「Spatial Grounding Orbit」是模型迭代过程（提 3D 姿态假设 → 渲出来 → 看视觉残差 → 修订，最多 30 步）；右上是「Final Layout」输出；右下是「Hidden ADD-S」对比模型预测和隐藏真值，ADD-S 0.1672 m 越低越好。这张图只代表 Layout 一个任务，其余 4 个任务各有自己的对照卡。

5 个任务共同跑在同一条循环上，但每个任务测的能力互补：Layout 测的是「能不能把 2D 视图里的物件反推回 3D 位置」，Camera 测的是「能不能从一张图反推相机的位置和朝向」，Articulated 测的是「能不能从一个物体的多帧视频反推出关节类型、轴心和运动范围」，Reconstruction 测的是「能不能从几张照片脑补出完整的 3D 形状」，Dynamic 测的是「能不能从一段视频复刻出多物体同时运动的轨迹」。一个模型在这 5 项里的得分不会完全一致——这就是后面「Overall 高 ≠ 每项都强」的伏笔。

几何真值怎么打分？为什么 ADD-S / PE-AE / MPE / F@5% / MME-LE 不是「文字打分」？

上一节提到，每个任务的 Primary metric 不一样。直观看，它们各自在测一件不同的事：

• ADD-S（米，越低越好）：量「模型摆的家具离标准位置差多少米」。Layout 用它。
• PE（米，越低越好）+ AE（度，越低越好）：量「模型猜的相机位姿离真值差多远、差几度」。Camera 用它。
• MPE（米，越低越好）：量「模型复原的关节运动量离真值差多少米」。Articulated 用它。
• F@5%（百分比，越高越好）：量「模型重建的点云离真值点云距离 ≤ 5% 对角线的占比」。Reconstruction 用它。
• MME（米，越低越好）+ LE（米，越低越好）：量「模型复原的多物体运动轨迹离真值差多少米」。Dynamic 用它。

它们的共同点是：都把模型的输出当作摆好的实物，用真实几何量作尺子量它离标准答案有多远——这和「文字打分」不是一回事。文字打分是让模型说一段话，再让评分系统比较两段话有多像，本质上是文本相似度；几何打分是直接量 3D 物体在空间里的位置、姿态、形状差异。SpatialVLM 在 CVPR 2024 上已经验证了这一点：当代 VLM 即使在 20 亿条空间问答上做过训练，给出的「左边」「靠近」这种定性表述仍然不能被定量复用——必须用几何真值打分才有意义。SpatialVLM

几何打分这条规则还配套一个公平性原则：「考试密封卷 + 一次打分」。模型从头到尾看不到标准答案，跑完一次输出 GLB 或 JSON，再由隐藏的 ground truth 一次性比对，评分结果不反馈给 agent。这条原则写在 harness 的右上角——Scored once · no agent feedback。它的目的是避免 agent 通过试错「摸到」评分标准，然后专门针对评分标准作弊。从图里右上角的 Scored once · no agent feedback 可以直接看到这条承诺。

为什么这一点重要？因为如果允许 agent 在循环中看到「刚刚这一步 ADD-S 是 0.18」这样的实时分数，它就会朝「让 ADD-S 下降」的方向去 hack——比如把所有家具都往原点挪，因为原点附近 ADD-S 天然较低。一次性打分切断了这条作弊路径。这条设计同时也保证了 11 个 VLM 配置之间的可比性：所有人面对的都是同样的封闭考卷，没机会做针对性准备。

具体到每个指标，ADD-S 量「摆的物件离标准位置多远」，名字里的 S 是 Symmetric 的缩写——它对每个物件计算模型预测位姿与真值位姿之间的最近点距离（米量级，与归一化常数 4 m 对齐），再把所有物件的误差求平均。PE/AE 量「猜的相机离真值相机多远 / 朝向差几度」——PE 是 Position Error，单位米；AE 是 Angle Error，单位度。MPE 是 Mean Position Error，量关节件每一段运动后位置的平均位移偏差。F@5% 量「重建的点云有多少百分比的点离真值点云在 5% 对角线以内」。MME/LE 量「动态轨迹里每个物体运动后位置的平均误差（MME）和线性误差（LE）」。这五个指标单位不同、含义不同，但都遵守同一条规则——一次性几何打分、不向 agent 反馈。

210 个源实例怎么变成 520 个任务案例？「同份考题换题型」的设计逻辑

接着看评测的另一条公平性设计——数据规模。SceneActBench 一共用到 210 个源实例，分配如下：

3D-FRONT 是 ICCV 2021 上的一个合成室内数据集，包含 18,968 间带家具房间、13,151 件带纹理家具实例、覆盖 31 类场景——它能成为 SceneActBench Layout 任务的来源，是因为它的规模、风格相容性和纹理质量都远高于同期公开同类数据集（在 Table 3 用户研究中对 SUNCG 取得 60–70% 偏好胜率）。3D-FRONT

但 210 个源实例并不等于 210 个案例——同一批 100 间房会被 Layout / Camera / Reconstruction 三个任务分别使用，光基础案例就有 410 个（Layout 100 + Camera 100 + Articulated 100 + Reconstruction 100 + Dynamic 10）。要让不同模型在同一条件下可比、还需要把部分源实例按输入条件再展开一次。SceneActBench 用的是「同一份考题换几种题型」的做法：每份源实例在某些任务上配对成两种输入条件，看模型在不同条件下表现是否一致。

具体展开方式是：Layout 任务每个房间有单视图（约 1 张校准视图）和多视图（约 11 张）两种条件——同一间房，模型拿到 1 张图要做对、拿到 11 张图也要做对。Dynamic 任务每个动态场景有低多边形和写真实感（用 NVIDIA Cosmos 把低多边形渲染升级到接近照片的真实感）两种条件——同一段视频，模型在两种画面风格下都要能复刻轨迹。基础 5 任务案例共 410 个，再加上配对条件：多视图 Layout 100 + 写真实感 Dynamic 10 = 110，410 + 110 = 520 个任务案例。这就是「同一份考题换题型」的口径。

「换题型」的口径还要遵守另一条约束：这些配对条件不进入 Overall 分。Overall = 先在每个任务内对案例分取平均，再把 5 个任务分等权平均（用单视图 Layout 和低多边形 Dynamic 这一套单条件）；多视图 Layout / 写真实感 Dynamic 这些配对条件单独报告——它们的作用是「看模型是否真的看懂内容，还是只对某种输入风格敏感」。比如多视图 Layout 在 9/11 配置上都比单视图高（Sonnet +12.1、Gemini +9.4、Opus +8.5），说明多数模型能从多视图里获取更多空间线索；但 Step（-1.4）和 MiMo（-0.6）反而退步，说明更多视图不一定总是有帮助。写真实感 Dynamic 的效应更混合：4 个配置变好、6 个退步、Opus 一位小数不变（GPT 5.4 High +17.3，Step -10.3，Sonnet -10.2）——这说明有些模型对渲染风格敏感，给它写真实感图反而干扰判断。

源实例在进入基准前还要做一道「标准化」处理：室内资产被移到原点、设为中性朝向、按标注尺寸做米制缩放；关节件被重定向到统一坐标系、关节参数对模型隐藏；所有文件名和节点名一律换成匿名 ID——目的是去掉「物体名字本身就是线索」「原始资产里就藏着答案」这类泄漏。从外部看进去，模型看到的只是一堆带匿名 ID 的几何体和几张图，它必须从图本身反推答案。

「考试密封卷」+「同份考题换题型」合起来就构成了 SceneActBench 的两条公平性原则：所有模型面对同一份封闭考卷，每份考题还换了不同题型看模型是否真的稳。这两条原则保证了 11 个 VLM 配置在 38.6–50.2 这个区间里的相对排名是可信的——它反映的不是「谁在调 prompt 上更用心」，而是「谁真的能在多对象 3D 操作上做对更多几何题」。

11 个顶尖 VLM 都在 38.6–50.2 之间——分数背后的真实瓶颈

回到那张 leaderboard 图，把 Overall 数字展开看：

图注：和第一章相同的一张图，本章用它看分数分解。

第一名 Doubao Seed 2.0 Pro High 50.2，第二名 Claude Opus 4.6 48.9，第三、四名 GPT 5.4 Medium 和 GPT 5.4 High 都是 48.7。看似第一到第四名只差 1.5 分，但拆开看 5 个任务的得分，会发现每个模型的「领导关系」已经交换了：在 5 个任务里换着当第一——Doubao 领 Layout / Camera / Dynamic，GPT 5.4 High 领 Layout / Articulated / Reconstruction，Opus 在 Articulated 上排第二（63.7，仅次于 GPT 5.4 High 的 73.8）；GPT 5.4 High 在 Reconstruction 上以 12.3 排名第一（F@5% 0.123），Medium 在 GPT 5.4 High / Sonnet 5 之后排第三（10.4），因此 Medium 并未独占 Reconstruction 第一；GPT 5.4 High 在 Layout / Articulated / Reconstruction 三项都是第一，但因为它在 Dynamic 上落后 GPT 5.4 Medium 21.8 分而掉到第四。Overall 奖励均衡，不奖励单项突出——这是设计选择，不是 bug。

第一到第二的差距具体怎么来的？Doubao 比 Opus 高 1.34 分，拆开是 +1.49 来自 Dynamic、-0.15 来自其他 4 项之和。Dynamic 这 +1.49 集中在哪里？raceloop 场景贡献 +0.86、factory 场景贡献 +0.68，其余 8 个动态场景加起来 -0.05。论文用 50,000 次配对案例重采样验证，结论是 Doubao 在 64% 的样本里排第一（Opus 19%，Medium 17%）——但 Doubao 的 95% 置信区间跨零，所以不能宣称 Doubao 统计上稳赢。这条提醒很重要：Overall 排序基于基准案例组合的敏感性，而不是重复运行之间的方差。

另一个反直觉的发现：交互步数多并不等于分数高。11 个配置之间，交互预算使用率和 Overall 是负相关的——Spearman ρ = -0.68。Opus 用掉了 82.9% 的预算、每跑 39.1 次工具调用，最后拿到 48.9 分；GPT 5.4 Medium 用 32.8% / 19.9 次调用 → 48.7 分；Doubao 用 34.3% / 11.4 次调用 → 50.2 第一。也就是说，模型跑得越多步、调用工具越频繁，分数反而越可能往下掉。这和「智能体里说的『无效循环』」是同一件事：每多按一次键不等于更接近目标。Opus 反复修改却没改对地方，相当于在原地打转；Doubao 每次修改都朝目标推进，自然不需要按太多次键。这条结论的统计口径是「task-balanced」——把每个模型的交互预算先在每个任务内归一化、再在 5 个任务间等权求 Spearman，论文也提醒这条结论是「描述性、不是因果」。

同样的 Overall 分下面，不同模型错在不同环节。失败分阶段图把这件事画了出来：

图注：denominator-aware failure stages。行 = 失败阶段（primary geometry / object/target selection / surface completion / motion direction），列 = 任务（Layout / Camera / Articulated / Reconstruction / Dynamic）。每格显示 stage 成功率 + success/denominator 数值；† 行使用条件分母：Articulated type / direction 要求部件有可测的刚性运动、Dynamic direction 要求 eligible non-loop movers、Camera 排除同时 PE≥4m 且 AE≥90° 的零分情形。0/0 表示无证据，不是成功。

读这张图要注意 † 行的条件分母。Articulated 的 type 正确率只在「有可测刚性运动的部件」上计算；Dynamic direction 正确率只在「非循环运动且有匹配轨迹」上计算；Camera 阶段排除同时 PE≥4m 且 AE≥90° 的零分样本。脱离分母读成功率很容易误读。举具体例子：Articulated MPE 前三名（Doubao 0.404、Opus 0.375、Medium 0.381）看似接近，但 Doubao 只移动了 13/391 个 GT 部件、Opus 移动了 255/391、Medium 132/391——在「部件有可测刚性运动」的子集上，Doubao 只有 8/12 个部件类型正确、方向正确，Opus 是 248/251 / 238/251，Medium 是 124/127 / 105/127。也就是说，Doubao 看着 Articulated 分数高，是因为它选择只动最确定的那几个部件；Opus 动了大部分部件但在每个部件上的精度参差。Dynamic 也有类似故事：Doubao 匹配了 28/29 movers，但在 eligible tracks 上只恢复了 7/16 的方向（Opus 11/14，Medium 11/15）。这就是「Overall 高 ≠ 每项都强」的具体含义。

11 个配置都没拉开差距，瓶颈落在几个特定的失败模式反复卡住所有人：primary geometry（位姿基础估算错）、object / target selection（在场景里挑错对象）、surface completion（重建时表面补不全）、motion direction（多物体运动方向猜错）。这些失败模式在 11 个配置之间普遍存在，谁都没解决。

怎么把这个基准借到自己项目里，什么时候该借鉴、什么时候不该？

把 SceneActBench 当作一份「设计模式库」来读，可以拆出三件可以单独借走的事：

第一件，怎么挑任务。5 个能力维度互补（空间定位 / 自我中心空间推理 / 关节运动学 / 形状想象 / 动态推理），覆盖了 3D 推理的主要类型。一个评测如果想测「多对象 3D 操作」而不是「单对象编辑」或「文本成功」，可以从这 5 个能力维度挑 3–4 个组成自己的任务组合，避免只盯一项造成能力盲区。

第二件，怎么组织数据。SceneActBench 用的是「多源融合 + 标准化 + 匿名 + 配对条件」四件套。多源指 Layout / Camera / Reconstruction 都用 3D-FRONT 室内房间、Articulated 用 S2O ACD、Dynamic 用 Kenney 场景——一个评测往往需要把多个公开数据集拼起来。标准化指所有资产被居中、归向、米制缩放、ID 匿名——这步是去掉泄漏。配对条件指同一份考题换几种输入条件（单视图 / 多视图、低多边形 / 写真实感），让模型的真本事和「运气成分」分开。

第三件，怎么打几何分。5 个任务用 5 个不同单位的指标，但都遵守同一条规则——一次性几何打分、不反馈给 agent。借鉴时重点是「一次性 + 不反馈」这条公平性原则，而不是某一项指标的具体公式。每个任务挑最贴合的几何量（位置 / 朝向 / 形状 / 运动）做单位不一的指标，再用统一的 Overall 折算公式汇总，就构成了可量化的几何评测。

下面是一张迁移判断表，帮助快速判断该不该借鉴：

关于开源落地证据。SceneActBench 同时在 Hugging Face 和 GitHub 上做了完整发布。Hugging Face 上的数据集是 FEInaldo/SceneActBench，按 CC BY-NC 4.0 发布（覆盖新增的标准化、标注和动态场景；底层 3D-FRONT / S2O ACD / Kenney 各自保留原始许可证）；GitHub 上的 harness 是 Feinaldo2/SceneActBench，按 MIT 发布（包括配套的 blender-mcp 服务器）。下载命令是 huggingface-cli download FEInaldo/SceneActBench --repo-type dataset --local-dir ./data，harness 的接入方式是 pip install -r requirements.txt && cp .env.example .env，再把 DATA_ROOT 指向 ./data。运行入口是 python src/harness/run.py --models models.json --task tasks/<task>.json --headless --auto-port。商用项目注意：数据集是 CC BY-NC 4.0 非商用，harness 是 MIT 可商用——这两者的边界要分清。SceneActBench Project PageSceneActBench Harness Repo

横向坐标上还有两个同期基准可以参照。BlenderGym 是 2025 年同方向的 3D 图形编辑评测（CVPR 2025 Highlight，5 类编辑任务共 245 个 start-goal 对），走渲染真值而非几何真值——和 SceneActBench 的差异在「单对象静态 vs 多对象动态」+「渲染真值 vs 几何真值」。EmbodiedBench 是 2025 年的 MLLM 具身评测（ICML 2025 Oral，4 环境 1128 任务 24 个 MLLM），走低层控制 + 任务成功分——GPT-4o 在 EB-Manipulation 单环境只有 28.9%，关闭视觉后 EB-Navigation 从 57.7% 掉到 17.4%、long-horizon 任务直接崩到 0%。SceneActBench 与这两个基准的方向都不同：BlenderGym 偏图形编辑、EmbodiedBench 偏低层控制，SceneActBench 把动作从这两条线分别推向「多对象 3D 操作 + 几何真值」。

总结借鉴的边界。需要多对象可执行评测、需要 VLM 真的输出 3D 工件的项目，最适合借鉴 SceneActBench 的任务设计、数据组织和评估手段这三件套。如果只是想要文本回答、单对象任务、或关注交互效率，那不应该照搬——用文本相似度评测、单对象任务成功率、或者 EmbodiedBench 式的任务成功分即可。

参考文献

本专题引用的核心资料如下，建议深入学习时阅读原文：

1. SceneActBench: Can Agents Act on the 3D Scenes They See? — arXiv:2607.22393
2. SceneActBench Project Page — feinaldo2.github.io/sceneactbench-project-page/
3. FEInaldo/SceneActBench (Dataset + Harness Repo) — huggingface.co/datasets/FEInaldo/SceneActBench / github.com/Feinaldo2/SceneActBench
4. BlenderGym: Benchmarking Foundational Model Systems for Graphics Editing — arXiv:2504.01786
5. EmbodiedBench: Comprehensive Benchmarking Multi-modal Large Language Models for Vision-Driven Embodied Agents — arXiv:2502.09560
6. SceneCraft: An LLM Agent for Synthesizing 3D Scenes as Blender Code — arXiv:2403.01248
7. VoxPoser: Composable 3D Value Maps for Robotic Manipulation with Language Models — arXiv:2307.05973
8. Voyager: An Open-Ended Embodied Agent with Large Language Models — arXiv:2305.16291
9. SpatialVLM: Endowing Vision-Language Models with Spatial Reasoning Capabilities — arXiv:2401.12168
10. 3D-FRONT: 3D Furnished Rooms with layOuts and semaNTics — arXiv:2011.09127