企业 IT 运维里AI Agent 到底行不行 Artificial Analysis 和 IBM 联手推出的 ITBench-AA 基准把前沿大模型被拉进考场最高分不到50%。一众顶级模型在真实的企业 IT 故障排查场景仍然不够用。当最强AI遇上企业运维AI Agent 的能力评测这几年出了不少。写代码、做数学、答常识题基准测试一个接一个。模型分数刷刷往上涨排行榜上你追我赶热闹得很。可企业真正关心的场景比如线上服务挂了几十个微服务互相依赖日志像瀑布一样刷怎么快速定位根因这类任务一直缺一个靠谱的评测标准。现有的大多数 Agent 基准测的是通用能力。模型会不会用搜索引擎能不能操作浏览器代码写得对不对。这些确实重要但企业 IT 运维是一个高度专业的领域需要模型理解 Kubernetes 的资源模型读懂 Prometheus 的告警规则从分布式链路追踪里找到异常的调用链还要在错综复杂的微服务拓扑中锁定故障源头。通用基准很难触及这些痛点。Artificial Analysis 和 IBM Software Innovation Lab 联手填补了这个空白。他们推出的 ITBench-AA是目前首个专门针对企业级 IT 任务的 Agent 基准测试。这个名字里ITBench 来自 IBM 开发的 IT 运维基准数据集AA 是 Artificial Analysis 的缩写。两家团队花了6个月时间把 IBM 积累多年的 ITBench 数据集改造成面向前沿 AI 模型的评测工具。ITBench 背后是 IBM 在企业 IT 运维领域深耕多年的专业积累数据集本身就有着扎实的行业基础。ITBench-AA 先从 SRE站点可靠性工程师任务切入后续还会扩展到 FinOps财务运营和 CISO首席信息安全官方向。为什么从 SRE 开始因为 SRE 是企业运维中最核心也最紧迫的环节线上故障排查直接关系到业务可用性和用户体验也是 Agent 最有可能产生实际价值的场景之一。59道 SRE 题目3次重复测试所有前沿模型的得分全部低于50%。Claude Opus 4.7自适应推理最大努力以47%领跑GPT-5.5超高推理46%紧随其后Qwen3.7 Max 拿到42%。开源模型方面GLM-5.1推理40%领跑和 Gemini 3.5 Flash高推理并列DeepSeek V4 Pro推理最大努力38%居中Gemma 4 31B推理37%紧追。Gemini 3.1 Pro Preview 只有30%。对比其他 Agent 基准前沿模型在 Terminal-Bench 上的表现要好得多。ITBench-AA SRE 算得上当前最不饱和的 Agent 基准之一模型离天花板还远得很。企业级 IT 运维任务对 AI Agent 的要求远比通用编程或问答任务严苛。低饱和度恰恰是 ITBench-AA 的价值所在它给模型的进步留出了足够大的空间不会出现刷几个月就全员满分的尴尬局面。一场真实的K8s排障考试ITBench-AA SRE 包含59道题其中40道公开19道全新保留题。保留题不对外公开防止模型靠刷题拿高分。每道题给模型提供一个 Kubernetes容器编排平台故障快照包含告警、事件、链路追踪、指标、日志和应用拓扑。模型要做的就是从中找到导致故障的最小独立根因实体集合。故障类型覆盖了 SRE 日常面对的典型场景基础设施故障、服务故障、应用故障还有混沌工程注入的故障。具体来说资源配额耗尽、滚动发布失败、连接池耗尽、网络分区这些运维人再熟悉不过的痛全都成了考题。故障场景的设计贴近真实IBM 在企业 IT 运维方面的经验保证了题目的专业度和代表性。举一个公开题目的例子。Agent 看到前端链路出现用户侧故障它用 Shell 命令检查离线快照先看告警确定故障时间窗口再通过链路追踪和日志把故障缩小到前端流量拓扑定位受影响的服务Kubernetes 配置文件揭示了一个阻止前端流量的网络策略。最终诊断出的根因实体是 otel-demo/NetworkPolicy/frontend-block-all-ports。这个过程很接近真实 SRE 工程师的排查思路。先从告警入手缩小范围再用链路追踪和日志层层剥茧最后在配置层面找到根因。区别在于人类工程师会凭经验快速跳过无关信息而 Agent 需要一步步执行 Shell 命令每一步都可能走弯路。真实环境中的 SRE 还面临时间压力几分钟的延误可能导致业务损失扩大Agent 的排查效率直接决定了它的实用价值。这套考试的评分规则很严格用的是全召回条件下的平均精度。模型提交一组根因实体比如 Kubernetes 的 Deployment、Service、Pod、NetworkPolicy 等和 IBM 提供的标准答案做比对。只要漏掉任何一个真实根因该次得分直接归零。全部找对了得分等于精确率即正确识别的实体数除以提交的总实体数。多报乱报也要扣分少报漏报更是直接判零。最终成绩是59道题乘以3次重复的平均值。考试环境用的是 Stirrup一个开源的参考 Harness。每个任务上限100轮对话每个任务跑3次取平均消除随机性带来的波动。所有模型都用同一个 Stirrup 框架确保了公平对比。模型通过 Shell 命令访问沙箱文件系统里面存着相关的日志和快照数据完成任务后提交一份结构化的 JSON 诊断报告。Stirrup 框架开源任何人都可以复现测试结果也可以用自己的模型跑一遍看看成绩。多干不如干对一个有意思的发现轮次多的模型成绩不一定好。GPT-5.5 平均31轮对话拿到46%Gemini 3.1 Pro Preview 平均83轮却只有30%。轮次差距接近3倍分数反而低了16个百分点。这跟很多人的直觉相悖毕竟多查几轮似乎应该更有机会找到正确答案。为什么因为这套评分机制下多报根因实体是要受惩罚的。有的模型翻来覆去查把上游的故障注入机制或者并发的症状也当成根因提交上去结果被判定为误报精确率下降。全召回条件下的平均精度天然鼓励模型只提交自己确信的根因把疑似但不确定的对象排除在外。Gemma 4 31B推理平均58轮拿到37%Gemini 3.1 Pro Preview 平均83轮却只有30%。过度调查的模型容易把混沌注入的控制器或者同时出现的症状当作根因上报在全召回精确率的评分规则下这些多出来的实体全是误报。这个发现对 Agent 的设计思路有直接启发。很多 Agent 框架追求更多工具调用、更长推理链、更细致的排查流程仿佛多查一轮就多一点把握。在 ITBench-AA 的 SRE 场景里这个思路行不通。精准定位根因干净利落提交答案比翻箱倒柜地把所有可疑对象都报上去要聪明得多。运维排障也遵循同样的规律。企业里排查故障最怕的就是找到一堆疑似问题却分不清主次。误报根因的代价同样高昂运维团队按照错误方向去排查浪费的时间和人力都是实打实的损失。一个能精准定位根因的 Agent远比一个什么都要报一通的 Agent 有价值。ITBench-AA 的评分机制巧妙地把这种现实约束转化为了评测规则逼迫模型在准确和全面之间做出取舍。开源模型的性价比战场闭源模型拿走了前几名开源模型却在性价比上打了一场漂亮的翻身仗。Gemma 4 31B推理每道题只花0.14美元得分37%在分数上超过了每道题花2.23美元、得分30%的 Gemini 3.1 Pro Preview。花的钱不到对方的1/15分数还高出7个百分点。GLM-5.1推理每道题1.23美元拿到40%和 Gemini 3.5 Flash高推理的1.70美元、40%持平但成本更低。Claude Opus 4.7自适应推理最大努力以47%占据榜首但每道题5.38美元是最贵的选手。对企业来说7分的性能提升值不值得付出近4倍的价格是个需要认真权衡的问题。尤其是在大规模部署 Agent 的场景里一天跑上千次故障排查任务5.38美元和1.23美元的差距调用的成本差距会迅速放大。从 ITBench-AA 的数据看开源模型已经站在了性价比的前沿线上。ITBench-AA 目前只发布了 SRE 部分后续 FinOps 和 CISO 任务会陆续上线。FinOps 关注云资源成本优化CISO 聚焦安全合规三个方向加起来基本覆盖了企业 IT 管理的核心版图。随着更多领域的企业 IT 任务加入评测模型在不同专业场景下的表现差异也会更加清晰。一个模型在 SRE 上表现好在 FinOps 上未必同样出色这种跨场景的差异化评测对企业的选型决策很有参考价值。企业级 IT 运维场景Agent 还有很长的路要走。参考资料https://arxiv.org/abs/2502.05352https://github.com/itbench-hub/ITBenchhttps://artificialanalysis.ai/evaluations/itbench-aahttps://huggingface.co/datasets/ArtificialAnalysis/ITBench-AA
首个企业IT运维Agent基准，Claude拿第一也才47%
发布时间：2026/6/8 15:48:12
企业 IT 运维里AI Agent 到底行不行 Artificial Analysis 和 IBM 联手推出的 ITBench-AA 基准把前沿大模型被拉进考场最高分不到50%。一众顶级模型在真实的企业 IT 故障排查场景仍然不够用。当最强AI遇上企业运维AI Agent 的能力评测这几年出了不少。写代码、做数学、答常识题基准测试一个接一个。模型分数刷刷往上涨排行榜上你追我赶热闹得很。可企业真正关心的场景比如线上服务挂了几十个微服务互相依赖日志像瀑布一样刷怎么快速定位根因这类任务一直缺一个靠谱的评测标准。现有的大多数 Agent 基准测的是通用能力。模型会不会用搜索引擎能不能操作浏览器代码写得对不对。这些确实重要但企业 IT 运维是一个高度专业的领域需要模型理解 Kubernetes 的资源模型读懂 Prometheus 的告警规则从分布式链路追踪里找到异常的调用链还要在错综复杂的微服务拓扑中锁定故障源头。通用基准很难触及这些痛点。Artificial Analysis 和 IBM Software Innovation Lab 联手填补了这个空白。他们推出的 ITBench-AA是目前首个专门针对企业级 IT 任务的 Agent 基准测试。这个名字里ITBench 来自 IBM 开发的 IT 运维基准数据集AA 是 Artificial Analysis 的缩写。两家团队花了6个月时间把 IBM 积累多年的 ITBench 数据集改造成面向前沿 AI 模型的评测工具。ITBench 背后是 IBM 在企业 IT 运维领域深耕多年的专业积累数据集本身就有着扎实的行业基础。ITBench-AA 先从 SRE站点可靠性工程师任务切入后续还会扩展到 FinOps财务运营和 CISO首席信息安全官方向。为什么从 SRE 开始因为 SRE 是企业运维中最核心也最紧迫的环节线上故障排查直接关系到业务可用性和用户体验也是 Agent 最有可能产生实际价值的场景之一。59道 SRE 题目3次重复测试所有前沿模型的得分全部低于50%。Claude Opus 4.7自适应推理最大努力以47%领跑GPT-5.5超高推理46%紧随其后Qwen3.7 Max 拿到42%。开源模型方面GLM-5.1推理40%领跑和 Gemini 3.5 Flash高推理并列DeepSeek V4 Pro推理最大努力38%居中Gemma 4 31B推理37%紧追。Gemini 3.1 Pro Preview 只有30%。对比其他 Agent 基准前沿模型在 Terminal-Bench 上的表现要好得多。ITBench-AA SRE 算得上当前最不饱和的 Agent 基准之一模型离天花板还远得很。企业级 IT 运维任务对 AI Agent 的要求远比通用编程或问答任务严苛。低饱和度恰恰是 ITBench-AA 的价值所在它给模型的进步留出了足够大的空间不会出现刷几个月就全员满分的尴尬局面。一场真实的K8s排障考试ITBench-AA SRE 包含59道题其中40道公开19道全新保留题。保留题不对外公开防止模型靠刷题拿高分。每道题给模型提供一个 Kubernetes容器编排平台故障快照包含告警、事件、链路追踪、指标、日志和应用拓扑。模型要做的就是从中找到导致故障的最小独立根因实体集合。故障类型覆盖了 SRE 日常面对的典型场景基础设施故障、服务故障、应用故障还有混沌工程注入的故障。具体来说资源配额耗尽、滚动发布失败、连接池耗尽、网络分区这些运维人再熟悉不过的痛全都成了考题。故障场景的设计贴近真实IBM 在企业 IT 运维方面的经验保证了题目的专业度和代表性。举一个公开题目的例子。Agent 看到前端链路出现用户侧故障它用 Shell 命令检查离线快照先看告警确定故障时间窗口再通过链路追踪和日志把故障缩小到前端流量拓扑定位受影响的服务Kubernetes 配置文件揭示了一个阻止前端流量的网络策略。最终诊断出的根因实体是 otel-demo/NetworkPolicy/frontend-block-all-ports。这个过程很接近真实 SRE 工程师的排查思路。先从告警入手缩小范围再用链路追踪和日志层层剥茧最后在配置层面找到根因。区别在于人类工程师会凭经验快速跳过无关信息而 Agent 需要一步步执行 Shell 命令每一步都可能走弯路。真实环境中的 SRE 还面临时间压力几分钟的延误可能导致业务损失扩大Agent 的排查效率直接决定了它的实用价值。这套考试的评分规则很严格用的是全召回条件下的平均精度。模型提交一组根因实体比如 Kubernetes 的 Deployment、Service、Pod、NetworkPolicy 等和 IBM 提供的标准答案做比对。只要漏掉任何一个真实根因该次得分直接归零。全部找对了得分等于精确率即正确识别的实体数除以提交的总实体数。多报乱报也要扣分少报漏报更是直接判零。最终成绩是59道题乘以3次重复的平均值。考试环境用的是 Stirrup一个开源的参考 Harness。每个任务上限100轮对话每个任务跑3次取平均消除随机性带来的波动。所有模型都用同一个 Stirrup 框架确保了公平对比。模型通过 Shell 命令访问沙箱文件系统里面存着相关的日志和快照数据完成任务后提交一份结构化的 JSON 诊断报告。Stirrup 框架开源任何人都可以复现测试结果也可以用自己的模型跑一遍看看成绩。多干不如干对一个有意思的发现轮次多的模型成绩不一定好。GPT-5.5 平均31轮对话拿到46%Gemini 3.1 Pro Preview 平均83轮却只有30%。轮次差距接近3倍分数反而低了16个百分点。这跟很多人的直觉相悖毕竟多查几轮似乎应该更有机会找到正确答案。为什么因为这套评分机制下多报根因实体是要受惩罚的。有的模型翻来覆去查把上游的故障注入机制或者并发的症状也当成根因提交上去结果被判定为误报精确率下降。全召回条件下的平均精度天然鼓励模型只提交自己确信的根因把疑似但不确定的对象排除在外。Gemma 4 31B推理平均58轮拿到37%Gemini 3.1 Pro Preview 平均83轮却只有30%。过度调查的模型容易把混沌注入的控制器或者同时出现的症状当作根因上报在全召回精确率的评分规则下这些多出来的实体全是误报。这个发现对 Agent 的设计思路有直接启发。很多 Agent 框架追求更多工具调用、更长推理链、更细致的排查流程仿佛多查一轮就多一点把握。在 ITBench-AA 的 SRE 场景里这个思路行不通。精准定位根因干净利落提交答案比翻箱倒柜地把所有可疑对象都报上去要聪明得多。运维排障也遵循同样的规律。企业里排查故障最怕的就是找到一堆疑似问题却分不清主次。误报根因的代价同样高昂运维团队按照错误方向去排查浪费的时间和人力都是实打实的损失。一个能精准定位根因的 Agent远比一个什么都要报一通的 Agent 有价值。ITBench-AA 的评分机制巧妙地把这种现实约束转化为了评测规则逼迫模型在准确和全面之间做出取舍。开源模型的性价比战场闭源模型拿走了前几名开源模型却在性价比上打了一场漂亮的翻身仗。Gemma 4 31B推理每道题只花0.14美元得分37%在分数上超过了每道题花2.23美元、得分30%的 Gemini 3.1 Pro Preview。花的钱不到对方的1/15分数还高出7个百分点。GLM-5.1推理每道题1.23美元拿到40%和 Gemini 3.5 Flash高推理的1.70美元、40%持平但成本更低。Claude Opus 4.7自适应推理最大努力以47%占据榜首但每道题5.38美元是最贵的选手。对企业来说7分的性能提升值不值得付出近4倍的价格是个需要认真权衡的问题。尤其是在大规模部署 Agent 的场景里一天跑上千次故障排查任务5.38美元和1.23美元的差距调用的成本差距会迅速放大。从 ITBench-AA 的数据看开源模型已经站在了性价比的前沿线上。ITBench-AA 目前只发布了 SRE 部分后续 FinOps 和 CISO 任务会陆续上线。FinOps 关注云资源成本优化CISO 聚焦安全合规三个方向加起来基本覆盖了企业 IT 管理的核心版图。随着更多领域的企业 IT 任务加入评测模型在不同专业场景下的表现差异也会更加清晰。一个模型在 SRE 上表现好在 FinOps 上未必同样出色这种跨场景的差异化评测对企业的选型决策很有参考价值。企业级 IT 运维场景Agent 还有很长的路要走。参考资料https://arxiv.org/abs/2502.05352https://github.com/itbench-hub/ITBenchhttps://artificialanalysis.ai/evaluations/itbench-aahttps://huggingface.co/datasets/ArtificialAnalysis/ITBench-AA
