1. 论文基本信息

1.1. 标题

AIOpsLab: A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds

1.2. 作者

Yinfang Chen, Manish Shetty, Gagan Somashekar, Minghua Ma, Yogesh Simmhan, Jonathan Macc, Chetan Bansal, Ruja Wang, Saravan Rajmohan

1.3. 发表期刊/会议

该论文目前作为预印本 (preprint) 发布在 arXiv 平台。考虑到其发布日期为 2025-01-12T00:00:00.000Z，它很可能已被提交或即将提交至某个顶级会议或期刊，等待同行评审和正式发表。在计算机科学领域，特别是与人工智能和系统相关的研究，arXiv 是一个广泛使用的预印本发布平台，允许研究者在正式发表前分享其最新工作。

1.4. 发表年份

2025

1.5. 摘要

AIOps (AI for IT Operations) 旨在自动化复杂的运维任务，例如故障定位 (fault localization) 和根因分析 (root cause analysis)，以减少人工工作量并最小化对客户的影响。传统的 DevOps 工具和 AIOps 算法通常侧重于解决孤立的运维任务，而大型语言模型 (LLMs) 和 AI 智能体 (AI agents) 的最新进展正在通过实现端到端和多任务自动化来彻底改变 AIOps。本文设想了一个未来，其中 AI 智能体能够自主管理整个事件生命周期的运维任务，从而实现自愈云系统，我们称之为 AgentOps 范式。实现这一愿景需要一个全面的框架来指导这些智能体的设计、开发和评估。为此，我们提出了 AIOPSLAB，一个不仅可以部署微服务云环境、注入故障、生成工作负载和导出遥测数据，还可以编排这些组件并提供与智能体交互和评估智能体的接口的框架。我们讨论了此类整体框架的关键要求，并演示了 AIOPSLAB 如何促进下一代 AIOps 智能体的评估。通过在 AIOPSLAB 创建的基准 (benchmark) 中评估最先进的 LLM 智能体，我们深入了解了它们在处理云环境中复杂运维任务方面的能力和局限性。

1.6. 原文链接

https://arxiv.org/abs/2501.06706v1

1.7. PDF 链接

https://arxiv.org/pdf/2501.06706.pdf

2. 整体概括

2.1. 研究背景与动机

2.1.1. 论文试图解决的核心问题

论文旨在解决在复杂、分布式云环境中，如何有效地自动化运维任务以实现自愈系统，特别是针对 AI 智能体在这一领域的应用和评估问题。具体来说，它关注以下几点：

• 传统 AIOps 的局限性： 传统的 AIOps 工具和算法往往关注孤立的运维任务（如故障检测、定位），缺乏端到端 (end-to-end) 和多任务 (multitask) 的自动化能力。
• AI 智能体在 AIOps 中的潜力： LLM 和 AI 智能体具备动态与环境交互的能力，有望实现整个事件生命周期的自动化管理。
• 评估框架的缺失： 缺乏一个全面、统一的框架来指导这些能够自主管理复杂云运维任务的 AI 智能体的设计、开发和评估。

2.1.2. 为什么这个问题在当前领域是重要的

• 云系统复杂性剧增： 现代 IT 应用和服务高度依赖超大规模 (hyper-scale) 云系统，这些系统通常采用微服务 (microservices) 和无服务器计算 (serverless computing) 等分布式架构。虽然这带来了可扩展性，但也极大地增加了运维的复杂性，并引入了新的挑战。
• 故障的高昂代价： 在复杂云环境中，一个小问题可能迅速演变为大规模中断，造成巨大的经济损失（例如，Amazon 一小时中断可能造成 1 亿美元损失）。
• 人力运维负担沉重： 随着系统复杂性增加，人工管理和解决故障的难度和工作量也随之增加。AIOps 的目标正是减少人工干预，实现更高效、可靠的运维。
• LLM 和 AI 智能体带来的新机遇： 近年来 LLM 和 AI 智能体的快速发展，为实现更高级别的运维自动化提供了前所未有的可能性，即从单一任务自动化走向整个事件生命周期的自主管理。

2.1.3. 现有研究存在哪些具体的挑战或空白 (Gap)

• 缺乏集成： 现有工具虽然可以处理 AIOps 评估的各个组成部分（如可观测性工具、应用套件、混沌工程工具），但它们缺乏必要的集成来支持统一的 AIOps 评估。
• 不真实的评估场景： 现有运维基准 (operational benchmarks) 往往依赖静态数据集（如时间序列数据）或固定的问答格式，无法捕捉真实世界云环境的动态性、不可预测性和演变性。
• 关注点过于狭窄： 现有 AIOps 方法及其基准通常只关注事件生命周期的孤立方面（如异常检测、故障定位），缺乏评估 AI 智能体全面能力的框架。这限制了对链式算法或为特定场景选择最合适智能体的支持。
• 专有数据和实现： 最近在 AgentOps 方面的一些工作使用了专有服务和数据集，限制了研究的透明度和可复现性。
• 缺少高质量的基准： 尽管 AI 在 DevOps 的“开发”侧取得了显著进展（如 WebArena 等基准），但在“运维”侧，特别是 AgentOps 领域，由于缺乏高质量、多样化、真实场景的基准，进展仍然有限。

2.1.4. 这篇论文的切入点或创新思路是什么

论文通过提出 AIOPSLAB 框架来填补上述空白，其创新思路在于：

• 提出 AgentOps 范式： 明确将 AI 智能体应用于整个事件生命周期的端到端、多任务自动化，超越了传统 AIOps 对孤立任务的关注。
• 构建全面的互动式评估框架： AIOPSLAB 不仅仅是数据集，而是一个集成了云环境部署、故障注入、工作负载生成、遥测数据收集、智能体-云交互和结果评估的互动式 (interactive) 框架。
• 设计 Agent-Cloud Interface (ACI)： 提供标准化的接口，简化了 AI 智能体与复杂云环境的交互，使其能够进行操作并获得反馈。
• 开发任务导向的故障库： 引入了能够模拟真实世界复杂根本原因的功能性故障 (functional faults)，而非仅仅症状性故障 (symptomatic faults)，以全面评估智能体的诊断和缓解能力。
• 构建分层任务分类： 提出了从检测到缓解的渐进式复杂任务分类，确保评估的全面性。

2.2. 核心贡献/主要发现

2.2.1. 论文最主要的贡献是什么

论文做出了以下主要贡献：

• 明确了 AIOps 自主智能体框架的要求和挑战： 深入探讨了构建一个支持自主 AIOps 智能体设计、开发和评估的整体框架所需的关键要素和面临的挑战。
• 开发了 AIOPSLAB 框架： 提出了一个创新性框架 AIOPSLAB。该框架具备部署微服务云环境、注入故障、生成工作负载、导出遥测数据、编排这些组件，并提供智能体-云接口 (ACI) 以便与智能体交互并进行评估的能力。
• 构建了基准套件和智能体评估： 利用 AIOPSLAB 框架构建了一个包含48个问题的基准套件，涵盖不同类型的 AIOps 任务，并在互动环境中对四种 LLM 驱动的智能体进行了评估。
• 提供了详细的智能体性能分析： 通过在 AIOPSLAB 上的评估，深入分析了这些智能体的性能和局限性，揭示了它们在实际复杂云运维任务中面临的挑战。
• 承诺公开 AIOPSLAB： 论文承诺将公开 AIOPSLAB 框架，这将极大地促进 AgentOps 领域的研究和发展。

2.2.2. 论文得出了哪些关键的结论或发现

• 现有 LLM 智能体在 AIOps 任务中仍面临挑战： 尽管 LLM 智能体在处理实际运维任务方面显示出潜力，但没有一个智能体能够始终在 AIOpsLAB 基准的四个任务类别中实现高准确率，尤其是在更复杂的缓解 (mitigation) 任务中。
• FLASH 智能体表现最佳： 在所评估的智能体中，FLASH 达到了最高的总体准确率。
• 效率与准确率的权衡： GPT-3.5-TURBO 虽然完成任务最快，但准确率最低。
• 步数限制的影响： 智能体的性能受最大允许步数限制的显著影响。REACT 和 FLASH 的准确率随步数增加而提高，但 GPT-3.5-TURBO 在超过一定步数后性能不再提升，仅增加令牌 (token) 消耗。这表明 AIOps 问题的自我修复和环境反馈可能很快饱和。
• API 使用模式差异： get_logs 是最常用的 API，其次是 get_metrics 和 get_traces。不同智能体在 API 使用模式上存在差异，例如 FLASH 不使用 get_traces。
• 智能体行为中的问题：
  • 浪费步骤： 智能体常在不必要的动作上浪费步骤，例如重复调用相同 API、生成不存在的 API 或在多智能体通信中耗费过多步骤。
  • 过度使用遥测数据： 未经仔细考虑和分析就使用遥测数据（如直接 cat 大量日志或追踪），可能使模型的输入上下文窗口过载，导致令牌耗尽。
  • 无效 API 使用： 智能体在 API 调用格式上挣扎，例如 GPT-3.5-w-SHELL 经常生成不正确的命令格式。REACT 虽然有时也会出错，但通常能通过推理错误并自我纠正来恢复。
  • 误报问题： 除了 GPT-4-w-SHELL，其他智能体在没有故障的情况下会产生误报，将正常活动误判为故障。
• 传统 AIOps 方法的劣势： 所有 LLM 智能体在检测和定位任务上的表现优于传统的非 LLM AIOps 方法。

3. 预备知识与相关工作

3.1. 基础概念

• AIOps (AI for IT Operations)： 意为“用于 IT 运维的人工智能”。它利用大数据、机器学习和 AI 能力，智能地分析 IT 运维数据（如日志、指标、追踪），以自动化和改进运维任务，包括故障检测、根因分析、预测性维护等，从而减少人工干预，提高系统可靠性。
• DevOps (Development and Operations)： 是一种软件开发文化和实践，旨在通过促进开发 (Development) 和运维 (Operations) 团队之间的协作和沟通，来提高软件交付的速度、效率和质量。它强调自动化、持续集成 (Continuous Integration, CI)、持续交付 (Continuous Delivery, CD) 和持续监控。
• LLM (Large Language Models)： 大型语言模型，是一种基于深度学习的人工智能模型，通过在海量文本数据上进行训练，学习语言的统计规律，能够理解、生成和处理人类语言。它们在各种自然语言处理任务中表现出色，如文本生成、问答、翻译等。
• AI Agents (AI 智能体)： 指的是能够感知环境、进行决策并执行行动，以实现特定目标的 AI 系统。在本文语境下，AI 智能体通常指结合了 LLM 能力，并能调用外部工具 (tools) 和 API 来与真实环境（如云系统）进行动态交互的系统，以自主地完成复杂任务。
• Microservices (微服务)： 一种软件架构风格，将应用程序构建为一组小型、独立的服务，每个服务运行在自己的进程中，并通过轻量级机制（通常是 HTTP API）进行通信。微服务可以独立部署、扩展和管理，但增加了分布式系统的复杂性。
• Serverless Computing (无服务器计算)： 一种云计算执行模型，云提供商动态管理服务器资源的分配和调配。开发者只需编写和部署代码，无需关心底层服务器基础设施，按实际使用量付费。
• Fault Localization (故障定位)： 运维任务之一，指在系统发生故障时，准确识别出导致故障的具体组件、服务或代码段。
• Root Cause Analysis (RCA - 根因分析)： 运维任务之一，指在故障被定位后，进一步深入分析，找出导致故障的根本原因，而不是仅仅停留在表面症状。
• Incident Lifecycle (事件生命周期)： 指从故障发生到解决的整个过程，通常包括：检测 (Detection)、分类 (Classification)、定位 (Localization)、诊断 (Diagnosis/Root Cause Analysis)、缓解 (Mitigation)、解决 (Resolution) 和事后分析 (Post-mortem Analysis)。
• Self-healing Cloud (自愈云)： 指一种能够自动检测、诊断和修复自身故障的云系统。这是 AIOps 的最终目标之一，旨在最小化人工干预，提高系统韧性 (resilience) 和可用性。
• AgentOps (Agent for Operations)： 论文提出的一种新范式，强调 AI 智能体 (AI agents) 不仅限于处理孤立的运维任务，而是能够无缝管理整个运维堆栈中多个、跨层次的任务，自主做出实时决策并执行端到端的操作，以确保系统可靠性。

3.2. 前人工作

论文引用了大量相关工作，涵盖了 AIOps 的演进、LLM 和 AI 智能体在 AIOps 中的应用，以及现有基准和工具。为了帮助初学者理解，我们将补充一些关键概念和背景知识。

3.2.1. 传统 AIOps 和云系统管理

• 早期自愈系统概念： (Li et al., 2012; Dai et al., 2009) 早在十多年前就提出了自愈云系统的概念，强调通过自动化手段来管理和修复系统故障，减少人工干预。这为后来的 AIOps 发展奠定了基础。
• 可观测性工具 (Observability Tools)：
  • Jaeger (Jaeger Authors, 2024)： 一个开源的分布式追踪系统，用于监控和排除基于微服务架构的复杂分布式系统中的故障。它收集请求在不同服务间流动的完整路径信息（追踪），帮助开发者理解请求的延迟、服务依赖和潜在的瓶颈。
  • Prometheus (Prometheus Authors, 2024)： 一个开源的监控系统和时间序列数据库。它通过 HTTP 端点拉取 (pull) 各个服务和应用的指标 (metrics) 数据，并提供强大的查询语言 (PromQL) 和可视化能力。
  • Filebeat (Elasticsearch, 2024b) & Logstash (Elasticsearch, 2024a)： Elastic Stack （以前称为 ELK Stack）的组件。Filebeat 是一个轻量级的日志数据传输器，将日志从服务器发送到 Logstash。Logstash 是一个强大的数据处理管道，用于收集、解析、转换和丰富日志及其他事件数据，然后将其发送到 Elasticsearch 进行存储和分析。
  • Kubectl： Kubernetes 的命令行工具，用于与 Kubernetes 集群进行交互，部署和管理容器化应用程序。可以用于获取日志、查看资源状态等。
• 应用测试套件： (Gan et al., 2019; Zhou et al., 2021; Sriraman and Wensch, 2018) 提供了一系列微服务应用程序，用于测试和评估，如 DeathStarBench，其中包含了 HotelReservation 和 SocialNetwork 等应用，本文也采用了这些应用作为测试平台。
• 混沌工程 (Chaos Engineering)： (Netflix, 2011; ChaosBlade Team, 2019; ChaosMesh Authors, 2022) 一种通过在分布式系统中主动注入故障 (faults) 来测试系统韧性的实践。
  • ChaosMesh： 一个开源的混沌工程平台，用于 Kubernetes 环境，能够注入多种类型的故障（如网络延迟、Pod 崩溃等），以验证系统在各种异常情况下的行为。本文集成了 ChaosMesh 来注入故障。
  • Chaos Monkey (Netflix, 2011)： Netflix 开发的经典混沌工程工具，它随机关闭生产环境中的实例，以确保系统能够承受这种级别的故障。

3.2.2. AIOps 算法和基准

• 传统 AIOps 算法：
  • MKsMC (Çetin and Tasgin, 2020) for detection： 一种基于蒙特卡洛 (Monte Carlo) 方法的多变量 K-Sigma 分数异常检测算法，用于识别系统中的异常行为。
  • RMLAD (Wang et al., 2020) and PDiagnose (Hou et al., 2021) for localization： 用于故障定位的算法，通常通过分析系统指标、日志或追踪数据来识别故障源头。
• 静态数据集和问答基准： (Han et al., 2022; Jacob et al., 2020; Liu et al., 2023) 现有 AIOps 基准多采用静态时间序列数据或固定问答格式，无法模拟真实云环境的动态交互性和复杂性。

3.2.3. 大型语言模型 (LLM) 及其智能体

• LLM 进展： (Achiam et al., 2023) GPT-4 等模型的发布展示了 LLM 强大的语言理解和生成能力。
• LLM 智能体范式： (Mialon et al., 2023; Schick et al., 2024) 智能体结合 LLM 的推理能力和外部工具的执行能力，可以动态地与环境交互。
  • 思维链 (Chain-of-Thought, CoT) 推理： (Wei et al., 2022b) 一种提示工程技术，引导 LLM 在给出最终答案之前，逐步地展示其推理过程，从而提高复杂任务的解决能力。
  • REACT (Yao et al., 2023)： Reasoning and Acting 的缩写，是一种结合了思维链推理和行动 (Acting) 的智能体框架。它允许 LLM 在推理过程中，根据推理结果选择并执行外部工具操作，然后根据操作结果继续推理，形成迭代的“思考-行动-观察”循环。
  • FLASH (Zhang et al., 2024b)： 论文中提及的一种工作流自动化智能体，其核心思想是监控执行状态，将复杂指令分解为可管理、有条件的片段，并集成事后回溯生成 (hindsight generation) 以从过去的交互中学习。
• LLM 在 AIOps 中的应用： (Ahmed et al., 2023; Chen et al., 2024; Wang et al., 2023; Yu et al., 2024a; Jiang et al., 2024; Zhang et al., 2024a) 许多研究开始探索 LLM 如何增强 AIOps 任务，例如微调 GPT 模型、RCACopilot、RCagent、MonitorAssistant 和 Xpert 等，它们利用 LLM 来分析系统行为、推荐根因和缓解步骤等。

3.2.4. 软件开发侧的 AI 基准

• WebArena (Zhou et al., 2023)： 一个用于构建自主 AI 智能体的真实网络环境基准，评估 AI 智能体在网页浏览和操作任务中的能力。
• R2E (Jain et al., 2024b)： 将 GitHub 仓库转化为编程智能体环境的基准，用于评估 AI 智能体的代码理解和修改能力。
• HumanEval (Chen et al., 2021), LiveCodeBench (Jain et al., 2024a), SWEbench (Jimenez et al., 2024)： 用于评估 LLM 在代码生成、代码修复和解决 GitHub 问题等软件开发任务中的性能。

3.3. 技术演进

该领域的技术演进可以概括为以下几个阶段：

1. 早期自动化和自愈概念 (2000s - 2010s)： 提出通过自动化来管理复杂 IT 系统和实现自愈的概念，但主要依赖于规则、脚本和传统算法，自动化程度有限，且通常是针对特定、孤立的故障场景。
2. DevOps 和传统 AIOps 兴起 (2010s - 2020s)： DevOps 实践普及，强调开发与运维的集成。 AIOps 作为一种应用 AI 技术（如机器学习）来分析大量运维数据（日志、指标、追踪）的方法出现，以辅助甚至部分自动化故障检测、预测和简单定位。然而，其自动化能力仍主要停留在单个任务层面，缺乏端到端协同。
3. LLM 和 AI 智能体崛起 (2020s - 至今)： 随着 LLM 技术（如 GPT 系列）的突破性进展，AI 智能体开始具备强大的推理、规划和与外部工具交互的能力。这为实现更高级别的运维自动化（即 AgentOps）提供了可能性，智能体能够理解自然语言指令，动态调用工具，并完成整个事件生命周期的任务。
4. AIOPSLAB 提出的 AgentOps 范式 (本文工作)： 本文站在这一技术演进的前沿，认识到 LLM 智能体在 AIOps 领域的巨大潜力，并致力于构建一个全面的、交互式的框架 AIOPSLAB，以系统地评估和推动 AgentOps 智能体的设计和发展，旨在从根本上将 AIOps 从孤立任务推向端到端、多任务的自主云管理。

3.4. 差异化分析

AIOPSLAB 与现有工作的核心区别和创新点体现在以下几个方面：

1. 端到端、多任务评估能力：

   • 现有工作： 大多数传统 AIOps 方法及其基准只关注事件生命周期中的单个任务（如异常检测、故障定位）。
   • AIOPSLAB： 旨在评估 AI 智能体在整个事件生命周期中（从检测到缓解）的端到端和多任务能力，引入了 AgentOps 范式。

2. 交互式与动态环境：

   • 现有工作： 许多 AIOps 基准依赖静态数据集（如时间序列数据）或固定的问答格式。
   • AIOPSLAB： 提供一个交互式环境，其中 AI 智能体可以动态地与部署的微服务云系统进行交互、执行操作并接收实时反馈，更真实地模拟了实际运维场景。

3. 真实的故障建模：

   • 现有工作： 大部分故障注入工具和基准侧重于注入“症状性”故障（如性能下降、崩溃），这些故障只表现为表面症状。
   • AIOPSLAB： 引入了功能性故障 (functional faults)，这些故障模拟了更深层次的根本原因（如配置错误、软件缺陷），需要智能体进行复杂的诊断和缓解，从而更全面地评估智能体的能力。

4. 统一的评估框架：

   • 现有工作： 现有工具虽然涵盖了 AIOps 评估的不同组件（可观测性、应用套件、混沌工程），但它们通常是孤立的，缺乏一个统一的框架来协同这些组件进行评估。
   • AIOPSLAB： 提供了一个整体的、编排化的框架，集成了云环境部署、工作负载生成、故障注入、遥测收集和智能体-云接口 (ACI)，实现端到端的自动化评估流程。

5. 开放性和可扩展性：

   • 现有工作： 一些 AgentOps 研究使用了专有服务和数据集，限制了可复现性和社区贡献。
   • AIOPSLAB： 承诺将公开其框架，并设计为高度可扩展，允许用户定义新的问题、故障类型、工作负载和智能体，促进更广泛的研究和协作。

6. 专门为 LLM 智能体设计：

   • 现有工作： 通用 LLM 基准不适用于运维任务，而现有 AIOps 基准未考虑 LLM 智能体的特性（如工具使用、推理链、自然语言交互）。
   • AIOPSLAB： 专门为评估 LLM 智能体设计，通过 ACI 提供直观且易于使用的 API 接口，并能处理 LLM 智能体的独特输出和推理模式。

4. 方法论

4.1. 方法原理

AIOPSLAB 的核心原理是提供一个模拟真实的、交互式的云环境，并在此环境中自动化地生成运维问题，然后通过一个标准化的智能体-云接口 (Agent-Cloud Interface, ACI) 允许 AI 智能体与之交互，并最终全面评估智能体在解决这些问题上的表现。其设计哲学强调关注点分离，将问题定义、编排、云服务、故障库和可观测性组件解耦，以实现高度的模块化和可扩展性。通过注入具有真实根本原因的功能性故障，并结合详细的遥测数据，AIOPSLAB 旨在挑战和评估 AI 智能体在整个事件生命周期（从检测到缓解）的端到端能力。

4.2. 核心方法详解 (逐层深入)

4.2.1. 问题定义 (Problem Definition)

AIOPSLAB 首先对一个运维问题 $P$ 进行了形式化定义。一个问题被定义为一个三元组： $P = \langle T, C, S \rangle$ 其中：

• $T$ 代表任务 (Task)。它定义了智能体需要执行的特定 AIOps 操作。
• $C$ 代表上下文 (Context)。它描述了问题发生的背景信息。
• $S$ 代表预期解决方案 (Expected Solution)。它是该任务的正确结果，用于评估智能体的性能。

4.2.1.1. 任务 ($T$)

任务 $T$ 被分为四个主要类型，对应事件管理生命周期的不同阶段，复杂性递增，如 Table 1 所示。每个任务类型都关联有成功标准和评估指标。

以下是原文 Table 1 的内容：

• Level 1: Detection (检测)
  • 评估重点： 方法能否准确检测到异常或偏差？例如，检测到微服务中 Kubernetes Pod 的故障。
  • 例子： 测量“故障检测时间 (Time-to-Detect, TTD)”。
• Level 2: Localization (定位)
  • 评估重点： 方法能否精确定位故障的来源（例如，微服务）？
• Level 3: Root Cause Analysis (RCA - 根因分析)
  • 评估重点： 方法能否确定故障的根本原因？此级别包含两个子任务：预测受影响的系统层和故障类型。
• Level 4: Mitigation (缓解)
  • 评估重点： 方法能否提供有效的解决方案来恢复环境？

4.2.1.2. 上下文 ($C$)

上下文 $C$ 又被形式化为一个二元组： $C = \langle E, I \rangle$ 其中：

• $E$ 代表操作环境 (Operational Environment)。这是问题发生的具体云环境，包括：
  • 云服务 (Cloud Service)： 正在运行的微服务应用程序。
  • 故障模型 (Fault Model)： 注入到系统中的故障类型和特性。
  • 工作负载模型 (Workload Model)： 用于生成问题的用户请求模式和流量。
  • 注意： $E$ 的具体细节（如故障的精确注入点）不会直接共享给智能体，智能体需要通过观察和交互来推断。
• $I$ 代表问题信息 (Problem Information)。这是直接提供给智能体的信息，包括：
  • 服务描述 (Service Descriptions)： 关于云应用中各个微服务的描述。
  • 任务描述 (Task Descriptions)： 对智能体需要完成的任务的详细说明。
  • 可用 API 文档 (Documentation about available APIs)： 智能体可以调用哪些接口来与环境交互。
  • 间接信息： 此外，$I$ 还包括智能体在运行时可以通过查询获得的间接信息，如从操作环境观测到的日志 (logs)、指标 (metrics) 和追踪 (traces)。

4.2.1.3. 预期解决方案 ($S$)

$S$ 是任务的预期结果。对于某些任务（如缓解任务），可能存在多种解决方案。在这种情况下，AIOPSLAB 不仅会检查特定资源的修复，还会评估整个系统的状态（例如，所有服务是否正常运行），以确保在缓解过程中没有引入其他问题。

示例 2.1：故障定位任务定义

原文给出了一个 Kubernetes 目标端口配置错误定位任务的简化代码示例。这个例子展示了如何通过扩展 LocalizationTask 接口来定义一个具体的问题。

# interface.
Example 2.1. Consider the problem of localizing a Kubernetes target port misconfiguration in a social network application. AIOPSLAB makes it easy to define this problem in just a few lines by extending the Loc. t=ul configuration Task. def __init__(self): self. app = SocialNetwork() self. ans Σ = "user - service~" def start_workload(self): wrk = Wrk(rate=100, duration=10) wrk.start_workload(ur1=self.app. frontend_url) 11 def inject_fault(self)： inj Σ = UNITIe a upnt ien Jnnet ien "misconfig_k8s"( inj.inject([self.ans], "misconfig_k8s") def eval(self,soln, trace, duration): res[TTT]=duration res["success"] = i.findAll(soln, self resposta res) return res

• __init__(self)： 初始化任务，指定应用程序为 SocialNetwork，并设定预期答案 self.ans 为 "user-service"（即故障微服务的名称）。
• start_workload(self)： 启动工作负载，使用 wrk 工具以每秒100个请求 (rate=100) 持续10秒 (duration=10) 向 SocialNetwork 应用的前端 URL 发送请求。
• inject_fault(self)： 注入故障，使用故障注入器 inj 将 "misconfig_k8s" 类型的故障注入到 self.ans 指定的微服务 ("user-service") 中。
• eval(self, soln, trace, duration)： 评估智能体提交的解决方案 (soln)。它检查解决方案是否与预期答案 self.ans 匹配，并可能记录其他指标，如 TTT (Time To Task Completion)。

4.2.2. 编排器 (Orchestrator)

AIOPSLAB 的核心是编排器 (Orchestrator)。它负责协调各个系统组件之间的交互，并严格执行智能体与云环境之间的关注点分离。

下图（原文 Figure 2）展示了 AIOPSLAB 的概览，其中编排器是核心：

图1：AIOPSLAB 概览。编排器协调各个系统组件之间的交互，并充当智能体-云接口 (ACI)。智能体与编排器交互以解决任务，接收问题描述、指令和相关 API。编排器使用工作负载和故障生成器生成多样化问题，并将其注入到可部署的应用程序中。部署的服务具有可观测性，提供遥测数据，如指标、追踪和日志。智能体通过编排器执行操作，编排器执行操作并更新服务状态。编排器使用预定义的任务指标评估最终解决方案。

4.2.2.1. 智能体-云接口 (Agent Cloud Interface, ACI)

ACI 是编排器的一项关键职责，它为智能体提供了一个与云环境交互的标准化接口。其设计目标是简化智能体的决策过程，同时抽象掉底层云环境的复杂性。

• 作用：
  1. 规定智能体可执行的有效操作集。
  2. 定义服务状态如何作为观察结果反馈给智能体。
• 设计原则： 直观易用，API 列表简洁，并附有文档。
• 提供的默认 API 示例：
  • get_logs(ns: str, duration: int)：获取指定命名空间 (namespace) 在给定持续时间内的日志。
  • get_metrics(ns: str, duration: int)：获取指定命名空间在给定持续时间内的系统指标。
  • get_traces(ns: str, duration: int)：获取指定命名空间在给定持续时间内的分布式追踪数据。
  • exec_shell(command: str)：执行 shell 命令（会应用安全策略过滤）。
  • 其他 API 允许智能体进行缩放 (scaling)、重新部署 (redeploying)、打补丁 (patching) 等操作。

示例 2.2：get_traces API 定义

原文提供了一个 get_traces API 的示例，展示了 ACI 如何将复杂的底层操作封装成简单的接口：

1 class TaskActions: 2 def get_traces(ns: str, duration: int = 5) \rightarrow str: 3 get: 4 Capts Sce t raie dat o the serrices from aeger. 5 Args: 6 ns (str): The K8S namespace. 7 duration (int): Duration to collect traces. 8 Returns: 9 str: Path to the directory where traces saved. 10 = case_api = TraceAPI(ns) 11 end_t = datetime.now() 12 start_t = end_t - timedelta(duration) 13 traces traceapi.extract_traces(start_t, 14 end_t) 15 return traceapi.save_traces(traces)

• 此 API 接受 Kubernetes 命名空间 (ns) 和持续时间 (duration) 作为参数。
• 它通过 TraceAPI（可能封装了 Jaeger 的客户端）提取指定时间范围内的追踪数据。
• 最后，它将追踪数据保存到文件，并返回文件路径。
• 在初始化问题时，编排器会自动从这些 API 中提取文档，作为上下文 $C$ 的一部分提供给智能体。

4.2.2.2. 会话接口 (Session Interface)

• 作用： 管理智能体和服务的生命周期。
• 实现方式： 编排器实现为一个基于会话 (session-based) 的系统。对于每个智能体实例解决一个问题，都会创建一个会话。
• 智能体要求： 智能体必须实现一个特定的方法签名，以便与编排器交互：

  async def get_action(state: str) -> str
  

  这个方法接收服务当前状态 (state) 作为输入，并返回智能体下一步想要执行的动作 (action)。这允许 AIOPSLAB 与各种 LLM 和智能体框架集成。

示例 2.3：智能体注册和交互流程

from aiopslab import Orchestrator
class Agent:
    def __init__(self, prob, instructs, apis):
        self.prompt = self.get_prompt(prob, instructs, apis)
        self.llm = GPT4()
    async def get_action(self, state: str) -> str:
        return self.llm.generate(self.prompt + state)
# initialize the orchestrator
orch = Orchestrator()
pid = "miscconfig_app_hotel_res-mitigation-1"
prob_desc, instructs, apis = orch.init_problem(pid)
# register and evaluate the agent
agent = Agent(prob_desc, instructs, apis)
orch.register_agent(agent, name="myAgent")
asyncio.run(orch.start_problem(max_steps=10))

• Agent 类在初始化时接收问题描述 (prob_desc)、指令 (instructs) 和可用 API (apis) 来构建其内部提示 (prompt)。
• 编排器 (orch) 通过 init_problem(pid) 初始化一个特定问题。
• 智能体通过 orch.register_agent(agent, name="myAgent") 注册到编排器。
• orch.start_problem(max_steps=10) 启动问题解决过程，编排器会反复调用智能体的 get_action 方法，直到问题解决或达到最大步数限制。

4.2.2.3. 其他接口

• 问题初始化器 (Problem Initializers)：

  • 服务部署： 编排器使用基础设施即代码 (Infrastructure-as-Code) 工具（如 Helm）部署每个问题所需的云服务。
  • 工作负载生成器 (Workload Generator)： 编排器与工作负载生成器接口，注入模拟用户请求的流量。目前使用 wrk2 (Gan et al., 2019)，它支持多种工作负载策略和行业工作负载重放，并且可扩展。
  • 故障生成器 (Fault Generator)： 编排器与故障生成器接口，注入模拟服务中断的受控故障。AIOPSLAB 使用自定义故障库，并与 ChaosMesh (ChaosMesh Authors, 2022) 集成，能够注入跨系统堆栈不同级别的故障（如应用层、虚拟化层）。这些故障不仅限于表层症状，而是能够模拟更复杂的根本原因。

• 问题评估器 (Problem Evaluators)：

  • 评估机制： 编排器根据预定义的成功标准和任务特定评估指标来评估智能体的性能。
  • 默认指标： 支持 Time-to-Detect (TTD)、执行步骤数、LLM 智能体使用的令牌数。
  • 定性评估： 可选地支持使用 LLMs-as-Judges (Zheng et al., 2024) 对智能体轨迹进行定性评估。
  • 自定义指标： 允许用户定义问题特定的评估指标。
  • 日志记录： 维护智能体所有轨迹的全面日志，包括采取的行动和导致的系统状态，便于详细分析和调试。所有评估结果都会自动收集。

4.2.3. 云服务 (Cloud Services)

AIOPSLAB 部署真实的微服务应用程序作为其云环境。

• 已集成应用： HotelReservation 和 SocialNetwork，均来自 DeathStarBench (Gan et al., 2019)。
  • SocialNetwork：包含28个微服务，如 Memcached、MongoDB 和 Redis，实现了真实社交网络应用的多种功能。
  • HotelReservation：使用 Go 和 gRPC 实现，支持酒店推荐和预订服务。

4.2.4. 面向任务的故障库 (Task-oriented Fault Library)

AIOPSLAB 拥有一个精心设计的故障库，用于实例化各种运维问题。

下图（原文 Figure 3）展示了 AIOPSLAB 中实例化问题的故障类别：

图2：AIOPSLAB 中实例化问题的故障类别。

4.2.4.1. 任务分类 (Task Taxonomy)

如 Table 1 所示，故障库的故障类型被设计来支持在不同任务级别（从检测到缓解）构建问题。

4.2.4.2. 症状性故障 (Symptomatic Faults)

• 特点： 表现为可观察的系统症状，如性能下降 (performance degradation)、崩溃失败 (crash failures)、延迟增加 (increased latency)、资源耗尽 (resource exhaustion) 或服务中断 (service outages)。
• 用途： 主要用于构建 Level 1 (检测) 和 Level 2 (定位) 任务，因为这些故障提供了潜在问题概览，但不直接揭示深层根本原因。
• 注入工具： AIOPSLAB 集成了 ChaosMesh (ChaosMesh Authors, 2022) 来注入这些症状性故障。

4.2.4.3. 功能性故障 (Functional Faults)

• 特点： 模拟了更深层次的根本原因，例如配置错误 (misconfigurations)、软件缺陷 (software bugs) 或不正确的操作 (incorrect operations)。

• 重要性： 现有故障注入工具大多仅注入系统症状，而功能性故障能够挑战 AI 智能体不仅要检测和定位，还要诊断根本原因 (Level 3) 并应用正确的缓解策略 (Level 4)。它们更接近真实世界中需要复杂推理才能解决的事件。

• 示例： Figure 4 展示了一个撤销身份验证故障 (Revoke authentication fault)，它撤销了 MongoDB 数据库的管理员权限，导致依赖此数据库的 Geo 服务出现异常并生成错误日志。这种故障需要智能体理解服务间的依赖关系和权限问题。

  下图（原文 Figure 4）展示了撤销身份验证故障示例：

  图3：撤销身份验证故障示例。注入发生在 Mongodb-geo 服务，而 Geo 服务将异常并生成错误日志。

  示例 2.4：应用层故障注入器

原文提供了一个应用层故障注入器，用于注入撤销身份验证故障的示例：

1 from aiopslab.generators.fault.base import FaultInjector 2 from aiopslab.service.apps.hoteles import HotelReservation 3 class ApplicationFaultInjector(FaultInjector): 4 def inject_revoke_auth(self, microservices: list[str]): 5 """Revoke MongoDB admin privileges. " 6 ..

• 这个 ApplicationFaultInjector 类继承自 FaultInjector 基类。
• inject_revoke_auth 方法接受一个微服务列表，并撤销其 MongoDB 的管理员权限。
• 用户可以利用现有故障库定义问题，例如指定不同的故障服务，或同时向多个服务注入多个故障。
• 用户还可以自定义故障，AIOPSLAB 为每个故障场景提供注入和相应的缓解机制，以将系统从错误状态中恢复。

4.2.5. 可观测性 (Observability)

AIOPSLAB 集成了一个可扩展的可观测性层，提供全面的监控能力。其遥测收集器收集以下多种数据：

• 追踪 (Traces)： 来自 Jaeger (Jaeger Authors, 2024)，详细记录了分布式系统中请求的端到端路径。

• 日志 (Logs)： 通过 Kubectl 获取，或由 Filebeat (Elasticsearch, 2024b) 和 Logstash (Elasticsearch, 2024a) 格式化和记录。

• 系统指标 (System Metrics)： 由 Prometheus (Prometheus Authors, 2024) 监控。

  这些遥测数据不仅支持在 LLM 智能体交互过程中实时收集，还可以离线导出，以便评估传统的 AIOps 方法。此外，AIOPSLAB 还被设计用于捕获其他维度信息，如代码库 (codebase)、配置 (configuration) 和集群信息 (cluster information)。开发者还可以通过 AIOPSLAB 的接口向智能体暴露低级系统信息（如系统调用日志）。

5. 实验设置

5.1. 数据集

AIOpsLAB 框架本身充当了实验的基准环境，而非使用传统意义上的静态数据集。它通过动态部署微服务应用、注入故障和生成工作负载来创建真实的运维场景。

• 使用的微服务应用程序：

  • HotelReservation： 来自 DeathStarBench (Gan et al., 2019)。
  • SocialNetwork： 也来自 DeathStarBench (Gan et al., 2019)。该应用拥有28个微服务，包括 Memcached、MongoDB 和 Redis，共同实现真实社交网络应用的多种功能。

• 问题池 (Problem Pool)： AIOpsLAB 基准由48个问题组成，这些问题是通过在上述微服务应用中注入10种不同类型的故障来创建的。

• 故障类型与特点： Table 2 列出了用于实例化问题的选定故障。

  • 功能性故障 (Functional Faults) (1-7号故障)： 这些故障模拟了深层根本原因，如认证缺失、端口配置错误、权限撤销、用户未注册、应用镜像 bug、Pod 扩缩容错误、Pod 分配到不存在节点等。它们被用于创建所有四个任务级别（检测、定位、RCA、缓解）的问题。

    • 可扩展性 (Extensibility)： 多数功能性故障具有良好的可扩展性（标记为 ①），意味着可以轻松地将它们注入到其他目标服务中，以创建新问题。例如，故障2 (TargetPortMisconfig) 可以通过简单配置注入到10个不同的服务中。故障3 (RevokeAuth) 和故障4 (UserUnregistered) 需要额外的脚本和 Kubernetes 配置更新来构建问题。故障5 (BuggyAppImage) 是应用层代码 bug，特定于某些问题，难以泛化。

  • 症状性故障 (Symptomatic Faults) (8-9号故障)： 这些故障表现为可观察的系统症状，如网络丢失 (NetworkLoss) 和 Pod 故障 (PodFailure)。它们仅用于创建 Level 1 (检测) 和 Level 2 (定位) 任务的问题，因为它们不涉及深层根本原因。

  • 无操作 (Noop) (10号故障)： 不注入任何故障，用于测试智能体在正常运行情况下的表现，特别是识别误报。

    以下是原文 Table 2 的内容：

    No.
    		Application	Task Level	Category	Ext.	#Problem	Description
    1	AuthenticationMissing	HotelReservation	1,2,3,4	Functional Virtualization	①	4	Missing authentication credentials cause access denial to MongoDB.
    2	TargetPortMiscountina	SocialNetwork	1,2,3,4	Functional Virtualization	●	12	The service cannot connect to the specified port due to misconfiguration.
    3	RevokeAuth	HotelReservation	1,2,3,4	Functional Application	①	8	Revoked authentication causes database connection failure.
    4	UserUnregistered	HotelReservation	1,2,3,4	Functional Application	①	8	The database service has access failures after the user was unregistered.
    5	BuggyAppImage	HotelReservation	1,2,3,4	Functional Application	○	4	Connection code bug in the application image causes access issues.
    6	ScalePod	SocialNetwork	1,2,3,4	Functional Virtualization	●	4	Incorrect scaling operation makes the number of pod zero for a service.
    7	AssignNonExistentNode	SocialNetwork	1,2,3,4	Functional Virtualization	●	4	Pod in a pending a failure status due to wrong assignment to a non-existent node.
    8	NetworkLoss	HotelReservation	1,2	Symptomatic	●	2	Network loss causes communication failures for a specific service.
    9	PodFailure	HotelReservation	1,2	Symptomatic	●	2	Service interruption due to a pod failure.
    10	Noop	HotelReservation	1	-	●	2	No faults injected into the system.

• 注： Ext. 栏中的 ① 表示故障易于用于构建其他问题；● 表示需要一些手动工作来创建新问题；○ 表示故障特定于某些问题，不能用于创建其他问题。

5.2. 评估指标

论文使用了以下指标来评估 AIOps 智能体的性能：

5.2.1. Correctness (正确性)

• 概念定义： 此指标衡量智能体对问题的响应准确性。它评估智能体是否成功地检测、定位、分析和解决了问题，符合预期结果。
• 数学公式： 未直接给出通用公式。通常表示为针对每个问题的二元结果（成功为1，失败为0）或所有问题的平均准确率。对于定位任务，会考虑 Acc.@1 和 Acc.@3（即提交的前1个或前3个答案中是否包含正确答案）。
• 符号解释： N/A。

5.2.2. Time/Steps (时间/步数)

这些指标评估 AIOps 智能体在解决任务时的效率。

5.2.2.1. Time-to-Detect (TTD - 故障检测时间)

• 概念定义： 衡量从故障发生到智能体检测到该故障所需的时间。它反映了智能体对异常事件的响应速度。
• 数学公式： $$TTD = T_{\text{detection}} - T_{\text{fault\_occurrence}}$$
• 符号解释：
  • TTD：故障检测时间。
  • $T_{\text{detection}}$：智能体检测到故障的时间点。
  • $T_{\text{fault\_occurrence}}$：故障实际发生的时间点。

5.2.2.2. Time-to-Mitigate (TTM - 故障缓解时间)

• 概念定义： 衡量从故障检测到故障被完全缓解（系统恢复正常运行）所需的时间。它反映了智能体解决问题的效率。
• 数学公式： $$TTM = T_{\text{mitigation\_complete}} - T_{\text{detection}}$$
• 符号解释：
  • TTM：故障缓解时间。
  • $T_{\text{mitigation\_complete}}$：故障缓解完成的时间点。
  • $T_{\text{detection}}$：智能体检测到故障的时间点。

5.2.2.3. Number of Steps (# Steps - 步数)

• 概念定义： 记录智能体在解决问题过程中与 AIOPSLAB 交互的次数。这不包括智能体后端 LLM 的请求次数，而是智能体执行的独立动作数量。
• 数学公式： 未直接给出，是累积的整数计数。
• 符号解释： N/A。

5.2.3. Cost (成本)

• 概念定义： 使用智能体（特别是 LLM 驱动的智能体）在解决问题过程中生成的令牌总数作为成本指标。这反映了 LLM API 调用的潜在成本。
• 数学公式： $$\text{Tokens} = \text{Tokens}_{\text{input}} + \text{Tokens}_{\text{output}}$$
• 符号解释：
  • $\text{Tokens}$：总令牌数。
  • $\text{Tokens}_{\text{input}}$：作为输入发送给 LLM 的令牌数量。
  • $\text{Tokens}_{\text{output}}$：LLM 生成的输出令牌数量。

5.3. 对比基线

论文将自己的框架用于评估以下类型的智能体和算法：

5.3.1. 基于 LLM 的智能体 (LLM-based Agents)

• GPT-3.5-w-SHELL： 使用 GPT-3.5-turbo 模型作为基础，并提供安全 shell 访问能力的基线智能体。
• GPT-4-w-SHELL： 使用 GPT-4-turbo 模型作为基础，并提供安全 shell 访问能力的基线智能体。
• REACT (Yao et al., 2023)： 这是一个著名的 LLM 智能体框架，它通过整合推理 (Reasoning) 和行动 (Acting) 来扩展思维链 (Chain-of-Thought) 推理。REACT 智能体能够交错地进行思考和执行外部工具操作。
• FLASH (Zhang et al., 2024b)： 论文中提及的一种工作流自动化智能体，其设计理念是监控执行状态，将复杂指令分解为可管理、有条件的片段，并结合事后回溯生成 (hindsight generation) 从过去的交互中学习。由于论文撰写时 FLASH 尚未公开，作者开发了一个简化版本，该版本在每一步之后回顾性地生成洞察。

5.3.2. 非 LLM 的 AIOps 算法 (Non-LLM-based AIOps Algorithms)

为了与特定任务类型的其他 AIOps 方法进行比较，论文还评估了三种最先进的非 LLM AIOps 算法，它们以多模态 (multimodal) 遥测数据作为输入：

• MKsMC (Çetin and Tasgin, 2020)： 用于检测 (Detection) 任务的算法，基于蒙特卡洛的多变量 K-Sigma 分数异常检测。
• RMLAD (Wang et al., 2020) 和 PDiagnose (Hou et al., 2021)： 用于定位 (Localization) 任务的算法。

6. 实验结果与分析

6.1. 核心结果分析

6.1.1. 总体性能概览

以下是原文 Table 3 的内容：

• FLASH 表现最佳： FLASH 智能体在所有智能体中实现了最高的总体准确率 (59.32%)。
• 速度与准确率的权衡： GPT-3.5-w-SHELL 完成任务最快 (12.44秒)，但其准确率最低 (15.25%)。
• GPT-4-w-SHELL 表现中等： GPT-4-w-SHELL 的准确率为 49.15%，好于 GPT-3.5-w-SHELL，但低于 REACT 和 FLASH。它使用的令牌数也相对较少。
• REACT 性能可观： REACT 的准确率为 55.93%，仅次于 FLASH。然而，它使用的令牌数最多 (16,941.46)，并且运行时间也较长。
• LoC (Lines of Code) 低： 所有智能体的注册代码行数都很少（41-60行），表明 AIOPSLAB 框架具有良好的易用性和可扩展性。

6.1.2. 各任务类型性能

以下是原文 Table 4 的内容（检测任务）：

以下是原文 Table 4 的内容（定位任务）：

以下是原文 Table 4 的内容（RCA 任务）：

• 注： RCA 和 Mitigation 任务的表格数据在原文中似乎有排版问题，但我们可以从其结构和描述中提取信息。

  以下是原文 Table 4 的内容（缓解任务）：

  Agent	Accuracy	Time (s)	# Steps	Input	Output
  GPT-4-w-SHELL	27.27%	99.47	13.72	10,142.55	1,060.00
  GPT-3.5-w-SHELL	0%	23.78	20.00	3,178.33	967.71
  REACT	36.36%	67.18	15.54	29,211.90	1,464.90
  FLASH	54.55%	216.41	16.09	8,469.00	760.36

• 检测任务 (Detection Task) (Table 4(a))：

  • FLASH 表现出色，达到了100%的准确率。
  • REACT 紧随其后，准确率为76.92%。
  • GPT-4-w-SHELL 表现尚可 (69.23%)，而 GPT-3.5-w-SHELL 仅有23.07%。
  • 非 LLM 方法表现不佳： MKsMC 仅有15.38%的准确率，远低于 LLM 智能体。

• 定位任务 (Localization Task) (Table 4(b))：

  • 当考虑前3个答案 (Acc.@3) 时，REACT 表现最佳 (69.23%)。
  • 当只考虑前1个答案 (Acc.@1) 时，GPT-4-w-SHELL 表现最佳 (61.54%)。
  • FLASH 在 Acc.@1 和 Acc.@3 上的准确率分别为 46.15% 和 61.54%。
  • 非 LLM 方法表现极差： PDiagnose 只有15.38% ($Acc.@1/3$)，RMLAD 更是只有7.69% ($Acc.@1/3$)，再次证明 LLM 智能体优于传统方法。

• 根因分析 (RCA Task) (Table 4(c)) 和缓解任务 (Mitigation Task) (Table 4(d))：

  • 这两个任务对所有智能体来说都最具挑战性。
  • REACT 在 RCA 任务中略优于 GPT-4-w-SHELL 和 FLASH。
  • 在缓解任务中，FLASH 再次脱颖而出，达到了 54.55% 的准确率，而 GPT-3.5-w-SHELL 在此任务上完全失败 (0%)。
  • 这些复杂任务的准确率显著低于检测和定位任务，表明智能体在深层诊断和执行复杂修复操作方面仍有较大改进空间。

6.1.3. 步数限制的影响

下图（原文 Figure 5）展示了智能体性能与步数的关系：

图4：智能体性能与步数的关系。

• 显著影响： 步数限制对某些智能体的性能有显著影响。
• REACT 和 FLASH： 这两个智能体随着允许步数的增加，准确率有明显的提高。FLASH 在步数限制为20时达到了最高的59.32%的准确率。
• GPT-3.5-TURBO： 对于 GPT-3.5-TURBO，将步数限制提高到5步以上并不能带来更好的性能，反而只会增加令牌消耗。
• 性能饱和： 准确率在达到一定步数后趋于平稳，这表明通过环境反馈进行的自我修复在 AIOps 问题中可能很快达到饱和点。这暗示需要：
  1. 更好的任务分解 (task decomposition) 和规划 (planning) 能力。
  2. 更有效的中间步骤反馈机制。
  3. 超越简单环境反馈和自我修复的解决方案。

6.1.4. API 使用模式

下图（原文 Figure 6）展示了不同智能体采取动作的总百分比：

图5：不同智能体采取动作的总百分比。

• get_logs 是所有智能体中最常用的 API，其次是 get_metrics 和 get_traces。
• 智能体在 API 使用模式上存在差异。例如，FLASH 完全不使用 get_traces API。
• Table 5 进一步展示了系统命令的使用情况，但在原文中 Table 5 的内容排版错误，无法准确提取。
  • 问题： get_metrics 和 get_traces API 在成功解决问题的情况下反而使用较少。这表明这些数据本身复杂，难以直接解释。
  • 挑战： 智能体可能直接使用 cat 命令读取这些遥测数据，这可能导致模型的输入上下文窗口过载，消耗大量令牌，并可能引入噪声，干扰智能体的推理。

6.1.5. 智能体行为：优势、挑战与不足 (The Good, the Bad and the Gaps)

6.1.5.1. 浪费不必要的步骤

• 问题： 智能体经常在不必要的行动上浪费步骤，例如重复调用相同的 API、生成不存在的 API，或者在多智能体通信中花费过多时间。
• GPT-3.5-w-SHELL 的例子： 该智能体经常在循环中生成错误的 API 命令，导致重复的执行错误。它甚至会循环回复“I apologize for the error. Here is the API call again:”，然后再次犯同样的错误，这在一个20步的问题解决案例中多达14次。
• 多智能体通信： 将 speaker_selection_method 设置为 round_robin（轮询）可能导致所有智能体在每一步都发言，但缺乏果断高效的决策。即使是 auto 模式，选定的智能体也可能在没有必要通信的情况下连续发言十次。

6.1.5.2. 过度使用遥测数据

• 观察： 在成功解决的问题中，智能体倾向于更谨慎地使用 get_metrics 和 get_traces API，通常只在必要时才使用。
• 原因： 指标数据（如 CPU 和内存使用率）包含大量难以直接解释的值。追踪数据虽然描述了系统依赖，但通常需要可视化才能更好地理解。
• 挑战： 智能体直接使用 cat 命令处理这些原始数据，可能会使模型的输入上下文窗口过载，消耗大量令牌，并可能引入过多噪声，干扰推理过程。

6.1.5.3. 无效 API 使用

• 问题： 智能体在 API 调用的格式上经常挣扎。
• GPT-3.5-w-SHELL 的例子： 经常生成不正确的命令格式（即使 API 名称正确），如参数格式错误，并在后续步骤中重复此错误。
• REACT 的例子： REACT 偶尔也会生成不正确的 API 命令，但通常能够通过推理错误并自我纠正来恢复。例如，它会尝试一个带有错误参数的 get_logs 调用，然后通过检查现有服务的 shell 命令来纠正自己。

6.1.5.4. 误报检测问题

• 实验： 论文设置了两个“无操作 (Noop)”问题（无故障注入），以评估智能体在正常情况下的表现。
• 结果： 只有 GPT-4-w-SHELL 能够正确识别这些情况为正常系统执行。其他智能体均报告误报，将正常活动（如标准工作负载生成）错误地解释为故障。

6.2. 数据呈现 (表格)

由于 Table 4 中的 RCA 和 Mitigation 任务数据在原文中呈现不完整或有排版问题，我将根据可提取的信息进行呈现。

6.2.1. Table 2: 用于 AIOpsLAB 评估的问题实例化故障列表

以下是原文 Table 2 的内容：

6.2.2. Table 3: 不同智能体的总体性能

以下是原文 Table 3 的内容：

6.2.3. Table 4: 不同智能体在各任务上的性能

6.2.3.1. 检测任务性能 (Detection Task)

以下是原文 Table 4(a) 的结果：

6.2.3.2. 定位任务性能 (Localization Task)

以下是原文 Table 4(b) 的结果：

6.2.3.3. 根因分析任务性能 (RCA Task)

以下是原文 Table 4(c) 的结果：

6.2.3.4. 缓解任务性能 (Mitigation Task)

以下是原文 Table 4(d) 的结果：

6.3. 消融实验/参数分析

6.3.1. 步数限制对智能体性能的影响

论文分析了最大允许步数 (max_steps) 对智能体性能的影响，并在 Figure 5 中展示了结果。

• REACT 和 FLASH 的准确率随着步数的增加而提高，尤其 FLASH 在步数限制为20时达到了最高准确率。
• GPT-3.5-TURBO 在步数超过5之后，性能没有明显提升，但令牌消耗却增加了。
• 这一现象表明，对于 AIOps 问题，智能体通过环境反馈进行的自我修复可能很快达到饱和点。这提示需要更高级的规划、更好的中间反馈机制以及超越简单试错的解决方案。

6.3.2. API 使用模式分析

论文通过 Figure 6 展示了不同智能体采取动作的总百分比，并提到 Table 5 呈现了系统命令的使用情况（尽管 Table 5 的内容在原文中排版错误，无法准确提取）。

• get_logs 使用最频繁： 这是所有智能体中最常用的 API，其次是 get_metrics 和 get_traces。
• API 使用模式差异： 智能体在 API 使用模式上存在差异，例如 FLASH 完全不使用 get_traces API。
• 过度使用遥测数据的问题： 在成功解决问题的案例中，get_metrics 和 get_traces API 的使用反而较少。这表明，如果智能体不加分析地直接将这些原始遥测数据（例如通过 cat 命令）输入到 LLM 中，可能会导致上下文窗口过载，消耗大量令牌，并可能引入噪声，反而干扰智能体的推理。这突显了未来智能体需要更精细的遥测数据处理和过滤机制。

6.4. 误报检测问题

• 为了评估智能体的鲁棒性，AIOPSLAB 包含了“无操作 (Noop)”问题，即没有注入任何故障。
• 只有 GPT-4-w-SHELL 能够正确识别这些情况为正常的系统运行。
• 其他智能体都产生了误报，错误地将正常活动（如标准工作负载生成）解释为故障。这揭示了智能体在区分正常波动和真实故障方面的局限性。

7. 总结与思考

7.1. 结论总结

本文提出了 AIOPSLAB，一个开创性的整体框架，旨在支持自主 AIOps 智能体的设计、开发和评估。该框架整合了故障注入器、工作负载生成器、云-智能体编排器和遥测观察器，能够模拟复杂的云事件，并提供一个直观的智能体-云接口 (ACI) 来促进智能体的交互和评估。

通过利用 AIOPSLAB，作者构建了一个包含48个问题的基准套件，涵盖了从故障检测到缓解的各种 AIOps 任务，并对四种最先进的 LLM 驱动智能体进行了系统评估。实验结果揭示了这些智能体在处理复杂云运维任务时的能力和显著局限性。尽管 LLM 智能体在检测和定位任务上优于传统方法，但在根因分析和缓解等更复杂的任务中，它们的准确率仍有待提高。研究还指出，智能体在步数利用效率、遥测数据处理和 API 调用准确性方面存在挑战，且普遍存在误报问题。

总体而言，AIOPSLAB 为 AgentOps 领域提供了一个急需的、互动式的、真实世界场景的评估工具，为未来 AI 智能体在自主云运维中的发展奠定了基础。

7.2. 局限性与未来工作

7.2.1. 论文作者指出的局限性

• 基准创建的复杂度： 尽管 AIOPSLAB 提供了便利，但工程师仍需要投入精力来创建定制化的事件场景，以准确代表其系统中的事件。
• 评估粒度： 在某些情况下（例如，智能体答案正确但推理过程错误），需要更细粒度的评估预言 (evaluation oracles) 或结合 LLM-as-Judge 来进行全面评估。
• 智能体性能局限： 当前 LLM 智能体在复杂任务（特别是缓解任务）上的表现仍未达到高准确率。
• 性能饱和： 智能体通过环境反馈进行的自我修复在一定步数后可能迅速饱和，表明现有方法可能无法有效利用更多迭代。
• 资源浪费： 智能体存在浪费步骤（重复调用 API、生成不存在的 API），无效 API 使用，以及过度使用原始遥测数据（导致上下文过载、令牌耗尽）的问题。
• 误报问题： 除了 GPT-4-w-SHELL 外，其他智能体在无故障情况下易产生误报。

7.2.2. 论文作者提出的未来可能的研究方向

• 扩展故障类型和任务场景： AIOPSLAB 可以适应更多故障类型，例如引入异常检测工作负载场景。用户也可以创建要求智能体标记工作负载或遥测数据以识别异常的复杂任务。
• 改进遥测数据处理： 需要更精细的遥测数据处理和过滤机制，以避免智能体因原始数据过多而导致上下文过载和推理混乱。
• 增强智能体规划与反馈机制： 针对性能饱和问题，未来工作需要探索更好的任务分解、改进的中间步骤反馈机制，以及超越简单环境反馈和自我修复的解决方案。
• 持续改进智能体本身： 解决智能体在浪费步骤、无效 API 使用和误报等方面的固有问题。
• 公开 AIOPSLAB： 作者承诺将 AIOPSLAB 公开可用，这将促进社区在此框架上的进一步研究和贡献。

7.3. 个人启发与批判

7.3.1. 个人启发

• AgentOps 范式的提出极具远见： 将 AI 智能体应用于整个运维事件生命周期的端到端管理，这符合行业对自动化和自愈系统的终极追求。AIOpsLAB 为这一新范式提供了一个坚实的评估基础，对于推动相关研究具有里程碑意义。
• 交互式基准的重要性： 相较于静态数据集，提供一个允许智能体与真实（或高度模拟）环境交互的基准至关重要。这使得智能体能够学习“思考-行动-观察”的循环，更真实地反映其在实际运维中的能力。
• 功能性故障的引入： 区分症状性故障和功能性故障，并重点关注后者，是提升基准真实度和挑战性的关键。这促使智能体不仅要识别问题，还要深入诊断根本原因并执行复杂修复，这正是高级 AIOps 所需的能力。
• 模块化和可扩展性： AIOPSLAB 的模块化设计（问题定义、编排器、故障库、可观测性）使其具有高度的灵活性和可扩展性，便于研究人员添加新的应用、故障类型、评估指标和智能体，极大地促进了社区贡献。
• 工具使用和环境反馈的挑战： 实验结果清晰地揭示了 LLM 智能体在有效利用外部工具、处理环境反馈方面的挑战。这对于 AI 智能体领域的研究具有普遍意义，不仅限于 AIOps。

7.3.2. 批判与潜在改进

• 成本与效率的进一步权衡： 论文中 LLM 智能体的运行时间普遍较长，FLASH 甚至达到了216秒（缓解任务）。在实际生产环境中，许多运维事件需要毫秒或秒级的响应。未来的研究需要更深入地权衡 LLM 智能体的准确率、速度和令牌成本，并探索如何加速其决策过程。
• 遥测数据处理的智能性不足： 智能体直接 cat 大量原始遥测数据而非进行智能过滤和摘要，这是效率低下的表现。未来的智能体应该内置更高级的遥测数据处理模块（如模式识别、异常检测、事件关联），将处理后的结构化、摘要信息提供给 LLM，从而减少上下文压力并提高决策效率。
• 对人类知识的利用： AIOps 领域积累了大量的运维知识、最佳实践和专家经验。当前的 LLM 智能体更多依赖其通用知识和工具使用能力。如何有效地将这些领域特定的、非结构化或半结构化的人类知识融入 LLM 智能体（例如，通过知识图谱、检索增强生成 RAG 或领域特定微调），以提升其在复杂、罕见故障情境下的表现，是一个重要的研究方向。
• 可解释性和信任度： LLM 智能体的“黑箱”特性使得其决策过程难以解释，这在关键的运维场景中可能导致信任问题。虽然提到了 LLM-as-Judge 进行定性评估，但如何让智能体自身生成更可靠、更具说服力的解释，从而提高运维人员对其决策的信任度，是一个持续的挑战。
• 故障库的广度和深度： 尽管 AIOPSLAB 的故障库很出色，但真实的云系统故障模式极其复杂多样，且不断演变。持续扩展故障库，纳入更多罕见、多因、时序相关的复杂故障模式，并开发自动化生成更丰富故障场景的方法，将是 AIOPSLAB 持续发展的关键。
• 泛化到不同云环境： AIOPSLAB 目前在 DeathStarBench 的微服务应用上进行了评估。这些结果是否能很好地泛化到其他更复杂、异构的生产云环境（例如，不同的 Kubernetes 发行版、不同的云提供商、不同的应用栈），需要进一步的验证和适应性研究。