小 M：小 T，你看到同元最近发的 MWORKS AI 介绍了吗？

小 T：看了。上次我们体验的MWORKS MCP，能通过大模型调用 Syslab 或 Sysplorer，完成科学计算和系统建模仿真任务；而 MWORKS AI 更进一步，它是原生嵌入在 Syslab 和 Sysplorer 中的科学计算与系统建模仿真智能体，而是能在软件里理解任务、规划步骤、调用工具、生成模型并执行仿真。

小 M：也就是说，它开始真正参与工程流程了？

小 T：对。今天我们就直接在 Sysplorer 中，使用MWORKS AI 完成一个完整案例。

小 M：做什么案例呢？

小 T：LQR 两轮自平衡车。从控制器参数计算，到模型库生成、三维展示，再到 Sysblock 控制器接入，全流程跑一遍。

小 M：那我还挺期待的，我们现在就开始吧！

一次完整演示：从一句需求到可运行的 LQR 两轮自平衡车

小 T 没有一上来就让 MWORKS AI 直接生成模型，而是在 Sysplorer 的 MWORKS AI 中先输入了一条总任务。

（以下为任务核心口令，完整复现资料可通过文末二维码获取）

请基于 Syslab、Sysplorer MCP 和 Sysblock，构建一个展示级 LQR 两轮自平衡车案例。
模型库名称为 TwoWheeledBalanceLQR_Showcase。要求包括 LQR 控制器计算、Sysplorer 模型库生成、三维动画展示、Sysblock 控制器接入、开闭环对比和控制失败案例。

小 M：欸~咋不直接建模？

小 T：因为这个任务比较完整。如果一上来就让 AI 生成模型，它可能只写一个 LQR 控制器，或者只生成一段 Modelica 代码。我们需要先让它理解：这不是单点问题，而是一个跨 Syslab、Sysplorer、Sysblock 的工程案例。

小 M：也就是说，第一步不是生成结果，而是让 MWORKS AI 先给出工程路线图？

小 T：对。先看它能不能把任务拆对。

小 M：这条指令是不是有点长？

小 T：工程任务就应该说清楚。尤其要告诉 AI：这个案例不是只生成一个控制算法，而是要形成一个完整的模型库和演示流程。

小 M：那怎么判断这一步算通过？

小 T：看它有没有给出清楚的工程路线。如果它能说明：先用 Syslab 计算 LQR 控制率，再用 Sysplorer 生成系统模型并三维展示，之后用 Sysblock 搭建控制器框图，最后处理接口、参数和文档问题，就说明它理解任务了。

小 M：如果它只是解释 LQR 是什么，或者直接生成一段代码呢？

小 T：所以我选择了Plan模式，MWORKS AI 上的说明是提供了两种工作方式，可在 Build（直接生成）与 Plan（规划）模式之间切换。Plan模式是为完成任务制定详细的执行方案，仅生成步骤与建议，不执行任何实际操作。而默认的Build开发模式，规划、搜索、开发等一站式完成任务。

MWORKS AI输出的路线并确认下一步

小 M：很不错，流程很清晰。这样就不是让 MWORKS AI 直接“蒙着头生成”，而是先确认它知道自己要干什么。

小 T：没错。路线图对了，后面每一步才有检查标准；路线图不对，后面生成得再快也可能跑偏。

STEP 01，在 Sysplorer 的 MWORKS AI 中调用 Syslab 设计 LQR 控制参数

小 M：所以我们接下来就是设计LQR参数，那我刚才就想问，为什么不直接让 Sysplorer 生成 LQR 控制器，而是使用Syslab设计呢？

小 T：控制器参数不能凭空写。两轮自平衡车要先有被控对象的线性模型，LQR 控制器也要基于这个模型来算。所以我们先调用 Syslab，把物理假设、A/B 矩阵和 LQR 参数整理出来。

小 M：这些车体质量、车轮质量、质心高度是 Syslab 算出来的吗？

小 T：不是。它们是建模前的物理假设参数。如果有真实样机，可以从称重、CAD 或实验辨识里得到；如果只是做教学演示，就先设定一组合理的默认值。

小 M：那是不是参数随便填也行？

小 T：不能随便填。参数会影响 Plant 的 A、B 矩阵，进而影响 LQR 增益 K。如果后面换了物理参数，K 也应该重新计算。

小 M：所以这一步其实是工程师要把物理假设先定清楚。

小 T：对。MWORKS AI 可以帮我们生成默认参数和计算脚本，但参数来源、物理合理性和是否适合演示，还是要工程师确认。

小 M：那 Q、R 也是算出来的吗？

小 T：不是。Q 和 R 是设计输入，是我们给定的权重；真正根据 A、B、Q、R 计算出来的是 K。uMax、theta0、stopTime 则是工程演示参数，也是我们给定的。

小 M：所以 Syslab 这一步不是单独做一个脚本，而是为后面的 Sysplorer 和 Sysblock 提供统一参数。

小 T：对。后面所有模型都必须按这个参数表来，否则模型可能能跑，但控制效果不对。

Syslab LQR 计算脚本 + 开环/闭环响应曲线

STEP 02，生成 Sysplorer 模型库，先跑通线性闭环

小 T：有了控制参数后，我继续在 Sysplorer 的 MWORKS AI 中生成模型库。第一版先不追求所有功能一步到位，而是先保证线性闭环可检查、可仿真。

（以下为任务核心口令，完整复现资料可通过文末二维码获取）

请基于 Modelica Standard Library，从零新建 TwoWheeledBalanceLQR_Showcase 模型库。
本阶段目标：先生成 Sysplorer Modelica 线性 Plant + 包结构，跑通线性闭环，不直接进入 Sysblock 控制器框图。

小 M：这时候已经模型里面有三维两轮车了吗？

小 T：还没有真正的三维展示。这一版主要是把线性 Plant 和 LQR 控制闭环跑通。

小 M：那为什么不一开始就做复杂三维模型？

小 T：如果一开始就追求复杂轮地接触，很容易把控制问题和多体接触问题混在一起。这个案例的第一目标是先实现LQR 控制，所以先采用“线性状态空间 Plant + 后续三维可视化外壳”的方式。

小 M：也就是说，先保证控制方程是对的，再让它变得好看。

小 T：对。

模型库结构截图

STEP 03，补齐三维展示，但不是直接控制高保真多体模型

小 M：两轮自平衡车如果没有三维动画，展示效果确实差很多。

小 T：所以接下来让 MWORKS AI 追加 MultiBody 三维可视化外壳。但这里要特别说清楚：当前被控对象不是一个完整高保真多体动力学模型，而是“线性控制方程 Plant + MultiBody 可视化外壳”的组合。

小 M：那三维车体起什么作用？

小 T：线性 Plant 负责状态计算，输出 x、theta 等变量；三维外壳读取这些变量，用来显示车体移动、倾斜和车轮转动。它用于展示，不反向影响 Plant 的核心动力学。

当前被控对象由 LinearBalancePlant 与可视化模块共同组成，Plant 输出状态变量并驱动三维显示。

小 M：MWORKS AI 生成的三维动画是不是一次就好看？

小 T：没有。AI 能生成结构，但展示级动画不是只看能不能运行。比如车轮是不是对称、轮轴有没有穿过中心、车体倾斜方向和 theta 曲线是不是一致，这些需要人看。

小 M：所以不是 AI 不行，而是展示效果要靠工程师判断？

小 T：对。AI 负责快速搭出第一版，工程师负责判断它像不像真实两轮车、适不适合真实场景。

STEP 04，接入 Sysblock 控制器，为后续代码生成做准备

小 M：既然 Modelica 版 LQR 控制器已经能跑了，为什么还要再用 Sysblock 搭一遍呢？

小 T：这一步很关键。以前很多控制器直接写在 Sysplorer 的 Modelica 模型里，适合仿真；但如果后续要做控制算法代码生成，框图化的 Sysblock 控制器更合适。

小 M：也就是说，Sysplorer 负责系统模型和被控对象，Sysblock 负责控制算法框图？

小 T：对。更重要的是，现在可以让 MWORKS AI 帮我们生成 Sysblock 控制器。它把 LQR 的状态反馈、增益、求和、限幅和 out_cost 计算都搭成框图，后续更容易走向代码生成和工程部署。

说着小T把公式在纸上列了一下

u_raw = -(k1*x + k2*v + k3*theta + k4*omega) u = saturation(u_raw, -uMax, uMax) instantCost = q1*x^2 + q2*v^2 + q3*theta^2 + q4*omega^2 + r*u^2 out_cost = integral(instantCost)

小 M：这个out_cost 是用来干啥的，也是控制？

小 T：不是，它是用来评价控制效果的。LQR 不只是让车体回正，还要在状态偏差和控制输入消耗之间取得平衡。out_cost 可以帮助我们观察控制过程中的累计代价。

小 T：Sysblock 控制器生成了，我把它接入 Sysplorer 模型，生成新的示例 RunBalanceFromInitialTilt_3D_Sysblock。

STEP 05，仿真能跑了，但控制不住？这时必须统一参数

小 M：模型可以仿真，但是控制不住啊，接着问问？

小 T：MWORKS AI 给了两个排查方向：一是 Sysblock 里的 K、Q、R、uMax 没有和原来的 DesignData 完全一致；二是仿真参数也要统一，比如 theta0、stopTime、扰动幅值。

小 M：这就是工程师要介入的地方？

小 T：对。MWORKS AI 能帮我们定位方向，但参数一致性必须人工核对。我检查了 Syslab 参数表、DesignData、Modelica 版控制器和 Sysblock 控制器，确保 K、Qdiag、R、uMax、theta0、stopTime 都一致。

小 M：然后控制效果就正常了？

小 T：对。修正后，Sysblock 控制器下的两轮车也能恢复直立。这也说明：仿真能跑，不代表控制正确。

STEP 06，最后以当前稳定版本为基准模型库，进入中文化和文档优化

小 M：yes！模型跑通了，成果很完美，结束！

小 T：别着急，模型库优化，比如中文化、注释补齐、参数说明和示例文档也要加上来。

小 M：对，对，这步确实重要，要用于后续的学习和留存，还要让自己和其他同学都看得懂、能复现、能讲清楚。

小 T：这句说得很对，因为模型能跑只是第一步。准确和完善的注释同样重要。所以我们可以让MWORKS AI添加中文的注释和描述，以便我们后期的维护。

以当前稳定版本为基准后只做：

1. 将明显英文 description 改为中文；

2. 补齐模型内部注释；

3. 参数和变量说明中文化；

4. 补充每个 Example 的推荐观察变量；

5. 补充 Syslab、Sysplorer、Sysblock 分工说明；

6. 说明“线性 Plant + MultiBody 可视化外壳”的建模方式。

最终控制效果

从 MCP 工具调用到 MWORKS AI 原生工程智能体

小 M：这次和上次体验 MCP 的感觉确实不一样。

小 T：对。上次 MCP 已经证明了一件事：大模型可以调用 Syslab、Sysplorer 这些 MWORKS 工具能力，不只是停留在问答。

小 M：那这次 MWORKS AI 的变化在哪里？

小 T：这次更进一步。它不是让我们在外部 Agent 里配置工具、调用工具，而是把 AI 能力直接嵌入到 MWORKS 软件环境里。我们是在 Sysplorer 的 MWORKS AI 中发起任务，然后调用 Syslab 、生成 Sysplorer 模型库、接入 Sysblock 控制器。

小 M：也就是说，工具调用能力还在，但入口和体验变了。

小 T：对。原来是“大模型通过 MCP 调用 MWORKS”；现在是“MWORKS 软件本身内置了一个懂工程上下文的 AI ”。

小 M：这就方便多了。模型结构、仿真日志、报错信息、参数配置都在软件环境里，MWORKS AI 可以直接围绕这些内容分析。

小 T：没错。这也是 MWORKS AI 的重点。它把任务规划、工具调用、上下文组织、执行反馈和结果迭代放进了原生交互界面里。用户不需要在多个工具之间来回切换，MWORKS AI 就能围绕当前工程对象继续往下做。

小 M：这次案例里就很明显。Syslab 计算控制率，Sysplorer 构建系统模型，Sysblock 搭控制器框图，整个过程都能串起来。

小 T：而且它还内置了面向科学计算和系统建模仿真的专业 Skills。比如这次调用 Syslab Skill 生成 LQR 脚本，后面又在 Sysplorer Sill里生成 Modelica 模型库，再接入 Sysblock 控制器。

小 M：那国产大模型这块怎么理解？

小 T：MWORKS AI 的另一个重点是面向国产大模型做了工程化适配。不是简单接一个模型接口，而是围绕科学计算、系统建模、仿真调试这些场景，把工作流、规则和 Skills 做了优化，让国产大模型也能更好地完成工程软件里的实际任务。

小 M：也就是说，它不是只比谁回答得更像，而是看能不能在真实工程流程里把任务推进下去。

小 T：对。这次两轮自平衡车案例就能说明这一点。MWORKS AI 能生成初版模型、调用计算脚本、分析报错、建议接口适配；但工程师仍然要确认物理参数、状态顺序、控制参数一致性和动画展示效果。

小 M：所以 MWORKS AI 不是替工程师做所有判断，而是把工程师从重复搭建、查错、整理文档这些环节中解放出来。

小 T：对。MWORKS AI 负责加速执行，工程师负责定义目标、校正边界和审查结果。

小 M：这才是 MWORKS AI 和单纯 MCP 体验最大的不同：不是只把工具接上，而是把 AI 真正嵌入到 MWORKS 的工程工作流里。

小 T：没错。从 MCP 工具调用，到 MWORKS AI 原生嵌入，再到国产大模型和专业 Skills 支撑，MWORKS AI 正在变成一个面向科学计算与系统建模仿真的工程智能体。