AI 原生智能制造，与“大模型 + 智能体外挂”究竟差在哪里？

先说结论：差别不在有没有智能体，而在智能建立在哪里

今天很多工业 AI 方案看起来十分相似：接入大模型，配置几个智能体，再给智能体开放知识库、数据库查询或系统接口。演示时，它们都能回答问题、生成报告，甚至调用工具。

因此，判断一套方案是不是 AI 原生，不能只看它有没有大模型、智能体或工具调用。真正需要检查的是：

当模型被拿掉之后，工厂的对象语义、业务规则、动作边界、证据链和审计能力是否仍然存在。

如果这些能力主要依赖提示词、智能体记忆和某套编排流程，那么智能仍停留在应用表面。模型一换、场景一变，业务语义与安全边界往往要重新解释。

如果这些能力已经成为系统本身的契约，模型只是受治理的推理组件，那么系统才具备持续承载 AI 的基础。

两类方案分别解决什么问题

为了避免把概念绝对化，可以先公平地看两类方案各自擅长什么。

大模型 + 智能体外挂的常见起点，是让模型连接已有文档、页面、接口或数据库，快速获得问答、检索、总结和任务编排能力。它改造范围小，适合验证需求，也适合后果较轻的辅助场景。

AI 原生架构的目标，则是让生产对象、业务事件、规则、权限、动作和审计从设计上就能被人、应用与 AI 共同理解和调用。它关注的不只是“模型能回答什么”，还包括“依据是否可靠、动作能否治理、结果如何回到业务系统”。

两者不是简单的先进与落后之分，而是面向不同深度的问题。

这张表描述的是两种典型形态，不意味着所有外挂方案都缺少治理，也不意味着贴上 AI 原生标签就自然具备这些能力。最终仍要看可以检查的系统结构和运行证据。

为什么从“回答问题”走向“参与业务”后，差别会迅速放大

在只读问答场景中，模型答错一次通常可以由人发现并纠正。此时，文档检索加人工复核往往已经足够。

但当 AI 开始参与异常判断、计划调整、质量处置或跨系统协同时，问题会发生变化：

• 它理解的业务对象是否与系统中的真实对象一致？
• 它看到的是当前状态，还是过期缓存和临时拼接的数据？
• 一条建议依据了哪些数据、规则和版本？
• 操作人驳回建议后，原因是否会被结构化保留？
• 接口超时后重试，会不会产生重复动作？
• 用户有权咨询，是否也有权执行？
• 模型更换以后，原有权限与审计边界是否仍然有效？

这些问题无法只靠“提示词写得更严谨”来解决。它们需要数据合同、状态机、权限、事务、幂等、审计和人在环共同承担。

因此，AI 原生的价值不是让对话界面更像人，而是让 AI 从获取事实到提出建议、再到受控动作的整条链路都可以被验证。

旁路接入，不等于只做外挂

“旁路”与“外挂”经常被混为一谈，但它们其实在回答两个不同问题。

旁路接入回答的是系统部署在哪里。 为了不干扰既有生产与控制系统，新能力可以部署在旁边，通过只读数据、事件订阅和受控接口接入。这是一种风险隔离方式。

只做外挂回答的是能力沉淀在哪里。 如果业务语义只存在于智能体提示词中，动作只是临时脚本，治理依赖模型自觉，那么无论组件部署在旁边还是嵌入原系统，都仍然属于表层智能。

判断一个旁路系统是不是 AI 原生扩展，可以检查四件事：

1. 是否有独立、稳定的数据与事件合同。 接入不依赖模型临时理解页面或猜测字段含义。
2. 是否建立了共享对象语义。 同一个业务对象在人、应用和不同模型之间具有一致身份、状态和关系。
3. 是否有受治理的动作面。 权限、前置条件、幂等、人工确认和审计由服务端保证，而不是写在提示词里。
4. 是否形成业务结果闭环。 建议被采纳还是驳回、实际结果如何，都能回到可追踪的业务记录中。

满足这些条件，即使不替换既有 MES、ERP、QMS 或其他生产应用，旁路层也可以逐步成为企业的 AI 原生能力层。

AI 原生不是让模型越过控制边界

工业 AI 架构必须明确区分三个层次：

• 生产经营与业务决策层：计划、质量、能效、追溯和协同等应用，可以通过规则、证据和人在环逐步增强；
• 基础控制层：DCS 与 PLC 按既定控制逻辑运行，AI 默认只读取经批准的数据，不绕开原控制程序；
• 安全保护层：SIS 及其他独立安全机制保持独立，不由通用大模型或智能体替代。

对于需要改变业务状态或提交参数建议的场景，动作应经过服务器端白名单、身份权限、前置条件校验、人工确认、审计和失败收敛机制。

如果某个场景确实希望进入自动闭环，也必须按控制工程项目单独进行危害分析、控制策略验证、失效设计和变更审批。不能因为智能体具备工具调用能力，就默认它具备控制权限。

采购与技术评审时，可以要求对方现场回答这些问题

判断架构时，不必争论术语，可以要求对方演示或提交证据：

1. 拿掉当前大模型后，还剩下什么？ 对象模型、规则、权限、动作接口和审计是否仍能独立运行？
2. 更换模型要改哪些部分？ 是只替换模型适配层，还是要重写业务流程与安全规则？
3. 能否回放一条建议？ 是否能追溯到源数据、数据时间、规则版本、模型版本、人工确认和最终业务结果？
4. 权限在哪里执行？ 是提示词告诉模型“不要越权”，还是服务端在每次动作前强制检查？
5. 失败怎样收敛？ 接口超时、响应丢失和重复提交时，是否能避免重复动作并得到确定结果？
6. 知识能否带走？ 对象、规则、SOP 和动作契约能否以结构化方式导出，而不是只能留在某个模型或向量库里？
7. 控制边界是否清楚？ AI、MES、DCS、PLC 和 SIS 分别承担什么职责，哪些路径只读，哪些动作必须人工确认？
8. 旁路层是否产生新的数据孤岛？ 新的判断与业务结果会回写到统一记录中，还是长期停留在聊天记录和独立报表里？

怎么选择：先看任务深度，再决定建设深度

如果企业当前目标只是内部知识问答、文档检索、会议总结或低风险信息辅助，智能体外挂通常是合理且高效的起点。没有必要为了一个简单问题先建设完整底座。

如果目标开始涉及以下任一情况，就应认真评估 AI 原生能力：

• 一个判断需要跨多个系统拼接事实；
• 同一业务对象在不同系统中口径不一致；
• 建议需要转化为受控业务动作；
• 结论必须经得起复核、审计或责任追溯；
• 企业希望未来更换模型而保留既有知识与治理资产；
• 新场景不断增加，不希望每次都重新映射数据与编写提示词。

实际建设也不必“大爆炸式替换”。可以先用外挂方式验证问题，再把被证明有价值的对象、事件、规则和动作逐步沉淀为系统契约。

适用边界：AI 原生不是所有场景的必选项

AI 原生架构需要额外的前期工作，包括对象梳理、数据合同、动作治理、异常处理和验收设计。对于后果轻、生命周期短或不需要进入业务闭环的场景，这种投入未必必要。

它也不会自动解决源数据缺失、流程责任不清或组织协同不足。架构只能让这些问题更早暴露，并提供可治理的承载方式，不能代替企业完成业务定义。

因此，更稳妥的判断不是“要不要全部 AI 原生”，而是：哪些能力只是临时辅助，哪些能力将进入生产经营主链路；后者是否已经拥有可以长期保留的系统契约与安全边界。