从菜单式MES到工业智能体：基于Hermes Agent+MCP的智能助手实战指南（完整源代码）

目录为什么 MES 需要从“系统界面”进化为“业务助手”设计哲学：工业 Agent 不是套壳聊天机器人技术选型：为什么选择 Hermes Agent + MCP总体架构：四层解耦与认知-动作分离核心模块一：数据服务层，先构造一个可验证的工业世界核心模块二：MCP 工具层，把业务能力暴露为稳定契约核心模块三：Hermes Skills，把领域知识产品化核心模块四：前端交互层，让 Agent 执行过程可见一次完整请求如何流转：从自然语言到业务结论架构权衡：哪些能力应该放在代码里，哪些交给 LLM工业级落地逻辑：从 Demo 到生产系统的十个必答题踩坑复盘：真正消耗时间的不是大模型，而是契约细节演进路线：从查询助手到自主型工业智能体总结：Agent 落地的关键是把不确定性关进笼子项目源代码系统实现展示Web前端界面Hermes Cli界面手机飞书界面一、为什么 MES 需要从“系统界面”进化为“业务助手”生产执行系统 MES（Manufacturing Execution System）是连接企业计划层与车间执行层的关键系统。它承载工单、产量、质量、设备、人员、物料、工艺等大量实时数据，是工厂运行的事实中枢。但在很多工厂里，MES 的交互方式仍停留在典型的菜单式 GUI：操作员需要记住模块入口、筛选条件、字段含义和报表路径。一个看似简单的问题，例如：“A 产线最近 24 小时质量有没有异常？是不是和设备报警有关？”在传统系统中通常意味着：打开工单模块，筛选 A 产线与今日工单；打开生产模块，查看小时级产量和 设备综合效率OEE（Overall Equipment Effectiveness）；打开质量模块，导出最近 24 小时质检批次；打开设备模块，查报警设备与报警时间；人工对齐时间线，判断异常是否相关；将结论整理到日报或周报中。这背后不是单纯的“界面不好用”，而是存在更深层的语义鸿沟：系统懂数据，但不懂问题：MES 可以返回字段，却无法理解“谁在影响 OEE”。人懂业务，但被迫适配系统：调度员知道异常意味着什么，却要在菜单和表格里来回切换。数据分散，经验隐性化：质量异常、设备报警和产能下降之间的关联，往往沉淀在老员工经验中。反馈延迟：日报、异常复盘、班组交接依赖人工整理，无法形成实时闭环。因此，本项目的目标不是做一个“MES 查询聊天框”，而是让 MES 从被动数据库前端进化为一个能够理解自然语言、调用工具、综合判断并解释原因的工业业务助手。二、设计哲学：工业 Agent 不是套壳聊天机器人工业场景下的 AI Agent 有一个核心矛盾：大模型擅长理解与表达，但工业系统要求确定性、可追溯、可审计和低风险。如果直接把 MES 数据丢给大模型，让模型自由回答，短期 Demo 可能很惊艳，但很难进入生产。因为工业现场真正关心的不是“回答看起来像不像”，而是：数据从哪里来？是否调用了正确工具？计算逻辑是否可复现？报警和建议是否有业务依据？如果结论错误，能否追溯责任链？是否会越权读取或执行危险操作？所以本文采用的设计哲学可以概括为三句话。2.1 LLM 负责认知，工具负责事实LLM 适合做意图理解、语言组织、跨维度解释和报告生成；但不适合承担核心数值计算、阈值判断、权限控制和状态变更。例如“不良率是否超过 8%”“最近 3 小时是否连续上升”“EQ-003 是否处于 TEMP_HIGH 报警”这类判断，应当在 MCP 工具或后端服务中确定性完成，而不是让 LLM 凭自然语言推断。2.2 Agent 不直接访问数据库，而是访问经过治理的业务能力生产系统中不应让 Agent 直接拼 SQL 访问核心库。更稳妥的方式是：后端系统提供稳定 API；MCP Server 将 API 包装为业务工具；Hermes Agent 通过 Skills 学习何时调用工具；前端展示工具调用轨迹与结果。这样做的好处是每一层都可以设定边界，避免“模型绕过业务逻辑直接操作数据”。2.3 可解释性不是锦上添花，而是信任入口在工业现场，用户不只要结果，还要知道“为什么是这个结果”。因此系统必须展示 Agent Trace：调用了什么工具、用了什么参数、拿到了什么结果、最后如何形成结论。一个不能解释自己调用链的工业 Agent，很难获得调度员、工艺工程师和信息化部门的信任。三、技术选型：为什么选择 Hermes Agent + MCP本项目选择 NousResearch Hermes Agent 作为 Agent Runtime，并通过 MCP（Model Context Protocol）接入 MES 工具能力。3.1 Hermes Agent 的定位Hermes Agent 的核心定位不是传统意义上的应用框架，而更像一个可运行的 Agent 容器。它提供：Agent Runtime；OpenAI-compatible Gateway API；Skills 机制；MCP Client 能力；CLI 与服务化入口；流式输出与工具进度事件。和常见框架相比，它更强调“让 Agent 作为一个运行时系统被部署和集成”，而不是把智能体逻辑写死在一串 Python Chain 中。维度Hermes AgentLangChainAutoGen核心抽象Agent RuntimeChain / Workflow多智能体对话工具接入原生 MCPFunction Calling / Tool 封装Function Calling业务知识形态Markdown SkillsPython / Prompt / RunnablePython 代码企业集成Gateway API 友好通常需自建服务层通常需自建服务层适配角色企业工具集成、报告生成、运行时托管快速原型、RAG 编排多角色协作模拟对非开发人员友好度较高较低较低3.2 MCP 的价值：统一模型与外部系统的工具协议MCP 可以理解为 LLM 与外部工具之间的标准交互协议。Hermes 作为 MCP Client，通过 MCP Server 调用业务工具；MCP Server 内部再访问 MES API、设备服务、质量系统或数据仓库。这种模式的价值在于：跨语言：MCP Server 可以用 Python、Node.js、Go 等实现；跨系统：同一个 Agent 可以接入 MES、ERP、QMS、WMS、EAM；契约清晰：每个工具都有名称、参数、说明和返回结构；可替换：Mock MES 可以替换为真实 MES，而 Agent 层基本不变。3.3 Skills 的价值：把工业知识从代码里解放出来Hermes Skills 是 Markdown 文档，不是可执行代码。一个 Skill 可以描述：什么场景触发；应该调用哪个 MCP 工具；参数如何填写；工具返回字段如何解释；最终回答应遵循什么业务口径。这对工业项目很重要，因为很多业务规则掌握在工艺工程师、质量工程师、设备工程师手里，而不是软件开发者手里。把规则写成 Markdown，意味着业务人员可以参与 Agent 行为的治理与迭代。四、总体架构：四层解耦与认知-动作分离系统采用四层架构：用户交互层、Agent 运行时层、工具执行层、数据服务层。这套架构的关键是认知与动作分离。Hermes 负责理解用户问题、规划调用路径、综合工具结果、生成解释性回答；MCP Server 负责执行确定性业务工具；FastAPI / MES 负责提供数据事实；前端负责把对话结果和执行过程可视化。4.1 为什么前端直连 Hermes Gateway项目中选择 React 前端直接调用：POST http://localhost:8642/v1/chat/completions而不是走“前端 → FastAPI → Hermes”的代理模式。这是一项重要架构取舍。优点：减少一层中转，降低延迟；Hermes 原生处理会话、工具调用和 SSE 流；FastAPI 保持纯数据服务职责；每一层都可单独测试：先测 MES API，再测 MCP，再测 Hermes，最后测前端。代价：前端需要适配 Hermes 特有 SSE 事件；需要处理跨域、鉴权、API Key 暴露等生产问题；如果企业要求统一 API 网关，生产环境可能仍需增加 BFF 或 API Gateway。