政策在谈软件智能化，企业要回答的是“怎样进入现有流程”
2026年9月11日，工业和信息化部发布《“人工智能+软件”专项行动实施方案》。官方提出推进基础软件、工业软件智能化升级，培育智能体软件，并在重点行业打造100个智能体软件标杆应用。当天发布会进一步提出，软件由“被动响应”向“主动执行”转变，服务由产品交付向价值交付转变。
这些是可核验的政策事实。对白泽而言，更重要的工程问题是：制造企业已经有MES、ERP、WMS、QMS和设备系统，怎样让AI Agent调用这些能力，而不是再造一个新的信息孤岛？
我们的判断是，多数企业不应先替换核心系统，也不应让大模型直接连接数据库或PLC。优先任务，是把现有软件整理成一层可发现、可授权、可验证、可审计的“能力层”。Agent负责理解意图、组织信息和提出动作；能力层负责把动作约束为明确接口；原业务与控制系统继续保存事实、事务和安全边界。
软件“加一个聊天框”为什么不等于智能化升级
把企业知识接进RAG，让员工能问SOP、查报表，是有价值的第一步。但如果要让Agent真正处理一批质量异常，它至少要读取质检结果、确认物料批次、检索处置规则、创建隔离单、通知责任人，并在审批后更新库存状态。
如果Agent只有数据库账号，它既不知道哪些表是权威来源，也不知道当前用户能否创建隔离单，更无法证明一次写入是否重复执行。所以软件智能化不是把自然语言翻译成SQL，而是把“查什么、能做什么、谁能做、在什么条件下做、做完如何核对”变成机器和人都能理解的契约。
Agent可调用能力层，至少包含五类契约
业务对象契约
设备、工单、物料、批次、缺陷和人员要有稳定身份，并明确主数据来源。来自IoT的设备编号、MES工位编号与ERP资产编号需要映射，否则同一台设备会被理解成三个对象。
动作契约
把“创建维修工单”“查询在制品”“申请质量放行”等能力封装成有输入、输出、错误码和幂等键的接口。接口表达业务动作，而不是把任意SQL或通用脚本暴露给模型。
权限契约
模型能提出建议，不代表当前用户有权执行。每次调用要带用户、角色、工厂、产线和数据范围，由确定性权限服务重新校验；高风险动作需要审批、双人复核或现场确认。
证据契约
判断要关联来源：哪一版SOP、哪个传感器时间窗、哪条质检记录、哪个模型版本。RAG研发返回的文本用于解释和辅助判断，事务状态仍以业务系统为准。
执行契约
调用前检查前置状态和参数边界，调用后读取权威系统确认结果，并记录请求、审批、执行、回执和异常。超时不能直接重试写操作，要先用幂等键查询远端状态，避免重复建单或重复扣料。
一条可落地的架构：读、判、批、写、验分开
在“全域感知→认知理解→智能决策→受控执行”链路中，设备和业务系统持续产生数据；事件层把信号转成带时间、对象和证据的业务事件；RAG与模型负责解释当前情况；Agent根据已登记工具生成计划；权限与策略网关判断能否执行；适配器调用MES、ERP、WMS或工单系统；最后再读回权威状态完成核验。
这一架构有两个关键边界。一是读写分离：查询类工具可以先开放，写操作必须逐项登记风险、权限、审批和回滚。二是AI与安全控制分离：人员与设备安全的联锁、急停、速度和位置限制继续由PLC、安全控制器和确定性状态机承担，不能交给概率模型。
OPC Foundation在2026年4月宣布，将OPC UA配套规范转换为面向RAG、MCP与AI工程流程的形式，目标是让OPC UA成为Agentic AI与工业自动化之间的语义层。这说明行业正在补“让AI读懂工业对象”的基础，但企业仍需结合自身主数据、权限和流程建立本地契约，不能把标准等同于现成业务系统。
从一个“最小能力闭环”开始
不要一开始做万能Agent。选择一个高频、边界清楚、结果可核对、失败可恢复的流程，例如设备告警后的维修工单建议。
第一步，把目标写成业务结果：缩短从告警到受理的时间，同时不增加错误工单。第二步，限定上下文：设备身份、最近告警、当前工单、适用SOP和备件状态。第三步，先做只读建议，让一线人员确认设备、原因和方案。第四步，只开放“创建草稿工单”一个写工具，并设置必填字段、幂等键与审批。第五步，读取工单系统确认远端ID和状态。第六步，用人工采纳率、字段完整率、重复工单率、平均受理时间和越权拦截率验收。
如果这条流程跑通，再复制到质量隔离、备件申请或排产异常。每增加一个工具，都要同步增加权限、测试、审计和故障处理，而不是只增加提示词。可以结合既有工业智能体闭环和云边端推理架构，分别约束执行安全与部署位置。
验收智能软件，不只看“任务完成率”
建议把指标分成四组：业务结果包括处理时长、一次受理率和人工返工；工具质量包括参数正确率、幂等命中与远端状态核验；安全治理包括越权拦截、审批覆盖和敏感字段暴露；运行质量包括P95响应、超时恢复、审计完整率和版本回滚。
还要做反例测试：用户故意要求绕过审批，知识库返回过期SOP，MES接口超时但实际已建单，同一事件重复到达，设备身份映射错误。系统能否拒绝、追问、降级或转人工，比顺利演示一条理想流程更接近生产验收。
对重庆制造企业的行动建议
工信部的政策信号已经从“软件里增加AI功能”走向软件产品、交付模式和智能体形态的系统升级。重庆也在推进人工智能与制造业全流程融合。企业此时最有价值的准备，不是采购一个更大的模型，而是盘点核心系统能提供哪些可验证能力。
可先完成三张表：业务对象与权威来源表、可调用动作与风险等级表、结果验收与异常处置表。对外部重庆AI开发、RAG研发或系统集成团队，也应要求交付接口契约、权限矩阵、评测集、审计记录和回滚方案，而不仅是一个能对话的Demo。
AI只有进入真实流程、产生可验证结果才算落地。让MES与ERP成为Agent可调用的能力层，本质上不是推翻旧系统，而是给已有数字化资产补上语义、权限、证据和受控执行。
FAQ
企业要先替换MES或ERP，才能部署AI Agent吗？
通常不需要。先通过业务接口、事件总线和适配器开放边界清晰的查询与动作能力；只有核心系统无法提供稳定数据、权限或事务能力时，才评估局部改造或替换。
让大模型直接生成SQL，是否更快？
演示可能更快，生产风险更高。任意SQL难以稳定控制数据范围、写入副作用和审计。更稳妥的做法是提供面向业务动作的受限工具，并由权限网关和业务系统再次校验。
MCP能否直接解决工业软件集成？
MCP可以统一工具与上下文的描述和调用方式，但不会自动解决设备身份、主数据、权限、事务幂等、现场安全和结果验收。它是接口层的一部分，不是完整的工业治理方案。
第一个场景怎么选？
优先选择高频、边界清楚、可人工复核、失败可恢复且结果可从权威系统读回的流程。设备告警后的工单草拟、SOP检索与质量异常信息汇总，通常比自动修改控制参数更适合作为起点。
参考来源
1. 工业和信息化部，2026-09-11：《“人工智能+软件”专项行动实施方案》 →
2. 工业和信息化部，2026-09-11：《“人工智能+软件”专项行动实施方案》新闻发布会 →
3. 工业和信息化部办公厅，2026-01-07：《工业互联网和人工智能融合赋能行动方案》 →
4. OPC Foundation，2026-04-20：OPC UA Companion Specifications optimized for Agentic AI →
5. 重庆市人民政府，2026-08-21：《重庆市“十五五”人工智能发展规划（2026—2030年）》 →