从此告别重复劳动，百款开源项目适配经验提纯成 AI Agents | 龙蜥 SkillHub 精选

专注于 Infra 层的 AI Agent 技能平台——龙蜥社区 SkillHub 已收到数百个技能，当前陆续上线中。我们每周也会收到一些技能的最佳实践分享，本期给大家推荐的是统信软件如意玲珑（Linyaps）智能化生态团队贡献的 debian-rules-to-linyaps-rules、linyaps-app-packaging-script-generator、linyaps-packaging-scripts-running-skill 实践文章，他们拥有上百款 Linux 开源项目的适配实战经验，深度精通 CMake、Meson、Autotools 等传统构建系统，并熟练掌握 debian/rules 构建机制与 deb、tar、AppImage 等主流二进制包的玲珑化适配技巧。在历经大量复杂的打包排坑实践后，他们将沉淀的经验提纯为自动化技能，成功研发出一套如意玲珑 AI Packaging Agents 工具集，正全力推动 Linux 应用生态打包向自动化与智能化转型。以下是他们的实战经验分享：

在 Linux 生态里，应用打包这件事，从来都有门槛。Debian 构建规则、如意玲珑（Linyaps）的 linglong.yaml、deb / tar / AppImage 各种格式的转换……就算是经验老到的开发者，也难免在重复劳动里消耗大量精力。而现在，这些让人头疼的问题，有了更智能的解法——我们把上百款开源项目的适配经验，提纯成了一整套打包 Agents。

先说背景：适配门槛和通用痛点，其实是一家事

做这套东西的念头，是我们在挨个给开源项目做如意玲珑适配时，被“重复”磨出来的。

源码适配要读懂 debian/rules、debian/control，还要搞清楚 linglong.yaml 里 prefix、DESTDIR、编译开关这些门道；二进制转换要处理 deb 里的依赖、tar 包里的二进制、AppImage 里的运行库。看似是两条赛道，可底层碰到的其实是同一类难题：

1.门槛高。 一个 debian/rules 里藏着几十个编译参数，linglong.yaml 的语法、构建约定更是要一点一点啃。没个几年的适配经验，真写不出来一份能过构建的配置。

2.重复劳动。换一个项目、换一个版本、换一种包格式，前面那套人工步骤全都要再来一遍——这恰恰是最磨人的地方。

3.易错。desktop 的 Exec 写错一个符号、图标少放一个目录、依赖解析漏了一层、版本号带了架构标记……任何一个细节踩空，构建就直接失败，然后你还得靠肉眼去查。

为什么偏偏是“编译规则”这么难

Linux 原生编译工具链本身就有门槛：cmake、meson、make + autotools 各有一套约定——prefix 默认值（cmake/meson 默认 /usr，make/autotools 默认/usr/local）、--enable-* / --disable-* 开关、DESTDIR 语义、-j 并行度，每个项目还会自定义 CFLAGS、--with-*。要把这些翻译成linglong.yaml的 prefix、build_args、DESTDIR，没有几年适配经验根本无从下手。

而如意玲珑（Linyaps）的定位，恰恰让这种适配既必要又划算。官方在“为什么需要如意玲珑”中直指传统包格式体系的痛点：依赖靠系统维护者手工维持、应用安装权限过大易破坏系统、系统与应用高度耦合使 ABI 与生命周期不可控、发行版格式不一导致重复打包；如意玲珑的优势则是容器化隔离系统与运行环境、一次编译处处运行、Rootless 容器降低攻击面、支持增量更新。正因“一次适配、处处运行”，把最耗人的“翻译编译规则”环节交给 AI 批量完成，才格外有价值。

痛点这么集中，我们就在想：能不能把这些年攒下来的经验，“塞进”一组能直接被 Agent 调用的技能里，让 AI 来接手打包这件事？

于是就有了这套如意玲珑（Linyaps）打包 Agents 工具集。它内置三个 Agent，各司其职、串成完整链路：debian-rules-to-linyaps-rules 负责把源码的 Debian 构建规则“翻译”成如意玲珑配置，linyaps-app-packaging-script-generator 负责把 deb / tar / AppImage 批量转换成如意玲珑工程，linyaps-packaging-scripts-running-skill 负责拿着已有工程模板持续构建新版本。

这套工具集到底能干什么？

一句话版本：源码，它帮你把 debian/rules 翻译成linglong.yaml；二进制，它帮你把各种格式的包转成可直接构建的如意玲珑工程；版本迭代，它帮你用已有模板持续产出新的 layer 包。

展开说，几个核心 Agent 的能力是这样的：

 

先认识下这些“技能包”

这套工具集不是三个黑盒，而是“一个 Agent 管流程、一堆细粒度 skill 管能力”。我们把一件事拆成一个 Skill，既能被多个 Agent 复用，出了问题也好单点修复：

 

真实可用的场景

 

场景一：从 0 到 1 创建工程。

你有一个开源项目，一句提示词就能拿到能构建的工程：

https://linux.apps.demo.com/download/demo.orig.tar.xz 是一个开源项目源码包，/path/to/your/sourceDebianRules 是此项目的 debian 构建目录，帮我转换为如意玲珑构建配置文件 linglong.yaml。

手里是二进制包也一样，扔一句“帮我把本地 /path/to/your/file 安装包转换为如意玲珑应用”就行。

场景二：从 1 到 N 迭代。

工程模板在手，换新版本只改来源：

使用此软件包 https://linux.apps.demo.com/download/demo.deb 更新如意玲珑应用，已经适配的工程目录在 /path/to/your/pak_linyaps.sh。

做这套东西的过程，和踩过的那些坑

这次不聊细枝末节，重点说说两个核心 Agent 是怎么一路长起来的。

 

先看源码适配：debian-rules-to-linyaps-rules

这个 Agent 的难点，在于“读懂规则”。它最早期踩过一个大坑：build-res-generate 错误地无视了 debian rules。当时引入 common-building-rules.yaml 常见编译规则后，生成的 build section 却是靠硬编码模板拼的，跟参考规范对不上，甚至带上了 DESTDIR=${prefix} 这种被参考文件标记为 forbidden 的内容，直接把校验环节给堵死了。

我们用 VLC 做了个对比，问题立刻清楚了：参考的 autotools 段是 ./configure --prefix=... + make + make install，而脚本生成的是 ./configure --prefix=${PREFIX} --host= +make-j$(nproc) + make install DESTDIR=${prefix}——多出来的 --host= 和 DESTDIR 全是错的。

这次的教训很深：生成和校验必须分开，但必须共享同一份规范。 于是我们把流程改成“脚本机械分析 + LLM 语义分析”双轨制：

• 机械分析（脚本）：analyze-rules.py 输出 build_tool、build_args、baseline、resources；
  
• LLM 语义分析（SKILL.md 指引）：读完整 debian/rules，识别 --enable-* / --disable-* / CFLAGS 等有意义的参数，跟机械输出去重后给出 extra_args 和完整 build_section；
  
• 生成时对照 common-building-rules.yaml 补充缺失命令、注入参数、拦截 forbidden patterns；校验时做必需命令检查和禁用参数阻断。
  

另一个高频坑是 prefix 硬编码。源码项目的安装目录，不同构建工具默认值五花八门，cmake 和 meson 默认 /usr、make 和 autotools 默认 /usr/local，LLM 常常就照着硬编码进去了，装出来路径就错了。我们专门做了个 ${PREFIX} 安装目录约束：把四个工具的 prefix 默认值全部统一成 ${PREFIX}，还在校验脚本里加了 10 条硬编码路径检测规则，并在生成脚本里加了一层 replace_hardcoded_prefixes() 自动替换作为安全网。这套“自动替换 + 校验报错”的双层防护，58 项单元测试全绿，保证没有一条硬编码路径能漏出去。

还有 runtime 依赖解析。debian/control 里的 Build-Depends 只是构建期依赖，应用真正跑起来需要的运行时库还得自己挖。我们写了个 init-control.py 入口，从 Build-Depends 出发，用只读的 apt-cache depends 递归三层查下去，逐层提取 Depends / Recommends，再用黑名单把 gcc、mesa、编译工具这些不该进 depends 的包剔掉，最后去重排序。这中间还处理了好几个刁钻语法：libjack-jackd2-dev | libjack-dev 这种“或语法”（取第一个选项）、libc6:amd64 这种架构约束（剥离）、cmake (>= 3.16~) 这种版本约束（剥成裸包名），还有版本号要规整成 a.b.x.y 的纯数字结构。

再看二进制转换：linyaps-app-packaging-script-generator

这里最头疼的是“LLM 行为不可控”。有个很典型的 bug：明明有 pak_linyaps.sh，LLM 有时候偏要自己一行行执行 build 命令，导致构建失败。我们的解法是明确权责边界——执行节点严禁自己初始化，只能通过 pak_linyaps.sh 脚本打包，把规则硬写进 SKILL.md。

其次就是一大堆边界条件。给 floorp、krita、Postman 做转换时挨个踩：

• wrapper 生成。二进制包经常要在 desktop 的 Exec 里套一层 wrapper，可 wrapper 名、相对路径一算错就启动不了（krita 那次 wrapper 名直接变成空的 .wrapper）；
  
• desktop Exec 替换。Exec= 不能带参数，参数得由 wrapper 处理，否则会被 dde-application-manager 误传参数导致启动异常；
  
• deb 解压兼容。deepin 上 dpkg 默认只处理 xz 归档的 deb，zst 的会解压失败，最后改用 ar -x 兼容性更好；
  
• 软链破坏。Vivaldi 解压后 /usr/bin/vivaldi-stable 成了指向 /opt/vivaldi/vivaldi 的 broken link，不处理就起不来；
  
• 版本号重组。4200 这种一位数组、1.112.01907 这种带前导零的，都得正确提取并校验；
  
• so 库软链。部分软件包内置 so 库，不软链到 $prefix/lib 可能加载失败。
  

这些坑每踩一个，就沉淀成一个校验脚本或一条 Skill 指引，pak_linyaps.sh 也越打磨越稳。

后续规划

短期的三件事：

 

• 构建缓存复用——同一工程不同版本迭代时，尽量复用已构建的缓存，减少重复编译；
• LLM 语义分析增强——让对 debian/rules 和工程结构的理解更准，少依赖人工兜底；
• 独立 debug 修复 skill（src2linyaps.debug）——解压已有构建工程产出的 layer，对照分析定位问题，调用内部 skills 修复后指派重新打包，把“适配 → 构建 → 诊断 → 修复”整条线打通。

写在最后

从一条条 issue、一次次构建失败里，我们把上百款开源项目的适配经验，一点点提纯成了能被 AI 直接调用的技能包。如意玲珑（Linyaps）打包的下一步，是让 AI 真正成为打包工作的得力助手——这个方向，我们觉得走对了。

也欢迎更多对 Agent 编码感兴趣的小伙伴加入龙蜥社区、共建 SkillHub。把你踩过的坑、跑过的工作流写成 Skill 贡献到社区，每一次“从问题到贡献“”的循环，都是推动 Agent 编码生态进步的微小却坚定的力量。

相关链接：

debian-rules-to-linyaps-rules：

https://github.com/OpenAtom-Linyaps/debian-rules-to-linyaps-rules

linyaps-app-packaging-script-generator：

https://github.com/OpenAtom-Linyaps/linyaps-app-packaging-script-generator

linyaps-packaging-scripts-running-skill：

https://github.com/OpenAtom-Linyaps/linyaps-packaging-scripts-running-skill

如意玲珑官网：

https://linyaps.org.cn/

Skillhub 官网链接：https://skillhub.openanolis.cn

龙蜥社区 Skill 征集活动——「Skill 创造营」上线以来响应热烈。截至目前，龙蜥 SkillHub 已收到覆盖安全、系统运维、AI 推理、数据库等多个领域，一个面向 Infra 的 AI 技能生态正在加速成型。「Skill 创造营」持续征集中，诚挚欢迎每一位开发者提交你的 Skill 与最佳实践。如果你有感兴趣的方向或者关于 SkillHub 的问题，欢迎通过下方链接反馈给我们。

SkillHub 用户需求收集链接：https://alidocs.dingtalk.com/notable/share/form/v014jKqm0b74KdjLnw1_f22ghuX_M7AJs3D