运维智能体（AIOps Agent）现状综述

一、概述：从 AIOps 到 AIOps Agent

1.1 概念演进

AIOps 一词自 2016 年由 Gartner 提出以来，其内涵经历了三个阶段的变化：

阶段	时间	核心范式	代表能力
AIOps 1.0	2016–2019	基于规则 + 统计 ML	异常检测、告警聚合、指标预测
AIOps 2.0	2020–2023	深度学习 + 图谱	因果推理、日志模式挖掘、多模态关联
AIOps Agent	2024–至今	LLM 驱动的自主智能体	自然语言交互、工具调用、自主排查、Runbook 执行

根本性的变化在于：传统 AIOps 工具是被动的分析引擎——接收运维数据，输出分析结果，等待人类决策。而 AIOps Agent 是主动的推理-执行体——它理解工单意图、规划排查路径、调用监控/诊断工具、解读结果、形成根因假设并验证，直至给出可执行的修复建议。二者的关系不是替代，而是：Agent 将传统 AIOps 的分析能力作为"工具箱"来编排和调用。

1.2 为什么是现在

AIOps Agent 在 2024–2025 年的集中涌现，由三个技术条件共同促成：

LLM 的代码与工具使用能力：GPT-4/Claude/DeepSeek 等基础模型具备了理解和生成运维命令、解读日志和配置、调用 API 的能力
Agent 框架的成熟：ReAct、Plan-and-Execute、Multi-Agent 等 Agent 架构模式在通用任务中被验证，可直接迁移至运维领域
基础设施的可观测性工程化：OpenTelemetry、Prometheus、eBPF 等数据采集标准的普及，为 Agent 提供了可查询、可关联的统一数据基础

1.3 运维智能体的能力谱系

           理解力（语义理解、推理深度）
                ▲
                │
┌───────────────┼───────────────┐
│  STRATUS      │  Flow-of-Action│ 高级
│  TNR安全约束  │  SOP约束Agent │
│  RCAgent      │  mABC         │
├───────────────┼───────────────┤
│  D-Bot        │               │ 中级
│  领域特化诊断  │  LLM辅助RCA   │
├───────────────┼───────────────┤
│  规则引擎      │  统计异常检测  │ 基础
│  固定阈值告警  │  已知模式匹配  │
└───────────────┴───────────────┘
                                    执行力（自动化程度、爆炸半径）

二、学术研究进展

本节覆盖 2023–2025 年间 AIOps Agent 领域的主要学术工作，按主题分为综述与评测基准、Agent 架构与协作、领域特化诊断、日志与告警分析、自动修复五个方向。

2.1 综述与评测基准

2.1.1 AIOps 故障管理综述（Peking University, 2024）↗

论文：A Survey of AIOps for Failure Management in the Era of Large Language Models，arXiv 2024，arXiv:2406.11213

作者/机构：Lingzhe Zhang, Tong Jia, Philip S. Yu 等，北京大学 + UIC

核心贡献：首个系统性对比传统 AIOps 与 LLM 基 AIOps 方法的综述，涵盖故障管理的完整生命周期——数据预处理、异常检测、根因分析、自动修复。论文将 LLM 基方法分为四类：基础模型直接调用、微调、Embedding 基、Prompt 基，并对每类方法在不同子任务上的表现进行了对比分析。

关键结论：LLM 在语义理解和跨任务泛化方面显著优于传统 ML 方法，但在可解释性、推理一致性和数据隐私方面仍存在明显不足。

2.1.2 AIOpsLab：Agent 化的云运维评测框架（MLSys 2025）↗

论文：AIOpsLab: A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds，MLSys 2025，arXiv:2501.06706

作者/机构：Yinfang Chen, Chetan Bansal, Saravan Rajmohan 等，Microsoft + UIUC

核心贡献：提出了 AgentOps 范式——AI Agent 自主管理云基础设施的完整事件生命周期。AIOpsLab 是一个开源框架，可部署微服务环境、注入故障、生成负载、导出遥测数据，并通过 Agent-Cloud Interface（ACI）供 Agent 调用。框架支持 100+ 问题场景，覆盖检测、定位、RCA、缓解等任务。

关键数据：SOTA Agent 在 SRE 场景的成功率仅为 13.8%，表明全自主云运维仍有巨大提升空间。

2.1.3 其他评测基准：OpsEval、LogEval、ITBench

基准	论文/年份	覆盖范围	关键特性
OpsEval ↗	Liu et al., 2024 (Tsinghua + Microsoft)	8 类 AIOps 任务，7184 道选择题 + 1736 道 QA	中英双语、3 级能力分层、GPT-4 评分与人工专家 92% 一致性
LogEval ↗	Cui et al., 2024 (Tsinghua + Nankai)	日志解析、异常检测、故障诊断、摘要 4 项任务	4000 条日志、每任务 15 种 Prompt 变体、中英双语
ITBench ↗	Chen et al., 2025 (IBM + UIUC)	SRE / CISO / FinOps 三域	94 个真实场景、SRE 成功率 13.8%、FinOps 0%

2.2 Agent 架构与多智能体协作

2.2.1 Flow-of-Action：SOP 约束的 RCA Agent（WWW 2025）↗

论文：Flow-of-Action: SOP Enhanced LLM-Based Multi-Agent System for Root Cause Analysis，WWW 2025，arXiv:2502.08224

作者/机构：中科院计算所 + 字节跳动 + 清华大学

核心问题：通用 ReAct Agent 在 RCA 场景下表现不佳——缺乏结构化排查步骤的约束，Agent 容易在无关事件上浪费工具调用次数，或给出"貌似合理"但经不起推敲的结论。

方法论：

将人类 SRE 的标准操作流程（SOP）编码为 Agent 的状态机约束——Agent 必须按"环境检查 → 告警定位 → 变更关联 → 指标验证 → 日志取证 → 根因假设 → 修复验证"的顺序推进
每个阶段预定义可用的工具集，限制 Agent 在给定阶段只能调用该阶段授权的工具
通过 Langfuse 进行全链路追踪，支持人工回放和修正

关键数据：

当 RCA Agent 被 SOP 约束时，准确率从 ReAct baseline 的 35.50% 提升至 64.01%
SOP 约束并未降低 Agent 的灵活性——而是将"何时可以灵活"的控制权从 Agent 归还给流程设计者

启示：SOP 约束 + LLM Agent 是一个被低估的组合——它不是让 Agent "更自由"，而是让 Agent "在限定步骤内更聪明"。这一思想也影响了后续评测基准的设计：一个好的 AIOps Agent 评测框架，本身就应该通过流程约束来评估 Agent 的结构化诊断能力。

2.2.2 RCAgent：工具增强型自主 RCA Agent（CIKM 2024）↗

论文：RCAgent: Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models，CIKM 2024（该会议当年引用数排名第 1），arXiv:2310.16340 | ACM DOI

作者/机构：Zefan Wang（清华）+ Zichuan Liu（南大）+ Aoxiao Zhong（哈佛）+ 阿里巴巴 Flink 团队

核心问题：传统云 RCA 方法依赖人工预设的工作流程，未能发挥 LLM 的自主决策和环境交互能力。同时，工业部署有严格的数据隐私限制，无法使用 GPT-4 等外部 API。

方法论：

观察快照键（Observation Snapshot Key）：用键值存储压缩长上下文，解决多轮工具调用导致的 Token 爆炸问题——仅保留观察的摘要键而非完整内容
领域专家智能体：内嵌代码分析工具（递归搜索 + 总结）和日志分析工具（图聚类 + RAG），增强 Agent 对代码仓库和日志的理解能力
轨迹级自洽性（Trajectory-level Self-Consistency, TSC）：仅在"finalize"阶段采样多条轨迹，兼顾多样性与效率——相比传统 CoT-SC 更适用于 Agent 长轨迹场景
隐私友好：全流程运行在内部部署模型（Vicuna-13B-16K）上，无需依赖外部 LLM API

关键数据：

所有 RCA 维度（根因预测、解决方案、证据、责任判定）一致优于 ReAct 基线
根因预测 METEOR 指标提升 +8.71，解决方案提升 +6.52
动作轨迹通过率 99.38%，无效行动率仅 7.93%
已集成到阿里巴巴云 Apache Flink 实时计算平台的故障诊断流程中

启示：RCAgent 证明了在工业隐私约束下，基于内部部署模型 + 工具增强的 Agent 架构可以有效落地——不需要 GPT-4，不需要外部 API，仍然可以显著超越 ReAct 基线。

2.2.3 STRATUS：多智能体自主可靠性工程（NeurIPS 2025）↗

论文：STRATUS: A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds，NeurIPS 2025，arXiv:2506.02009

作者/机构：Yinfang Chen, Jiaqi Pan, Jackson Clark, Yiming Su, Tianyin Xu 等，IBM Research + UIUC

核心问题：如何让多 Agent 系统在云 SRE 场景中安全地自主决策？——单个 Agent 的误判可能导致级联故障，多 Agent 之间的协调失误更加危险。

方法论：

多 Agent 架构：按 SRE 职责拆分为 Detection Agent、Diagnosis Agent、Mitigation Agent，以状态机组织——每个阶段只能由对应 Agent 执行，防止越界操作
Transactional No-Regression（TNR）安全规范：定义了修复操作的安全约束——任何缓解操作必须可验证、可回滚，且不能引入新故障。TNR 本质上是一种"软事务"——允许 Agent 在安全边界内自主探索，但一旦触达边界即自动回滚
AIOpsLab + ITBench 双基准评测：在两个独立的评测框架上验证

关键数据：STRATUS 在 AIOpsLab 和 ITBench 上均以至少 1.5× 的幅度超越现有 SOTA SRE Agent。

启示：STRATUS 的 TNR 安全规范为 Agent 的自主决策提供了工程可落地的安全约束——它的核心洞察是：安全约束不是限制 Agent 的能力，而是定义了 Agent 可以放心探索的边界。这与 Flow-of-Action 的 SOP 约束在哲学上高度一致，但 STRATUS 将约束从"流程层面"下沉到了"执行安全层面"。

2.2.4 mABC：区块链启发的多智能体 RCA（EMNLP 2024）↗

论文：mABC: Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture，EMNLP 2024 Findings，PDF | GitHub

作者/机构：Wei Zhang, Hongcheng Guo, Bo Zhang 等

核心问题：在微服务架构中，单个 LLM Agent 的幻觉（hallucination）在 RCA 场景中尤其危险——错误的根因判断可能将 SRE 引向完全错误的方向。多 Agent 辩论可以部分缓解幻觉，但缺乏结构化的共识机制。

方法论：

7 个专精 Agent：每个 Agent 拥有不同的专业领域和工具集，独立分析同一故障
区块链启发的投票机制：每个 Agent 的投票权重由贡献指数（Contribution Index）和专业指数（Expertise Index）共同决定——避免"多数暴政"，也让真正有相关领域知识的 Agent 的意见获得更高的权重
Agent Workflow 标准化：定义客观有限的步骤数，避免微服务循环依赖导致的 Agent 死循环

关键数据：在 AIOps Challenge 数据集和自建的 Train-Ticket 数据集上均优于基线方法。消融实验证实：Agent Workflow、多 Agent 协作和区块链投票三项设计均对最终性能有显著贡献。

启示：mABC 的多 Agent 投票机制为解决 LLM Agent 的幻觉问题提供了一条新路径——不是让单个 Agent 更准确，而是让多个 Agent 的集体判断更可靠。这与软件工程中的"多重复审"（Multiple Review）方法论一致。

2.2.5 Agent 架构路线对比

维度	Flow-of-Action	RCAgent	STRATUS	mABC
Agent 数量	多 Agent（SOP 约束）	单 Agent + 专家工具	多 Agent（状态机组织）	7 Agent + 投票
核心约束机制	SOP 流程约束	工具增强 + 隐私保护	TNR 安全规范	区块链投票共识
部署状态	研究原型	阿里巴巴 Flink 生产集成	研究原型	研究原型
关键指标	准确率 35.5%→64.0%	METEOR +8.71	1.5× SOTA	优于基线
安全机制	阶段工具白名单	内部模型隔离	TNR 回滚	多 Agent 投票
主要威胁	SOP 外场景适应性差	工具链绑定	状态机设计复杂度	Agent 数量 × 通信开销

2.3 领域特化诊断 Agent

2.3.1 D-Bot：LLM 基数据库诊断系统（VLDB 2024）↗

论文：D-Bot: Database Diagnosis System using Large Language Models，VLDB 2024（PVLDB Vol.17），arXiv:2312.01454 | GitHub

作者/机构：Xuanhe Zhou, Guoliang Li 等，清华大学数据库组

核心问题：数据库诊断是运维中最依赖专家经验的领域之一——DBA 需要同时理解 SQL 语义、执行计划、系统配置、硬件状态才能定位根因。传统方法依赖人工专家逐层排查，耗时长且难以规模化。

方法论：

离线知识提取：从海量数据库管理文档（万页级）中自动提取诊断知识，构建摘要树（Summary Tree），将长文档压缩为结构化知识块
树搜索 RCA（Tree-Search RCA）：不使用简单的 CoT，而是构建分析节点树——每个节点是对一个可能根因的分析，由数据库反馈 + LLM 置信度联合评分，多分支并发探索后汇聚
协同诊断机制：复杂多根因场景下，调度多个 LLM "专家" 并行分析（每个配备不同工具集和知识库），交叉审查后生成统一诊断报告
Human Feedback Loop：支持人工反馈修正，修正模式存入向量数据库用于持续学习

关键数据：

覆盖 6 类典型数据库应用、539 个异常案例
自动生成诊断报告耗时 < 10 分钟（人类 DBA 通常需数小时）
在未见过的异常类型上也保持有效诊断能力
支持中英文，已开源并支持 Docker 部署

启示：D-Bot 是"领域知识 + Agent 架构"结合的经典案例——模型本身不是关键（可使用 GPT-4 或内部模型），真正的壁垒在于将数万页的数据库管理知识结构化为 Agent 可检索、可推理的知识图谱。这一模式可推广到网络设备诊断、存储系统诊断等其他领域特化场景。

2.4 LLM 基日志与告警分析

2.4.1 LLM4Log 系统综述 ↗

论文：LLM4Log: A Systematic Review of Large Language Model-based Log Analysis，arXiv 2025，arXiv:2604.16359

作者/机构：Concordia University（Ma, Yang, Chen 等）

核心贡献：对 2020–2025 年间 145 篇 LLM 基日志分析论文的系统性综述。覆盖从日志语句生成 → 日志解析 → 异常检测 → 故障预测 → 根因分析 → 日志摘要的完整流水线。

关键发现：

约 2/3 的论文集中在异常检测和日志解析两个环节，RCA 和日志摘要是增长最快的方向
主流技术路线：Prompting/ICL → RAG 增强 → 微调 → 工具/Agent 增强 → 验证
开放挑战：概念漂移下的鲁棒性、长尾事件处理、幻觉控制、面向运维人员的可解释性

2.4.2 代表性日志分析方法

方法	年份	核心思路	关键特性
LogPrompt ↗	2023	Zero-shot Prompt 工程	相比简单 Prompt 提升 380.7%
LILAC	2024	LLM + 自适应解析缓存	F1 提升 69.5%
LogLLM ↗	2024	BERT 语义向量 + Llama 分类	无需独立日志解析器，4 数据集 SOTA
R-Log	2024–2025	强化学习推理	模拟人类工程师步骤，通过奖励函数减少幻觉
LogEval ↗	2024	LLM 日志分析评测基准	4 任务 × 15 Prompt 变体，中英双语

2.4.3 基于 LLM 的告警压缩与总结

代表工作：微软 Azure、Google SRE、Datadog 均部署了基于 LLM 的告警摘要和相似告警聚类功能。

核心能力：

对告警风暴进行实时聚类——将数分钟内数百条告警按拓扑、语义和时间合并为 3-5 个独立事件
生成人类可读的告警摘要："在过去 5 分钟内，rack-b12 的 8 个节点同时出现 RDMA 链路错误，ToR 交换机 uplink 利用率超过 95%，疑似 uplink 拥塞导致"
相似告警召回：从历史数据库中检索与当前告警模式最相似的历史事件及其处理记录

技术路线：

Embedding 基：将告警文本和标签向量化，做语义聚类和相似度搜索
LLM 基：将聚类后的告警组直接送入 LLM 生成摘要和关联解释

2.4.4 Elastic 的日志异常检测

Elastic Stack（ELK）从 8.x 版本开始内置了基于机器学习的日志异常检测和告警规则引擎，支持：

时间序列异常检测：检测日志量、错误率、响应时间的基线漂移
日志模式异常检测：检测日志中出现的新模式（如新出现的错误消息）
分类分析：在大量日志中自动识别"与常态不同的分类分布"

这些传统 ML 能力与 LLM 的语义理解能力互补——前者负责发现"哪里变了"，后者负责解释"这个变化意味着什么"。

2.5 自动修复与自愈

2.5.1 低风险自动处置

当前业界对"自动修复"的共识是分阶段推进，优先自动化那些"即使误判也不会造成严重后果"的动作：

风险等级	动作类型	示例
极低	信息收集	自动拉取 dump、trace、完整日志包
低	通知与路由	自动静默已知维护窗口告警、自动升级 P1 事件到值班群
中	资源调整	自动将重复故障节点移出调度池（quarantine）、自动扩容
高	变更操作	自动回滚配置、自动切换网络路径、自动重启服务
极高	基础设施操作	节点下线、存储迁移、网络拓扑变更

当前落地状态：低风险和部分中风险动作已在大型云厂商和 GPU 集群中实现了一定程度的自动化。高风险动作仍普遍保留人工审批。如 STRATUS 论文所示，SOTA Agent 在 SRE 自主处置场景的成功率仅 13.8%，自主修复离生产就绪仍有相当距离。

2.5.2 自主修复的代表性研究

方法	年份/会议	核心思路	关键结果
STRATUS	NeurIPS 2025	TNR 安全约束下的多 Agent 自主 SRE	1.5× SOTA，安全约束优先
ICSSSM 多 Agent	2025	CrewAI + DeepSeek-R1/GPT-4o	RCA 准确率 96%，端到端 < 28 min
ARM	2024	闭环 LLM Agent：RCA + 缓解	云-边-端统一框架
LLexus	SIGOPS 2024	Agent 基 TSG 自动执行	事件缓解自动化
AI-Augmented Self-Healing	2024	LLM + RL 生成修复 Playbook	K8s + Prometheus + Lambda 集成

三、工业界产品与平台

3.1 Microsoft Azure ↗

Azure Monitor | Copilot for Azure | SuperBench 开源

产品矩阵：Azure Monitor（可观测） + SuperBench（GPU 验证） + Copilot for Azure（AI 助手） + Azure Resource Graph（资源拓扑）

AIOps 核心能力：

能力域	具体实现
全栈可观测	Azure Monitor 统一采集指标（Metrics）、日志（Log Analytics）、追踪（Application Insights），支持 Prometheus/Grafana 集成和 OpenTelemetry 标准
GPU 集群验证	SuperBench 提供面向 AI 训练 workload 的微基准主动验证——在生产前/中对 GPU 通信模式、带宽、延迟做持续验证，发现灰故障和性能退化。该研究发现其 A100 集群的 MTBI 仅为 17.5 小时，38.1% 事件修复超 1 天
智能告警	基于机器学习的动态基线告警（Smart Alerts），自动根据历史模式调整阈值，减少静态阈值带来的误报和漏报
变更影响分析	Azure Resource Graph 提供跨订阅/资源组的拓扑查询，结合变更日志实现"变更 → 异常"的自动关联
AI 辅助诊断	Copilot for Azure 支持自然语言查询——"为什么我的 AKS 集群在过去一小时内 GPU 利用率下降了 30%？"——Agent 自动调用 PromQL、日志查询和拓扑搜索，生成结构化诊断报告

LLM/Agent 集成深度：

Copilot for Azure 基于 OpenAI GPT-4 模型，深度集成于 Azure Portal、Azure CLI 和移动 App 中
Agent 可调用 Azure Resource Graph 查询资源拓扑、Kusto 查询语言（KQL）搜索日志、Azure Monitor API 拉取指标
2024-2025 年路线图包括：自动化 Runbook 推荐、变更风险评分、以及对 SuperBench 的 Agent 化编排

差异化特征：

SuperBench 的"主动验证"理念——不等故障发生再排查，而是通过持续微基准测试提前发现性能退化——是业内独特且被验证有效的实践
深度集成 GitHub Copilot 生态，开发者和 SRE 在同一界面内完成代码→部署→监控→排障的闭环

3.2 Google Cloud ↗

Cloud Monitoring | Gemini Cloud Assist | SRE Book

产品矩阵：Cloud Monitoring + Cloud Logging + Cloud Trace + Error Reporting + Gemini Cloud Assist + SRE 方法论

AIOps 核心能力：

能力域	具体实现
SLO 驱动的监控	以服务等级目标（SLO）为核心而非以告警数量为核心——通过 Error Budget 燃尽率控制告警的触发和升级节奏。这是 Google SRE 方法论在 AIOps 产品中的工程化落地
多信号关联	Cloud Monitoring 支持跨指标、日志、追踪的统一查询语言（MQL），在同一时间窗内自动关联多源信号
日志智能分析	Cloud Logging 内置日志异常检测（Log Analytics），支持自动识别日志中出现的新错误模式、错误率突变和分布漂移
分布式追踪	Cloud Trace 提供基于 OpenTelemetry 的端到端追踪，支持 AI/ML 推理请求的跨服务调用链分析
AI 辅助排障	Gemini Cloud Assist 集成于 Google Cloud Console，支持自然语言对话式运维——"分析 app-engine-service 的错误日志，找出过去 2 小时内的根因"

LLM/Agent 集成深度：

Gemini Cloud Assist 基于 Gemini 模型，通过与 Cloud Monitoring/Logging/Trace 的原生集成实现深度运维查询
支持自动生成告警规则（基于自然语言描述）、自动推荐监控 dashboard 配置
2025 年路线图：Gemini 驱动的自主诊断 Agent——从告警触发自动排查流程，输出根因假设与 Runbook

差异化特征：

SRE 方法论的产品化：Google 将内部 SRE 实践（SLO、Error Budget、事后复盘 Blameless Postmortem）深度嵌入 AIOps 产品设计
BigQuery 分析能力：Cloud Logging 支持将海量日志导入 BigQuery 做大规模 SQL 分析，适合万卡级集群的海量日志分析
GKE + GPU 运维：Google Kubernetes Engine（GKE）对 GPU 工作负载的一等支持，结合 Cloud Monitoring 的 GPU 指标采集（通过 DCGM），在 Kubernetes-native GPU 运维场景中有明显优势

3.3 AWS ↗

CloudWatch | DevOps Guru | Amazon Q Developer

产品矩阵：CloudWatch（监控+日志+告警） + X-Ray（追踪） + DevOps Guru（ML 基异常检测） + Amazon Q Developer（AI 助手） + AWS Config（资源配置与变更追踪）

AIOps 核心能力：

能力域	具体实现
统一可观测	CloudWatch 提供指标、日志、追踪的统一采集和存储，支持跨 AWS 服务的统一告警，内置数百个 AWS 服务的预置指标和 dashboard
ML 基异常检测	CloudWatch Anomaly Detection 基于 ML 自动学习指标的历史模式并设定动态告警阈值；DevOps Guru 更进一步——自动分析应用行为，识别异常并关联到具体的资源、指标和日志事件
日志洞察	CloudWatch Logs Insights 支持类 SQL 的自然语言查询；CloudWatch Logs Anomaly Detection 自动检测日志模式异常
变更关联	AWS Config 追踪所有 AWS 资源的配置历史和变更时间线，DevOps Guru 自动将检测到的异常与最近的配置/部署变更关联
AI 排障助手	Amazon Q Developer 支持对话式运维——"为什么我的 SageMaker 训练作业在过去几次迭代中速度变慢？"——自动查询 CloudWatch 指标、日志和 X-Ray trace 给出诊断

LLM/Agent 集成深度：

Amazon Q Developer 是面向开发者和运维人员的统一 AI 助手，集成于 AWS Console、IDE、CLI 和 Slack/Teams
运维场景中，Q 可调用 CloudWatch API、查询 CloudTrail、分析 Config 变更记录
Agent 能力仍在早期：2024-2025 年的重点在"信息检索和摘要"，而非"自主排查和修复"
Amazon Bedrock 为构建自定义运维 Agent 提供了模型层基础设施（Claude、Llama 等）

差异化特征：

SageMaker 原生 GPU 运维：对 GPU 训练和推理工作负载的深度集成——SageMaker 训练作业的 GPU 指标、数据加载 I/O、checkpoint 存储等一揽子监控
DevOps Guru 的无配置 ML：无需手动定义规则和阈值，自动学习应用基线并关联变更，对"灰故障"和"非显式异常"的检测能力在业界领先
安全与合规的一体化：CloudTrail（审计）+ GuardDuty（威胁检测）+ Security Hub 与运维监控的统一串联，使安全事件可作为运维事件的一部分被处理

3.4 Datadog ↗

Datadog | Bits AI | LLM Observability

产品矩阵：Infrastructure Monitoring + APM + Log Management + Bits AI + Watchdog + LLM Observability

AIOps 核心能力：

能力域	具体实现
全栈监控	覆盖基础设施、应用、网络、数据库、Serverless 的统一监控平台，支持 800+ 集成（包括 NVIDIA GPU、Kubernetes、Slurm 等 AI 基础设施组件）
Watchdog 异常检测	基于 ML 的自动异常检测引擎——无需手动配置，自动学习每个指标的历史基线并检测偏离，支持对 APM 异常和日志异常的自动发现
智能告警	支持复合条件告警（多个指标联合判断）、动态阈值、告警关联和分组
LLM Observability	专门面向 LLM 应用的可观测性模块——追踪 LLM 调用的延迟、token 消耗、质量和成本，支持 LangChain/OpenAI/Anthropic 等主流框架的自动埋点
Bits AI 助手	基于自然语言的对话式运维查询——"Show me the top 5 error logs from the payment-service in the last hour"——自动查询相关数据源并生成摘要和可视化

LLM/Agent 集成深度：

Bits AI 目前处于"Copilot"阶段——作为查询和摘要助手，不执行自主诊断或修复动作
LLM Observability 是 Datadog 2024 年的重点产品方向，反映了"监控 AI 应用"本身成为一个新需求
Agent 能力路线：2025 年计划支持基于 Bits AI 的自主排查流程，从"查询"升级到"诊断"

差异化特征：

800+ 集成生态：覆盖 GPU 厂商（NVIDIA DCGM）、ML 框架（PyTorch、TensorFlow）、调度器（Slurm、K8s）、ML 平台（Kubeflow、MLflow），为 AI 基础设施提供开箱即用的全栈视图
LLM Observability：随着 LLM 应用大规模部署，监控 LLM 调用链路本身（包括 token 消耗、PII 泄露、质量评估）正在成为一个独立的 AIOps 子领域
Watchdog 的零配置理念：自动学习基线、自动发现异常、自动生成摘要——降低 AIOps 的使用门槛

3.5 PagerDuty ↗

PagerDuty Operations Cloud | PagerDuty Advance

产品矩阵：PagerDuty Operations Cloud（告警管理 + 事件响应 + 自动化 Runbook）+ PagerDuty Advance（AI 原生功能）

AIOps 核心能力：

能力域	具体实现
告警降噪	基于 ML 的告警分组（Alert Grouping）——将同一根因产生的数百条告警自动合并为一个 Incident，减少信号噪声。支持基于时间窗口、拓扑依赖、文本相似度的多策略分组
事件管理	完整的 Incident 生命周期管理——自动升级、自动通知、SLA 追踪、事后复盘（Postmortem）
自动化 Runbook	通过 Rundeck 集成实现 Runbook 自动化——当特定类型的 Incident 触发时，自动执行预定义的诊断和修复脚本
AI 事件分析	PagerDuty Advance 基于生成式 AI 自动生成 Incident 摘要——将冗长的事件日志、相关告警历史和团队讨论压缩为一段可读的摘要，自动推荐可能的根因和处理步骤

LLM/Agent 集成深度：

PagerDuty Advance 采用"AI 辅助人类决策"而非"AI 替代人类决策"的设计——生成摘要和推荐，但不自主执行修复
AI 生成 Incident 回顾报告（Post-Incident Review），自动从事后复盘中提取经验教训
2025 年路线图：Agent 化的 Runbook 编排——AI 根据 Incident 特征自动选择和编排 Runbook 步骤

差异化特征：

定位在"事件响应"而非"全栈监控"——与 Datadog/CloudWatch 等监控平台互补而非竞争，专注于从"告警产生"到"事件关闭"的完整响应流程
Ops Cloud 理念：将告警管理、事件响应、自动化 Runbook、状态页通信、事后复盘统一为一个平台（Operations Cloud），减少工具切换带来的信息断链
在 AIOps Agent 评测中的参考价值：Agent 的诊断-修复-验证闭环与 PagerDuty 的事件管理流程在设计理念上高度对应——事件管理流程本身为 Agent 评测框架提供了天然的状态机模型

3.6 ServiceNow ↗

ITOM AIOps | Now Assist

产品矩阵：ITOM AIOps（事件管理 + 告警关联 + 自动化修复） + ITSM（IT 服务管理） + Now Assist（生成式 AI 助手）

AIOps 核心能力：

能力域	具体实现
事件关联与告警管理	ITOM AIOps 支持从多源监控工具（Datadog、Prometheus、SolarWinds、Zabbix 等）汇聚告警，并通过 ML 模型自动关联为事件群（Alert Grouping），减少告警噪声
变更影响分析	ITSM 的 CMDB（配置管理数据库）与 ITOM 的变更管理模块联动——当异常检测到时，自动关联最近的相关变更（代码部署、配置修改、基础设施变更）
自动化修复	Flow Designer 提供低代码/无代码的自动化 Runbook 编排，支持 200+ 预置连接器（包括 AWS、Azure、GCP、K8s、Slurm 等）
AI 辅助	Now Assist for ITOM 基于生成式 AI 提供：自动生成事件摘要、推荐关联的配置项（CI）和过往类似事件、生成解决步骤建议、将口语化的用户故障描述自动转写为结构化工单

LLM/Agent 集成深度：

Now Assist 在 ITOM 场景中的核心价值是"信息压缩与知识检索"——将杂乱的事件信息压缩为可操作的摘要，并从知识库中检索相关 Runbook
2024 年末发布的 Now Assist Skill Kit 允许企业构建自定义的 AI 技能——例如"GPU 集群 XID 错误自动诊断技能"
Agent 化方向：ServiceNow 将 AI Agent 定位为"超自动化（Hyperautomation）"的关键组件——Agent 在 ITSM/ITOM 两大领域之间做跨域协调

差异化特征：

ITSM-ITOM 一体化：将运维（ITOM）和服务管理（ITSM）统一在单一平台上，使告警→事件→工单→变更→知识库的闭环无需跨系统集成即可完成。这对构建完整的"故障到复盘"数据链路至关重要
CMDB 作为拓扑模型的工程实现：CMDB 维护的资源配置和依赖关系本身就是 RCA 所需的"拓扑模型"——ServiceNow 的优势在于这个拓扑模型与告警、变更、工单数据天然打通
低代码 Runbook 编排：Flow Designer 使 SRE 团队可以快速构建和迭代 RCA 流程，而不需要写代码——这对运维团队而言降低了 Agent 化的工程门槛

3.7 华为 ↗

华为 AIDC | 昇腾 CANN | ModelArts

产品矩阵：AIDC 全栈运维方案 + FusionInsight（大数据/AI 平台运维） + 天筹求解器 + ModelArts AI 平台 + 昇腾 CANN 工具链

AIOps 核心能力：

能力域	具体实现
7 层全栈可视	公开提出的 AIDC 7 层分层模型，覆盖：数据中心基础设施（供电/制冷/机柜）→ 算力基础设施（昇腾 NPU/GPU 服务器）→ RoCE/IB 网络 → 集合通信（HCCL）→ AI 平台（ModelArts）→ 训练框架 → 模型与应用。每层独立采集，层间通过拓扑关联
分钟级故障定界	华为公开声称支持分钟级故障定界定位（"从数小时到数分钟"），通过分层采集 + 规则引擎 + 拓扑关联实现
昇腾原生工具链	CANN（Compute Architecture for Neural Networks）软件栈提供从驱动、runtime、集合通信到算子开发的完整运维工具——包括 HCCL（昇腾集合通信库）打流测试、Profiling 工具、健康检查诊断工具
AI 辅助诊断	结合华为云盘古大模型，在工单系统、日志分析、告警解释等场景中部署 LLM 辅助

LLM/Agent 集成深度：

华为盘古大模型已在内部运维和政企客户中部署，主要应用于：日志异常检测、告警文本生成和摘要、工单智能路由
华为公开材料强调"运维智能体"作为智算中心运维的演进方向，但具体的 Agent 化产品（如自主诊断 Agent）尚未有公开的独立产品发布
昇腾生态的运维能力主要通过 CANN 工具链和 FusionInsight 平台对外提供，与盘古大模型的集成仍在推进中

差异化特征：

昇腾全栈自研：从芯片（昇腾 NPU）→ 通信库（HCCL）→ 框架（MindSpore/ModelArts）→ 运维工具的全栈自研，使华为在故障信息采集的深度和精度上有天然优势——不需要依赖第三方驱动的诊断接口
AIDC 7 层模型的工程指向性：7 层模型不仅是理论架构，更直接映射为实际的数据采集层级和故障域划分。每层的采集工具和告警策略是独立但可关联的
政企市场优势：华为在政府和企业智算中心建设中的市场地位，使其运维方案在合规、国产化、信创适配方面有独特积累

局限：

华为公开的材料体现的是方案方向和能力声明，不等同于独立第三方验证的评测结果
昇腾生态的运维工具链覆盖较全但学习曲线陡峭，与 NVIDIA CUDA/DCGM 生态的工具链不互通

3.8 阿里云 ↗

SLS 日志服务 | ARMS | 通义灵码

产品矩阵：日志服务 SLS（Simple Log Service）+ 云监控 CloudMonitor + ARMS（应用实时监控）+ 通义灵码 + 通义千问大模型

AIOps 核心能力：

能力域	具体实现
SLS 日志智能分析	SLS 是阿里云 AIOps 能力的中枢——提供 PB 级日志的统一采集、存储、检索和分析。内置 ML 基的日志聚类（LogReduce）、异常检测（LogAnomaly）、模式挖掘和预测分析。支持 SQL + 自然语言混合查询，通过通义千问实现"用自然语言描述问题，自动生成 SQL 查询日志"
智能告警	CloudMonitor + ARMS 提供多源告警统一管理——支持动态阈值、告警降噪、通知升级和静默窗口。告警可自动关联到 SLS 中的相关日志和 ARMS 中的调用链
全链路追踪	ARMS 提供基于 OpenTelemetry 的端到端调用链追踪，支持 Java/Go/Python/Node.js 等主流语言的自动埋点，并与 SLS 日志和 CloudMonitor 指标打通
AI 辅助排障	通义灵码（Tongyi Lingma）集成于阿里云控制台和 IDE 中，支持在运维场景中自动解读错误日志、推荐 SQL 查询、生成监控 dashboard 配置

LLM/Agent 集成深度：

通义千问 + SLS 的深度整合是阿里云 AIOps 的核心差异点——用户可直接在 SLS 控制台中用自然语言提问："分析过去 30 分钟内 error 级别日志的根因"，系统自动将问题转换为 SLS 查询语句，执行后将结果通过 LLM 生成人类可读的分析报告
通义灵码在 2024-2025 年正在从"代码补全工具"扩展到"运维助手"——支持 K8s 故障排查、日志解读、告警分析等场景
Agent 化进展：阿里云内部已在探索"通义千问 Agent + SLS + CloudMonitor"的自主诊断流水线，但正式产品尚未发布

差异化特征：

SLS 的全栈日志分析：SLS 不仅是一个日志存储和搜索工具，更是一个内置了 ML 能力的分析引擎——LogReduce（日志聚类）、LogAnomaly（异常检测）、时序预测等能力直接内置，无需额外搭建 ML 管道
淘宝/天猫的大规模运维经验：阿里云 AIOps 产品背后是双 11、618 等全球最大规模电商流量下的真实运维经验——数据库（PolarDB）、消息队列（RocketMQ）、容器服务（ACK）等核心产品的运维最佳实践被沉淀为产品能力
通义千问的生态整合：LLM 能力不是作为一个单独的"AI 功能模块"存在，而是深度嵌入到 SLS、CloudMonitor、ARMS 等现有产品的工作流中——"LLM 增强现有工具，而非替代它们"

局限：

AIOps Agent 的自主化程度仍在早期——当前更接近"LLM 增强的查询和分析"，而非"自主执行诊断和修复的 Agent"
GPU 集群运维的专用能力相对较弱——SLS 和 CloudMonitor 更擅长通用云原生运维场景，对 GPU 训练的通信拓扑、集合通信算子、NVLink 等专用指标的覆盖不如 SuperBench/DCGM 专门化方案

3.9 腾讯 ↗

腾讯云可观测平台 | 蓝鲸平台 | Holmes 论文详见《智算集群 RCA 方法综述》

产品矩阵：Holmes（GPU 训练故障诊断）+ 织云（内部 AIOps 平台）+ 蓝鲸（运维自动化和 SaaS 开发平台）+ 腾讯云可观测平台

AIOps 核心能力：

能力域	具体实现
GPU 训练故障诊断	Holmes（NSDI 2025）——面向大规模 LLM 训练的故障诊断系统。在训练框架中嵌入通信算子日志器，构建通信算子图（COG），通过 BFS/DFS 混合搜索在 DP/TP/PP 拓扑中追踪 straggler 根因。在 3072 GPU 场景中，仅访问 106 个相关 GPU 的日志即可定位根因
织云 AIOps	腾讯内部的大规模运维平台——覆盖数百万服务器、数万个业务。提供统一告警管理、智能事件关联、自动化 Runbook 编排、故障自愈等能力
蓝鲸平台	面向企业客户的运维自动化和 SaaS 开发平台——提供 CMDB、作业平台（自动化和脚本编排）、监控平台、日志平台等模块化组件。蓝鲸的核心设计理念是"运维开发一体化"——SRE 可以在蓝鲸平台上快速构建自定义的运维工具和 SaaS
腾讯云可观测平台	面向公有云用户的可观测产品——整合指标、日志、追踪、事件管理，支持 Prometheus/Grafana/OpenTelemetry 生态

LLM/Agent 集成深度：

Holmes 系统本身不是 LLM Agent，但其"拓扑化推理"思路是 LLM Agent 在 GPU 诊断场景中的重要参考架构
腾讯混元大模型在内部运维中已开始试探性应用——消息队列故障的自动分析、数据库慢查询的根因推理
蓝鲸平台正在探索"大模型 + 运维流程"的智能编排——通过 LLM 自动将自然语言描述的运维需求转化为作业平台的自动化流程

差异化特征：

GPU 集群运维的学术级深度：Holmes 是业界首个在顶会（NSDI 2025）发表的 GPU 集群故障诊断系统，其"通信算子图 + 拓扑化 RCA"方法论在 Agent 领域有重要的参考价值
运维开发一体化（蓝鲸的理念）：蓝鲸的平台化设计——让 SRE 能用 SaaS 化方式构建运维工具——天然为 Agent 化提供了基础。Agent 不再需要"从零构建工具"，而是可以直接编排蓝鲸平台上已有的运维原子能力
内部验证的规模化：织云平台在腾讯内部的运维规模（百亿级指标、百万级服务器）为 AIOps 方法提供了极大规模的真实验证环境

局限：

Holmes 和织云的能力主要为腾讯内部使用，对外商业化程度有限。蓝鲸平台虽然对外开源/商业化，但其 AIOps 模块的开放度和标准化程度不如国际竞品
在公有云运维产品（腾讯云可观测平台）中，LLM/Agent 的集成深度落后于 AWS Q 和 Google Cloud Assist

3.10 字节跳动 ↗

相关论文：Robust LLM Training Infrastructure at ByteDance（2025），arXiv:2509.16293；Flow-of-Action 论文见 §2.1.3

产品矩阵：内部 AIOps 平台（未对外商业化）——覆盖 K8s 集群运维、容量管理、故障自愈、变更管控

AIOps 核心能力：

能力域	具体实现
大规模 K8s 集群运维	管理月级数千个 Kubernetes 集群和百万级节点——在如此规模下，"手工运维"是不可能的，自动化是唯一的选项。字节的 AIOps 聚焦于 K8s-native 场景的故障自动检测、隔离和恢复
容量与资源管理	基于 ML 的容量预测和弹性伸缩——根据历史业务流量和训练/推理需求自动调整集群规模和资源分配
变更管控	严格的变更管理流水线——每次部署、配置变更、基础设施变更都被追踪，并与后续的异常检测关联
故障自愈	针对已知故障模式（节点不可达、Pod CrashLoop、磁盘满、GPU ECC 错误等）的自动隔离和恢复流程——通过 operator 模式在 K8s 中实现

LLM/Agent 集成深度：

字节跳动在 LLM 应用方面动作积极（豆包大模型），但在公开的运维 Agent 落地方案方面披露较少
内部探索方向包括：基于 LLM 的日志异常语义分析、告警自动摘要和关联、以及将自然语言运维需求转换为 K8s operator 配置
Agent 化路线：字节的 AIOps 更侧重于"规则化自动化 + ML 增强"而非"LLM Agent 自主决策"——反映了字节技术栈偏实用主义的风格

差异化特征：

极致规模下的运维实践：数千个 K8s 集群、百万级节点的运维规模在全球互联网公司中属于顶级。字节的 AIOps 方案在极端规模下的可靠性经过了内部严苛验证
K8s Operator 模式的深度应用：字节内部大量使用 K8s Operator 模式实现运维自动化——Operator 负责检测→决策→执行→验证的闭环，这本质上是 Agent 的早期形态（有限状态机而非 LLM 驱动）
数据闭环文化：字节的运维文化强调"一切可量化"——每个故障都有 SLO 定义、MTTR 追踪和复盘记录。这为 AIOps Agent 的构建提供了教科书级别的数据基础

局限：

字节的 AIOps 平台未对外商业化，公开信息有限
对 GPU 专用诊断（如通信拓扑级排查）的公开方案不如腾讯 Holmes 深入

3.11 H3C（新华三）↗

H3C 智算解决方案

核心方案：万卡级 AI 数据中心端-网-存全局可视运维体系

AIOps 核心能力：

H3C 在智算运维领域的核心主张是"端-网-存全局可视"——将计算（GPU 服务器）、网络（RoCE/IB fabric）、存储（分布式文件系统）的统一可视化作为万卡级 AI 数据中心运维的基础。H3C 将这一方案定位为 AI 数据中心的"统一运维底座"——提供计算资源健康监控、网络 fabric 拓扑可视、存储性能和容量监控的三维一体视图。

具体能力包括：GPU 节点的温度/功耗/ECC 错误/PCIe 健康监控；RoCE/IB 网络的端口健康、链路利用率、拥塞检测；分布式存储的 MDS/OSS/OST 监控和性能基线告警；以及将三者通过拓扑关联实现跨层故障的粗定位。

LLM/Agent 集成深度：H3C 公开材料中强调了"运维智能体"作为 AI 数据中心运维的演进方向，但目前的产品形态更偏向"提供全栈数据和可视化"，而非"提供可自主诊断的 Agent"。LLM 的应用场景主要是告警自然语言描述和操作手册检索。

差异化特征：H3C 在网络设备（交换机/路由器）领域的深厚积累使其在 AI 数据中心网络 fabric 运维方面有独特优势——尤其是 RoCE 和 IB 网络的深度 telemetry 采集和故障诊断。

3.12 中国联通研究院

核心方案：智算网络运维白皮书——数字孪生 + 故障自愈 + 管控运维智能体

AIOps 核心能力：

联通研究院提出的智算网络运维体系包含三个核心方向：

数字孪生：为智算网络构建数字孪生模型——将物理网络拓扑、流量模式、设备状态实时映射到数字空间，在孪生体中做故障仿真和故障预案演练
故障自愈：基于预定义的故障模式 + 数字孪生仿真结果，实现特定网络故障场景的自动恢复——包括链路切换、流量重路由、设备隔离等
管控运维智能体：将"运维智能体"作为智算网络运维的关键演进方向——目标是构建可理解运维意图、可自主规划排查步骤、可调用网络管理接口的 Agent

LLM/Agent 集成深度：联通的白皮书对"运维智能体"的定位是中长期演进方向而非当前产品能力。在具体技术路径上，联通强调了"意图驱动网络（Intent-Driven Networking）"——运维人员描述期望的网络状态，Agent 自动将意图转化为具体的网络配置操作。这一理念与 AIOps 社区中的"自然语言驱动的运维"思路一致。

差异化特征：联通的切入点是运营商级网络的运维场景——智算网络（联接 GPU 集群的网络 fabric）本身成为运维对象。这与云厂商从"计算和存储"切入的视角不同——联通更关注网络 fabric 层的故障诊断和自愈。

3.13 开源项目全景

项目	定位	关键技术	成熟度
AISHPerf（CAICT）	AIOps 评测基准 + 故障模拟器	混沌工程 + 标准化评测数据集 + 评测框架	早期（2026 年开源）
OpenTelemetry（CNCF）	可观测数据采集标准	指标/日志/追踪统一采集、Collector 汇聚转发	生产就绪，事实标准
Prometheus + Alertmanager	时序监控与告警管理	PromQL 查询 + 告警去重/分组/路由/抑制	生产就绪
Grafana	可视化 + 告警	多数据源仪表盘、告警规则、静默与路由	生产就绪
NVIDIA DCGM	GPU 层监控	ECC/XID/PCIe/NVLink/热功耗指标	生产就绪，GPU 运维不可替代
Falco（CNCF）	运行时安全检测	内核级系统调用监控、容器/K8s 异常行为检测	生产就绪
Langfuse	LLM 应用可观测	Agent 全链路 Trace、评估、Prompt 管理	快速成长中
Keep	开源告警管理	告警去重、关联、工作流自动化	成长中
Robusta	Kubernetes 运维自动化	K8s 事件监控、自动修复 playbook	成长中
Chaos Mesh	云原生混沌工程	K8s-native 故障注入（网络/存储/Pod/内核）	CNCF 孵化项目
LitmusChaos	混沌工程平台	声明式故障注入、GitOps 集成	CNCF 孵化项目
Elastic Stack	日志分析 + 异常检测	ML-based 日志异常检测、时间序列分析	生产就绪
eBay Groot	事件因果图 RCA	事件图构建 + PageRank 排序	开源（2021）
MCP（Anthropic）	Agent 工具接入协议	标准化工具接口、多语言 SDK	快速成长中

四、AIOps Agent 评测基准全景

4.1 现有评测资源的局限

在标准化评测基准出现之前，AIOps Agent 的评测面临几个系统性不足：

缺乏标准化数据集：大多数评测依赖各家自建的内部数据集，不可复现、不可比较
缺乏真实故障注入：评测通常是"给 Agent 一段描述文本，问根因是什么"，缺少故障注入 → 采集 → 诊断的闭环
缺乏难度分层和人工基线：不知道一个任务对人类 SRE 意味着什么难度，就无法衡量 Agent 的"智能"程度
GPU 异构生态覆盖不足：国外基准通常仅覆盖 NVIDIA GPU，国内国产 GPU 的运维场景缺乏评测支持
安全运维场景缺失：大多数 AIOps 评测基准不包含安全事件（入侵、挖矿、权限滥用）

4.2 评测基准的设计要素

一个面向 AIOps Agent 的标准化评测基准，核心应包含三个组件：故障模拟器（注入真实故障并导出遥测数据）、标准化数据集（标注根因、难度、预期诊断路径）和评测框架（自动化评分、支持多种 Agent 架构接入）。

与已有工具的对比（以 AISHPerf 作为 AIOps Agent 评测基准的代表实现）：

维度	通用 LLM Agent 基准	AIOps Agent 评测基准	SuperBench
故障注入	无	16 类故障、90+ 用例	GPU 微基准注入
标准化数据集	无/少	103 条 JSONL	无
评测框架	通用	专为 AIOps 设计	性能指标
GPU 异构覆盖	无	6 家厂商	NVIDIA only
安全场景	无	含入侵/挖矿检测	无
人工基线（human_seconds）	无	每条都有	无
难度分层	粗粒度	easy/medium/hard 三级	无
端到端流水线	部分	注入→诊断→恢复→评分	注入→验证

4.3 其他相关评测资源

资源	类型	覆盖范围	限制
Microsoft SuperBench	微基准验证框架	GPU 计算/通信复合基准	无诊断评测、无 NLP 问题
NVIDIA DCGM Diagnostics	GPU 健康检查	ECC/PCIe/带宽/CUDA 健康	仅限 GPU 层、无跨层诊断
Chaos Mesh / LitmusChaos	通用混沌工程	Kubernetes 层面故障注入	无诊断评测、无 AIOps 特化
GAIA Benchmark	通用 Agent 评测	多步推理、工具使用	非运维特化，不包含基础设施场景
SWE-bench	代码修复评测	GitHub Issue → PR	软件工程导向，非运维导向

4.4 评测方法论的关键问题

问题一：如何定义"正确答案"？

在 RCA 场景中，"根因"的定义本身就是分层的——是一个节点？一个 GPU？一个 PCIe 链路？还是一个驱动版本？合理的做法是定义 expected_output.root_cause 为具体可操作的根因描述（如"GPU 2574 计算变慢"），并要求 Agent 输出包含该实体的诊断结论。

问题二：如何平衡自动化评分与人工评分？

规则基评分（精确匹配节点/组件）适用于 easy/medium 难度，但 hard 难度的案例往往需要语义级评分——Agent 可能没有正确输出故障节点编号，但推理路径完全正确。双重评测器设计（RuleBased + LLMBased）是当前较合理的方案。

问题三：如何衡量 Agent 的效率而不仅是准确率？

human_seconds 字段提供了一个有意义的效率基线。一个好的 AIOps Agent 不仅应该"做对"，还应该比人类更快。这一维度在目前的所有评测基准中几乎都被忽略。

五、关键技术路线

5.1 Agent 架构模式

AIOps Agent 的架构主要沿以下几条路线演进：

路线一：ReAct（Reasoning + Acting）

1	用户输入 → Thought（分析）→ Action（调用工具）→ Observation（观察结果）→ Thought → ...

优势：灵活，不需要预定义流程劣势：在 RCA 场景中容易"迷路"——在没有 SOP 约束时，Agent 可能在无关日志上浪费大量 token 和工具调用 代表实现：LangChain ReAct Agent、AutoGen Assistant

路线二：Plan-and-Execute（先规划再执行）

1	用户输入 → Planner（制定排查计划）→ Executor（按计划逐步执行）→ Evaluator（评估结果是否充分）→ 如需补充，重新规划

优势：结构清晰，排查路径可追踪劣势：规划的粒度难以把握——太粗则无指导意义，太细则适应性差 代表实现：Flow-of-Action、LangGraph StateGraph

路线三：SOP 约束的有限状态机

┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
│ 告警定位 │───→│ 变更关联 │───→│ 指标验证 │───→│ 日志取证 │
└─────────┘    └─────────┘    └─────────┘    └─────────┘
                                                    │
                    ┌─────────┐    ┌─────────┐      │
                    │ 修复验证 │←───│ 根因假设 │←─────┘
                    └─────────┘    └─────────┘

优势：可控、可解释、爆炸半径小劣势：无法处理 SOP 序列之外的意外路径 代表实现：Flow-of-Action、企业级 AIOps 平台

路线四：Multi-Agent 协作

Coordinator Agent
    ├── Log Analyzer Agent（日志分析专精）
    ├── Metrics Agent（时序指标分析专精）
    ├── Network Agent（网络拓扑分析专精）
    ├── Storage Agent（存储层分析专精）
    └── Security Agent（安全事件分析专精）

优势：各 Agent 可独立优化，专家知识可模块化沉淀劣势：Agent 间通信和冲突协调复杂，Multi-Agent 架构本身尚在早期 代表实现：AutoGen Multi-Agent、CrewAI、LangGraph 多 Agent 编排

总结：从 Flow-of-Action 的实验数据来看（SOP 约束将准确率从 35.50% 提升至 64.01%），当前阶段最有效的路线是三和四的结合——在 SOP 约束的框架内，在每个阶段部署领域特化的 Sub-Agent。

5.2 工具使用机制

AIOps Agent 需要调用的工具类型，按其语义层级可分为五类：

工具类别	典型工具	输入	输出
查询类	PromQL 查询、Elastic 搜索、SQL	自然语言或结构化查询	指标值、日志行、事件列表
诊断类	DCGM 诊断、SuperBench 微基准、nvidia-smi	目标节点/GPU	健康状态、错误计数、带宽
拓扑类	NVLink 拓扑查询、IB fabric 拓扑、K8s 拓扑	节点/作业标识	拓扑邻接信息
操作类	kubectl、systemctl、Slurm scontrol	目标对象 + 操作类型	执行结果
知识类	Runbook 检索、故障库查询、文档搜索	症状或错误码	历史相似案例、解决步骤

工具接入范式：

MCP（Model Context Protocol）：Anthropic 提出的标准化工具接入协议，在部分评测框架中已支持通过 MCP 协议接入工具服务
Function Calling：OpenAI 兼容的函数调用接口，是当前最广泛的工具接入方式
自定义 Plugin：LangChain Tool / AutoGen Tool 等框架级插件机制

5.3 知识库与 RAG

运维知识库在 Agent 中的作用不仅是"提供参考信息"，更是约束 Agent 的推理边界。典型的运维知识库结构：

┌─────────────────────────────────────────────┐
│  运维知识库（RAG Retrieval Target）            │
├─────────────────────────────────────────────┤
│  故障模式库        │ 已知故障签名 → 根因 → 修复  │
│  Runbook 库       │ 标准操作流程 → 检查步骤     │
│  已知问题库        │ 厂商发布的已知 bug/workaround│
│  配置基线库        │ 各机型/组件的标准配置       │
│  拓扑快照库        │ 历史拓扑状态 → 变更追踪     │
│  工单归档库        │ 历史工单 → 处理记录 → 结论  │
└─────────────────────────────────────────────┘

这与学术界故障诊断系统（如 L4 等）的 fault library 思路一致——知识库不仅用于信息检索，更是 Agent 推理的"锚点"。在遇到新故障时，Agent 首先查询知识库中是否有匹配的历史模式；只有在未命中的情况下，才进入开放式推理。详见《智算集群 RCA 方法综述》。

5.4 Multi-Agent 协作

当前 Multi-Agent 在运维场景中的主要落地模式：

模式	说明	适用场景
分工协作	不同 Agent 负责不同组件（网络/存储/计算）的独立分析，结果汇总至 Coordinator	故障可能跨层时
辩论式	多个 Agent 独立给出根因假设，互相交叉验证	故障症状模糊、需要多角度分析
层级式	L1 Agent 做粗筛（"哪个组件有问题"），L2 Agent 在锁定组件范围内做精细分析	大规模场景的分层排查
人工审查式	Agent 输出诊断建议，人类 SRE 审查并确认/修正，修正结果回写知识库	需要控制自动化爆炸半径的场景

六、挑战与趋势

6.1 当前阶段的核心挑战

挑战一：数据基础先于模型能力

这是反复被证实的结论——在统一 incident schema、统一拓扑标识、定义良好的 resolved cases、准确时间同步和可回写工单系统建立之前，AI/ML 几乎无法学到稳定的运维规律。Flow-of-Action 的实验中，Agent 在低质量数据条件下的准确率甚至低于纯规则方法。

挑战二：版本漂移与域迁移

GPU 驱动、CUDA/ROCm、训练框架、通信库的迭代速度以月计，许多根因在版本升级后会改变其表现位置与特征。这意味着：

知识库必须持续更新
Agent 推理策略需要随环境变化重新校准
"一次训练，长期运行"的模型部署范式在 AIOps 中不成立

挑战三：可解释性与爆炸半径

即使是最先进的 AIOps Agent，其诊断结论也是对"可能性"的排序而非确证。一旦将 Agent 的建议不经人工审查直接执行——如节点下线、路径切换、版本回滚——误判将造成比原故障更严重的连锁影响。

Flow-of-Action 论文中 64.01% 的准确率意味着每 3 次 Agent 判断中就有 1 次可能出错。这对生产环境来说仍过高。

挑战四：评测体系的缺失

如前所述，在 2024 年之前，几乎没有专门针对 AIOps Agent 的标准化评测基准。缺乏可复现、可比较的评测体系，直接阻碍了该领域的学术研究和工业落地之间的相互验证。

挑战五：Multi-Agent 系统的可靠性

Multi-Agent 系统的协调开销和通信故障模式尚未被充分研究。当 Coordinator Agent 给出错误的职责划分时，错误会向下传播并被各 Sub-Agent 放大。

6.2 未来趋势

趋势一：Agent 能力从"辅助"到"半自主"的渐进演进

预计演进路径：

2025 → 辅助（Agent 提供诊断建议，人类做全部决策）
2026 → 监控（Agent 自主执行信息收集和初步分析）
2027 → 推荐（Agent 自主完成诊断并给出修复方案，人类审批执行）
2028 → 半自主（低风险场景 Agent 自主处置，高风险仍人工审批）

这与此前 RCA 工程指南中提出的四阶段路线一致。

趋势二：评测基准的标准化

AIOps Agent 的评测正在从"各家自建不可比数据集"向"标准化、可复现的评测基准"收敛。以故障模拟器 + 标准化数据集 + 评测框架为核心组件的评测模式正在成为共识。预计会有更多类似 SuperBench（用于性能验证）的标准化评测工具出现。

趋势三：SOP + Agent 的深度融合

Flow-of-Action 已经证明 SOP 约束对 Agent 准确率的提升效果显著。未来这一方向可能的发展：

可学习的 SOP：从历史工单处理流程中自动提取和优化 SOP
自适应的 SOP：根据当前故障的特征动态调整 SOP 的步骤顺序和粒度
SOP 共享：跨组织共享和持续改进的 SOP 知识库

趋势四：领域特化模型的兴起

通用 LLM（GPT-5、Claude 4、DeepSeek 等）在运维领域的能力取决于 Prompt Engineering 的质量——需要大量特定领域的上下文才能产出可用的分析。领域特化模型（如基于通用模型微调的 AIOps-specific 模型）可能成为提升 Agent 准确率和降低成本的关键路径。

趋势五：与混沌工程的深度融合

"故障模拟器 + 评测数据集 + 评测框架"的三位一体模式可能成为 AIOps Agent 评测的标准范式。未来可能出现：

在 Agent 运行过程中动态注入新故障以测试鲁棒性
使用混沌工程覆盖"长尾故障"来扩充评测数据集
Agent 的"自我训练"——在混沌测试环境中自动发现自身弱点并迭代优化

七、总结：AIOps Agent 领域的现状与方向

7.1 领域成熟度地图

       数据/benchmark 成熟度
              ▲
              │
高  ┌─────────┼─────────┐
   │ 告警管理  │         │
   │ (已商用)  │         │
   ├──────────┼─────────┤
   │          │         │
中  │ 日志分析  │ 异常检测 │
   │          │         │
   ├──────────┼─────────┤
   │          │         │  ← Agent RCA
低  │          │ Agent   │   评测基础设施
   │          │ 自主RCA │   刚刚起步
   └─────────┼─────────┘
              │
      低      中      高    Agent 自主化程度

Agent 自主 RCA 恰好位于"低成熟度 × 高潜力"的交汇点——评测基础设施刚刚起步，而这一方向的工程价值已被学术界和工业界广泛认可。

7.2 评测基准建设的核心方向

填补标准化评测空白：在 2024 年之前，AI 运维 Agent 领域缺乏可复现的标准化评测基准，这也是当前社区最紧迫的建设方向
端到端流水线闭环：故障模拟 → Agent 诊断 → 评分 → 导出的闭环设计，是评测基准应参考的核心架构模式
多厂商覆盖：评测基准需要覆盖多家 GPU 厂商和异构硬件生态，这对中国 AI 基础设施生态尤其重要
以人为基准的评测理念：human_seconds 基线、难度分级、双重评测器等设计，体现了"以人类 SRE 为基准"的评测理念

7.3 开放问题

103 条评测数据是否足够覆盖 AIOps Agent 的能力边界？ ——当前数据集覆盖 11 个故障域和 6 家 GPU 厂商，但每个细分组合的样本量很小。需要持续扩充。
评测框架是否可能被"刷榜"？ ——任何标准化评测都有被过度优化的风险。需要定期补充新的故障类型和场景。
Agent 在真实生产环境中的表现与评测环境中的差异有多大？ ——评测环境中的故障是已知的、可控的、可恢复的；生产环境中的故障是未知的、复合的、后果不可逆的。这一 gap 需要持续的现场验证。
如何建立跨组织的评测数据共享机制？ ——运维数据天然敏感，但孤立的评测数据和 benchmark 限制了领域进步。联邦学习或隐私保护评测可能是解决方案。

本文基于对 AIOps Agent 领域的学术文献分析、工业界产品动态和开源项目的综合调研。覆盖时间范围为 2023–2026 年。工业产品信息基于各厂商公开文档和官方发布。完整引用链接见下方参考资料。

参考资料

学术论文

简称	完整标题	会议/期刊	年份	链接
AIOps 故障管理综述	A Survey of AIOps for Failure Management in the Era of Large Language Models	arXiv	2024	arXiv:2406.11213
AIOpsLab	AIOpsLab: A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds	MLSys	2025	arXiv:2501.06706
OpsEval	OpsEval: A Comprehensive Task-Oriented AIOps Benchmark for Large Language Models	arXiv	2024	arXiv:2310.07637
LogEval	LogEval: A Comprehensive Benchmark Suite for Large Language Models In Log Analysis	arXiv	2024	arXiv:2407.01896
RCAgent	RCAgent: Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models	CIKM	2024	arXiv:2310.16340 · ACM
STRATUS	STRATUS: A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds	NeurIPS	2025	arXiv:2506.02009
mABC	mABC: Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture	EMNLP (Findings)	2024	PDF · GitHub
D-Bot	D-Bot: Database Diagnosis System using Large Language Models	VLDB	2024	arXiv:2312.01454 · GitHub
LLM4Log	LLM4Log: A Systematic Review of Large Language Model-based Log Analysis	arXiv	2025	arXiv:2604.16359
LogPrompt	LogPrompt: Prompt Engineering Towards Zero-Shot and Interpretable Log Analysis	arXiv	2023	arXiv:2308.07610
Flow-of-Action	Flow-of-Action: SOP Enhanced LLM-Based Multi-Agent System for Root Cause Analysis	WWW (Industry)	2025	arXiv:2502.08224
Holmes	Holmes: Localizing Irregularities in LLM Training with Mega-scale GPU Clusters	USENIX NSDI	2025	PDF · 会议页
L4	L4: Diagnosing Large-scale LLM Training Failures via Automated Log Analysis	ACM FSE	2025	arXiv:2503.20263
Meta 可靠性研究	Revisiting Reliability in Large-Scale Machine Learning Research Clusters	arXiv	2024	arXiv:2410.21680
SuperBench	SuperBench: Improving Cloud AI Infrastructure Reliability with Proactive Validation	USENIX ATC (Best Paper)	2024	arXiv:2402.06194 · GitHub
Groot	Groot: An Event-graph-based Approach for Root Cause Analysis in Industrial Settings	IEEE/ACM ASE	2021	arXiv:2108.00344 · GitHub
KGroot	KGroot: A Knowledge Graph-Enhanced Method for Root Cause Analysis	Expert Systems with Applications	2024	arXiv:2402.13264
字节训练基础设施	Robust LLM Training Infrastructure at ByteDance	arXiv	2025	arXiv:2509.16293
GPU 弹性特征	Characterizing GPU Resilience and Impact on AI/HPC Systems	arXiv	2025	arXiv:2503.11901

工业产品

厂商	产品/方案	链接
Microsoft Azure	Azure Monitor	https://learn.microsoft.com/en-us/azure/azure-monitor/
	Copilot for Azure	https://learn.microsoft.com/en-us/azure/copilot/
	SuperBench (开源)	https://github.com/microsoft/superbenchmark
Google Cloud	Cloud Monitoring	https://cloud.google.com/monitoring
	Gemini Cloud Assist	https://cloud.google.com/products/gemini
	SRE 方法论	https://sre.google/books/
AWS	CloudWatch	https://aws.amazon.com/cloudwatch/
	DevOps Guru	https://aws.amazon.com/devops-guru/
	Amazon Q Developer	https://aws.amazon.com/q/developer/
Datadog	Datadog 平台	https://www.datadoghq.com/
	Bits AI	https://www.datadoghq.com/product/bits-ai/
	LLM Observability	https://www.datadoghq.com/product/llm-observability/
PagerDuty	Operations Cloud	https://www.pagerduty.com/platform/operations-cloud/
	PagerDuty Advance	https://www.pagerduty.com/platform/advance/
ServiceNow	ITOM AIOps	https://www.servicenow.com/products/it-operations-management.html
	Now Assist	https://www.servicenow.com/now-platform/now-assist.html
华为	AIDC 智算中心	https://www.huawei.com/cn/technology/ai-data-center
	昇腾 CANN	https://www.hiascend.com/software/cann
	ModelArts	https://www.huaweicloud.com/product/modelarts.html
阿里云	SLS 日志服务	https://www.aliyun.com/product/sls
	ARMS 应用监控	https://www.aliyun.com/product/arms
	通义灵码	https://tongyi.aliyun.com/lingma
腾讯	腾讯云可观测平台	https://cloud.tencent.com/product/tcop
	蓝鲸平台	https://bk.tencent.com/
字节跳动	训练基础设施论文	https://arxiv.org/abs/2509.16293
H3C（新华三）	智算解决方案	https://www.h3c.com/cn/Products_Technology/Technology/Intelligent_Computing/
中国联通研究院	智算网络运维白皮书	参见联通研究院官方网站

开源项目与标准

项目/标准	说明	链接
AISHPerf	AIOps 评测基准 + 故障模拟器	https://gitee.com/aishperf-caict/aishperf_openness
OpenTelemetry	可观测数据采集标准 (CNCF)	https://opentelemetry.io/
Prometheus	时序监控 (CNCF Graduated)	https://prometheus.io/
Alertmanager	告警管理	https://prometheus.io/docs/alerting/latest/alertmanager/
Grafana	可视化与告警	https://grafana.com/
NVIDIA DCGM	GPU 数据中心管理	https://developer.nvidia.com/dcgm
Falco	运行时安全 (CNCF Graduated)	https://falco.org/
Langfuse	LLM 应用可观测	https://langfuse.com/
Keep	开源告警管理	https://www.keephq.dev/
Robusta	K8s 运维自动化	https://home.robusta.dev/
Chaos Mesh	云原生混沌工程 (CNCF Incubating)	https://chaos-mesh.org/
LitmusChaos	混沌工程平台 (CNCF Incubating)	https://litmuschaos.io/
Elastic Stack	日志分析 + ML 异常检测	https://www.elastic.co/
MCP	Model Context Protocol (Anthropic)	https://modelcontextprotocol.io/
GAIA Benchmark	通用 Agent 评测	https://huggingface.co/gaia-benchmark
SWE-bench	软件工程 Agent 评测	https://www.swebench.com/

来源	标题	链接
科技日报	中国信通院发布 AI Infra 运维领域首个评测基准	https://www.stdaily.com/web/gdxw/2026-06/30/content_539880.html
C114 通信网	中国信通院发布 AI Infra 运维领域首个评测基准	https://www.c114.net.cn/ainews/95440.html
东方财富	中国信通院牵头，首个智算运维智能体评测基准来了	https://finance.eastmoney.com/a/202606303788468120.html
智东西	让 AI 自己修服务器？先过了这场"火线测试"再说	https://zhidx.com/p/570345.html

运维智能体（AIOps Agent）现状综述

一、概述：从 AIOps 到 AIOps Agent

1.1 概念演进

1.2 为什么是现在

1.3 运维智能体的能力谱系

二、学术研究进展

2.1 综述与评测基准

2.1.1 AIOps 故障管理综述（Peking University, 2024）↗

2.1.2 AIOpsLab：Agent 化的云运维评测框架（MLSys 2025）↗

2.1.3 其他评测基准：OpsEval、LogEval、ITBench

2.2 Agent 架构与多智能体协作

2.2.1 Flow-of-Action：SOP 约束的 RCA Agent（WWW 2025）↗

2.2.2 RCAgent：工具增强型自主 RCA Agent（CIKM 2024）↗

2.2.3 STRATUS：多智能体自主可靠性工程（NeurIPS 2025）↗

2.2.4 mABC：区块链启发的多智能体 RCA（EMNLP 2024）↗

2.2.5 Agent 架构路线对比

2.3 领域特化诊断 Agent

2.3.1 D-Bot：LLM 基数据库诊断系统（VLDB 2024）↗

2.4 LLM 基日志与告警分析

2.4.1 LLM4Log 系统综述 ↗

2.4.2 代表性日志分析方法

2.4.3 基于 LLM 的告警压缩与总结

2.4.4 Elastic 的日志异常检测

2.5 自动修复与自愈

2.5.1 低风险自动处置

2.5.2 自主修复的代表性研究

三、工业界产品与平台

3.1 Microsoft Azure ↗

3.2 Google Cloud ↗

3.3 AWS ↗

3.4 Datadog ↗

3.5 PagerDuty ↗

3.6 ServiceNow ↗

3.7 华为 ↗

3.8 阿里云 ↗

3.9 腾讯 ↗

3.10 字节跳动 ↗

3.11 H3C（新华三）↗

3.12 中国联通研究院

3.13 开源项目全景

四、AIOps Agent 评测基准全景

4.1 现有评测资源的局限

4.2 评测基准的设计要素

4.3 其他相关评测资源

4.4 评测方法论的关键问题

五、关键技术路线

5.1 Agent 架构模式

路线一：ReAct（Reasoning + Acting）

路线二：Plan-and-Execute（先规划再执行）

路线三：SOP 约束的有限状态机

路线四：Multi-Agent 协作

5.2 工具使用机制

5.3 知识库与 RAG

5.4 Multi-Agent 协作

六、挑战与趋势

6.1 当前阶段的核心挑战

挑战一：数据基础先于模型能力

挑战二：版本漂移与域迁移

挑战三：可解释性与爆炸半径

挑战四：评测体系的缺失

挑战五：Multi-Agent 系统的可靠性

6.2 未来趋势

趋势一：Agent 能力从"辅助"到"半自主"的渐进演进

趋势二：评测基准的标准化

趋势三：SOP + Agent 的深度融合

趋势四：领域特化模型的兴起

趋势五：与混沌工程的深度融合

七、总结：AIOps Agent 领域的现状与方向

7.1 领域成熟度地图

7.2 评测基准建设的核心方向

7.3 开放问题

参考资料

学术论文

工业产品

开源项目与标准

相关行业动态