过去一段时间，我们一直在推进supOS-Free的应用生成Agent。很多用户第一次看到它时，最直观的感受是：输入一句需求，AI就能生成一个工业应用。
比如：基于现有数据，为包装产线生成一个设备OEE运行监控看板，展示设备OEE、运行状态、设备告警、运行时长和告警趋势。
Agent会根据需求生成对应的页面、图表和应用。但在我们看来，“会生成页面”并不是这件事最重要的部分。
真正决定工业应用生成能不能落地的，是另一个问题：AI怎么知道工厂里的数据是什么意思？
■PLC里的Tag001，AI本身并不知道它是什么
假设PLC中有这样一个数据：PLC01.DB03.Tag027=83.4
仅仅看到这一行数据，大模型并不知道83.4代表什么。它可能是温度，也可能是压力、转速、产量或者设备OEE。
所以，我们做应用生成Agent时，并不是把PLC原始地址直接扔给大模型，然后让AI自己猜。
在Agent开始工作之前，首先要解决的是：让工业数据变得可以被AI理解。这也是supOS-Free在整个应用生成体系中承担的重要工作。
■第一步，先把数据连接进来
工厂的数据通常散落在很多地方。PLC、仪表、传感器、数控设备是一类数据；MES、ERP、WMS、数据库又是另外一类数据。协议不同、格式不同、命名方式也不同。
supOS-Free首先负责把这些数据接入并统一管理。对于支持的工业设备和协议，可以通过平台内置的采集驱动进行软采；对于无法直接连接的设备，也可以结合网关、协议适配等方式完成数据接入。
这里也需要明确一个边界：应用生成Agent本身不负责直接采PLC。它使用的是supOS-Free已经接入、注册和管理好的数据。
完整关系是“现场设备/业务系统→supOS-Free→应用生成Agent”，而不是让大模型直接面对现场设备。
■第二步，让数据从“一个地址”变成“有含义的数据”
数据接进来只是第一步。如果系统里还是一堆Tag001、Tag002、DB03.Tag027、Value01，AI同样很难正确使用。所以supOS-Free中还有非常重要的一层：UNS建模。
例如，原来的一条数据是PLC01.DB03.Tag027=83.4。经过组织以后，可以表示为“包装车间→包装产线→包装机01→OEE”，并附上当前值83.4、单位%、实时数据类型和历史值可查询等信息。
对于Agent来说，这两种数据完全不同。前者只是一个不知道含义的地址。后者告诉了AI：数据在哪里；属于哪个车间；属于哪条产线；属于哪台设备；这个字段表示OEE；单位是什么；是实时数据还是其他类型数据；是否存在历史数据。
进一步还可以建立设备、工单、产量、告警等对象之间的关系。这些上下文，才是工业Agent能够正确使用数据的基础。
■这也是我们做UNS的一个重要价值
过去讨论UNS，更多是在解决数据集成问题：让不同系统的数据按照统一的方式组织起来。
但随着AI进入工业场景，UNS又多了一层新的价值：把过去主要给“系统”使用的数据，变成AI也能够理解的数据。
因此，现在再看整个产品链路，会更加清楚：数据连接→UNS→Agent→应用
数据连接解决：数据在哪里。UNS解决：数据是什么、属于谁、和谁有关。Agent解决：拿这些数据做什么。
最终形成的，才是业务人员真正能够使用的应用。
■有了这些数据，Agent才真正开始工作
当用户在应用生成Agent中开启“集成supOS”后，Agent可以在授权范围内读取supOS中已有的数据结构和相关信息。
还是以设备OEE看板为例。用户输入：基于现有数据，为包装产线生成一个设备OEE运行监控看板，展示设备OEE、运行状态、设备告警、运行时长和告警趋势。
Agent收到需求以后，并不是马上开始“画页面”。它首先会理解需求。例如识别：对象：设备、指标：OEE、场景：运行监控看板
然后开始寻找这个应用需要的数据。例如：包装车间→包装产线→包装机01
进一步找到对应的数据资源：设备信息、设备运行、设备告警、设备OEE，以及生成应用需要使用的字段：设备名称、OEE、运行状态、告警数量、运行时长。
完成这些工作以后，Agent才开始生成应用。所以我们现在更愿意把应用生成过程描述成：理解需求→理解数据→生成应用。
而不是简单地说：输入一句话→生成一个页面。
■为什么这和普通的AI编程工具不太一样？
现在使用AI写代码已经越来越普遍。Codex、Claude Code等工具都可以根据自然语言快速生成程序。如果只是做一个普通后台页面或者一个网站，AI已经可以完成很多工作。
但是工业应用有一个额外的问题：代码可以现场生成，工厂数据却不是大模型天然知道的。
通用AI编程工具并不知道：Tag027是包装机的OEE；也不知道：哪张表存设备状态；哪张表存告警；哪一个字段表示实际产量。
而这些恰恰决定了工业应用能不能真正运行起来。所以应用生成Agent和数据底座是绑定在一起考虑的。我们希望解决的是：不仅让AI会做应用，还要让AI知道这个应用应该使用哪些真实工业数据。
■和传统低代码相比，变化在哪里？
过去做工业看板或者轻量应用，很多工作依赖低代码工具完成。典型过程是：找数据→选字段→选组件→拖组件→调布局→绑定字段→配参数→再修改
这些能力仍然有价值。变化在于：过去由人完成的大量操作，现在开始由Agent根据自然语言自动完成。
新的过程变成：用户描述需求→Agent理解需求→Agent查找数据→Agent选择和绑定数据→Agent生成应用→用户审核和继续修改
所以我们并不认为这是“把低代码换一个名字”。更准确地说：大语言模型正在接管过去低代码中大量人工拖拉拽和配置的操作。
人的角色也从“亲自搭建每一个页面”，逐渐变成：告诉Agent我要什么，并审核最终结果。
■当然，UNS也不是魔法
这里我们也希望把产品的能力边界说清楚。如果一台设备的数据从来没有被采集过，Agent不可能凭空获得这些数据。如果PLC地址没有任何定义，也没有人知道这个地址代表什么，AI同样不能凭空判断。
对于标准设备、常见协议和已有模板，可以明显降低连接和建模工作量。但对于高度非标的设备和工艺，仍然需要现场人员、实施人员或者数据工程师完成必要的定义和确认。比如：这个地址到底是什么；单位是什么；OEE按什么口径计算；设备和工单是什么关系；哪些数据可以被Agent使用。
AI可以减少开发应用的工作，但不能跳过工业现场的数据基础。这一点，我们认为反而应该讲清楚。
■生成出来的应用，也不是“一次生成就永远不用改”
实际业务永远会变化。第一版应用生成以后，用户还可以继续告诉Agent：把OEE放到第一屏；增加最近24小时的告警趋势；OEE低于80%时标红；再增加一张设备运行时长排名。
Agent根据新的需求继续修改应用。
这也是Agent相比传统开发流程的另一个变化：应用开发从“一次性交付”，变成持续对话式迭代。
■最终生成的，是连接真实数据的应用
当应用完成后，它可以部署到本地supOS-Free环境中运行。例如设备OEE看板，可以读取已经接入的设备数据，展示：OEE；设备运行状态；运行时长；设备告警；趋势变化。
底层数据发生变化以后，应用按照实际采集周期和数据链路进行更新。因此最终得到的不是一张AI生成的静态效果图，而是一个和现场数据真正连接起来的应用。
■应用生成Agent现在更适合做什么？
现阶段，我们更聚焦信息化层工业应用。例如：设备运行看板；生产管理看板；能源管理；质量分析；库存管理；生产日报；设备告警；台账和查询系统；轻量MES、WMS、CRM等业务应用。
对于已经有MES、ERP、WMS的企业，它可以用于快速补充个性化看板、报表和轻量应用。对于数字化基础还比较薄弱的中小工厂，也可以从一个具体场景开始搭建自己的应用。
需要特别说明：应用生成Agent不直接参与PLC实时控制，也不替代DCS、SCADA、安全联锁等控制系统。
我们的重点仍然是：基于已有工业数据，降低信息化应用的开发和迭代成本。
■接下来，我们会继续把“数据+Agent”做深
应用生成只是我们目前看到的一个开始。当工业数据能够被AI正确理解以后，可以做的事情远不止生成一个看板。
数据查询、分析、日报、报警、应用开发，以及后续更多Agent，都可以建立在同一套数据基础之上。
这也是我们最近越来越明确的一件事：工业AI真正的基础，不只是更大的模型，而是有没有一套AI能读懂的数据。
supOS-Free做的，是让这些数据先连接起来、组织起来。应用生成Agent做的，是让业务人员能够直接使用这些数据。
最终希望实现的是：懂业务的人，可以直接把自己的需求变成应用。
