现在GUI Agent很流行，比如智谱推出的 AutoGLM2.0 能够进行一些手机、电脑操作，能成为生活助手或者办公助手。AutoGLM2.0 相比AutoGLM1.0 成熟度比较高， 数字生命卡兹克大佬使用后，有一句精华总结：两岸卧槽啼不住，AI 已过万重山！

还有阿里的Mobile-Agent-v3 和 GUI-Owl ，测评分数在手机端和电脑端取得了多个开源类的 SOTA，能够完成一系列的复杂任务、多智能体协助。

GUI Agent要执行各种任务，必须具备：看、思（理解）和做的能力。“看”需要不停的截取屏幕，然后对截取的屏幕内容用图像理解大模型进行信息解读，思考应该进行什么操作比如是模拟鼠标点击，还是特定的位置输入数值或文本内容，确定好了具体要干什么之后，就是调用输入接口控件进行操作了，做的过程中还要持续不断的“看”和“思”。

图像信息密度往往是非常大的，这就对图像理解大模型的要求比较高，资源的消耗也会比较大；此外，图像理解大模型需要有大量的图像样本数据进行学习才能表现得比较好、理解得准确，日常使用的软件或者APP这类图像样本数据相对比较容易获得且丰富，目前 GUI Agent 在常用的软件操作中表现得确实是越来越好了，越来越老练。

但是，在工业自动化领域比如生产工艺流程自动化系统的监控界面，都是各企业私有的定制的图像界面，图像理解大模型学习到的数据很少，GUI Agent 想发挥用武之地、提高生产效率、辅助决策，可能就会有一些“水土不服”，或者需要进一步训练调教。

既然现阶段 GUI Agent 对工业自动化领域存在可能看不明白看不懂的问题，那么是不是摈弃“看”这种模式？做过工业自动化控制的一般会遇到这种场景：本地机旁设备上有一套相对独立自主的控制系统，然后在中控室或集控室还有一套上层系统对各类机旁设备进行集中远程监控；或者是工厂级控制系统能对车间级控制系统进行远程监控。上述层级式监控过程必然涉及一些关键性控制数据的传输交互，那么这些数据也是可以传输给非图像理解大模型，比如普通的文本大模型进行处理，核心思想就是把通用性更好的文本大模型当成假想的“上层”集控系统来处理这些数据，这样就能避开 GUI Agent 底层的图像大模型在理解工业自动化领域图像时的软肋，也能提高人工智能大模型在工业自动领域的适用范围了。

举个简单例子：比如要控制一个容器内的水温，这个容器是通过电加热器加热来维持温度的稳定。通常做法是工程师首先编写PID控制程序，工程师还需基于该控制器上对该PID控制程序进行一次又一次的整定调参，来达到温度的动态平衡。如果借助人工智能大模型的力量，只需要用相关通信MCP/API 将当前温度、目标温度和控制对象调节参数传递给普通的文本大模型，该模型进行目标温度和当前温度的简单的大小比较后，改变调控参数值，再由通信MCP/API 回传给控制器即可，运行过程中由普通的文本大模型实时监测，不断自适应调节调控参数值。简单来说就是基于目标值（文本/数值内容）的处理，这种情况下的资源开销、通用性上会比使用图像大模型 GUI Agent 显著更优。当然这里面可能也需要特定的 Agent，但这种 Agent 应该是通用的，比专业工程师为适配该PID控制任务中的定制性开发具有显著的优势。尤其是在大型复杂控制系统中，比如涉及多个相互关联的目标参数与控制对象，大模型的优势会进一步凸显。

端侧小型化大模型性能的提升，部署的便捷，必将助推工业自动化向着工业智能化发展。