当前位置：首页 > news >正文

使用工业自动化的功能块实现大语言模型应用

news 2025/7/12 12:04:48

大语言模型无所不能？

以chatGPT为代表的大语言模型横空出世，在世界范围内掀起了一场AI革命。给人的感觉似乎大模型语言无所不能。它不仅能够生成文章，图片和视频，能够翻译文章，分析科学和医疗数据，甚至可以实现推理，富有情感，控制机器人等等。令人眼花缭乱。

如果让大模型尽情地发挥想象力，也许它的确能够回答，但是如果指望它准确地回答问题，就要求它富有逻辑性地思考。前提是人类的问题和提示也需要具有逻辑性。加以正确地引导。

事情并非如此

大模型真的如此神奇么？了解真相的最好办法就是亲手去试试。2024年以来，我先后测试了openai，文心一言，kimi，零一万物，千问，llama-3 等各种大语言模型。同时尝试学习使用langchain 库编写了python和nodeJS 的大语言编程。实现了各种的RAG，Agent ，langGraph 等应用范式。给我的总的印象是：

与语言相关的应用令人惊艳

大模型强大的文字生成能力令人映像深刻，写一首诗信手拈来，尽管没有多少绝句，也算是中规中矩。

文章翻译，润色，总结也表现出色。大模型上知天文地理，下知鸡毛蒜皮。知识渊博令人乍舌。似乎一下子原来感觉高不可攀的搜索引擎公司突然感到背脊骨阵阵寒风，岌岌可危了。

大模型同时展示了编写程序都表现出非凡的能力。以至于许多认惊呼码农未来要丢饭碗了。

结合我自己熟悉的领域，我使用大模型生成工业自动化领域的信息模型，例如OPC UA 的信息模型，工业4.0 的资产管理壳（AAS）模型收到比较好的效果，只要使用自然语言描述一个设备的信息属性，就能够自动生成符合OPCUA 规范的XML OPCUA 模型。这将大幅度地提升构建各种信息模型的效率。

推理，智能体（Agent），工具使用牵强人意

如果AI 仅仅停留在通用知识对话，生成文本的程度的话，大语言模型的作用就太狭隘了。随着大语言模型的演化，人们惊喜地发现，大模型涌现出了人类智慧的能力，比如推理，使用工具以及构建自主智能体（Agent）的超强能力。给人们留下了无限的想象空间。但是，这些”涌现“无法使用数学证明其内部的机理。大模型演变成为遵循大力出奇迹原理（scale law ）的黑匣子。

在我看来，大语言模型应用技术越来越基于生物学家的方式在进行。难以解释生命的全部奥秘，只能尝试生命的某些特征。使用各种提示和流程来测试大语言模型的各种潜在特征。给我的感觉是，写大语言模型应用程序很像训练自己家的狗。采用各种各样的语言，身体动作来训练狗做动作。反正变着法子来。有时候晚上训练的不错，明天却又不灵了。

人们也提出了各种训练秘籍，例如提示工程，zero shot react，Tools 等等方式。其实大多数是训练宠物的方式，大模型不灵也是白瞎。

近一段时间以来，我也做了一些尝试。编写了基于langchain 的各种大模型方法。它们包括：

memory
Agent
Function Call
React
RAG

作为一个大模型的菜鸟，我依葫芦画瓢地写了基于python 和nodeJS 的应用。同时也分别测试了下面几个大模型

openai
本地 llama-3
文心一言
kimi
零一万物

初步实验的结果并不理想。主要表现在：

大模型的推理能力并不强有时候会不断地在Action Thought Observation兜圈子。
工具经常用错
momory 保存了对话的输入和输出，有时候会干扰大模型的判断。
对于简短的对话输入往往与矢量数据库中的内容无法进行相似度匹配。

使用的结果表明 openai （GPT-4）表现最好，但是也不理想。

思考

江南的清晨，我坐在窗口，望着烟雨茫茫的太湖。不仅陷入的沉思。。。难道人工智能就这么一个投资巨大，消耗能源惊人的黑匣子么？人类千百年来创造的哲学，科学方法，数学，信息技术的终结目标就是这么一个”怪胎“？显然不应该如此。于是顿悟，大语言模型应该与已有的科学技术相融合，而不是取代。人类积累的宝贵技术，科学和经验能够让大语言模型发挥更强的威力。它们将相互成就。

其实，对于特定的大语言模型应用而言，完全可以由人类预先设定处理的逻辑。就像我们编写应用程序那样处理。类似ReAct 方式，我们完全可以使用传统编程的方式编排出来。何必劳神大模型费力费钱呢？说到这里，不由得想起几年前学习神经网络时的经历，当是我就使用复杂的数学公式训练了一个神经网络模型。好像是一个滤波器。训练了5 万步之后，仿真的值非常出色了。但是既然有了滤波器公式，没有必要额外地训练一个神经网络。

让大模型做它最擅长的事情，用传统的IT/OT 技术来做其它。这才是正确的方法。

大语言模型与IT/OT技术的融合

我并没有研究和使用各种LLM 应用架构。主要使用的是langchain。感觉这样的架构过度地依赖大语言模型的能力。尽管langchain 提供了一些语言处理的模块，使用链（chain）连接运行，后来又提出了langGraph ，似乎想导入图形程序设计方法。但是并不像传统IT技术中的图形程序设计方法那么灵活。Agent 的概念也是如此，所谓的ReAct 模式是预先编排好的，完全是依靠大模型的推理能力来实现Action-Thought-Observation和工具的使用，存在很大的不确定性。

基于本人近年来研究开放自动化系统的经验。我认为完全可以采纳类似基于模型的设计思想来构建大语言模型的应用程序。比如使用工业控制领域的PLC 功能块（IEC61131-3）和IEC61499 基于事件功能块，功能块网络等建模设计思想。与工业控制领域的功能块不同的是大语言模型的功能块处理的是自然语言为主。并且通过大模型来确定输出的路由。于是，我提出了一套LangFunctionBlock 的概念和架构，实现大模型的Agent。

逻辑学和形式逻辑的重要性

人类语言大多数是含糊不清的，没有逻辑的。我们也不知道人类是如何相互理解的。为了能够精确地表达。人们提出了逻辑学和形式逻辑语言。形式逻辑系统的目的是追求精益求精。数学和计算机程序都是一种形式化语言。

逻辑学是确定性推理的基础，而形化语言是确定性描述事物的工具。大语言模型是基于自然语言训练出来的。它显然更容易理解具有逻辑的形式化语言。但是这并不代表它能够准确地理解任何自然语言。如果人类能够准确地理解自己的语言，逻辑学和形式语言就没有存在的必要了。

因此，如果需要让大模型构建确定性AI，做出确定的操作，需要转换成为形式化逻辑语言。使用IT /OT 的逻辑处理。

第一步要判断用户的提问是否与IT/OT 系统相关，如果没有关系，就简单地让大模型做出回答，如果与IT/OT 相关，就提取形式化信息，转向IT/OT 模块处理。在这个过程中，还能够做出正确性检查。如果缺少某些信息，就回答”你没有提供XXX 信息，我无法执行。

对于特定的大语言模型应用，使用传统形式化技术来验证，推理和处理是可能的。

关于Agent

“Agent”是一个有着悠久历史的概念，在许多领域都得到了探索和解释。现在泛指具有高度自主性的智能实体。他可能是天然有机的，也可能是人工制造。比如在人类社会中处理法律的Agent，处理房产买卖的Agent等等，正是因为如此，经常将Agent 翻译成代理。

在人工智能领域提到的Agent，通常是指能够使用传感器感知其周围环境、做出决策、然后使用致动器采取响应行动的人工实体。 Agent 人工智能系统的基本构建块。

一群智能体可以理解为一组智能体在单个环境中共同共存，在该环境可以相互协作解决问题。

在AI 的研究过程中，人们提出了各种智能体模型，比如ReAct ，Zero-shot-React 等等。

最近Agent 的定义

Lilian Weng在其博文《LLM Powered Autonomous Agents》中，对基于LLM的AI Agent 做了系统综述。

原文地址：https://lilianweng.github.io/posts/2023-06-23-agent/

她将Agents定义为LLM、记忆（Memory）、任务规划（Planning Skills）以及工具使用（Tool Use）的集合，其中 LLM 是核心大脑，Memory、Planning Skills 以及 Tool Use 等则是 Agents 系统实现的三个关键组件，并对每个模块下实现路径进行了细致的梳理和说明。

智能体工作流 Agnetic Workflow

在今年的Sequoia Capital AI Ascent 2024大会上,著名人工智能专家Andrew N提出了一个很有趣的新概念——”代理工作流程(Agentic Workflow)”。

智能体工作流(Agentic Workflow)是与大型语言模型(LLM)交互和完成任务的一种新方法。传统上,我们与LLM交互时，会直接输入一个提示(prompt),LLM然后会基于这个提示直接生成一个输出结果。这种做法有点像让一个人一次性从头到尾写出一篇文章,没有反复修改和迭代的机会。

代理工作流则更像是将写作过程分解为多个步骤：首先是根据主题大纲写一个草稿，然后是对草稿进行分析、修改和补充，之后是进一步完善和润色,如此反复迭代,直到最终生成期望的结果。

在这个过程中,我们不是直接向LLM提出”写一篇文章”这样的指令,而是将任务分解为多个子任务，引导LLM按步骤完成每个子任务。每个子任务的输出将作为下一步的输入，以此循环往复。

Andrew 给出了四种常见的agent 设计模式。分别是Reflection、Tool use、Planning和Multiagent collaboration。

即使是较低版本的大型语言模型（如GPT-3.5），通过将任务分解为多个步骤并进行反复迭代优化，也能在解决复杂问题上达到超越一次性直接生成输出的卓越性能。

笔者看来，智能体工作流绝非这么几种，事实上设计智能体工作流，与我们编写程序非常地相似。应该具有许多的方式。使用传统程序设计方式会更灵活。我们可以借鉴工业自动化行业编写工业控制软件的方式来编排智能体工作流，比如IEC61499，IEC61131-3 的方式。

智能体推理设计模式

Agent 的本质

我们提出的系统架构

我们借用了IEC61499 事件功能块的概念，这样做的另一个意图是实现语言功能块和IEC61499 功能块的融合。 IEC61499 的基本概念包括：

基本功能块
复合功能块
功能块网络

与IEC61499 系统架构的区别

系统中保留了一个环境信息（Environment Information）这是一个全局变量区，大模型功能块会输出信息到该区域，由不同功能块共享访问。

在上述观点下，一个大语言模型应用程序是由由功能块网络和环境信息构建而成的。在langFunctionBlock 运行时（runtime）执行。

大语言功能块内部访问大语言模型，返回的结果可以做一些验证，保证回答的确定性。

大模型与IT/OT 的接口

大语言模型的输出如何与IT/OT 程序的正确接口对于保证系统的确定性是非常重要的，我们尝试在系统中引入了Tag 和关键字机制。首先通过大模型判断输入信息的Tag 或者关键字（Keyword）。对于简单的语句而言，大模型理解后输出Tag 或者Keyword 是十分轻松的。IT程序通过Tag来决定程序的转移。例如（使用kimi 的结果）

判断问题的类型

问：请问下面的内容是询问，还是描述？我喜欢吃番茄，简单地用“询问”或者“描述” 回答。

答：描述

问：请问下面的内容是询问，还是描述？我喜欢吃番茄吗？，简单地用“询问”或者“描述” 回答。

答：询问

同样地，我们也可以从信息中提取关键词，IT 程序能够通过关键词查询数据库或者跳转程序。就现在大语言模型的能力而言，这是非常可靠和确定的了。

提取问题中的关键词

问：提供你下面几个关键词：当前，时间，事件。请简单列出下面内容中包含的关键字。现在正在下雨。以数组形式输出

答：["当前", "事件"]

对于更复杂的情形，我们可以从自然语言中提取出一个json 或者XML 信息模型，供IT程序进一步处理，比如写入数据库。

调用工具

问：有一个工具ControlLight，当需要控制灯光时时调用，回答下面的问题，需要调用该工具吗？请打开灯。简单回答YES 或者NO

答：YES

问：工具ControlLight，当需要控制灯光时时调用。工具ControlAirCondition ，当需要控制空调时调用。回答下面的问题，需要调用该工具吗？请开空调。简单回答应该使用哪一种工具

答：ControlAirCondition

语言功能块（langFunctionBlock）

语言功能块是一种基于大语言模型的处理自然语言的功能块。这里我们借用了IEC61499 事件功能块的概念，这样做的另一个意图是实现语言功能块和IEC61499 功能块的融合。实现AI/IT/OT 的相互融合。也可以认为

主要属性

名称（Name)
类型(Type)
状态(Status)
大语言模型类型(LLM Model)
大模型提示(LLM Prompt)
- 针对不同的状态，可以定义不同的提示。

输入/输出：

事件输入
事件输出
数据输入
数据输出

事件IO

用于程序执行流程的引导，最基本的事件包括：

Excution
Finish
Error

数据IO

数据IO 我们在IEC61499 功能块的基础上做了一些扩展，可以传递JSON 结构化数据类型。

状态机

功能块内部维护一个状态机。可以实现更复杂的功能。

功能块内部的程序结构

语言功能块网络

多个语言功能块连接成一个功能块网络，完成大语言应用程序

复合语言功能块

多个语言功能块能够构成一个复合功能块。其内部是一个功能块网络。

AI与IT/OT 的融合

基于LangFunctionBlock 的系统架构的另一个优点是实现AI/IT/OT 的融合。我们完全可以将langFunctionBlock 和IEC61499 Event FunctionBlock 相结合，构成一个AI/IT/OT 结合的网络，实现AI/OT 应用。比如图像识别，机器人控制等复杂的场景。

实验平台

为了实验langFunctionblock 的想法，我们简单地搭建列一个实验平台：

基于Nodejs/Javascript
基于langchain库

App架构

实验-1 在零一万物大模型下实现工具调用。

为此我们构建了下面的功能块网络（以IEC61499 4Diac IDE 设计）

设计的功能块：

InputMessage

输入用户提问的功能块，当用户输入消息时。该功能块产生：

Output 事件
OutMessage 数据

应用程序通过 WriteData 和Execution 调用该功能块。

设置InputMessage和OutMessage功能块的主要目的是使功能块具有一个统一的入口和出口。

Basic

这是一个基本的功能块，将InMessage 询问大模型，回答输出到OutMessage

Tools

这是一个工具功能块，判断用户的输入信息和是否要调用两个工具 ControlLight 和 ControlAirCondition。然后调用相关的工具功能块。

ControlLight

这是一个普通的功能块，实现对灯光的控制。

ControlAirCondition

这是一个普通的功能块，实现对空调的控制。

OutputMessage

向用户回复消息。

从这个实验表明，即便是大模型没有支持Function Call 的功能（据我了解，到目前为止，零一万物大模型没有支持Function Call 的API）

处理流程

前端输入的用户提问，通过Post 发送给NodeJS 后端。
将用户消息写入InMessage 功能块，调用InMessage 功能块的Excution。
InMessage 将用户消息直接发送给Tools
Tools 判断是否要使用两个工具,ControlAirCondition 和ControlLight 如果需要的话，就转向相关工具的功能块，如果不需要调用工具，就调用基本功能块Basic 回答问题。
最好通过OutMessage 返回结果信息。

用户界面

代码示例

Tools功能块源代码

export class ToolsType{constructor() {    this.Type = "ToolsType";}CreateInstance(Parameters){//   console.log("Create BasicType Instance")return new Tools(Parameters)}
}class Tools {constructor(Parameters) {this.Name = Parameters.Name;this.Type = "ToolsType";this.model=Parameters.Modelthis.ModelType=Parameters.ModelType }static Prompt = "Point";async   Executive(runtime,EventType){if (EventType=="Invoke"){//  console.log("Invoke:---------"+this.ModelType)console.log(this.InMessage)const Prefix=`工具:ControlLight:当需要控制灯光时时调用。该工具有2个操作，Open 和Close。工具:ControlAirCondition ，当需要控制空调时调用。该该工具有2个操作，Open 和Close。 回答下面的问题，需要调用该工具吗？`const Suffix=`判断是否应该使用哪一种工具，要求直接输出结构化JSON 对象。JSON 格式为：{ToolName:"The Tool Name"Operation:"The Operation of the tool"}如果判断不需要使用工具，直接回答： {"ToolName":"NotUseTools"`const Prompt=Prefix+this.InMessage+Suffixconst completion = await this.model.chat.completions.create({messages: [{"role": "user","content": Prompt,}],model: this.ModelType,});const Content=await completion.choices[0].message.contentconsole.log(Content)                    const JSonContent=JSON.parse( Content.replace("```json\n","").replace("```",""))//   console.log(JSonContent)if (JSonContent.ToolName=="ControlAirCondition"){ this.Operation=JSonContent.Operationawait runtime.WriteOutputData({FBName:this.Name,DataName:"Operation",Value:this.Operation})runtime.EventNotify({FBName:this.Name,EventName:"ControlAirCondition"})}else if  (JSonContent.ToolName=="ControlLight"){this.Operation=JSonContent.Operationawait runtime.WriteOutputData({FBName:this.Name,DataName:"Operation",Value:this.Operation})    runtime.EventNotify({FBName:this.Name,EventName:"ControlLight"}) }  else if  (JSonContent.ToolName=="NotUseTools"){console.log("NotUseTools======"+this.InMessage)this.OutMessage=this.InMessage;await runtime.WriteOutputData({FBName:this.Name,DataName:"OutMessage",Value:this.OutMessage})await runtime.EventNotify({FBName:this.Name,EventName:"NotUseTools"})}else {this.OutMessage="抱歉，无法判断！"runtime.EventNotify({FBName:this.Name,EventName:"Finish"})}  }
}async WriteData(Name,Value){//  console.log(this.Name+" WriteData:"+Value)if (Name=="InMessage"){this.InMessage=Value;//  console.log(this.InMessag)}}async ReadData(Name){if (Name=="OutMessage")return this.OutputMessage;}
}

结论

对于大多数特定的AI 项目，能够使用IT 程序设计的方式来决定大模型应用的流程编排。

使用OT 领域的功能块实现大模型应用，有利于AI 与IT,OT 的融合，在机器人控制，物联网的到应用。

工业控制领域的功能块有利于将复杂的问题划分成小问题，一步一步地解决。小问题更容易回答正确。同时小问题的Prompt 能够表述更明确。

将复杂问题分解成为小问题，功能块只是回答单一的问题，这有利于使用本地小模型解决复杂的应用。不同的功能块可以调用不同的大语言模型。

本文只是记录了我的一些初步的尝试。还需要不断进一步实验和研究。感兴趣的读者可以共同探讨。