BrickWright：智能体驱动的物理可行乐高积木模型构建 BrickWright: Agentic Creation of Physically Feasible Brick Builds
用积木装配 SDK 与物理验证回路，让现成 LLM 智能体生成 100% 物理可行的乐高模型
前置知识
LLM 智能体与计划-执行-验证循环
LLM 智能体是能调用工具（读写文件、执行代码、调用 API）自主完成多步任务的预训练大模型系统，如 OpenAI 的 Codex 与 Anthropic 的 Claude Code。计划-执行-验证循环（plan-execute-validate）是其经典工作模式：先做简短规划，再写代码或调用工具生成产物，然后运行验证工具获取反馈，根据反馈修改后重试，直到所有检查通过。
BrickWright 的整套方法就是围绕这个循环设计的：它只提供极简的工具集和循环指引，让智能体写 Python 代码搭积木、跑验证、读失败详情、改代码重验，因此不懂智能体循环就无法理解方法的运行机制和实验设计。
LDraw 格式
LDraw 是乐高积木模型的标准开放文本格式，模型文件（.ldr）中每行描述一个零件或子模型的绝对 3D 位姿，例如「1 25 20 -8 10 1 0 0 0 1 0 0 0 1 14418.dat」表示把零件 14418 按某旋转矩阵和平移放置。它只支持绝对坐标放置，不含任何物理验证能力，也没有连接件概念，对人或模型都不友好。
LDraw 是本任务的最终输出格式和所有基线的工作对象；论文反复强调直接写 LDraw 既费 token 又容易放错零件（消融实验显示 token 成本约翻倍），这正是 BrickLayer 存在的理由，也是理解对比实验设置的前提。
类型化连接件（typed connectors）
指乐高零件上带类型标注的对接点：凸点 studs 与凹点 antistuds 互锁构成转动关节，此外还有销/孔、轴、夹/杆、球关节等。每个连接件带局部坐标架（位置、轴方向、侧面），两个连接件能否连接由类型兼容性与坐标架对齐规则决定；关节类型分为固定、转动、球、滑动、圆柱五类。
这是 BrickLayer 装配 API 的核心抽象：智能体通过 find_connector 和 connect 让零件按连接件对接而非手调坐标，验证器则据此定义「连接」与「连通分量」。理解它才能看懂方法如何把物理可行性变成确定性检查。
代码即 3D 模型（code-as-3D-models）
用程序而非网格文件来表示三维形状：几何与零件关系被写成结构化代码，便于精确编辑、参数化复用和版本管理。已有研究表明 LLM 在写代码并把精确计算交给解释器执行时推理更可靠（如 PAL），因此智能体 3D 生成系统普遍让模型输出建模代码而非直接输出几何。
本文把积木模型表示为可编译执行的 Python 程序，这使得验证可以确定性进行、修改可以定位到具体零件、递归子模型可以层次化组织，是整个智能体框架成立的表示基础。
VQAScore 与 SigLIP 2 图文对齐指标
VQAScore 通过「给定图像回答该文本描述的概率」来衡量图文一致性， Perception Encoder（PE）和 SigLIP 2（SL2）则是两种视觉-语言编码器的嵌入相似度打分。三者共同构成无需人工的文本到图像生成忠实度评估组合，分数越高表示生成结果越贴合提示描述。
论文用这三个指标（渲染积木模型后与提示文本比对）量化「提示忠实度」，是 Table 1 的重要组成部分；不熟悉这些指标就无法解读「物理有效性提升是否以牺牲还原度为代价」这一关键问题。
研究动机
前沿编码智能体在 3D 建模上越来越强，无需微调即可产出铰接物体、场景和 CSG 模型，但一旦目标是要在物理世界中组装的物件（如乐高多部件装配），输出就常常违反物理约束：零件相互穿插（碰撞）、悬空、或整体断成多个不连通的组件。在 BrickNet-512 的 512 个文本提示上，未经辅助的商业智能体物理有效率只有 8.6%（GPT-6 Luna）到 69%（GPT-6 Astra）。值得注意的是，最强的 GPT-6 Astra 配 Codex 其实已有自我验证意识：512 个样本中 471 个（92%）写了生成器代码、424 个（83%）写了验证代码，但对复杂物理领域这种自发验证仍不够，产物依旧大量穿模和悬空（Fig. 2）。现有专门的积木生成模型虽考虑物理性，却各有短板：BrickGPT 只支持 8 种矩形砖和 21 个物体类别；BrickNet-14B 有效率仅 31.8%；LegoACE 隐式学习连接关系会生成不连通组件；BrickNet 在长序列中不断累积碰撞。它们的泛化能力和保真度都不如商业智能体。
本文的目标是本文的目标是：不进行任何任务特定训练，仅通过给现成预训练 LLM 智能体配备一套「装配 API + 物理验证器」工具箱，使其能从文本或图像提示生成物理可行的乐高积木模型。物理可行被形式化为四个可检验条件：只使用真实零件库中的零件；任意两个零件的网格不相互穿插（无碰撞）；没有悬空零件——每个零件都能通过已接合的连接件或带向上分量的支撑性面接触到达地面；若描述为单个物体则整体构成单个连通分量。同时要求不牺牲提示忠实度、不明显增加推理成本。最终量化目标是在 512 个提示的测试集上，让从轻量级到前沿级的所有智能体都达到 100% 物理有效率，并超越专门训练的文本到积木模型。
与已有工作不同的是，本文的独特切入角度是把「智能体式 code-as-3D-models」与「积木零件的规则性」合并起来。乐高是一个有上万个零件、几十种连接方式的复杂系统，但连接件具有可编程的装配生产规则（凸点与凹点互锁等，可追溯到 1961 年的乐高专利），因此可以把每个零件建模为带局部连接件坐标架的几何体，用确定性的可执行验证取代视觉判断或学习到的统计先验。与微调式方法（BrickGPT、BrickNet 等）不同，BrickWright 零训练样本即可开放词表生成任意物体；与面向数字资产的 agentic 3D 工具包（Articraft、aDSL 等）不同，BrickLayer 显式编码物理装配约束。作者还提出一个常被忽视的论点：即使智能体强到能自己写工具箱，单独开发工具箱仍然重要——可节省 token、避免重复劳动，实验显示直接用 LDraw 建模 token 成本约翻倍、验证调用约三倍。
核心方法
直觉上，BrickWright 让会写代码的智能体「像工程师一样工作」：先用一个好用的装配 API 把模型写成 Python 程序，再让确定性的验证器报告所有物理违例，智能体读反馈、改代码、重验，直到全部通过。技术路线由两部分组成。其一是 BrickLayer Python SDK，提供三组能力：目录发现——对 LDraw 17k+ 零件做关键词/字段搜索，按 BM25 分数乘以随官方套装出现次数对数增长的流行度因子排序；装配——Element（单色零件）与 LegoBuild（可递归嵌套的积木构建）两类对象经统一的 LegoGeometry 接口暴露尺寸与类型化连接件，支持网格对齐放置、按连接件对接、命名引用、镜像、铰接关节等；验证——列出碰撞零件对、悬空零件和连通分量。其二是 BrickWright harness，只向智能体提供 build.py 读写、explore（执行 Python 片段）、validate、render、finalize 几个工具，系统提示里仅有 BrickLayer 文档与循环指引，不含任何完整搭建示例或技巧。
核心创新是把乐高的物理生产规则（snap-fit 连接）编译成带类型的连接件 API 和可执行验证器，从而把「物理可行性」从模糊的视觉判断变成确定性检查。与已有方法的本质区别有三点。第一，相比 BrickGPT、BrickNet 等专门训练的生成模型，本文完全使用预训练智能体、零训练样本，即可开放词表生成任意物体，且连通性由 API 与验证显式保证，而非像 LegoACE 那样隐式学习。第二，相比 Articraft 等生成自由几何、靠视觉判断解决碰撞的 agentic 3D 系统，本文装配的是固定零件，连接件决定零件如何连接与运动，碰撞检查可精确到网格内缩 0.1mm 的确定性相交测试。第三，相比在生成后用物理仿真或力平衡做后处理优化的路线，本文把验证前移到生成循环内部，失败信息直接指导代码修改。作者还刻意用极简 harness 证明：收益来自 API 与验证器的设计本身，而非提示工程。
方法步骤详情
第一步，输入文本和/或图像提示，系统提示只含 BrickLayer 文档与循环指引；智能体先做简短内部规划（定义特征、尺寸、支撑结构、特殊零件）。第二步，写 build.py：create_build() 返回 LegoBuild，run_tests() 返回 TestContext 报告（必须保留无悬空、无碰撞、连通三项检查，可加自定义量化测试如 build.brick_count > 100）；编写中用 search_parts 查目录、brick/plate/slope/minifigure/fill_box 等高层函数快速成形、connect 将连接件对接。第三步，调用 validate：运行固定碰撞检查（网格内缩 $0.1\,\mathrm{mm}$ 后查相交，避免紧配合误报）、悬空检查（先平移至最低点触地，再沿已接合连接件或带向上分量的支撑面接触寻找接地通路）与连通分量统计，连同自定义测试输出报告。第四步，若失败则逐条读失败详情、增量修复并重复 validate，可随时用 explore 运行 Python 片段调查 API；多数智能体调用 2-3 次，Luna 需 4-5 次。第五步，调用 render 生成多视图做视觉检查。第六步，全部通过后 finalize，经 write_ldraw 导出标准 LDraw 文件；铰接模型可用 posed 在指定关节坐标下生成快照，校验运动范围内的可行性。
技术新颖性
技术新颖性体现在四个方面。其一，API 设计是经验驱动的协同迭代：brick/plate/tile/slope/minifigure/fill_box 等高层便利函数是作者观察到智能体生成代码中的重复模式后补加的，fill_box/fill_slope 能保证填充区域合法且尽可能连通，这种「观察智能体行为→沉淀为 API」的循环在同类工作中少见。其二，验证的工程细节考究：0.1mm 网格内缩处理乐高紧配合导致的误报（参考 BrickNet 做法）；悬空判定显式排除纯侧向接触；因 BrickNet 标注不区分滑动与圆柱关节，BrickLayer 通过绕轴旋转 15° 是否碰撞来判定关节类型。其三，递归 LegoBuild 结构配合命名引用，使 29,667 零件级别的山城这类大规模构建能分层组织与局部编辑，并支持以 BrickLayer 脚本或 LDraw 文件为输入的增量编辑。其四，铰接支持：连接件可附带 MotionRange 关节范围，posed 方法在运动学树结构上采样校验碰撞、悬空与脱开，静态检查之外的这一能力是纯文本到积木模型不具备的。
实验结果
在 BrickNet-512（512 条 VLM 为人搭建模型生成的描述）上有四层发现。第一，物理有效性（Table 1）：Codex 基线有效率仅 Luna 8.6%、Sol 64.1%、Astra 69%，Claude Code（Haiku）32.8%，配 BrickWright 后全部达 100%（Valid/无碰撞/无悬空均为 1.000），平均连通分量数降到最小值 1.00。第二，轻量模型受益最大且忠实度不降反升：Luna 的 VQAScore 0.6504→0.6945、Haiku 0.6032→0.6523，Luna 以约 2% 于前沿模型的成本（$0.03 对 Astra 的 $1.28）取得接近的 SL2 分数；强模型忠实度保持（Sol VQA 0.7610 持平，Astra 0.7695 略升）。第三，对专门模型全面超越：BrickGPT 有效率 0.990 但 VQA 仅 0.0658（结构过简），BrickNet-14B 仅 0.318，Articraft+Astra 0.684 且成本 $3.00。第四，消融与效率：去装配 API 后 Haiku 降至 82.2%、Luna 降至 99.6% 且零件数从 27.4 崩到 7.2、VQA 跌至 0.3342；去验证器后全部低于 77.9%——仅 API 的网格吸附就能较基线提升最多 44 个百分点，但验证器仍不可或缺；直接写 LDraw 使 token 约翻倍、验证调用约三倍。完整版 Sol 的 valid@1 达 0.475、valid@5 达 0.992，总 token 528.3K 反而低于基线 654.3K。Table 2 显示物理检查占失败调用的 63.5%-84.7%，GPT 系失败以碰撞为主（79.6%-89.9%）而 Haiku 以连通性为主（76.7%）。人工复核表明自动指标略保守，碰撞免检率被低估 0.2-1.4 个百分点。扩展实验（Fig. 5）验证图像条件生成、15,067 与 29,667 零件的大规模场景、铰接构建、增量编辑和 20 砖约束生成，全部有效且连通。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 文本到积木物理有效率（BrickNet-512） | Valid 有效率 | 100%（四个智能体档位全部） | Codex 基线 8.6%（Luna）/64.1%（Sol）/69%（Astra）；BrickNet-14B 31.8%；Articraft 68.4% | 最高 +91.4 个百分点（Luna） |
| 提示忠实度（轻量模型 Luna） | VQAScore | 0.6945 | 0.6504（Codex 基线） | +0.0441 |
| 提示忠实度（Claude Haiku 5.5） | VQAScore | 0.6523 | 0.6032（Claude Code 基线） | +0.0491 |
| 验证首次通过率（GPT-6.1 Sol） | valid@1 | 0.475 | 0.164（w/o assembly API） | 约 2.9 倍 |
| 推理成本（GPT-6.1 Sol） | 平均总 token（千） | 528.3 | 654.3（Codex 基线）；1,825.0（w/o assembly API） | 较基线省 19%，较去 API 版省 71% |
| 单样本 API 成本（GPT-6 Astra） | 美元/样本 | $1.28 | $3.00（Articraft+Astra） | 省 57% |
| 结构连通性（BrickNet-512） | 平均连通分量数（越低越好） | 1.00（全部档位） | Codex(Astra) 2.00；Codex(Luna) 10.11 | 降至理论最小值 |
局限与改进
作者承认的局限：可行性定义不覆盖可执行装配顺序与稳定性/受力平衡分析（结构是否倾覆、滑移），留待未来；相比专门模型，agentic 方法更慢更贵（Sol 完整版 251 秒对 BrickNet 的 5 秒）；每样本 $5 预算下 Articraft 有 34 个样本触顶，取最后完成的模型计入结果。方法内生的边界：铰接运动检查只采样关节范围的离散位姿（默认 5 个样本），不覆盖所有中间姿态，未标注的连接保持刚性，可能误报或漏报；悬空判定基于带向上分量的支撑接触，不含滑动与倾覆；连通性允许智能体自设 expected_components，多物体场景的判定主观。我自己的观察：忠实度评估完全依赖 VQAScore/PE/SL2 自动指标，无法衡量「搭得美不美」或零件可购性；全部实验绑定闭源模型（GPT-6 系列、Claude Haiku 5.5），版本更迭会改变结论；29k+ 零件构建耗时 267 秒以上，代码级表示在超大规模下的上下文与时间成本未被系统评估。
独立分析的弱点
独立分析揭示以下弱点。第一，稳定性是最大缺口：一个 100% 「可行」的高塔可能头重脚轻一推就倒，验证器只查碰撞、悬空、连通，不查重心与力矩平衡；改进方向是接入 StableLego 式力平衡分析或物理仿真（作者亦承认），并在失败报告中给出倾覆风险提示。第二，修复是试错式的：validate 返回违例清单但不给修改建议，弱模型 Luna 需 4.62 次验证调用、valid@1 仅 0.268，且论文提到弱模型有时会「放弃不 finalize」；改进方向是在验证器中返回可执行的修复建议（如碰撞对的最小平移向量、悬空件的候选连接点），或引入约束求解器辅助重连。第三，高层便利函数依赖人工沉淀，覆盖模式有限，可从大量成功/失败生成记录中自动挖掘新模式并回归测试。第四，评测缺人工对齐评分与真实拼搭验证（零件是否真的买得到、能否按序列拼出），「物理可行」与「可用套件」之间仍有距离。第五，验证调用次数与 $5 预算构成隐性上限，超限时取最后完成的模型可能高估弱配置的表现。第六，对多物体场景的组件数预期完全交由智能体判断，缺少结构化的场景分解机制。
未来方向
作者明确提出两个方向：把力平衡稳定性分析（如 StableLego）纳入可行性定义；把强大智能体的能力蒸馏到更小更快的模型，弥合 agentic 方法在时延与成本上的劣势。基于本文成果还可延伸：利用 BrickLayer 已记录的连接件与关节信息自动生成分步拼搭说明书，实现「可行」到「可按序拼装」的跨越；把框架推广到其他「预制件+连接规则」的物理装配域，如榫卯结构、平板家具、PCB 元件布局或钢结构节点；与图像到 3D 重建结合，从真实照片直接输出可购买的零件清单与搭建指南；在 validate 反馈信号上做强化学习或偏好优化以微调轻量模型（与 Brick-Anything 的结构感知 token 化路线互补）；把铰接校验从离散采样扩展到运动全域验证，并支持闭环机构（当前运动环会直接报错）；引入多智能体协作，让规划者分解场景、多个建造者并行搭建子模块再由验证器统一合验，以加速 29k+ 零件级别的超大构建。
复现评估
复现条件较友好。代码在项目页 avalovelace1.github.io/brickwright 开源，BrickLayer 是独立 Python 包，评测集 BrickNet-512 公开，整条流水线无需训练、无需 GPU：全部实验通过商业 API 完成（Claude Haiku 5.5、GPT-6 Luna/Sol/Astra，High reasoning），按 2026 年 10 月 token 定价，完整版每样本平均成本 $0.03-$1.28、耗时 143-415 秒，512 样本全量跑一遍的 API 费用估计在几百美元量级，普通电脑即可承担。风险有三：一是结果与闭源模型版本强绑定，模型下架或换代后数字会漂移；二是连接件标注来自 BrickNet 注释加作者补充（如 15° 旋转判定滑动关节），数据工程的开源完整度需查仓库；三是人工复核环节（资深乐高设计师校准 0.2-1.4 个百分点偏差）难以复制，但影响很小，跳过亦可。综合评估复现难度：中等偏低，核心结论对模型版本相对稳健。
论文图表
分两部分。(a) 展示方法全流程：用户输入文本提示（如「被海蛇围困的灯塔」），智能体编写生成代码，编译并运行测试，验证无碰撞、无悬空、连通性，未通过则检视结果并修改，通过后得到物理可行的模型；同时展示能力范围——图像条件输入、铰接构建（可摆姿势的螃蟹）、场景级大构建（15,067 零件的香港维多利亚港），全部使用真实乐高零件。(b) 展示各代模型（GPT-6 Luna 到 GPT-6 Astra、Claude Haiku 5.5）在 Codex/Claude Code 下的输出全部 Colliding（红色轮廓标出网格相交），而加 BrickWright 后全部 Valid。
这是论文的电梯陈述图：一图同时交代工作流（写代码-验证-修复闭环）、输入输出形式、能力边界（铰接、大规模、图像条件）与核心卖点（所有档位模型从违例变有效），读论文前先看它能建立完整心智模型。
展示 GPT-6 Astra（高推理档）配 Codex 直接生成积木时的三个失败案例：两个碰撞案例（局部放大图中红色轮廓标出零件网格相互穿插）和一个悬空案例（零件无任何支撑通路）。这些模型是商用最强配置，却仍然产出物理不可行的装配。
直观定义了本文要解决的三类物理违例（碰撞、悬空，加上连通性断裂），并论证问题的真实性：即便最强模型已有自我验证意识（83% 的样本自写验证代码），仍不足以保证物理可行性，为工具箱方案提供动机。