在工厂里，一条由智能体生成的处置建议，如果工程师没法复述它的推理路径，基本不会被采纳。这跟模型准不准关系不大，问题出在责任上：建议一旦落地，承担后果的是工程师，不是模型。2026年GTC的制造业分享里，STW61072场次把标准定得很直白——要交付的是“工程师愿意信任并使用”的智能体工作流。这句话的分量，比任何架构图都重。
先嵌进工程师已有的判断框架
该场次以SPC（统计过程控制）应用作为线索，这个选择本身就说明了路径。统计过程控制是制造工程师熟悉的方法论，控制图、判异规则、处置逻辑在他们脑子里已经成型。智能体介入这套框架，做的是读取设备数据、比对工艺参数、给出异常处置建议，工程师能用自己的语言校验它，信任就有落脚点。反过来，如果一个智能体另起一套黑箱判断，即便结论正确，工程师也只能选择相信或不信，无法验证。信任的前提是能被检验。
可解释只是底线，可追责才是门槛
公开分享中提到的工具适用范围与边界，值得注意。厂商自己都在强调工具不是通用解法，企业在评估时更该把边界问清楚。具体到落地，至少三类信息必须在合同或方案里写明：智能体可以读写哪些系统、每次执行的日志保留多久、错误建议的责任如何归属。
与之配套的是编排层的工程细节。智能体要完成“读取数据—比对参数—生成建议—触发工单”这样的任务链，中间任何一步异常，都需要明确的失败回退和人工接管机制。工程师愿意放手，不是因为它从不犯错，而是因为犯错时系统会停下来、会留痕、会交回给人。权限分层、审计日志、关键节点人工确认，这些听上去不性感的机制，才是信任的实际载体。
用流程指标验收，别用模型指标
还有一个容易被忽略的环节：怎么算成功。以模型准确率验收，工程师会觉得这套系统与自己无关；以可观测的流程指标验收——异常是否被更早发现、处置是否更快闭环、误报由谁复核——工程师才会把它当成工位上的工具。前者是实验室语言，后者是车间语言。
工厂智能体的信任问题，本质上是一个组织问题：谁消费输出、谁复核事件、谁承担后果。把这三件事在项目启动前谈清楚，比在架构评审时争论用哪一层组件更有价值。工具会换代，责任分工留在流程里。