当运维遇上LLM：大模型 Agent 在 AIOps 运维场景有哪些新实践

近期，大模型的迅猛发展为 AI 行业带来了巨大的进步，也有力地推动了 AIOps 的变革。大模型主要通过对话的方式实现智能赋能，Agent 借助多步对话，利用规划、反思以及工具的使用，以目标为驱动，形成能够自治完成复杂任务的智能体。

Agent 对大模型的加持，极大地提升了大模型的智能能力，并且能对 AIOps 任务类场景起到很好的智能增强作用，有助于提升运维的人效和加强自动化程度。

大模型 Agent 在 AIOps 运维场景中，可以解决日常任务，将 SRE 从重复的劳动中解脱出来，提高人效，如日常的巡检，重复故障发现和处置，知识/数据查询分析等；Agent 不再依靠 SRE 针对低级指令和流程的编辑/计划，可完全自驱的进行分析，规划，最终解决问题；而针对一些创新性和探索性的工作，Agent 也可以通过知识探索，流程规划，工具使用等方式实现。

人工交互，主要是针对单/多 Agent 中模型的推理能力和知识信息不足的问题，通过人工介入进行补充。

在 AIOps 运维中，大模型 Agent 对传统场景带来了全新的增强与提升：

• 异常检测：借助大模型的 Transformer 架构，能够将不同模态的数据进行统一向量化，然后通过预训练的方式构建异常检测大模型，比如可将指标数据、拓扑数据、事件数据混合起来，利用大模型进行异常检测。除了预训练方式，还可通过 Agent，采用不同的 prompt 及规划流程进行分析，形成多维度多模态的综合检测。
• 故障诊断：大模型 Agent 能够在规划与反思的作用下，设计并推动排查流程，同时利用数据检索、异常检查、根因分析等工具的使用，自主对生产环境中的故障进行分析与诊断。
• 故障修复：在故障诊断分析后，大模型 Agent 能够驱动编程执行以及现有工具的使用，实现故障的缓解与止损，以及真实故障的修复，甚至能在一定程度上实现故障自愈。
• 告警收敛：大模型 Agent 可依据对知识和记忆的了解，对告警进行解析，借助解析信息通过规则和语义等方式对告警进行合并总结。

• ChatOps：大模型 Agent 对 ChatOps 的支持较为直接，最直接体现在意图识别和工具使用上，可直接借助大模型和 Agent 的能力来实现并增强，对于知识问答，还可以充分利用 RAG 的方式，实现知识库的引用及回答的生成。
  

Agent 的建设有比较常见架构，包括了重要的组成部分：行动，计划，记忆，工具，同时依赖大模型LLM的能力，角色和环境。各个组成部分根据功能分工，利用sop进行合理编排，形成不同领域或者特性的智能体，在线上环境中通过Agent的制定或者意图的识别，实现调用和执行。如下简单介绍一下各个组件常用的构建方法和落地时间。

大模型是整个Agent的大脑，Agent的运行都需要大脑的反思能力和规划能力来自驱Agent的思考和运行，针对目前商用和开源的大模型的能力上看，在不同的场景和专业领域各有差异，在使用中可根据不同场景进行比对分析选择合适的模型和参数，并需要建立统一的适配器接口，达到方便进行模型调试比对的能力。同时，依赖LLMOps的功能实现模型的训练/微调，实现模型能力的调整和优化。

计划规划，Agent一般对需要多次大模型的交互和工具调用来达到任务目标，整个过程需要通过大模型能力等方式来进行规划计划，其中最常用的方法是反思，通过大模型的批判和思考能力，对于问题，中间回答等进行反思来确定下一步工作，常见的方法如 ReAct，Self-Ask，ReWoo 等。

这里的实践落地中，需要考虑运维的 SOP（Standard Operating Procedures）如何引入规划中，针对重复的有规范的任务，可通过专家经验生成流程驱动规划，针对无法匹配的任务，尝试推理生成规划，并能通过自学习来完善和丰富经验流程。

另外，如在根因定位和故障排查等场景中，可通过启发式算法，搜索问题空间，如 ToT（Tree of Thought），GoT（Graph of Thought） 等。

记忆管理，Agent 的记忆，最常见的是分长记忆和短记忆，长记忆最常用的方法是通过 RAG 的方式从外挂的知识库来获取知识，整个 RAG的过程可以使用固定的流程，更好的方式也使用Agent的规划和反思的能力，选择和调整检索的策略，来提升检索知识的有效性。

短记忆，一般是通过 prompt 的方式，将会话的历史，指令，例子，要求等信息放入，让大模型进行回答，有很多相关的策略和方法，重要的是要控制token数，从生成大模型的主要机制上，整体的 token 数量一般是有限制的，根据注意力机制，prompt 中过多的语义也是会被遗忘的，可通过 chatGPT 等对 prompt 进行生成和压缩，将重要信息放到 prompt 的开头和结尾，通过引号等方式加重关键信息。

工具执行，工具执行是大模型拓展到 Agent 的关键基础能力，很多大模型都通过针对性的预训练和微调将 function calling 的能力加入到模型本身中，通过模型的调用来实现工具调用的决策，当然通过 ReAct 的方式，调用通用大模型也是可行的。在运维领域，相关工具和能力不会在通用的训练数据中，因为领域知识的缺乏导致很多工具决策不够精准，可通过模型的微调，或者训练中小模型来达到精准的工具调用。

环境交互，在 AIOps 的运维场景中，环境主要是通过工具来定义，通过工具的使用来实现 Agent 的对环境的感知，控制以及互动。在建设实践中，原有 AIOps 和运维平台中的相关平台和工具都是可以打包成工具，作为感知和操作的工具，如异常检测的模型，根因分析的工具，运维可观测的数据，日志，告警的信息等，Agent 智能体需要通过这些工具。

• 范围定界：首先通过问题来提取故障的实体和时间，已经故障的类型，通过反思发现故障信息缺失，通过人工介入的方式要求用户进行故障信息补全。然后根据故障信息进行排查计划，这里使用 ReWoo 的方式，先制定一个固定的流程和步骤，在生成该流程的时候，可使用历史相似故障的计划，或根据历史相似故障的计划进行重新生成。由于一般故障都有深层次的原因，如果使用 ReAct 的方式进行排查，容易在表象问题上终止信息收集和异常判别，而使用完整计划生成的方式有助于排查过程无遗漏，尽最大可能的发现故障根因
• 故障排查：故障排查阶段会通过排查计划进行信息收集和异常检测，并逐步分析检测结果多步迭代的分析检测，在信息收集和检测中，结合检索可观测的数据并调用规则/异常检测算法等进行巡检和告警/事件等事件数据进行异常判别，部分场景会调用已有的诊断工具（如专家系统，智能根因分析等）进行一定范围的根因判别，最终将排查结果进行总结压缩，提交到步骤结论中。故障的排查阶段需要充分利用现有工具和数据，最大范围的感知和分析系统情况，为下一步的根因判断提供充足的信息。整个过程中为了提升效率，需要使用并行的方法，通过 ReAct，ToT，GoT 等方式，加快排查速度，减少排查点，提升排查效率。

• 故障总结：根据排查计划和排查结果，进行故障的总结，总结包括故障现象，故障分析过程，故障根因，推荐止损措施，推荐修复措施。相关的总结信息，需要通过 RAG（Retrieval-Augmented Generation） 的方式，检索内部故障库，知识库，以及利用搜索引擎进行知识搜集后，通过大模型进行总结回答，回答后的结果，进行格式整理存入故障库中，在人工审核后形成新的故障知识，为之后的故障排查使用。

总体上来说，故障排查通过固定流程（范围界定->故障排查->故障总结）的生成降低了可能的排查遗漏，复用了历史故障排查，提升了排查效率；通过并发的逐步反思排查的步骤执行，尽可能的分析相关事件，指标，日志等的异常，代替SRE进行故障下钻分析；通过故障总结，自动化利用历史知识和外部知识，进行故障的根因分析和修复推荐，辅助SRE进行相关故障分析，帮助场景实现自学习。

在 Oncall 运维场景中，期望通过智能问答实现一线拦截，提升一线人效的同时，减少二线的介入量，提升 SRE 的人效。知识问答目前主要的实现方法就是通过 RAG 的技术，实现外挂知识库的检索，通过大模型进行回答，其中有些比较有效的实践如下：

• 多路检索：单一的知识库很难满足运维场景的需要。可通过大模型的规划能力，在检索前，针对检索进行规划，选择相关的知识库或检索器进行检索，检索文本，可根据检索器需要进行重写或改写。
• 使用可微调 Embedding 的模型：在运维知识域相关的专有名字比较多，最要使用可微调的 embedding 模型进行微调后适应私域的语料。
• 使用反思优化检索结果：利用大模型的反思能力，对检索的结果进行批判/反思，根据反思的结果进行进一步的检索规划，或针对结果进行重排/过滤/压缩后发给大模型进行回答
• 解析多模态的知识：在运维领域中，有大量的图片和表格，针对图片和表格设计相关的解析，向量化和生成上下文的策略，可尝试使用多模态的模型。
• 数据的检索：针对意图进行分离出数据检索的问题，利用 nl2sql 的方法，将数据检索并生成回答。在可观测数据检索，配置/资源信息查询等场景中有比较重要的作用，也有助于复杂任务的数据信息/知识的补充。