要是在一年前有人说拿GPT-4直接去控制一台空调我大概率会觉得这是个博眼球的玩具Demo。但当我顺着微软展示过的“LLM工具调用”免训练思路在仿真的环境里把一整套控制链路搭起来之后我对这件事的看法完全变了它不是在整活而是把大模型往工业控制的方向上结结实实推了一把。所谓“免训练”说白了就是不改GPT-4的任何一个权重也不在设备数据上做微调而是靠函数调用Function Calling、场景化提示词和结构化的设备描述让模型在推理过程中自己决定“该调哪个设备、该改哪个参数”。用大白话讲就是不让模型死记硬背你的工厂工艺而是让它在现场看说明书干活。这个思路对工业控制意义很大因为工厂里的设备型号、通信协议、工艺规则五花八门你不可能为每个现场都训练一个专用模型但你可以用同一套免训练框架去适配不同的控制需求。这篇文章我想写给两类人一类是正在折腾LLM应用落地的工程师想看看大模型除了写代码、做问答之外怎么跟物理设备发生真实交互另一类是做自动化集成的朋友想评估这玩意能不能降低一点组态和脚本开发的工作量。我会把架构原理、代码级的实现链路、我在实际搭建时踩过的坑以及它在工业现场真正的边界都掰开讲清楚。1. 免训练控制为什么说这是LLM进入工业控制的正路1.1 传统工业控制到底痛在哪里传统工业控制的现场实现通常是一条“需求 → 流程图 → PLC程序 → 现场调试”的链路。控制逻辑一旦固化后续要改一个设定值范围、加一台设备、换一种工艺参数都要动代码、重新下装、重新验证。这个过程不是写代码本身难而是需求沟通和现场适配的成本特别高。举一个很常见的场景车间主任说“夏天太热了把空调调低点”维护工程师需要把这句话翻译成“设定温度24℃、风速高速、制冷模式”这样一个具体的控制指令然后去触摸屏或SCADA里翻菜单、找参数、下命令。如果现场有三台不同品牌的空调每个品牌的操作界面还不一样工程师就得分别处理。这种“人肉翻译和适配”的过程恰恰是LLM最擅长替代的环节。传统方法还有一个更结构性的痛点控制策略是预先写死的处理不了语言层面的模糊表达。“有点热”“太闷了”“后半天凉快点”这类自然语言在传统控制系统里根本没位置。你要么把它们固化成几档按钮要么靠人工介入。LLM的价值就在于它能够把这种不精确的、上下文相关的意图映射到精确的设备参数上。1.2 免训练的核心逻辑上下文学习加函数调用免训练方法能成立靠的是两个机制。第一个是上下文学习In-Context Learning。GPT-4在推理时能读懂你塞给它的系统提示和工具描述然后照着这个临时约定输出结果。你不更新它的权重它就靠着当前这段对话里的“说明书”来理解任务。第二个是函数调用Function Calling。OpenAI在GPT-4的接口里专门给模型开放了“决定调用哪个函数并填好参数”的能力模型不是输出一段文本让你自己解析而是直接输出一个结构化的函数调用请求。这两个机制加在一起就构成了一个非常实用的控制闭环对话上下文里放着设备能力描述、当前状态和安全约束模型根据用户的自然语言指令决定调用哪个控制函数并填好参数。整个过程不需要训练数据、不需要微调甚至不需要GPU资源来做模型训练只需要一个API和一套精心设计的“设备手册”。从这个角度看免训练并不是“偷懒”而是刻意选择。工业控制的场景碎片化极其严重每个工厂的设备组合、控制需求都不同如果每个项目都要微调模型光是数据标注成本和版本管理成本就会把项目拖死。免训练方法把复杂度从“训练模型”转移到了“设计上下文和函数描述”上而后者是可以沉淀成标准化工具的。1.3 为什么偏偏是GPT-4而不是其他模型我是从今年开始认真对比不同模型在工具调用上的稳定性的。结论是GPT-4在“根据函数描述输出正确参数”这件事上目前仍然有明显优势。最直观的表现是它对枚举值范围、参数默认值、甚至中文单位表述的理解都更准确很少出现把风速填成“high高”这种半中半英的脏数据。而一些开源模型虽然理解能力在追赶但在遵循复杂工具约束时还是容易把参数类型搞错或者在JSON里塞进去多余字段。当然并不是说开源模型不能做。如果控制场景比较简单函数只有两三个参数都是布尔或整数那么经过优化的小参数模型完全够用甚至可以用ONNX格式部署到现场边缘盒子。我甚至还特意去看过Open LLM Leaderboard上的榜单想找找有没有更适合离线部署的替代品但测试下来免训练控制的效果跟模型对工具文档的遵循能力强相关短期内GPT-4这个级别的大模型还是最省心的选择。后面4.1节我会给出一套可替换模型的思路。2. 架构拆解LLM究竟怎么“握”上空调的手2.1 设备抽象层把Modbus协议变成LLM看得懂的API很多人一听到LLM控制工业设备第一反应是“让GPT-4直接去读Modbus寄存器”。这个想法很危险GPT-4根本不认识线圈和保持寄存器更别说不同类型寄存器的大小端和缩放系数了。真正要做的是在设备和LLM之间加一个设备抽象层把Modbus、BACnet、PLC变量这些底层通信细节统统封装成一组语义化的控制函数。举个例子空调的原始控制可能是往某个Modbus地址写入一个16位整数值0x00EE表示设定温度但要乘以10才是实际温度。这个转换逻辑绝对不能暴露给GPT-4。抽象层要做的是暴露一个名为air_conditioner.set_target_temperature(temperature)的函数参数直接就是整数摄氏温度返回值直接就是当前室温。模型不需要知道协议不需要知道寄存器地址只需要知道“我调的是温度”。设备抽象层的另一个作用是把设备的能力范围限制住。空调只能制冷到16℃模型如果输出了12℃抽象层可以直接拒绝。这样的校验不应该放在提示词里靠模型自觉而应该放在函数的真正实现里靠代码强制执行。2.2 领域本体让模型知道“我是谁、我在控制什么”热词榜单里常看到LLM Ontology和LLM Wiki以前很多人觉得是花架子但做工业控制时会发现本体结构是真的有用。所谓领域本体就是一套对设备和环境的规范化描述设备有哪些类型、每个设备有哪些属性、属性可取什么值、设备之间有什么关系。放到空调控制的例子里本体要回答这么几个问题这台空调安装在哪个房间它支持制冷、制热还是除湿风速有哪几档当前设定温度是多少当前室温是多少这些信息如果一股脑全塞进提示词token会爆而且模型容易抓不住重点。更好的做法是采用RAGGraphRAG的思路把本体知识库拆成索引每次只把与当前设备相关的片段检索出来加进上下文。我在项目里把每个设备类型写成一段结构化的JSON描述然后用向量库做检索。用户说“会议室太热”系统先从知识库里检索“会议室”对应的设备清单和控制约束再把这些信息组装成发给GPT-4的系统提示。这比把所有设备的维保手册全文喂给模型要聪明得多。2.3 安全壳与执行校验免训练不代表免约束免训练方法最容易被质疑的地方就是可靠性。GPT-4是一个概率模型它可能在大部分情况下输出正确参数但偶尔也会犯离谱的错。工业控制最不能接受的就是“偶尔犯离谱的错”所以整个架构里最重要的部分不是我前面说的函数描述而是LLM和真实设备之间的那道安全壳。安全壳要做三件事。第一参数合法性校验温度范围、运行模式、风速档位都必须在枚举范围内任何超出范围的请求直接拒绝。第二变化量限制人说要“冷一点”模型可能会直接把温度从28℃调到18℃这不符合暖通的基本常识安全壳里要定义单次调节步长不能超过两度。第三人工确认通道对于首次出现的控制指令组合或者涉及设备启停的指令先推送给操作员确认再执行。这套安全壳写起来很简单但价值极高。它把LLM从“控制者”降级为“建议者”真正对设备安全负责的仍然是确定性代码。我在仿真环境里故意让模型输出各种非法参数无一例外都被安全壳挡下来了这比提高提示词约束可靠得多。3. 从指令到动作一个控制空调的完整链路3.1 用户意图怎么变成结构化参数我搭的Demo是一个模拟会议室环境里面有台“虚拟空调”状态量有当前室温、当前设定温度、运行模式、风速。整个控制链路的起点是一句自然语言请求用户说“会议室太热了赶紧给我凉下来。”系统拿到这句话之后先把当前环境状态组装成一段上下文大致长这样{ current_room_temperature: 29.5, current_setpoint: 26, mode: cool, fan_speed: medium, room_name: 会议室A }同时系统提示词里写清楚当前的规则约束“山间会议室温度建议控制在24到26℃单次调节幅度不超过2℃仅在有人在场时允许开启制冷。”这些约束既是给模型的也是给后续安全壳做强制校验的。在这个上下文基础上GPT-4要做的就是判断“太热了”该对应哪一个函数、填什么参数。这步本质上是一个意图识别加槽位填充任务但GPT-4处理起来比传统的意图识别模型自然得多因为它能结合当前温度和用户的语气做推理。用户说“赶紧凉下来”模型的合理输出就是把目标温度设定为24℃风速调到高。3.2 函数定义与模型决策的交互方式为了让模型能做出这个决策我们需要把控制函数用OpenAI要求的JSON Schema格式描述出来。我在项目里实测下来函数描述里的description字段起着决定性的作用。写清楚每个参数的含义、取值范围、枚举值和触发条件模型的输出精度会明显上升。下面是实际使用的函数定义{ name: air_conditioner.set, description: 设置空调的目标温度、运行模式和风速档位。仅在安全检查通过后执行。, parameters: { type: object, properties: { target_temperature: { type: number, description: 目标温度单位为摄氏度允许范围16到30, minimum: 16, maximum: 30 }, mode: { type: string, enum: [cool, heat, fan, auto], description: 运行模式cool为制冷heat为制热fan为送风auto为自动 }, fan_speed: { type: string, enum: [low, medium, high], description: 风速档位low低风medium中风high高风 } }, required: [target_temperature, mode, fan_speed] } }调用OpenAI接口时把这段函数定义放进functions参数模型在需要控制设备时就会返回一个function_call对象里面包含函数名和已经填好的参数。整个过程不需要任何微调也不需要自己写解析器模型输出的JSON直接用Python的json.loads就能读进来。3.3 执行反馈与闭环修正设备执行完指令后抽象层会返回一组最新的状态数据比如“当前室温29.5℃设定温度24℃风速高”。这个结果要再次交给GPT-4让它生成给用户的自然语言反馈或者判断是否还需要进一步调整。闭环修正在我的仿真里出现了很有意思的表现。用户继续说“还是有点热”系统拿到的新状态是室温已经降到27.8℃但人体感觉还是热于是模型会根据新的室温判断是否再次调用控制函数。这正好符合我们在实际控制里常说的迭代逼近不指望一次指令就调到位而是通过多次反馈逐步收敛到目标舒适区间。不过这里要特别提醒一个弊端。LLM调用一次要两三秒闭环修正意味着用户每说一句话都要等两秒以上在多轮对话里体验会变得拖沓。所以我做了个折中模型在决策时除了“立即修改参数”之外还可以选择“继续保持当前设定并观察”把一部分迭代交给传统PID或者空调自身的控制器LLM只负责更高层的调度。4. 实操要点怎么在你的设备上复现这套控制4.1 环境准备与选型建议如果你想跟着做一遍我建议先用仿真环境跑通链路再接真实设备。我用的核心组件是一个装了OpenAI SDK的Python 3.10环境一台能跑Node-RED或者Modbus TCP模拟器的电脑再加一个用来模拟空调状态的简单状态机。选型上我给三点实测建议。第一接口优先选支持Function Calling的GPT-4系列实测下来对函数遵循的稳定性明显更好等模型回复时能少一点意外。第二设备模型状态不要直接存在内存里建议落到SQLite或者Redis里方便你观察每次控制前后的变化。第三如果你是接真实设备强烈建议先用Modbus TCP模拟器调试把函数调通的再接PLC或DDC控制器一步到位接真实物理设备会非常难排查问题。如果你要考虑开源模型也可以但要准备好做两件事一是写更长的few-shot示例给模型展示更多“输入输出对”来弥补函数遵循能力二是把设备抽象层的调用方式改得更死板比如不要用开放式的自然语言描述而用固定的模板填充。开源小模型在边缘盒子上用ONNX部署是可行的但控制精度确实会下降我建议用于辅助建议不要用于全自动控制。4.2 完整可跑的核心流程主流程没什么高深的东西就是构造消息、调用接口、解析函数调用、执行、返回状态。核心的伪代码流程如下组装系统提示词内容包含当前环境描述、设备状态JSON、安全规则和“你是空调控制助手”的角色说明。发起一次ChatCompletion请求在参数里带上定义好的functions。拿到响应后判断是普通文本还是function_call。如果是函数调用就把里面的参数提取出来交给安全壳校验。校验通过后调用真实的设备抽象层函数得到最新状态。把执行结果作为一条新的消息追加进对话上下文再请求模型生成最终回复。把最终回复展示给用户。我强烈建议把这七步封装成一个AgentRuntime类不要把它们揉在一个大函数里。因为后续你要加权限校验、加日志、加人工确认如果流程是面条代码后面改一次就要崩一次。下面给出一段简化的核心实现方便你理解函数调用的逻辑import openai import json functions [{ name: air_conditioner.set, description: 设置空调的目标温度、运行模式和风速档位。, parameters: { type: object, properties: { target_temperature: {type: number, description: 目标温度}, mode: {type: string, enum: [cool, heat, fan, auto]}, fan_speed: {type: string, enum: [low, medium, high]} }, required: [target_temperature, mode, fan_speed] } }] def run_agent(user_prompt, system_prompt, device_state): messages [ {role: system, content: system_prompt}, {role: user, content: user_prompt \n当前状态 json.dumps(device_state, ensure_asciiFalse)} ] response openai.ChatCompletion.create( modelgpt-4, messagesmessages, functionsfunctions, function_callauto ) msg response[choices][0][message] if msg.get(function_call): fn_name msg[function_call][name] args json.loads(msg[function_call][arguments]) return call_function, fn_name, args return reply, msg[content], None这段代码在早期版本里跑得很稳后来我加上了安全壳和日志后就变成了一个能持续运行的控制代理。4.3 实测中的坑token、幻觉与时延我把这几个月在里面踩过的坑整理成了一张速查表很多问题在官方文档里根本不会写。现象原因处理方式模型把温度参数填成-5模型对“凉”的理解过于激进安全壳强制范围校验并设置单次步长上限描述设备的上下文太长直接超出token上限把所有设备手册一股脑塞进prompt用RAG检索设备相关片段按需注入模型偶尔不返回function_call而是直接输出一段废话系统提示语气太开放引导不足在提示词末尾明确“必须调用工具来修改设备”多轮对话后上下文越来越大请求越来越慢历史消息全量携带只保留最近两轮历史摘要作为文本放进去用户说“稍微降一点”结果模型输出16℃缺少对“微调”的语义约束在系统提示里写清楚挡位与语义映射印象最深的一次是我发现提示词里只要出现“你可以自由控制温度”这类话GPT-4就会特别放飞自我。后来我把系统提示改成了“你是一个操作员助理只有在上位系统允许的范围内才能建议参数最终执行由安全壳决定”模型立刻变得保守了。并不是GPT-4能力不行而是你的角色设定和约束表述直接影响它的谨慎程度。这算是免训练方法里最值得琢磨的经验。时延问题也需要重视。一次GPT-4调用在2到5秒之间这还不包括网络波动的可能。如果设备控制要求秒级响应这套架构在纯在线模式下是不可用的。我的妥协方案是拆成两层确定性控制回路继续由传统PLC执行LLM只负责“设定值调度”和“异常工况解释”这样既保留了自然语言交互的便捷性又不牺牲实时性。5. 影响范围与实际边界LLM在工业控制里到底能走多远5.1 对工业软件形态的影响从“操作界面”到“对话界面”我之前一直觉得SCADA和HMI里的图形组态很难被替代但做完这个Demo之后想法有些松动。传统的组态界面是把所有操作都做成人能看懂的按钮、图表和参数面板好处是直观坏处是每次新增功能都要重新组态。而LLM控制方案直接消灭了中间层用户不需要在几十个画面里找控制入口只需要说一句“把三号车间的空调调低两度”。这不是说HMI会立刻消失而是说HMI会慢慢退居为“确认通道”和“可视化通道”。模型负责理解意图和生成控制建议界面负责展示建议、接收人工确认、展示执行结果。对工业软件厂商来说这是一个把“功能操作”迁移到“语义交互”的窗口期对集成商来说这意味着多了一个用自然语言快速构建上层应用的选项。5.2 对工程师角色和能力结构的影响控制工程师过去的核心技能是看懂梯形图、写ST语言、搞懂寄存器映射。这套技能仍然重要但未来还需要多一项能把设备的操作逻辑翻译成LLM能理解的API描述和提示词约束。说白了以前是让人去适应机器现在是让模型去理解人然后人把核心规则提炼出来交给模型。我在实际调试中有个特别明显的感受跟GPT-4打交道就像带实习生你得提前把规矩讲清楚。哪些能碰哪些不能碰参数范围多大变化幅度多快这些原来写死在程序里的东西现在要写进提示词和安全壳。这个过程对工程师的要求不是低了而是更高了你得真正理解自己设备的安全边界才能把它抽象成模型能遵守的规则。5.3 边界在哪里什么能控什么绝对碰不得目前看LLM控制在以下几个场景里是能落地的设备参数调度、多设备协同建议、运行日志分析、操作员培训模拟。这些场景的特点是允许人来确认、允许延迟、允许失败后覆盖。反过来以下场景我劝你碰都不要碰需要毫秒级响应的安全联锁、直接影响人身安全的保护逻辑、以及任何“一旦误动作就会导致严重后果”的闭环控制。免训练方法的最大价值不是替代现有控制系统而是补齐了“自然语言到控制语义”之间的空缺。控制器还是原来的控制器安全回路还是原来的安全回路只是在最上层多了一个能听懂人话的协调者。这才是LLM迈向工业控制最合理的姿态。我个人的体会是做这个项目最大的收获不是实现了什么“AI控制空调”的高大上效果而是弄明白了一件事大模型进工业不是靠拍脑袋替代谁而是靠把人和设备之间的沟通成本真正降下来。哪怕只是省掉了让维护工程师翻手册、找菜单的几分钟对于频繁变化的现场工艺来说也已经值回票价了。后面如果再有人问你“GPT-4能不能控制设备”你可以直接告诉他能但前提是给它一套可靠的安全壳和一本写得足够清楚的设备说明书。