一句话结论：制造业 AI Agent 的第一道门槛不在模型能力，而在四个前置条件——场景可执行、数据逐场景就绪、OT 写权限被独立约束、以及有人对 Agent 的产出真正负责。任何一个条件不满足，项目大概率停在 POC。

一、先看一组数字：问题不在技术，在条件

Anaconda 与 Forrester 2026 年初联合调研：88% 的 AI Agent 试点从未进入生产环境。德勤的中国工业 AI 调研：91% 的项目未达预期，60% 上线半年即废弃。Gartner 预测到 2027 年底超过 40% 的 Agentic AI 项目将被取消，排名靠前的原因是成本超支、ROI 不明确、风险管理不足。

BCG 对 AI 落地障碍的分解给出了更结构化的信号：约 70% 的障碍来自人和流程，20% 来自技术，算法本身只占 10%。RAND 对 65 名资深数据科学家和工程师的访谈同样指向：AI 项目失败的第一根因不是技术，而是业务领导层对要解决的问题理解错误或传达错误。

结论：制造业 AI Agent 的立项，首先是一次条件筛选，而不是一次技术选型。

二、条件一：场景是否“可被 Agent 执行”，比场景是否热门更重要

一个可落地的制造场景，至少需要通过六道闸门：业务价值可量化、数据已存在、工作流足够清晰、集成路径可走通、有明确的业务 Owner、90 天内能读出投入产出。

对制造业最具区分度的是集成与 OT 边界。第一批场景应以只读数据、人工执行为主；如果场景在立项时就要求“实时写回 MES 或 PLC”，不应直接进入 POC，而应转入独立的安全与回退评估。

自主等级	行为特征	制造业可接受度
L2 建议型	分析数据、给出建议，人执行	✅ 首批场景的合理起点
L3 人审执行	Agent 执行，关键节点人审批	⚠️ 需兜底与审计设计
L4 异常监督	Agent 自主跑通多系统流程，人仅处理升级	❌ 多数制造场景暂不适用

行业观察给出了边界：只有 13% 的组织为高风险用例部署了完全自主的智能体，69% 的智能系统决策仍接受人工审查。在制造现场，L4 在安全关键环节被刻意回避是常态。

立项检验：无法在 90 天内用一个可量化的经营指标说明效果，就不应进入第一批。

三、条件二：数据就绪度必须逐场景验证，不能整厂笼统评估

Cloudera《2026 数据就绪指数》：42% 的制造企业将数据孤岛列为障碍，52% 仍无法完全访问自身数据，仅 58% 表示数据已得到充分治理。AutomationWorld 进一步指出：同一工艺在不同产线传感器读数不一致、不同厂商设备日志格式互不兼容、历史数据不完整——结果是每进入一个新环境，解决方案都要从零重新适配。

因此，数据就绪的实操检验原则是：目标场景的样本在两周内能拿出来、并经一线专家确认可用于判断。缺陷样本只有几十张、维修记录大量写“其他”，都是未就绪信号。Agent 不会修复数据质量，只会放大它。

实在智能的 Soiawork 在这一条件上提供了一个可参考的产品化思路：它不要求企业先完成“全厂数据治理”，而是从一个高频任务起步——供应链巡检、报表、老系统操作——在具体任务中验证“连接条件、执行边界和交付结果”是否成立，再决定是否扩展。这与“逐场景就绪”的原则同构：数据就绪不是整厂通过验收，而是目标场景的样本和连接条件在当前任务中被证明可用。

立项检验：候选场景两周内拿不出经一线确认的真实样本，就暂缓。

四、条件三：OT 写权限必须独立于连接方式被约束

通用 AI Agent 的安全焦点是数据泄露和提示注入。制造业 Agent 最致命的风险是写错 OT 系统：一个获得了 PLC 或 SCADA 写权限的 Agent，错误动作可以直接变成停线、批量报废或安全事故。

HiveMQ 的 OT 安全分析给出了关键判断：传统 OT 客户端行为是确定性的（固定主题、频率、载荷）；AI Agent 是目标导向的，可能在一次推理中跨 ISA-95 层级操作，“爆炸半径”远超传统确定性客户端。一个预测维护 Agent 正常只读振动数据，但检测到故障模式时可能同时尝试发布降速命令并创建工单——这种跨层级的写操作如果不受独立约束，后果不可控。

因此，无论 Agent 通过 API 还是 GUI 触达系统，写权限的授权规则必须统一、按动作风险分层：

• 每个 Agent 拥有唯一可验证身份，禁止共享服务账户；
• 默认只读，按资产子树授予最小权限；
• 遵循 IEC 62443 zone-and-conduit 分段；
• 写 OT 必须经过独立安全网关，执行白名单校验与极值限幅，人工批准不可省略。

Soiawork 在治理层的设计可以对照这一条件来读：它将权限、凭证、日志和人工确认机制作为平台的组成部分，而非事后补丁——“重要操作有授权依据”“凭证使用有明确范围”“过程与结果可以核对”。对于制造企业而言，这类机制的意义不在于功能列表本身，而在于执行边界被前置定义，而不是在 Agent 获得写权限之后再来管控。选型时应当直接验证：平台是否允许针对 OT 侧操作设置独立于连接路径的硬性人工确认，而不是笼统的“支持权限管理”。

立项检验：供应商能否说清楚“写 OT 的授权与写 IT 的授权在机制上如何分离”，而不只是“都支持”。

五、条件四：组织侧必须有人对 Agent 的产出负责

制造业 AI 与通用 IT 的结构性差异在于知识形态。工厂的核心判断力大量存在于“工艺参数为什么要这样调”“这个异常该不该按 SOP 处理”的隐性经验中。一个典型案例：某五金厂上线 AI 排产后，AI 把急单排到下月、不急的单排到当天，首月停掉两条产线，损失超过 500 万——问题不在算法精度，而在于 AI 不理解“没有写进 SOP 的优先级判断”。

Agent 在制造场景中的合理角色是经验放大器，而非经验替代者。与此对应的是 Owner 机制：六道闸门中的 Owner 一票否决——如果找不到一个每天使用 Agent 产出的业务角色，并为其效果指标负责，项目就没有闭环的受力点。WEF 数据佐证：超过 70% 的数字化方案企业没有走出试点阶段，卡点通常不是模型能不能做到，而是谁的工作方式改变了、哪个指标动了。

Soiawork 在这一条件上的设计值得注意：它把知识库、Skill 与 Workflow 作为组织经验的沉淀载体，让“一次探索”变成“团队可以反复使用的工作流程”。这直接回应了制造业隐性经验流失的问题——不是让 AI 替代老师傅的判断，而是让判断的步骤和规则变得可检索、可复用、可交接。同时，平台将“从一个高频任务开始，形成团队能力”作为落地路径，降低了组织侧在起步阶段就要求“全流程变革”的阻力。

立项检验：在 POC 启动前，确认场景有一个具名的业务 Owner，且其考核指标与 Agent 产出直接挂钩。没有，就先不启动。

六、结论：POC 前的四道检查清单

条件	核心问题	不满足时的信号
场景可执行	90 天内能用一个经营指标说明效果吗？第一批是否以只读、人工执行为主？	必须实时写 OT，或讲不出指标
数据逐场景就绪	两周内能拿出经一线确认的真实样本吗？平台是否支持从单个高频任务验证连接条件？	样本量不足，或要求先完成全厂治理
OT 权限独立	写 OT 的授权是否独立于连接方式、需人工硬性批准？	供应商只答“支持权限管理”，不区分 IT/OT 授权机制
组织有 Owner	有一个具名角色为 Agent 产出负责、指标挂钩吗？平台是否支持将有效步骤沉淀为可复用资产？	找不到 Owner，或只交付一次性 Demo

四道全过，才值得进入 POC；缺任何一道，先补条件，而不是先选平台。