Siemens工厂模拟：状态、工具可用性和消息控制，怎样影响故障恢复

输送命令报告成功，物料却没有移动。此时继续沿旧计划执行，或者反复调用同一动作，都可能让局部故障变成空转。Siemens 与慕尼黑工业大学的研究在六模块工厂模拟中注入这种静默故障，比较单体、中心编排与点对点协作。

这项研究的工程价值不只在三种架构的分数。它公开说明：模型看到什么状态，哪些工具在本轮允许调用，模块之间怎样交接，以及为何某种组织方式在一种故障中有效、换一种却失手。全部实验仍在模拟环境，不能据此批准实体设备运行。论文v1，§IV–VII

先把模块能力变成有限接口

模拟产物是一块最多装配五个木块的托盘，需要从投放、输送、装配到检查，再交付或回收。模块不能直接操作内侧输送带上的托盘：必须移到对应外侧位置并装载，才能执行装配或检查等能力。

每个模块通过 OPC UA 方法提供能力；OPC UA 是工业系统的类型化接口。MCP server 再把方法包装为模型可调用工具。只有适配层知道具体端点和方法签名，模型接收工具名称、说明和输入结构。这将设备接口变化与上层编排分开，而不是让模型理解所有设备内部细节。§IV-A、§V-A

论文表I给出了实际方法，而非一组泛化“执行工具”：

这些方法解释了一个关键依赖：模型的“下一步”必须对应当前托盘、位置和库存，不是只生成一条听起来合理的动作名称。表I、§VI-A

工具前提不全靠模型记住

模拟每次改变状态后，经 MQTT 发布事件，状态跟踪器更新托盘位置、输送占用、库存和检测结果。MQTT在这里承担发布／订阅消息传递，不负责替模型作生产计划。

当前快照会前置到每轮模型输入，模型不必仅凭整段历史重建现场。更重要的是，ToolAvailabilityManager 持续按模拟状态计算哪些操作有效，在推理前过滤工具清单。例如托盘还没有装入检查模块，就不提供检查工具。这是程序控制，不是一句“请只做合法动作”的提示。§IV-C、§V-B1、图4

可横向查看，点击打开原尺寸 ↗

图据论文v1 §IV–V重组：状态和调用关系来自模拟，不代表已验证实体工厂安全。

模型因此同时得到两种约束：快照解释现在发生了什么，可用工具限制现在能做什么。它仍需要决定采取哪项动作；状态系统也必须正确反映动作效果。实验中的环境真值来自模拟，论文没有证明同样的方法已解决真实传感噪声、工业网络延迟或设备安全联锁。

三种架构具体改变了什么

中心编排。一个骨干 Agent 掌握全局路线并控制输送带，六个专家分别操作模块。中心Prompt包含模块位置、木块类型、装卸协议和检测后的路由规则；专家Prompt包含本模块技能、位置与料仓。中心通过各专家专用的 command topic 下发任务，再订阅 reply topic接收结果。

专家收到任务后，带当前工具清单调用模型，经MCP执行工具，把结果回给模型继续循环；模型产生普通文本回复时，将回复发回消息通道，结束这一段请求／响应。这个局部循环结束不等于整个生产订单已交付。

点对点。只保留六个外围模块Agent，各自能操作相邻输送位置，并通过 send_message 给其他Agent发消息。输入消息作为带发送者标记的 user-role回合，加上当前状态进入同一工具循环。每Agent一把锁串行处理来信，防止多个同伴同时修改对话历史。

其Prompt包含可通信同伴、模块工具、订单片段与协调协议；这些是本实验的协作约定，不能直接当成生产授权系统。模块完成一步后把托盘交到下一边并通知下游，没有中心替所有模块维护统一重规划。

单体。一个Agent取得全部模块工具，同名方法加模块前缀。它的Prompt包含全布局、全部订单与投放到交付的流程；上下文和每轮工具预算比多Agent更大，并从历史移除过期工厂状态，减少窗口膨胀。

三者共用工具调用、状态注入和可用性控制，但承担的全局信息与消息责任不同。论文描述了Prompt内容，没有公布每套系统Prompt全文或全部运行参数，不能用这些说明反推一份“官方配置”。§V-B

两种静默故障，不能用一个平均分代替

实验有九项挑战，每项运行十次；使用Gemma4:31B（30.7B密集模型），经Ollama以Q4_K_M量化在RTX 6000 Pro Blackwell工作站GPU本地运行，温度0.3。作者选择本地推理，是为减少云端负载和网络对计时的干扰；没有把温度设为0，是为了让静默故障的重复运行能探索不同恢复策略。某个装配模块持续产生缺陷时，中心方案只完成两成，单体全部完成；作者观察到中心在装配与质检之间反复循环，没识别出应换模块。静默输送故障恰好相反：中心全部完成，点对点一半，单体四成。中心对运输网络的全局视角帮助它绕过阻塞。§VI–VII、表II

局部工具说成功、最终产品不对，以及移动工具说成功、位置没变，是两类不同的证据冲突。重复执行本身不会解决冲突；要先把结果与状态重新对照，才可能改变路径。

状态注入也有单独消融：单体总体完成率由不注入时的88%升至93%，同时增加token与时间。这说明明确状态有用，也有持续输入的成本；不是把更多历史永远保留就更可靠。论文报告输入占总token消耗92–98%，上下文管理因此会实际影响资源负担。§VII、表III

模拟成绩怎样支持下一次工程决定

没有一种架构同时主导成功率、时延和token。点对点在本实验中总体token较少，却承担消息开销和跨模块诊断传播问题；单体较快但上下文更重；中心有些任务很省，却可能陷入昂贵循环。六边形输送骨干本身还带有集中结构，不能把这次结果当作所有工厂拓扑的排名。

论文把先在模拟生成并验证序列、再交工程师批准用于物理设备，列为可能方向；并未完成这项实体迁移。普通调度或离线生成足以解决的任务，应保留为对照，而不是因出现模型就把所有控制搬到运行时。§VIII

自己的比较应先写清每项故障的预期状态、允许重试、停止或接管条件和交付证据。记录命令接受、动作观察与最终订单完成三个结果，再比较恢复时间、调用与资源。若当前系统只能知道“接口返回了成功”，还不能独立知道动作是否发生，就应先补状态证据，而不是扩大Agent数量。