航空发动机的结构强度分析，难点常常不在算得快不快，而在流程“接不上”。设计规范、输入格式、单位制、节点命名只要有一处变化，原先写死的脚本流水线就会报错，工程师只能停下来改代码。瑞典航空部件制造商 GKN Aerospace 的涡轮后承力结构（Turbine Rear Structure，TRS）分析就遇到了这种局面：整机厂交付的新载荷文件带来了四处偏差，旧流水线无法直接消化。
让智能体管“解释”，让工具管“计算”
论文提出 DUCTILE（Delegated, User-supervised Coordination of Tool- and document-Integrated LLM-Enabled）编排方法。核心是分工：大模型负责理解任务、读取设计规范、检查输入数据并规划处理路径；所有计算交给经过验证的确定性工具。输入变化由智能体吸收，工程严谨性、可追溯性和认证合规仍由原有工具链保证。
案例中的四处偏差分别是：整机厂发来的 YAML 文件与工具的 JSON 解析器不兼容、单位制变为英制、导向节点名称发生变化，以及要求在原始数据之外对所有 Fx 力额外乘 1.04 的修正系数。传统脚本流水线遇到任何一项都要人工介入或改代码。
七步计划与两种监督方式
实现上，团队用 Claude Code 作为智能体框架，设计实践文档放在 MCP 文档服务器上，载荷处理工具以 Python 包发布，并同时提供人类可读和面向大模型的 llms.txt 接口说明。智能体先读任务 PDF、检索设计规范、检查工作目录和上一次分析结果，在推理轨迹里识别出全部四处偏差，随后给出七步处理计划，等工程师批准再动手。
两位工程师采用了不同监督方式：一位把任务整体交给智能体，结束后统一检查输出；另一位不熟悉智能体，要求一步一步来，每步都先核对中间结果。两条路径最终得到完全相同的输出：6 个 .inp 载荷工况文件、一张包络汇总表，以及与上一次分析的超限对比。
用 pass^k 而不是“演示一次”来验收
团队没有用单次演示证明可用，而是按工程软件验证的思路做重复试验。同一场景独立运行 10 次，提示词、工具和上下文都不改；判定同时使用 LLM-as-judge（Opus 4.6）检查脚本是否处理了四项偏差，以及确定性比对检查最终载荷汇总值。10 次全部通过，专家人工复核与自动评判的一致率为 100%。论文还借用航空材料许用值的概率口径，建议开发阶段 k=3、部署阶段 k≥10，任务越关键、自主度越高，重复次数越要多。
方法刻意不微调、不做持久记忆，设计规范在运行时从文档和技能中检索。这样换模型、升工具版本都不必重训，但也把压力转移到文档质量上：智能体暴露了原先只存在于老师傅脑子里的隐性步骤，团队不得不把设计实践补写完整。
值得强调的是，智能体接手的是“操作熟练度”，不是“工程判断”。结果是否符合物理直觉、方法是否适用、能否满足认证要求，仍由工程师负责。论文也提醒另一面：把杂活拿走之后，监督多个智能体可能变成新的疲惫岗位，组织需要为判断力的培养继续投入资源。
资料来源：DUCTILE: Agentic LLM Orchestration of Engineering Analysis in Product Development Practice — arXiv（2026-03）。本文为技术要点整理/编译，非原文全文。