IBM 发布工业 AI 智能体基准 AssetOpsBench

AssetOpsBench 是一个全面的基准测试和评估系统，包含六个定性评估维度，旨在弥合智能体 AI 在特定领域应用中的差距，首先聚焦于工业资产全生命周期管理。

引言：为何需要专门的工业基准？

现有的 AI 基准测试擅长处理编码或网页导航等孤立任务，但往往无法捕捉真实世界工业运营的复杂性。为了弥合这一差距，我们推出了 AssetOpsBench。这个框架专门设计用于在工业应用的六个关键维度上评估智能体性能。

与传统基准不同，AssetOpsBench 强调 多智能体 协调的必要性——超越“独狼”模型，转向能够处理复杂故障模式、整合多数据流并管理复杂工单的系统。通过关注这些高风险、多智能体的动态，该基准确保 AI 智能体能够根据其在真实工业环境中驾驭细微差别和安全关键需求的能力进行评估。

AssetOpsBench 专为冷水机组和空气处理单元等资产运维场景构建。它包含：

• 230 万 个传感器遥测点
• 140 多个 跨 4 个智能体的精选场景
• 4.2K 个用于多样化场景的工作单
• 53 种结构化故障模式

专家们帮助策划了 150 多个 场景。每个场景都包含元数据：任务类型、输出格式、类别和子智能体。设计的任务涵盖：

• 传感器流中的 异常检测
• 故障模式推理 与诊断
• KPI 预测 与分析
• 工单 总结与优先级排序

评估框架与整体反馈

AssetOpsBench 在六个定性维度上评估智能体系统，这些维度旨在反映工业资产管理中的真实操作约束。该基准不优化单一成功指标，而是强调决策轨迹质量、证据对齐、故障意识以及在数据不完整和嘈杂情况下的可操作性。

每个智能体运行都会在六个标准上打分：

1. 任务完成度
2. 检索准确性
3. 结果验证
4. 序列正确性
5. 清晰度与论证
6. 模型幻觉率

在早期评估中，我们观察到许多通用智能体在表面推理上表现良好，但在涉及工单、故障语义和时间依赖性的持续多步骤协调方面存在困难。那些明确建模操作上下文和不确定性的智能体，即使最终任务完成度是部分的，也倾向于产生更稳定和可解释的执行轨迹。

这种以反馈为导向的评估是刻意的：在工业环境中，理解智能体为何失败通常比一个二元成功信号更有价值。

工业智能体工作流中的故障模式

AssetOpsBench 的一个核心贡献是将 故障模式 作为智能体工业工作流中的一等评估信号进行明确处理。它不将故障视为二元结果，而是分析完整的多智能体执行轨迹，以识别在现实操作约束下，智能体行为在 何处、如何 以及 为何 崩溃。

AssetOpsBench 中的故障分析通过一个专用的轨迹级管道 TrajFM 实现，该管道结合了基于 LLM 的推理和统计聚类，从智能体执行轨迹中提取可解释的故障模式。该管道分三个阶段运行：(1) 使用 LLM 引导的诊断提示进行轨迹级故障提取，(2) 基于向量嵌入的聚类以分组重复出现的故障模式，(3) 分析和可视化以支持开发者反馈和迭代。

在工业场景中，反复出现的故障模式包括：

• 传感器遥测、警报和历史工单之间的错位
• 在证据缺失、延迟或不足的情况下得出过度自信的结论
• 跨智能体的异构数据模态聚合不一致
• 在没有充分验证步骤的情况下过早选择行动
• 多智能体协调崩溃，例如忽略输入或行动-推理不匹配

重要的是，AssetOpsBench 不仅仅依赖固定的、手工制作的故障分类法。虽然使用了一组结构化的预定义故障类别（例如，验证错误、步骤重复、角色违规）以确保一致性，但该系统明确设计用于 发现实践中出现的新故障模式。由 LLM 识别的额外故障模式会自动进行向量嵌入和聚类，允许分类法随着新智能体设计和行为的评估而演进。

为了保护工业机密性，原始执行轨迹从不暴露。相反，智能体会收到跨六个评估维度的聚合分数，以及解释智能体 为何 失败的聚类故障模式摘要，而不泄露敏感数据或中间推理步骤。这种以反馈驱动的设计使开发者能够诊断弱点、改进智能体工作流，并迭代地提交改进后的智能体。

这种故障感知评估反映了工业资产管理的现实，其中谨慎的、能感知性能退化的推理——以及识别不确定性、推迟行动或适当升级的能力——通常比激进但脆弱的自动化更可取。

提交智能体进行评估

AssetOpsBench-Live 被设计为一个开放的、竞赛就绪的基准，我们欢迎社区提交智能体实现。智能体在一个受控的、保护隐私的环境中接受评估，该环境反映了真实的工业资产管理约束。

要提交智能体，开发者首先使用提供的模拟环境在本地验证其实现，该环境包括代表性的传感器数据、工单、警报和故障模式目录。然后，智能体被容器化并提交，以便在隐藏的评估场景上进行远程执行。

提交的智能体使用一致、可复现的评估协议，在六个定性维度——任务完成度、准确性、结果验证、行动排序、清晰度和模型幻觉——上进行评估。执行轨迹不会暴露；相反，参与者会收到聚合分数和结构化的故障模式反馈，突出显示智能体推理或协调在何处以及为何崩溃。

这种以反馈驱动的评估循环支持迭代改进：开发者可以诊断故障模式，改进智能体设计或工作流结构，并提交更新的智能体以进行进一步评估。该框架支持以规划为中心和以执行为中心的智能体，允许研究人员和从业者在同一基准框架内探索多样化的智能体设计。

实验与观察

我们进行了一次社区评估，测试了两个赛道：

1. 以规划为导向 的多智能体编排
2. 以执行为导向 的动态多智能体工作流。

在 225 名用户和 300 多个智能体及领先的开源模型中，观察结果如下：

注意： 没有一个模型能够通过我们的评估标准基准并获得 85 分，这是部署就绪的阈值。

故障分布

在 881 个智能体执行轨迹中，故障分布如下：

• 无效的错误恢复： 31.2%
• 过度陈述完成度： 23.8%
• 格式问题： 21.4%
• 未处理的工具错误： 10.3%
• 忽略反馈： 8.0%
• 其他： 5.3%

除此之外，185 个轨迹有一种新的故障模式，164 个有多个新颖故障。

关键错误发现

1. “听起来对，实际错”： 智能体声称已完成任务（23.8%），即使在错误恢复失败后也输出成功（31.2%）。AssetOps 基准测试对于揭示这一点很重要，这样操作员就不会根据错误信息采取行动。
2. 工具调用： 这是高低性能智能体之间最大的区别因素，顶级智能体的工具调用准确率达到 94%，而低性能智能体为 61%。
3. 多智能体放大故障： 单智能体任务准确率（68%）与多智能体（47%）之间的对比显示了多智能体带来的复杂性，包括上下文丢失、异步问题和级联故障。
4. 领域知识： 能够访问故障模式数据库和维护手册的智能体表现更好。然而，RAG 知识并不总是被正确使用，这表明需要结构化推理。
5. 模糊性： 传感器缺失、日志冲突和模糊的操作员描述导致成功率下降 34%。智能体必须内置澄清策略。

如何开始？

• 阅读我们的技术报告 AssetOpsBench: Benchmarking AI Agents for Task Automation in Industrial Asset Operations and Maintenance
• 如何在本地运行 AssetOpsBench - 视频 AssetOpsBench Local Execution
• 在 HuggingFace Space Playground 中试用 AssetOpsBench
• 查找更多详情 AssetOpsBench GitHub，fork 仓库并开始使用。