Qwen3.7-Max ITBench-AA 企业运维与 SRE 故障根因分析实测

一句话结论

在 IBM Research 与 Artificial Analysis 联手推出的真实企业级 SRE 运维基准 ITBench-AA 中，Qwen3.7-Max 发布即斩获全球 #3，在沙箱化 Kubernetes 复杂事故多维快照分析中展现出突出的跨系统根因定位能力。

测试环境

• 评测基准：ITBench-AA（IBM ITBench 独立复现版）。

• 测试场景：59 个真实企业级 Kubernetes 故障排查任务（40 个公开场景 + 19 个未公开私有验证场景），每项任务重复测试 3 次以消除随机误差。

• 输入数据载荷：离线事故快照（包含全量 Prometheus 指标、OpenTelemetry Traces、K8s Events、系统告警日志与应用服务拓扑图）。

• 运行框架：Stirrup（开源 Agent 执行沙箱，赋予模型自主 Shell 交互与文件检索权限）。

• 评分标准：全召回率下的平均精确率（Average Precision at Full Recall：在无假阴性的前提下计算 TP / (TP + FP)）。

输入/配置

• 诊断输出：要求 Agent 在沙箱中完成链路排查后，输出一份标准 JSON 故障诊断书，显式指定根本原因实体（Deployment, Service, Pod, Namespace, NetworkPolicy, ConfigMap 等）。

• 思考模式：开启 Thinking 模式，赋予工具探索与日志过滤能力。

结果数据

1. ITBench-AA 核心排名与准确率对照 (SRE Tasks)

2. 经典故障诊断案例分析

• 案例：Feature Flag 配置引发下游服务雪崩：

  • 故障现象：otel-demo 命名空间下广告服务 CPU 骤升、延迟超标。

  • 表面诱因：下游 Ad Deployment Pod 处于高负载报警。

  • 模型表现：Qwen3.7-Max 能够顺着拓扑关系排查上游，成功定位至 flagd-config ConfigMap 中的异常标记（adHighCpu: true），而非仅标记下游受影响的 Pod，避免了误判。

• 案例：环境变量端口错配导致通信中断：

  • 故障现象：Shipping 服务调用 Quote 服务失败。

  • 模型表现：通过 Trace 追踪与 Deployment 环境变量比对，准确抓取到 QUOTE_ADDR 误写为无效端口（quote:0000）的配置缺陷。

结论

• 企业 IT 与 SRE 场景的一流水平：在面对数百兆的指标、日志与链路拓扑多维混合输入时，Qwen3.7-Max 能有效运用 Shell 工具进行有针对性的 grep 与相关性分析，整体排查效率与定位精确率稳居全球头部（#3）。

• 交互轮次与耗时平衡：平均 35~40 轮的交互轮次与 3.5 分钟左右的解码耗时，比 Claude Opus 4.7（68.2 轮、10.16 分钟）更精简高效。

局限

• 即使是前三名模型，ITBench-AA 上的整体精确率也尚未突破 60%，表明全自主企业级 SRE 运维仍处于高难度攻坚阶段，目前仅适合作为辅助排障 Copilot，不可直接授予线上集群的无审查自愈写权限。

• 该评测基于静态离线事故快照，未涉及动态实时故障注入与长周期链路自愈交互。

复现步骤

1. 克隆官方评测套件 github.com/ArtificialAnalysis/ITBench-AA 及执行引擎 Stirrup。

2. 配置沙箱环境挂载 IBM 提供的 Kubernetes 事故快照数据包。

3. 将端点指向 qwen3.7-max，运行完整的 59 项 SRE 评估流水线，对比产出的 JSON 诊断与 Ground Truth。

来源摘录或观察（仅做合规短引）

IBM Research 与 Artificial Analysis 强调：“ITBench-AA tests AI agents on Kubernetes incident root-cause analysis... Qwen3.7-Max just hit #3 on ITbench-AA, demonstrating how well models handle real-world enterprise IT tasks, agentic-style”。