给工厂落地 AI Agent，别只盯着 Demo：一个工程师视角的避坑笔记-编程实验室

这一年陆陆续续接触了不少制造业的 AI Agent 选型，踩坑、复盘、再踩坑，慢慢想明白一件事：给工厂选 Agent，和给一个客服系统、一个办公场景选 Agent，根本不是一回事。

差别就一句话——在工厂里，Agent 能动的不是数据库里的一行记录，是真实世界里一根正在 3000 转上跑的主轴。

这句话听起来像废话，但它几乎决定了制造业 Agent 选型里所有真正重要的判断。很多方案 Demo 跑得漂亮，接到产线上却处处是坑，根子都在这。下面把我认为最该想清楚的三件事讲透，顺便贴一段代码，省得停留在 PPT 层面。

如果你是给工厂做技术选型、或者正在自研工业 Agent 的工程师，希望能帮你少走点弯路。

一、安全这件事，在工厂里的重心是"管物理动作"，不是"防数据泄露"

通用场景下聊 Agent 安全，大家担心的是数据外泄、prompt 注入、越权调用。这些在制造业当然也存在，但都不是最致命的。

最致命的是：Agent 一旦获得对 OT 系统（PLC、SCADA、DCS）的写权限，它的一个错误决策会变成停线、批量报废，甚至安全事故。

业界有调研预测：到 2026 年，自主 Agent 将在无人干预的情况下解决 80% 的常见运营问题。这个数字听着很美，但反过来想——你真的敢让一个大模型驱动的系统，在没人盯着的情况下，直接改产线参数吗？

我见过的真实数据更扎心。有一份针对企业 Agent 部署的调研显示，60% 的组织根本没有能力中途叫停一个已经跑偏的 Agent。在 IT 系统里这顶多是生成了一堆垃圾工单，回滚就好；在产线上，这是不可接受的。

所以制造业的 Agent 安全，我的判断是要从三个维度去卡。

OT/IT 边界要做权限分级，写权限尤其要分级。不能让 Agent 对控制系统是"全有或全无"的访问：读数据可以放开，生成建议可以放开，写 IT 系统（开工单、生成报表）可以有条件放开，但写 OT 系统（改参数、下指令）必须强制走人在回路。

全局急停（kill switch）是底线，不是加分项。任何时候，运营人员要能一键冻结所有 Agent 动作，这个开关的优先级必须高于一切业务逻辑。

还要关注工控网络这个新攻击面。Agent 接进来之后，它既是生产力工具，也是新的攻击入口。这块建议直接对照 IEC 62443 去问供应商，看他们是不是真的懂工控环境，还是只会拿 IT 安全那套来糊弄。

落到代码上，一个最基础的"动作网关"应该长这样。核心思想就一句：把动作按风险分级，OT 写操作强制人工批准，急停优先级最高。

from enum import IntEnum from dataclasses import dataclass from typing import Callable class ActionRisk(IntEnum): READ = 0 # 读取 PLC / SCADA / MES 数据 SUGGEST = 1 # 仅生成建议，不落地执行 WRITE_IT = 2 # 写入 IT 系统：工单、报表、通知 WRITE_OT = 3 # 写入控制系统：改参数、下发指令（最高危） @dataclass class AgentAction: target: str # 目标系统/设备标识 risk: ActionRisk payload: dict reasoning: str # Agent 的决策依据，落审计日志用 class ActionGateway: def __init__(self, kill_switch: Callable[[ ], bool], approve_fn: Callable[[AgentAction], bool]): self._kill_switch = kill_switch # 全局急停状态查询 self._approve_fn = approve_fn # 人工审批入口 def execute(self, action: AgentAction) -> dict: # 急停优先级最高，无条件拦截 if self._kill_switch(): return {"status": "blocked", "reason": "全局急停已触发"} # OT 写操作：无论模型多自信，强制人在回路 if action.risk == ActionRisk.WRITE_OT and not self._approve_fn(action): return {"status": "rejected", "reason": "未获人工批准"} # 真正下发前还应叠加：幂等校验、参数物理边界检查、变更审计落库 return self._dispatch(action)

代码本身不复杂，关键是这个分级思路。我见过太多团队一上来就给 Agent 配了个 service account，权限拉满图省事，结果上线前安全团队一票否决，又得返工。权限分级要在架构阶段就定，不是上线前补的补丁。

二、ROI：制造业其实是最好算账的行业，但数据质量是个隐形门槛

这一节我想先讲个好消息，再泼盆冷水。

好消息是：制造业是为数不多天生就有量化基线的行业。 OEE（设备综合效率）、MTBF（平均故障间隔时间）、废品率、节拍时间、单位能耗——这些指标工厂早就在盯了。这意味着你不用像知识工作那样，去虚头巴脑地论证"提升了员工幸福感"，而是可以直接说："预测性维护上线后，3 号线的非计划停机时间从月均 14 小时降到 5 小时。"

业界有调研显示，2025 年有个数据很能说明问题：有成熟 KPI 跟踪体系的制造商，AI 从试点走到生产的转化率能到 65%；而那些没有量化基线的行业，这个数字只有 28%。差距一倍多，根子就在"能不能把账算清楚"。

所以选型时，别接受任何只承诺"提效"却说不清挂钩哪个 KPI 的方案。让供应商把话说死：你这个 Agent，预期把哪个指标、从多少、改善到多少、多久见效。

按落地确定性，我一般建议这么排优先级。

先上预测性维护和质量检测。这俩是制造业里部署最广、ROI 最确定的，依赖现有传感器和成熟 ML 方法就能跑，不需要把整个数据架构推倒重来。

再上需要数据整合的，比如能源优化。但这里有坑——能源优化通常需要 6 个月以上、跟生产排程关联好的细颗粒度能耗数据。数据不够，模型就是空中楼阁。

最后才碰跨域的复杂编排，比如供应链协同、新品研发。Deloitte 的报告里就有制造商用 Agent 在"成本"和"上市时间"这种相互冲突的目标间找平衡点的案例，但这类用例对基础设施和治理成熟度要求最高，别一上来就啃硬骨头。

现在说回那盆冷水：数据量大 ≠ 数据可用。

单条产线一天能产出 50 到 200 GB 的传感器数据，振动、温度、压力、电流、视觉检测图像，听着特别唬人。但这些数据如果没打时间戳、格式不统一、采样有空洞、或者传感器漂移了没人发现，喂给再强的 Agent 也是 garbage in garbage out。

我的经验是，在 Agent 消费数据之前，一定要先架一道数据质量闸门：时间戳必须存在且单调、采样不能有大空洞、物理量不能超量程、关键字段缺失率得卡在阈值内。这道闸门上线时一定会被你那位"灵活"的同事吐槽太严格。但相信我，第一次 Agent 因为一个漂移的温度传感器给出离谱建议、还差点被执行的时候，你会庆幸自己加了它。

三、集成的真正难点是 OT/IT 融合，不是接个 ERP

通用 B 端场景聊集成，无非是打通 SAP、Oracle、Salesforce 这些 IT 系统，标准 REST API，做个 connector 就完事。

制造业难就难在，你既要连 IT，又要连一大堆异构、老旧、协议五花八门的 OT 设备。一个十年前上的 SCADA、一个用 Modbus 的老 PLC、一个 OPC UA 的新设备、再加上各产线自己攒的数据历史库——这些东西的"打通"，工作量经常被严重低估。

业界现在基本形成了共识：当下部署 Agent 工作流，最难的不是模型智能本身，而是对生产系统安全、可靠的接入。一份 2026 年的调研里，57% 的组织已经在跑多步骤 Agent 工作流，但随着工作流复杂度上升，编排和可靠性会成为真正的瓶颈——多步骤会同时放大 Agent 的收益和运营风险。

选型时，围绕集成和落地可靠性，我重点看三件事。

一是供应商能不能对接你现有的 MES、ERP、SCADA 和数据历史库，而不是要求你为了上 Agent 把底层系统全换一遍。凡是上来就让你"配套升级整个数据中台"的，先警惕。

二是要清醒认识到，Agent 不是来取代现有自动化的。2026 年比较成熟的制造业技术栈是分层的：用预测模型做模式识别，用生成模型做推理解释，用 Agent 系统做编排执行。三者协同，各干各擅长的事。指望一个大模型 Agent 包打天下的，多半要交学费。

三是可观测性，这是底线中的底线。另一份行业调研里，接近 89% 的受访者已经给 Agent 部署了可观测性，而把"质量"列为头号生产障碍的占了 32%。在产线上，你必须能实时回答："这个 Agent 现在在干嘛？它为什么这么决策？出了问题怎么复盘？"

落地时，给每一个 Agent 决策做结构化的审计追踪——决策依据、动作、结果、耗时一个都不能少。注意前面那段代码里我特意留了个reasoning字段，这是踩过坑之后的执念：出问题的时候，光知道"Agent 改了参数"没用，你得知道"它当时是基于哪几个信号、用了什么逻辑做的判断"，否则复盘就是抓瞎。很多制造业还涉及合规审计，每一次工艺参数变更都得能追溯到人或系统，这个字段也是为它准备的。