高混合、小批量的产线要求频繁重编程，而静态程序永远列不全所有可恢复的异常——尤其是“方法返回成功、物理上却没动作”的静默故障。arXiv 上这篇《LLM-Driven Multi-Agent Control for Skill-Based Smart Manufacturing》把这个问题搬进了一座七个模块的六边形仿真工厂：六边形传送带做主干，六个外围工位各配一个独立的 LLM 智能体，模块技能通过 MCP 工具服务器暴露成 OPC UA 方法调用，智能体之间用 MQTT 通信，实时工厂状态在每次推理前注入上下文。作者用九道复杂度递增的生产题，比较了编排器、点对点、单体三种架构。
模块即工具：MCP 包住 OPC UA 方法
技能化制造把设备功能拆成一个个可调用的技能，OPC UA 的方法（method）正好是这些技能的标准化入口。论文的做法是给每个模块单独配一个 MCP 服务器，服务器是唯一知道 OPC UA 端点地址和方法签名的组件；LLM 只看到工具名、描述和参数结构（schema）。这样替换或扩展某个模块的功能，只需要更新它自己的 MCP 服务器，上层编排逻辑不用动。作者强调这条原则与协议无关：任何能通过 OPC UA 暴露技能的生产系统都能照搬。
MQTT 上的三种组织方式
编排器架构里，中央智能体掌握全局视图，把任务派给六个模块智能体；点对点架构没有中心，模块之间直接发消息；单体架构则是一个智能体握着所有模块的工具，论文把它比作“LLM 驱动的 MES”。产线产品是一块板上最多五块木块，涉及装配、旋转装配、检测、回收、交付等技能。智能体用 Gemma4:31B 本地推理（Ollama，Q4_K_M 量化，约 20GB 显存），温度设 0.3，每道题跑 10 次。
状态注入与工具白名单
两个工程细节值得注意。一是状态跟踪器：每次技能完成事件经 MQTT 回来，就更新板位、皮带占用、料仓库存和检测结果，再把结构化快照前置到提示词里，LLM 不必从对话历史里自己重建世界。二是 ToolAvailabilityManager：它按当前状态筛出物理上合法的工具再发给智能体，比如板还没进检测模块，检测工具就不会出现在列表里。这等于把前置条件检查从模型推理挪到了外部逻辑。
九道题的结果：没有全能架构
前五道基线题三种架构都是 100%，第六题（两张订单并行）在 90%–100%。真正的分水岭是第 7–9 题的三类静默故障。第 7 题第一个装配模块全是坏料，编排器只有 20%：它陷入装配与检测智能体之间的循环，始终没想到换模块，单次失败平均烧掉 1997k token、1050 秒；单体智能体则十次全部自行切到备用模块，推理轨迹里甚至出现了“要不要试试 2 号边的装配模块”这种自发诊断。第 9 题传送带静默卡死，情况反过来：只有编排器 100%，因为它的全局视图能看出顺时针路径不通、改走逆时针；单体架构 40%，点对点 50%。总体解决率单体与点对点都是 93%，编排器 87%。
成本排序也不同：单体最快（163 秒），点对点最慢（353 秒），但点对点最省 token（222k），编排器平均最贵（375k），且几乎全部由第 7 题的循环失败贡献；在它擅长的题上，token 只有 44k–181k。消融实验显示，去掉状态注入后总体解决率从 93% 降到 88%，第 9 题从 40% 降到 20%——模型分不清是硬件真故障还是自己推断错了状态。
这篇论文的价值不在于宣布哪种架构赢了，而在于把“LLM 直接控产线”拆成可测的三件事：标准化的工具接口、结构化的智能体拓扑、外部注入的实时状态。三者组合起来，静默故障诊断可以是涌现行为，而不是预先写死的分支。
资料来源：LLM-Driven Multi-Agent Control for Skill-Based Smart Manufacturing — arXiv（2026-10）。本文为技术要点整理/编译，非原文全文。