企业官网建设流程全解析

做了十几年系统工程，我对周围那些“AI Agent能包打天下”的说法一直有点戒心。不是怀疑技术本身，而是见过太多通用模型把一份需求文档当成百科问答来玩——你问它“这个信号裕量还剩多少”，它能给你分析出一篇小作文，但接入到真的SysML模型里，它连哪个Block对应哪个约束都不知道。直到最近，我把一套面向复杂装备研制的Agent框架，也就是同元Mogick，放到一个小型卫星测控系统的早期设计验证任务里完整跑了一遍，才真正想明白“为什么系统工程需要专属Agent”这个问题。这篇文章不打算去追什么参数规模，就围绕Mogick实际解决的一个场景来讲：当需求发生变化时，如何让AI自动定位受影响模块、修正仿真模型、输出可追溯的验证报告。适合在做MBSE、数字孪生、型号研制的朋友看，也适合那些正在犹豫到底要不要自研Agent平台的团队参考。

1. 系统工程为什么不能直接拿通用Agent硬扛

很多人会问：现在通用大模型已经那么强了，写代码、查资料、做推理样样行，为什么还要专门搞一个系统工程Agent？这个问题如果不先说清楚，后面所有的架构设计都站不住脚。我过去也踩过这个坑，最早把需求文档直接丢给通用对话Agent，结果它在纯文本层面一切都好，一旦涉及到模型、参数、接口关系，就开始一本正经地胡说八道。根源不在模型能力，而在系统工程这个领域的信息组织和通用场景有本质区别。

1.1 通用Agent只能回答“是什么”，系统工程需要“为什么”

通用Agent擅长的是从已有文本中抽取信息、归纳要点、生成问答。你问它某段需求描述了什么功能，它能答得头头是道。但系统工程中最值钱的东西并不是这些表面描述，而是需求背后的约束传播关系——一个需求变了，它会影响哪些功能模块，哪些物理接口会连锁反应，哪些验证用例需要重跑。这种“为什么”的推理链路，通用Agent是看不见的。

举个例子，一个测控系统的下行链路数据率从1Mbps提升到2Mbps，表面上只是改了一个数字。实际上这个数字会传导到编码器的码率参数、调制器的带宽设计、功率放大器的线性度要求、天线口径的增益预算，最后还可能推翻整个链路仿真模型里的好几个假设。通用Agent面对这个问题，只能根据语义相似度去猜测相关模块，猜中一两个算运气好，但绝不敢保证不漏项。

Mogick的做法是把这层约束关系显式建出来。它内部维护了一张“需求→功能→逻辑组件→物理部件→验证用例”的追溯网络，Agent的每次推理都在这张网络上执行节点跳转，而不是靠大模型自由联想。这样一来，当数据率这条需求变更时，Agent能严格按追溯链路找到所有下游节点，并且标注出哪里缺少覆盖、哪里存在冗余，这种能力在通用Agent里基本见不到。

1.2 模型即代码，通用Agent够不到工程资产

系统工程里最核心的资产不是文档，而是模型。SysML的块定义图、内部块图、状态机图，Modelica或Simulink里的方程和仿真参数，这些都是高度结构化的工程资产。一个通用Agent只能看到经过序列化处理后的文字描述，比如“Block A连接到Block B，连接线名为C”，但它没法直接打开一个SysML模型库去查询Block的端口类型、约束属性、关联关系的多重性。

这就像让一个没学过电路的人去看电路原理图，他看的是线条和符号，你问他“这个节点的电压是多少”，他只能猜。Mogick专门加了一层“模型感知层”，用系统的元模型去索引模型库，Agent可以像调用数据库一样查询模型元素。它知道某个Block的哪个端口关联着哪条约束，知道某个参数在哪个仿真场景里被引用，知道哪个需求条目追踪到了哪张状态机图。这不是提示词工程能解决的问题，而是要把Agent的信息输入从“文本”改成“模型”。

我见过一个典型的对比。同样问“如果外部干扰信号强度翻倍，哪些指标会受影响”，通用Agent给出的答案是把需求文档里出现“干扰”这个关键词的段落都罗列出来，看着全面，实际没用。Mogick的仿真Agent会直接解析干扰模型的参数定义，逐条遍历关联的验证用例，甚至能自动跑一轮仿真数据来判断裕量变化趋势。这中间的差距，本质上是“有没有真正接入工程数据”的差距。

2. Mogick的“专属”不是换提示词，而是换执行链

很多人以为让一个通用Agent“懂系统工程”的办法是写一版更长的系统提示词，把领域术语都塞进去。这个方向我试过，效果很有限。原因很简单：系统工程是流程密集型工作，不只是知识密集型。Agent真正要干的不是“知道什么”，而是“按什么顺序调用什么工具、检查什么约束、产出什么工件”。Mogick在这上面的做法很有代表性——它没有把精力花在训练一个更懂工程的模型上，而是花在了重新设计Agent的执行链路上。

2.1 Harness、Skill与Agent：一条可编排的工程流水线

先区分两个经常被混在一起的概念：Harness和Agent。我理解的Harness是Agent外部的“执行外壳”，负责工具的调用、状态的维护、任务的编排和结果的收集；Agent本体则是决策内核，负责根据当前上下文决定下一步做什么。Mogick把整个仿真验证过程抽象成了一个Harness，里面挂载了多个技能节点，每个Skill都是原子能力。需求和模型检索、仿真执行、结果对比、报告生成，这些Skill可以被组装成流水线，而不是靠Agent每次都从头推理。

实际跑任务的时候，Mogick的Agent会收到一个变更请求，然后走这样一条链路：第一步读取变更的具体内容并定位到需求库条目；第二步触发“需求追溯”技能，找到所有下游关联元素；第三步调用“模型查询”技能，把受影响的功能模块和逻辑组件取出来；第四步调度仿真服务执行参数扫描；最后一步由报告生成技能把验证结论整理成结构化输出。这条链路是固定的、可重复的，每一步的输入输出都有明确的Schema。

多Agent协作也是在这条流水线上实现的。建模Agent负责处理SysML模型变更，仿真Agent负责运行仿真任务，质控Agent负责校验结果完整性。它们之间传递的不是自然语言对话，而是工程对象——带着模型ID、参数名、数值集合的结构化数据。这样做的好处很明显：不会发生两个Agent聊着聊着把技术术语理解岔了的情况。我见过不少团队用通用Agent做多Agent编排，结果A Agent说了一句话，B Agent理解成另一个意思，最后全链路跑偏。Mogick用Schema约束住了每个节点的通信格式，从根本上避免了这类问题。

2.2 领域知识怎么进入Agent：工程本体与记忆管理

要让Agent真正“专”起来，光有执行链路还不够，它还得理解什么是需求、什么是功能、什么是验证用例，以及它们之间存在哪些关系。Mogick的做法是建立了一个工程本体层，把MBSE里常用的关系类型，像“派生、分解、满足、验证、实现”这类语义关系，都做成了机器可读的三元组结构。Agent在查询“哪些功能满足这条需求”时，执行的是一场精确的图查询，而不是一次模糊的文本匹配。

记忆管理是另一个容易忽略但特别关键的点。系统工程任务往往跨度很长，一个变更影响分析可能要同时处理需求文档、几十个模型文件和多轮仿真结果。如果把所有材料都塞进Agent的上下文窗口，很快会爆掉，而且早期信息会被后续内容稀释。Mogick把记忆分成了工作记忆和长时记忆：工作记忆只保留当前任务链路上的关键对象，长时记忆则存储历史决策和已验证过的模型绑定关系。仿真日志这类体积大但价值密度低的数据，Agent会先生成结构化摘要再决定是否进入上下文。

记忆这块我特别有感触。早期我们做Agent时，恨不得把所有历史记录都留着，结果发现上下文一长，Agent开始犯迷糊，甚至会引用一段已经废弃的参数定义。后来改成Mogick这个方案，让记忆系统只保留“当前任务需要的”和“经验证过的结论”，整个Agent的执行稳定度明显上来了。所谓专属Agent，其实就是把“该记什么、不该记什么”这件事从模型参数转移到了工程语义中。

3. 实操：在Mogick上搭建一个变更影响分析Agent

前面说得再多，不如动手跑一遍。我基于Mogick搭了一个针对卫星测控系统的变更影响分析Agent，整个搭建过程大概花了一天时间。下面我把关键步骤写出来，你照着做就能复现一个简化版本。当然，真实企业里模型库、仿真服务、权限体系要复杂得多，但核心思路是一样的。

3.1 环境准备与Agent配置

我用的是本地方案，一台高性能工作站，装好了Python环境和一个支持TCP通讯的仿真求解器，模型库放在本地目录。Mogick本身提供了Agent框架的Python SDK，以及一个基于YAML的配置入口。需要说明的是，这里的配置直接影响了Agent的行为边界，不建议图省事用默认值。

agent: name: change_impact_agent harness: max_steps: 12 timeout_seconds: 120 checkpoint_dir: ./checkpoints memory: working_memory_size: 32 long_term_memory_store: ./memory_store skills: - name: requirement_traceability type: knowledge_query model_repo: ./model_repo - name: simulation_runner type: sim_service endpoint: tcp://127.0.0.1:9090 - name: report_generator type: template_engine template: ./templates/impact_report.j2

配置里值得注意的几点：max_steps限制Agent最多执行12步，防止它在推理链上无限走下去；working_memory_size限制上下文容量，逼着它依赖外部记忆而不是把所有东西都揣在手里；模型仓库的地址明确指定，让Agent只能访问被授权的模型目录。这些看起来都是小参数，但决定了Agent是否可控。

配好环境后，我会用一个简单的脚本初始化Agent。这一步主要是把工程本体加载进来，让Agent知道“需求”“功能”“部件”“验证用例”这些概念以及它们之间的连线。加载完成后可以做一次自检，让Agent回答一个已知答案的追溯问题，比如“系统的安全模式由哪个功能模块实现”。如果这一步回答错误，说明本体加载有问题，后面就不用往下跑了。

3.2 一个完整任务：需求阈值从7.5变成8.2

现在模拟真实场景。测控系统有一项需求REQ-1042，内容为“在正常工况下，遥测信号接收电平门限不大于7.5dBm”。需求变更申请提出要把这个门限改成8.2dBm，也就是接收灵敏度要求降低。这个任务交给Agent执行后，它会按预设链路自动开工。

第一步，Agent把“REQ-1042”解析为需求库中的实体，读取新的门限值，然后调用需求追溯技能。追溯结果显示这条需求被三个功能模块实现，分别是信号接收前端F-201、自动增益控制F-202、下行解调器F-203。每个功能模块又对应着具体的逻辑组件和物理部件。过去人工做这个追溯，需要打开好几份文档和模型图，至少大半天；Mogick在几秒内就把这条链路拉出来了。

第二步，仿真Agent登场。它根据受影响组件找到对应的仿真模型，把门限参数从7.5改成8.2，然后在同样的干扰场景下重新运行一组参数扫描。这里重点看的是余量变化：原门限下系统链路裕量约有2.1dB，新门限下变成了0.8dB，虽然仍为正，但已经逼近临界值。Agent没有止步于“没失败”这个结论，而是自动检查了关联的验证用例，发现有一个关于高海拔地区性能的测试用例原本就处在边缘状态，改动后余量会更差，所以判定为“中高风险变更”。

第三步，报告生成技能把整个追溯路径、仿真数据、风险判定整理成一份结构化变更影响报告，标题、结论、风险等级、建议动作都齐了。这份报告不是一段长篇大论，而是可以直接挂入变更评审系统的结构化数据，后面还能继续追踪。整个流程跑下来大约三分钟，其中大部分时间花在仿真计算上，Agent本身的调度开销非常小。

3.3 扛得住并发：多任务并行的工程实践

企业里不可能只有一个变更请求在手。我测试过让Mogick同时处理8个不同的需求变更，Agent框架的表现还算稳定。这里的要点是任务队列和结果缓存。每个变更任务会被拆成独立的工作项，由编排层统一调度，仿真服务因为计算资源有限，需要做并发控制。Mogick把同类型仿真任务合并成批量参数扫描，大幅减少了重复建模的损耗。

另外一类容易被忽略的是“结果缓存”。如果两个变更请求触及同一个功能模块，Agent不会盲目地重新仿真两遍，而是先查缓存里有没有相同场景下的近期结果。这个设计和做Web系统时用Redis缓存思路一样，但在Agent领域很多人想不到。实测下来，叠加缓存以后，8个并发任务的完成时间从理论上的半小时压缩到了十二分钟左右。

4. 踩过的坑与排查实录

专属Agent不是配好就能顺利跑，中间一定会出幺蛾子。这里把我的实战踩坑记录整理一下，每个问题都是真实遇到过的，给后面动手的人做个心理准备，也给出排查思路。

4.1 Agent把约束忘了：指令偏移

最开始跑的时候，出现了一个很典型的现象：Agent在做完需求追溯之后，下一步动作忽然开始“自由发挥”，不再沿着预定义的执行链走，而是尝试自己解读一段模型描述文本，结果给出的结论牛头不对马嘴。这就是所谓的指令偏移。原因是把工程约束写在了Prompt里，Prompt一长，模型对约束的关注度就被稀释了。

解决方式是把约束从“提示词”移到“Harness逻辑”里。Mogick的做法是让Tool返回结果时自带校验规则，比如模型查询技能返回的每个Block都要附带“是否已确认连接关系”的标记，Agent如果没带上这个标记就继续下一步，编排层会直接拦截并提示重跑。靠逻辑强制而不是靠模型自觉，这个思路特别管用。

4.2 上下文爆炸与记忆污染

第二个大坑是仿真日志把Agent给冲晕了。有一回跑链路仿真，生成的日志文件接近10万行，我图省事直接把日志内容塞给了Agent，结果它不仅没找出关键指标，反而从日志里“提炼”出了几段无关紧要的错误信息，然后一本正经地写进报告。上下文一炸，整个推理质量断崖式下降。

Mogick的修正方式是给仿真技能加了一个“输出摘要器”，仿真完成后不是回传原始日志，而是先提取关键指标的均值、方差、极值和超限次数，再把这几项结构化数据返回给Agent。工程数据的维度比文本低很多，完全不需要把原始日志全量带进上下文。这个改动让Agent的判断准确率提升了一大截，而且Token开销也降了至少一个数量级。

4.3 多Agent协作死锁

多Agent编排看起来光鲜，跑起来也会有并发问题。有次我让建模Agent和仿真Agent协同处理一个模型同步任务，结果建模Agent发现参数不一致，发消息给仿真Agent要求重新计算，仿真Agent算完发现模型需要调整，又回头请求建模Agent修改。两个Agent就这样互相等待，直到超时。这不是模型笨，而是缺少编排层的任务终止机制。

解决办法是在Harness里加了两项硬指标：每个Agent的最大重试次数设成3次，每个任务的全局超时设为120秒。一旦检测到循环依赖，编排层会主动中止当前任务并返回中间结果，同时标记出冲突的模型元素，等人来仲裁。经验是：多Agent编排不能太相信Agent的自我判断，必须由外部机制兜底。

4.4 与老工具的集成适配

很多单位已经用了十几年的建模工具，比如老版本Simulink、Rhapsody，这些工具往往没有开放的API接口。Mogick在接入这类老工具时用了适配器模式，把它封装成一个“黑盒工具”，Agent通过文件交换来驱动工具运行。但这又引出了模型版本一致性问题——A适配器打开的是v1.2的模型，B适配器读到的却是v1.3，两个结果对不上。

我们后来的做法是为每个工具适配器固定模型版本快照，并在工作流里加模型校验节点。仿真之前先跑一遍模型编译检查，确保所有参与仿真的模型文件都来自同一个版本基线。这个动作多花了几分钟，但避免了好几起“仿了个寂寞”的事故。

5. 最后聊几句我的体会

跑完这个变更影响分析任务之后，我对“AAAI Agent”的认知有了很大变化。以前总想着把Agent做得越通用越好，什么都会一点；但实际做下来发现，工程场景里反倒是“窄而深”的Agent更好用。Mogick这套框架给我的感觉是，它没有追求让Agent像人一样理解一切，而是把Agent变成了工程流水线里的一个可靠执行器——输入是标准化的变更请求，输出是可追溯的验证报告，中间每一步都可检查、可回退。

我在实际使用中还有一个很深的体会：建立专属Agent的关键投入，不在调Prompt，而在工具链接入和领域语义建模。你的Agent能不能真正读懂一个SysML模型，取决于模型仓库有没有按“关系”组织，而不是按文档目录组织。最后分享一个小技巧：模型仓库的索引不能只做全文检索，架构上尽量用图结构存储关系数据。这样Agent做追溯查询时会非常快，而且结果的准确率比纯文本检索要高得多。如果你正在规划自己的系统工程Agent，我建议先从变更影响分析这类最痛、最具确定性的场景切入，跑通后再逐步扩展，千万别一上来就想做全品类覆盖。