AI 智能体在工厂能做什么？从问答到自动执行的落地边界

01先把「智能体」拆成三级能力

把宣传语放一边，按是否写入业务系统划一条线，智能体的能力就清楚了。第一级问答：查资料、查单据状态、汇总说明，只读不改。这一级风险最低，即使答错，使用者也能对照原文发现——工厂里已成熟落地的大模型知识库、报表问数基本属于这一级。

第二级建议：生成排程建议、缺料补齐方案、异常处置建议、单据字段补全结果，但不落库，由人确认后才生效。这一级的价值往往被低估：它把「人从零想方案」变成「人审核一个方案」，省下的时间与减少的遗漏都很实在，却不必承担自动执行的责任。

第三级执行：智能体直接调用接口写入 MES、WMS 或 ERP——创建工单、改期、过账、触发报修。这一级才真正配得上「自动执行」，也才是所有权限、审计、回滚问题的来源。同一个「智能排产」产品，停在建议级与开到执行级，是两个完全不同的项目。

分级的实际用处是让讨论落到具体动作。供应商说「我们的智能体能自动处理异常」，追问一句「是直接改工单状态，还是生成待办清单让人确认」，项目的风险、预算与验收方式立刻就清楚了。合同里也应写明本次交付开放到哪一级、哪些动作允许自动执行，避免上线后边界靠口头约定。

还有一个常被忽略的第四种情况：智能体不写业务系统，但会对外发消息（给客户回复交期、给供应商发催料、在群里 @ 责任人）。这类动作虽然没有改数据库，却产生了对外承诺，风险等级应按执行级管理，不能因为「只是发条消息」而放松。

02哪些动作可以自动执行：可逆、低风险、可回滚

判断一个动作能不能放开自动执行，用五个条件筛：可逆（改错了能撤回或冲销）、影响范围有限（单张单据或单个对象，不是批量）、有明确校验规则（字段完整性与业务规则可被程序判定）、能回滚（有历史版本或冲销单据）、全程留痕（动作前后值与依据可查）。五条都满足，才适合进执行级。

按这个标准，工厂里适合自动执行的动作其实不少：单据字段补全（根据规则补齐物料分类、默认库位、责任人）、异常清单生成与分派（超期未报工、待检超时、缺料预警按规则推给对应岗位）、编码对照建议落库（新增物料与既有编码的候选匹配，写入待确认状态而非直接生效）、报表与看板数据的定时刷新、知识条目与工单结论的归档。它们的共同点是：错了能改，且改动本身会被发现。

注意「待确认状态」这个设计——它是把执行级动作降风险的常用手法：智能体可以写入，但写的是待办、草稿、建议值，业务数据本身不变，人一键确认后才生效。既减少了手工录入，又没有让系统悄悄改变账与单。

反过来，批量动作要格外谨慎。「自动把 200 张工单改期」即使技术上可回滚，也涉及产能、物料与客户交期的连锁影响，一次错误会波及多个部门。稳妥做法是把批量拆成单条规则 + 影响预览：先列出将受影响的单据清单与前后差异，人确认后再执行，且保留一次撤回窗口。

最后一条经验：自动执行的范围应当从窄到宽、可随时收回。系统里给每个动作一个开关，出问题能单独关掉某个自动动作而不必整体停用。这个开关在上线头两个月会被用到，几乎是可以肯定的。

03哪些必须人工确认：账务、质量、承诺与不可逆动作

四类动作建议一律保留人工确认。影响账务与库存的：出库过账、盘点差异调整、成本结转、发票与收付款相关动作。账务权威留在 ERP，任何自动生成的结果都应是待审核单据，不能由智能体直接过账——这不是不信任模型，而是财务本身就需要复核与责任岗位。

涉及质量判定的：不良品判退、让步接收、批次放行、检验结论。AI 视觉质检给出的是判定建议，最终结论要有质检责任岗位签署，尤其在客户审厂、召回与合规追溯场景下，责任不能落在一个概率输出上。

产生对外承诺的：交期答复、报价、订单变更确认、给供应商的催料与索赔。这类动作一旦发出就构成业务承诺，且常常依赖尚未进系统的上下文（客户口头约定、产线临时状况），智能体掌握的信息不完整，误发的代价远高于节省的几分钟。

不可逆或高连锁影响的：删除单据、批量改期、BOM 版本切换、产线停机指令、权限变更。这些动作要么无法撤回，要么会连带多个系统，应当走既有审批流，而不是塞进智能体的自动链路。

人工确认不等于「加一个弹窗点确定」。有效的人工确认要给出三样东西：建议的依据（命中了哪些数据、按哪条规则）、影响预览（改了之后哪些单据与指标会变）、以及修改入口（人可以改建议值再确认）。只有「确定 / 取消」两个按钮的确认框，用久了会变成无脑点确定，形同虚设。

04权限与审计：给智能体一个独立账号

执行级智能体最容易出的问题不是判断错，而是权限给大了还查不到是谁改的。常见坏做法是直接把管理员账号的令牌交给智能体程序：一旦出错，日志里全是同一个管理员，事后分不清哪次是系统自动改的、哪次是人操作的，责任与回滚都无从下手。

正确做法是独立账号 + 最小权限：为智能体建独立的服务账号，在 MES/WMS/ERP 里按「本次开放的动作清单」逐项授权，不授予清单之外的写权限；账号只用于该应用的调用，不与人共用。权限清单写进交付文档，业务方与实施方各执一份。

动作留痕要能回答四个问题：谁（服务账号 + 触发来源）、在何时、依据什么（输入数据快照或规则版本）、把什么从什么改成了什么（前后值）。日志与业务单据同生命周期保存，不能被定时清理。涉及质量判定与账务的动作，还应保留人工确认人与确认时间。

失败回退要在设计阶段就定：接口超时是重试还是转人工、部分成功时怎么回滚、批量动作中途失败如何标记已完成部分。这些在传统系统集成里是常规项，到了智能体项目里常被「模型会处理」的想象带过去，结果异常全靠人肉排查。

还有一条管理要求：动作清单变更走变更流程。上线后想新开一个自动动作，应重新评估五条件并更新权限清单与测试，而不是在后台勾一下就生效。智能体的风险随开放动作数量增长，管住「新增动作」这个口子，比事后追查更重要。

05落地顺序：从一个岗位的一个动作开始

不建议以「全厂智能体平台」立项。稳妥路径是从一个岗位、一个高频动作、一个可回滚的闭环开始：比如设备岗的「异常自动归类分派」——系统识别超期未处理的报修与待检项，按规则生成待办并推给责任岗位，不修改任何业务单据。这个动作可逆、留痕、价值可量化（异常响应时长），却几乎不需要动审批流。

第一阶段的产出不是「智能体上线」，而是一份真实运行数据：四周内自动生成了多少条待办、多少被采纳、多少被判定为误报、责任岗位有没有因此少打电话。用这组数据决定下一步——误报多就先修规则与数据，采纳率高再考虑把某个动作升级到执行级。

扩展按动作清单逐项加，不按「部门」或「模块」铺开。每加一个动作，重新走一遍五条件评估、权限更新、测试与试运行。看起来慢，但每个动作都有独立可验收产出，也不会因为一个动作出问题导致整个应用被叫停。

组织上要有一个明确的业务负责人对动作清单负责：有权决定开哪些、关哪些，也有权在异常时一键停用。这个角色通常由生产或运营负责人兼任，不能由 IT 或供应商代管——自动执行影响的是业务规则，拍板权必须在业务侧。

与既有系统的关系是补一层，不是替换：智能体调用的是 MES、WMS、ERP 已有的接口与业务规则，账务权威、质量判定流程、审批流都不因它而改变。凡是要求「先推翻现有流程再上智能体」的方案，风险都远大于收益。

06常见坑与投入区间

坑一：概念不分级别。把问答级产品当执行级采购，或反过来对只读应用做过度管控，都会让项目目标从一开始就说不清。合同里写明开放到哪一级。

坑二：共用管理员账号。出错后日志分不清人改还是系统改，回滚与追责都做不了。给智能体独立服务账号与最小权限。

坑三：确认框没有依据与影响预览。只有「确定 / 取消」，用久了变成无脑点确定，人工确认形同虚设。

坑四：一上来做全厂自动调度。批量、跨部门、连锁影响的动作风险最高，出了问题往往整体回退，试点成果也一起丢掉。

坑五：动作清单后台随手勾。新增自动动作不走评估与测试，风险随开关数量无声增长。

坑六：没有一键停用。上线头两个月出现误判时关不掉，只能整体停用，业务对系统的信任一次耗尽。

投入参考（软件加实施口径，模型调用、硬件与年运维另计）：问答与建议级单点应用 3~15 万（一个岗位、一个动作闭环、基础留痕，1~2 个月）；含执行级动作、独立账号权限与审计日志的岗位级应用 15~50 万（多动作清单、人工确认界面、失败回退与试运行，3~6 个月）；跨系统多岗位协同含统一动作治理 50 万以上（6 个月起）。成本大头在流程梳理、权限设计与接口改造，模型调用通常不是主要支出。均为区间表述，实际以动作数量、系统接口与审计要求勘察为准。

常见问题（FAQ）

Q：AI 智能体在工厂到底能做什么？

按「是否写入业务系统」分三级看最清楚：问答级——查工艺规范、查单据状态、汇总说明，只读不改，风险最低；建议级——生成排程建议、缺料补齐方案、异常处置建议、单据字段补全，但不落库，由人确认后生效；执行级——直接调用接口创建工单、改期、过账、触发报修。适合自动执行的是可逆、影响范围有限、有明确校验规则、能回滚、可留痕的动作，例如字段补全、异常清单生成与分派、报表定时刷新；账务过账、不良品判退、交期答复客户、批量改期等必须人工确认。选型与合同里都应写明本次开放到哪一级、哪些动作允许自动执行。

Q：哪些动作绝对不能让智能体自动执行？

四类：一是影响账务与库存的——出库过账、盘点差异调整、成本结转，账务权威应留在 ERP，自动生成的结果只能是待审核单据；二是涉及质量判定的——不良品判退、让步接收、批次放行，AI 质检输出的是建议，最终结论需质检责任岗位签署；三是产生对外承诺的——交期答复、报价、订单变更确认、给供应商发催料或索赔，这类动作依赖未进系统的上下文且发出即构成承诺；四是不可逆或高连锁影响的——删除单据、批量改期、BOM 版本切换、停机指令、权限变更。人工确认界面要同时给出建议依据、影响预览与修改入口，只有「确定/取消」的确认框起不到把关作用。

Q：给智能体开权限，要注意什么？

四条：独立服务账号，不借用人用的管理员账号，否则日志里分不清哪次是系统改的；最小权限，按本次开放的动作清单逐项授权，清单外不授予写权限，清单写进交付文档；动作留痕，日志能回答「谁、何时、依据什么、把什么从什么改成了什么」，与业务单据同生命周期保存，质量与账务相关动作还要记录人工确认人；失败回退与一键停用，接口超时是重试还是转人工、部分成功怎么回滚要事前约定，上线头两个月出现误判时能单独关掉某个自动动作而不必整体停用。新增自动动作必须走变更评估与测试，不能在后台随手勾选放开。

Q：工厂上 AI 智能体大概要多少钱、怎么起步？

参考区间（软件加实施口径，模型调用、硬件与年运维另计）：问答与建议级单点应用约 3~15 万，周期 1~2 个月；含执行级动作、独立账号权限与审计日志的岗位级应用约 15~50 万，周期 3~6 个月；跨系统多岗位统一动作治理约 50 万以上，6 个月起。成本大头在流程梳理、权限设计与接口改造。起步不要做「全厂智能体平台」：选一个岗位、一个高频、可逆的动作闭环（如异常自动归类分派，只生成待办不改单据），跑满四周，用自动生成条数、采纳率、误报率与异常响应时长决定下一步，再按动作清单逐项扩展。均为区间表述，实际以动作数量与接口范围勘察为准。