作為國產開源操作系統社區，OpenCloudOS從L1到L3全鏈路覆蓋，從上游社區獨立選型軟件包，編譯、運行不依賴任何其他發行版，做到自主維護、演進，獨立修復bug、cve及backport等維護工作。

今年3月，OpenCloudOS已率先構建了一套全流程自動化的基礎設施和工具平臺，實現對3000+大規模軟件包的全鏈路自主研發與自主維護：《如何實現對 3000+ 軟件包的全鏈路自主研發與維護?》

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

一、解決方案綜述

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

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

相對于上一代工具平臺，在引入LLM/AI后，進一步提高了準確性和效率, 節省了更多成本，同時新增了自動修復CVE、基于LLM/AI的容器基礎鏡像自動化轉換和制作、自動化軟件包構建打包，率先覆蓋了當前Linux發行版開發、維護的主要流程。

以下詳解各個部分。

二、具體實現

1.rpm-upgrade跟蹤上游新release

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

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

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

2.rpm-tracker跟蹤上游commits

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

如果出現commits回合沖突，則需要進行適配，當前正在嘗試通過LLM來處理patch沖突。

3.patch沖突治理

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

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

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

4.自動修復CVE

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

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

目前自動修復CVE功能，需要進一步提高時效性。

5.rpm-check兼容性檢查

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

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

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

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

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

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

提交代碼后可能導致軟件包有變化，從而影響到依賴它的其他包，通過 rpm-dep 工具獲取快速、準確獲取受影響的軟件包，同時能夠按依賴層級排序、指導構建系統按依賴順序逐層進行編譯構建。

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

找到受影響的包后就要進行重編。

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

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

8.利用大模型進行review

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

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

三、新增模塊

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

1.容器基礎鏡像轉換和制作all2image

在大數據、云原生、AI等新興領域，大量開發者基于debian 和 alpine打包業務容器鏡像。為了豐富OpenCloudOS 的支持場景，適配更多的開源項目，我們考慮參考其他開源社區的開源項目以及對應的容器鏡像，構建基于OpenCloudOS的容器環境。

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

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

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

2.自動構建打包AutoPkg

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

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

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

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

四、小結

通過對以上自動化基礎設施、工具平臺進行大模型的加持，軟件包開發、自主維護效率和質量得到極大提升，OpenCloudOS自主維護能力之路走得更加堅實。