1. 從告警風暴說起為什么傳統(tǒng) AIOps 越用越累凌晨兩點手機在床頭柜上震個不停。我摸黑抓起來一看監(jiān)控群里已經(jīng)刷了上百條消息——某個核心服務的響應時間曲線突然抬頭緊接著是超時告警、線程池告警、下游依賴告警、數(shù)據(jù)庫連接數(shù)告警五分鐘之內(nèi)涌進來四十多條。值班的同事在群里問了一句有人知道這是哪個變更引起的嗎然后是一片沉默。這個場景我相信做運維的人都太熟悉了。過去幾年大家應對這種局面的標準答案就是上 AIOps。買一套平臺接一堆數(shù)據(jù)源做指標異常檢測、日志聚類、告警收斂、根因分析。聽起來很美好但真正落地之后你會發(fā)現(xiàn)一個尷尬的事實告警確實被收斂了但問題并沒有被解決。平臺告訴你這四十條告警大概率來自同一個根因然后呢然后還是得靠人去看、去查、去判斷、去操作。這就是我想在這篇里聊清楚的核心問題。AIOps 這個詞從誕生到現(xiàn)在差不多有七八年了它解決的是看得見的問題——把海量監(jiān)控數(shù)據(jù)變成可理解的信號。但運維工作的終點從來不是看見問題而是把問題處理掉。從看見到處理之間隔著一條巨大的鴻溝而這條鴻溝恰恰是傳統(tǒng) AIOps 邁不過去的。最近一兩年行業(yè)里開始頻繁出現(xiàn)一個新說法Agentic Operations中文一般叫智能體運維或者代理式運維。它不是給 AIOps 換個馬甲而是把整個運維自動化的范式往前推了一大步。簡單說AIOps 是AI 幫你分析Agentic Operations 是AI 幫你干活。前者是副駕駛后者是能自己握方向盤、看路況、踩油門剎車的司機——當然關鍵決策還是人在把關。這篇文章我打算從一線運維的視角把從 AIOps 到 Agentic Operations 這條演進路徑講透。包括傳統(tǒng) AIOps 到底卡在哪、Agentic Operations 的核心機制是什么、一個可落地的智能體運維系統(tǒng)該怎么搭、實際跑起來會遇到哪些坑、以及我對這個方向的一些真實判斷。不管你是剛接觸運維自動化的新人還是已經(jīng)在 AIOps 平臺上投了不少錢的老兵應該都能從中找到對自己有用的東西。2. AIOps 的能力邊界它到底解決了什么又卡在了哪里2.1 傳統(tǒng) AIOps 的三層能力模型要理解為什么需要 Agentic Operations得先把 AIOps 本身拆開看。行業(yè)里比較公認的劃分方式是把 AIOps 的能力分成三層。最底層是數(shù)據(jù)層負責把指標Metrics、日志Logs、鏈路追蹤Traces、事件Events這些異構數(shù)據(jù)統(tǒng)一采集、清洗、存儲。這一層是地基沒有它上面什么都做不了。很多團隊在這一層就卡了很久因為數(shù)據(jù)源太雜、格式太亂、采樣率不一致光是做數(shù)據(jù)對齊就夠喝一壺的。中間層是分析層也是 AIOps 最核心的部分。這里面塞滿了各種算法時序異常檢測、日志模式挖掘、告警關聯(lián)分析、根因定位、容量預測等等。這一層的目標是把原始數(shù)據(jù)變成洞察——告訴你哪里不對勁、可能是什么原因。最上層是展示與聯(lián)動層把分析結果通過看板、告警、工單等形式呈現(xiàn)出來并且和現(xiàn)有的運維流程做對接。比如檢測到異常之后自動創(chuàng)建工單、自動通知值班人、自動觸發(fā)某個預案腳本。這三層模型本身沒問題問題出在最上層的聯(lián)動做得太淺。絕大多數(shù) AIOps 平臺的聯(lián)動本質上還是if-then的規(guī)則引擎如果檢測到 A 異常就執(zhí)行 B 動作。這種聯(lián)動在面對簡單、確定、重復的場景時很好用但一旦場景稍微復雜一點規(guī)則就爆炸了。2.2 規(guī)則引擎的天花板在哪里我舉個真實的例子。假設你有一個電商系統(tǒng)大促期間某個商品詳情頁的響應變慢。傳統(tǒng) AIOps 會怎么處理首先異常檢測模塊發(fā)現(xiàn)響應時間 P99 超過了閾值觸發(fā)告警。然后告警關聯(lián)模塊發(fā)現(xiàn)這個告警和數(shù)據(jù)庫慢查詢告警、緩存命中率下降告警在時間上高度相關于是把它們聚成一條。接著根因分析模塊根據(jù)拓撲關系推測可能是緩存層出了問題。最后聯(lián)動層根據(jù)預設規(guī)則執(zhí)行清理緩存的預案腳本。聽起來很順對吧但現(xiàn)實往往是清理緩存之后問題沒解決因為真正的根因是某個新上線的代碼邏輯導致緩存 key 設計不合理大量請求穿透到了數(shù)據(jù)庫。而清理緩存這個動作不僅沒幫上忙反而讓緩存雪崩問題更嚴重了。這就是規(guī)則引擎的根本局限它只能處理已知的已知。你事先想到了什么場景就寫什么規(guī)則。但運維現(xiàn)場絕大多數(shù)故障都是未知的未知——是多個因素疊加出來的、之前沒遇到過的組合。規(guī)則引擎面對這種情況要么無動于衷要么執(zhí)行一個錯誤的動作把事情搞得更糟。更麻煩的是規(guī)則會隨著系統(tǒng)演進而腐化。半年前寫的一條規(guī)則當時是對的但現(xiàn)在系統(tǒng)架構變了、依賴關系變了這條規(guī)則可能就變成了定時炸彈。而維護這些規(guī)則的成本隨著數(shù)量增長是超線性的。我見過一個團隊AIOps 平臺里積累了上千條聯(lián)動規(guī)則最后沒人敢動因為誰也不知道刪掉哪條會引發(fā)什么連鎖反應。2.3 從分析到行動的斷層把問題說得更本質一點傳統(tǒng) AIOps 的能力分布是極度不均衡的。它在分析這一側投入了 90% 的精力做了各種花哨的算法但在行動這一側基本還停留在腳本和規(guī)則的原始階段。這個斷層帶來的直接后果就是分析結果無法有效轉化為行動。平臺告訴你根因大概率是 X但接下來要做什么、按什么順序做、做完怎么驗證、失敗了怎么回滾這些全都得靠人。而人在凌晨兩點、面對四十條告警、還帶著困意的時候判斷力和執(zhí)行力都是打折扣的。我經(jīng)常用一個比喻傳統(tǒng) AIOps 就像一個特別厲害的診斷醫(yī)生能通過各種檢查告訴你得了什么病但開藥、打針、手術這些事它一概不管全得你自己來。而 Agentic Operations 想做的是讓這個醫(yī)生不僅能診斷還能在授權范圍內(nèi)直接開方、執(zhí)行、觀察療效、必要時調整方案。這個跨越靠堆算法是堆不出來的它需要一套全新的架構。3. Agentic Operations 的核心機制從規(guī)則驅動到目標驅動3.1 智能體到底智能在哪里先說清楚一個概念Agentic Operations 里的Agent不是指某個具體的 AI 模型而是指一個具備自主決策能力的執(zhí)行單元。它有幾個關鍵特征缺一不可。第一是目標導向。你給它的不是一個具體的指令執(zhí)行腳本 A而是一個目標讓這個服務的 P99 恢復到 200ms 以內(nèi)。它會自己拆解這個目標規(guī)劃出需要執(zhí)行的步驟。第二是工具使用能力。它能調用各種工具——查監(jiān)控、看日志、執(zhí)行命令、調 API、發(fā)通知——就像人一樣。這些工具是它的手和腳。第三是反饋閉環(huán)。它執(zhí)行完一個動作之后會觀察結果判斷是否接近目標如果沒達到就調整策略再試。這個執(zhí)行-觀察-調整的循環(huán)是它和規(guī)則引擎最本質的區(qū)別。第四是邊界意識。它知道自己能做什么、不能做什么遇到超出權限或能力范圍的情況會主動交給人。這一點極其重要后面會專門講。把這四點合起來看你會發(fā)現(xiàn) Agentic Operations 的本質是把運維工作從執(zhí)行預設動作變成了追求預設目標。這是一個范式級的轉變。3.2 一個具體的對比告警處理流程的兩種形態(tài)為了讓大家直觀感受到差異我用同一個場景——某服務響應時間突增——來對比兩種形態(tài)的處理流程。傳統(tǒng) AIOps 的流程是這樣的異常檢測觸發(fā)告警告警收斂合并相關告警根因分析給出可能原因然后推送給值班人。值班人打開電腦登錄各種系統(tǒng)手動排查手動執(zhí)行修復動作。整個過程中AI 的參與在推送那一刻就結束了。Agentic Operations 的流程則是異常檢測觸發(fā)之后一個運維智能體被激活。它首先自主收集上下文——拉取最近的相關變更記錄、查看服務依賴拓撲、檢查上下游指標、檢索歷史相似故障。然后它形成假設——比如可能是最近一次發(fā)布引入的問題。接著它驗證假設——對比發(fā)布前后的指標差異、檢查新版本代碼的日志特征。如果假設成立它規(guī)劃動作——回滾發(fā)布、觀察指標、確認恢復。如果假設不成立它換一個假設繼續(xù)排查。整個過程中只有在需要執(zhí)行高風險動作比如回滾生產(chǎn)環(huán)境時才會請求人工確認?？闯鰠^(qū)別了嗎傳統(tǒng) AIOps 把 AI 當成分析工具Agentic Operations 把 AI 當成執(zhí)行主體。前者是人用 AI后者是人管 AI。3.3 支撐智能體運轉的四個技術支柱Agentic Operations 不是憑空冒出來的它站在幾個技術方向的交匯點上。第一個支柱是大語言模型的推理與規(guī)劃能力。這是最關鍵的變量。過去的自動化系統(tǒng)之所以只能做規(guī)則是因為機器不理解目標和上下文。而大語言模型第一次讓機器具備了理解模糊目標、拆解復雜任務、根據(jù)上下文調整策略的能力。它能把讓服務恢復正常這種模糊目標拆解成一系列具體的、可執(zhí)行的步驟。第二個支柱是工具調用與函數(shù)編排。光會想不會做沒用。現(xiàn)在的智能體框架普遍支持工具調用——把各種運維能力查詢、執(zhí)行、通知封裝成標準接口智能體根據(jù)需要自主選擇調用。這相當于給智能體裝上了手和腳。第三個支柱是可觀測性數(shù)據(jù)的標準化。智能體要決策得有足夠的信息輸入。OpenTelemetry 這類標準的普及讓指標、日志、追蹤數(shù)據(jù)的格式趨于統(tǒng)一智能體不需要為每個系統(tǒng)寫一套適配邏輯。這是基礎設施層面的準備。第四個支柱是執(zhí)行環(huán)境的安全隔離。讓 AI 去操作生產(chǎn)環(huán)境安全是繞不過去的坎。現(xiàn)在主流的做法是沙箱執(zhí)行 權限分級 人工審批三層防護。智能體的所有動作都在受控環(huán)境中進行高風險動作必須經(jīng)過人工確認。這套機制成熟了智能體才敢真正落地。3.4 為什么是現(xiàn)在三個條件同時成熟有人可能會問智能體運維這個概念聽著挺好為什么以前沒人做答案是以前做不了因為缺條件。條件一是模型能力。兩三年前的大語言模型推理能力還不足以支撐復雜的運維決策。你讓它規(guī)劃一個多步驟的排查流程它經(jīng)常邏輯混亂、遺漏關鍵步驟。而現(xiàn)在的主流模型在復雜推理任務上的表現(xiàn)已經(jīng)相當可靠了。條件二是工具生態(tài)。以前要讓 AI 調用運維工具得自己寫一大堆膠水代碼?，F(xiàn)在各種智能體框架、工具協(xié)議逐漸成熟接入成本大幅降低。條件三是成本。智能體運維需要頻繁調用模型進行推理token 消耗不小。隨著模型推理成本持續(xù)下降這個經(jīng)濟賬才算得過來。一個中等規(guī)模的系統(tǒng)如果每次故障處理要消耗幾十萬 token成本能不能接受是必須算清楚的。這三個條件在最近一兩年同時成熟所以 Agentic Operations 才從概念走向了落地。4. 搭建一個可落地的運維智能體架構與關鍵設計4.1 整體架構五層結構如果要動手搭一套運維智能體系統(tǒng)我建議按下面這個五層結構來設計。這是我在實際項目中驗證過、比較穩(wěn)妥的分層方式。第一層是數(shù)據(jù)接入層。負責對接各種可觀測性數(shù)據(jù)源——指標系統(tǒng)、日志平臺、鏈路追蹤、變更系統(tǒng)、CMDB。這一層的核心任務是把數(shù)據(jù)標準化讓上層智能體不用關心數(shù)據(jù)來自哪里、格式是什么。建議統(tǒng)一用 OpenTelemetry 的數(shù)據(jù)模型做中間格式。第二層是工具層。把運維能力封裝成智能體可調用的工具。每個工具要有清晰的名稱、描述、參數(shù)定義和返回值格式。工具的設計有個原則粒度要適中。太粗比如一個修復服務的工具智能體沒法靈活組合太細比如一個讀取某個文件第 3 行的工具智能體要調用太多次。我一般按一個完整的運維動作來切分比如查詢服務指標獲取最近變更執(zhí)行回滾重啟實例。第三層是智能體層。這是核心。里面住著各種專職智能體——有的負責告警分診有的負責根因排查有的負責執(zhí)行修復有的負責事后復盤。它們之間可以協(xié)作也可以有主從關系。這一層要解決的關鍵問題是任務規(guī)劃和上下文管理。第四層是編排與治理層。負責智能體之間的調度、權限控制、審批流、審計日志。這一層是管智能體的確保它們不會亂來。第五層是交互層。人機交互的界面——值班人怎么查看智能體的工作過程、怎么介入、怎么審批。這一層的設計直接決定了運維人員愿不愿意用這套系統(tǒng)。4.2 工具設計智能體的手該怎么造工具層是很多人容易忽視、但實際最影響效果的部分。我見過一些項目模型能力很強但工具設計得糟糕導致智能體要么用不對工具要么被工具返回的一堆無用信息淹沒。工具設計有幾個實操要點。描述要寫給模型看不是寫給人看。工具的描述文本會直接進入模型的上下文所以它要清晰說明這個工具做什么、什么時候用、參數(shù)是什么、返回什么。不要寫查詢指標這種模糊描述要寫根據(jù)服務名和時間范圍查詢該服務的響應時間、錯誤率、QPS 等核心指標返回時序數(shù)據(jù)點。返回結果要精簡。工具返回的數(shù)據(jù)會占用模型的上下文窗口。如果一個工具返回幾千行日志模型根本處理不過來。正確做法是在工具內(nèi)部做預處理——聚合、采樣、提取關鍵字段——只返回模型決策真正需要的信息。要有明確的失敗語義。工具執(zhí)行失敗時返回的錯誤信息要能讓模型理解為什么失敗、能不能重試、要不要換方法。不要返回一個裸的異常堆棧。高風險工具要單獨標記。比如執(zhí)行回滾刪除資源這類工具要在定義里明確標注風險等級編排層據(jù)此決定是否需要人工審批。下面是一個工具定義的示例結構用 JSON 表示{ name: query_service_metrics, description: 查詢指定服務在指定時間范圍內(nèi)的核心指標包括響應時間P50/P95/P99、錯誤率、QPS。用于判斷服務健康狀態(tài)和異常程度。, parameters: { service_name: 服務名稱字符串, start_time: 起始時間ISO8601格式, end_time: 結束時間ISO8601格式, metrics: 要查詢的指標列表可選值latency, error_rate, qps }, risk_level: low, returns: 時序數(shù)據(jù)點數(shù)組每個點包含時間戳和值 }4.3 任務規(guī)劃智能體怎么想任務規(guī)劃是智能體的核心能力。給定一個目標它要能拆解出可執(zhí)行的步驟序列。目前主流有兩種模式。一種是先規(guī)劃后執(zhí)行。智能體先一次性把整個計劃列出來然后按順序執(zhí)行。這種模式適合流程相對固定的場景比如標準故障排查流程。優(yōu)點是執(zhí)行效率高缺點是遇到意外情況不好調整。另一種是邊執(zhí)行邊規(guī)劃。智能體每執(zhí)行一步根據(jù)結果決定下一步做什么。這種模式更靈活適合復雜的、不確定的排查場景。缺點是可能陷入循環(huán)或者走彎路。實際落地中我建議混合使用。對于標準化的高頻場景比如常見的幾類告警用預定義的規(guī)劃模板智能體在模板框架內(nèi)做微調。對于罕見的、復雜的場景用自由規(guī)劃模式讓智能體自主探索。這樣既保證了高頻場景的效率又保留了處理長尾問題的能力。規(guī)劃過程中有個關鍵技巧強制智能體顯式輸出推理過程。讓它把我現(xiàn)在觀察到什么、我推測是什么原因、我打算做什么、為什么這么做都寫出來。這不僅能提升決策質量更重要的是讓運維人員能看懂它在想什么建立信任。4.4 上下文管理別讓智能體失憶運維排查往往是個長過程涉及大量信息。智能體的上下文窗口是有限的怎么管理這些信息是個技術活。我的經(jīng)驗是分三層管理。第一層是當前任務上下文只保留當前正在處理的這一步所需的信息保持精簡。第二層是任務記憶把已經(jīng)排查過的假設、執(zhí)行過的動作、觀察到的結果用結構化的方式記錄下來需要時檢索。第三層是長期知識把歷史故障的處理經(jīng)驗沉淀成知識庫供所有智能體共享。這里有個容易踩的坑不要把原始數(shù)據(jù)一股腦塞進上下文。我見過一個實現(xiàn)把查詢到的所有日志都塞給模型結果模型被無關信息干擾推理質量直線下降。正確做法是讓工具層做預處理只把關鍵信息傳給模型。4.5 權限與審批讓智能體有邊界這是整個系統(tǒng)里最不能省的部分。讓 AI 操作生產(chǎn)環(huán)境安全底線必須守住。我的做法是三級權限模型。只讀操作查詢指標、看日志完全放開智能體自主執(zhí)行。低風險寫操作重啟無狀態(tài)實例、清理緩存可以自動執(zhí)行但要記錄審計日志。高風險操作回滾發(fā)布、改配置、動數(shù)據(jù)庫必須人工審批智能體只能發(fā)起申請不能直接執(zhí)行。審批流程的設計也有講究。不要簡單地彈個是否同意的框而要把智能體的完整推理過程展示給審批人——它觀察到了什么、推測是什么原因、打算做什么、預期效果是什么、失敗了怎么回滾。審批人基于這些信息做判斷而不是盲目點同意。還有一點所有智能體的動作都要可追溯。誰發(fā)起的、什么時候、基于什么信息、執(zhí)行了什么、結果如何全都要記錄。這既是安全要求也是后續(xù)優(yōu)化系統(tǒng)的數(shù)據(jù)來源。5. 實戰(zhàn)中的坑智能體運維落地會遇到什么5.1 坑一智能體過度自信做了錯誤的動作這是最危險的一類問題。智能體基于不完整的信息得出了一個錯誤的結論然后自信滿滿地執(zhí)行了修復動作結果把問題搞得更糟。我遇到過一個案例某服務的錯誤率上升智能體排查后發(fā)現(xiàn)是數(shù)據(jù)庫連接池耗盡于是它判斷需要擴容連接池直接修改了配置。但實際上連接池耗盡的根因是上游有個服務在瘋狂重試導致連接被占滿。擴容連接池只是治標而且掩蓋了真正的問題導致上游的重試風暴持續(xù)了更久。應對方法一是強制驗證假設。智能體在形成根因假設后必須找到至少兩個獨立的證據(jù)支撐才能進入執(zhí)行階段。二是高風險動作必須審批。像改配置這種動作無論智能體多有把握都要人確認。三是設置熔斷機制。如果智能體連續(xù)幾次動作都沒有改善指標強制它停下來交給人處理。5.2 坑二工具返回的信息質量太差智能體的決策質量很大程度上取決于它拿到的信息質量。如果工具返回的數(shù)據(jù)又亂又多智能體就會迷失。常見的問題包括日志工具返回了海量無關日志、指標工具返回的粒度太細導致數(shù)據(jù)點過多、拓撲工具返回的依賴關系不完整。這些問題在傳統(tǒng)監(jiān)控場景下可能不明顯因為是人看的人會自己過濾但對智能體來說是致命的。應對方法把工具當成產(chǎn)品來設計而不是接口。每個工具都要考慮模型拿到這個返回結果能不能做出有效決策。該聚合的聚合、該采樣的采樣、該排序的排序。我一般會要求每個工具在返回前做一次信息壓縮把數(shù)據(jù)量控制在模型能有效處理的范圍內(nèi)。5.3 坑三智能體和現(xiàn)有流程兩張皮很多團隊上了智能體系統(tǒng)之后發(fā)現(xiàn)它和現(xiàn)有的運維流程是割裂的。智能體在自己的世界里跑運維人員還是用原來的工單系統(tǒng)、原來的告警群兩邊信息不同步。這個問題的根源是沒有把智能體嵌入現(xiàn)有流程而是把它當成一個獨立的系統(tǒng)。正確做法是讓智能體成為現(xiàn)有流程的增強層——它接收現(xiàn)有告警系統(tǒng)的輸入它的處理結果回寫到現(xiàn)有工單系統(tǒng)它的審批請求走現(xiàn)有審批流。運維人員不需要切換系統(tǒng)就能看到智能體的工作。應對方法在項目初期就梳理清楚現(xiàn)有的運維流程找到智能體可以切入的接口點。不要試圖用智能體替換整個流程而是先在一個環(huán)節(jié)上做增強跑通了再擴展。5.4 坑四成本失控智能體運維的 token 消耗可能遠超預期。一次復雜的故障排查智能體可能要調用幾十次模型每次都要帶上大量上下文。如果沒做好優(yōu)化成本會很難看。應對方法一是分級處理。簡單場景用規(guī)則或小模型處理只有復雜場景才動用大模型。二是緩存復用。相似的排查場景可以復用之前的推理結果。三是上下文精簡。嚴格控制每次調用帶的信息量能摘要的摘要能結構化的結構化。四是設置預算上限。給每個智能體或每個時間段設置 token 預算超了就降級處理。5.5 坑五運維人員不信任、不愿用這是最軟但最要命的問題。技術做得再好運維人員不買賬系統(tǒng)就是擺設。不信任的來源通常有兩個一是看不懂智能體在干什么覺得它是個黑盒二是被智能體坑過某次它做了錯誤動作導致故障擴大。應對方法一是透明化。把智能體的推理過程、決策依據(jù)、執(zhí)行動作全部展示出來讓人能看懂。二是漸進式授權。一開始只讓智能體做只讀操作和建議人執(zhí)行建立信任后再逐步放開低風險寫操作。三是保留人工接管。任何時候運維人員都能一鍵接管終止智能體的動作。四是做好復盤。每次智能體處理完故障都做一次復盤把好的和不好的都記錄下來持續(xù)優(yōu)化。6. 從 AIOps 到 Agentic Operations 的遷移路徑6.1 不要推倒重來如果你已經(jīng)有一套 AIOps 平臺不要想著推倒重來。Agentic Operations 不是替代 AIOps而是在它之上加一層行動能力。你現(xiàn)有的數(shù)據(jù)采集、異常檢測、告警收斂這些能力都是智能體決策的輸入是寶貴的資產(chǎn)。正確的遷移思路是保留 AIOps 的分析能力在其上疊加智能體層。讓 AIOps 繼續(xù)負責看見問題智能體負責處理問題。兩者通過標準接口對接。6.2 分階段推進我建議分三個階段推進。第一階段智能助手。智能體只做只讀操作幫運維人員收集信息、分析問題、給出建議。這個階段的目標是讓運維人員熟悉智能體、建立信任。這個階段大概需要一到兩個月。第二階段半自動處理。智能體可以自動執(zhí)行低風險動作高風險動作走審批。這個階段的目標是驗證智能體的決策質量積累成功案例。這個階段大概需要三到六個月。第三階段自主處理。對于高頻、標準化的場景智能體可以端到端自主處理人只在異常時介入。這個階段的目標是提升整體效率把運維人員從重復勞動中解放出來。每個階段都要有明確的畢業(yè)標準——比如智能體在某個場景下的處理準確率達到多少、人工介入率降到多少才能進入下一階段。6.3 選一個合適的切入點不要一上來就做全場景覆蓋選一個高頻、標準化、風險可控的場景切入。什么樣的場景合適高頻意味著能快速積累數(shù)據(jù)、驗證效果。標準化意味著流程相對固定、智能體容易上手。風險可控意味著即使智能體出錯后果也不嚴重。我一般推薦從告警分診這個場景切入。它的任務是收到告警后自動收集相關上下文判斷告警的嚴重程度和可能原因決定是立即通知人、還是自動處理、還是先觀察。這個場景高頻、相對標準化、風險低最壞情況就是誤判了嚴重程度非常適合作為第一個落地場景。6.4 度量體系怎么建沒有度量就沒有優(yōu)化。智能體運維系統(tǒng)需要一套自己的度量體系。我建議關注這幾個核心指標自動處理率多少比例的故障由智能體端到端處理、處理準確率智能體的處理結果正確的比例、平均處理時長從告警觸發(fā)到問題解決的時間、人工介入率多少比例需要人介入、誤操作率智能體執(zhí)行了錯誤動作的比例、成本每次處理的 token 消耗。這些指標要持續(xù)跟蹤作為優(yōu)化系統(tǒng)的依據(jù)。特別是誤操作率這是安全底線一旦上升就要立即排查原因。7. 我對這個方向的一些真實判斷聊了這么多技術和實操最后說幾句我個人的判斷不一定對但都是從實際項目里摸出來的感受。第一Agentic Operations 不是萬能藥它解決的是行動效率問題不是理解深度問題。如果你的可觀測性數(shù)據(jù)本身就不全、不準智能體再聰明也是垃圾進垃圾出。所以數(shù)據(jù)基礎該補還得補別指望智能體幫你跳過這一步。第二人的角色會變但不會消失。智能體接管的是重復性的排查和執(zhí)行工作但架構設計、容量規(guī)劃、復雜故障的創(chuàng)造性解決這些還是得靠人。運維人員要從操作工轉型成智能體的管理者和訓練者。這個轉型對很多人來說不容易但方向是明確的。第三短期內(nèi)不要追求完全自主。讓 AI 完全自主地操作生產(chǎn)環(huán)境風險和收益不成正比。至少在可預見的未來人在環(huán)上human-in-the-loop還是最穩(wěn)妥的模式。智能體負責 90% 的常規(guī)工作人負責 10% 的關鍵決策這個配比是比較現(xiàn)實的。第四這個方向的門檻比想象中高。它不是接個模型、寫幾個工具就能跑起來的。它需要數(shù)據(jù)、工具、模型、流程、組織多個方面的配合。小團隊如果資源有限建議先從智能助手這種輕量級形態(tài)入手別一上來就搞大而全的系統(tǒng)。第五別被概念忽悠回到問題本身。不管是叫 AIOps 還是 Agentic Operations核心都是用技術手段提升運維效率、降低故障影響。判斷一個方案好不好就看它是不是真的解決了你的實際問題而不是看它用了多新的概念。我見過太多團隊為了追概念上了一堆用不起來的系統(tǒng)最后反而增加了負擔。我在實際項目里最大的體會是智能體運維的成敗技術只占一半另一半是組織和流程。你得讓運維人員愿意用、敢用、會用得把智能體嵌入現(xiàn)有的工作流得建立配套的度量和管理機制。這些軟的東西往往比模型選型、架構設計更決定成敗。如果你正在考慮往這個方向走我的建議是先別急著買平臺、搭系統(tǒng)先花時間梳理清楚自己的運維流程找到最痛的那個點想清楚智能體在這個點上能帶來什么價值。然后小步快跑從一個場景做起跑通了再擴展。這個領域變化很快保持學習、保持務實比什么都重要。