作為國產(chǎn)開源操作系統(tǒng)社區(qū)，OpenCloudOS從L1到L3全鏈路覆蓋，從上游社區(qū)獨(dú)立選型軟件包，編譯、運(yùn)行不依賴任何其他發(fā)行版，做到自主維護(hù)、演進(jìn)，獨(dú)立修復(fù)bug、cve及backport等維護(hù)工作。

今年3月，OpenCloudOS已率先構(gòu)建了一套全流程自動化的基礎(chǔ)設(shè)施和工具平臺，實現(xiàn)對3000+大規(guī)模軟件包的全鏈路自主研發(fā)與自主維護(hù)：《如何實現(xiàn)對 3000+ 軟件包的全鏈路自主研發(fā)與維護(hù)?》

與此同時，OpenCloudOS進(jìn)一步結(jié)合LLM/AI輔助功能，持續(xù)提升開發(fā)、維護(hù)效率和質(zhì)量，讓社區(qū)的開發(fā)者、軟件包的維護(hù)者有更多的精力投入到對重要包的掌握和能力建設(shè)、新技術(shù)新特性的探索和研發(fā)中。（本文基于2024.10.16 CID演講整理）

一、解決方案綜述

這套從上游跟蹤到代碼同步的全流程自動化維護(hù)工具平臺，主要包括5個部分及對應(yīng)的工具，其中紅色標(biāo)識的部分通過LLM/AI輔助進(jìn)一步提升效率和質(zhì)量。

• rpm-upgrade用來跟蹤上游社區(qū)的發(fā)布情況，包括獲取新版本的changelog，以了解社區(qū)的動態(tài)（比如在開發(fā)什么新特性）。
• rpm-tracker用來跟蹤重要包的commits，使用LLM/AI進(jìn)行分類。通過這2個工具可以及時獲取上游最新的動態(tài)、修復(fù)，按需backport到自主維護(hù)的版本，軟件包維護(hù)者無需人肉跟蹤上游社區(qū)。
• 獲取到上游的更新、修復(fù)后，會嘗試自動提交pr。提交成功的pr，會通過第3個工具rpm-check進(jìn)行變更識別和兼容性檢查，對正則表達(dá)式無法處理的差異通過LLM/AI進(jìn)行比較判斷；如果pr有補(bǔ)丁沖突，嘗試使用LLM/AI解決沖突。同時通過LLM/AI先review出代碼規(guī)范問題，maintainer專注于代碼邏輯。
• 如果發(fā)現(xiàn)兼容性變化，會自動通過第4個工具rpm-dep來查找受影響的軟件包來進(jìn)行重編、執(zhí)行受影響的包的用例。
• 最后通過rpm-sync結(jié)合LLM/AI來同步到其他分支，以上覆蓋維護(hù)全過程，通過ci串聯(lián)起來實現(xiàn)了全流程自動化。

相對于上一代工具平臺，在引入LLM/AI后，進(jìn)一步提高了準(zhǔn)確性和效率, 節(jié)省了更多成本，同時新增了自動修復(fù)CVE、基于LLM/AI的容器基礎(chǔ)鏡像自動化轉(zhuǎn)換和制作、自動化軟件包構(gòu)建打包，率先覆蓋了當(dāng)前Linux發(fā)行版開發(fā)、維護(hù)的主要流程。

以下詳解各個部分。

二、具體實現(xiàn)

1.rpm-upgrade跟蹤上游新release

軟件包的上游社區(qū)形式多樣，有g(shù)it、svn、hg等不同的協(xié)議，github/gitlab、pypi、Sourceforge等不同接口，并且軟件包新release發(fā)布頻率、時間間隔不同，如果無差異地對所有包執(zhí)行升級查詢，浪費(fèi)資源和人力。rpm-upgrade工具可解決這些問題，3200+軟件包中的98.5%都能實現(xiàn)自動化查詢是否有新release，基本不再需要人工跟蹤上游。

上游新release查詢到后，符合條件的軟件包就可以進(jìn)行自動升級。但在升級過程中，還存在多Source源，tarball無法直接獲取等情況，另一個問題是升級中補(bǔ)丁沖突。rpm-upgrade工具已經(jīng)較好地解決了大部分問題，還有部分補(bǔ)丁沖突問題正在通過引入LLM/AI來輔助分析、解決。

可提升軟件包升級效率80+%，平均節(jié)省10分鐘以上。

2.rpm-tracker跟蹤上游commits

在軟件包的穩(wěn)定維護(hù)階段，主要通過backport補(bǔ)丁的方式進(jìn)行維護(hù)，但軟件包的分支、commits信息多。我們設(shè)計了rpm-tracker工具通過GraphQL來獲取上游commits信息，支持github、gitlab等主流平臺；選擇專門的大模型，結(jié)合微調(diào)，對commits進(jìn)行分類，把bug修復(fù)、cve修復(fù)等類型的commits識別出來，backport到我們的代碼中。

如果出現(xiàn)commits回合沖突，則需要進(jìn)行適配，當(dāng)前正在嘗試通過LLM來處理patch沖突。

3.patch沖突治理

傳統(tǒng)工具只能處理少部分情況（例如文件格式等），對于行號偏移、新值插入、源碼內(nèi)容變動等更常見更復(fù)雜的情況，無能為力。

利用大模型可識別代碼語義的優(yōu)勢，可以更智能的處理補(bǔ)丁沖突情況，基本原理為：

• 確保該patch未在代碼中已合并，為新patch；
• 流水線首先嘗試將patch合并；
• 如果出現(xiàn)失敗，則將patch、代碼原文和prompts一并交給大模型進(jìn)行自動處理，適配出新的補(bǔ)??；
• 再次嘗試進(jìn)行patch合并；
• 經(jīng)過以上步驟，適配出適應(yīng)代碼的新補(bǔ)??；
• 最后經(jīng)過人工確認(rèn)，將補(bǔ)丁合入源碼，實現(xiàn)patch沖突適配。

4.自動修復(fù)CVE

在穩(wěn)定維護(hù)階段，CVE感知、修復(fù)的及時性非常重要。CVE修復(fù)需要長期跟蹤修復(fù)，對人力、時效要求高；同時上游CVE修復(fù)可能涉及多個commit聯(lián)合修復(fù)。

通過扒取NVD、github等多個安全數(shù)據(jù)庫并建立漏洞和commits對應(yīng)關(guān)系數(shù)據(jù)庫，自動化跟蹤C(jī)VE，且能自動化獲取對應(yīng)的完整commits；同時大模型也會針對rpm-tracker爬取的所有commits，做CVE識別，此時以CVE數(shù)據(jù)庫為高優(yōu)先級，大模型為低優(yōu)先級，進(jìn)行搭配，同時兼顧時效性和準(zhǔn)確性。

目前自動修復(fù)CVE功能，需要進(jìn)一步提高時效性。

5.rpm-check兼容性檢查

當(dāng)前業(yè)界已有的兼容性檢查開源工具存在檢測速度較慢，支持語言少，同時存在無法處理庫中部分特殊字符、無法判斷符號是否對外等問題。rpm-check通過包和文件粒度并發(fā)、多維匹配算法等方法解決了這些問題。

但還存在兼容性結(jié)果可讀性較差，適配成本較高；可執(zhí)行文件檢查中，因為選項和參數(shù)類型各異，特殊場景較多，很難通過正則匹配代碼直接判定以及過濾無效差異等問題。

rpm-check結(jié)合大模型的分析能力，對結(jié)果進(jìn)行輔助分析評估：比如ABI/API的變化，會先經(jīng)過內(nèi)外部符號判定，判斷該變化為內(nèi)部變化還是外部變化；然后經(jīng)過大模型強(qiáng)化的評估算法確定其影響等級；最后根據(jù)評估結(jié)果確認(rèn)影響范圍。

**LLM/AI修正了10%的兼容性結(jié)果，提升了差異報告的可讀性；可執(zhí)行文件差異誤報率降低了30%以上，兼容性檢查誤報率整體上降低了10%**。

如果存在需要適配兼容性的代碼，還能夠借助大模型能力給出詳細(xì)的排查和適配步驟，幫助開發(fā)者修復(fù)OS系統(tǒng)升級后的應(yīng)用不兼容問題，大大提升了應(yīng)用代碼的兼容性適配效率。

6.rpm-dep查詢包依賴及排序

提交代碼后可能導(dǎo)致軟件包有變化，從而影響到依賴它的其他包，通過 rpm-dep 工具獲取快速、準(zhǔn)確獲取受影響的軟件包，同時能夠按依賴層級排序、指導(dǎo)構(gòu)建系統(tǒng)按依賴順序逐層進(jìn)行編譯構(gòu)建。

7.release+1重編受影響包/測試發(fā)布

找到受影響的包后就要進(jìn)行重編。

根據(jù)影響和風(fēng)險的不同，分為正式重編和測試重編，正式重編是指要release+1提交pr，如soname變化會導(dǎo)致找不到依賴，就要正式重編。而測試重編不release+1、不提交pr，只用來驗證變化會不會導(dǎo)致問題，如API頭文件變化，如果某項測試重編失敗，則后續(xù)加入到正式重編。

測試重編、正式重編，都要保障編譯源依賴的是變化后的包，不能基于老包編譯，同時要保證編譯順序，按照依賴關(guān)系層級排序進(jìn)行編譯，底層的包編譯成功、進(jìn)入編譯源后再編譯上層的包。

8.利用大模型進(jìn)行review

PR的合入，除了門禁檢查外，還需要人工審核代碼，maintainer往往耗費(fèi)大量精力在檢查一些“低級”代碼問題上，review效率極低。

利用大模型給出PR的總結(jié)，同時檢查代碼是否符合規(guī)范，并找出可能潛在的風(fēng)險項，讓maintainer把精力放在review代碼的邏輯上。

三、新增模塊

在軟件包維護(hù)之外，還有開發(fā)活動，我們識別了2個重要的開發(fā)活動，容器鏡像制作、軟件包打包，在大模型輔助下進(jìn)行了自動化的嘗試。

1.容器基礎(chǔ)鏡像轉(zhuǎn)換和制作all2image

在大數(shù)據(jù)、云原生、AI等新興領(lǐng)域，大量開發(fā)者基于debian 和 alpine打包業(yè)務(wù)容器鏡像。為了豐富OpenCloudOS 的支持場景，適配更多的開源項目，我們考慮參考其他開源社區(qū)的開源項目以及對應(yīng)的容器鏡像，構(gòu)建基于OpenCloudOS的容器環(huán)境。

基于大模型的語義理解能力，研發(fā)對應(yīng)的基礎(chǔ)鏡像轉(zhuǎn)換工具，通過建立操作系統(tǒng)軟件包映射，即可精確提供系統(tǒng)依賴，通過大模型完成 Dockerfile 語義理解和改寫，建立自動化工作流：“映射查詢 —— 改寫 —— 構(gòu)建 —— 糾錯”，將基于 debian/alpine 的 dockerfile 轉(zhuǎn)換為 基于opencloudos 鏡像，然后制作容器鏡像。

這個工具依賴于存在dockerfile這種穩(wěn)定的預(yù)定義運(yùn)行時文件，如果沒有相關(guān)的文件，那就需要我們進(jìn)一步考慮是否可以自動識別一個項目的編譯環(huán)境和運(yùn)行環(huán)境。

對于這個問題，我們通過自動化構(gòu)建打包工具autopkg來解決 。

2.自動構(gòu)建打包AutoPkg

開源社區(qū)存在大量軟件，只靠發(fā)行版維護(hù)者人力打包速度緩慢，為此開發(fā)了該工具，提高效率。

通過分析大量開源軟件，我們發(fā)現(xiàn)絕大部分軟件的構(gòu)建，至少使用一款構(gòu)建系統(tǒng)，因此通過解析構(gòu)建系統(tǒng)的腳本或配置文件，獲取軟件信息、構(gòu)建依賴等，有可能自動生成發(fā)行版構(gòu)建腳本（例如構(gòu)建rpm的.spec），對于復(fù)雜的原始構(gòu)建腳本例如configure，使用大模型進(jìn)行解析。

AutoPkg是一個中立的工具，并非只服務(wù)OpenCloudOS采用的rpm軟件格式，也能支持deb/AppImage等其他格式。

該工具計劃覆蓋所有熱門編程語言的主流構(gòu)建系統(tǒng)，從而盡可能覆蓋所有開源軟件，目前已經(jīng)完成Python和R語言，部分完成了C/C++/JAVA語言。

四、小結(jié)

通過對以上自動化基礎(chǔ)設(shè)施、工具平臺進(jìn)行大模型的加持，軟件包開發(fā)、自主維護(hù)效率和質(zhì)量得到極大提升，OpenCloudOS自主維護(hù)能力之路走得更加堅實。