MAS4SysML：一个用于自然语言生成SysML v2模型的多代理框架

Summary

该协议提出了MAS4SysML，这是一种多智能体方法，通过协调任务划分自动生成SysML v2代码，无需少量修复迭代，显著减少手工建模时间，同时提升系统建模效率。

Abstract

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

Introduction

MBSE已成为需求分析、系统架构设计和验证规划中，航空和^航空航天等领域复杂设备开发的关键方法论。利用SysML等统一建模语言作为建模骨干，信息——包括需求、结构、行为和约束——可以组织成连贯的模型框架，提升流程结构和跨学科协作效率².然而，随着系统规模的持续扩大，需要开发的模型数量相应增加，导致手动SysML建模的工作量持续增加。此外，建模师必须在严格的语法和方法论约束下工作，这需要丰富的专业知识和强大的抽象能力。这些因素已成为MBSE³工程采用的主要瓶颈。

近年来，LLM展现了在自然语言理解、结构化信息表示和代码生成方面的强大能力，为从自然语言向代码⁴自动化MBSE建模开辟了新机遇。此前的研究曾探索过利用^{LLMs 5}直接生成SysML模型代码的方法。然而，仍然存在重大挑战。在语法上，SysML 的类型系统、作用域机制和引用语义受严格的形式约束，通常比通用编程语言⁶ 更为复杂。从语义上讲，LLM可能无法完全捕捉行为逻辑、结构关系和跨层约束，导致缺少关系、逻辑不一致^或模型不完整。这些局限性阻碍了直接生成方法的可靠性、可控性和可解释性。

为应对这些挑战，本文介绍了MAS4SysML，一个包含四个代理角色的SysML v2代码生成框架。本研究并非直接针对一次性生成完整交叉视图系统模型，而是侧重生成并迭代修复多个代表性的SysML v2建模任务。MAS4SysML 由任务分解和结构化任务卡驱动，并集成代码生成、工具级语法诊断和语义一致性验证，建立了生成、验证和修复的闭环工作流程。该设计在有限的修复预算下提升了生成代码的语法正确性、语义一致性和结构完整性。

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

Protocol

MAS4SysML 框架的代码生成过程在 补充文件 1 中进行了总结。需要注意的是，本研究并不旨在实现从自然语言中一次性生成一个完整的系统模型，且严格符合交叉视图一致性，包括需求、结构、参数和行为。相反，该协议专注于生成几种代表性的 SysML v2 视图代码类型。

第一阶段：任务分析
工作流程从任务解析开始。该系统向任务结构生成代理提供自然语言建模意图，该代理输出任务卡集。为了确保后续世代的可执行和可重复，每张任务卡至少必须包含：（i） 任务标识符，（ii） 依赖关系，以及 （iii） 验证所需的关键建模信息，如建模目标、约束/边界条件、参数槽、实例化值以及预期输出。该阶段输出 task_card_set，作为后续模型代码生成的统一基础。

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

第三阶段：语义验证
在所有任务卡生成代码后，工作流程进入语义验证阶段。语义验证代理通过 task_card_set 中的关键字字段作为参考，评估最终代码与建模意图之间的一致性，并输出语义验证结果。如果验证成功， prev_code 作为最终的 SysML v2 模型代码被接受。否则，系统生成语义偏差报告，识别未满足的任务卡字段和所需的修订范围。代码修复代理随后相应地修订代码，并输出修订后的模型代码作为最终结果。

模型架构与方法论
模型架构
MAS4SysML 框架如 图1所示，包含四个协作代理：任务结构生成代理、代码生成代理、代码修复代理和语义验证代理。对应的提示模板如 图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 语义元素，主要包括需求定义/需求、部分定义/部分、端口定义/端口、项目定义、属性定义/属性和状态/转换。这些元素之间的关系主要通过连接（结构连接）、端口上的输入/输出项（信息/物料流）以及状态机转换的触发/守护条件（例如命令、健康状态和阈值约束）来表达，C 作为语义规则或边界条件，P 作为任务中可参数化的槽位，如属性名称、数据类型或复合类型， V 是每个槽位实例化的值，D 是任务间的建模依赖关系，其中 depend_on 指定了其他任务的必要输出，生成当前任务代码，提供 表示任务完成后产生的输出，消耗 表示任务所需的外部输入。

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

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

E₁ = （类型_{i，pos i}，主信_i）（ 2）

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

例如，如果生成的代码包含语法错误，如“属性未被属性定义类型化”，验证模块会返回以下诊断信息：

'type' ： 'error'
'message' ： 'ERROR：属性必须按属性定义类型化。'(3)
“位置”：“第7行第3列”

当验证结果 e_i ≠ 0 时，收集到的错误信息 e_i 会被转发给代码修复代理进行进一步纠正。因此，代码修复过程不是无限制的修改过程，而是基于解析器和验证器返回的显式诊断信息引导的有针对性修订。

语义验证机制
语义验证机制使用与模型代码有显式且可追溯对应关系的关键任务卡字段作为语义锚点。它评估模型层面的语义一致性，从而为后续模型修复提供明确且可操作的标准。具体来说，对于每个任务卡 TC_i，以下字段用作关键语义引用：（i）建模目标 O_i，（ii）语义约束和边界条件 C_i，（iii）实例化参数槽值 V_i，（iv）任务完成后期望输出 D_i['提供'].这些领域从多个角度对生成的模型施加互补的语义约束：建模意图的实现、约束的满足、参数实例的一致性以及模型输出的完整性——使模型代码能够在不需额外假设的情况下，做出原则性判断是否满足建模需求。

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

(4)

其中I（·）表示指示函数，若括号内所有子决策函数成立则为1，否则为0。这一二元判定明确区分了满足建模要求的状态和需要进一步修复的状态，为后续语义修复过程提供了确定性触发条件。整体决策由以下四个子决策函数共同决定：

（1）建模客观一致性：

Φ₀ （TC_{i，c f}） = I（组成（c_{f，0 i}））（5）

其中 Consist（c_{f，0 i}） 表示模型代码 c_f 是否与任务卡中指定的建模目标 _{0 i} 语义一致。

（2）语义约束满足：

Φ_c （TC_{i，c f}） = I（Satisfy（c_{f，C i}）） （6）

其中 Satisfy（c_{f，C i}） 表示模型代码 c_f 是否满足任务卡中 C_i 指定的语义约束和边界条件。

（3）参数一致性：

Φ_c （TC_{i，c f}） = I（瞬时（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因其强大的语义理解和信息提取能力而被选中，能够准确捕捉核心模型元素而不产生幻觉，并生成类人建模意图^描述9。为确保准确性并消除歧义，所有生成的描述均由具备系统工程背景的研究人员手工审查和完善。不同模型类型的代表性示例见 表1。

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

平均句法错误率（SER）
该指标量化了在验证生成模型代码与官方 SysML v2 语法规则相符时检测到的语法错误比例。其计算公式如下：

(9)

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

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

(10)

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

人类质量评估
传统的自动化指标如BLEU和CodeBLEU主要评估表层相似性或代码可执行性，但它们无法捕捉模型是否真正理解或正确表达预期建模语义。这些指标在评估语义一致性、关键元素完整性以及与建模意图的一致性方面^有限。相比之下，人类评估可以更准确地识别诸如语义元素缺失、逻辑不一致、结构冗余或无依无据的幻觉等问题，从而提供更可靠的评估¹¹。基于这些局限性，我们设计了一个人工评估框架，涵盖三个标准：（1） 正确性：生成模型必须准确反映建模意图，保持与任务目标的结构和逻辑一致性，且不含语义歧义、遗漏元素或错误扩展。（2） 可读性：模型代码应清晰易懂，命名一致，结构连贯，层级结构良好，支持检查和后续维护。（3）完整性：模型应具备完整的结构逻辑、一致的跨元素引用，且无未定义类型或断裂的依赖链，确保其在后续分析和集成中的可用性。我们邀请有SysML建模经验的研究人员，在三分制上对每个生成的模型进行评分，1代表最低质量，3代表最高。评估过程中，评估员被允许将生成的模型代码与真实模型进行比较，以确保评估更准确、更全面。

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

自我规划¹³：引入两阶段代码生成流水线，模型先规划解决方案步骤，然后按计划生成代码，有效提升复杂任务的逻辑连贯性和可解释性。

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

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

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

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

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

Results

基线模型评估
我们首先选定了几个主流大型语言模型，并使用直接的模型到代码生成进行了初步性能测试，包括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）被选为本研究评估各种代码生成策略的基础LLM。这些策略评估的结果总结于 表2

Discussion

我们提出了MAS4SysML，一个多智能体协作框架，用于半自动化SysML v2模型代码生成。该框架由四个功能互补的代理组成。在生成过程中，它（i）利用基于任务树的结构分层分解自然语言建模需求，并将其形式化为结构化任务卡，（ii）根据这些卡中指定的约束和依赖关系，自下而上生成SysML v2模型代码。在生成过程中，基于官方 SysML v2 验证环境构建的语法验证模块执行语法诊断并返回以修复为导向的反馈。代码生成后，框架进一步检查关键任务卡字段的语义一致性，提升生成代码的可执行性及其与预期需求的一致性。

MAS4SysML为将自然语言建模意图转化为SysML v2模型代码提供了实用路径。它有助于降低复杂设备开发中手工建模的成本和学习负担，并通过闭环验证过程提高迭代效率。相较于模板或规则驱动的模型生成方法35，MAS4SysML避免了大规模手动模板维护，能够在结构化任务卡约束下以更低的工程成本适应多样化建模任务，同时通过验证反馈提升输出稳定性和可执行性。与仅使用LLMs...

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
LangChain	LangChain（开源项目）	v1.0.8;https://github.com/langchain-ai/langchain	LLM交互与代理编排框架
LangGraph	LangChain（开源项目）	v1.0.3;https://github.com/langchain-ai/langgraph	多智能体工作流执行框架
蟒蛇	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	用于语法验证和模型解析