当大模型智能体真的被放进车间去编排生产，一个工程问题立刻浮出水面：智能体之间该怎么分工？是由一个”总调度”统管全局，还是每个工位自治、彼此直连，抑或干脆让一个智能体掌控所有设备？一篇针对模块化智能工厂的研究给出了可复现的答案——三种架构各有所长，没有哪一种在所有指标上占优。
每个模块配一个智能体与一个工具服务器
研究的核心设计是”模块—智能体—工具服务器”一一对应：工厂的每个模块都配一个专属的大模型智能体，以及一个 MCP（Model Context Protocol）工具服务器，把该模块的技能封装成可通过 OPC UA 方法调用的工具。MCP 服务器是唯一知道 OPC UA 端点地址和方法签名的组件，智能体只看到工具的名称、描述与参数模式。这样替换或扩展某个模块的功能时，只需更新它自己的 MCP 服务器，编排逻辑不必改动——这正是”技能化制造”强调的关注点分离。
智能体之间通过 MQTT 发布/订阅协同。相比 OPC UA 传统的客户端—服务器模式，发布/订阅让智能体通过 broker 解耦，新增智能体无需改动既有节点，主题路由天然支持一对多广播。第三个关键机制是实时状态注入：内部状态跟踪器根据 MQTT 上的技能完成事件，维护板材位置、皮带占用、料仓库存与检测结果的实时快照，并在每次推理前作为结构化上下文块前置到提示词中。状态还驱动动态工具约束——可用工具管理器按当前状态筛出物理上合法的工具，避免模型调用必然被控制器拒绝的操作，例如板材尚未装入模块就发起检测。
三种架构，九道考题
实验在一个六边形模块化工厂的 Python 仿真中进行，包含六条外围产线与一条作为骨架的环形皮带，产品是一块板上最多五个、共十种类型、可 0 或 180 度放置的木块。九道生产挑战从单模块单类型订单，逐步加到双模块带旋转、料仓补料、回收再装配、双订单并行，最后三道是”静默故障”：整仓来料全为次品、装配模块报告成功却未放料、皮带报告移动成功但板材原地不动。
三种架构分别是：编排式（中心智能体掌握全局视图，向模块智能体分派任务）、对等（模块智能体直接通信，无中心协调者）、单体（一个智能体直接控制所有模块，类似大模型驱动的 MES）。每道挑战跑 10 次，模型为本地部署的 Gemma4:31B，温度设为 0.3 以便在静默故障场景中探索不同的恢复策略。
结果：解出率、时延与 token 的三重权衡
前五道基础挑战，三种架构均达 100% 解出率；双订单并行的第六题也都在 90%—100%。真正的差异出现在静默故障。单体与对等架构的平均解出率最高，均为 93%；编排式为 87%，但它是唯一在皮带静默故障（第九题）上做到 100% 的架构——全局视图让它识别出顺时针路径被阻断，从而改走逆时针。相比之下，单体架构在第九题只有 40%，对等架构 50%，后者的问题在于故障信息需要跨智能体传播，诊断被稀释。
速度与成本呈现另一组权衡：单体最快，平均 163 秒，因为没有智能体间消息开销；编排式 279 秒；对等最慢，353 秒。token 消耗顺序几乎相反：对等最少（约 222k），单体 312k，编排式 375k——后者主要被第七题的循环失败推高，单次运行曾消耗 1997k token。所有架构中，输入 token 占总量的 92%—98%，这正是把工厂状态与对话历史注入每次调用的代价。按云端定价折算，简单挑战不足 0.01 美元，最坏的循环失败约 0.26 美元。
一个消融实验值得注意：仅对单体架构去掉状态注入，解出率从 93% 降到 88%，第九题从 40% 降到 20%，说明智能体难以仅凭动作历史还原物理状态、区分真实硬件故障与错误推断。而所有架构都在没有任何显式故障处理代码的情况下表现出”涌现”的故障诊断行为，例如单体智能体自问”也许该试试另一个装配模块，以防 1 号边缘在生产次品”。
可复用的结论
没有全能架构：单体结构简单、执行快，但上下文膨胀会限制其扩展到更大工厂；编排式擅长全局路由、在其擅长的题目上 token 最省，却存在单点失效风险；对等架构最省 token、对孤立模块故障表现好，但缺少全局重规划，跨边界故障时力不从心。研究者提出的改进方向是为对等架构加共享记忆库或全局广播通道。对工程团队而言，选择架构前应先明确故障主要发生在模块内还是跨模块，以及 token 预算与响应时限谁更紧。
资料来源：LLM-Driven Multi-Agent Control for Skill-Based Smart Manufacturing — arXiv（2026）。本文为技术要点整理/编译，非原文全文。