🤖 AI

Automating Structural Analysis Across Multiple Software Platforms Using Large Language Models

该研究提出了一种基于两阶段多智能体架构的大语言模型，能够自动将用户输入的结构信息统一解析并转化为 ETABS、SAP2000 和 OpenSees 等多个有限元分析平台的可执行脚本，在跨平台框架结构分析任务中实现了超过 90% 的准确率。

原作者： Ziheng Geng, Jiachen Liu, Ian Franklin, Ran Cao, Dan M. Frangopol, Minghui Cheng

发布于 2026-04-14

📖 1 分钟阅读☕ 轻松阅读

原作者： Ziheng Geng, Jiachen Liu, Ian Franklin, Ran Cao, Dan M. Frangopol, Minghui Cheng

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文讲述了一个非常酷的想法：如何让人工智能（AI）像一位“全能翻译官”一样，自动帮结构工程师在不同软件之间“变魔术”，把设计图纸变成可运行的分析代码。

为了让你更容易理解，我们可以把整个结构分析过程想象成**“盖房子”，而这篇论文就是关于如何雇佣一位“超级管家”**来帮你搞定所有繁琐的准备工作。

1. 背景：工程师的烦恼

想象一下，你是一位建筑师（结构工程师），你想盖一栋大楼。你需要知道这栋楼会不会在台风中倒塌，或者在大地震中会不会摇晃得太厉害。

现状：为了算这些，你需要用专业的“计算器”（软件），比如 ETABS、SAP2000 或 OpenSees。
痛点：这些软件就像三种完全不同的语言。
- 有的软件喜欢听“指令式”的命令（像 OpenSees，全是代码）。
- 有的软件喜欢“菜单式”的操作（像 SAP2000，点点鼠标）。
- 还有的软件喜欢按“楼层”来组织（像 ETABS，先定楼层再放柱子）。
以前的问题：以前的 AI 就像一个只会说一种方言的翻译。如果你让它用 OpenSees 算，它可能很行；但如果你让它用 ETABS 算，它就晕头转向了。工程师不得不手动把数据从一个软件“搬运”到另一个软件，既慢又容易出错。

2. 解决方案：多智能体“超级管家”团队

这篇论文提出了一种新的 AI 架构，它不是让一个 AI 单打独斗，而是组建了一个**“特工小队”（多智能体架构）**。这个团队分两步走：

第一阶段：理解与规划（大脑团队）

想象你给这个团队发了一条语音消息：“我要盖一栋楼，宽 6 米，高 5 层，左边受风，材料用钢……"

分析员（Problem Analysis Agent）：像一位秘书，把你说的话拆解成关键信息（哪里是墙，哪里是柱子，多重，多高）。
规划师（Construction Planning Agent）：像一位工头，决定盖楼的顺序（先打地基，再立柱子，最后盖屋顶）。
绘图员（Node & Element Agents）：像测量员，把楼的具体坐标、连接关系画出来。
负载员（Load Assignment Agent）：像搬运工，把风力和重力准确地放在该放的位置。

关键魔法：这一阶段，不管最后要用哪个软件，他们先把所有信息整理成一份通用的“万能食谱”（统一的 JSON 文件）。这就好比不管你要做中餐、西餐还是日料，先把食材和做法都列在一张通用的清单上。

第二阶段：翻译与执行（手艺人团队）

现在，手里有了“万能食谱”，团队里的翻译员们开始工作了。他们同时开工，把食谱翻译成不同软件能听懂的“方言”：

OpenSees 翻译员：把食谱变成一堆代码指令（.tcl 文件）。
SAP2000 翻译员：把食谱变成点选菜单的脚本（.s2k 文件）。
ETABS 翻译员：这里有个特殊的**“楼层规划师”**，因为 ETABS 喜欢按楼层说话，所以这位翻译员会先把通用的清单重新整理成“按楼层排列”的格式，再翻译成脚本（.e2k 文件）。

3. 结果：他们做得有多好？

研究人员找了 20 个不同的“盖楼”难题（有的楼歪歪扭扭，有的受力复杂），让这位“超级管家”团队去尝试，并且每个题目做了 10 次测试。

表现：这个团队超级稳！在 10 次尝试中，有超过 90% 的时候都能一次性生成完美的代码，直接运行出结果。
- 对 SAP2000 是 100% 完美。
- 对 ETABS 和 OpenSees 也都在 98%-99% 左右。
对比：
- 如果让目前最厉害的通用 AI（比如 GPT-5 或 Gemini-3）直接去干这事，它们就像只会背字典但不会做饭的厨师。
- 它们能写出看起来像代码的东西，但一运行就报错（比如把“柱子”连到了“空气”上，或者把“楼层”搞混了）。
- 通用 AI 在商业软件（SAP/ETABS）上的成功率几乎是 0%，因为它们不懂那些软件特有的“行规”和“语法”。

4. 为什么这很重要？（比喻总结）

以前：你想去三个不同的国家旅行，必须分别找三个不同的导游，还要自己学三种语言。
现在：你只需要跟一位**“全能领队”说话。他听懂你的需求，然后派出三个精通当地语言的向导**，分别带你去三个国家，而且保证你走的路都是对的。
成本与速度：虽然这个团队人多（需要多个 AI 协作），但他们干活很快（大概 2 分钟搞定一个复杂模型），而且很便宜（每次算一次只要几分钱）。

总结

这篇论文的核心就是：用“分工合作”的 AI 团队，解决了 AI 不懂“行业方言”的难题。 它让结构工程师不再需要手动在不同软件间反复横跳，只需输入自然语言描述，AI 就能自动在多种专业软件中生成完美的分析模型。这就像给工程师装上了一双“透视眼”和“万能手”，让复杂的工程计算变得像点外卖一样简单。

以下是基于该论文《利用大语言模型跨多个软件平台自动化结构分析》（Automating Structural Analysis Across Multiple Software Platforms Using Large Language Models）的详细技术总结：

1. 研究背景与问题 (Problem)

现有局限：尽管大语言模型（LLM）在自动化结构建模和分析方面展现出巨大潜力，但现有研究主要集中在让 LLM 操作单一的结构分析软件平台（如仅 OpenSees 或仅 SAP2000）。
实际需求：在实际工程实践中，结构工程师通常需要根据项目需求、用户偏好和公司限制，灵活使用多种有限元分析（FEA）工具（如 ETABS, SAP2000, OpenSees）。
核心挑战：缺乏能够跨不同软件平台自动工作的 LLM 系统。如果为每个软件单独训练 LLM，将严重限制其可扩展性和实际部署。此外，通用 LLM 在处理特定软件的严格语法要求和独特的建模逻辑（如 ETABS 的“楼层”逻辑与 OpenSees 的“节点/单元”逻辑差异）时，往往表现不佳，容易产生幻觉或语法错误。

2. 方法论 (Methodology)

本研究提出了一种两阶段多智能体架构（Two-Stage Multi-Agent Architecture），旨在将结构建模任务解耦为“语义推理”和“平台特定代码生成”两个部分。

阶段一：输入解释与语义推理 (Input Interpretation & Semantic Reasoning)

目标：将用户的自然语言描述转化为与软件无关的统一结构化表示（JSON 格式）。
核心模型：使用 GPT-OSS 120B，因其具备强大的语义推理能力。
智能体协作：
1. 问题分析智能体 (Problem Analysis Agent)：从自然语言中提取几何、边界条件、荷载和材料属性等关键参数。
2. 施工规划智能体 (Construction Planning Agent)：制定自下而上、从左到右的组装逻辑。
3. 节点智能体 (Node Agent)：推导节点 ID、坐标及支撑类型。
4. 单元智能体 (Element Agent)：定义单元类型、连接关系及端点坐标。
5. 荷载分配智能体 (Load Assignment Agent)：将集中荷载和分布荷载映射到相应的节点和单元。
输出：生成一个包含所有建模信息的统一 JSON 文件，作为中间数据格式。

阶段二：跨平台并行代码翻译 (Parallel Code Translation)

目标：将统一的 JSON 文件转换为特定 FEA 平台可执行脚本（.tcl, .s2k, .e2k）。
核心模型：使用 Llama-3.3 70B Instruct Turbo（用于代码生成）和 GPT-OSS 120B（用于特定逻辑映射）。
平台适配策略：
- OpenSees & SAP2000：采用几何翻译智能体和代码编译智能体。由于这两者的建模逻辑（定义节点、单元、材料、荷载）与 JSON 结构相似，直接进行语法转换和脚本组装。
- ETABS：引入额外的语义映射智能体 (Semantic Mapping Agent)。因为 ETABS 采用基于“楼层（Story-based）”的建模逻辑（先定义楼层，再分配构件），与通用的节点/单元逻辑不同。该智能体负责将 JSON 中的对象定义转换为 ETABS 所需的楼层级表示，然后再进行代码生成。
执行方式：不同平台的翻译流程并行执行，提高了效率并支持未来扩展更多平台。

3. 关键贡献 (Key Contributions)

首个跨平台多智能体框架：提出了一种能够同时处理 OpenSees、SAP2000 和 ETABS 三种主流软件的多智能体 LLM 架构，解决了工程实践中多工具并用的痛点。
解耦架构设计：通过“统一 JSON 中间层”将高层语义推理与底层特定软件语法生成解耦，显著提高了系统的可扩展性和鲁棒性。
针对特定逻辑的适配：专门设计了“语义映射智能体”来解决 ETABS 独特的楼层建模逻辑与通用 FEA 逻辑之间的不兼容问题。
轻量化与经济性：利用轻量级开源模型（GPT-OSS-120B, Llama-3.3-70B）作为骨干，相比使用昂贵的闭源通用大模型，大幅降低了计算成本。

4. 实验结果 (Results)

研究使用了 20 个具有代表性的框架结构问题（涵盖不规则拓扑、不同跨度和层高），在三种软件上进行了 10 次重复试验。

准确性表现：
- SAP2000：100% 准确率（所有问题在所有试验中均成功）。
- ETABS：99% 平均准确率（20 个问题中 18 个达到 100%，2 个为 90%）。
- OpenSees：98% 平均准确率（大部分问题 100%，5 个问题为 90%）。
- 总体：所有案例的准确率均超过 90%。
与最先进通用 LLM 的对比：
- GPT-5.2：OpenSees 平均准确率仅 18%，SAP2000 和 ETABS 为 0%。主要失败原因是无法处理严格的语法要求（如 SAP2000 的表头匹配）和建模逻辑差异（如 ETABS 的楼层逻辑）。
- Gemini-3-Pro：OpenSees 平均准确率为 79%，但在 SAP2000 和 ETABS 上同样全部失败。
- 结论：通用 LLM 在端到端结构建模中不可靠，而本研究的专用多智能体架构表现显著更优。
效率与成本：
- 时间：生成脚本平均耗时约 2 分钟（OpenSees ~113s, SAP2000 ~127s, ETABS ~144s）。
- 成本：每个问题每个平台的成本仅为 **$0.012 - $0.025**，远低于通用模型（约$ 0.04 - $0.05）。

5. 意义与展望 (Significance)

工程实践价值：该系统无需替换现有的工程软件，而是作为输入接口补充现有工作流。工程师可以使用自然语言描述问题，系统自动生成可导入的脚本，大幅减少手动建模时间和语法错误。
跨平台验证：支持在同一项目中并行生成不同软件的分析脚本，便于工程师进行跨平台结果对比和验证，增强决策信心。
可扩展性：模块化设计使得未来集成新的 FEA 平台变得容易，只需添加对应的翻译智能体。
局限性：目前仅适用于矩形框架结构（垂直柱、水平梁）。未来工作将扩展至支撑系统、悬臂构件等复杂结构，并引入更真实的非结构化输入（如草图、非标准文本）。

总结：该论文通过创新的多智能体架构，成功解决了 LLM 在跨多种结构分析软件自动化应用中的瓶颈问题，实现了高准确率、低成本且可扩展的自动化结构分析工作流，为土木工程领域的 AI 落地提供了重要的技术路径。