AI 驅(qū)動(dòng)的智能異常處置：從異常發(fā)現(xiàn)到根因定位

演講嘉賓｜張穎瑩

編輯｜Kitty

策劃｜QCon 全球軟件開發(fā)大會(huì)

異常處置包含異常發(fā)現(xiàn)、問題定界和根因定位等環(huán)節(jié)，高效的異常處置流程對(duì)于保障平臺(tái)的穩(wěn)定性起到至關(guān)重要的作用，然而平臺(tái)本身的復(fù)雜度以及海量的多元異構(gòu)數(shù)據(jù)給異常處置帶來了巨大的挑戰(zhàn)。如今，大模型等 AI 技術(shù)的演進(jìn)則為應(yīng)對(duì)這些挑戰(zhàn)提供了新的思路。在 2025 年 InfoQ 舉辦的 QCon 全球軟件開發(fā)大會(huì)（ 北京站）上，來自阿里云的算法專家張穎瑩發(fā)表了題為《AI 驅(qū)動(dòng)的智能異常處置：從異常發(fā)現(xiàn)到根因定位》的演講。她從阿里云計(jì)算平臺(tái)的運(yùn)維場(chǎng)景出發(fā)，分享了從異常發(fā)現(xiàn)到問題定界和根因定位各環(huán)節(jié)的算法選型和設(shè)計(jì)思路，包括通用的時(shí)間序列異常檢測(cè)、高效的日志聚類和精準(zhǔn)的多 Agent 根因定位框架。

預(yù)告：將于 2026 年 4 月 16 - 18 召開的 QCon 北京站策劃了「Agent Ops：運(yùn)維新生產(chǎn)力」專題，將深入討論 Agent 如何與現(xiàn)有技術(shù)棧深度集成，并演進(jìn)為具備長期記憶與自我進(jìn)化能力的運(yùn)維實(shí)踐。如果你也有相關(guān)方向案例想要分享，歡迎提交至 https://jinshuju.com/f/Cu32l5。

以下是演講實(shí)錄（經(jīng) InfoQ 進(jìn)行不改變?cè)獾木庉嬚恚?/blockquote>

阿里云大數(shù)據(jù)運(yùn)維背景

我們阿里云計(jì)算平臺(tái)整合了整個(gè)阿里的大數(shù)據(jù)和 AI 的能力，并以產(chǎn)品化、平臺(tái)化的方式支撐了我們集團(tuán)內(nèi)部與云上各行各業(yè)客戶的眾多非常核心的業(yè)務(wù)場(chǎng)景。這里列舉其中幾個(gè)比較典型的平臺(tái)。

• 比如 MaxCompute 大數(shù)據(jù)計(jì)算服務(wù)主要負(fù)責(zé)大規(guī)模數(shù)據(jù)的離線計(jì)算。大家日常在網(wǎng)購后經(jīng)常會(huì)在手機(jī)上去追蹤自己的包裹，這些菜鳥的物流數(shù)據(jù)產(chǎn)出就依賴 MaxCompute。

• 還有實(shí)時(shí)性要求相對(duì)較高的場(chǎng)景，比如自動(dòng)駕駛場(chǎng)景，車機(jī)系統(tǒng)會(huì)對(duì)司機(jī)的危險(xiǎn)駕駛行為發(fā)出實(shí)時(shí)警告。像這一類比較追求時(shí)效性的場(chǎng)景，往往就依賴 Flink 這樣的實(shí)時(shí)計(jì)算引擎。下一個(gè)是 Hologres 實(shí)時(shí)數(shù)倉，大家在手機(jī)淘寶上檢索商品關(guān)鍵詞時(shí)，它會(huì)在底層進(jìn)行實(shí)時(shí)的交互式分析，為大家呈現(xiàn)實(shí)時(shí)的檢索推薦結(jié)果。

• 另外隨著大模型越來越火爆，大家對(duì)機(jī)器學(xué)習(xí)模型相關(guān)的訓(xùn)練、微調(diào)、在線服務(wù)的需求都有了爆發(fā)式的增長。這一類的模型訓(xùn)練、微調(diào)、在線服務(wù)都可以一站式在我們的機(jī)器學(xué)習(xí)平臺(tái) PAI 上完成。

可以看出我們的這幾個(gè)平臺(tái)上層支撐的業(yè)務(wù)都非常重要，所以做好這些平臺(tái)的運(yùn)維也非常關(guān)鍵。但傳統(tǒng)的運(yùn)維模式很容易讓運(yùn)維人員變成背鍋俠的角色。所以我們計(jì)算平臺(tái)也專門設(shè)置了一支運(yùn)維中臺(tái)研發(fā)團(tuán)隊(duì)來負(fù)責(zé)所有大數(shù)據(jù)和 AI 產(chǎn)品的統(tǒng)一運(yùn)維管控。我們也一直利用“AI+ 數(shù)據(jù) + 工程”的手段來提升整體運(yùn)維效率。

穩(wěn)定性作為運(yùn)維的基石，其重要性是毋庸置疑的。但對(duì)于系統(tǒng)來說，異常的發(fā)生很難避免，怎樣在異常發(fā)生時(shí)能進(jìn)行快速高效的處置，對(duì)于整個(gè)平臺(tái)的穩(wěn)定性是非常重要的。另一方面，隨著我們的用戶對(duì)云服務(wù)廠商服務(wù)水平的要求越來越高，精細(xì)化運(yùn)維已成為行業(yè)趨勢(shì)。另外像我們前面提到的這些大數(shù)據(jù)平臺(tái)，它們的底層都是超大規(guī)模的計(jì)算集群，這些集群無時(shí)不刻都在產(chǎn)生海量的數(shù)據(jù)，這些海量數(shù)據(jù)對(duì)我們的異常處置也帶來了更多的戰(zhàn)。

我把整個(gè)異常處置層面我們面臨的挑戰(zhàn)總結(jié)成三個(gè)層面。首先是面對(duì)這樣復(fù)雜的系統(tǒng)，我們?cè)鯓訌倪@個(gè)系統(tǒng)運(yùn)行的蛛絲馬跡里全面發(fā)現(xiàn)各種異常，確保監(jiān)控的覆蓋率。第二個(gè)層面是面對(duì)這么多異常告警，我怎樣從這些告警風(fēng)暴里真正剝離出最關(guān)鍵的信息，從而減少誤報(bào)對(duì)運(yùn)維人員的干擾。第三個(gè)層面是當(dāng)異常發(fā)生時(shí)，我怎樣快速定位到問題的根本原因，并采取針對(duì)性的措施，對(duì)癥下藥來讓異常快速恢復(fù)，減少對(duì)用戶帶來的損失。

異常發(fā)現(xiàn)和告警降噪

接下來我們會(huì)為大家分享我們是怎樣逐一來攻克前面提到的三個(gè)挑戰(zhàn)。

首先是異常發(fā)現(xiàn)的層面，我們團(tuán)隊(duì)構(gòu)建了非常豐富的異常檢測(cè)相關(guān)的算法，力求實(shí)現(xiàn)異常的全面覆蓋及精準(zhǔn)發(fā)現(xiàn)。

我們?cè)谶@里梳理了 4 個(gè)典型場(chǎng)景，我們針對(duì)不同形態(tài)的數(shù)據(jù)和不同的場(chǎng)景都會(huì)選擇它最適配的算法。

首先是單指標(biāo)異常檢測(cè)場(chǎng)景，比較典型的應(yīng)用就是我們整個(gè)系統(tǒng)的可用性監(jiān)控。比如這個(gè)平臺(tái)整體的流量、性能、成功率，這些指標(biāo)和用戶自身的業(yè)務(wù)周期是非常緊密相關(guān)的，因此它經(jīng)常會(huì)呈現(xiàn)出比較復(fù)雜的多重周期性。所以在這里我們自研了一套魯棒的周期分解算法，來對(duì)這些曲線中的多重周期性進(jìn)行精準(zhǔn)的識(shí)別和分解，從而更好地做到異常的發(fā)現(xiàn)。

第二類是多指標(biāo)異常檢測(cè)場(chǎng)景。當(dāng)我需要判斷一臺(tái)機(jī)器是不是存在異常時(shí)，可能單獨(dú)去看其中的某一條指標(biāo)是沒有太大參考價(jià)值的，我需要綜合去看這個(gè)機(jī)器所有維度的指標(biāo)。在多指標(biāo)異常檢測(cè)這邊，我們直接選用了開源的多指標(biāo)異常檢測(cè)模型。雖然它相比單指標(biāo)異常檢測(cè)可能會(huì)犧牲一定程度的可解釋性及性能，但它可以更好地把握多指標(biāo)之間的內(nèi)部關(guān)聯(lián)性，從而提升檢測(cè)的精準(zhǔn)度。

第三類是基于分布的異常檢測(cè)。在大數(shù)據(jù)運(yùn)維的場(chǎng)景里，我們經(jīng)常會(huì)面臨著這樣的問題，就是當(dāng)我的集群性能變慢時(shí)，我不單是要檢測(cè)單個(gè)指標(biāo)、單個(gè)作業(yè)是不是變慢了，而是希望去看整個(gè)集群或整個(gè)平臺(tái)的作業(yè)運(yùn)行的分布是不是有異常的變化。針對(duì)分布的異常檢測(cè)，我們也自研了一套異常檢測(cè)算法。

除了指標(biāo)之外，日志也是非常重要的一種可觀測(cè)的數(shù)據(jù)。日志數(shù)據(jù)最大的挑戰(zhàn)是它的體量非常龐大，所以在這里我們先選用了業(yè)界性能比較高的日志模板提取算法，然后我們會(huì)基于提取出來的日志模式去判斷它是不是新增的異常，或者它的模式是不是有暴增的變化。

接下來我們重點(diǎn)給大家展開介紹一下前面提到的兩類自研算法。

首先是針對(duì)單指標(biāo)的場(chǎng)景，我梳理了我們運(yùn)維場(chǎng)景里最關(guān)心的幾類典型異常，包括均值變化、方差變化，也就是抖動(dòng)頻率的變化，還有尖峰深谷的異常、斷崖式跌落的異常，還有趨勢(shì)型的異常。大家可以看到梳理出來的異常可能看起來還比較明確，但實(shí)際上這些異常融合到真實(shí)的業(yè)務(wù)數(shù)據(jù)里時(shí)，非常容易受到數(shù)據(jù)本身的其他周期性的干擾，使得檢測(cè)變得非常困難。

所以在這里我們構(gòu)建了周期分解算法，它的核心思想是采用了分而治之的策略。首先從一條時(shí)間序列里把不同頻率的周期逐一剝離出來，然后再針對(duì)剝離出來的每一重周期去精準(zhǔn)計(jì)算它具體的周期長度，從而更好地把握整個(gè)數(shù)據(jù)的周期性特點(diǎn)。做完周期分解后，我們會(huì)進(jìn)一步利用不同類型的統(tǒng)計(jì)檢驗(yàn)方法，來分別對(duì)應(yīng)檢測(cè)前面提到的這幾種典型異常，從而實(shí)現(xiàn)用一套算法框架就能夠覆蓋前面提到的多種類型的異常，使得這一套單指標(biāo)的異常檢測(cè)算法能夠在運(yùn)維領(lǐng)域具備更強(qiáng)的普適性。

第二類是基于分布的異常檢測(cè)。大數(shù)據(jù)運(yùn)維經(jīng)常會(huì)面臨的痛點(diǎn)，是當(dāng)我需要做整個(gè)集群性能的異常檢測(cè)時(shí)會(huì)面臨兩個(gè)挑戰(zhàn)。首先是整個(gè)集群上運(yùn)行的作業(yè)數(shù)量非常多，如果我對(duì)每個(gè)作業(yè)都去檢測(cè)它有沒有運(yùn)行變慢，耗費(fèi)的成本會(huì)非常高。而且即使我做到了對(duì)每個(gè)作業(yè)的檢測(cè)，但實(shí)際上我并不會(huì)關(guān)心單一的某作業(yè)的波動(dòng)，因?yàn)楹芏嗲闆r下可能用戶購買的資源不足，他自己的資源組里面的作業(yè)之間也會(huì)進(jìn)行資源的爭搶，所以也會(huì)出現(xiàn)單作業(yè)變慢的情況。但我們真正需要關(guān)心的是整個(gè)集群作業(yè)性能異常、變慢的這種趨勢(shì)。

所以我們把整個(gè)集群作業(yè)運(yùn)行時(shí)長的分布圖構(gòu)建了出來，然后借鑒了優(yōu)化領(lǐng)域非常經(jīng)典的運(yùn)輸問題，結(jié)合基于重構(gòu)的深度學(xué)習(xí)模型來進(jìn)行異常檢測(cè)。我們可以把整個(gè)集群的作業(yè)運(yùn)行時(shí)長的分布圖想象成土堆，然后當(dāng)這個(gè)土堆向右邊運(yùn)輸時(shí)，我們?cè)黾右欢ǖ膽土P項(xiàng)，從而更好地檢測(cè)出整個(gè)作業(yè)運(yùn)行時(shí)長分布圖向右偏移，也就是整個(gè)集群性能變慢的這種場(chǎng)景。當(dāng)然我們還在深度學(xué)習(xí)模型里選用特殊的門控機(jī)制，來更好地應(yīng)對(duì)訓(xùn)練樣本當(dāng)中的噪音問題。

到這里我們已經(jīng)通過多種類型的異常檢測(cè)算法實(shí)現(xiàn)了異常的全面覆蓋。隨之而來的問題就是面對(duì)這么多的異常告警，運(yùn)維人員怎么判斷到底哪些異常才是需要第一時(shí)間響應(yīng)的。所以我們需要對(duì)這些告警進(jìn)行進(jìn)一步的精細(xì)化分級(jí)。我們主要從兩個(gè)方面來進(jìn)行告警的精細(xì)化處理，分別是影響面拉取和問題定界。

影響面拉取指的是當(dāng)我們的主指標(biāo)異常觸發(fā)了異常工單后，我可以根據(jù)整個(gè)拓?fù)潢P(guān)系拉取到主指標(biāo)所關(guān)聯(lián)的子指標(biāo)。然后我通過時(shí)間序列的下鉆算法，可以量化出來每個(gè)子指標(biāo)對(duì)主指標(biāo)的貢獻(xiàn)程度，以及它自己相對(duì)于歷史的異常度。綜合這兩個(gè)維度，我可以計(jì)算出來這一次的異常所波及到的影響面到底有多廣。一般來說波及面越廣的異常，運(yùn)維人員自然要去更加高優(yōu)地響應(yīng)。

第二類是問題定界。在大數(shù)據(jù)的場(chǎng)景里有很多異常是因?yàn)橛脩糇约旱牟僮魇д`引起的，比如像一條 SQL 語句，如果它的語法就存在錯(cuò)誤，自然會(huì)運(yùn)行失敗，但運(yùn)行失敗就會(huì)產(chǎn)生報(bào)錯(cuò)日志，甚至?xí)绊懙接脩魧?shí)例本身的成功率。但像這一類語法錯(cuò)誤導(dǎo)致的異常，我們的運(yùn)維人員并不需要第一時(shí)間介入處理。運(yùn)維人員真正應(yīng)該關(guān)心的是由平臺(tái)問題導(dǎo)致的失敗或者任務(wù)的異常，所以我們需要對(duì)用戶作業(yè)的報(bào)錯(cuò)日志進(jìn)行更加精細(xì)化的分析。

這里我們首先用前面提到的日志聚類算法對(duì)異常時(shí)段的所有日志先進(jìn)行聚類，聚類完成后我們會(huì)提取出其中典型的日志異常模式，然后和我們?nèi)罩局R(shí)庫當(dāng)中的標(biāo)簽去匹配，這個(gè)標(biāo)簽就可以標(biāo)識(shí)出日志到底是用戶問題還是平臺(tái)問題。日志知識(shí)庫的標(biāo)簽從哪來？一方面可以由我們的運(yùn)維專家去人工標(biāo)注，另一方面我們現(xiàn)在也在用大模型做這方面的提效。我們會(huì)利用大模型事先生成預(yù)標(biāo)簽結(jié)果，然后讓專家審核。

基于影響面和問題定界的結(jié)果，我們就可以對(duì)告警分成不同的等級(jí)，包括需要立即響應(yīng)的故障性異常，還有紅燈、黃燈，還有可以稍微延遲處理的風(fēng)險(xiǎn)性異常。這種做法首先可以讓我們不遺漏任何一種風(fēng)險(xiǎn)，同時(shí)又可以更好地分配運(yùn)維專家的精力和關(guān)注度，確保他們能夠更高效地處置那些真正緊急的異常。

多 Agent 根因定位框架

到這里我們已經(jīng)解決了異常發(fā)現(xiàn)環(huán)節(jié)的問題。但實(shí)際上在異常處置流程里，最耗時(shí)也往往最困難的點(diǎn)在根因定位這個(gè)環(huán)節(jié)。因?yàn)檫@個(gè)環(huán)節(jié)涉及到的數(shù)據(jù)還有工具都非常繁雜，而且即使存在一套非常標(biāo)準(zhǔn)的運(yùn)維排障流程，但真正具體到每一次故障時(shí)，依然需要結(jié)合當(dāng)時(shí)的場(chǎng)景和數(shù)據(jù)的具體問題做具體分析。所以根因定位往往也只有那些經(jīng)驗(yàn)非常豐富的運(yùn)維專家才能夠做到真正高效的處置。也正是因?yàn)楦蚨ㄎ淮嬖谥@樣的難點(diǎn)，它近年來也一直是學(xué)術(shù)界、工業(yè)界都非常關(guān)注的熱門話題。我們團(tuán)隊(duì)也一直在根因定位這個(gè)方向上不斷升級(jí)策略和算法，現(xiàn)在也引入了多 Agent 的框架來解決這樣的問題。

在具體介紹我們的策略之前，我們可以先簡單回顧一下 Agent 的核心要素。這幾個(gè)要素對(duì)構(gòu)建高效的智能體來說非常關(guān)鍵，它也是我們后續(xù)設(shè)計(jì)我們整個(gè)多 Agent 根因定位的核心思路。首先是角色的設(shè)定部分，我們通常會(huì)在大模型的 prompt 里交代它的角色定位，包括它的業(yè)務(wù)背景，使得它能夠在領(lǐng)域上具備更好的專業(yè)度，同時(shí)也能夠更加明確它自己的任務(wù)產(chǎn)出到底是什么樣的形式。第二類是長短期記憶，通常我們會(huì)通過 RAG 的方式引入外部私域知識(shí)，進(jìn)一步提升大模型在私域的專業(yè)性，更好地讓它了解上下文。第三類是好的工具模塊，讓大模型具備更強(qiáng)大的主觀能動(dòng)性，拓展它的能力邊界。最后是自主編排，對(duì)大模型來說非常關(guān)鍵，因?yàn)樗苯記Q定了大模型能不能很好地做到任務(wù)的拆解，以及具體執(zhí)行步驟的編排，它很大程度上決定了大模型能不能夠解決根因定位的問題。

接下來我們就分別介紹我們是怎樣基于這幾個(gè)核心要素來構(gòu)建多 Agent 根因定位框架。首先是角色設(shè)定的部分。

我們可以回憶一下，當(dāng)我們?nèi)粘３霈F(xiàn)線上問題時(shí)，運(yùn)維團(tuán)隊(duì)是怎樣工作的？通常他們會(huì)成立故障應(yīng)急小組，在這個(gè)小組中會(huì)有各個(gè)模塊的負(fù)責(zé)人，他們會(huì)分別排查各自的模塊目前的信息，并且判斷自己到底是根因方還是受影響方。然后他們也會(huì)和自己的上下游模塊做溝通，最終他們的結(jié)論會(huì)匯總到故障應(yīng)急負(fù)責(zé)人這邊，他會(huì)去對(duì)全局的信息做整體匯總，并給出最終結(jié)論。

我們希望基于大模型構(gòu)建出來的診斷系統(tǒng)也能夠具備故障應(yīng)急團(tuán)隊(duì)這樣的效果。在這個(gè)團(tuán)隊(duì)里面，人的分工是非常關(guān)鍵的，每個(gè)角色都應(yīng)該具備自己的專業(yè)度和特長，所以單一的 Agent 通常不能滿足這樣復(fù)雜任務(wù)的需求，所以我們引入了多 Agent 的框架。我們是按照系統(tǒng)的模塊來設(shè)定每個(gè) Agent 的角色，比如會(huì)有專門的存儲(chǔ) Agent、調(diào)度 Agent、網(wǎng)絡(luò) Agent 等。在 prompt 里，我們會(huì)內(nèi)置模塊相關(guān)的背景信息，使得它們可以對(duì)照現(xiàn)實(shí)世界里每個(gè)模塊的 owner 這樣的角色。除了模塊 Agent 外，在上層我們還會(huì)有系統(tǒng) Agent 的角色，就相當(dāng)于是故障應(yīng)急負(fù)責(zé)人。它可以收集每個(gè)模塊 Agent 的結(jié)論，并且給出最終的判斷。

在完成了 Agent 的角色設(shè)定后，接下來很重要的就是要豐富每個(gè) Agent 的裝備庫。我們構(gòu)建了 4 大類工具，首先是算法服務(wù)類的工具，包括前面提到的時(shí)間序列異常檢測(cè)、日志異常檢測(cè)能力，還有因果推斷能力。這些服務(wù)都會(huì)構(gòu)建成在線服務(wù)的形式，可以非常方便地對(duì)接其他系統(tǒng)，或者作為 API 來讓 Agent 調(diào)用。

第二類是 RAG 工具，它在私域的智能問答領(lǐng)域里是非常核心的技術(shù)，在根因定位環(huán)節(jié)里同樣發(fā)揮著非常關(guān)鍵的作用。比如當(dāng)我們需要對(duì)照歷史的相似故障來參考它的排障經(jīng)驗(yàn)時(shí)，或者當(dāng)我遇到一些指標(biāo)和日志，但可能不太清楚它的具體含義是什么時(shí)，都需要參考對(duì)應(yīng)的文檔，把對(duì)應(yīng)的知識(shí)檢索回來，從而給大模型提供更豐富的背景知識(shí)。

第三類是運(yùn)維分析類工具。我們的運(yùn)維人員構(gòu)建了很多集成了他們專家經(jīng)驗(yàn)的分析診斷流，比如針對(duì)單個(gè)作業(yè)的診斷，還有針對(duì)整個(gè)單機(jī)的診斷，還有網(wǎng)絡(luò)層的診斷等。這一類診斷工具理論上都可以由大模型來自主編排完成，但實(shí)際上因?yàn)檫@些工具之前就已經(jīng)沉淀好了，而且我們利用編排好的診斷流可以直接得到非常明確的結(jié)果，所以在很大程度上可以減少大模型的 token 消耗，來提升整體根因定位的效率。

第四類是外部插件。現(xiàn)在很多大模型應(yīng)用平臺(tái)都搭載了非常豐富的生態(tài)系統(tǒng)，有著插件市場(chǎng)這樣的概念，在里面很多第三方的開發(fā)者都會(huì)貢獻(xiàn)他們自己研發(fā)的分析工具，比較典型的包括在線檢索類工具、代碼編寫類工具，還有 chatBI 類的工具。現(xiàn)在這些工具都可以直接拿來為我們自己所用。

通過這些工具集的構(gòu)建，我們就讓 Agent 同時(shí)具備了專業(yè)的運(yùn)維分析能力、專業(yè)的算法分析能力，甚至還具備一定的通用基礎(chǔ)開發(fā)能力，這樣它就能有更好的武器應(yīng)對(duì)更加復(fù)雜的根因定位場(chǎng)景。

第三部分是關(guān)于編排可靠性的提升。

關(guān)于編排，我們會(huì)面臨這樣的挑戰(zhàn)，就是一方面我們希望能夠盡可能釋放大模型自主編排的靈活性，這樣它在以前沒有遇到過的故障場(chǎng)景也能發(fā)揮特定的效應(yīng)，而不是只能針對(duì)歷史重復(fù)出現(xiàn)的故障才知道該怎么做。但另一方面大模型編排結(jié)果是否可靠，可能直接決定了這個(gè)故障是不是能夠及時(shí)恢復(fù)，在這個(gè)方面我們的容錯(cuò)性是非常低的。所以這里的最大難點(diǎn)就是怎樣在釋放大模型編排靈活性的同時(shí)，又能進(jìn)一步提升編排結(jié)果的可靠性。

在這里我們采取的策略是固定工作流編排和自主編排相結(jié)合的混合策略。一方面我們會(huì)把運(yùn)行性能相對(duì)較高，并且對(duì)根因診斷非常關(guān)鍵的工具，直接編排到前置的工作流里。這些工具直接執(zhí)行完后，我會(huì)把它的結(jié)果輸入到大模型里，再讓大模型自主決策是不是還需要調(diào)用額外的工具來做進(jìn)一步排查，才能夠得到最終的根因推斷結(jié)論。

然后在大模型自主編排這一部分，我們也采取了很多策略來提升它結(jié)果的可靠性。任務(wù)分解部分我們主要采用的是 react 框架，也是現(xiàn)在比較主流的框架。大家在實(shí)際應(yīng)用里也可以直接把它作為 baseline 來作為后續(xù)提升的參照。另一部分是記憶增強(qiáng)，我們通過檢索外部的 SOP 來讓大模型進(jìn)一步校準(zhǔn)它生成的 SOP 的可信度。第三部分是加入了反思機(jī)制，我們會(huì)讓大模型在整個(gè)決策過程動(dòng)態(tài)反思中間過程可能會(huì)有哪些改動(dòng)來保證靈活性。

除了任務(wù)分解、記憶增強(qiáng)和反思機(jī)制之外，還有一些策略可以進(jìn)一步提升它的編排可靠性，包括多計(jì)劃選擇，還有引入外部規(guī)劃器來輔助它生成這樣的策略。我們也計(jì)劃在后面再對(duì)這些策略做更詳細(xì)的嘗試。

最后一個(gè)問題涉及多 Agent 框架的協(xié)同。我們前面聊的都是怎樣讓 Agent 自己變得更好，接下來的問題是我有這么多個(gè) Agent，怎么能夠讓它們更好地協(xié)同。

現(xiàn)在有非常多的 multi Agent 編排框架，他們?cè)谙到y(tǒng)里都會(huì)內(nèi)置編排好的多 Agent 協(xié)同工作流。但這些默認(rèn)的工作流，在我們的場(chǎng)景里或多或少都會(huì)存在一定的弊端。比如像順序執(zhí)行的工作流，上游節(jié)點(diǎn)在做決策時(shí)是不知道下游節(jié)點(diǎn)信息的，所以會(huì)存在著一定的信息不對(duì)稱，會(huì)導(dǎo)致它得到片面的結(jié)論，而它的結(jié)論可能又會(huì)進(jìn)一步影響到下游節(jié)點(diǎn)的決策，會(huì)形成一定的誤差累積效應(yīng)。第二類是層次結(jié)構(gòu)，雖然看起來有頂層節(jié)點(diǎn)來對(duì)大家的信息做匯總，但實(shí)際上下游節(jié)點(diǎn)之間依然是不存在任何信息交換的，同樣會(huì)導(dǎo)致它們自己得到比較片面的結(jié)論。第三種圓桌討論的模式，看起來大家的信息可以在桌子上進(jìn)行非常充分的交換，但它最大的弊端在于缺少明確的領(lǐng)導(dǎo)者，所以大家的討論可能會(huì)非常發(fā)散，聊著聊著可能就偏離了主題，很難在限定時(shí)間內(nèi)得到非常明確的結(jié)論。

考慮到這些固定編排模式的弊端，我們自研了一套基于神經(jīng)網(wǎng)絡(luò)反饋機(jī)制的工作流。它的核心思想也非常簡單，我首先會(huì)根據(jù)模塊之間的拓?fù)浣Y(jié)構(gòu)設(shè)定單向傳導(dǎo)的工作流，我們稱之為前向反饋。在前向反饋的基礎(chǔ)上，我額外增加了后向反饋的機(jī)制，實(shí)際上就是讓前置 Agent 有機(jī)會(huì)修改自己之前可能得出的錯(cuò)誤結(jié)論，然后最終大家的結(jié)論依然會(huì)匯總到系統(tǒng) Agent 這邊來。這樣的好處是一方面我可以在一定程度上彌補(bǔ)信息不對(duì)稱的問題，同時(shí)也能把整體的推理次數(shù)非常嚴(yán)格地限制在預(yù)設(shè)的范圍內(nèi)，減少盲目發(fā)散的討論。

通用異常處置平臺(tái)

前面介紹的更多都是算法層面的設(shè)計(jì)，而好的算法最終還是需要真正集成到我們的平臺(tái)上，才能真正融合到運(yùn)維人員的工作流里，發(fā)揮出真正的效用。所以工程平臺(tái)的建設(shè)也非常關(guān)鍵。在這里我給大家分享一下我們?cè)鯓觼順?gòu)建通用的異常處置平臺(tái)。現(xiàn)在我們各個(gè)產(chǎn)品的運(yùn)維異常處置流程都可以在這個(gè)異常處置平臺(tái)上來進(jìn)行，很大程度上提升了我們計(jì)算平臺(tái)整體異常處置的效率。

整體架構(gòu)最底層是數(shù)據(jù)層，我們?yōu)檫\(yùn)維場(chǎng)景里這些經(jīng)典的數(shù)據(jù)模式都安排了最適合它們的存儲(chǔ)方式，包括指標(biāo)、日志、拓?fù)洹⑽臋n、事件等，使得它可以在后續(xù)的分析環(huán)節(jié)里做到非常高效的數(shù)據(jù)抽取、根因分析。

數(shù)據(jù)層之上是我們非常核心的算法服務(wù)層及大模型服務(wù)層。算法服務(wù)層里搭載的是前面提到的時(shí)序、日志、根因定位、因果分析，還有檢索這類非常基礎(chǔ)通用的算法，這些算法會(huì)部署在 PAI-EAS 上變成在線服務(wù)，可以供其他系統(tǒng)直接調(diào)用，也可以作為工具集成到 Agent 里。

大模型相關(guān)的這一部分，除了前面提到的 prompt 工程，還有工具的調(diào)用，還有工作流編排。對(duì)于完整的大模型服務(wù)而言，如果你不是 demo，如果你想要真正上生產(chǎn)的話，還需要考慮很多因素，比如像可觀測(cè)能力，還有資源的管理隔離能力等。所以想要搭建好大模型應(yīng)用服務(wù)，還是需要搭配非常好的大模型應(yīng)用構(gòu)建的平臺(tái)。幸運(yùn)的是現(xiàn)在也有非常多的這樣的平臺(tái)，包括商業(yè)化的、開源的，都具備了非常強(qiáng)大的能力。但對(duì)我們來說，我們還是需要根據(jù)我們自己的業(yè)務(wù)場(chǎng)景去選擇最好的、最適合自己的平臺(tái)來進(jìn)行構(gòu)建，才能提升效率。

接下來也想和大家進(jìn)一步分享一下我們?cè)谶x擇這樣的大模型應(yīng)用開發(fā)平臺(tái)時(shí)會(huì)從哪幾個(gè)角度來考慮。我們主要會(huì)從三個(gè)層面，第一個(gè)是應(yīng)用構(gòu)建本身的便捷度和產(chǎn)品應(yīng)用性，第二個(gè)是 LLMOps 能力的完備度，最后是平臺(tái)本身的開放度。

在應(yīng)用構(gòu)建方面，我們會(huì)重點(diǎn)考慮我在這個(gè)平臺(tái)上是不是可以非常便捷地完成非常復(fù)雜的業(yè)務(wù)工作流的編排，最好就是拖拉拽的方式就可以完成復(fù)雜的編排任務(wù)。其次是這個(gè)平臺(tái)上面是不是同時(shí)具備了微調(diào)能力，這樣我就不需要在各個(gè)平臺(tái)上頻繁切換，能夠在平臺(tái)上一站式完成整個(gè)模型的微調(diào)和最終應(yīng)用的部署搭建。第三個(gè)是像 RAG 的經(jīng)典組件，我在這個(gè)平臺(tái)上是不是能夠直接復(fù)用，減少額外的開發(fā)工作量。最后是我在這個(gè)平臺(tái)上面搭建的服務(wù)，是不是能夠非常便捷地和最終的交互出口承接，不需要額外再構(gòu)建中間的一層服務(wù)來進(jìn)行引流。

第二個(gè)大的層面是 LLMOps 的能力，它直接決定了整個(gè)大模型應(yīng)用服務(wù)的穩(wěn)定性，以及后續(xù)性能優(yōu)化的空間。所以我會(huì)重點(diǎn)關(guān)注平臺(tái)是不是具備一定的模型加速能力，資源管理的能力也非常重要，就是在突發(fā)流量打進(jìn)來的時(shí)候，你是不是能非常方便地幫我做資源擴(kuò)容。還有我不同的大數(shù)據(jù)產(chǎn)品之間肯定是要做隔離的，你是不是具備完備的資源管理隔離的體系。可觀測(cè)性也是非常關(guān)鍵的，當(dāng)我大模型推理失敗的時(shí)候，是不是能夠非常便捷清晰地看到到底是哪個(gè)環(huán)節(jié)、哪個(gè)工具調(diào)用出現(xiàn)了問題，方便我進(jìn)行問題的快速恢復(fù)和改進(jìn)。最后是模型測(cè)評(píng)的能力，因?yàn)楝F(xiàn)在基礎(chǔ)模型發(fā)展非常迅速，所以我希望能夠在平臺(tái)上非常便捷地做模型效果的測(cè)評(píng)，來方便我選擇最適合這個(gè)場(chǎng)景的基模。

第三個(gè)層面是開放性，開放性直接決定了我在你這個(gè)平臺(tái)上是不是能夠更好地利用別人開發(fā)的能力，以及我是不是能夠和開源的生態(tài)做更好的兼容。這里首先要考慮你的插件市場(chǎng)是不是足夠豐富。第二個(gè)方面，像現(xiàn)在比較火的 MCP 協(xié)議，你是不是能夠天然支持？還有同外部系統(tǒng)以及開源框架的對(duì)接，我現(xiàn)在遷移到你的平臺(tái)，是不是能夠更好地做到無縫的遷移，我后續(xù)是不是還能夠持續(xù)用到開源生態(tài)的創(chuàng)新性成果，這些都非常關(guān)鍵。

基于這些考慮因素，我們現(xiàn)在選用的是阿里云的百煉來搭載大模型應(yīng)用，當(dāng)然大家也可以結(jié)合自己對(duì)這幾個(gè)因素的優(yōu)先級(jí)的排序，選擇更適合自己的平臺(tái)。我們選擇百煉，一方面是它在我前面提到的幾個(gè)維度上相對(duì)來說是比較完整的，同時(shí)它在應(yīng)用類型上也非常豐富，既包括我前面提到的固定工作流式的編排，也提供了以 RAG 為核心的智能體應(yīng)用，同時(shí)它還提供了智能體編排應(yīng)用，可以把前面提到的多種不同類型的應(yīng)用全部整合進(jìn)來，做到混合編排。

另外它整個(gè)任務(wù)編排的產(chǎn)品界面是相對(duì)來說比較友好的，我在上面可以非常便捷地拖拉拽來完成復(fù)雜工作流的編排。最后在整個(gè)百煉的項(xiàng)目空間里，我可以觀測(cè)到整個(gè)服務(wù)的調(diào)用情況，每一次調(diào)用都可以點(diǎn)開詳情看每個(gè)工具的輸入輸出到底是什么，是不是符合預(yù)期，方便我進(jìn)行問題的排查。

前面我們已經(jīng)完成了大模型應(yīng)用搭建的部分，接下來我們具體聊一下整個(gè)異常處置平臺(tái)到底包含了哪些核心的模塊。

首先這個(gè)平臺(tái)的入口也就是告警源，除了前面提到的算法檢測(cè)結(jié)果外，在我們實(shí)際的業(yè)務(wù)里它還會(huì)包含 SRE 自己在監(jiān)控系統(tǒng)里設(shè)置的監(jiān)控告警，當(dāng)然還有用戶來提的工單或者人工補(bǔ)錄的情況。每一種告警來源，我們都會(huì)給它生成異常工單，這個(gè)工單里會(huì)包含 4 個(gè)非常核心的模塊，首先是異常現(xiàn)場(chǎng)，然后是定界定級(jí)的結(jié)果，還有根因定位的結(jié)果以及快速恢復(fù)。

異常現(xiàn)場(chǎng)主要呈現(xiàn)出這一次開工單的原因到底是什么，觸發(fā)的指標(biāo)和日志到底是什么樣的，來方便運(yùn)維人員在接手工單時(shí)快速了解問題的背景。然后是定界定級(jí)的結(jié)果，會(huì)具體呈現(xiàn)出這一次異常的影響面，以及算法得到的分級(jí)過程。根因定位會(huì)展現(xiàn)出多 Agent 框架定位的結(jié)果，我們現(xiàn)在會(huì)得到根因模塊的結(jié)論，同時(shí)大模型也會(huì)提供出得到這個(gè)結(jié)論的推理依據(jù)。同時(shí)對(duì)于每個(gè)模塊 Agent，我都可以點(diǎn)開詳情查看它的工具調(diào)用情況。最后快速恢復(fù)的部分，我們現(xiàn)在還在相對(duì)比較初步的階段。目前主要是做的是檢索歷史的相似工單，這樣運(yùn)維人員可以在新的工單里直接點(diǎn)擊跳轉(zhuǎn)到歷史工單里查看當(dāng)時(shí)的處理策略，從而對(duì)這一次的異常處置提供一定的參考。

我們可以整體來看一下整個(gè)異常處置平臺(tái)在我們線上應(yīng)用的真實(shí)效果。首先當(dāng)異常發(fā)生時(shí)，運(yùn)維人員會(huì)在釘釘上收到卡片的通知，根據(jù)告警等級(jí)的不同，卡片也會(huì)呈現(xiàn)出不同的顏色，直觀看出異常的嚴(yán)重程度。如果異常沒有被及時(shí)處置，它的影響面可能會(huì)不斷擴(kuò)大，它可能會(huì)從黃燈變成紅燈，這個(gè)卡片的顏色也會(huì)隨之動(dòng)態(tài)變化。

另外當(dāng)工單被運(yùn)維人員接手進(jìn)行處置時(shí)，我們可以在工單上實(shí)時(shí)看到它的處置進(jìn)度，方便整個(gè)群里的人都了解整個(gè)異常的處置情況。

運(yùn)維人員收到這個(gè)卡片后，他可以點(diǎn)擊對(duì)應(yīng)的鏈接跳轉(zhuǎn)到異常工單的頁面上，可以看到異常的現(xiàn)場(chǎng)，包括具體的曲線以及曲線到底是從哪個(gè)時(shí)刻開始有這個(gè)異常點(diǎn)。

然后在異常影響面的分析部分，我們可以看到這次的異常到底影響了哪些客戶，我們會(huì)在這里列出具體的客戶信息。同時(shí)我們也能看到這個(gè)客戶這次受影響的實(shí)例在我們這次異常里的占比。在最下方，我們會(huì)呈現(xiàn)多 Agent 的根因定位結(jié)論。首先會(huì)得到明確的定界和定位結(jié)果，以及這個(gè)結(jié)果的核心依據(jù)。下面我們可以看到每個(gè)模塊 Agent 的獨(dú)立結(jié)果，點(diǎn)擊詳情就可以進(jìn)一步看這個(gè)模塊到底調(diào)用了哪些工具，以及這些指標(biāo)日志的檢測(cè)的情。實(shí)際上我們經(jīng)常會(huì)出現(xiàn)多個(gè)模塊 Agent 都覺得自己出問題了，都可能覺得自己是根因這樣的情況，但我們最終的系統(tǒng) Agent 還是會(huì)根據(jù)各個(gè)模塊之間的潛在拓?fù)潢P(guān)系得到更加明確的結(jié)論，最終它給出的結(jié)論只會(huì)是最終根因的那個(gè)模塊。

總結(jié)和展望

這次分享，我們首先從大數(shù)據(jù)運(yùn)維的業(yè)務(wù)背景出發(fā)，來給大家介紹了我們?cè)诋惓Ｌ幹铆h(huán)節(jié)到底都面臨著哪些挑戰(zhàn)，包括我們?cè)鯓尤鏅z測(cè)出這些異常，以及怎么面對(duì)告警風(fēng)暴，真正剝離出其中關(guān)鍵的信息，幫助運(yùn)維人員更好地分配注意力，以及最后我們?cè)诋惓０l(fā)生時(shí)怎么快速定位到問題的根因。

然后我們具體介紹了我們?cè)鯓永?AI 技術(shù)來逐一攻破這些挑戰(zhàn)，包括建設(shè)多種類型的異常檢測(cè)算法，以及通過影響面的分析還有問題的定界來幫助我做更加精細(xì)化的告警分級(jí)。最后我們還引入了多 Agent 的根因定位框架，來模擬現(xiàn)實(shí)當(dāng)中的故障處置小組實(shí)現(xiàn)根因模塊的定位，并且給出它的推理依據(jù)，讓我們的大模型推理不再是黑盒。前面提到這些算法技術(shù)都是通過 PAI-EAS 部署成在線服務(wù)的方式來供其他的系統(tǒng)和大模型應(yīng)用層來進(jìn)行進(jìn)一步的調(diào)用。

而我們大模型服務(wù)層本身則是依靠百煉這個(gè)平臺(tái)來進(jìn)行構(gòu)建和部署的，最終這些算法服務(wù)層和大模型服務(wù)層共同支撐了最上層的異常處置平臺(tái)，真正把 AI 能力集成到平臺(tái)和產(chǎn)品里，整合到運(yùn)維人員日常的工作流里，發(fā)揮出真正的提效作用。

最后我們來對(duì)下一步的規(guī)劃做展望。首先我們會(huì)進(jìn)行異常處置能力整體的補(bǔ)全，會(huì)從現(xiàn)在事中的異常發(fā)現(xiàn)，一步向前延展，做風(fēng)險(xiǎn)預(yù)防。我們整體的思路是希望納入更多海量數(shù)據(jù)來做故障的提前預(yù)警，這方面帶來的技術(shù)挑戰(zhàn)會(huì)更大，可能會(huì)涉及告警本身時(shí)空相關(guān)性的挖掘等技術(shù)。

在根因定位之后，我們還會(huì)打造真正的預(yù)案推薦，因?yàn)橹挥姓嬲扑]出了可能的預(yù)案，才有可能走到最終的自愈環(huán)節(jié)，做到處置的自動(dòng)化閉環(huán)。預(yù)案推薦在某種程度上也依賴根因定位的精細(xì)度。目前我們的根因定位也只能做到一級(jí)的模塊，后面我們會(huì)進(jìn)一步做到二級(jí)模塊，來讓整個(gè)根因定位更加明確具體，讓它最終的關(guān)聯(lián)動(dòng)作可以更加明確。

除了異常處置能力的補(bǔ)全外，我們還會(huì)進(jìn)行 Agent 的能力增強(qiáng)，包括自主編排、可靠性的提升，我們還有很多的策略需要嘗試，來進(jìn)一步保證它的結(jié)果是靠譜，并且性能是足夠優(yōu)的。還有工具能力的拓展，我們現(xiàn)在主要是把現(xiàn)有的運(yùn)維平臺(tái)上面的工具還有作業(yè)去兼容 MCP 這樣的協(xié)議，使得 Agent 具備更強(qiáng)的系統(tǒng)兼容性。

最后是交互體驗(yàn)的優(yōu)化以及人工反饋的增強(qiáng)。要讓大模型能夠得到令人滿意的效果，人的實(shí)時(shí)反饋是非常重要的，包括現(xiàn)在很多像 Manus 這樣的組件，都會(huì)在生成 plan 之后允許用戶有機(jī)會(huì)做調(diào)整，這對(duì)最終結(jié)果的準(zhǔn)確性非常關(guān)鍵。所以我們整體的交互模式的變化，以及后續(xù)怎樣利用人工的反饋來持續(xù)優(yōu)化后面的迭代，讓大模型真正做到越用越聰明，是非常關(guān)鍵的問題。

整體來說，我覺得大模型技術(shù)和 AI 技術(shù)的發(fā)展可以用日新月異來形容，它也給我們智能運(yùn)維領(lǐng)域帶來了很多技術(shù)上面的突破，我也非常期待我們能夠有更多的成果來做進(jìn)一步的分享，感謝大家。

阿里云計(jì)算平臺(tái)正急招智能運(yùn)維算法專家，崗位鏈接：https://careers.aliyun.com/off-campus/position-detail?lang=zh&positionId=2009183001&trace=qrcode_share，也可直接投遞簡歷至：congrong.zyy@alibaba-inc.com，歡迎加入我們。

嘉賓介紹

張穎瑩，阿里云算法專家，阿里云計(jì)算平臺(tái)智能運(yùn)維算法團(tuán)隊(duì)負(fù)責(zé)人，在智能運(yùn)維領(lǐng)域深耕 8 年。用產(chǎn)品和服務(wù)支撐計(jì)算平臺(tái) MaxCompute、Flink、Dataworks、PAI 等多個(gè)大數(shù)據(jù) &AI 產(chǎn)品的智能化運(yùn)維。多項(xiàng)研究成果被 ICLR，KDD，VLDB, SIGMOD, ICDE，WWW, CIKM，ICASSP 等國際頂會(huì)接收，并帶領(lǐng)團(tuán)隊(duì)獲得了 ICASSP 國際智能運(yùn)維算法大賽冠軍。曾受邀在 QCon，ArchSummit，DataFunCon，F(xiàn)linkForward 等大會(huì)發(fā)表演講，同時(shí)參與了阿里巴巴開源大數(shù)據(jù)運(yùn)維平臺(tái) SREWorks 開發(fā)和信通院《智能運(yùn)維能力成熟度模型》行業(yè)標(biāo)準(zhǔn)編寫。

2026，AI 正在以更工程化的方式深度融入軟件生產(chǎn)，Agentic AI 的探索也將從局部試點(diǎn)邁向體系化工程建設(shè)！

QCon 北京 2026 已正式啟動(dòng)，本屆大會(huì)以“Agentic AI 時(shí)代的軟件工程重塑”為核心主線，推動(dòng)技術(shù)探索從「AI For What」真正落地到可持續(xù)的「Value From AI」。從前沿技術(shù)雷達(dá)、架構(gòu)設(shè)計(jì)與數(shù)據(jù)底座、效能與成本、產(chǎn)品與交互、可信落地、研發(fā)組織進(jìn)化六大維度，系統(tǒng)性展開深度探索。QCon 北京 2026，邀你一起，站在拐點(diǎn)之上。