用有限元分析作为反馈的自改进 CAD 生成智能体 Self-Improving CAD Generation Agents with Finite Element Analysis as Feedback
用蓝图+21视图+FEA 反馈，让 LLM 智能体生成满足工程约束的 STEP 装配体。
前置知识
CadQuery 与 STEP 文件
CadQuery 是基于 OpenCascade 的 Python 参数化 CAD 编程库，可编写脚本生成实体模型并直接导出为 STEP（ISO 10303 AP242）文件，支持布尔运算 $\cup, \cap, -$，适合作为 LLM 输出的可执行 CAD 表达。
本文 agent 直接写 CadQuery 代码并执行导出 STEP，因此读者需理解这种 code-as-CAD 范式才能看懂方法闭环。
有限元分析 (FEA) 与 CalculiX
FEA 将几何离散为网格并求解应力、位移、屈曲、模态等物理量；CalculiX 是开源求解器，兼容 Abaqus 输入语法，典型输出包括最大 von Mises 应力 $\sigma_{vM}$、位移 $\|u\|_\infty$、屈曲因子 $\lambda_b$ 与各阶固有频率 $f_i$。
FEA 是本文工程反馈层的核心，决定了任务是否被判定为合格，是理解整个闭环的关键。
LLM Coding Agent 工具调用循环
现代 coding agent (如 Codex、Claude Code) 在沙盒中读写代码、运行命令、接收结构化输出，反复迭代完成任务；测试时计算可花在内部推理或外部工具交互上。
本文研究如何把 FEA、渲染、蓝图三种工具接入这种 harness，区分一次性推理预算与闭环工具反馈两类测试时计算。
工程需求合约 (typed requirements)
将工程契约编码为可被求解器或几何检查器自动判定 pass/fail 的类型化指标，例如最大 von Mises 应力、屈曲因子、面密度等，每条带阈值与适用范围。
这是 Hephaestus-CCX 基准的判分基础，与传统依赖与参考几何对比的评测范式截然不同。
研究动机
现有学习式 CAD 生成方法存在两大根本缺陷。第一，评测依赖金标准几何匹配——Chamfer 距离 $CD(P, Q) = \frac{1}{|P|}\sum_{p \in P}\min_{q \in Q}\|p-q\|_2^2 + \frac{1}{|Q|}\sum_{q \in Q}\min_{p \in P}\|p-q\|_2^2$、F-score $F_\tau = \frac{2P_\tau R_\tau}{P_\tau + R_\tau}$、IoU $= |A \cap B|/|A \cup B|$、Invalidity Ratio，无法捕捉工程可用性：螺栓孔偏 1 mm 或管件在额定载荷下屈服会被误判为合格；高 IoU 也不代表满足物理规格。第二，零件合成与装配被当成两个独立任务，要么只生成孤立零件不处理接口，要么从已可装配的 Fusion 360 库中预测 mate，从未要求模型从零生成需要与邻居配合并承受载荷的新零件。Hephaestus-CCX 中 Brief 1 设计的 $25.4\,\text{mm OD} \times 3.05\,\text{mm}$ 壁厚 1018 DOM 钢管越野空间框架就是典型例子，要求 $5/4/4/6\,G$ 冲击、$3.5\,G$ 轮跳、屈曲因子 $\lambda_b \geq 1.5$，传统几何匹配方法完全无法验证这些契约。
本文的目标是本文将 CAD 生成重新定义为「从自由文本工程简报生成完整装配的 STEP 工件」这一工业级任务，并通过有限元分析验证其工程可用性。具体目标包括：(1) 发布 Hephaestus-CCX 基准（50 个工程简报，覆盖 20 个单零件 + 30 个多装配，配 CalculiX 求解套件与类型化需求检查器）；(2) 在生产级 coding agent (Codex、Claude Code) 内实现并对比结构化蓝图、21 视图渲染和 FEA 三种反馈源；(3) 量化多次反馈迭代的复合增益，并区分「一次性推理预算」与「闭环工具反馈」两类测试时计算的有效性。
与已有工作不同的是，本文的独特切入角度是把「工具反馈」与「测试时计算」放回 CAD agent 设计的中心。区别于依靠单次强化推理或参考几何匹配的已有工作，作者主张有效测试时计算 = 智能体在外部验证器（求解器+渲染器+检查器）返回的具体工程证据下闭环修复；并通过同时引入 pre-CAD 蓝图规划、21 视图富视觉检查、CalculiX 物理验证三件套，让 frontier 模型能在 10 轮迭代中从 38.8% 提升到 60.5% 的需求通过率。这与最近关于测试时扩展的讨论形成对照，揭示「更具体的反馈」比「更长的内部推理」更稳定地提升产出质量。
核心方法
方法整体是「LLM 智能体 + 确定性控制器」的协作流水线。智能体负责设计决策（写 CadQuery、修改 selector、调整蓝图），控制器负责执行、测量、装配、验证。每一轮智能体接收同一份工程简报和交付契约，可在三个可选工具中按需调用：(1) 蓝图技能把简报分解为 schema-v4 蓝图.yaml，锁定功能需求、材料、载荷路径、接口、支持/载荷 selector、验证目标，并把每个零件拆成来自封闭参数原语语法（加性/减性/修饰）的构造单元；(2) 富视图工具通过 ParaView 渲染 21 个定标视角 （12 外视 + 6 近距 + 3 alpha 混合 X 光剖切）让智能体做静态审视；(3) 控制器外置的 FEA 回路使用 gmsh 网格化 → CalculiX 求解 → 与简报侧模板拼接，输出应力、位移、模态、屈曲、接触与间隙等类型化失败清单。智能体最多 10 轮迭代，每轮把失败原因编码为蓝图变更后再写下一版 CadQuery。
核心创新在于把工程反馈分层为三种互补监督信号：先验的文本蓝图、中观的几何视觉反馈、后验的物理仿真反馈。已有方法要么用单次参考几何匹配，要么用 VLM 评估外视图，缺少从规划到验证的完整工程闭环。文本蓝图把工程承诺外化为审计可查的 schema（封闭参数原语、接口锁定、验收声明），解决「智能体写不出工程级容差蓝图」的问题；21 视图富视觉把内部配合暴露给智能体，弥补「外视图看不到 mating 错误」；FEA 反馈把物理合规性从外部参考几何里解放出来，使评测不再依赖单份 curated mesh。本质上，这是把 LLM agent 从几何模仿者改造成工程迭代者。
方法步骤详情
流水线分四步。第一步是任务初始化：控制器为每个简报创建隔离工作区，注入同一份 brief、交付合约和工具清单，并固定 Hephaestus-CCX 的 CalculiX 套件作为外部验证器。第二步是规划阶段：若启用蓝图技能，智能体先生成 design_brief.md 和 blueprint.yaml，列出功能需求、材料、载荷路径、接口、support/load selector、验收指标，并把每个零件拆解为封闭原语语法的构造单元（加性/减性/修饰算子），再把选择器位置编码到 selector 元数据中。第三步是 CAD 编写与执行：智能体生成 CadQuery Python 代码，控制器执行并导出为 STEP 工件（ISO 10303 AP242），同时对声明尺寸、孔位、配合预期做确定性测量。第四步是反馈循环：智能体可选调用富视图（21 视图渲染 + 测量）做视觉审视，记录 verdict、summary、issues、failure_category、primary_claim_id、retry_advice 等紧凑字段；提交后控制器运行 FEA，输出失败需求、剩余裕度、selector/载荷区问题、分析失败原因，下一轮把 FEA 与富视图结果先编码进蓝图再修改 CadQuery，最长 10 轮。
技术新颖性
技术新颖性体现在三方面。其一，Hephaestus-CCX 是首批把工程需求合约 + 开源 FEA 求解器绑定到 LLM 生成 CAD 的基准，覆盖专利、供应商数据表、NASA-STD/ECSS/AISC/MIL-STD/FIA Art.253 等工程标准与高校竞赛共 466 候选简报，筛出 50 例且每条数值阈值都内联在 brief 里。其二，蓝图技能作为一个模型无关的 skill 包（23 文件、1.5k 行、近 50k 字符）提供规划建议、schema 模板、发布清单、难度/质量 rubric 与 scope/datum/interface/load/material/assembly/safety/validation 八个参考模块，让 Codex 与 Claude Code 不同 harness 共享同一规划流程。其三，21 视图富视觉把内部 X 光剖切引入 CAD agent 视觉审视（远超 4–6 视图的常规做法），并以 typed 报告形式让反馈进入下一轮蓝图更新，从而把 LLM 测试时计算组织成「越来越具体的工程证据」而非单纯延长推理链。
实验结果
实验在 Hephaestus-CCX（50 例）、S2O 子集（133 例）、Fusion 360 子集（225 例）上对比 GPT-5.5、GPT-5.4、Opus-4.7、Sonnet-4.6 在 xhigh/high/max 推理档下的表现。核心发现：(1) H-CCX 几乎未被攻破——主扫描 400 次首试全 0/20、0/30 严格通过，仅一次 FEA 修复轮带来额外 1 例；最优首试为 Opus-4.7/xhigh 单零件 32.7% 与 GPT-5.5/xhigh 多零件 15.0% 平均需求通过率。(2) 反馈显著改善但程度因模型而异：富视图把 GPT-5.5/xhigh H-CCX 均值从 19.4% 抬到 29.3%、Fusion 360 Box-IoU 从 0.397 抬到 0.505；蓝图把 GPT-5.5/xhigh S2O Box-IoU 从 0.444 抬到 0.592；GPT 系几何 Box-IoU 平均提升约 0.09。(3) 首试设计与反馈修复是两种能力：Opus-4.7/xhigh 单零件首试 32.7% 但反馈后略退，GPT-5.4/high 起点 23.3% 但 FEA 修复后 +18.8 分。(4) 测试时扩展主要来自具体反馈：GPT-5.5/high 10 轮 H-CCX 均值从 38.8% 升到 60.5%，严格通过 9/50，每例平均 68 分钟（约为 10 分钟两轮设定的 7×），第 2 轮注入富视图带来首次跃升、第 6 轮起 FEA 反馈附加失败裕度带来第二次跃升。(5) 推理档位非单调：多行 high 反而超过 xhigh，说明「如何花测试时计算」同样重要。(6) 9 例严格通过的修复可分四类：真结构再调、简化网格几何、checker 契约修复、隐藏质量属性修复。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Hephaestus-CCX 单零件 Mean req pass | 需求通过率 (%) | GPT-5.5/xhigh 25.9% → FEA 修复 39.4%；GPT-5.4/high 23.3% → 42.1%；Opus-4.7/xhigh 32.7% → 31.4% | 无蓝图、无富视图的 0-shot 生成 | GPT 系单轮 FEA 修复 +13.5 ~ +18.8 分，Claude 系 ~ -1.3 ~ +4.6 分 |
| Hephaestus-CCX 多零件 Mean req pass | 需求通过率 (%) | GPT-5.5/high 8.3% → FEA 修复 39.2%；GPT-5.5/xhigh 15.0% → 36.1%；Opus-4.7/xhigh 6.6% → 28.6% | 无反馈的 0-shot 生成 | GPT 系 +21.1 ~ +30.9 分，Claude 系 +18.0 ~ +22.0 分 |
| Hephaestus-CCX 10 轮最长反馈闭环 | 需求通过率 (%) 与 strict pass 数量 | GPT-5.5/high 由 38.8% 提升到 60.5%，strict pass 9/50，每例 68 分钟 | 两轮 10 分钟设定下的 38.8% | +21.7 绝对分（相对 +55.9%），9 例从无到有 |
| S2O 几何重建 (Box-IoU ↑) | Box-IoU | GPT-5.5/xhigh 0.444 → +blueprint 0.592；GPT-5.4/xhigh 0.577 → +blueprint 0.608；+rich-view 同样显著 | 无反馈直接生成 | GPT-5.5/xhigh +0.148（+33.3%），GPT-5.4/xhigh +0.031 |
| Fusion 360 几何重建 (Box-IoU ↑) | Box-IoU 与 F1% | GPT-5.5/xhigh IoU 0.397 → +rich-view 0.505，F1% 0.042 → 0.070；GPT-5.4/xhigh IoU 0.410 → 0.502 | 无反馈生成 | GPT 系 IoU 平均 +0.097，F1% 提升约 0.025 |
| Chamfer Distance 越低越好 (S2O 与 Fusion 360) | CD ↓ | GPT-5.5/xhigh S2O 0.060 → 0.047；Fusion 360 0.220 → 0.163 | 无反馈生成 | S2O -21.7%，Fusion 360 -25.9% |
局限与改进
局限性体现在多个层面。第一，Hephaestus-CCX 仅 50 例（20 单 + 30 多），样本量限制统计显著性，多档位推理非单调本身就反映这种不稳定性。第二，基准使用固定 CalculiX + gmsh 配置，并非真实工业 Ansys/Abaqus 工程审计流程；需求阈值由作者从工程标准内联抽取，不能完全代表行业容差等级。第三，反馈回路对 frontier 模型依赖严重——Codex 与 Claude Code 之外的开源模型是否能同样受益尚未验证，且 50 例 × 10 轮最长 68 分钟/例的代价意味着单基准耗资巨大。第四，「类型化合约」仍依赖 selector 元数据正确标注，若 selector 命名错误，失败原因会被错误归因（Table 4 中 prosthetic pylon、AIJ、KOSEN 正是「物理过关但 selector binding 失败」的伪阴性）。第五，21 视图固定视角对拓扑变化大的装配可能漏掉动态配合；第六，作者没有报告 FEA 求解失败（meshing 不收敛、奇异矩阵）时的回退策略，case 整体被算作失败。
独立分析的弱点
独立分析下三个突出弱点。其一，「意图对齐」问题：H-CCX brief 是自然语言规格，但所有数值阈值都写死在简报里，agent 实际上在做一个有监督检索-执行任务而非真实工程推断；若简报中阈值含糊（如「足够强」），当前流水线无解。改进方向是引入需求澄清子环节，让 agent 反向询问或显式假设未指定量。其二，「失败归因」粗糙：FEA 报告只列失败需求 ID 与裕度，对真实工程师而言缺少「哪个网格单元应力集中、哪条边界条件假设错」的诊断；Table 4 显示 ECSS 板 case 仅靠内部 X 光就漏掉了面密度错误，需要富视图 + FEA 联合归因。改进方向是在 CalculiX 输出里附加单元级 stress/displacement map、敏感性分析或 surrogate gradient，让反馈进一步可解释。其三，「成本/收益失衡」：最长 10 轮闭环平均 68 分钟/例，单基准消耗巨大但 strict pass 仍只有 9/50，且 7× 时间换 +21.7 分需求通过率的性价比随轮数递减。改进方向是引入早停或自适应反馈选择器，根据首两轮的失败模式只调用最相关工具。
未来方向
作者明确提出的方向包括：把蓝图+富视图+FEA 三件套抽象为可重用的 agent skill 库，跨模型/跨 harness 共享；引入更细粒度的单元级 FEA 报告以减少 checker-contract 类伪失败；以及扩大 H-CCX 规模。基于结果还可延伸：(1) 多智能体分工——一个做装配布局、一个做单零件细化、一个做 FEA 解读，缓解单 agent 在 10 轮内的认知负担；(2) 把 FEA 反馈与 differentiable simulation / neural surrogate 结合，让梯度信息能直接反传到 CadQuery 代码生成，缩短收敛轮数；(3) 把 benchmark 扩展到机构学（运动副）、热-结构耦合、流体-结构耦合等多物理场，验证文本蓝图+物理反馈范式的可推广性；(4) 与真实企业 PDM/PLM 流程集成，把材料库、版本管理、变更请求纳入闭环；(5) 研究小模型（如 7B/13B）配合 skill 包能否在受限算力下复现 frontier+反馈的优势。
复现评估
Hephaestus-CCX 50 例的 brief、可执行需求检查器与 CalculiX 套件作者承诺随论文发布，但 23 文件、1.5k 行、~50k 字符的 blueprint skill 包与 21 视图 ParaView 脚本在论文中未明确给出 GitHub 链接；数据来源（专利、NASA-STD、ECSS、AISC、MIL-STD、FIA Art.253、供应商数据表、466 候选工程竞赛简报）描述清楚但全量数据未公开。算力方面，10 轮最长闭环在 Codex GPT-5.5/high 上需约 $50 \times 68 \approx 56$ 小时单模型时间，加上全模型×全档位扫表，单次完整实验估计需数百到上千 GPU/API 小时；FEA 本身依赖 CalculiX + gmsh 在 CPU 集群运行，meshing 失败会显著拉长耗时。复现难度较高：(1) 需生产级 Codex 或 Claude Code 订阅与最新 frontier 模型 API；(2) 21 视图 ParaView 渲染对 GPU/显存有要求；(3) 50 例需求检查器需正确编写 gmsh 模板与 CalculiX 输入；(4) 部分 Case 需领域知识（如 FIA Art.253 rollcage 规则）才能解读结果。
论文图表
