LLM for AIOps：是泡沫還是銀彈？智能運維的爭議、破局與未來

作者 | 付秋偉

大模型浪潮席卷運維領域之際，LLM Agent 既被寄予 “打破協同壁壘” 的厚望，也深陷 “過度炒作” 的輿論爭議。AIOps 概念誕生多年，傳統方案始終難以突破數據、智能的雙重瓶頸，而 “OS + LLM Agent” 新范式的出現，為行業帶來了新的可能。「AI 進化論」第六期直播聚焦 “LLM for AIOps，是泡沫還是銀彈？” 這一核心議題，特邀阿里云智能集團運維總監、龍蜥社區系統運維聯盟主席馮富秋，以及云杉網絡總裁向陽，從行業痛點、技術破局、未來規劃三大維度，深度解析 LLM 與 OS 底座的協同之道。以下為經編輯整理的專家訪談實錄。

1 行業痛點與爭議——“銀彈”幻象下的真實困境

Q1：LLM Agent 被視為 “銀彈” 也被質疑 “泡沫”，行業最突出的爭議和挑戰是什么？

@馮富秋：AI 究竟是銀彈還是泡沫，本質是預期與落地之間的偏差。從正向來看，大模型的語義理解和文本分析能力很強，在意圖識別上比傳統 NLP 先進得多，能極大提升前線問題的歸因分析效率。但反過來，它的推理及深度分析能力相對缺乏。我舉個不恰當的比喻，現在 AI Agent 的能力就像一個 “神棍神醫”，操作系統的日志更像是人的表征，比如發燒，它沒有任何指標，僅憑表象就直接開藥，你根本分辨不出方子的對錯。這就是業界所說的 “幻覺”，看似正確，實則可能完全錯誤，這是很大的矛盾點。

@向陽：這個事本身肯定是革命性的。AIOps 出現很多年，以前靠規則化和數據清洗來做，現在有了大模型的機會，我們在客戶處看到的效果非常驚艷。比如銀行發版，以前要七八個部門及對應的運維廠商駐場，現在人數能急劇降低，但還到不了無人值守，就像自動駕駛一樣，特斯拉 FSD 也沒有完全剝離駕駛員的責任。它存在幻覺和準確率問題，給出的是柔性答案而非基于規則，只要不是基于規則，就有正確率的問題，需要通過 Guardrail 等機制約束行為，讓它隨著使用慢慢成長。總體來講它是一場革命，但我們不能預期它像資深運維工程師一樣不犯錯。

Q2：“OS + LLM Agent” 新范式，是為了解決傳統 AIOps 的哪些痛點？

@馮富秋：AIOps 提了好久但始終沒達到預期，原來的技術要么是規則引擎，要么是小神經網絡。規則引擎對復雜操作系統代碼的靜態分析都做不到，關鍵字匹配效率差，只能處理預先設定的正向案例；小神經網絡需要監督訓練，但運維領域沒有大量高質量的數據，泛化能力不足，準確率甚至不及早期的統計學模型。而生成式模型最大的好處是基于內在知識庫生成，而非過往數據的復現，能在更少人工調教的情況下，產生比傳統神經網絡更好的效果。大模型的泛化能力，是運維場景中非常顯著的特征。

@向陽：以往 AIOps 的痛點主要在兩方面：一是數據，二是智能。數據層面，以前靠插樁、打日志的方式采集數據，第一步就要做痛苦的數據清洗，企業客戶往往要花費半年以上時間；智能層面，基于規則的方案難以突破大量 Corner case。OS 能提供很好的零侵擾視角，看到機器上所有進程的活動，構建完整數據集；大模型則帶來了真正的智能，就像自動駕駛從規則跨越到 FSD 模型，突然有了可能性。現在的模型泛化能力已經足夠好，運維領域更強調獲取關聯性強的實時數據，數據既要完整，標簽標注也要統一。

Q3：阿里云推動這一范式落地的核心訴求是什么？與云杉網絡如何協同？

@馮富秋：阿里云的核心訴求是讓模型真正改善工單處理效率，提升客戶體驗。我們和云杉網絡是龍蜥系統運維聯盟的核心成員，整個 AI 落地過程涉及很多操作系統技術和觀測技術。阿里云提供操作系統底座，保障其堅固可靠，還推出了操作系統控制臺，希望操作系統相關的所有問題都能在上面得到解決。在此基礎上，我們還提供了很多觀測操作系統的探針，云杉網絡會基于這些探針做上層應用和全鏈路容器等生態，雙方強強聯合，共同提升運營效率和用戶體驗。

@向陽：阿里開放操作系統的可觀測性能力，比如 eBPF 技術接口，這是非常重要的基礎能力。我們 DeepFlow 會使用 eBPF 接口實現零侵擾的可觀測性，如果用日志或 APM 的方式，會涉及繁瑣的數據清洗問題，但借助操作系統的 eBPF 能力，就能很好地實現零侵擾的結構化數據采集。尤其是金融這類關鍵行業，在生產環境中不用修改應用代碼、不用重啟，就能憑借操作系統的能力拿到豐富數據，這些數據就是 LLM Agent 的 “燃料”，雙方是相互促進的關系。

Q4：如何保證 LLM Agent 這個 “橋梁” 不會成為系統的單點故障或脆弱點？

@馮富秋：這是個熱門話題，AI 創新的同時，運行平臺的穩定性至關重要。我們從兩個層面保障：一是操作系統層面，保障 AI Agent 的運行環境穩定，通過操作系統控制臺透出能力，讓客戶能看到問題及解決方案；二是研究 AI 觀測能力，診斷 Agent 本身是否出現 HANG（算子掛死）、死鎖、OOM（內存溢出） 等問題，確保其穩定可靠、可診斷。此外，我們還會聯合合作伙伴，實現模型快速裝載、恢復及問答流路由，從節點和彈性環境兩方面共同保障 “橋梁” 的穩固。

@向陽：解決橋梁可靠性要從兩方面入手：一是 AI 基礎設施層面，保障 GPU 卡、顯存、RDMA 網絡等環節及通用算力上分布式調用鏈的可靠性；二是應用層面，通過評估和反思機制持續提升推理質量，解決幻覺問題。我們和阿里合作的 AI 技術設施可觀測解決方案剛剛獲得了最佳案例獎，這正是雙方合作成果的體現。

2 技術破局——降幻覺、強協同的實踐路徑

Q5：面對 “幻覺” 問題，提升可靠性、實現 “降幻覺” 的核心思路是什么？

@馮富秋：要把模型從 “神棍神醫” 變成真正的專家，我們總結了三步法。第一步，提供工具支持，就像醫院的 CT、化驗設備，把操作系統和運行環境的深層次問題提煉出來供模型使用，這就是 AI Agent 中的 “工具”；第二步，制定結構化執行綱要，就像癌癥診療指南，阿里巴巴沉淀了大量運維工單經驗，形成結構化綱要，讓模型有章可循，這對應 AI Agent 的 Planning；第三步，持續迭代優化，AI 答復不準確時，客服團隊會回收案例，對模型進行監督訓練或強化訓練，讓模型積累經驗、不斷成長。

@向陽：我們的策略也是三步走。第一步，以基于操作系統的觀測數據為主干，解決數據完整性和結構化問題，尤其在金融場景下，能應對 APM 和日志參差不齊的情況；第二步，補齊數據關聯關系，比如在故障診斷場景中，把銀行交易的不同流水號串聯成調用鏈，這有點像把稀土冶煉成合金；第三步，基于狀態機生成動態思維鏈，避免 Workflow 失控，同時在診斷和巡檢報告中列出完整證據鏈，方便金融等嚴謹行業做審計回溯，再通過評估反思機制讓智能體持續學習。最終解決幻覺問題。

Q6：將 eBPF 采集的底層數據與 LLM Agent 決策邏輯打通，最難的環節是什么？如何平衡數據豐富性與性能損耗？

@馮富秋：核心難點是權衡數據采集的多與少。采集多了，CPU、內存、存儲開銷會非常大，出現問題時也分不清該關注哪個指標；采集少了，又無法準確定位問題。這就需要與大模型結合，以問題和場景為驅動，整合最優的采集方案，甚至通過動態開關，在開銷可控的情況下達成預期效果。

@向陽：平衡數據豐富性與性能損耗，我們做了兩件事。一是給 eBPF 常規數據打統一標簽，標注云資產、容器資產、業務資產，消除數據 “方言” 差異，比如避免 APM 和日志中對同一服務的命名不一致；二是層次化遞進獲取實時數據，生產環境中長期打開黃金指標、調用鏈等低開銷觀測數據，當智能體發現數據不夠時，借助 eBPF 的熱加載能力，通過 Agent 的動態思維鏈，在故障現象丟失前快速補充實時數據，實現高效平衡。

Q7：LLM Agent 適配企業內網環境時，面臨哪些安全合規挑戰？如何建立安全護欄？

@馮富秋：客戶最關心兩個尖銳問題：一是數據安全，擔心生產數據泄露，我們推出了 Confidential AI 雙向可信方案，數據在完全可信的沙箱內運行，阿里云和客戶雙方都看不到對方數據；二是答復可靠性，擔心按 AI 結論操作失敗后的責任歸屬，我們采取人機協同模式，AI 結論先供客服和客戶參考，不直接強制執行，通過持續的監督訓練提升模型可信度，逐步推進落地。

@向陽：生產環境的故障復雜度遠高于實驗室，首先要拉齊客戶預期，讓其理解預期不是 100%；其次要提供完整證據鏈，智能體的專業廣度可能超過單人，工程師需要通過證據鏈理解結論由來；合規層面，任何操作都需要人在循環中承擔責任，關鍵操作需人工審批，同時將診斷和恢復效果沉淀為反思數據集，持續優化模型，就像運維老司機積累經驗一樣，讓智能體越用越強。

3 未來啟示——生態共建與范式革新

Q8：未來吸引更多開發者和企業參與 “OS + LLM Agent” 生態，會側重哪些方面？

@馮富秋：生態建設主要聚焦三個維度：一是阿里云聚焦操作系統核心能力，以 MCP 方式開放出來，讓所有模型都能結合使用，就像提供專業診療設備供各方使用；二是依托龍蜥運維聯盟構建溝通橋梁，和云杉網絡等伙伴發布聯合解決方案，堆疊各方能力；三是計劃推出脫敏后的運維工單標準測試集，建立行業基準，讓所有 Agent 都能在上面測試，解決運維行業缺乏訓練集和測試集的痛點，促進行業良性發展。

@向陽：主要有兩個方面：一是通過 DeepFlow 開源社區降低 eBPF 技術使用門檻，解決其內核適配、技術門檻高的問題，同時在開源社區開放 MCP Server 等能力，讓開發者能獲取生產環境的剖析數據和調用數據；二是作為大模型和操作系統的用戶，積極融入阿里這樣的大生態，與行業伙伴共同推進技術落地。在分工明確的企業中，Multi-Agent 是必然趨勢，我們會按場景化實現智能體能力，且不同場景的智能體之間會相互交互，形成閉環。

Q9：LLM for AIOps 對運維領域有哪些啟發？LLM Agent 會成為服務器操作系統的 “標配” 嗎？

@馮富秋：LLM Agent 未來一定會成為服務器操作系統的標配。現在開發者從 IaaS 到 FaaS、MaaS，越來越聚焦客戶價值，不用關注底層環境，但系統出問題時，運維會陷入困境，甚至被拉回基礎操作層面。未來運維應該是 “零運維” 模式，系統能自主發現、分析、推送問題，人只需要做決策授權。LLM Agent 正是實現這一目標的關鍵，能極大改善運維體驗，讓運維人員從基礎操作中解放出來。

@向陽：我也認為 LLM Agent 會成為操作系統的標配。我們的愿景是讓 DeepFlow 跑到每一個操作系統上，目標是三年內國內每年新增服務器的 1% 都能運行 DeepFlow。未來每臺服務器可能都會標配 GPU，本地擁有算力解決本地問題。另一方面，云作為一個分布式操作系統，也需要 LLM Agent 和可觀測性能力保障穩定。可觀測性和控制論最早成功解決飛船登月的問題，因此面對復雜的分布式操作系統運維場景，LLM Agent 和觀測數據能力肯定是必備的。

Q10：落地 LLM for AIOps 最關鍵的是什么？有什么建議給到行業？

@馮富秋：首先要明確，LLM for AIOps 既不是銀彈也不是泡沫。它目前的推理能力和知識結構還不足以解決所有復雜問題，大家要做好預期管理，這個領域還有很長的路要走。但它也不是泡沫，大模型確實能改善客戶體驗、精準理解客戶意圖，還能在模糊問題中做出取舍 —— 這種取舍能力是傳統程序不具備的。希望行業各方共同參與，客戶不用抱過高預期，但可以適當擁抱技術，讓技術從泡沫中提煉精華，最終實現 “零運維” 的效果。

@向陽：最關鍵的是 “開始行動”。我們看到它是一場革命，需要勇敢邁出第一步，同時要避免上一代 AIOps 的錯誤 —— 上一代 AIOps 的數據多來自插樁和日志，數據清洗過程異常痛苦，不少創業公司因此失敗，交付團隊也可能陷入客戶環境的泥沼。選擇 “OS + LLM Agent” 的正確方向，走順數據采集和規整的第一步，后續 Agent 的效果會在持續使用和評估反思中不斷優化、加強。

4 結語：智能運維的進化，始于爭議，成于協同

LLM for AIOps 的行業爭議，本質是新技術落地時預期與現實的必然碰撞。LLM for AIOps 不是解決所有問題的 “銀彈”，卻用語義理解、跨部門協同的核心能力，打破了傳統 AIOps 的固有瓶頸；雖然因 “幻覺” 問題仍面臨著 “泡沫”相關的質疑，但在 OS 底座的堅實支撐、eBPF 技術的精準賦能，以及持續的技術迭代中，正不斷走向完善。

從技術落地到產業普及，這場變革的核心，在于 “協同”——阿里云與云杉網絡的生態協同，OS 底座與 LLM Agent 的技術協同，大模型與傳統規則、小模型的分工協同，以及人與機器的決策協同等。當生態層面的技術壁壘逐步消融，當數據與智能的閉環持續構建，當行業標準逐步完善，LLM Agent 有望從 “爭議焦點” 逐步成為 “運維標配”，進而讓 “端著咖啡做運維” 的夢想照進現實。

欄目介紹：

在 AI 重塑產業格局與國產化替代加速推進的雙重浪潮下，《AI 進化論：智算時代 OS 的破局之路》以云、AI、安全等技術與服務器操作系統如何融合演進為主線，聚焦服務器操作系統在智算時代的進化之路，特邀學術權威、行業專家、客戶代表圍繞原生智能、原生安全、軟硬協同等熱點議題展開深度對話，并以阿里云服務器操作系統為例，系統性解析其技術架構、演進之路及場景應用價值，以期給行業帶來啟示與借鑒。