LLM驱动工程设计：多智能体框架与基准测试实践

1. 项目概述：当大语言模型遇上工程设计

最近在AI圈和工程软件圈里，一个叫EngiAI的项目讨论度挺高。乍一看标题“EngiAI: A Multi-Agent Framework and Benchmark Suite for LLM-Driven Engineering Design”，信息量就很大。简单来说，它想干一件事：用现在火热的LLM（大语言模型）来驱动复杂的工程设计流程，并且不是让一个模型单打独斗，而是搞了个“多智能体框架”，让多个AI“专家”协同工作，同时还配套了一个“基准测试套件”来衡量它们干得好不好。

这背后戳中了一个很现实的痛点。工程设计，无论是机械结构、电子电路还是建筑布局，从来都不是一个“一步到位”的活儿。它是一个典型的、高度结构化的、多阶段迭代的决策过程。比如设计一个零件，你得先明确需求（载荷、材料、成本），然后进行概念设计、详细建模、仿真分析、优化迭代，最后输出图纸或模型。这个过程里，工程师需要调用不同领域的知识（力学、材料学、制造工艺）、使用不同的专业软件（CAD, CAE, EDA），并在不同抽象层级（系统级、部件级、特征级）之间反复横跳。

传统的自动化工具，比如参数化设计或者基于规则的优化，灵活性有限，很难处理模糊的、自然语言描述的需求，或者应对需求中途变更的情况。而LLM，尤其是GPT-4这类模型，展现出了强大的自然语言理解、逻辑推理和代码生成能力。大家自然会想：能不能让LLM来当“总工程师”，指挥整个设计流程？

但问题来了。让一个“通才”LLM去精通所有工程细节，既不现实（上下文长度、专业知识深度有限），也不经济（token成本高）。于是，EngiAI的思路就很清晰了：分而治之，专业的人（Agent）干专业的事。它构建了一个多智能体系统，每个智能体负责设计流程中的一个特定环节，比如“需求解析Agent”、“概念生成Agent”、“仿真Agent”、“优化Agent”。它们之间通过标准化的“工作流”和“通信协议”进行协作，共同完成从一段文字描述到最终设计方案的自动化产出。

更关键的是，它还提供了一个Benchmark Suite（基准套件）。这太重要了。没有标准化的评估，你说你的AI设计得好，我说我的好，就成了“公说公有理，婆说婆有理”。这个套件就像一套“标准考题”，包含了不同难度、不同领域的工程设计问题（比如“设计一个能承受5kg重量的轻质支架”、“设计一个低通滤波电路”），以及对应的评估指标（如性能达标率、计算效率、方案创新性等），让不同方法能在同一个起跑线上公平比较。

所以，EngiAI瞄准的，正是LLM从“聊天工具”迈向“生产力工具”的关键一步——将其能力深度嵌入到严肃的、价值创造的核心流程中。它适合谁？首先是AI+工程交叉领域的研究者，他们需要一个统一的平台来验证新算法；其次是工程软件开发商和大型制造企业的数字化部门，他们可以基于此框架开发内部的AI辅助设计工具；甚至对于有编程基础的工程师个人，这也是一个绝佳的学习和实验平台，能亲手搭建属于自己的“AI设计助手”。

2. 框架核心设计：多智能体如何协同“造物”

EngiAI框架的核心思想，是模拟一个高效的工程设计团队。在这个团队里，没有全知全能的超人，而是由各司其职的专家组成，通过清晰的流程和沟通机制来合作。下面我们来拆解这个“虚拟设计团队”是如何组建和运作的。

2.1 智能体角色定义与专业化分工

框架中的每个智能体（Agent）都不是通用的聊天机器人，而是被赋予了特定角色和能力的“专家”。这种专业化分工是高效协作的基础。通常，一个完整的设计流程会包含以下几类核心智能体：

1. 需求解析与规格制定智能体：这是团队的“产品经理”。它的任务是理解用户用自然语言（甚至是不完整、模糊的语言）提出的需求，并将其转化为结构化、可量化、无歧义的设计规格书（Specification）。例如，用户说“帮我设计一个放在阳台上的花架，要结实、好看、省钱”。这个智能体需要解析出：应用场景（户外阳台，可能有风雨）、载荷要求（花盆总重量、风载）、材料约束（耐腐蚀，如不锈钢或防腐木）、成本预算、美学倾向（现代简约还是复古田园），并输出一份包含具体参数（如最大承重10kg，材料成本<200元，尺寸范围）的规格文档。它需要强大的上下文理解、信息抽取和逻辑归纳能力。

2. 概念设计与方案生成智能体：这是团队的“架构师”。基于规格书，它负责提出初步的设计概念或拓扑结构。在机械领域，它可能生成草图描述或关键特征参数；在电路领域，它可能给出电路框图或核心器件选型建议。这个智能体需要拥有丰富的领域知识库和创造性思维，能够生成多个可行的备选方案供下游评估。它常常利用LLM的思维链（Chain-of-Thought）或思维树（Tree-of-Thought）技术来探索不同的设计路径。

3. 详细建模与实现智能体：这是团队的“详细设计师”或“制图员”。它将选定的概念方案转化为精确的、可制造的数字化模型。对于机械设计，它需要生成参数化的CAD脚本（例如使用Python调用OpenCASCADE或FreeCAD API）；对于电路设计，它需要生成SPICE网表或PCB布局草图。这个智能体需要将自然语言或高级描述“编译”成精确的工程语言（代码、坐标、尺寸），对精度要求极高，容不得半点模糊。

4. 仿真分析与验证智能体：这是团队的“测试工程师”。它负责对生成的详细模型进行虚拟测试，评估其是否满足性能规格。例如，对机械结构进行有限元分析（FEA）计算应力应变；对电路进行瞬态或频域仿真。这个智能体通常不直接包含庞大的仿真求解器，而是作为“调度员”，编写调用外部仿真软件（如ANSYS, COMSOL, LTspice）的脚本，并解析仿真结果报告。它需要理解仿真输入输出的语义，并能判断“通过”或“失败”。

5. 优化与迭代智能体：这是团队的“优化专家”。当仿真结果不满足要求时，它负责分析问题所在，并提出修改建议，驱动设计迭代。它可能采用基于规则的调整（“壁厚不足，建议增加2mm”），也可能集成更复杂的优化算法（如遗传算法、贝叶斯优化），形成“分析-优化”闭环。这个智能体需要具备因果推理和决策能力，知道改哪里、怎么改最有效。

注意：在实际部署中，一个物理上的LLM实例可以扮演多个逻辑智能体角色，通过不同的系统提示词（System Prompt）来切换“人格”和知识背景。关键在于，框架为每种角色定义了清晰的输入输出接口和职责边界，就像公司里的岗位说明书。

2.2 智能体间通信与工作流引擎

智能体各就各位后，如何让它们有序协作，而不是乱成一锅粥？这就需要一套可靠的通信机制和工作流引擎。

通信机制：智能体之间不直接“对话”，而是通过一个共享的、结构化的“设计上下文”或“黑板”来交换信息。这个上下文通常是一个不断演化的JSON或YAML文档，记录了当前设计状态的所有信息，例如：

{ “project_id”: “demo_001”, “specification”: { “objective”: “设计轻质承重支架”， “constraints”: {“max_weight”: “5kg”, “max_cost”: “150”, “material”: “铝合金”}, “performance_metrics”: [“static_strength”, “weight”] }, “current_stage”: “detailed_modeling”, “concept_options”: [“option_a_desc”, “option_b_desc”], “selected_concept”: “option_a”, “detailed_model”: “step_file_content_or_script”, “simulation_results”: {“max_stress”: “205 MPa”, “weight”: “0.8kg”}, “validation_status”: “FAILED - stress exceeds yield strength”, “optimization_suggestions”: [“increase cross-sectional area”, “add rib”] }

每个智能体在完成任务后，将产出写入这个上下文，并触发状态变更。下游智能体被唤醒，读取上游输出作为自己的输入。这种方式保证了信息传递的标准化和可追溯性。

工作流引擎：它负责协调整个设计流程的执行顺序。EngiAI框架需要定义一个工作流描述语言（可以是简单的YAML配置，也可以集成像Apache Airflow这样的成熟工具），来刻画设计流程的DAG（有向无环图）。例如：

workflow: name: mechanical_design_workflow steps: - id: parse_spec agent: spec_agent next: generate_concepts - id: generate_concepts agent: concept_agent next: select_concept branch: true # 可能生成多个分支 - id: select_concept agent: human_in_loop # 或一个评估agent next: detailed_modeling - id: detailed_modeling agent: modeling_agent next: simulation - id: simulation agent: simulation_agent next: check_simulation - id: check_simulation agent: evaluator_agent next: - if: “validation_passed” goto: finalize - if: “validation_failed” goto: optimize - id: optimize agent: optimization_agent next: detailed_modeling # 跳回建模，形成循环 - id: finalize agent: report_agent

引擎根据这个定义，依次或并行地执行各个步骤，管理依赖和循环。当出现“仿真失败”时，引擎能自动将流程导向“优化”步骤，然后重新进行“建模”和“仿真”，形成一个自动迭代优化环。

2.3 框架的扩展性与工具集成

一个框架能否有生命力，看它是否易于扩展和集成。EngiAI在设计上必须考虑这两点。

智能体扩展：框架应该提供清晰的接口，让开发者能够轻松地注册新的智能体。例如，如果你想增加一个“成本估算Agent”，你只需要实现一个符合框架输入输出规范的类或函数，并将其注册到智能体池中。框架应提供标准化的基类（BaseAgent），定义如process_input(context)和get_output()这样的方法，让开发者聚焦于智能体内部的逻辑。

工具集成（Tool Integration）：这是工程落地的关键。智能体，尤其是建模和仿真Agent，不可能自己从头实现一个CAD内核或有限元求解器。它们必须能调用外部工具。框架需要提供一套“工具调用”机制。这通常通过以下方式实现：

• 封装为API：将常用工程软件（如FreeCAD, OpenFOAM）的功能封装成RESTful API或Python库，供智能体调用。
• 利用LLM的Function Calling能力：将外部工具描述成“函数”，让LLM智能体在需要时自主决定调用哪个函数，并生成正确的调用参数。例如，仿真Agent可以调用一个名为run_static_stress_analysis(model_file, material_properties)的函数。
• 子进程调用：对于命令行工具，智能体可以生成相应的命令脚本并执行。

框架需要管理这些工具的连接、认证和执行环境，确保智能体能安全、可靠地使用它们。同时，工具的描述（名称、功能、输入参数格式、输出格式）需要以一种LLM能理解的方式（如JSON Schema）注册到框架中，以便智能体在规划任务时知道有哪些“武器”可用。

3. 基准测试套件：如何科学评价AI的设计能力

如果说多智能体框架是“发动机”，那么基准测试套件就是“测功机”。没有客观、全面、可复现的评估，任何关于AI设计能力的宣称都是空中楼阁。EngiAI的Benchmark Suite正是为了解决这个评估难题而生的，它的设计本身就是一个值得深究的工程。

3.1 基准任务的构建与分类

一套好的基准，首先要有一组有代表性的任务。这些任务不能太简单（否则无法区分模型能力），也不能过于复杂和不切实际（否则难以普及和复现）。EngiAI的基准任务库很可能从以下几个维度进行构建：

1. 按工程领域分类：

   • 机械/结构设计：例如，给定载荷和空间约束，设计一个梁、支架、连杆机构或简单的齿轮箱。
   • 电子电路设计：例如，给定滤波要求，设计一个RC或运放滤波器电路；给定逻辑功能，设计一个数字电路。
   • 热力学/流体系统设计：例如，设计一个简单的散热片或管道布局。
   • 建筑设计：例如，在给定地块和功能需求下，进行简单的空间布局规划。

2. 按任务复杂度与抽象层级分类：

   • L1: 概念生成与选择：仅要求生成符合文本描述的设计概念或方案草图，不要求精确尺寸。评估重点是创造性和合理性。
   • L2: 参数化详细设计：在给定概念或拓扑结构下，要求确定具体尺寸、材料等参数，生成可制造的模型。评估重点是精度和可制造性。
   • L3: 分析与优化闭环：要求完成从需求到通过仿真验证的完整设计闭环，并能根据仿真结果进行自动优化。评估重点是流程的自动化程度和最终性能。

3. 按输入形式分类：

   • 纯文本描述：最灵活，也最具挑战性，考验LLM的需求理解能力。
   • 文本+草图/图片：结合多模态输入，更贴近实际工程沟通场景。
   • 结构化参数表格：需求已被初步结构化，降低了解析难度，专注于后续设计逻辑。

每个基准任务都是一个完整的“问题包”，至少包含：

• 问题描述（Problem Statement）：用自然语言清晰定义设计目标、约束条件和成功标准。
• 地面真实数据（Ground Truth，可选）：一个或多个已知的、可行（甚至最优）的设计方案，用于结果比对。对于创新性任务，可能没有唯一解。
• 评估脚本（Evaluation Script）：自动化的评估程序，能够对AI提交的设计方案进行量化打分。

3.2 多维度的评估指标体系

评估AI的设计成果，不能只看“做没做出来”，更要看“做得多好”。一个全面的评估体系应该涵盖多个维度：

实操心得：在设计评估脚本时，仿真的自动化集成是一大挑战。你需要确保仿真环境（如FEA网格划分、边界条件设置）对于不同的AI生成模型是稳定和一致的，否则性能对比就失去了意义。一种可行的方法是，将评估脚本也“容器化”，与基准任务打包在一起，确保在任何机器上运行都能得到可复现的结果。另外，对于“创新性”这种主观指标，初期可以结合简单的多样性计算（如方案之间的差异度）和专家打分来进行。

3.3 基准套件的使用模式与意义

这个Benchmark Suite怎么用？它主要服务于三种场景：

1. 模型能力评测与排行榜：研究人员或开发者可以将自己的多智能体系统（或单个设计Agent）在整套基准任务上跑一遍，生成一份综合成绩单。框架可以自动汇总各项指标，形成排行榜。这能直观地回答“当前LLM驱动的工程设计达到了什么水平？”以及“我的方法在同行中处于什么位置？”。

2. 消融研究与组件测试：你可以用基准任务来测试框架中某个特定组件的改进效果。例如，你优化了“需求解析Agent”的提示词，那么可以固定其他智能体，只替换该Agent，看在同一组任务上，需求转化的准确率是否提升，以及最终设计成功率是否随之提高。这为框架本身的迭代优化提供了科学依据。

3. 新人上手与案例学习：对于刚接触LLM和工程设计的研究生或工程师，这套基准任务就是一套绝佳的“练习题”和“案例库”。通过尝试复现或改进基准任务上的结果，可以快速理解多智能体设计框架的工作原理和挑战所在。

它的核心意义在于建立标准。在AI for Science（AI4S）和AI for Engineering（AI4E）领域，缺乏标准化的评估一直是阻碍研究可比性和工程落地的一大障碍。EngiAI的Benchmark Suite如果设计得当、社区认可度高，完全有可能成为该领域的一个事实标准，像计算机视觉领域的ImageNet一样，推动整个领域快速发展。

4. 关键技术实现与核心环节剖析

了解了框架设计和评估体系，我们深入到“引擎盖”下面，看看让这一切运转起来需要哪些关键技术，以及在实现时会遇到哪些核心挑战和解决方案。

4.1 智能体的核心实现：提示工程与规划能力

每个智能体的“大脑”都是一个LLM（或经过微调的LLM）。如何让这个“大脑”胜任专业工作？关键在于系统提示词（System Prompt）和规划（Planning）能力。

系统提示词的精雕细琢：这是定义智能体“角色”和“专业知识”的剧本。一个优秀的提示词需要包含：

• 角色与职责声明：明确告诉LLM“你是谁”。例如，“你是一个经验丰富的机械设计工程师，擅长将模糊的需求转化为精确的设计规格。”
• 工作流程与输出格式指令：明确告诉LLM“你该怎么工作”和“产出什么”。例如，“请按以下步骤分析用户需求：1. 识别核心功能... 2. 提取关键参数... 3. 澄清模糊点... 最后，请将输出严格整理为如下JSON格式...”
• 领域知识注入：通过少量示例（Few-shot Learning）或在提示词中嵌入关键知识片段（如材料属性表、设计规范摘要），让LLM具备必要的背景知识。
• 约束与边界：明确限制LLM的行动范围，防止其“胡思乱想”或执行危险操作。例如，“你只负责提出概念，不得生成具体的CAD代码。”“所有尺寸单位必须使用毫米。”

规划与推理能力：对于概念生成、优化等需要多步思考的任务，智能体不能只做一次响应。它需要具备规划能力，将大任务分解为子任务，并逐步推理。常用的技术包括：

• 思维链（CoT）：引导LLM“一步一步思考”，将其推理过程用文字展示出来，这通常能提高复杂任务的准确性。
• 思维树（ToT）：对于存在多个可能路径的任务（如概念设计），让LLM同时探索多个推理分支，并对每个分支进行评估和剪枝，最终选择最优路径。
• ReAct模式：将推理（Reasoning）和行动（Action）结合起来。智能体先推理当前情况（“仿真显示应力过大”），然后决定采取什么行动（“调用‘增加壁厚’工具”），执行行动后观察结果，再进行下一步推理。这种模式非常适合与外部工具交互的闭环任务。

4.2 工作流与状态管理：确保设计流程的鲁棒性

多智能体协作就像一场接力赛，接力棒（设计状态）传递不能出错。工作流引擎和状态管理是保障鲁棒性的关键。

状态管理的挑战：设计上下文（Context）在流程中不断演变，可能变得非常庞大和复杂。如何高效地存储、检索和更新这个上下文？简单的单一JSON文件在多次迭代后可能难以维护。解决方案可以是：

• 版本化存储：每次智能体修改上下文后，都创建一个新版本，并记录修改者和修改内容。这便于回溯和调试。
• 结构化数据库：将上下文拆分成不同的表或文档存储，例如需求表、概念表、模型表、仿真结果表，通过项目ID关联。这提高了查询和管理效率。
• 向量化检索：当上下文很长时，后来的智能体可能需要快速找到相关信息。可以将上下文的关键部分（如最新的仿真结论、未解决的约束）生成向量嵌入，供智能体通过语义检索快速定位所需信息。

错误处理与回退机制：在实际运行中，什么都有可能出错：某个智能体生成的内容格式不对、调用外部工具超时、仿真不收敛……框架必须能优雅地处理这些异常。

• 智能体输出验证：在每个智能体输出被写入共享上下文前，应有一个验证环节。这可以是一个简单的格式检查（JSON Schema验证），也可以是一个轻量级的规则检查或另一个LLM调用（用于检查逻辑合理性）。验证失败则触发重试或人工干预。
• 超时与重试：对于调用外部API或运行仿真等可能耗时的操作，必须设置超时。超时后，可以尝试重试、更换参数，或者将任务标记为失败，由工作流引擎决定下一步（如切换到备选方案或请求人工帮助）。
• 检查点（Checkpoint）：在关键步骤完成后（如完成概念选择、完成一次仿真），保存整个设计状态的快照。如果后续步骤失败，可以从最近的检查点恢复，避免从头开始，节省大量计算成本。

4.3 外部工具的安全与高效集成

智能体需要通过工具来影响现实世界（生成模型、运行仿真），工具集成的安全性和效率至关重要。

安全性是首要考虑：

• 沙箱环境：任何由智能体生成并准备执行的代码（如Python建模脚本、Shell命令），都必须在严格的沙箱环境中运行。这个环境应该限制网络访问、文件系统访问（只允许读写特定临时目录）和系统调用，防止恶意或错误的代码对主机系统造成破坏。
• 工具权限控制：不是所有智能体都能调用所有工具。框架需要实现基于角色的访问控制（RBAC）。例如，“概念生成Agent”可能只有读取权限和调用“草图生成库”的权限，而“详细建模Agent”则拥有调用CAD内核API的写权限。
• 输入过滤与清理：对智能体传递给工具的参数进行严格的验证和过滤，防止注入攻击。例如，如果工具接受文件路径参数，必须确保路径被限制在安全目录内。

效率优化策略：

• 工具调用缓存：对于确定性操作（如用同一组参数计算某个公式），可以将结果缓存起来。当其他智能体请求相同计算时，直接返回缓存结果，避免重复调用，显著减少耗时和成本。
• 异步与并行调用：如果工作流中有多个独立的任务（如同时评估多个概念方案的性能），工作流引擎应能调度这些任务并行执行，充分利用计算资源。
• 工具抽象层：为不同的外部工具（如不同的CAD软件、不同的仿真器）提供统一的接口抽象。这样，智能体只需要调用run_simulation(design, type='static_stress')，而无需关心底层用的是ANSYS还是Abaqus。这大大降低了智能体提示词的复杂度和框架的耦合性。

5. 实践挑战、常见问题与未来展望

将EngiAI这样的框架从论文或开源项目应用到实际工程中，必然会遇到一系列挑战。这里结合常见的实践问题，分享一些排查思路和个人体会。

5.1 典型实践挑战与应对策略

1. 挑战：LLM的“幻觉”与不确定性

   • 问题描述：智能体可能生成看似合理但实际违反物理定律或设计规范的内容，例如提出一种不存在的材料属性，或者设计出无法装配的结构。
   • 排查与解决：
     • 加强验证环节：在关键步骤（如概念输出、详细参数输出）后，增加一个由“规则引擎”或“验证专用小模型”进行的检查。这个检查器不负责创造，只负责根据已知规则（如材料库、几何约束）进行逻辑判断。
     • 采用“保守”策略：在提示词中强调“如果你不确定，请输出‘需要更多信息’或给出一个保守的、经验证过的方案范围，而不是一个精确值”。
     • 人类在环（Human-in-the-Loop）：在关键决策点（如概念选择、仿真失败后的优化方向）设置检查点，由人类工程师进行确认或微调。这并非失败，而是人机协同的必然模式。

2. 挑战：上下文长度限制与信息丢失

   • 问题描述：复杂工程的设计上下文可能非常长（包含多个方案、多次迭代的仿真数据），很容易超出LLM的上下文窗口，导致智能体“忘记”早期的重要信息。
   • 排查与解决：
     • 上下文摘要与压缩：开发一个“上下文管理Agent”，它的职责是定期对当前设计状态进行摘要，提炼出最关键的信息（如当前核心问题、已尝试的方案、剩余约束），将冗长的原始数据替换为精炼的摘要，再提供给后续智能体。
     • 分层级上下文：并非所有信息都需要在每一步传递给所有智能体。可以为不同智能体提供不同粒度的上下文视图。例如，优化Agent可能需要详细的仿真数据，而报告生成Agent只需要最终方案和性能总结。
     • 利用长上下文模型：随着技术的进步，选择支持更长上下文（如128K、1M tokens）的LLM作为基础，从根本上缓解此问题。

3. 挑战：评估指标的矛盾与权衡

   • 问题描述：设计目标往往是多目标的，且相互矛盾。例如“轻量化”和“高强度”，“低成本”和“高可靠性”。AI如何在这些目标间进行权衡？
   • 排查与解决：
     • 引入多目标优化：在优化Agent中集成多目标优化算法（如NSGA-II），让其能够生成一组“帕累托最优”解集，即在这些解中，无法在不损害一个目标的情况下改进另一个目标。然后将这个解集呈现给人类决策者进行最终选择。
     • 需求解析阶段明确优先级：在需求解析阶段，就引导用户或由智能体主动询问：“在重量、成本、强度这三个指标中，请按重要性排序。” 将模糊的“又好又便宜”转化为具体的权重系数，指导后续优化。

5.2 常见问题速查与调试技巧

在实际搭建和运行多智能体设计系统时，你可能会遇到下面这些典型问题：

5.3 个人体会与未来方向

从我尝试构建类似系统的经验来看，EngiAI所代表的路径无疑是正确的，但这条路走通并不容易。最大的感触是，成功的LLM工程应用，是“三分模型，七分工程”。选择一个强大的基础LLM（如GPT-4、Claude 3）只是起点，更多的工作在于如何用扎实的软件工程和领域知识，为这个“大脑”构建一个可靠的“身体”（框架、工具）和“训练手册”（提示词、工作流）。

目前，这类系统最适合的场景是“概念设计辅助”和“参数化优化”。在这些场景中，AI能够快速生成大量人类可能想不到的创意方案，或者在海量参数空间中高效搜索最优解，将工程师从繁琐的试错中解放出来，专注于更高层次的决策和评审。

对于未来，我认为有几个方向值得关注：

• 多模态深度集成：未来的设计输入不仅是文本，可能是一张草图、一段描述性语音、甚至一个手势。输出也不仅是代码和参数，而是直接的可视化3D模型、渲染图或动画。框架需要更好地理解和生成多模态内容。
• 仿真与AI的紧耦合：不再仅仅是“AI生成模型 -> 丢给仿真软件 -> 读结果”的松散耦合，而是仿真过程本身能被AI实时理解和干预，形成更高效的“共舞”式优化。
• 从自动化到自主化：当前的系统大多仍需较多的人工设定和干预。未来的方向是提高系统的自主性，使其能理解更宏观、更模糊的任务（如“设计一款下一代电动汽车的底盘”），并自主分解任务、寻找工具、学习领域知识，最终与人类工程师成为真正的协作伙伴。

EngiAI框架和基准测试套件，为这个激动人心的未来搭建了一个非常重要的实验场和竞技台。无论你是研究者、开发者还是工程师，现在投身其中，正当时。