> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # AI智能体正在涌入PLC世界 - URL: https://www.hubwiz.com/blog/ai-agents-are-entering-the-world-of-plcs/ - Published: 2026-09-24T13:41:12.000Z - Updated: 2026-11-06T03:25:41.000Z - Description: 在2026年，生成式AI的下一阶段——AI代理——终于开始进入PLC和FA（工厂自动化）的世界。 - Author: admin - Tags: INDUSTRY, #Import 2026-10-14 14:41 当人们听到"生成式AI"时，很多人会想到ChatGPT或Codex那样的文本生成或程序生成。 然而，在2026年，生成式AI的下一阶段——**AI代理**——终于开始进入PLC和FA（工厂自动化）的世界。 迄今为止，PLC编程一直是一个高度专业化的领域，由以下要素构建： - 梯形图（LAD） - 结构化文本（ST） - 功能块图（FBD） - 专用工程工具 - 熟练的PLC工程师 然而，这一前提现在开始改变。要求AI生成PLC代码——我们已经超越了仅仅那个阶段。 不仅仅是那个阶段了。 AI正在发展到能够读取PLC项目并做到以下事情的程度： - 生成PLC代码 - 分析现有程序 - 修复编译错误 - 生成HMI - 配置驱动器 - 配置网络 - 创建文档 - 执行测试 - 验证自己的结果并进行修正 也就是说， > **从"副驾驶"到"AI代理"的转变在PLC世界也开始了** 可以这样理解。 ## 1、PLC中的"AI代理"是什么？ 首先，让我们明确AI助手/副驾驶和AI代理的区别。 使用传统的生成式AI， ``` PLC工程师 ↓ 「请写这个ST代码」 ↓ 生成式AI ↓ 生成代码 ↓ 工程师确认 ↓ 复制到PLC开发环境 ``` 这种用法很常见。AI严格来说是"提供答案的一方"。 而使用AI代理， ``` PLC工程师 ↓ 「请创建这个设备的控制程序」 ↓ AI代理 │ ├─ 项目分析 ├─ PLC代码生成 ├─ HMI生成 ├─ 硬件配置 ├─ 网络配置 ├─ 测试生成 ├─ 编译 ├─ 错误分析 └─ 自我修正 ↓ 工程师批准 ↓ PLC ``` 最大的区别在于它 **"执行多个任务以实现目标"，而不仅仅是"回答"**。 ## 2、西门子用"Eigen工程代理"迈出了一步 西门子象征着这一变化。 2026年4月，西门子正式发布了**Eigen工程代理**作为工业自动化AI。 这是一个直接连接到"**TIA Portal**"的AI代理。 TIA Portal（完全集成自动化门户）是西门子开发的集成工程软件，统一了FA（工厂自动化）领域各种控制设备的设计、编程和配置。 西门子将此定位为从AI驱动的建议到自主任务完成的过渡。Eigen工程代理不仅仅是用于生成PLC代码的AI。 在TIA Portal中， - 功能块 - 用户定义数据类型 - HMI - 驱动器 - 硬件配置 - 网络配置 等方面，使其能够理解实际的项目结构。 目前， - SCL/ST代码生成 - 梯形图生成 - PLC代码修正 - 编译/语法错误修正 - 测试逻辑生成 - HMI JavaScript生成 - 驱动器配置 - PROFINET配置 - 硬件配置 - 项目文档 等都可以执行。 这很重要。这与将PLC程序粘贴到ChatGPT等工具中并要求"请修复这段代码"有本质区别。 因为Eigen工程代理**通过理解实际PLC项目的上下文来工作**。 ## 3、更进一步，从自然语言到PLC项目 2026年6月，Eigen工程代理进一步发展。 西门子宣布了 **"从用自然语言编写的机器规范生成符合标准的自动化项目"的功能**。 可视化一下， ``` 「使用2台电机制作输送传送带。 在入口传感器处检测工件。 从传送带A输送到B。 设有紧急停止。 异常时在HMI上显示。」 ``` 从这样的规范， ``` 自然语言 ↓ AI工程代理 ↓ I/O定义 ↓ PLC逻辑 ↓ HMI ↓ 设备配置 ↓ 文档 ↓ 测试 ``` 方向是自动生成到那个程度。这有可能改变PLC编程的本质。 ## 4、"PLC × AI"目前分为三个方向 在查看PLC和AI的新闻时，如果不将所有内容统称为"AI PLC"，会更容易理解。 当前的趋势可以大致分为三个方向。 | 分类 | AI角色 | 典型用例 | | ----------- | ----------- | ----------------- | | (1) PLC开发AI | 程序生成/分析 | ST、梯形图、代码审查 | | (2) 工程代理 | 操作整个PLC项目 | PLC、HMI、驱动器、网络、测试 | | (3) 运维AI | 分析/优化运行中的设备 | 异常检测、预测性维护、生产优化 | 这三者看起来可能相似，但实际上有很大不同。 ### 4.1 PLC开发AI 最容易理解的是PLC程序生成。 例如， ``` 「按下START按钮时启动电机。 按下STOP按钮时停止。 发生过载时立即停止。 按下复位按钮时解除异常。」 ``` 从这样的规范， ``` IF StartPB AND NOT Overload THEN Motor := TRUE; END_IF; IF StopPB OR Overload THEN Motor := FALSE; END_IF; ``` 生成这样的IEC 61131-3结构化文本。对于这个目的，通用LLM已经相当实用。但这仍然只是"AI助手"。 ### 4.2 工程代理 下一个是目前最重要的变化。西门子工程代理属于这一类。不仅仅是代码生成， ``` 机器规范 ↓ AI代理 ↓ PLC HMI 驱动器 网络 硬件 文档 测试 ``` 单个代理遍历到那个程度的所有内容。 也就是说，AI**正在从"PLC程序员"转变为"FA工程师"**。 西门子 Eigen 代理做的是"理解项目上下文"，这条路本地也能走：[TiaLink](https://tia.hubwiz.com/tia-link?utm%5Fsource=blog&utm%5Fmedium=article&utm%5Fcampaign=ai-agents-are-entering-the-world-of-plcs) 在本机把当前工程索引成知识图谱（块接口、调用链、交叉引用、DB 成员读写），再让 Agent 改块、编译、仿真，工程数据不出厂区。 ### 4.3 运维AI 另一种方法不是创建PLC程序的AI，而是将从PLC获取的数据传递给AI的方法。 ``` 传感器 ↓ PLC ↓ OPC UA / MQTT ↓ 边缘/IPC/云 ↓ AI ├─ 异常检测 ├─ 预测性维护 ├─ 质量分析 └─ 生产优化 ``` 这不需要在PLC本身上加载庞大的AI模型。 PLC处理**可靠的实时控制**，AI处理**判断、分析和优化**。 在分离控制和AI的意义上，这是当前制造现场非常现实的配置。 ## 5、不是用AI替换PLC本身 这很重要。 即使AI代理发展了， ``` PLC → 被AI替换 ``` 也不太可能这样想。 PLC需要： - 确定性执行 - 毫秒级扫描周期 - 安全性 - 故障安全 - 长期供应 - 高可用性 - IEC标准 - 实时性能 即使你告诉LLM"你必须在10ms内响应"，它也无法替代PLC。 因此，未来也将保持这样的角色分工： ``` AI代理 ↓ 工程/优化 ↓ PLC ↓ 实时控制 ``` 与其说AI取代PLC，**更有可能显著改变设计、配置和操作PLC的人的工作**。 ## 6、那么，日本PLC厂商落后了吗？ 这里出现了一个问题。 西门子发布了非常容易理解的产品**Eigen工程代理**。 相比之下， - 三菱电机 - 欧姆龙 - 基恩士 - 横河电机 - 发那科 - 安川电机 等日本FA厂商似乎没有名为"PLC工程代理"的产品。 为什么？当我调查时， > **"日本厂商没有做AI代理"的理解是不正确的。** 相反，它正在从不同的方向快速发展。 ## 7、三菱电机也已经明确推进"AI代理" 在2026年FA系统业务说明会资料中，三菱电机明确强调了**AI代理计划**。 其中包括： - 设备维护 - 生产管理 - 生产计划优化 - 生产线设计 - 系统集成效率 - AI代理套件 - 数字孪生 - 自主改进 等。 特别有趣的是\*\*"融合生产工程专业知识的AI代理套件"\*\*的开发。 也就是说，虽然切入点与西门子略有不同，但方向本身非常相似。 此外，三菱电机还公开了利用多个专业AI代理的多AI代理技术，以及在公司内横向部署AI代理的通用平台。 因此，**并非三菱电机对AI代理持消极态度**。 而是 ``` 西门子 ↓ 从PLC工程代理化 ------------------------------------------------ 三菱电机 ↓ 从生产工程/管理代理化 ``` 将其视为切入点的差异更为恰当。 ## 8、欧姆龙也展示了"AI代理操作机器的未来" 欧姆龙也在采取重大举措。 在公司的技术文档中，作为生成式AI的高级形式，他们展示了\*\*"AI代理主动与人和机器交互"的未来愿景\*\*。 此外， - AI支持只有专家才能理解的调整 - AI代理通过自然语言指示机器 - 未来AI代理自己操作机器 等也在构想中。 他们还在推进**AI驱动的软件定义制造**，结合虚拟孪生和FA。 也就是说，欧姆龙也是， ``` PLC 传感器 机器人 数字孪生 ↓ AI ↓ 自主制造 ``` 正在朝那个方向前进。 ## 9、发那科已经到了"AI代理控制机器人"的阶段 发那科是一个更清晰的例子。 2026年，通过与谷歌合作，发那科宣布了**谷歌AI代理操作机器人的系统**。 此外，\*\*"AI焊接代理"\*\*等具体产品和技术也出现了。 这是一个AI读取零件图纸并将其连接到机器人弧焊的概念。 ``` 图纸 ↓ AI代理 ↓ 任务规划 ↓ 机器人程序 ↓ 机器人 ↓ 焊接 ``` 这已经超越了"PLC程序生成"，更接近**物理AI**的领域。 ## 10、安川电机也有"代理机器人系统" 安川电机也在2026年宣布了**MOTOMAN NEXT代理机器人系统**。 使用谷歌DeepMind的Gemini Robotics， ``` 「请分拣这个零件」 ``` 从这样的指令， 机器人本身， - 识别情况 - 思考工作步骤 - 规划动作 - 执行工作 它朝着那个方向努力。这确实是AI代理。 ## 11、那么为什么日本的"PLC工程代理"不突出？ 从这里开始是基于各公司公开举措的分析。 原因不仅仅是一个。 ### 原因1：日本厂商倾向于从"制造现场"而非"PLC"的角度看待AI 西门子有 ``` TIA Portal ``` 一个非常强大的集成工程平台。 因此，很容易形成 ``` TIA Portal + AI代理 ``` "PLC的AI"这样的产品战略。另一方面，看日本厂商， ``` PLC 伺服 机器人 传感器 视觉 生产设备 ``` 有很多**从现场设备侧引入AI**的方法。 因此， ``` ■　欧洲 工程 ↓ AI ↓ 机器 ``` 相比之下， ``` ■　日本 机器/现场 ↓ AI ↓ 自主运行 ``` 可能存在这样的差异。 ### 原因2：存在TIA Portal这样的庞大"工程平台" 西门子能够轻松实现工程代理的最大原因之一可能是TIA Portal。 在TIA Portal中， - PLC - HMI - 伺服/驱动器 - PROFINET - 安全 - 硬件配置 - 诊断 都集成在一起。 也就是说，从AI代理的角度来看，**操作对象集中在一个平台上**。 这是一个巨大的优势。AI代理可以使用工具调用来 ``` 创建PLC块 编译 创建HMI 配置驱动器 运行测试 ``` 更容易按顺序调用函数。这是一个与代理高度兼容的结构。 ### 原因3：AI生成PLC代码的责任问题 PLC与Web应用程序不同。 PLC代码中的错误可能导致： - 生产停止 - 产品损坏 - 电机损坏 - 机器人碰撞 - 人身伤害 例如，如果AI代理意外删除了**安全互锁**会怎样？"这是AI生成的"将不是一个可以接受的借口。 因此， ``` AI生成 ↓ 静态分析 ↓ 编译 ↓ 仿真 ↓ 数字孪生 ↓ 工程师批准 ↓ 部署 ``` 验证链是必不可少的。长期以来优先考虑质量和安全的FA厂商很可能会极其谨慎地处理这个问题。 ### 原因4：在日本FA中，设备"运行20年"是常态 FA设备有着独特的文化。 在IT中， ``` 3年 5年 ``` 系统有时会更新。 但在PLC中， ``` 10年 15年 20年 ``` 使用设备并不少见。 此外，在现有工厂中， ``` 旧PLC 旧伺服 旧HMI 专有网络 自定义功能块 ``` 大量存在。 引入AI代理时，不仅仅是新项目，**如何理解遗留PLC**也是一个难题。 相反， ``` 遗留PLC分析 ↓ AI代理 ↓ 迁移到现代PLC ``` 未来有可能成为一个相当大的市场。 ### 原因5：日本厂商在不称其为"AI代理"的情况下实施 这也很重要。 在最近的AI行业， ``` 代理 代理AI 副驾驶 物理AI 自主AI ``` 这些术语频繁使用。 另一方面，日本制造业长期以来一直使用以下术语进行研究： - 自主控制 - 自主改进 - 优化 - 异常预测 - 熟练技能支持 即使在技术上非常接近代理AI，**也有不将"AI代理"作为营销术语突出的方面**。 然而，进入2026年， - 三菱电机：AI代理 - 欧姆龙：AI代理 - 发那科：AI代理 - 安川电机：代理机器人 这些术语实际上开始被使用。 这是一个明显的变化。 ## 12、日本厂商并非落后，而是在"不同的路线"上奔跑 总结以上内容，并非"西门子朝着AI代理方向发展，而日本厂商无所作为"的构成。 而是 ``` ★ 西门子 工程代理 ↓ PLC / HMI / 驱动器 ↓ 机器 ``` 相比之下， ``` ★ 日本FA厂商 机器/机器人/生产 ↓ AI代理 ↓ 自主制造 ``` 可以看到差异。最终，这两者很有可能会融合。 ## 13、最终，"工程AI"和"物理AI"会连接 思考未来的FA系统， ``` AI代理 │ ┌──────────────┼──────────────┐ │ │ │ 工程 生产 维护 │ │ │ ↓ ↓ ↓ PLC ─────── 数字孪生 ───── 机器人 │ ↓ 传感器 │ ↓ 机器 ``` 可能会变成这样的结构： 工程代理构建设备，物理AI代理操作设备，维护代理维护设备。 当这三者协作时，就变成了**从设计到运营都有代理参与的工厂自动化**。 ## 14、PLC程序员会变得不再需要吗？ 可能不会那么简单。 而是角色会发生变化。迄今为止PLC工程师一直在做的工作是： ``` 规范 ↓ I/O分配 ↓ 编写梯形图/ST ↓ 调试 ``` 在AI代理时代，这可能会变成： 也就是说，价值将从**编写代码的能力**转变为**定义正确的控制规范和验证AI生成的系统的能力**。 不仅PLC知识不会变得不再需要，当AI出错时进行判断的深层知识可能会变得更加重要。 ## 15、你可以用OpenPLC体验同样的世界 这种变化不仅仅关乎主要PLC厂商。 例如，如果你将OpenPLC与AI编码代理结合使用，你可以实验这样的系统： ``` Requirements.md ↓ Codex / AI代理 ↓ IEC 61131-3 ST ↓ OpenPLC ↓ 编译 ↓ 仿真 ↓ 错误日志 └─────────→ AI代理 ↓ 修正 ``` 作为个人。 此外，如果添加Git，它就变成了接近IT软件开发的PLC开发环境： ``` 需求 ↓ AI代理 ↓ ST源代码 ↓ Git ↓ 构建 ↓ 测试 ↓ 仿真 ↓ 审查 ↓ PLC ``` 这个方向非常有趣。 ## 6、PLC世界已经开始从"编写梯形图逻辑的世界"发生变化 如果我们非常粗略地总结PLC的历史，可以看到这样的流程： ``` 继电器 ↓ PLC ↓ 梯形图 ↓ IEC 61131-3 ↓ 集成工程 ↓ 软件定义自动化 ↓ AI副驾驶 ↓ AI代理 ``` 2026年可能会被回顾为开始从**AI副驾驶到AI代理过渡**的一年。 特别是西门子工程代理很重要，因为它从"让AI编写PLC代码"迈向了\*\*"让AI执行PLC工程"\*\*。 另一方面，日本厂商也绝非无所作为。 三菱电机正在从生产技术、SI和生产管理的角度推进AI代理；欧姆龙正在研究人与机器之间的自然语言交互；发那科和安川电机开始步入物理AI/代理机器人领域。 因此，如果用一句话表达现在发生的事情： > **不是"AI被添加到了PLC中"，而是"工厂自动化本身开始变得具有代理性"。** 这样思考可能更接近本质。 PLC不会消失。但是，我们设计、编程、配置、测试和操作PLC的方式将发生重大变化。 **AI代理的浪潮正在涌入PLC世界。** --- 原文链接：[The Wave of AI Agents is Reaching the World of PLCs](https://note.com/ya%5Fikegami/n/ne74b49c6e589?hl=en&ref=hubwiz.com) 汇智网翻译整理，转载请标明出处 > **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)