大模型加持的 Linux 发行版开发和自动化维护实践

腾讯架构师

发布于 2025-02-05 11:12:50

1150

作为国产开源操作系统社区，OpenCloudOS 从 L1 到 L3 全链路覆盖，从上游社区独立选型软件包，编译、运行不依赖任何其他发行版，做到自主维护、演进，独立修复 bug、cve 及 backport 等维护工作。

今年 3 月，OpenCloudOS 已率先构建了一套全流程自动化的基础设施和工具平台，实现对 3000+大规模软件包的全链路自主研发与自主维护。

与此同时，OpenCloudOS 进一步结合 LLM/AI 辅助功能，持续提升开发、维护效率和质量，让社区的开发者、软件包的维护者有更多的精力投入到对重要包的掌握和能力建设、新技术新特性的探索和研发中。（本文基于2024.10.16 CID演讲整理）

一、解决方案综述

这套从上游跟踪到代码同步的全流程自动化维护工具平台，主要包括 5 个部分及对应的工具，其中红色标识的部分通过 LLM/AI 辅助进一步提升效率和质量。

1. rpm-upgrade 用来跟踪上游社区的发布情况，包括获取新版本的 changelog，以了解社区的动态（比如在开发什么新特性）。

2. rpm-tracker 用来跟踪重要包的 commits，使用 LLM/AI 进行分类。通过这 2 个工具可以及时获取上游最新的动态、修复，按需 backport 到自主维护的版本，软件包维护者无需人肉跟踪上游社区。

3. 获取到上游的更新、修复后，会尝试自动提交 pr。提交成功的 pr，会通过第3个工具 rpm-check 进行变更识别和兼容性检查，对正则表达式无法处理的差异通过 LLM/AI 进行比较判断；如果 pr 有补丁冲突，尝试使用 LLM/AI 解决冲突。同时通过 LLM/AI 先 review 出代码规范问题，maintainer 专注于代码逻辑。

4. 如果发现兼容性变化，会自动通过第 4 个工具 rpm-dep 来查找受影响的软件包来进行重编、执行受影响的包的用例。

5. 最后通过 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 镜像，然后制作容器镜像。