推理层：法学硕士、代理人和MCP

面向系统集成商、OEM厂商和自动化工程师的实用指南 - 第二部分

与realvirtual.io 的首席执行官Thomas Strigl合作

作者简介：Thomas Strigl 是 realvirtual.io 的首席执行官，在仿真和自动化软件领域拥有超过 18 年的经验。

点击此处阅读本电子书系列的第一部分。从可视化到行动：Unity、机器信息系统、人工智能代理和工业数字孪生。

本电子书系列的第一部分介绍了现代机器信息系统背后的架构基础：将实时机器信号、MES 环境、结构化文档和空间3D界面融合到一个单一的操作界面中。它还探讨了新的欧盟机械法规和资产管理框架 (AAS) 等新兴标准如何推动机器文档向结构化、机器可读格式发展。这些基础——组件链接数据、版本化文档和上下文相关的机器状态——使得人工智能代理和大型语言模型能够在工业环境中使用。

本电子书系列的第二部分也是最后一部分，在此架构的基础上，探讨了“基础层”：人工智能系统如何访问可靠的操作和文档上下文，以及 MCP 等协议如何融入机器信息系统堆栈。

接地问题

在工业环境中引入大型语言模型的一个常见方法是将聊天机器人添加到现有系统（网站、支持门户或HMI）中。实际上，这种方法存在局限性。

语言模型本身无法访问机器的实时状态、当前的生产订单或制造商的特定文档。如果没有这种背景信息，它的响应将基于训练数据，而这些数据可能是通用的、可能过时的，并且不太可能包含所讨论的特定机器。

这通常被称为接地问题。为了使 LLM 在工业环境中产生有用的输出，它通常需要对三件事进行结构化访问：机器的实时状态、相关的企业环境和制造商的文档。

第 1 部分中描述的四层架构与此要求基本吻合。信号提供当前状态。MES提供操作背景信息。文档提供权威的参考资料。3D场景提供了呈现这一切的空间框架。

MCP作为一种集成模式

模型上下文协议 (MCP) 是一个开放标准，它定义了如何以一致的方式将工具和数据源暴露给语言模型。它规定了客户端如何连接到服务器、服务器如何宣传其功能以及模型如何调用这些功能。尽管 MCP 最初是为通用开发人员工具而设计的，但这种模式可以很好地应用于工业集成，因为工业集成面临的根本问题——提供对一组异构底层系统的一致访问——与之类似。

大多数工厂都结合了来自不同供应商的 PLC、MES 系统、文档管理平台和历史数据库。如果没有标准层，每个新客户都需要单独与这些系统进行集成。使用 MCP，每个底层系统都可以封装在 MCP 服务器中一次，并通过任何兼容客户端都可以使用的统一接口对外公开。

对于工业数字孪生而言，以下三类MCP服务器尤为重要：

• 机器状态服务器，可公开实时信号值、报警状态、驱动位置和最近历史记录——由现有的信号层（OPC 买量、Beckhoff ADS、MQTT、S7 或基于 WebSocket 的流层）提供支持。
• MES 服务器公开订单、批次、KPI 和质量记录——由 REST API、消息代理或直接数据库查询提供支持。
• 一个文档服务器，公开结构化的数字文档集——操作说明、原理图、符合性声明、软件版本、维护程序——可通过组件 ID、故障代码或自然语言进行搜索和检索。

连接到这三个服务器的 LLM 具有可靠的响应基础。诸如“为什么 3 号生产线停止运行？”之类的问题可以通过读取报警状态、识别受影响的组件、从手册中检索相关的故障排除部分，并在3D HMI中突出显示受影响的组件来回答。输出结果基于实际系统，而不是基于模型的训练数据。

本电子书系列第 1 部分第 6 节中描述的参考架构直接应用到这一层。那里描述的信号、MES 和文档服务由 MCP 服务器封装，并通过一致的接口公开这些服务。根据客户的数据策略，LLM 或代理运行时（在本地、边缘服务器或私有云中运行）连接到这些服务器。最终的回应依据当前状况、当前背景和权威文件。

3D HMI位于堆栈的顶端，服务于两个用户：操作员和任何基于 AI 的工具。AI 工具既将其用作呈现界面（突出显示与响应相关的组件），也将其用作确认界面（显示建议的操作以供人工审核）。该HMI使用Unity编写，涵盖运行时将使用的 CAD 导入、运动学、信号映射和组件元数据，并以 Unity 原生版本交付，适用于桌面、平板电脑、AR/ VR或工业PC；或者以基于 Three.js 构建的浏览器3D HMI交付，适用于 WebGL 部署。同一个 Unity 创建的场景文件，以一致的组件 ID 导出为 GLB 格式，可以同时满足两种交付目标。

Unity 的开放 C# 环境支持直接托管推理——通过 Sentis 和 ONNX，正如电子书中所述。设计、模拟、部署：为什么Unity对工业Digital Twins至关重要— 并充当外部运行时的前端。对于大多数集成项目而言，将代理运行时与HMI分离是一种更简单的方法，MCP 提供集成边界。

文件记录和基础

监管方向与地面LLM输出的技术要求之间存在明显的重叠。

从历史上看，文档一直是一种交付成本——因为需要而制作，但很少被查阅。根据(EU) 2023/1230 号条例，文件可以以数字方式交付，并且当以数字方式交付时，必须结构化、在线，并至少在机器的使用寿命内（通常是后者）进行生命周期维护，因为工业机械很少在法规规定的最低期限内报废。一旦文档采用这种形式，它还具有使其成为语言模型基础材料的特性：它是结构化的，可以通过组件或故障代码进行识别，并且具有制造商的权威性。

基于制造商实际交付文档的LLM不太可能产生不准确的程序或捏造的零件编号，因为它的响应可以追溯到特定的文档部分。这可能也与可审计性以及与该法规针对安全相关软件引入的日志记录和决策记录义务的整合有关。

对于集成商而言，实际观察是，准备结构化数字文档的工作（无论如何都需要）也会产生一种可用于构建基于 LLM 的工具的工件。这两项工作是相互重叠的，而不是争夺各自的预算。

法学硕士作为发展加速器

降低整合工作的成本

到目前为止，讨论一直将 LLM 视为数字孪生数据的消费者——读取实时状态、查询文档和响应操作员的工具。还有第二个角色，它对整合者的经济学有着更直接的影响：LLM 作为双胞胎自身发育的加速器。

构建集成数字孪生体涉及大量技术上不复杂但耗时的工作。信号层和3D场景之间的适配器代码。MES 的 REST 或 OPC 买量客户端。PLC变量与组件ID之间的映射表。HMI中的项目特定图表、仪表板和小型用户界面组件。架构设计旨在使文档部分与场景中的组件保持一致。这些任务都不算特别难；它们都是手工的、重复性的，而且是针对特定项目的。

LLM 辅助编码工具可以减少此类工作所需的工作量——为新的 MES API生成适配器、搭建图表组件、绘制信号表和运动学层次结构之间的映射。其结果并非集成商停止编写代码，而是日常集成工作所需时间减少。这在工业领域很重要，因为大量的小型、特定于项目的粘合代码历来是集成项目成本高昂的主要原因之一。

为什么标准化接口很重要

当底层接口标准化时，这种效应会加剧。与临时定制的 API 相比，公开机器状态、MES 数据和文档的 MCP 服务器更容易成为 LLM 辅助开发的目标。标准化接口与LLM辅助开发的结合降低了构建集成数字孪生的门槛。

LLM生成代码的局限性

有两个局限性值得注意。LLM 生成的代码是草案，不是最终交付成果；对于安全相关或控制系统代码，审查和验证流程与任何其他代码相同。而且这种加速主要适用于集成和可视化工作，而不是底层控制逻辑，底层控制逻辑仍然是自动化工程师使用现有工具的责任。

将创作与运行时交付分离

在这种情况下，一种有用的架构模式是将创作环境与交付的成果分离。创作环境是Unity一个成熟的工业数字孪生平台，用作编辑器，机器制造商可以在其中导入 CAD、定义运动学、配置行为模型并将文档链接到组件。Unity提供了工业项目所需的深度工具、CAD 导入流程、运动学和物理支持以及多平台构建目标。然而，交付的工件会在客户的环境中运行，直至机器报废，并且受益于其开放性和自托管性：一个基于浏览器的查看器，构建于标准 Web 技术（Three.js、TypeScript）之上，使用标准场景格式（GLB）。realvirtual.io 网络查看器，其基于 Unity 的创作堆栈为 AGPL 许可的开源网络运行时提供支持，是目前生产环境中这种模式的一个例子。

对工业4.0的更广泛影响

综合来看，这些影响对工业 4.0 具有更广泛的意义。集成项目面临的一个常见障碍是将异构系统拼接在一起的成本。随着成本的下降，数字孪生作为集成平台变得更具吸引力——它不仅是一个可视化产品，更是信号、企业数据、文档和可视化融合的平台。对于系统集成商而言，数字孪生的更持久作用在于：它本身并非一种交付成果，而是所有其他事物汇聚之处。

一线销售人员——一个光谱

“代理人”一词涵盖了一系列风险状况截然不同的行为。最好具体说明指的是哪一方面。

• 受限程度最高的是只读诊断工具。他们观察状态，阅读文件，并回答问题。它们不向控制系统写入数据。操作员询问某条线路为何停止运行；系统读取报警状态，在手册中查找代码，并进行解释。这是一个合理的起点，并且对于许多使用场景来说，也是一个合理的终点。
• 中间是咨询工具。他们会观察状态并提出行动方案——设定点变更、维护任务、参数调整——但不会执行这些方案。操作员确认或拒绝每个提议。3D HMI可以作为确认界面，在进行任何写入操作之前，显示受影响的组件和建议的空间上下文变化。这种模式既保留了决策过程中的人类判断，又利用人工智能辅助进行诊断。
• 限制最少的系统是那些无需人工逐个批准即可向 PLC 写入数据、更改配方或调度订单的行动执行系统。在某些情况下，这在技术上是可行的，但在新的机械法规下，这引入了额外的考虑因素。根据附件三，网络安全现在是一项重要的健康和安全要求，而基于人工智能的安全功能明确属于该法规高风险机械清单的范围，需要更严格的合格评定。任何允许 LLM 驱动的系统向控制系统写入数据的路径也是潜在的攻击路径。此类系统通常需要像任何其他具有写入权限的控制系统组件一样进行精心设计，包括法规为安全相关软件引入的日志记录和数据记录义务。

早期项目的常见做法是默认只读，然后扩展到需要操作员明确确认的咨询功能，并将任何操作能力视为控制系统组件，接受与 PLC 代码相同的审查和验证。

对于集成商来说，这是一个实用的起点。

对于正在考虑从哪里入手的集成商来说，循序渐进的方法往往比雄心勃勃的方法效果更好。

一个切实可行的初步实施方案可以包括：

• 利用现有的机器项目：首先，选择一台已经配备3DHMI)的机器，并根据 (EU) 2023/1230 号条例准备结构化文档包。
• 通过 MCP 服务器公开文档：将文档集封装在一个支持按组件 ID 检索的 MCP 服务器中。
• 将3DHMI连接到文档服务：配置现有的3D HMI，以便选择组件时自动检索相关的手册章节。
• 添加一个基于现实的AI界面：使用基于文档 MCP 服务器的通用 LLM，在3D视图旁边引入聊天面板。

预期结果

最终得到的机器可以让操作员提出问题，得到引用制造商文档的答案，并在3D视图中看到突出显示的相关组件。没有控制状态，没有自主行动，也没有新的自动化基础设施。其益处——减少支持电话、提高首次修复率、更容易获取制造商知识——是可以衡量的，而风险是有限的。

对于想要了解此类系统在实践中实际效果的集成商，可以在 web.realvirtual.io/demo 上观看基于浏览器的3D HMI实时信号数据公开演示。底层架构Unity作为创作环境，开放的 Web 堆栈用于交付，以及 Gitea 等标准版本控制系统用于在十年监管期限内存储交付的软件包——是集成商可以采用并适应自己项目的模式。

从这个起点出发，可以逐步添加后续步骤。信号层 MCP 服务器允许查询实时状态。通过MES连接，可以查询有关当前订单的信息。在3D HMI中，通过操作员确认的咨询建议可以进一步扩展系统，而不会改变其基本风险状况。每一步都可以单独进行测试和逆向操作。

支持合规性和人工智能的架构

上一本电子书的结尾指出，数字孪生既是一项组织投资，也是一项技术投资——例如，虚拟调试只有在周围的流程愿意改变时才能带来价值。类似的观察也适用于此。

目前两条时间线正朝着集成商的方向汇合。机械法规自 2023 年起就已为人所知，但为 2027 年 1 月 20 日的实施日期做准备的实际工作——包括强制性的新网络安全规定，以及现在明确提出的具有生命周期维护的结构化数字文档选项——正在从规划阶段过渡到执行阶段。与此同时，人工智能工具也催生了对结构化、有依据的数据的需求。这些可以作为单独的项目来处理，但其基本工作有很大的重叠之处。第 1 部分中描述的四层架构既支持操作员，也支持以后添加的任何 AI 工具。为遵守监管规定而准备的结构化数字文档也可用作基础材料。3D HMI可以作为所有这些功能的统一界面。

第 1 部分中描述的运营优势——更快的诊断、更低的专业知识门槛、情境化的信息传递、有意义的远程支持——无论监管环境如何，都适用。欧盟以外的集成商，或者从事机械法规未涵盖的系统工作的集成商，可以从相同的架构中获得相同的运营优势，而无需受到监管期限的强制约束。该架构本身就具备运行可行性；法规只是明确规定了欧洲市场的实施时间。

自主运行并非首要交付成果。更现实的出发点是，一台操作员可以查询、集成商可以支持、制造商可以使其在十年监管期限内保持最新的机器。制造这种机器所需的工具和标准已经存在，而且大部分基础工作无论如何都是集成商必须完成的。