突破泛化瓶頸：阿里云智能運維 Agent 評測體系實踐

演講嘉賓｜李也 博士

編輯｜Kitty

策劃｜QCon 全球軟件開發大會

大模型 Agent 在智能運維場景落地時常常遇到“做 demo 容易，泛化難”的問題。在 2025 年 QCon 全球軟件開發大會（上海站） 上，阿里云云原生可觀測算法專家，香港中文大學計算機專業博士李也作了題為 “突破泛化瓶頸：阿里云智能運維 Agent 評測體系實踐”的演講，他深入介紹了如何利用評測集驗證并提升基于 Agent 的智能運維算法泛化性的實踐。

預告：將于 4 月 16 - 18 召開的 QCon 北京站設計了「Agent 可觀測性與評估工程」專題，本專題立足架構與工程實戰，系統探討如何構建面向 Agent 的全鏈路語義觀測體系，實現對意圖決策、中間狀態與工具調用的可追蹤、可回放、可診斷；同時通過覆蓋離線評測與在線實時度量的評估體系，對任務成功率、路徑質量、輸出穩定性與效果進行持續量化，驅動 Agent 從“基于經驗的盲目調優”轉向“基于數據驅動的持續演進”。敬請關注。

以下是演講實錄（經 InfoQ 進行不改變原意的編輯整理）。

今天我帶來的分享題目是《突破泛化瓶頸：阿里云智能運維 Agent 評測體系實踐》。我所在的團隊專注于智能運維，我們的口號是“讓天下沒有難查的故障”——這句話借用了阿里電商“讓天下沒有難做的生意”的句式，但故障排查至今仍遠未變得輕松。就在不久前，一家海外友商就爆發了一次重大故障；倘若“天下已無難查故障”真的成為現實，這類事故或許就能被提前化解。

1 智能運維泛化之痛

我們深耕智能運維多年，真正的痛點究竟在哪里？為何“天下無難查故障”仍停留在口號？首先，我把自己這些年踩過的坑、流過的汗，濃縮成“泛化之痛”的心路歷程。最早，我們像所有人一樣，從“規則 + 算法”起步：先寫死一條條規則，再讓算法在規則的縫隙里補位。大模型浪潮到來后，我們又忙著搭上下文工程、跑大模型工作流。最近，智能體（Agent）概念爆火，我們自然也沒缺席，或多或少都試過幾輪。

然而，無論規則、算法還是大模型，都繞不開“泛化”這道坎。日常運維里，我們依舊依賴閾值：CPU 超 80 % 就告警，磁盤剩余 10 % 就紅燈——這種做法簡單直接，也確實救過急。但經驗告訴我們，固定閾值像一把刻度不變的尺子，量不準千變萬化的系統。同一臺機器 80 % 是常態，換一臺就可能異常；昨天有效的日志關鍵詞，今天系統升級后消失，告警立刻啞火。于是，我們寫下一串又一串 if-else 規則：若網絡斷開且下游大面積告警，則判定為網絡故障。

后來，我們做算法的同事登場，承諾用“動態基線”取代死板閾值：不再 80 % 一刀切，而是讓曲線自己“長”出上下界，還貼心地剔除節假日、周末周期。聽上去很美，用起來卻棘手——不同指標對周期、敏感度要求各異，調參調到懷疑人生。日志側也一樣：模板提取算法能自動把相似日志歸堆，卻常把 IP 地址固化進模板，或把常量錯當變量，結果誤報比手配規則的方案還多。再激進一點，有人提出“全自動規則挖掘”，聲稱無需人工寫 if-else。現實是，標注數據要人堆，算法假設又多，產出的規則很可能不如手寫的那幾行規則魯棒。

剛才說到算法難以泛化，那么大模型是否就能破局？在座或許有人試過：把線上 Dashboard 截圖、診斷頁面、日志和監控畫面一并丟給大模型，讓它“看圖說話”。初次體驗確實驚艷——昔日只有老專家才能一眼識別的異常，如今模型竟也能侃侃而談，甚至直接給出根因。日志再多，它也能梳理得頭頭是道，仿佛通用智能真的降臨。

然而用得久了，便會發現“幻覺”如影隨形。這不是 bug，而是大模型自帶的 feature：它會把一次普通的 GC 增多臆斷為內存泄漏，若按此排查，只會南轅北轍。GC 上升或許只是剛升級的 Java 版本在重新調整策略。又如日志里明明沒有 500 錯誤，只因提示詞里出現了“錯誤”二字，模型便一口咬定“肯定有 500”，任你如何糾正，它都固執己見。

倘若再往前走一步，用所謂“大模型工作流”把診斷過程編排成固定節點，局限性同樣明顯：節點一旦寫死，便難以隨場景變化。更棘手的是，模型并不總聽指揮。過去我們 debug 傳統代碼，if-else 邏輯清晰，錯了總能定位；如今卻像在馴服一匹烈馬，你叮囑它“只讀勿寫”，它卻可能順手刪庫；同事用 Cursor 生成腳本，一不留神確認了 rm .*，半天成果瞬間歸零。實驗也表明，即便是最前沿的模型，當指令超過兩百條時，遵循率也會急劇下降。

大模型 Agent 看似無所不能，實則把舊疾與新病一并打包：幻覺、提示詞不服從依舊存在，又額外添加了“自主決策”帶來的麻煩。JSON 少一個引號、SQL 多一個逗號，它便原地卡死；陷入死循環后，會無休止地“分析—探索”，卻遲遲給不出終點。要把 Agent 做扎實，必須為其配備成體系的工具鏈，這本身就需要大量時間與精力。

對我而言，最難受的是失控感——按下葫蘆浮起瓢。我們試著收緊韁繩，要求“僅基于證據作答”，它立刻變得過度保守，一句“無法判斷”便不再行動；限定“只能使用內部知識庫”，遇到稍有外延的問題便拒絕合理泛化。再讓它嚴格按模板輸出，它竟能生成格式完美卻毫無價值的 Mock 數據，令人哭笑不得。

2 高質量的評測集的重要性

既然“泛化性”被反復提起，那我們究竟在談論什么？坦率地說，在缺乏明確邊界之前，我們甚至說不清自己希望模型泛化到哪些場景。于是，我斗膽提出一個“暴論”：唯有先構建一套評測集——一塊可復現、可度量的“試金石”——泛化性才會從抽象口號變成可觸摸的目標。

他山之石，可以攻玉。代碼生成、數學推理、科學問答等社區早已鋪就大量公開 benchmark；一旦基準確立，模型能力便在這些榜單上肉眼可見地躍升。數學定理證明、LeetCode 做題，過去遙不可及，如今大模型捷報頻傳。這讓我們不禁設想：倘若智能運維也能擁有同樣嚴謹的評測體系，是否就能復現“刷榜即進步”的良性循環？

在回答“評測集到底有什么用”之前，我更想先描述一種在沒有評測集時幾乎必然出現的場景，它聽起來像故事，卻每天都在真實地上演。

某日，高層突然決定要做一次 AIOps 演示：線上數據庫被打爆，事后發現大量慢 SQL 的根因，源于某次代碼變更引入了長連接。老板只給一句話：“把根因定位做成 Demo，下周演示”。如果目標只是讓屏幕上的流程跑通，我們總有辦法“交卷”：先寫一條規則，把“長連接、CPU 飆高、活躍線程數激增”等現象全部 if-else 串起來；再套一層算法殼，讓曲線看起來有“智能”；最后用大模型工作流把巡檢、日志檢索、知識庫問答封裝成 Agent，把前因后果寫進 Prompt，一個光鮮的 Demo 便宣告誕生。老板若說“一個不夠，再來五個”，我們只需把同樣的套路復制粘貼，換幾組關鍵詞即可。可一旦現場數據稍有偏差，整套演示便可能當場穿幫，因為沒人知道這套“萬能腳本”在真實世界到底能跑多遠。

倘若沒有評測集，僅憑 Demo 驗證，老板的任務確實可以快速完成：只要針對“變更導致連接池耗盡”這一單一場景，規則、算法或大模型工作流都能交出漂亮答卷。然而一旦場景換成“Java 版本升級引發 GC 陡增”，同樣的方法便可能失靈——大模型時而答對，時而答錯，成敗全憑運氣。所謂“泛化”不過是一句空話。

評測集的價值，正在于把“泛化”從口號變成可度量的指標。它首先像一面鏡子，照出任何 AIOps 方法的邊界：Demo 中光鮮的流程，可能在評測集上寸步難行。其次，它又是一把磨刀石，讓優化有跡可循。最樸素的實踐，是把內部評測集鋪開到日常可能出現的各類故障，再以“打補丁”的方式增補規則，手工消解沖突，直到規則集能覆蓋九成以上案例。

若再往前一步，算法工程師可依據評測集調參；大模型工作流可據此重塑節點與提示詞；Agent 開發者則能看清缺哪些工具、需何種腳手架，甚至直接拿評測集里的標注數據做監督微調或者強化學習。有了評測集，我們做的就不再只是實驗室里的“玩具”，而是可以放到成千上萬真實線上故障里去驗證和打磨的“正式產品”。

評測集的價值貫穿智能運維的全生命周期。開發階段，我們只需抽取少量典型樣本，就能快速驗證算法或數據采集鏈路是否跑通；進入評估與調優環節，同一套評測集又成為衡量改進效果的標尺。上線后，隨著真實故障不斷匯入，評測集持續擴容，形成“越用越真、越真越用”的正反饋。若公司愿意開源，社區便可可以共同豐富這套基準，讓評測集像雪球一樣越滾越大。

3 如何構建高質量的評測集

既然 benchmark 的重要性已成共識，下一步便是“如何落地”。要回答這個問題，先得對軟件系統做一次簡潔而完整的抽象。在我看來，任何系統都可被拆成四層：最上層是輸入，即持續涌入的 workload 與請求；中間是代碼與配置，它們共同決定業務邏輯；再往下是計算、存儲、網絡等系統資源；若系統帶狀態，歷史數據和狀態也會影響軟件系統的運行。最終，所有處理結果匯聚為輸出。所謂故障，正是輸出與預期發生偏離。

因此，一份高質量的 benchmark 必須盡可能覆蓋上述全部維度：輸入的多樣性、代碼 / 配置的多樣性、資源瓶頸的多種形態，以及狀態演化帶來的長尾異常。只有把這些“面”都考慮到，評測集才能真正成為衡量智能運維方法泛化能力的標尺。

我們回頭審視最初那個“代碼變更導致數據庫線程打滿”的案例：輸入流量本身并無異常，真正的變量是代碼變更；新代碼在運行過程中耗盡了數據庫線程這一關鍵資源，最終表現為大量慢 SQL，拖垮整個系統。在這個故障案例中，我們可以把這一鏈條拆成“根因—傳播路徑—結果”三節點。類似地，只要我們能用同樣方式拆解所有潛在故障，并確保 benchmark 覆蓋每一類根因、每一條傳播路徑、每一種結果，就能說這套評測集的“覆蓋度”是完整的。

覆蓋度只是第一關，第二關是“真實度”。首先，系統架構必須真實。我們注意到，不少學術 benchmark 直接拿開源項目“造”場景，與生產環境差距甚遠。其次，流量必須真實。有些 benchmark 的流量靠“拍腦袋”模擬；而真正貼近業務的流量，通常只有一線運維團隊才擁有。再次，各組件的可觀測數據也必須真實。很多 benchmark 為了突出異常，直接把 CPU 利用率從 0 % 拉到 100 %，或編造一條看似嚇人的日志，而線上系統的曲線往往平緩得多，日志也沒那么戲劇化。唯有把這些細節都還原，benchmark 才能經得起真實世界的考驗。

既然目標已定為“既真實又全面”，下一步便是落地路徑。我們初步梳理出三條互補思路，并嘗試取長補短。

1. 第一條最理想：直接采集線上真實故障。每當系統異常，立即抓取當時的可觀測數據快照，并完整記錄前因后果。為降低人工成本，可借助大模型做初稿標注，但經驗告訴我們，完全依賴模型并不可靠——若大模型已能精準歸因，便不會仍有“難查故障”。因此，最終仍需人工復核與修正。

2. 第二條借鑒學術界常用的故障注入法：在開源系統里植入缺陷，快速生成案例。更進一步，可借用阿里云內部的演練環境——一個按比例縮微的真實集群——回放真實流量并注入故障，從而復現部分線上場景，兼顧成本與逼真度。

3. 第三條則是構建可運行的模擬系統。該系統僅對輸入輸出做輕量級 Mock，卻保留真實調用鏈路與資源消耗特征，可低成本、大批量地生成故障樣本。

上述三種手段在“覆蓋度”與“真實度”上各有利弊。我們的實踐是：先用真實案例打底，哪怕故障現場沒有被保留下來，也要盡量靠資深專家的記憶將其還原；若線上難以復現，則到演練環境或開源系統里做故障注入；若仍受限于環境差異，再退而求其次，用模擬系統補充邊緣場景。通過層層遞進，力求讓評測集既貼近生產，又足夠豐富。

關于案例的生成方式，我們已對“真實性”有了直觀感受；接下來需要厘清“覆蓋度”究竟指什么。在阿里云，我們使用 UModel 對可觀測數據做統一建模：所有指標、日志、鏈路追蹤被歸攏到同一張以實體為中心的圖里——應用、容器、主機、數據庫等皆是節點，各自的監控項、日志字段 作為屬性掛在節點上。下面這張大圖便是我們可觀測數據的全景 Schema。

因此，只要故障案例能觸及圖中每一類實體、每一條屬性，我們便認為覆蓋度足夠。衡量方法也簡單：從實際故障出發，若每個真實異常都能在評測集中找到對應樣本；同時，所有被采集的可觀測字段（既然我們決定收集，就默認其有用）都被至少一個案例觸發，那么這套 benchmark 的完備性即可得到驗證。

4 阿里云 AIOps 評測集 (持續發布)

一套高質量評測集是討論“泛化性”的前提，也是持續優化各類 AIOps 方法的抓手；同時，我們也摸索出一套“既真實又全面”的建設思路。

阿里云對 AIOps 及配套評測集均作長期投入。我們將沿著前文所述路線，持續采集并脫敏更多真實故障，逐步擴大覆蓋范圍，并把可開源的部分全部開放。目前，我們已接入三類數據源：開源系統、內部演練環境以及線上生產系統；所有數據統一存入阿里云云監控 2.0 與日志 / 指標存儲，任何持有阿里云賬號的用戶均可免費訪問。對于需要主動注入的維度——請求流量、系統資源、代碼變更及歷史狀態——我們主要使用 ChaosBlade 與 ChaosMesh 等混沌工程工具。實踐中發現，這些工具偶爾會帶來副作用：例如注入 CPU 故障可能連帶推高內存，內存泄漏也可能觸發 CPU 飆高。因此，若今后在由故障注入產生的評測集中看到類似現象，請多留意，真正的根因未必是注入點本身。相較之下，直接采集線上可觀測數據得到的案例，在真實性上仍無可替代。

目前，我們已沉淀 2 000 余個原始案例，經脫敏與校驗后發布 200 余個，并仍在持續擴充。這套評測集可與學術界同類基準（如 Open-RCA）互補使用——基準越多越好。若某種方法在多套評測集上均表現穩健，其可靠性便不言而喻。

5 基于評測集的智能運維 Agent 能力提升實踐

前面我們反復論證了評測集的重要性，也介紹了如何構建它。接下來，大家最關心的恐怕是：這套評測集到底有沒有帶來實打實的提升？

規則 + 算法在已收集的 3000 余個真實樣本上，自動規則挖掘算法在訓練集里取得了接近 100 % 的準確率與召回率。雖然存在過擬合風險，但至少說明算法能夠充分擬合已知故障模式。

大模型工作流以“正則表達式生成”這一高頻需求為例：裸用通用大模型時，正則可解析率不足 50 %，字段抽取完整度也徘徊在 50 % 左右。我們針對評測集里的 bad case 設計了一條專用工作流，把上下文、日志樣例、目標字段一并喂入，再輔以校驗與回退節點，最終把可解析率提升到 98 %，字段完整度提升到 95 % 以上。

大模型 Agent基于同一批評測集，我們持續調優腳手架與工具鏈。在首批 200 余個已驗證案例中，根因召回率達到 87.5 %，定位準確率超過 80 %。這些數字并非刻意刷榜，而是日常迭代的自然結果；如果評測集本身覆蓋全、場景真，刷榜也就有了實際意義。將評測集里已標注的根因診斷結果用于監督微調和強化微調，排序任務的準確率已穩定在 80 % 以上。

聽到這里，大家或許仍覺抽象。做個總結 -- 我只希望大家記住三件事：

第一，沒有評測集，泛化性就無從談起，生產環境只能“開盲盒”。第二，構建高質量評測集有方法論可循：真實場景優先，覆蓋度兜底，持續迭代。第三，阿里云正按這套方法論建設并開源評測集，同時用它驅動算法、工作流和 Agent 的持續改進。

最后，回到我們的口號——“讓天下沒有難查的故障”。第一步，便是把天下可能出現的故障悉數納入評測集。愿今天的分享能讓各位有所收獲。謝謝大家。

演講嘉賓介紹

李也，阿里云云原生可觀測算法專家，香港中文大學計算機博士，在智能運維和數據驅動的決策方向有近 10 年科研和落地經驗。主導的異常檢測和根因定位等 AIOps 算法在阿里云大規模落地。在 ASPLOS、SIGMOD、WWW、VLDB、TKDE、TON 等頂會頂刊發表過多篇 AIOps 算法論文，并在這些國際會議上做報告。目前他專注于大模型 Agent 及其強化學習在智能運維場景的落地。

會議推薦

OpenClaw 出圈，“養蝦”潮狂熱，開年 Agentic AI 這把火燒得不可謂不旺。在這一熱潮下，自托管 Agent 形態迅速普及：多入口對話、持久記憶、Skills 工具鏈帶來強大生產力。但這背后也暴露了工程化落地的真實難題——權限邊界與隔離運行、Skills 供應鏈安全、可觀測與可追溯、記憶分層與跨場景污染、以及如何把 Agent 納入團隊研發 / 運維流程并形成穩定收益。

針對這一系列挑戰，在 4 月 16-18 日即將舉辦的 QCon 北京站上，我們特別策劃了「OpenClaw 生態實踐」專題，將聚焦一線實踐與踩坑復盤，分享企業如何構建私有 Skills、制定安全護欄、搭建審計與回放機制、建立質量 / 效率指標體系，最終把自托管 Agent 從可用的 Demo 升級為可靠的生產系統。