作为国产开源操作系统社区，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一并交给大模型进行自动处理，适配出新的补丁；
- 再次尝试进行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自主维护能力之路走得更加坚实。
