摘要：IBM AssetOpsBench 将工业设备运维拆成 IoT、失效模式、时序模型、振动分析和工单等 MCP 服务，并通过场景、轨迹和离线评分检查智能体是否正确定位资产、调用工具、形成证据链并安全执行运维动作。
项目：IBM/AssetOpsBench
方向：工业设备运维智能体、MCP、时序模型、振动诊断、工单自动化
适合读者：工业互联网平台团队、设备运维部门、智能体研发团队、工业软件产品经理
摘要
工业运维智能体最容易做出令人印象深刻的演示，也最容易在进入现场后失去可信度。用户问一句“冷水机为什么报警”，模型可以快速生成一段故障分析；但工程团队需要确认的是：它是否读取了正确设备、正确测点和正确时间窗，是否区分了异常现象与失效模式，是否调用了合适的时序模型，是否在证据不足时停止推断，是否生成了可执行且经过审批的工单。
AssetOpsBench 的价值，正在于把这类问题从聊天效果转成可复现的任务、轨迹和评测。它以工业资产运维为场景，把 IoT 数据、失效模式、时序基础模型、振动分析和工单系统拆成多个领域服务，再通过 MCP 暴露给智能体。智能体需要在一条完整任务链中选择工具、读取数据、形成判断并留下操作轨迹，评测系统随后检查答案质量、调用顺序、数据准确性、幻觉情况、时延和成本。
对工业智能团队而言，这个项目更像一套“智能体中试环境”：它不能替代真实工厂的设备管理系统，却提供了一个较完整的参考框架，用来回答工业智能体能否测、如何测、测什么，以及如何把一次成功演示沉淀成长期可回归的能力基线。
一、工业运维智能体为什么需要专门的 Benchmark
通用大模型评测通常关注知识问答、代码、数学和通用工具调用。工业运维任务的困难来自另一套约束。
第一，数据具有明确的资产上下文。一个温度值脱离设备、测点、单位、采样频率和工况便没有稳定含义。同样是 85℃，对电机绕组、轴承外圈、润滑油或环境温度代表的风险完全不同。智能体首先要完成资产定位和语义对齐，然后才谈得上分析。
第二，诊断过程横跨多种数据形态。资产台账是结构化记录，传感器数据是时序信号，振动诊断需要频谱与包络谱，FMEA 或失效模式库带有知识图谱特征，维修工单还包含状态机、人员、成本和审批权限。单个检索增强问答模块很难覆盖这条链路。
第三，运维动作具有后果。查询历史曲线属于低风险读操作，创建、审批、指派、关闭工单则会改变业务状态。工业智能体的评测需要同时观察“答得对不对”和“做得对不对”，还要检查是否越权、是否跳过前置验证、是否在证据不足时直接写入系统。
第四，现场更关心稳定性。一次成功没有太大意义。模型升级、提示词调整、工具描述变化、数据库字段变更，都可能使原有流程退化。只有把任务输入、环境状态、期望结果和执行轨迹保存下来，团队才能持续做回归测试。
AssetOpsBench 因此采用场景化设计。一个场景不只是问题文本，还包括装载环境所需的清单、期望行为或标准答案，以及用于评测的标识。运行器按场景调用智能体，保存每一步轨迹，再由评测器离线评分。这一思路接近软件测试：工业任务被写成测试用例，模型与智能体框架成为被测对象。
二、六类 MCP 服务构成运维任务的工具底座
仓库当前公开的核心能力由五个领域 MCP 服务和一个公共工具服务组成。
1. IoT 服务：解决“设备和数据在哪里”
IoT 服务负责站点、资产、传感器和历史数据查询。典型工具包括列出站点与资产、查看设备详情、查找已安装或正在测量的传感器、读取最新值、获取历史序列和统计摘要。
这一层看似基础，却决定了后续诊断是否建立在正确对象上。可靠的智能体应先确认站点、资产 ID、测点名称和单位，再决定时间范围与分析方法。若用户只说“六号冷水机最近是不是不稳定”，系统需要把自然语言映射到具体资产和相关传感器，而不能直接凭经验生成故障原因。
2. FMSR 服务：把异常现象连接到失效模式
FMSR 服务提供失效模式查询、生成和写入能力。它承担的角色类似 FMEA 知识层：把泵、压缩机、冷水机等资产类别与可能的故障模式、症状、原因和检查项连接起来。
在工程上，失效模式库应当约束模型的候选空间。智能体可以先根据资产类别读取已知模式，再结合传感器证据排除或排序。这样形成的结论更容易追踪，也便于与企业已有的设备编码、故障代码和维修标准对齐。
3. TSFM 服务：把时序模型选择与运行变成可调用能力
TSFM 服务覆盖任务分析、序列画像、数据质量、模型目录、特征目录、训练或推理方案、运行记录和结果评估。它不仅提供“调用一个预测模型”的接口，还试图管理模型卡、特征卡、配方和实验账本。
这对工业现场很关键。时序模型不应由大模型随意挑选。预测、异常检测、分类和剩余寿命估计对应不同任务；不同采样频率、缺失比例、序列长度和季节性，也会影响模型可用性。智能体先做数据画像，再检索模型目录、检查加载条件、生成运行配方，最后读取结果，整个过程可以留下可审计记录。
4. Vibration 服务：把专业信号分析从语言模型中剥离
振动服务提供振动数据读取、FFT 频谱、包络谱、严重度评估、轴承特征频率计算和诊断。这里体现出工业智能体架构的一条重要原则：数值计算由确定性工具完成，语言模型负责规划、解释和组合证据。
轴承故障、齿轮啮合异常、松动和不对中通常需要观察频域结构。让大模型直接“看一串时域数字”并得出诊断并不可靠。把 FFT、包络解调和特征频率计算封装成工具，模型得到的是有明确物理意义的结果，工程师也能复核计算过程。
5. Work Order 服务：覆盖工单全生命周期
工单服务既有查询能力，也有创建、更新、审批、指派、关闭和取消等写操作，并沿用 Maximo 风格的字段语义。仓库还提供只读开关，可以只暴露查询工具。
工业智能体最终要进入维护流程，分析文字只是中间产物。一个完整任务可能包含：确认异常、查询已有工单、检查人员排班、生成任务与物料建议、提交审批、指派技术人员、记录实际工时与费用，最终关闭工单。写操作越接近生产系统，权限控制、人工确认和幂等性越重要。
6. Utilities 服务：统一时间、目录和 JSON 读取
公共工具负责时间、资产目录、传感器目录和 JSON 等辅助能力。它们避免每个领域服务重复实现相同功能，也能减少模型对隐含上下文的猜测。
三、一个完整场景如何运行
可以设想一个冷水机轴承异常任务：
- 用户提出：“检查 MAIN 站点六号冷水机的振动异常，并给出维护建议。”
- 智能体通过 IoT 服务定位站点和资产，列出振动传感器，确认单位和采样时间。
- 它读取一段历史数据，检查缺失值、采样间隔和序列长度。
- 调用振动服务计算 FFT 与包络谱，并根据转速、轴承参数计算理论故障频率。
- 查询 FMSR 服务，获取冷水机或相关旋转设备的失效模式。
- 将频谱峰值、趋势变化、严重度和失效模式进行对照，形成证据链。
- 查询现有工单，避免重复创建；必要时生成新工单草稿。
- 在涉及审批、指派或关闭时请求人工确认。
- 返回结论、证据、置信度、未确认事项和工单编号。
这条流程的价值在于每一步都能被记录。评测时可以检查智能体是否先定位资产再读取数据，是否调用了正确工具，是否在数据质量不足时仍给出确定性诊断，是否凭空捏造传感器或工单字段。
AssetOpsBench 的场景运行器把问题、环境清单和标准答案组织在固定目录中。运行器支持按类别选择轻量集或全量集，也支持多种 Agent 入口。每次运行保存独立 trajectory，按智能体、模型和场景组织，便于同一场景比较不同模型，也便于同一模型比较不同编排策略。
四、评测不只看最终答案
AssetOpsBench 的评测链条可以概括为：
1 | 场景 → 智能体运行 → 轨迹文件 → 离线评分 → 单场景报告与聚合报告 |
场景包含问题、类别、期望行为、预期答案和评分方式；轨迹包含模型、运行器、最终回答、逐步调用、Token、时长和工具信息；评分器可以在不重新运行智能体的情况下反复执行。
当前实现中，主要有两类可用评分方式。
1. LLM-as-Judge：检查六项行为标准
六项标准包括任务完成度、数据检索准确性、结果验证、工具或 Agent 顺序、解释清晰度以及幻觉。前五项均通过且没有幻觉，整体才算通过。评测还禁止默认的“自我评分”：当被测模型与裁判模型相同，系统会终止该行评测，降低自我偏好带来的失真。
LLM 裁判适合检查开放式过程，但不应成为唯一评分来源。裁判模型也会波动，因此需要固定版本、固定提示词、抽样复核，并与确定性指标结合。
2. Static JSON：对结构化输出进行确定性比较
对于资产清单、传感器列表、失效模式集合、计数结果等结构化任务，系统提供静态 JSON 评分。它可以解析 JSON、Python 风格字典、嵌套结构、Markdown 代码块和带前缀的回答，并计算精确匹配、部分匹配、精确率、召回率、F1、缺失键和多余键。
这类评分更适合工业数据查询。答案中多一个不存在的设备或少一个关键测点，都能被明确记录，不必依赖裁判模型的主观判断。
3. 运行成本也进入报告
聚合报告记录输入输出 Token、工具调用总数、P50/P95 时延和估算成本。工业智能体的优劣不能只看成功率。两个方案都能完成任务时，调用 6 次工具和调用 30 次工具的稳定性、时延和成本差异很大。将这些指标纳入回归体系，有助于发现模型升级后“答案没变，但流程越来越重”的隐性退化。
五、对工业智能体平台建设的启示
AssetOpsBench 的核心参考价值在于它对工业智能体工程边界的划分。
其一，领域能力应以可测试工具呈现。传感器查询、频谱分析、模型检索、工单写入分别有清晰接口、参数和返回值。知识被放进服务、目录和规则中，语言模型只负责在约束范围内组合。
其二，读操作与写操作需要分级。查询资产和计算频谱可以自动执行，创建工单可以先生成草稿，审批、指派和关闭应进入人工确认或策略引擎。生产环境还需要角色权限、双人复核、操作幂等键和回滚机制。
其三，场景集应来自真实业务流程。企业可以从高频工单、重大故障复盘、设备点检标准和专家问答中提炼场景。每个场景至少要保存初始数据、目标结果、允许工具、禁止动作、验收规则和风险等级。
其四，评测需要分层。数据查询用确定性比较，数值计算用容差与物理守恒检查，诊断解释用专家规则或裁判模型，业务动作检查状态机和权限。把所有任务交给一个大模型裁判，会掩盖许多工程错误。
六、如何将它改造成面向国内制造业的中试环境
一个可行的落地路线可以分为四步。
第一步，先做只读运维助手。接入设备台账、测点目录、报警和历史工单，限制在查询、摘要和证据整理，不允许写回。重点验证资产映射、单位、时间窗和权限隔离。
第二步，引入确定性分析工具。把振动、趋势、异常检测、能效计算和规则诊断封装为服务，要求智能体必须引用工具输出。建立 50—100 个高质量回归场景，覆盖正常、异常、缺失数据和冲突证据。
第三步，开放工单草稿与人工审批。智能体可以生成工单标题、故障描述、建议任务、备件和安全注意事项，但写入前由工程师确认。系统记录每次修改，比较模型建议与最终工单的差异。
第四步，形成多模型、多编排框架的持续评测。每次更换模型、提示词、知识库或工具版本都运行场景集，观察通过率、误动作率、工具调用数、时延和成本。高风险场景单独设置红线，任何越权写入、虚构测点或跳过确认都判为失败。
七、边界与局限
AssetOpsBench 仍然是一套快速演进的研究和工程框架。仓库描述与 README 中的场景数量存在迭代不同步，说明数据集和文档仍在扩展；部分评分器仍是骨架；模拟环境无法覆盖真实现场的通信中断、传感器漂移、编码混乱和组织流程。
它采用 Maximo 风格工单语义，对其他 EAM、MES 或企业自研系统仍需要适配。更重要的是，Benchmark 通过不能直接等同于生产可用。现场部署还要完成网络安全、身份鉴权、数据分级、模型版本管理、工具白名单、审计留痕、人工接管和事故责任界定。
即便如此，AssetOpsBench 已经把工业智能体从“会回答设备问题”推进到了“能在受控环境中完成、记录和评测运维任务”。对正在建设工业智能体、数字工匠或设备管理 Agent 的团队来说，它是一份很有参考价值的测试架构样本。