为什么工业 PLC 是块难啃的骨头
把 LLM 用到工业控制语言生成（西门子 SCL、Codesys ST、三菱 FB），第一直觉会被劝退：
- 语料稀缺：SCL 在 GitHub 上的可见仓库不足 Python 的万分之一，主流模型预训练时几乎没见过。
- 错误代价高：一段不严谨的 SCL 写进 PLC 可能让产线停摆，严重时引发安全事故。这跟 Web 应用"刷新一下"的容错完全不在一个量级。
- 对接平台封闭：要把代码真正写进 TIA Portal，绕不开西门子的 Openness API，而它只跑在 Windows + 本地 TIA 安装上。
- 变量与命名规范个性化：每家工厂的命名规范都不一样，模型不可能通过通用预训练学会"你们家的 FB 编号怎么排"。
但这恰恰是个值得做的方向：电气工程师手写一个完整设备程序往往需要数天，如果智能体能把"需求 + 工艺说明 + 变量表"自动转成 80 分的 SCL 草稿，剩下 20 分由工程师审核改进，整体效率可以提升一个数量级。
下面把我们最近整理的方案骨架完整写出来。
一、双模型协同，而不是一个模型全包
代码生成场景最常见的错觉是"换最大的代码模型一把梭就行"。实际生产里我们更倾向把"需求理解"和"代码生成"用两个不同模型分开做：
| 层 | 推荐模型 | 为什么是它 | |---|---|---| | 需求理解 / 任务规划 | Qwen2.5-72B-Instruct | 中文工艺描述解析准、把"水箱液位达到上限就开排水阀"拆成 FB 任务清晰 | | 代码生成（主力） | DeepSeek-Coder-V2 | 开源 236B MoE，对小众工业语言泛化能力强，可蒸馏 + LoRA 微调 | | 代码审核 | Qwen2.5-Coder-32B | 扮演"审核员"做二次逻辑审阅，捕捉变量类型不匹配、FB 调用参数错位 | | 知识库嵌入 | text-embedding-v3 / bge-large-zh | 中文向量化质量优先 |
这种规划与生成分离的设计来自一个朴素观察：让一个模型同时理解中文工艺逻辑、处理变量表、写 SCL，注意力被稀释，每一项都做不到位。拆开之后，每个模型只在自己最擅长的赛道发挥，整体一次通过率比单模型方案高一个台阶。
别强行追求"一个模型搞定"，那是 demo 思路。生产场景的智能体几乎都是多模型流水线。
二、RAG 三层知识库 = 智能体的灵魂
我们把知识库切成三层，每层职责完全不同：
第一层：SCL 语言知识库
├─ 西门子 S7-1200/1500 SCL 编程手册重点章节
├─ IEC 61131-3 标准库函数说明
└─ 常见语法陷阱、官方风格规范
第二层：工艺程序模板库（核心竞争力）
├─ 电机控制：正转 / 反转 / 软启动 / 变频
├─ 阀门控制：开关阀 / 比例阀 / 电动调节阀
├─ 传感器采集：模拟量 / 称重 / 温度
├─ PID 调节：温控 / 压控 / 流量
└─ 顺序控制：步进 / 工序联锁 / 安全互锁
第三层：变量命名规范库
├─ 变量前缀：I_ / Q_ / M_ / DB_
├─ FB 命名惯例：FB_Motor_Ctrl_001
└─ 项目组织结构与注释规范
第二层是真正的护城河。前两层是公开知识，搜得到、抄得来；模板库是企业自己沉淀的、按"功能 + 触发场景"打标签的可召回资产。每次系统对接成功的真实案例，自动归入这一层——用得越久，模板库越准。
一个反幻觉的工程细节：变量表解析器
输入里最结构化的部分是变量表（Excel / CSV）。别让 LLM 直接读原始表格，幻觉率高得吓人——它会把变量名拼写改一改、把 %MW100 写成 %MD100、把 BOOL 标成 INT。
正确做法是写一个专用解析器，先把表格变成标准化 JSON：
{
"var_name": "Motor1_RunCmd",
"data_type": "BOOL",
"address": "%I0.0",
"description": "电机1启动命令",
"direction": "INPUT"
}
之后再喂给 LLM。任何能用代码确定性处理的环节，都不交给 LLM。 这条规则在工业场景比在通用场景更刚需。
三、三步校验链路：纯 AI 路径里的安全带
光生成不行，必须有一套递进的校验。我们现在用的链路是这样的：
① 语法静态检查（毫秒级，不烧 token）
用 ANTLR4 + SCL Grammar 做正则 + 语法树解析。能在百毫秒内过滤掉关键字拼错、括号不匹配、语句缺分号这种低级错误。100% 确定性，不依赖 AI。
② LLM 逻辑一致性检查
让一个独立的"挑剔的审核员" LLM 角色（用 Qwen2.5-Coder-32B）做二次审阅，重点抓：
- 变量引用：所有用到的变量是否都在变量表里声明过
- 数据类型匹配：赋值两侧类型是否兼容（BOOL 不能直接赋给 INT）
- FB 调用参数：输入输出引脚类型 / 数量是否对得上
- 安全互锁完整性：异常状态是否都覆盖
③ 自动修复循环
发现问题不中断，把校验报告（问题列表 + 位置）作为新的 prompt 喂给生成模型，让它定向修复，再重新进入校验。这一步是系统能不能自我提升的关键。
最大轮次设 5。超限的案例直接标记为人工介入——这种"修不好"的样本是宝贵的改进线索，应该完整记录下来定期复盘，反过来优化 system prompt 和模板库。
死循环的边界条件比死循环本身重要：固定上限 + 兜底转人工 + 完整记录"修不好"的样本。
四、和封闭工业平台对接：先降级，再自动化
博图（TIA Portal）只跑在 Windows + 本地 TIA 安装。Openness API 不能从 Linux/Mac 直接调，必须在 Windows 服务器上跑一个 Agent 服务，通过 REST/gRPC 与主系统通信。
这套架构需要时间打磨，绝对不能等它完美再上线——所以分阶段降级：
| 阶段 | 对接方式 | 工程师介入 |
|---|---|---|
| MVP | 系统生成 .scl 文件 → 工程师手动导入博图 | 全程人工 |
| V1 | Windows Agent 完成文件传输 → 工程师确认导入 | 一次确认 |
| V2 | Openness API 直接写入程序块 | 仅审核 |
| V3 | 全自动 + 案例自动入库到 RAG | 仅监控 |
写入操作必须有事务保护：写之前备份 TIA 项目状态，对接失败自动回滚，不留脏数据；成功 / 失败 / 错误信息全部入库，用于问题排查和"这个案例要不要进 RAG 模板库"的决策。
五、四阶段路线图与质量门槛
工业场景最容易栽跟头的是：质量没到位就追求自动化。我们的做法是给每个阶段定一个强制的质量门槛，没过就不给推进：
| 阶段 | 时间 | 语法正确率 | 逻辑正确率 | 一次通过率 | |---|---|---|---|---| | MVP | 第 1-2 月 | > 90% | > 70% | > 60% | | V1 | 第 3-4 月 | > 98% | > 85% | > 75% | | V2（领域微调后） | 第 5-6 月 | > 99% | > 92% | > 85% | | V3（闭环成熟） | 第 7 月+ | > 99.5% | > 96% | > 92% |
V2 阶段会触发首次 LoRA 领域微调：当 RAG 知识库积累到 500+ 个对接成功的案例后，前期沉淀的数据天然就是训练集，无需额外标注。用 LLaMA-Factory 在租用的 A100 上训完（一次性几百块），权重拷回本地推理。之后每季度做一次增量微调即可。
六、工业安全红线：不要心存侥幸
最后一段算是给所有打算做工业领域 Agent 的同行一个提醒：
MVP 和 V1 阶段，AI 生成的 SCL 代码必须经工程师审核后才能下载到生产 PLC。 这不是产品体验问题，是合规与安全问题。系统投产后建议设立强制的"审核确认"步骤，不允许任何角色绕过。即便 V2/V3 全自动也建议先在仿真环境验证。
工业安全的代价是不可逆的——一段没人复核过的 AI 代码可能让产线停摆 8 小时，严重时是事故和人身伤害。我们做工业 Agent 的第一原则永远是：最坏情况下系统应该退化到"人工审批 + AI 辅助"，而不是"AI 自主写入"。
七、可复用的设计模式总结
把上面的所有内容压缩成 6 条可以套到其他工业 Agent 项目上的设计模式：
- 规划与生成分离：用两个不同模型，不要试图一个模型全包。
- RAG 三层切分：语言基础 / 模板库 / 命名规范分开维护，前两层公开、第三层私有。
- 结构化输入用代码处理：变量表、配置文件、结构化字段绝不交给 LLM 直接读，写解析器转成 JSON。
- 校验链路递进：语法 → 逻辑 → 自动修复，每层独立可观测，超限兜底转人工。
- 平台对接先降级：先做"导出文件 + 手工导入"的兜底，再追求全自动。
- 质量门槛硬卡：每个阶段有强制指标，未达标不推进自动化。
工业领域不是 LLM 最性感的赛道，但能把这套链路打通的团队，护城河比写一个聊天机器人深得多。如果你也在做类似的方向，欢迎在我们公众号后台留言交流。
延伸阅读
- 西门子官方 TIA Portal Openness 文档
- DeepSeek 团队的 DeepSeek-Coder-V2 论文与权重
- 阿里云 Qwen2.5-Coder 模型卡片
- LoRA 训练框架 LLaMA-Factory