DUCTILE: Agentic LLM Orchestration of Engineering Analysis in Product Development Practice

该论文提出了 DUCTILE 框架，一种由大语言模型代理进行自适应编排、工程师负责监督的混合自动化方法，旨在解决航空航天产品开发生态中因工具接口和数据格式频繁变更而导致传统工程分析自动化失效的问题，并验证了其在处理输入偏差时仍能生成符合规范且准确结果的有效性。

要点

这篇论文介绍了一种名为 DUCTILE（意为“柔韧的”）的新方法，旨在解决工程师在开发产品（特别是飞机部件）时遇到的一个老难题：自动化太脆弱，稍微变一下就“断”了。

为了让你轻松理解，我们可以把整个故事想象成**“一位超级聪明的翻译官（AI 代理）带着一群严谨的工匠（传统软件）干活”**。

1. 以前的困境：像搭积木，换一块就塌

想象一下，你有一个自动化的流水线，专门用来组装飞机零件。

• 以前（传统自动化）： 这个流水线是死板的。如果供应商送来的零件从“方形”变成了“圆形”，或者把“米”换成了“英尺”，流水线就会卡死、报错，甚至生产出一堆废品。
• 后果： 工程师们不得不花大量时间像“修水管工”一样，去手动调整这些死板的程序，而不是去设计更好的飞机。一旦有人离职，或者软件更新了，整个自动化系统就瘫痪了。

2. DUCTILE 的解决方案：聪明的“翻译官” + 严谨的“工匠”

这篇论文提出的 DUCTILE 方法，把任务分成了两半，就像**“大脑”和“双手”**的配合：

• 大脑（LLM 智能代理）： 这是一个像大语言模型（比如现在的 AI）一样的“超级翻译官”。它不直接干活，也不直接计算。它的任务是：

  • 读说明书： 理解工程师的意图和公司的老规矩。
  • 看现场： 检查送来的数据（比如发现这次是 YAML 格式而不是 JSON，或者单位变了）。
  • 做计划： 告诉“工匠”们该怎么调整步骤。
  • 特点： 它很灵活（Ductile），能应对各种突发状况。

• 双手（传统工程软件）： 这些是那些经过严格认证、绝对严谨的旧软件（比如计算强度的工具）。

  • 任务： 它们只负责死板地执行大脑下达的指令。
  • 特点： 它们绝对可靠，不会乱算，保证结果符合航空安全标准。

比喻：
以前是**“死板的机器人”在干活，一旦输入变了，它就傻眼。
现在是“一位经验丰富的老工头（AI）”看着图纸和新材料，灵活地指挥“一群严谨的工匠（传统软件）”**干活。如果材料变了，工头会立刻告诉工匠：“嘿，把尺子换成英尺，再按那个新公式算一下”，然后工匠们继续精准地干活。

3. 实际案例：飞机零件的“体检”

作者在一家航空制造公司（GKN Aerospace）测试了这个方法。

• 任务： 给一个飞机发动机后部的零件做强度分析。

• 突发状况： 供应商发来的数据有四个大变化，足以让旧系统崩溃：

  1. 文件格式变了（从 JSON 变成了 YAML）。
  2. 单位变了（从公制变成了英制）。
  3. 零件名字变了（从“左/右”变成了“左/右”的另一种叫法）。
  4. 计算规则微调（所有受力都要乘以一个系数）。

• 结果：

  • 传统方法： 程序员得重写代码，或者工程师得手动改数据，耗时耗力。
  • DUCTILE 方法： AI“工头”读到了这些变化，自动生成了新的处理脚本，指挥软件完成了计算。
  • 验证： 他们让 AI 独立跑了 10 次，结果100% 正确。而且，无论是让一位经验丰富的工程师“全权委托”，还是让一位新手“步步监督”，结果都一样完美。

4. 核心亮点：为什么这很重要？

• 不再脆弱： 就像橡胶（Ductile）一样，这个系统能拉伸、变形，适应变化，而不会断裂。
• 人类依然掌舵： AI 只是“代理”，它不替工程师做最终决定。工程师依然是老板，负责审核计划、监督过程，并对结果负责。这符合航空业严格的“安全认证”要求。
• 解放双手： 把工程师从枯燥的“改格式、对单位、调代码”中解放出来，让他们去解决真正需要创造力和判断力的问题。

5. 潜在的挑战与思考

论文也诚实地提到了风险：

• 过度依赖： 如果工程师太依赖 AI，可能会忘记基本的物理原理（就像司机太依赖自动驾驶，可能忘了怎么手动换挡）。
• 监督疲劳： 如果 AI 总是犯错，工程师可能会因为要时刻盯着它而感到精疲力竭。
• 知识文档化： 这个方法的前提是，公司的“老规矩”必须写在文档里。如果知识只存在于老工程师的脑子里（没写下来），AI 就学不会。

总结

DUCTILE 就像是给僵硬的工程自动化系统装上了一个**“智能大脑”。它不取代传统的严谨工具，而是作为润滑剂和翻译官**，让自动化系统在面对变化时变得柔韧，让工程师能更专注于创造，而不是修补。

这就好比：以前是死板的机器人在种地，下雨了它还在按程序播种，结果淹死了；现在是一位聪明的农艺师（AI）指挥精准的播种机（传统软件），下雨了农艺师立刻喊停，等天晴了再根据土壤湿度调整播种深度，最后机器依然精准地种出了好庄稼。

技术摘要

论文技术总结：DUCTILE——产品工程中基于智能体（Agent）的 LLM 编排方法

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

在航空航天等复杂工程领域，产品开发依赖于工程师、数据、方法和专用工具构成的生态系统。传统的工程分析自动化（如脚本、KBE 系统、PIDO 平台）面临严重的**脆弱性（Brittleness）**问题：

• 刚性接口依赖：传统自动化依赖于预定义的确定性接口（数据格式、单位、命名规范、工具版本）。
• 维护成本高：当产品演进导致输入数据格式变化、单位系统调整或工具更新时，自动化流程极易断裂，需要工程师进行大量手动干预或重写代码（即“数据清洗”和“工具编排”）。
• 知识孤岛：为了应对变化，组织往往依赖资深工程师的个案调整，导致关键知识集中在个人手中，造成组织脆弱性。
• 现有 AI 局限：现有的生成式 AI（如扩散模型）主要用于生成设计候选或预测性能，无法处理需要严格遵循文档化流程、调用特定验证工具并保证可追溯性的复杂工程分析任务。

核心痛点：如何在保持工程严谨性、可追溯性和认证合规性的前提下，使自动化系统能够适应工程实践中不可避免的输入变异和流程演变？

2. 方法论：DUCTILE 框架 (Methodology)

论文提出了 DUCTILE（Delegated, User-supervised Coordination of Tool- and document-Integrated LLM-Enabled，即“委托的、用户监督的工具与文档集成 LLM 赋能协调”）方法。其核心思想是将“适应性编排”与“确定性执行”分离。

2.1 核心架构原则

• LLM 作为编排层（Orchestrator）：负责解释文档化的设计实践、检查输入数据、识别偏差，并动态生成执行代码或调用工具。LLM 不直接进行工程计算，而是负责“思考”和“指挥”。
• 确定性工具作为执行层（Executor）：所有实际的工程计算、仿真求解和数据处理由经过验证的、确定性的工程工具（如 Python 脚本、商业求解器）完成。
• 人类监督：工程师负责审查计划、监督执行过程并对最终结果进行判断和批准，确保符合航空/汽车行业的认证标准。

2.2 技术实现细节

• 推理机制：利用 LLM 的**思维模式（Thinking Mode）**进行自我批判和推理，在处理模糊或意外情况前进行多步思考，减少幻觉。
• 工具调用（Tool Calling）：LLM 根据上下文动态选择并调用外部工具（如读取文件、运行脚本、查询数据库），而不是依赖训练权重中的静态知识。
• 上下文管理：将设计实践文档、API 文档、输入数据和任务描述放入上下文窗口，使 LLM 能够“零样本（Zero-shot）”学习并适应新任务，无需微调模型。
• 可观测性与可追溯性：系统记录所有中间步骤、工具调用参数、生成的代码和输出日志，确保每一步都可审计（Auditability）。

2.3 评估指标 (Pass-k)

借鉴航空航天材料认证中的统计方法（A-Basis, B-Basis），提出 Pass-k 指标：

• 定义：在 $k$ 次独立运行中，智能体均能正确完成任务的概率。
• 应用：根据任务风险等级设定 $k$ 值（如开发阶段 $k=3$，部署阶段 $k \ge 10$），以量化智能体的可靠性。

3. 主要贡献 (Key Contributions)

1. 提出 DUCTILE 方法：首次系统性地展示了如何利用 LLM 智能体作为中间层，连接工程师与经过验证的专用工程工具，解决了传统自动化在应对输入变异时的脆弱性问题。
2. 工业案例验证：在一家航空航天制造商（GKN Aerospace）的真实场景中进行了验证。任务涉及涡轮后部结构（TRS）的强度评估，处理了四种会导致传统脚本崩溃的输入偏差：
   • 文件格式变更（YAML 代替 JSON）。
   • 单位制变更（英制代替 SI 制）。
   • 节点命名规范变更（Left/Right 代替 Port/Starboard）。
   • 方法论修正（Fx 力需乘以 1.04 系数）。
3. 双模式人机协作验证：测试了两种不同的工程师监督风格：
   • 完全委托：工程师一次性授权，事后检查。
   • 增量发现：工程师分步指导，逐步建立信任。
     结果显示，两种模式下智能体均能产生正确且一致的结果。
4. 开源与可复现性：提供了完整的智能体应用实现、评估脚本和补充材料，供其他研究人员复现和改进。

4. 实验结果 (Results)

• 鲁棒性：在 10 次独立的重复运行中，智能体成功处理了所有四种输入偏差，100% 通过了定量（数值对比）和定性（LLM-as-a-judge 及专家审查）检查。
• 适应性：智能体能够阅读非结构化的设计实践文档，推断出正确的工作流，并自动编写脚本以适配新的输入格式和参数，无需修改底层工具代码。
• 可追溯性：所有生成的代码、中间文件和决策路径均被完整记录，满足工程审计要求。
• 人机交互：不同经验的工程师（熟悉智能体流程的新手与不熟悉的老手）均能有效利用该工具，且智能体能够适应不同的监督粒度。

5. 意义与影响 (Significance)

• 解决工程自动化瓶颈：DUCTILE 打破了传统自动化对“完美输入”的依赖，将工程时间从繁琐的数据清洗和脚本维护中解放出来，使其专注于高价值的工程决策。
• 平衡灵活性与严谨性：通过分离“概率性编排”和“确定性执行”，既利用了 LLM 的适应能力，又保留了工程工具的可信度和可认证性，符合航空安全标准。
• 知识显性化：该方法迫使组织将隐性的工程知识转化为结构化的文档和工具接口，减少了因人员流动导致的知识流失风险。
• 对未来工作的启示：
  • 机遇：消除枯燥的重复劳动，提升工程师效率。
  • 挑战：需警惕“监督疲劳”和工程判断力的退化。工程师的角色从“执行者”转变为“监督者和判断者”，这需要重新设计工作流程和培训体系，确保工程师保持对物理原理和结果合理性的深刻理解。
• 行业范式转变：标志着工程自动化从“刚性规则驱动”向“适应性智能体驱动”的范式转变，为复杂系统开发中的 AI 应用提供了新的参考框架。

总结：DUCTILE 证明了 LLM 智能体可以作为可靠的“编排者”，在严格的人类监督和确定性工具的支持下，有效应对工程实践中动态变化的挑战，为航空航天等高风险行业的自动化转型提供了可行的技术路径。