MAS4SysML：一种用于从自然语言生成 SysML v2 模型的多智能体框架

摘要

本方案介绍了MAS4SysML，这是一种多智能体方法，通过协调的任务划分自动生成SysML v2代码，仅需少量修复迭代，显著减少了手动建模时间，同时提高了系统建模效率。

摘要

从自然语言需求中自动生成准确的 SysML 模型，可显著加速基于模型的系统工程（MBSE）在复杂系统开发中的应用。然而，使用大语言模型（LLMs）生成模型代码时，往往难以满足形式化建模语言严格的语法约束，且持续确保生成模型与需求之间的语义一致性仍具挑战性。为应对这些挑战，本文提出 MAS4SysML，一种面向 SysML v2 代码生成的多智能体协同框架，可在有限的修复预算下提升语法正确性与语义一致性。该框架将建模任务分解为分层子任务，将其形式化为结构化任务卡片，并采用自底向上的方式生成模型代码。在生成过程中，使用官方验证环境进行语法诊断；代码生成完成后，框架进一步验证代码与任务卡片之间的语义一致性。若语法或语义验证失败，框架将在预定义的修复预算内，依据诊断反馈迭代地修复并重新验证代码，直至满足验证标准或预算耗尽。为评估所提方法，我们构建了一个涵盖五类核心任务类型（需求、用例、结构、参数分析和状态机）的 SysML v2 数据集，并开展了对比实验。结果表明，MAS4SysML 将平均语法错误率降低至 2.63，语义相似度提升至 0.91，在整体性能上优于现有的代码生成方法。

引言

基于模型的系统工程（MBSE）已成为航空与航天等领域复杂装备研制过程中需求分析、系统架构设计及验证规划的关键方法论¹。通过采用统一建模语言（如SysML）作为建模核心，可将需求、结构、行为和约束等信息整合为统一的模型框架，从而提升流程的结构性以及跨学科协作的效率²。然而，随着系统规模持续扩大，所需构建的模型数量相应增加，导致人工进行SysML建模的工作量持续上升。此外，建模人员必须在严格的语法和方法学约束下开展工作，这对专业知识和抽象能力提出了较高要求。上述因素已成为MBSE在工程实践中推广应用的主要瓶颈³。

近年来，大语言模型（LLMs）在自然语言理解、结构化信息表示和代码生成方面展现出强大的能力，为实现从自然语言到模型代码的基于模型的系统工程（MBSE）建模自动化提供了新的机遇⁴。先前的研究已探索了使用大语言模型直接生成SysML模型代码的方法⁵。然而，仍存在重大挑战。在语法层面，SysML的类型系统、作用域机制和引用语义受严格的形式化约束控制，其复杂性通常超过通用编程语言⁶。在语义层面，大语言模型可能无法充分捕捉行为逻辑、结构关系以及跨层约束，导致关系缺失、逻辑不一致或模型不完整⁷。这些局限性制约了直接生成方法的可靠性、可控性和可解释性。

为应对这些挑战，本文提出了 MAS4SysML，这是一个包含四个智能体角色的 SysML v2 代码生成框架。本研究并未直接追求一次性生成完整的跨视图系统模型，而是专注于生成并迭代修复多个具有代表性的 SysML v2 建模任务。MAS4SysML 以任务分解和结构化任务卡片为驱动，融合代码生成、工具级语法诊断与语义一致性验证，建立了一个生成、验证与修复的闭环工作流程。该设计在有限的修复预算下，提升了生成代码的语法正确性、语义一致性以及结构完整性。

主要贡献总结如下：（1）MAS4SysML 框架。我们提出了 MAS4SysML，一种多智能体、大语言模型驱动的框架，能够实现从自然语言需求到可执行的 SysML v2 模型代码的端到端生成，为降低建模成本、提升建模效率提供了切实可行的路径。（2）任务解析与双重验证。我们引入了任务结构树解析机制和双重验证方案（语法与语义验证）。在任务解析阶段，建模目标被逐层分解并形式化为结构化的任务卡片；在验证阶段，语法诊断利用官方验证环境⁸检查生成的代码，并返回面向修复的诊断信息，而语义验证则以任务卡片中的关键字段为参考，评估生成模型与建模目标之间的一致性。（3）实验评估。我们以语法错误率和语义一致性得分作为主要指标进行了对比实验。结果表明，MAS4SysML 将平均语法错误率降低至 2.63，语义相似度提升至 0.91，在生成准确性和自动化水平方面优于基线方法。

方案

MAS4SysML 框架的代码生成过程总结于补充文件 1中。需要注意的是，本研究并不旨在通过自然语言一次性生成包含需求、结构、参数和行为且具有严格跨视图一致性的完整系统模型。相反，该方案侧重于生成 SysML v2 多种典型视图的代码。

第一阶段：任务分析
工作流程从任务解析开始。系统将自然语言描述的建模意图提供给任务结构生成代理，该代理输出一组任务卡片。为确保后续生成过程具有可执行性和可重复性，每张任务卡片至少必须包含以下内容：(i) 任务标识符，(ii) 依赖关系，以及 (iii) 用于验证的关键建模信息，例如建模目标、约束条件/边界条件、参数占位符及其实例化取值，以及预期输出结果。此阶段的输出为task_card_set，作为后续模型代码生成的统一基础。

第二阶段：迭代式代码生成
在迭代生成过程中，系统将代码上下文 prev_code 初始化为空状态，并根据依赖字段确定的顺序依次为每个任务卡片生成代码。对于每个任务卡片，代码生成代理以当前任务卡片和上下文代码作为输入，生成 candidate_code，然后立即调用语法验证模块进行检查。该模块使用官方 SysML v2 验证环境对代码进行验证，并返回诊断结果。若验证通过，则使用 candidate_code 更新 prev_code，并支持后续代码生成。若验证失败，则触发代码修复代理，根据返回的诊断信息执行最小化、有针对性的修改，随后将 repaired code 重新提交以进行再次验证。此修复与再验证循环受最大修复预算 K_max 的限制。若在预算范围内验证成功，则通过的版本将用于更新 prev_code；否则，在经历 K_max 次尝试后，系统记录失败信息，并继续使用最后一次修复的版本作为 prev_code 进行后续任务卡片的生成，以避免阻塞工作流程，同时保持上下文的连续性。

第三阶段：语义验证
在为所有任务卡片生成代码后，工作流程进入语义验证阶段。语义验证代理使用 task_card_set 中的关键字段作为参考，评估最终代码与建模意图之间的一致性，并输出语义验证结果。若验证通过，则将 prev_code 接受为最终的 SysML v2 模型代码；否则，系统将生成一份语义偏差报告，指出未满足的任务卡片字段及所需的修改范围。随后，代码修复代理根据该报告对代码进行相应修订，并将修订后的模型代码输出为最终结果。

模型架构与方法
模型架构
如图1所示，MAS4SysML 框架包含四个协作型智能体：任务结构生成智能体、代码生成智能体、代码修复智能体以及语义验证智能体。相应的提示模板见图2。

任务结构生成代理对输入的建模意图进行语义分析，并生成可执行的结构化任务卡片。它首先应用分层任务分解机制（参见分层任务分解机制），将整体建模目标分解为具有明确定义语义边界的任务节点，然后为每个节点构建结构化任务卡片。随后，任务卡片根据其建模依赖字段进行排序，以确保执行顺序与最终代码结构保持一致，从而为由全局建模目标驱动的自底向上代码生成奠定基础。

代码生成代理根据建模依赖关系逐步生成符合 SysML v2 规范的模型代码。该代理基于父级任务生成的代码产物，依据每个任务卡片中指定的要求执行相应的代码生成操作，从而实现从局部组件到完整模型的逐步构建过程。

代码修复代理根据语法验证模块（参见语法验证模块）和语义验证结果的输出，修正生成代码中的错误。在语法修复方面，它利用语法验证器返回的错误类型、位置及上下文信息，生成针对性的修复策略并产生修正后的代码。在语义修复方面，它根据语义验证结果调整结构和逻辑关系，确保最终模型的语义一致性和结构完整性。

语义验证代理通过专用的语义验证机制（参见语义验证机制）评估完全生成的代码与任务卡片之间的语义一致性。通过定量评估，确保生成的代码准确反映原始建模意图，从而实现模型代码与指定建模要求之间的精确对齐。

分层任务分解机制
作为复杂系统的正式建模语言，SysML v2 具有紧密耦合的语法、深度嵌套的层次化结构以及跨层级的语义约束。例如，一个系统结构模块可能包含多个子部件、属性和端口，同时通过跨层约束表达性能或行为需求。这些结构和约束形成了自上而下的结构依赖关系以及自下而上的语义反馈关系。采用扁平化、一次性生成的方法，难以准确映射此类层次化依赖关系，常常导致关系缺失、语义不一致或约束信息丢失。

为应对这一挑战，我们开发了一种基于任务树的建模意图解析方法，该方法可对自然语言描述的建模需求进行层次化分解。如图3所示，复杂的建模目标被分解为结构化且可追溯的任务节点，使系统能够以自上而下的方式解析建模语义，并识别其中的依赖关系。具体而言，当任务结构生成代理接收到用户输入后，首先利用大语言模型（LLM）的语义解析能力，识别核心建模目标、关键实体及其相互依赖关系；随后，将顶层目标递归地分解为语义上独立的子任务，并进一步细化为可直接映射到 SysML v2 建模操作的原子任务，最终形成完整的任务结构树。任务树构建完成后，代理将根据预定义模板为每个任务节点生成结构化的任务卡片。任务卡片的格式定义如下：

TC = {id,O,N,K,P,V,C,D} (1)

其中，id 表示任务节点的唯一标识符，O 表示任务目标，N 表示任务的自然语言描述，K 表示任务中可能涉及的核心 SysML v2 语义元素，主要包括需求定义/需求（requirement def/requirement）、部件定义/部件（part def/part）、端口定义/端口（port def/port）、项目定义（item def）、属性定义/属性（attribute def/attribute）以及状态/状态转移（state/transition）。这些元素之间的关系主要通过连接关系（connect，表示结构连接）、端口上的输入/输出项目（input/output items on ports，表示信息流或物质流）以及状态机转移中的触发/守卫条件（trigger/guard conditions，例如命令、健康状态和阈值约束）来表达。C 表示语义规则或边界条件，P 表示任务中可参数化的插槽，例如属性名称、数据类型或复合类型，V 表示每个插槽的实例化值，D 表示任务之间的建模依赖关系，其中 depend_on 指定在生成当前任务代码前需依赖的其他任务的输出，provides 表示任务完成后产生的输出，consumes 表示任务所需的外部输入。

语法验证模块
基于 SysML v2 试点实现构建了一个语法验证模块。通过调用其解析器和验证器接口，该模块对生成的 SysML v2 模型代码进行解析，并验证其语法正确性。该模块的验证准则主要来源于 SysML v2 语言规范，以及试点工具中实现的语法规则、作用域解析规则和相关约束检查机制。具体而言，验证内容包括：元素声明是否结构良好，块结构是否完整，类型注解是否有效，名称和引用是否能够成功解析，以及端口、连接、状态和转换等建模结构是否符合语言要求。

在代码生成代理为当前任务生成代码片段后，输出将被转发至语法验证模块，验证脚本在此分析代码，并以结构化的诊断信息形式返回结果。验证结果报告如下：

e₁ = (类型_i, 位置_i, 消息_i) (2)

其中 e_i 表示当前建模任务中检测到的问题列表，每个条目包含错误类型 type_i、错误位置 pos_i 和诊断信息 msg_i。

例如，如果生成的代码包含语法错误（例如“属性未通过属性定义进行类型声明”），验证模块将返回以下诊断信息：

'type' : 'error'
'message' : '错误：属性必须根据属性定义进行类型声明。' (3)
'position' : '第 7 行，第 3 列'

当验证结果 e_i ≠ 0 时，收集到的错误信息 e_i 将被转发给代码修复代理以进行进一步修正。因此，代码修复过程并非无约束的修改过程，而是在解析器和验证器返回的明确诊断信息指导下进行的针对性修订。

语义验证机制
该语义验证机制利用任务卡中具有明确且可追溯的模型代码对应关系的关键字段作为语义锚点。它在模型层面评估语义一致性，从而为后续的模型修复提供明确且可操作的判断标准。具体而言，针对每个任务卡 TC_i，以下字段被用作关键语义参考：(i) 建模目标 O_i，(ii) 语义约束与边界条件 C_i，(iii) 实例化的参数槽值 V_i，以及 (iv) 任务完成后预期的输出 D_i['provide']。这些字段从多个角度对生成的模型施加互补的语义约束：建模意图的实现、约束条件的满足、参数实例化的一致性以及模型输出的完整性——从而能够在无需额外假设的前提下，系统性地判断模型代码是否满足建模需求。

基于这些关键字段，我们定义一个多字段语义一致性决策函数：

(4)

其中，I(·) 表示一个指示函数，当括号内的所有子决策函数均成立时，其值为 1，否则为 0。该二元决策明确区分了满足建模要求与需要进一步修复的两种状态，为后续的语义修复过程提供了确定性的触发条件。总体决策由以下四个子决策函数共同决定：

（1）建模目标一致性：

Φ₀ (TC_i,c_f) = I(consist(c_f,0_i)) (5)

其中 Consist(c_f,0_i) 表示模型代码 c_f 是否在语义上与任务卡中指定的建模目标 0_i 一致。

（2）语义约束满足：

Φ_c (TC_i,c_f) = I(满足(c_f,C_i)) (6)

其中 Satisfy(c_f,C_i) 表示模型代码 c_f 是否满足任务卡中指定的语义约束和边界条件 C_i。

（3）参数一致性：

Φ_c（TC_i，c_f）= I(Instant(c_f，V_i)) （7）

其中 Instant(c_f,V_i) 表示任务卡中的实例化参数值 V_i 是否在模型代码中得到一致反映。

（4）输出一致性：

 (8)

其中 Artifacts(c_j) 表示任务卡片所期望的输出是否存在于最终的模型代码中，用以衡量生成结果的完整性。

这些一致性判断由语义验证代理利用大语言模型（LLM）的语义理解能力来实现；该代理的内部推理过程不会改变一致性函数的形式定义或使用方式。

通过这种多字段语义一致性检查，可以逐字段验证生成的模型，确保每个建模目标、约束条件、参数配置以及预期输出均得到充分满足。该过程不仅为后续的语义修复提供了明确的触发机制，还为整个生成流程提供了可追溯的语义依据，从而提高了生成模型的可靠性与一致性。

实验数据与评估
实验数据
SysML v2 模型代码并非普通软件代码；其生成的产物具有形式化建模的显著特征。不同视图通常涉及不同类别的核心建模元素，例如需求、部件、端口、属性、状态和转移，这些元素在声明方式、组织形式和构成结构上存在显著差异。此外，模型代码必须满足多种约束条件，包括类型引用、层次嵌套、连接约束以及元素间的语义复用。

为了在不同建模复杂度下全面评估所提出方法的性能，构建了一个涵盖五种代表性模型视图类型的代码数据集——需求、用例、结构、参数化和状态机。这些模型视图分别对应于系统建模中的需求规格说明、功能交互、结构组成、参数约束表示以及行为逻辑描述。通过对不同模型视图类型分别评估该框架，可以更细致地分析其在多样化代码结构特征和建模约束条件下的适用性。

每种模型视图类型包含15个手动创建的模型实例，从而构成一个包含N = 75个SysML v2模型的数据集。该数据集涵盖多个工程领域，包括航空航天、汽车、医疗和智能家居系统，所有模型均成功通过了官方SysML v2验证环境，确保了严格的语法合规性。

随后，我们为每个模型生成了相应的自然语言建模意图描述。为了提高构建效率，我们使用了补充文件2中所示的提示模板，并采用GPT-4o生成初始描述。选择GPT-4o是因为其强大的语义理解与信息提取能力，能够准确捕捉模型的核心要素而不会产生幻觉，并生成类似人类撰写的建模意图描述⁹。为确保准确性并消除歧义，所有生成的描述均由具备系统工程背景的研究人员进行人工审核与优化。不同模型类型的代表性示例如表1所示。

评估指标
我们采用以下三个关键指标来评估生成的 SysML v2 模型代码的质量：

平均句法错误率（SER）
该指标用于量化在将生成的模型代码根据官方 SysML v2 语法规则进行验证时所检测到的句法错误比例。其计算公式如下：

   (9)

其中 E_i 表示在第 i 个生成模型中识别出的语法错误数量。该指标反映了生成的模型代码符合 SysML v2 形式化语法规范的程度。

语义一致性评分（SCS）
该指标用于评估生成的模型代码在多大程度准确且全面地捕捉了自然语言建模说明中所表达的语义意图。具体而言，我们从建模意图中提取语义单元——例如系统实体、参与组件、核心功能或行为场景，以及关键条件或约束——并将这些单元与生成模型代码中存在的语义单元进行比较。语义一致性按以下方式计算：

    (10)

其中 U 表示从建模意图中提取的语义单元集合， 表示在生成的代码中识别出的语义单元集合。 表示生成的模型代码正确捕捉到的单元数量。SCS 值越高，表明语义覆盖度和对齐性越强。

人工质量评估
传统的自动化指标（如 BLEU 和 CodeBLEU）主要评估生成结果在表层上的相似性或代码的可执行性，但无法判断模型是否真正理解或正确表达了预期的建模语义。这些指标在评估语义一致性、关键要素的完整性以及与建模意图的契合度方面存在局限性¹⁰。相比之下，人工评估能够更准确地识别诸如语义元素缺失、逻辑不一致、结构冗余或缺乏支持的虚构内容等问题，从而提供更为可靠的评估结果¹¹。鉴于上述局限性，我们设计了一套针对生成的 SysML v2 模型的人工评估框架，包含以下三个评估标准：（1）正确性：生成的模型必须准确反映建模意图，与任务目标保持结构和逻辑上的一致性，且不含语义歧义、缺失元素或错误扩展；（2）可读性：模型代码应清晰易懂，命名一致，结构连贯，层次分明，便于审查和后续维护；（3）完整性：模型应具备完整的结构逻辑，元素间交叉引用一致，不存在未定义的类型或断裂的依赖链，以确保其可用于下游分析与集成。我们邀请了具有 SysML 建模经验的研究人员，对每个生成的模型按照三分制进行评分，其中 1 分表示质量最低，3 分表示质量最高。在评估过程中，评阅人被允许将生成的模型代码与真实模型进行对比，以确保评估结果更加准确和全面。

基线
我们选择了多个评估基线，用于与所提出的方法进行对比测试，包括：
CodeCoT¹²：结合思维链推理与自检机制，使模型在生成过程中能够显式推理并自我纠正语法错误，从而提高代码质量和语义一致性。

自主规划¹³：提出一种两阶段代码生成流程，其中模型首先规划解决方案的步骤，然后根据该计划生成代码，从而有效提升复杂任务的逻辑连贯性和可解释性。

Self-edit¹⁴：采用迭代生成与编辑的范式，通过执行生成的代码并基于运行时反馈自动纠正错误，持续优化输出结果。
CodeChain¹⁵：通过将复杂任务分解为独立的功能模块，采用模块化生成与迭代修订的方法，并经过多轮优化以提升结构合理性和整体质量。

自调试¹⁶：赋予模型自主调试和解释能力。通过生成、执行与调试的闭环过程，在无需人工干预的情况下显著提升复杂编程任务的正确率。

MapCoder¹⁷：构建了一个多阶段协作框架，包含检索、规划、编码和调试四个智能体，紧密模拟人类编程工作流程，实现从任务理解到结果验证的闭环生成。

自我协作¹⁸：将系统组织为一个具有分析师、程序员和测试员等角色的虚拟编程团队，通过基于角色的协作和迭代反馈，提升复杂代码生成的整体性能。

实验设置
为确保实验间的公平性和可比性，我们首先采用直接代码生成方法评估了多个主流大语言模型（LLM），以建立基线性能。根据这些初步结果，选择表现最优的LLM作为后续所有实验的统一骨干模型。随后，我们将所提出的MAS4SysML框架与多种具有代表性的代码生成方法进行了比较。所有LLM的交互均在固定的温度设置下进行（T = 0.2），以最小化生成过程中的随机性。对于每个建模任务，MAS4SysML中的最大修复迭代次数设置为K_max = 3。所有基线方法均在与MAS4SysML相同的实验配置下运行，以确保结果的一致性和实验的公平性。MAS4SysML方法的Python脚本作为补充文件3提供。

结果

基线模型评估
我们首先选取了多个主流的大语言模型（LLM），并采用直接模型到代码生成的方式进行了初步性能测试，包括 CodeX(175B)¹⁹、CodeGen-Mono(16.1B)²⁰、PaLM Coder(62B)²¹、Alphacode(1.1B)²²、Incoder(6.7B)²³ 和 code-davinci-002(175B)²⁴。如表2所示，code-davinci-002(175B)²⁴ 在 SER 和 SCS 两项指标上均表现出最佳性能。因此，本研究选择 code-davinci-002(175B) 作为基础大语言模型，用于评估各种代码生成策略。这些策略评估的结果汇总于表2的下半部...

讨论

我们提出MAS4SysML，一种用于半自动化生成SysML v2模型代码的多智能体协同框架。该框架由四个功能互补的智能体组成。在生成过程中，该框架（i）基于任务树结构对自然语言描述的建模需求进行层次化分解，并将其形式化为结构化的任务卡片；（ii）根据这些卡片中指定的约束条件和依赖关系，自底向上生成SysML v2模型代码。在整个生成过程中，基于官方SysML v2验证环境构建的语法验证模块会执行语法诊断，并返回面向修复的反馈信息。代码生成完成后，框架进一步检查生成结果与关键任务卡片字段之间的语义一致性，从而提升所生成代码的可执行性及其与预期需求的一致性。

MAS4SysML 提供了一种将自然语言建模意图转化为 SysML v2 模型代码的实用途径。它通过闭环验证流程，有助于降低复杂装备开发中人工建模的成本与学习门槛，并提升迭代效率。相较于基于模板或规则驱动的模型生成方法³⁵，MAS4SysML 避免了大规模人工维护模板的需求，在结构化任务卡片约束下，能够以较低的工程成本适应多样化的建模任务，同时通过验证反馈提升输出的稳定性与可执行性。...

材料

本文使用的材料清单

姓名	公司	目录编号	评论
LangChain	LangChain（开源项目）	v1.0.8；https://github.com/langchain-ai/langchain	用于大语言模型交互与智能体编排的框架
LangGraph	LangChain（开源项目）	v1.0.3；https://github.com/langchain-ai/langgraph	多智能体工作流执行框架
Python	Python 软件基金会	3.10.x；https://www.python.org/downloads/release/python-3100/	MAS4SysML 实现的主要编程语言
SysML v2 试点实现	对象管理组织（OMG）	（提供发布版本/标签版本）；https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation	用于语法验证和模型解析