AI Agent 在工业场景的落地面临一个数据侧的根本障碍：工业数据散落在 PLC、DCS、MES、SCADA、工业网关等十几个系统中，格式各异、权限分散。工业互联网的建设初衷之一就是要解决这些数据孤岛问题，但当前仍有大量企业只完成了数据采集而未打通消费链路。Agent 消费工业数据的传统路径是让工程师先将数据整理成统一的数据库模型，Agent 再通过 SQL 或 API 查询，这个过程本质上还是以人为中介而非机器直连。
MCP（Model Context Protocol）为这个问题提供了一条新路径：让 Agent 直接面向设备层和控制系统暴露能力，跳过人工整理的中间层。
MCP 架构在工业场景的适配
MCP 的标准架构是 Client-Server 模型：AI Agent 作为 MCP Client，通过 MCP Server 访问外部能力。Server 暴露三类资源——Tools（可执行的操作）、Resources（可读取的数据源）、Prompts（预设的提示模板）。
映射到工业场景，MCP Server 的角色由工业网关或数据接入层承担。一个典型的工业 MCP Server 可以暴露如下 Tools 和 Resources：
类型 | 示例 | 说明 |
Tools |
| 读取 PLC 实时标签值 |
Tools |
| 查询设备历史时序数据 |
Tools |
| 按条件查询告警列表 |
Tools |
| 执行预设的设备宏指令 |
Resources |
| 电机对象的完整数据视图 |
Resources |
| 活跃告警的实时流 |
Prompts |
| 根因分析的标准提示模板 |
Agent 收到用户指令（"帮我查一下 3 号线 2 号电机最近半小时的振动数据"）后，通过 MCP 协议调用对应的 Tools。调用过程中 MCP Server 负责处理 OPC UA、Modbus、S7 等底层协议转换，Agent 完全不感知设备侧的通信细节。
标准 MCP 协议基于 JSON-RPC over SSE（Server-Sent Events）传输。在工业场景，SSE 的 TCP 长连接机制天然适合实时数据推送，但连接稳定性和带宽效率需要专门优化——工厂车间的 Wi-Fi 信号可能不稳定，断线重连时需要支持断点续传，避免重复拉取大量历史数据。部分实现开始支持 MCP over gRPC，利用 gRPC 的双向流特性同时处理请求-响应和订阅-推送两种模式。
Agent 能力边界
MCP 协议解决了"如何拿到数据"的问题，但 Agent 在拿到数据后能做什么、不能做什么，需要一个清晰的能力边界定义。工业场景对 Agent 行为的容错空间远小于互联网——一条错误的指令可能导致生产线停机甚至安全事故。
Agent 能力分为三级：只读、分析、执行。只读能力包括查询实时数据、拉取历史趋势、获取告警信息，风险最低，是所有 Agent 的基础能力。分析能力包括模式识别（"这条振动曲线是否符合轴承早期故障特征"）、异常检测（"当前温度是否偏离正常基线"）、根因推断（"3 号线停机是否由 2 号电机过载触发"），需要模型具备对应的工业知识。执行能力是风险最高的一级——调整 PLC 参数、执行设备宏指令、触发工单创建。
执行能力必须引入人工确认机制。Agent 发出的执行型 Tool 调用，在到达 MCP Server 之前需要经过两道关卡：第一道是策略引擎检查调用是否在预定义的安全范围内（例如允许 Agent 在 ±5% 范围内调整 PID 参数，超出范围则直接拒绝）；第二道是人工审批——关键指令推送到现场工程师的移动端，工程师确认后才真正下发到设备侧。
Agent 的权限模型比人类用户更细粒度。人类工程师的权限通常按系统角色划分（"操作员"、"工程师"、"管理员"），Agent 的权限需要精确到 Tool 参数级别。一个负责质量检测的 Agent 只能调用 read_plc_tags 且只能访问质量相关的测点（如表面粗糙度、尺寸偏差），不能读取产量数据，更不能触发执行类 Tool。权限配置用声明式语言描述，MCP Server 在处理每个请求前先做权限校验。
典型场景：AI 工程师助手
AI 工程师助手是当前最成熟的工业 AI Agent 应用形态。传统工程师在处理一个现场技术问题时，需要手动查看 PLC 标签历史曲线、翻阅设备手册、对照标准作业指导书，整个过程耗时 30-60 分钟。AI 助手将这个流程缩短到数分钟。
一个典型的根因排查场景：工程师说"2 号线的电机温度过高了"，Agent 的处理链路是：
- 解析意图，提取关键实体——"2 号线"、"电机"、"温度过高"
- 调用
get_historical_data拉取过去 2 小时内该电机的温度、电流、振动三个维度的时序数据 - 并行调用
read_plc_tags获取该电机当前实时值，确认是否仍在异常状态 - 调用
list_alerts查询同一时间段该电机关联的告警事件 - 调用
execute_macro中的一个只读宏，获取电机轴承温度的横向对比数据——正常运行的同型号电机平均温度是多少 - 将以上多路数据聚合成一个结构化 JSON，喂入根因分析 Prompt 模板
- 根据模型输出生成诊断报告："轴承温度 68°C，超过基线均值 45°C 约 51%；振动 RMS 略高；告警日志显示 20 分钟前电流有 2 秒尖峰；综合判断轴承润滑不良概率 72%"
整个过程中，Agent 没有直接连接任何底层设备——所有数据都是通过 MCP Server 的 Tools 和 Resources 获取的。MCP Server 在每次调用时记录审计日志，包括调用时间、参数、返回结果、调用方 Agent 标识。工程师可以事后回溯 Agent 的每一步推理链条。
挑战与解决方案
MCP 在工业场景的落地有三个具体的技术挑战。
第一个是 MCP Server 的高可用。如果 Agent 依赖的 MCP Server 挂了，所有 Agent 的数据消费能力归零。解决方案是边缘部署——每个车间或区域部署一个本地 MCP Server 实例，就近接入本区域的工业设备，同时与中心 MCP Server 保持同步。中心 Server 维护跨区域的聚合视图，本地 Server 负责本区域的低延迟数据服务。
第二个是 Tool 和 Resource 的注册与发现机制。一个大型工厂可能有数十台 MCP Server，Agent 如何知道哪个 Server 暴露了哪些能力？当前 MCP 规范没有内置服务发现，需要额外的注册中心。注册中心维护一张 MCP Server 的能力清单——每个 Server 声明自己能处理哪些设备类型、哪些通信协议、哪些数据标签。Agent 首次启动时向注册中心查询，根据自己的任务需求选择合适的 Server 组合。
第三个是实时数据的处理效率。工业现场的高频数据（振动采样 10kHz 级别）如果全部通过 MCP 通道推送给 Agent，带宽和内存开销都不可接受。MCP Server 内部需要做自适应降采样——Agent 只拿到分析所需粒度的数据，原始高频数据留在工业数据平台本地存储。AI 原生工业数据平台可以内置 MCP Server 组件，让高频振动数据直接在平台侧完成降采样和特征提取后再推送给 Agent。
结语
MCP 协议为工业 AI Agent 提供了一套标准化的数据消费接口，让 Agent 不再依赖人工整理的中间数据库。但协议只是基础设施层，真正的落地难点在于 Agent 的工业知识建模、细粒度权限控制和边缘侧的高可用架构。当前 MCP 生态在快速迭代——工业领域的 MCP Server 实现正在从 POC 走向生产级，IEC 62443 也在补充 Agent 安全相关的控制目标。对于正在规划 AI 工程师助手的团队，建议先从只读分析型 Agent 入手，积累数据访问模式后再逐步放开执行能力。
