近期，大模型的迅猛發展為 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 的方法，將數據檢索并生成回答。在可觀測數據檢索，配置/資源信息查詢等場景中有比較重要的作用，也有助于復雜任務的數據信息/知識的補充。