专属Agent重构MBSE：让系统工程人摆脱模型搬运工

先说一个我上周的真实经历。开SysML评审会，设计组把环控导管改成双路冗余，顺手下发了一条需求变更：系统总重从5000公斤下调到4800。整场评审一个小时，四十分钟都在讨论“这条变更影响了哪些模块、哪些接口、哪些验证项”——不是在讨论设计决策本身，而是在手工数牵扯、翻追溯矩阵、改图模型。这种场景在基于同元Mogick这类系统工程工具的团队里几乎每天都在发生，它恰恰就是专属Agent最该接手的活。

我在这个领域待了十多年，见过太多团队把MBSE推行不下去的原因从“工具不会用”慢慢变成“人被工具耗死”。工具链越来越全，需求、架构、仿真都能管了，但人的精力全花在模型库里做搬运工。所以当AI Agent这个概念热起来之后，我一直觉得系统工程是最值得被“专属化”重构的领域之一。通用Agent能写代码、能做文档摘要，但放进SysML模型库就抓瞎。这篇文章我想认真聊一聊：为什么系统工程需要的是专属Agent，而不是直接开箱即用的通用Agent，以及面向同元Mogick这类MBSE平台做Agent化改造时，真正要解决的架构问题和边界问题。

1. 一场SysML评审引发的思考：系统工程人都在忙什么

1.1 需求追溯矩阵背后的手工劳动

很多人以为需求追溯矩阵是工具自动生成的，其实一半以上是手工喂出来的。需求变了，要去模型库里找出所有refine、satisfy、derive、verify关系，一条条确认受影响的设计元素和验证活动。模型小的时候还能扛，模型到了几百个模块、上千条连接关系的时候，做一次变更影响分析就是一场灾难。

我在Mogick里见过最典型的一次变更：一条关于“最大起飞重量不超过5000kg”的需求调整为4800kg。表面上只改一个数值，实际上要追到总体参数、推进系统选型、结构质量预算、接口负载、验证用例、甚至评审交付物清单。每查一层关系都要在模型树上点开几个节点，截图、贴标签、做清单。这套活本质上是图遍历，可人做图遍历的效率和机器差了十万八千里。

1.2 文档与模型之间的旧账

系统工程交付物里有一大块是文档：系统规格书、接口控制文档、验证计划。这些文档的理想来源是模型，现实里却经常是手工从模型里把信息“抄”出来，或者反过来——模型改了，文档没跟上，评审时被人当场抓包。

不少MBSE平台都有报告生成模板，但模板能生成的是“数据报表”，不是“有逻辑的叙述”。你让工具按模板出一份接口控制文档，它能把端口列表拉出来，但说不清楚这条接口为什么这么设计、备选方案是什么、谁拍的板。这些语义层面的东西散落在讨论记录和评审纪里里，模型层没有，文档层也没有，最后就成了个人经验。

1.3 模型是答案，人手不够才是问题

说实话，方法学层面该卷的已经卷得差不多了。SysML的九种图、需求追踪、架构权衡、基于模型的验证，知识都是公开的，工具也都支持。真正卡脖子的不是“不知道怎么做”，而是“做一遍要花太多人工”。

参数化设计更明显。做多方案权衡的时候，理想做法是把参数模型跑几十次，扫出响应面再挑Pareto前沿候选。可现实里，大家往往是拍两个方案试一下，觉得差不多就收工。不是不想多探索，是每次参数调整、仿真调度、结果汇总都得手动来一遍，时间成本根本不允许。这种“让人干不了的事”，正是Agent最应该补位的部分——但请注意，这里的Agent不是能和你聊天的通用助手，而是能直接在模型库里操作元素、维护关系、调度仿真工具的专属智能体。

2. 通用Agent进不了SysML模型库：三处硬伤

2.1 文本语义和模型语义不是一回事

通用Agent的训练语料里绝大部分是自然语言文本，它对“单词怎么组合成一句话”理解得极好，但对“SysML图上的一个端口怎么连到另一个端口”这种结构语义几乎没有感知。

举个例子，你在Mogick里画了一个内部块图，组件A的output端口通过一条带item flow的连接线接到组件B的input端口。这条连接在模型库里是一串带类型的对象和关系，不是一段文字说明。你把图导出成文字描述拿给通用Agent看，它能读得懂，但你要是让它“给这个连接加一个数据流约束”，它就不知道数据流约束该挂在哪个元素上、值类型对不对、方向有没有搞反。这就是文本语义和模型语义的鸿沟。

SysML里的知识密度远比一篇文章高。一个block上挂着属性、操作、约束、端口、流属性，一个需求上悬着派生关系和验证方法。这些在模型库里是点对点的引用关系，通用Agent没有接受过这个层面的语义训练，让它直接编辑模型库，就像让一个只看过菜谱的人直接上手颠勺——理论上知道流程，实际上处处失控。

2.2 通用Agent没有操作模型工具的“手”

第二个硬伤更现实：工具边界。通用Agent能通过API调代码、操作文档、发邮件，但MBSE平台是个相对封闭的建模工作台。Mogick里面的模型树、图形编辑器、仿真配置、参数绑定，都有自己专有的数据格式和交互协议。通用Agent连它的模型库都没法直接读写，更谈不上在图上增删元素、改端口绑定、调整约束块。

有人会想，那我让Agent用屏幕自动化去点界面总行了吧？实测过的人都知道，图形化建模工具的界面自动化极其脆弱，一个模型树折叠状态变了、一个弹窗焦点偏了，整个操作链就崩了。所以专属Agent必须有一个“工具接入层”，把MBSE平台的原子操作封装成可调用的服务。这个服务不是通用Agent自带的，是要针对Mogick这类平台一个个去适配的。

2.3 状态一致性：没有领域边界就是乱改库

通用Agent还有一个让人头疼的问题：它对“一致性”没有概念。写代码的时候，少一个分号编译器会报错；但改模型库的时候，很多错误是静默的——元素还在，引用关系却断了；参数值改了，约束方程没更新；端口类型改成另一个值类型，接口文档里还挂着旧信息。

模型库和数据库有一点很像：它是有状态、有约束的。一个模型库里几万个元素互相引用，任何一次写入都可能破坏引用完整性、类型匹配、覆盖率关系。通用Agent没有被约束规则约束过，它只知道自己完成了“写下这个操作”，不知道这个操作是否把模型库置于破损状态。

我见过一个实验，让通用Agent在测试库上“帮忙补需求追踪关系”，结果它一口气创建了将近两百条类型错误的关系，把需求图的引用关系全弄乱了。这种事没有领域状态校验能力的通用Agent干起来毫无心理负担。所以专属Agent的核心不是“更聪明”，而是“更受控”——它在模型语义的约束边界内行动，而不是天马行空。

这张表放在一起看就很清楚了：通用Agent的能力模型是“以文本为中心、以通用工具为边界”，系统工程的专属Agent是“以模型为中心、以MBSE工具链为边界”。两者差的不是一点半点，是整套认知模型和工作范式的区别。

3. 专属Agent“专”在哪里：四个层面的能力拆解

3.1 模型语义映射：把一句大白话变成模型库操作

专属Agent的第一层能力，是能听懂“人话”并且把它翻译成模型库的原子操作。拿需求变更来说，你说“把需求SYM-023的重量从5000改到4800，并把受影响的设计元素列出来”，专属Agent要做的不止是找到SYM-023改数值，它要自动沿着需求追踪关系往前遍历——哪些block满足这条需求、哪些接口承载了流量、哪些组件要做质量预算重算——然后输出一个影响清单草稿。

这层能力的背后，是“自然语言意图 → 模型语义查询/修改计划 → 模型库操作序列”的三级映射。把“改需求”变成“改某个需求元素的属性值，同时触发影响传播分析”，这个能力必须针对SysML的元模型进行定制开发，而不是靠通用大模型一身灵性现场发挥。

我看过有团队用提示词让通用LLM生成SysML模型代码，比如生成XML格式的模型片段再导入。这种路子偶尔能跑通Demo，但到了生产环境，模型库的变更规则、元素ID的引用关系、图元素的布局信息根本不是一段XML能覆盖的。专属Agent的价值在于它不生成“模型的样子”，而是直接操作“模型的实体”——在模型仓库里改真实元素，改完图的渲染自动更新，不需要导出导入这种脆弱的桥。

3.2 领域知识：需求、FMEA、权衡方法不是现场推理出来的

第二种“专”在知识。系统工程有一大堆流程性知识，不是靠大模型泛化的常识能覆盖的。比如FMEA（失效模式与影响分析）里风险优先数怎么算、严重度发生度探测度的评分标准是什么；比如架构权衡分析里AHP打分、响应面方法、Pareto前沿怎么用；比如需求工程里一致性和可验证性检查的规则清单。

这些知识最适合沉淀成两个东西：一是知识库，把组织内部的历史项目经验、老专家的决策逻辑、评审常见问题整理成可检索的记忆库；二是技能包，把一类高频任务封装成一个可调用的流程单元。

我在Mogick实践里用过这样的技能定义，格式类似这样：

{ "skill": "impact_analysis", "trigger": "requirement_changed", "steps": [ "collect_satisfied_blocks", "trace_flow_ports", "update_traceability_matrix", "flag_risk_items" ], "guard": "requires_review_approval", "output": "impact_report_draft" }

这个技能包的意思是：当需求变更触发时，Agent先收集所有满足该需求的模块，再追踪流经的端口，然后更新追溯矩阵，最后标记风险项。整个流程不允许直接对外发布，必须经过评审确认。这看起来只是一段配置，但它把组织沉淀的干活路径变成了Agent的肌肉记忆，而不是每次都在提示词里重新编排。

3.3 工具接入：没有适配器就没有手脚

第三种“专”在工具接入。任何Agent想干活都得有“手”，专属Agent的手就是针对MBSE平台专门开发的适配器层。

以Mogick为例，要让Agent完成真实建模任务，适配器至少得提供这些操作能力：

• 模型仓库读写：查询元素、创建/删除/更新元素、维护关系和引用
• 图形与视图刷新：模型变更后通知视图层刷新，保持图与模型一致
• 仿真调度：提交参数化仿真任务、收集结果、写入模型参数
• 报告与导出：按模板生成文档草稿、导出追溯矩阵、生成图表
• 基线管理：创建和恢复基线、审批变更集、锁定受保护元素

这些操作在人工操作时是鼠标点出来的，在Agent化之后就是一组REST或RPC接口。没有这层适配器，Agent学再多领域知识也只能停留在“动嘴皮子”的阶段。这也是为什么我总说，专属Agent的工程量分配里，适配器和工具链能占掉七成，模型语义和知识库反而只有三成。

3.4 流程嵌入：干活的人也必须被流程管着

最后一种“专”，是对流程的嵌入。系统工程不是个人创作，是流程协作。需求变更要走变更控制，设计产物要过评审，模型基线要受构型管理约束。专属Agent不能游离在流程之外，它本身就是流程里的一个执行者。

嵌入流程的意思是，Agent发起任何写操作之前，都要先看自己的权限边界和流程状态。处于“评审中”的模型区域，Agent只能读不能写；涉及基线的变更，Agent只能生成变更集草案，不能直接落到基线上；需要多方会签的决策，Agent可以组织材料、将意见和风险点整理好，但最终批准由人来点。

这层设计至关重要，它决定了Agent是“流程的仆人”还是“流程的破坏者”。把流程约束直接写进Agent的执行规则里，比事后审计要省钱得多。与其等Agent把库改坏了再恢复，不如让它根本碰不到受保护的位置。

4. 同元Mogick上的专属Agent架构：分层设计与并发策略

4.1 分层思路：Harness、Agent内核与模型服务各司其职

真正在Mogick这类MBSE平台上落地专属Agent，我强烈建议用分层架构，别把调度逻辑、领域逻辑、工具逻辑全写在一个循环里。现在做Agent开发经常听说harness和Agent的区别，放在系统工程的语境里更清楚：harness是执行壳，管流程编排、工具调用循环、上下文注入、超时与错误处理；Agent内核是决策者，管“这一步该做什么、下一步做什么”的判断。harness决定Agent怎么跑，Agent决定活怎么干。

我建议的五层结构是这样的：

• 第一层，编排层（Harness）：接收任务，维护任务状态机，管理工具调用循环和错误重试策略
• 第二层，领域Agent内核：理解用户意图，结合模型上下文物化执行计划，调用下层能力
• 第三层，语义服务层：提供SysML模型语义解析、需求追踪遍历、影响传播计算、约束检查
• 第四层，工具适配层：对接Mogick模型仓库、仿真引擎、报告引擎、基线服务
• 第五层，模型仓库：存SysML模型对象、关系、视图、基线版本

分层的核心意义在于隔离责任。语义服务层出了问题，不影响工具适配层；工具接口变了，只需要改适配层，Agent内核不用动。这一点在被现实毒打过之后会深有体会——MBSE平台的接口两年一小变、五年一大变，没有隔离层，Agent代码就会变成一次性工程。

4.2 并发怎么扛：单写多读的工作区策略

很多人问AI Agent怎么扛并发，做搜索问答类Agent并发不是大问题，但做MBSE模型操作，并发就是个真问题。Mogick的模型仓库不是数据库，不支持MVCC那一套复杂的多版本并发控制。两个Agent同时往模型库里写，轻则互相覆盖，重则把关系引用写断。

我的实践经验是：在系统工程的模型仓库场景里，抛弃“多Agent同时写同一个模型库”的幻想，老老实实采用单写多读的工作区策略。所有写操作统一走一个串行队列，读操作可以并行。这个队列不必搞得高大上，可以用最简单的消息队列或者分布式锁实现，关键是保证同一时刻只有一个写者在修改模型对象。

这事儿的本质是向Git学着用工作区分隔，但比Git更保守。SysML模型的合并比代码合并痛苦得多，因为模型里一个元素可能有几十种关联，代码冲突能看diff，模型冲突没法看。所以策略不是“允许并行写再合并”，而是“尽量不让并行写发生”。

4.3 一台电脑多个Agent同时干活的正确姿势

那真正需要并行的时候怎么办？按模块分区、按任务分时段。比如一个Agent负责需求域，另一个负责逻辑架构域，如果它们操作的元素集合完全不重叠，就可以放进不同工作区并行执行。等两个工作区的变更都稳定了，再做统一合并评审。

还有一种更实用的组合方式：一个“管理Agent”负责任务拆分和结果汇总，多个“执行Agent”分头做独立子任务。管理Agent把“分析这30条接口的流量匹配关系”拆成三个子任务，每个子Agent处理10条，处理完把结果汇总。这些都是只读分析，不存在写冲突，并发度可以提得很高。一旦涉及写模型，就回到单写者模式。

并发策略的背后其实是软硬件资源与一致性风险的权衡。MBSE场景并发收益没那么大，因为瓶颈往往在模型语义推导和人工评审环节上，不在计算速度。别为了炫技硬上分布式，把架构搞复杂了，最后修冲突比手工干还累。

5. 落地时真正的大坑：一致性校验、记忆与安全

5.1 写后校验：模型库不是大模型的安全气囊

Agent写入模型之后，模型可能已经处于不一致状态，而且Agent自己未必知道。所以专属Agent的架构里必须有一个独立的写后校验环节，写入之后立即触发约束校验规则，这跟数据库的触发器一个思路。

校验规则至少覆盖这几类：

• 引用完整性：删除元素时，所有指向它的引用都被正确处理
• 类型匹配：端口连接的类型兼容、值类型匹配、接口协议一致
• 关系约束：需求必须至少有一条实现路径（satisfy/refine），无孤儿需求
• 覆盖完整性：架构元素是否都有对应的需求和验证项

这些规则里，有些是SysML规范本身就要求的，有些是组织自定义的工程约束。我在实操中踩过一个典型坑：Agent自动给一个新block创建了十几个端口，但忘了给其中一个端口做类型绑定，模型库没报错，直到仿真预处理器开始报“未定义流类型”才暴露。后来我就强制要求所有端口创建操作必须走一个“创建并绑定”的复合工具，从工作机制上堵住这个漏洞，而不是靠Agent自觉。

5.2 工作记忆与长期记忆怎么分工

Agent记忆问题在系统工程场景下有个特殊的维度：它不能只记住对话上下文，更要记住“模型仓库当前长什么样”。你让Agent去补两条需求追踪关系，它得知道模型库里现在有哪些需求元素、哪些模块还没被覆盖、上游某个接口最近刚改过。这些信息如果全靠对话上下文携带，上下文长度先炸了。

我的习惯是把记忆拆成两层。一层是任务级工作记忆，用来存当前这个任务涉及的模型对象ID、临时结论、待确认问题，任务结束就释放。另一层是项目级长期记忆，存历史决策记录、常用设计模式、评审遗留事项、变更记录索引，跨会话复用。长期记忆可以用向量存储，但更关键的是要和模型仓库的标签与基线系统打通，让Agent能按“项目、阶段、模块、需求编号”这几个维度精确检索历史信息，而不是让人在记忆库里大海捞针。

5.3 权限、基线、审计：把Agent当成一个新人来管

最后是安全和治理。很多团队让Agent在模型库里干活的时候心里没底，怕它乱改。破解这个心理障碍的办法很简单：把Agent当成一个入职三个月的新人工程师，该有的权限控制和操作审计都有，你给新人的信任边界也就是给Agent的信任边界。

权限上，按角色分：需求分析Agent能读写需求域，架构Agent能读写设计域，但只有极少数管理Agent能碰基线发布操作。基线上的模型区全部只读，要改就必须走变更集流程。审计上，Agent每一次写操作的before/after快照、触发动机、审批状态都要记录，这样出了问题能倒查，也能用来给Agent不断做效果评估。

很多工程团队的顾虑是“AI改了模型出了问题谁负责”。我的回答是：不让AI直接负责，让它负责“提出变更”，人来负责“批准变更”。Agent生成的变更集相当于一个待审PR，模型管理员review通过后才落到正式基线。这个机制比事后追责更健康，团队接受度也高得多。

6. 哪些团队适合上专属Agent，哪些先别急

6.1 适合的画像

不是所有团队都适合立刻上专属Agent，我见过不少团队上了全套系统然后闲置，很浪费。判断适合不适合，主要看四个信号：

一是模型资产是不是已经成为团队的“主资产”。如果团队每天的核心工作就是在Mogick这类工具里维护需求、架构、接口和验证数据，模型承载了真实的设计知识，那Agent化改造的ROI就非常高。

二是需求变更频率高不高、波及面大不大。那种一个季度需求难得动一次的团队，Agent的影响分析能力发挥不出来。反过来，每周都要做变更影响评估的团队，Agent上线你立刻能感受到效率差异。

三是团队有没有把工具链API化的意识。如果团队还在靠纯手工点界面的方式维护模型库，那么先做工具链API化，再谈Agent化。没有稳定的接口，Agent就没有靠谱的手。

四是组织容错度。Agent刚开始干一定会犯错，团队要有试错空间，能接受“让Agent在预演环境里跑、人审完再合并”的工作方式。一上来就要零误差的团队，不适合做第一个吃螃蟹的。

6.2 不合适的画像

反过来说，有些团队先别急。模型库刚建、连基本的方法论都没跑顺的团队，先别上Agent，先把建模规范和评审流程理顺了再说。不然Agent学到的就是一团乱麻的模型操作习惯，越自动化，垃圾产生得越快。

工具链没有开放接口的团队也别硬上。我见过一个团队试图用UI自动化去操作建模工具，结果平台版本一升级，所有脚本全废，维护成本比手工干活还高。这条路走不通就别强求，去跟工具厂商要求开放API或者等待官方Agent方案，比自研省心得多。

另外，团队如果本身没有“领域知识沉淀”的习惯，也得缓一缓。Agent的知识库不是凭空来的，它需要历史变更记录、历史评审结论、过往FMEA库这些养料。一个不归档、不复盘、不记录决策理由的团队，Agent学不到东西，最后就只是个自动化鼠标。

6.3 落地路线建议

如果决定要上，我的建议是先挑一个最痛的场景做小闭环。别想着一步到位做一个全知全能的系统工程Agent，那是产品愿景，不是落地路径。

理想的第一步，是针对“需求变更影响分析”这个单一任务做Agent化。原因很实在：它流程清晰、涉及的操作收敛在一个频发的场景里、短期就能看到人效提升。跑通这一个任务之后，再逐步扩展到报告草拟、参数化仿真调度、接口一致性检查。每攻下一个场景，把该场景牵扯到的工具能力、校验规则、知识沉淀补齐，再进入下一个。

这种渐进路线还有一个好处：团队能在早期就积累起对Agent的信任。看到Agent真的能把追溯矩阵更新干净、把影响清单整理得像老工程师出手，后面推其他场景就顺畅了。相反，如果一上来就放它去动整个模型库架构，大概率第一天就被“不信任”卡死。

结合我自己的使用体验，这类系统工程专属Agent一旦在设计闭环里站稳脚跟，最明显的变化不是“人变少了”，而是“人终于开始干回人该干的活了”——做决策、做权衡、做评审，而不是趴在模型树上数关系。同元Mogick这类MBSE平台提供了最好的土壤，它已经有现成的模型仓库和工具链底座，缺的就是一个真正懂SysML语义、受模型约束、嵌在流程里的专属Agent执行层。这个位置，通用Agent替不了，也抢占不了。