愿景：会对话、可以自优化的工厂

​

看了 SUPCON 的 workshop 之后深受感动，如果工厂能用云原生技术构建，那即使是工业，也可以享受软件技术带来的快速迭代（可能不适用高危化工业，但也足够开始畅想了）。对于重组装的工厂，完全可以像电车一样 OTA 升级，单纯用云上的软件升级来控制控场。即使是化工，也可以畅想先使用一个足够真实的虚拟工厂测试 OTA 升级，像软件一样，跑通所有 dev 环境的测试用例后，推送到生产环境。

在这个系统中，机器不再是孤立的执行者，而是能够“对话”的智能体：“我这边快满了，暂停投料。” “收到，我先缓一轮。”

​

我们的目标是构建一个智能调度大脑，利用 Agent 技术，让虚拟工厂的生产效率最大化。

​

​

## 探索之路：从规则到智能的迭代

我们的开发过程遵循了从简单到复杂、从稳固到智能的演进路径，最终做出了三个版本的调度器：

###V0: 基于低代码平台的 EventFlow 实现

尝试了之后发现在从 Eventflow 发往本地的时候出现问题，认为代码更容易调试，切换成了基于 Python。

V1.0: 基于规则的调度器 (task_scheduler.py)

实现: 这是我们的起点。我们实现了一个简单但可靠的基于规则的调度方案。该方案为两台 AGV 划分了明确的责任区：AGV1 负责运输左侧产线的物料，AGV2 负责右侧。此版本逻辑清晰、行为可预测，为整个系统打下了稳定的基础。

​

表现:在基础工况下运行稳定，能够获得约 50分的 KPI。

​

局限: 灵活性差，无法处理 Product 3 等复杂或动态变化的生产需求（在到达 QC 后运回工作站 B 重新处理），也无法处理QC不过关的情况。是典型的“指令式”而非“自适应”系统。

V2.0: AI Agent 驱动的调度器 (task_scheduler_ai.py)

• 实现: 这是我们项目的核心创新。我们将调度逻辑升级为 AI Agent 架构。这个 Agent 旨在拥有更全局的视野和更动态的决策能力。它不再依赖僵化的“if-then”规则，目标是根据整个工厂的状态综合判断，动态地为任何可用的 AGV 分配最高优先级的任务。

​

• 挑战与洞察: 在实现过程中，我们遇到了工业级 Agent 开发中的典型挑战：

• 状态同步难题: 在长时间运行中，我们观察到 Agent 本地维护的工厂状态与服务端偶尔会出现不一致，导致决策失误。这暴露了在分布式系统中保持状态一致性的重要性，是未来工业 Agent 走向生产环境必须解决的关键问题。

• supOS 平台探索: 我们最初尝试使用 eventflow 进行消息处理，但在本地调试中遇到了消息路由问题。为了快速推进，我们切换到了更底层的 sourceflow 和 uns namespace，直接处理 MQTT 消息，这加深了我们对 supOS 数据流转机制的理解。

​

• 表现: 尽管存在状态管理的 Bug，AI Agent 在运行平稳的阶段（在运行了 10 多次后平均在 400 模拟秒之前），其决策效率和灵活性明显优于规则版，在稳定阶段最高能导 73 分KPI，在约 400 模拟秒后，服务和本地状态不统一且错误高发后，AGV卡住不能工作，KPI逐渐降低到 50 分左右。如果做好状态管理和错误处理，有希望冲击更高的分数。

总结与展望

这个项目成功验证了 AI Agent 在工业调度场景中的可行性。我在虚拟环境中简单构建了一个可运行的系统，而且让我通过实践识别了从原型到工业级应用的一些关键（如状态管理、秒级的响应）。

未来还需要提升的地方有：

• 增强 Agent 状态管理: 引入更鲁棒的状态机或校验机制，确保与服务端状态的强一致性。

• 融合 LLM 决策能力: 将 LLM 融入决策环路，让 Agent 能够理解更复杂的自然语言指令（如“优先处理紧急订单”），甚至进行多 Agent 间的协商。现在只能实现单个 Agent 接单，比如让生产线 agent 意识到有新订单，需要让 AGV 取订单。

• 深度利用 supOS: 修复 eventflow 的问题并加以利用，或探索使用 Node-RED 进行更便捷的可视化流程编排。