mes-line 不该是 Agent，而是 Agent 的手——一次产品定位反省，顺便科普 5 个 AI 概念

先坦白：我们犯了一个方向性错误

我们曾经把 mes-line 包装成一个叫「mes-line 智能体」的东西，给它套了一层 LLM 对话壳。现在回头看，这是一次漂亮的方向性错误——用 12 个开发人天、大约 5% 的工时，给自己的核心产品贴了一张“会聊天”的脸。技术投入不大，但叙事的副作用不小。

这篇博客，既是给 mes-line 正名，也想借这次踩坑，把我们在过程中现学现卖的 5 个 AI 概念——Ontology、向量知识库、Skills、MCP、Agent——讲清楚。

mes-line 到底是什么

要谈它不该是什么，得先说清它是什么。mes-line 是青璃的产线中控 MES，落在云网边端架构的「边缘」层：每条产线部署一套，断网也能独立运行；以配方中枢串起数据采集、工单调度、OEE 看板、CPK 质量分析；配青璃 DAQ 解决“协议地狱”（三菱、西门子、Modbus 各说各话）；向上通过 Online 平台汇聚到工厂管理层。

它的核心价值只有一个词：确定性。工业现场不需要一个“会思考”的系统——需要的是指令准确、结果可审计、毫秒级响应、断电断网也不崩。客户可以不用我们的上层 MES，但设备接入和产线节拍这一环，是刚需。

mes-line 的正确位置：做那只“手”——通过 MCP 把 DAQ 采集、工单下发、OEE 查询、质量追溯暴露为标准工具，让外部 AI Agent 来调用。

为什么“套壳 Agent”是个坑

把 mes-line 包装成“智能体”，听起来很 AI、很性感，落地后三个实打实的问题：

• 性能倒退：每次下发工单、读设备状态都是毫秒级确定性指令。套壳后操作要先绕一圈 LLM 推理——把确定性的事用不确定的方式重做一遍。
• 体验倒退：自然语言是模糊的，工业生产要的是精确的、可复核的。让用户用“帮我看看那条线怎么样”替代一个明确的 OEE 看板，是把已经解决好的 UX 问题重新制造出来。
• 定位模糊：mes-line 最该被记住的一句话是「可以不用我们的 MES，但 mes-line 是刚需」。把它包装成“会聊天的智能体”，等于用一层炫技的壳盖住了真正能卖钱的内核。

正确的路：不做 Agent，做 MCP

反省之后的思路其实很干净——让 mes-line 支持 Agent，而不是成为 Agent。

怎么做？给 mes-line 做一个 MCP（Model Context Protocol）出口：把核心能力封装成一组标准工具暴露出去——get_device_status 读设备状态、dispatch_work_order 下发工单、query_quality_trace 拉质量追溯、pull_oee_dashboard 取 OEE 看板。

用户的任意 AI 助手（Cursor、Claude Desktop、企业内部 Agent）都能通过 MCP 直接调用 mes-line 去干活。用户说“把 3 号线夜班工单按优先级重排”，Agent 经 MCP 驱动 mes-line 执行——入口是自然的，落地是确定的，性能与可靠性一点没丢。

Agent 是大脑，mes-line 是手。我们该把手打磨好，去接各种大脑，而不是自己假装长出一个大脑。

5 个 AI 概念，一条主线串起来

这次弯路逼我们把 AI 工程化的全景补了一遍。用一条主线串：ontology 定义世界 → 向量知识库存知识 → skills 封装流程 → MCP 接工具 → agent 编排执行。

五层栈：Ontology 是骨架（定义领域概念和关系），向量知识库是记忆（治幻觉），Skills 是电器（封装可复用流程），MCP 是插座（标准接口），Agent 是大脑（编排执行）。

Ontology：让 AI 真正“懂工业”的骨架

Ontology 回答的是：“这个领域里有哪些概念，它们之间什么关系。” 青璃自研的三环联动控制模型——设备环（PHM）↔ 效率环（OEE）↔ 工单环（W），三角形耦合、跨环直通——本质上就是一套工业现场的 ontology。当你把这层关系建模清楚，Agent 才知道“重排工单”之前得先看效率环 OEE，再看设备环健康度 A[H(t)]。没有 ontology，Agent 再聪明也只是个外行。

向量知识库 / RAG：治“一本正经胡说”的偏方

把文档切段、转成向量存起来，用户提问时按语义检索出“对的资料”，再让 LLM 基于这些资料回答。我们那个 mes-line 智能体，底层确实用到了 KB RAG 来辅助生成 HMI 页面——这部分是真有价值的，只是被埋在了“智能体”的叙事里，没被单独讲清楚。

Skills：插在 MCP 插座上的“电器”

如果 MCP 是插座，Skills 就是插上去就能干活的电器：把一类任务（比如“生成一张 HMI 面板”）的流程、提示词、工具依赖打包成模块，Agent 拿来就能用。未来 mes-line 的实施，完全可以写成一组 Skills，交给客户自己的 Agent 去调用。

MCP：AI 世界的“USB-C”

MCP 是 Anthropic 提出的开放协议，解决一个很朴素的问题：模型怎么标准地连上外部工具和数据。一次定义，任何支持 MCP 的客户端即插即用。这正是 mes-line 应该选的位置——做那个“被插”的标准端点，而不是自己再造一个大脑。

Agent：能调用工具，不等于能聊天

Agent 的本质是“感知—决策—执行”的闭环，而它的分水岭是能调用外部工具。我们当初把“能聊天的壳”当成 Agent，是偷换了概念——那只是个对话框，不是智能体。真正的 Agent 应该站在 mes-line 外面，通过 MCP 来指挥它。

不变的价值，新增的能力

反省完，mes-line 该守的和该加的，都更清楚了：

• 确定性执行层：三环联动控制、A[H(t)] 可用产能控制信号、确定性网络传输、断网独立运行——这些不变。
• MCP 出口：把 mes-line 的能力变成标准工具，让任何 AI 助手都能来“操盘”。
• 可复用 Skills：把实施经验沉淀为可配置的模块，降低交付门槛。

给客户的一句话也更诚实了：你要的是确定性，不是表演。

感谢这次“错误”

它让我们用最小的代价，把 AI 工程化的全景——从 ontology 到 agent——从头到尾学了一遍。现在的 mes-line，不再假装是智能体；它安心做好那只“手”，等各种各样的大脑来握住它。如果你也在做工业软件 + AI 的尝试，欢迎来聊聊：你是怎么处理“该不该让产品自己变成 Agent”这个问题的？