ARTICLE · 983857
当AI Agent成为工业软件用户:船厂该先改界面,还是先改数据?
假设一个工艺员收到一句指令：“把这次设计变更涉及的托盘和生产任务找出来，列一张需要确认的清单。”
今天，人会在PLM、物料系统、计划系统和共享文件夹之间来回查找。明天，一个智能体或许能完成大部分检索：先识别变更对象，再沿产品结构和工艺路线追踪，最后生成一张待确认清单。
真正变化不在于它会说中文，而在于它第一次成了工业软件的“用户”。它不需要点击菜单、看懂图标，却要读懂对象、状态、版本、权限和例外。过去围绕“人机界面”设计的PLM、ERP、MES，开始出现另一种使用方式：人提出目标，Agent通过接口和工作流完成受控操作。
这不是一句“以后不用页面了”。人仍然需要页面来判断、审批、追责和处理例外。但对船厂而言，软件建设的重心会慢慢从“页面是否好用”，延伸到“机器能否安全、稳定、可审计地使用这些系统”。
机器用户不看菜单，它只看得懂契约
图1：人依靠页面理解业务，机器依靠受控接口调用同一业务服务。
人可以容忍系统里的模糊：同一个分段有两个常用叫法，型号写错一个字符也能凭经验猜出来；一张图纸放在共享盘里，工程师知道应当找哪个目录。机器不具备这种默认常识。
它需要一份更严格的“契约”：对象叫什么，唯一标识是什么，版本何时生效，状态能不能读取，关联由谁维护，接口在什么条件下返回什么结果。OPC UA（OPC Unified Architecture）信息模型的思路很有启发性：信息模型不是单纯的数据表，而是应用之间对结构、行为和语义的共同约定。
把这个思路放到船厂，分段、区域、系统、托盘、物料、图纸、变更单、工作包不只是字段名；它们还必须有能被程序稳定识别的身份与关系。比如“某分段受变更影响”不能只存在于一段文字里，而应能追溯到哪份变更、哪个有效版本、哪些结构或工艺对象，以及关系的建立时间。
这也是为什么给PLM加一个问答框，不等于拥有了“Agent-ready”的PLM。聊天框可以帮人找到资料；真正的机器用户还需要系统提供可读取、可验证、可限制的业务能力。
先改四种能力，不要先画一张Agent架构图
图2：数据语义、业务接口、状态事件和可执行规则共同构成机器可用基础。
第一种是机器可读的数据语义。船厂不需要一夜之间统一所有编码，但至少应为高频对象建立明确的主键、版本和关系规则。没有这个基础，Agent只能根据文本相似度“猜”关联，结果很难拿去推动工程动作。
第二种是稳定的业务接口。不要让智能体去模拟工程师点击页面。页面会改版，按钮会移动，异常提示也可能是给人看的。更可靠的做法，是让系统以接口提供“查询有效图纸”“获取变更影响对象”“草拟审批单”这类具体能力。读、建议、草拟、发起、执行应当是不同等级的接口，而不是一个万能账号。
第三种是事件和状态。Agent不只需要知道当前数据，还要知道发生了什么：图纸何时发布、物料何时替代、采购何时确认、检验何时不合格、任务何时冻结。如果企业系统只提供最终结果，没有事件和状态变化的记录，智能体就很难解释它为什么在某个时刻提出某项建议。
第四种是机器可执行的规则。例如，什么情况必须由工艺确认，什么情况可以自动生成待办，哪些变更一旦影响开工任务就必须升级，哪些异常绝对不允许写回系统。规则不必全部复杂化，但必须从口头习惯、邮件和会议纪要中抽出一部分，变成可以检查、可以版本化的约束。
这四种能力不比训练模型“酷”，却决定了智能体是一个可控的新岗位，还是一个随时可能误解上下文的自动化脚本。
“人—菜单—页面—数据库”的链条会怎样变化
图3：机器负责归集与组织证据，工程师继续承担判断和确认责任。
过去的工业软件常遵循一条很稳定的路径：人选择功能，填写表单，系统校验并写入数据。以后更常见的路径可能是：人表达目标，Agent调用受控工具，工具执行既有业务服务，系统留下操作记录，再把需要判断的部分交给人。
这里的关键不是把人从链条里拿掉，而是重新分工。机器适合跨系统搜集、比对、归类、草拟和监控；人仍然负责目标取舍、工程判断、责任确认和例外处理。一个成熟的船厂场景，可能不是“Agent自动批准变更”，而是它把80份相关记录按证据强弱排好，指出缺失的版本，再把最终确认交给专业工程师。
因此，未来工业软件的重要用户之一可能确实是Agent，但这不代表用户体验不重要。恰恰相反，人机界面会从“录入窗口”变成“决策窗口”：显示机器读了什么、依据了什么、建议做什么、哪里不确定、谁需要接手。对管理者来说，这种界面比一段流畅回答更有价值。
最容易被忽略的不是API，而是权限的颗粒度
图4：读取、草拟、发起和执行必须拆成不同权限，关键动作由人工放行。
很多系统只有两种身份：能进系统，或不能进系统。这套设计服务人时尚可勉强使用，交给机器用户就太粗了。
船厂至少应区分：能否读取受控对象；能否看到脱敏字段；能否生成草稿；能否发起流程；能否写入状态；能否执行不可逆动作。每种权限还应绑定范围，例如特定船型、项目、专业、时间窗口或审批级别。
公开的企业Agent实践强调了护栏、批准动作、模拟评估和人工升级机制。这些并不是某一家软件的专属做法，而是一个朴素原则：当系统开始跨业务边界执行动作时，授权和回退必须比回答质量更先被设计。
NIST《人工智能风险管理框架》（AI Risk Management Framework，AI RMF）也把可信、可靠、可解释、安全和治理放在从设计到部署、使用和评估的全流程里。对船厂的翻译是：不要只问“这个Agent能否打通系统”，还要问“它在什么条件下不能打通，谁能看到它停下来的原因”。
给正在建设PLM、MES或数据平台的船厂三条提醒
图5：数据对象、受控服务与审计机制应围绕一个小范围业务闭环共同设计。
第一，不必为了Agent推倒现有系统。先挑一个业务动作做“机器可用性体检”：对象标识是否稳定，版本是否明确，接口是否能读，事件是否留痕，异常是否有归属。这个检查本身就能暴露数字化基础的缺口。
第二，把接口当作产品能力，而不是项目组的临时通道。临时脚本可以跑通演示，却难以承受版本迭代、权限审计和跨项目复用。未来真正有价值的工业软件能力，会是那些可被人、报表、自动化流程和Agent共同调用的业务服务。
第三，不要一开始就设想多智能体协作。先让一个小范围的Agent只读运行：给出影响清单、来源链和不确定项，再和人工结果并行对比。只有当它能稳定地“少做错、说清楚、及时停下”，才讨论发起流程或写入系统。
编辑判断：Agent时代最稀缺的不是“会调用大模型的工程师”，而是既懂船舶工程对象、又能把对象关系和业务边界说清楚的人。因为模型与工具会持续变化，真正长期留在船厂里的，是那套被定义、被审计、被维护的工程语言。谁先把这门语言做成机器可读的契约，谁就更有机会把AI从演示屏带进日常协作。
参考来源
OpenAI：Introducing OpenAI Presence（2026-07-22） OPC Foundation：OPC Unified Architecture Core OPC Foundation：OPC UA Part 5 — Information Model NIST：Artificial Intelligence Risk Management Framework（AI RMF 1.0）