专业级GPU显存稳定性检测：5分钟掌握memtest_vulkan硬件测试完整指南
2026/5/7 3:46:27
目录
- 为什么 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 Agent | LangChain | AutoGen |
|---|---|---|---|
| 核心抽象 | Agent Runtime | Chain / Workflow | 多智能体对话 |
| 工具接入 | 原生 MCP | Function Calling / Tool 封装 | Function Calling |
| 业务知识形态 | Markdown Skills | Python / Prompt / Runnable | Python 代码 |
| 企业集成 | 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。 <