歐洲科學院院士劉向陽：許多企業的數字化底座，配不上今天的AI發展 | GAIR 2025

2025年12月12-13日，第八屆GAIR全球人工智能與機器人大會在深圳·博林天瑞喜來登酒店正式啟幕。

作為AI 產學研投界的標桿盛會，GAIR自2016年創辦以來，始終堅守“傳承+創新”內核，始終致力于連接技術前沿與產業實踐。

在人工智能逐步成為國家競爭核心變量的當下，算力正以前所未有的速度重塑技術路徑與產業結構。13日舉辦的“AI 算力新十年”專場聚焦智能體系的底層核心——算力，從架構演進、生態構建到產業化落地展開系統討論，試圖為未來十年的中國AI產業，厘清關鍵變量與發展方向。

會上，歐洲科學院院士、美的首席信息安全官兼軟件工程院院長、IEEE Fellow、IET Fellow、ACM杰出科學家劉向陽，在大會上帶來題為《中立云：賦能AI與AI賦能的多云統一數字化底座》的主題演講，分享了美的在企業級數字化與AI實踐中的真實路徑。

深耕數字化與信息安全領域的劉向陽，曾任職螞蟻集團首席科學家、美國高校教授，如今在美的集團主導數字化底座與信息安全建設。他敏銳指出，當前多數企業在 AI 落地中面臨 “數字化底座薄弱” 的核心問題——若將數字化比作建筑，底座如同地基，直接決定 AI 價值的上限。

圍繞“地基”該怎么打，他直指企業常見的兩條路徑：自建數據中心，或全面上公有云。前者看似成本低，但現實往往事與愿違，“如果一個CIO真能把數字化底座建得非常好，那他其實已經可以去開一家公有云了。”在他看來，多數企業的自建底座仍停留在上世紀90年代的虛擬化技術，存在技術老舊、產品雜亂、穩定性和安全性難以保障的問題。

而公有云看似先進，卻又帶來了另一組難題：多云幾乎是大型企業的必然選擇，美的目前使用的云超過8朵，但彼此之間互不兼容，且遷移難、聯動難，最終形成云孤島、數據孤島。在業內，一個數字化應用的跨云遷移通常需要至少半年以上。

正是這樣的背景下，劉向陽帶領美的選擇了一條“自建云能力”的路徑。他詳細拆解了美的如何構建一體化云架構，打通數據中心與多公有云資源，同時落地全棧監控、自動化運維、安全防護等核心能力，為企業數字化轉型提供可復用的實踐方案。

以下是劉向陽演講的精彩內容，雷峰網作了不改變原意的整理與編輯：

一、規模≠能力，底座技術代差侵蝕企業數字化ROI

感謝大會的邀請，非常高興有這個機會跟大家做技術交流。我來自美的集團，在美的集團負責兩塊業務，一是集團的數字化底座，二是集團的信息安全。在加入美的之前，在螞蟻集團做首席科學家，再之前在美國德州大學奧斯汀分校計算機系博士畢業，又在美國高校做了十多年教授。

首先簡單介紹一下美的集團，大家熟悉的是它的To C業務，它現在每年有3000多億的To C業務，實際它還有1000多億的To B業務，包括樓宇科技、數據中心制冷，還包括工業技術、機器人與自動化、醫療、物流等等。例如，華為最大的貴陽數據中心，機房制冷就是美的樓宇科技提供的，根據美國商業專利數據庫的數據，美的專利在中國企業中排行第一，在世界排行第四，連續十幾年是世界500強，也被評為全球最有價值科技品牌Top100。

本次大會的主題跟AI相關，但實際上AI在很多企業并沒有起到大家所預期的價值。AI的基本功是數字化，數字化的基本功是數字化底座。如果把數字化比作一棟樓的話，數字化底座就像地基，地基決定著你的樓能蓋多高。

數字化底座的建設一共有兩個選項，一個是在自己的數據中心建設，另一個是在公有云上建設。

在自己的數據中心中建設，好處是什么？成本低。跟公有云相比，公有云是你在數據中心建設成本的6~10倍。在自己數據中心建設數字化底座的缺點是很難搞好，它有很多原因：

首先，技術非常老舊，很多底座都是誕生于90年代的技術，跟現在公有云的基于云原生的技術體系相比有代際差距。

其次是產品雜，大家買的軟件有商用的、有開源的，互相之間無法聯動，很多想實現的功能都實現不了。需要注意的是，所有開源都不是直接給企業用的，都不是企業版。大多數企業駕馭不了開源，因為所有的軟件都有bug，包括開源，當系統出現故障的時候，絕大多數企業無法定位bug、更沒有修復開源軟件bug的能力。

技術差、產品雜給企業帶來的是整個數字化底座的穩定性和安全性很差。大的故障都是架構和體系的問題。信息安全不是一個信息安全團隊就能搞好的，需要整個團隊和公司的配合，尤其是基礎設施的配合。舉個例子，絕大多數企業的數據中心只有物理網絡，沒有虛擬網絡，這會導致一個很嚴重的問題是，你的業務之間隔離不開。在一個數據中心里，用防火墻只能做大區域的隔離，比如做DMZ和內網的隔離、或者數據中心與數據中心之間的隔離，但一個數據中心里業務系統可能有幾十上百個，這些業務系統之間無法隔離，一個系統被攻破，就全軍覆沒了。

另外，技術差，產品雜還給企業帶來效率低下，例如每個團隊都要搭建運維，比如中間件、數據庫等。

用公有云，不僅成本高，還會涉及多云的問題，像美的，我們用了8朵云。為什么會用多個云？有很多原因，不同部門可能選了不同的云，包括公司在不同的歷史階段也可能選擇了不同的云，還有企業出海，你公司去海外開展業務的地方，很可能你之前用的公有云在當地沒有開服，那你只能用另外一朵公有云，大家要知道，沒有任何一個公有云在全世界任何地方都開服。

但多云帶來的問題，一是適配很難：每個公有云都是不兼容的，從一朵公有云遷移到另一朵公有云，需要做大量的業務改造，業界普遍情況是至少需要半年的改造時間，如果你半年內能改造完，就已經非常好了。其次，聯動很難，會出現云孤島問題、數據孤島的問題。另外，多云也給運維帶來高復雜度，因為每朵公有云都不一樣，你的運維團隊需要一個一個去熟悉。

二、GPU利用率翻五倍、運維工單九成自動化，美的做了什么？

我們以自己的數據中心為主，也用很多公有云，所以以上這些問題和挑戰，美的都有。那美的怎么解決這些問題呢？我們建設了一整套的云計算能力，這套云計算能力既可以部署在一個企業自己的數據中心，也可以部署在這個企業所使用的公有云上。本地的數據中心，企業直接買裸金屬服務器就可以；在公有云上，企業買虛擬機即可。也就是說，數據中心的裸金屬之上、公有云的虛擬機以上，都是我們的整套云計算軟件。

這一架構對企業來說有什么好處？

首先，自有的數據中心擺脫了傳統計算虛擬化的陳舊模式，升級為云原生技術體系，跟主流公有云是一樣的技術體系。

其次，云下數據中心和云上公有云之間、以及不同公有云之間，就完全是一套技術體系了，應用軟件從自有數據中心遷移到公有云、或從一朵公有云遷移到另一朵云上，不需要任何遷移改造。

第三，對一個企業所擁有的全部公有云上的資源及全部數據中心上的資源，我們是操作系統級別的統一納管統一調度。上層業務系統不需要感知底層部署環境，無論是 AWS、阿里云，還是其他硬件設施，體驗完全一致，真正實現了“全球一張網，全球一朵云，一個企業一朵云”。

在統一的云底座之上，我們構建了多層級的技術平臺矩陣：包括計算存儲和網絡的IaaS平臺、容器平臺、服務治理、API網關等的應用管理PaaS平臺、AI算力平臺。包括自動化運維平臺和全棧監控平臺的運維平臺；大數據引擎平臺與大數據研發平臺；數據庫管理平臺、數據庫引擎平臺。此外，還自研了一套研發效能平臺，和集統一身份安全平臺、四合一終端安全平臺（包括零信任、準入、 數據防止泄漏DLP、桌面管理）、自動化攻擊模擬平臺、機密管理平臺于一體的安全平臺。

四年前，我剛加入美的時候，我們的底座技術架構還處于一堆商用產品的“混搭”狀態，之后逐步進行自研替換，例如我們自研的企業版Linux操作系統替換了RedHat，自研的軟件負載均衡替換了F5設備，自研的全棧監控平臺替換Dynatrace，自研的大數據研發平臺替換Databricks，自研的大數據引擎平臺替換了Cloudera CDP，自研的零信任替換了Fortinet VPN，自研的DLP替換了McAfee DLP，自研的準入替換了Forescout準入，自研的桌管替換了聯軟的桌管。對業務來講，這一系列升級可以實現最快速的響應——無論部署在公有云還是本地數據中心，都可以做到一鍵部署、全球統一、無縫遷移。

接下來，我對各個部分稍微展開進行介紹。

對AI算力平臺，如果大家買了GPU的卡，沒有這個算力平臺，GPU利用率可能就只有10%；有了這個算力平臺，至少可以提升4~5倍，相當于降本4~5倍。這套軟件下面，支持異構的卡，國內外的卡都支持。而且，我們的AI算力平臺既可以部署在本地的數據中心，也可以部署在公有云上。當本地數據中心的資源不夠時，任務會自動彈到云上，不需要任何人的介入。

同時，我們還搭建了一套AI網關。在美的，AIGC能力已經內嵌在每個應用系統里，而且很多應用系統都允許終端用戶選擇用哪一個大模型。試想，用n代表應用系統數量，用m代表大模型個數，我們就有n乘以m個大模型對接。這些模型對接有很多像安全審計、額度控制、計量計費等共性能力。我們把這些共性的能力全部集成到我們的AI網關中，大幅降低重復開發。

我們打造的自動化運維平臺，讓美的的系統與網絡運維工作實現了95%的自動化運維率 —— 即95%的運維工單無需人工介入，審批流程結束后即可自動完成全流程操作，覆蓋物理機管理、網絡配置、防火墻管控、數據備份、腳本執行、作業調度及CMDB同步等全場景。

以防火墻規則管理為例：一條新的防火墻規則經審批通過后，會自動下發至對應設備。美的目前管理著500多臺防火墻，傳統模式下如需拉黑某個IP，運維人員需逐臺登錄設備操作；但在這個平臺上，只需完成審批流程，指令就能瞬間同步到所有目標防火墻。

再比如CMDB，數據不準確是業界公認的最大痛點，對此，我們做了大量自動校準的工作。一方面，在主機部署Agent，由Agent采集硬件信息與CMDB中的數據做對比，一旦發現不一致就會自動報警；另一方面，我們會抓取網絡流量進行校驗，若某個IP地址在網絡流量中存在，但未錄入CMDB，即可判定為CMDB數據遺漏。要知道，CMDB是所有基礎設施數據的源頭。CMDB數據不準的話，穩定性不可能做好；舉個例子，如果一臺機器你都不知道它的存在，你當然不會在這臺機器上部署監控，而監控不全肯定影響穩定性。CMDB數據不準的話，安全性不可能做好；舉個例子，如果一臺機器你都不知道它的存在，你當然不會在這臺機器上部署主機防護，而防護不全肯定影響安全性。

我們的全棧監控平臺，覆蓋從底層硬件到上層應用的全鏈路。多數企業的監控系統呈碎片化狀態 —— 不同系統分別負責硬件、系統等單一維度的監控，數據分散在各個平臺，故障發生時無法自動做關聯分析，全靠手工，所以難以快速定位故障的位置。

對此，我們把所有數據收集聚合做綜合分析，包括物理機、存儲、網絡性能、端側等全維度監控數據。例如，我們的一個度量標準是用戶端到端體驗。當業務反饋系統卡頓，但技術側感知不明顯時，平臺就能一鍵生成完整調用鏈路，每個調用所消耗的時間都一目了然。另外，平臺會自動監控所有慢SQL語句，這類語句在流量高峰時極易引發故障。

我們的大數據體系由兩大核心平臺構成：引擎平臺負責底層數據計算，開發平臺則承載代碼編寫與數據治理功能，是一站式的大數據研發運維平臺。開發平臺整合了多源數據同步能力，支持離線與在線代碼分析，并內置運維、數據治理等能力。

我們的大數據平臺做了很多降本增效的能力，而這些能力是公有云上的大數據平臺所不具備的。對于公有云來說，沒必要花很大的精力為了讓自己減少營收。舉個例子，大多數企業的大數據集群都很大，而且有兩套集群：一套是生產集群、一套是開發測試集群。一般來說，生產數據要同步到開發測試集群、在這個開發測試集群進行開發測試，調試好之后才放到生產集群上跑。對我們的大數據平臺，只有一套數據，只有一套集群，就是生產集群，大數據開發人員就在生產集群上做開發。給開發人員的感受是他可以在生產數據上進行開發、增刪查改，但這些動作并不會真正污染生產數據。并且，開發在白天、跑數在晚上，完美錯峰，最大化提升集群資源利用率。

在數據治理方面，美的集團的數據治理都在我們這個大數據平臺。我們數據治理能力很多，我這里以全自動數據血緣分析為例講一下。可以圖形化展示表與表之間的血緣關聯關系，一旦某張表數據異常，就能快速定位受影響的下游數據鏈路。此外，AI 問數功能已全面投入使用，已經為美的業務部門落地了200多個應用場景，讓業務人員通過自然語言就能完成數據分析。

大數據引擎平臺則與開源生態全面兼容。我們聯合Intel開展性能優化，目前引擎運行效率比開源引擎高40%~60%。

我們還構建了數據庫管理平臺，能對MySQL、Oracle等各類開源或商用數據庫的增刪查改等操作進行統一管控。大多數企業的數據庫管理員、研發、測試等人都直連數據庫進行操作，這樣做的問題是無法進行細粒度權限管控，而且看了什么、改了什么、刪了什么、增了什么都無法進行審計。

在美的，我們禁止任何人直連數據庫，員工需要用個人賬戶登錄到這個平臺，對數據庫進行操作，寫各種SQL語句。我們會解析員工的SQL語句，判斷是否有權限，有則通過、無則要申請。

其次，數據庫管理員DBA需要很多工具，但是在很多企業這些工具都是缺失的。我們的數據庫管理平臺提供了幾乎全部DBA所需工具，包括數據歸檔、校驗、優化診斷等等。另外，我們的監控平臺所監控到的所有慢SQL，會自動同步在這個數據庫管理平臺平臺上，然后這個平臺會利用AI大模型技術自動生成慢SQL的修改建議。

在數據庫引擎平臺層面，我們認為大多數企業用開源數據庫的性能就夠了，尤其是制造業。但開源數據庫能直接用嗎？所有的開源軟件都不專業、都不是企業版，拿過來直接用的話，沒有高可用、高可靠或動態擴縮容這些企業級能力，數據庫會非常容易宕機。我們的數據庫引擎平臺就是對這些開源數據庫進行企業級能力增強，并且全部數據庫實現了服務化（即SaaS化）與容器化，業務部門根據需要申請數據庫實例就可以使用了，不需要自己搭建和運維數據庫。

我們還打造了一整套的研發效能平臺，涵蓋項目管理、研發管理、自動化測試、電控軟件開發、全流程 AI 代碼生成及度量平臺等模塊。所有研發數據均沉淀到度量平臺，用于量化分析業務指標與研發效率指標。

在美的，AI代碼生成功能已經進入規模化實用階段了：

目前美的入庫代碼中，每四行代碼就有一行是AI寫的，即AI代碼入庫率達25%。現在業界大多數度量不了AI代碼入庫率，只能度量采納率——原因在于大多數企業軟件開發人員使用的是本地集成開發環境IDE，無法采集到的開發者的行為和代碼入庫情況，只能使用采納率來衡量，但是采納的的代碼未必最終入庫的代碼，采納的代碼有很多都是垃圾，需要修改或扔掉。所以其實采納率這個統計數據實際意義不大。而我們采用的是Cloud IDE，只有Cloud IDE 才能度量到入庫率。美的現在98%的軟件研發人員每天都在使用這個工具開展編程工作。

三、安全演練代價高？美的四年打磨終端安全平臺

密碼是信息安全的基石，但很多企業的密碼管理存在嚴重漏洞：應用系統訪問數據庫的密碼多直接寫死在代碼中，一套密碼往往被多個業務系統所使用，導致密碼難以定期輪換，存在很大的脫庫風險；此外，運維人員習慣用 “密碼本” 記錄各類密碼，而這類密碼本非常容易通過釣魚攻擊被竊取。

對此，我們搭建的機密管理平臺，采用認證Token機制：業務系統通過臨時Token從平臺獲取數據庫密碼，平臺與數據庫實時打通，可自動定期更換密碼，且業務側無需做任何改造。

第二，是自動化攻擊模擬平臺。如何判斷一個企業信息安全的建設水平？這就需要實戰演練。但請攻擊隊的成本很高，每次幾十萬。我們自研的攻擊模擬平臺可以讓企業7×24小時的自己攻擊自己，每天早上信息安全團隊會收到報告，然后就可以根據這份報告整改。

對美的的終端安全，我們建設了一個四合一的終端安全平臺，包括零信任、DLP（數據防泄漏）、終端準入、設備管控能力。

傳統 VPN 只能提供四層網絡的防護，無法實現業務級精準訪問的控制——用戶登錄VPN后，可以訪問內網所有業務系統，且公司也無法限制訪問時段，如夜間2點到6點禁止訪問核心系統。零信任架構則可以實現細粒度的業務權限與時間管控。

對DLP，我們調研了市面上所有的DLP產品，發現幾乎都是基于關鍵詞檢測技術的。基于這種老舊技術的DLP有很多問題。第一，誤報率太高，信息安全的人完全查不過來。第二，即使能查得過來，信息安全人員也無法判斷一個外發文檔是不是機密，因為信息安全人員的定位也不是精通公司技術。第三，這樣的DLP很容易被員工繞過，文件加個密就繞過了。我們的DLP采用 “只進不出”的核心原則：公司配發的終端默認禁止任何數據外發，所有外發都是基于白名單的機制。

對終端準入，很多企業依然采用802.1x協議做準入控制，這就需要逐臺配置路由器節點，工作量巨大。我們將準入功能直接內置在終端側，無需進行網絡設備配置，大幅降低部署成本，提升部署和運營的效率。

以上是我們站在甲方視角打造的一整套數字化底座，實現了公有云與自有數據中心資源的全面整合，真正實現全球一張網，全球一朵云，一個企業一朵云。現在我們也做對外輸出，讓這個平臺賦能更多企業。感興趣的企業可以聯系我（郵箱：alexliu360@qq.com，請務必注明：公司-職務-姓名。）。謝謝大家。