“美好”的一天，从引包开始

上午 9 点，小安收到一条消息：

“把这个软件包引入 Anolis OS 27，最好今天能看到构建结果。”

上午 10 点，新包还在构建，安全群再次弹出告警：

“某基础组件曝出高危 CVE，请尽快确认影响范围并完成修复。”

小安电脑上逐渐堆满软件包仓库、上游页面、构建任务、失败日志和聊天记录。需求方问新包什么时候能用，安全同学追问补丁是否完成，测试和发布同学又在等待下一步结果。

看起来是两个任务，背后却是同一道难题：软件包、发行版规则、构建工具和发布状态分散在不同位置，多个任务的并行，需要在不同窗口、不同页面之间来回切换。小安嘴上说着“做完你的做你的，我心里有数”，实则已经阵脚大乱。

一套发行版，被拆成了一串独立又关联的工程拼图。

一个软件包修改，为什么要跑遍整个研发流程 Pipeline？

“引入一个软件包”或者“修复这个 CVE”听起来只是对一份代码进行修改，实际却是一场发行版各个基础设施跨层层接力：

版本调研
  → 找仓库和分支
  → 查询代码信息/查询仓库信息
  → 准备 spec/source/patch
  → SRPM/mock 构建
  → 分析失败
  → 修改重试
  → 整理变更
  → 审核发布复制

整个过程牵扯到多个研发系统，需要在不同的机器上流转处理。如果涉及多个研发任务并行，往往会出现包引入选型文档刚开了个头、Bug 修复的代码还没提交、群里已经在@你处理高危 CVE，最后求助资深 Maintainer，发给你一篇藏在个人文档库的流程文档。发行版工程实际都困在 数据分散、入口分散、状态分散和经验难以传递 的问题里。

一个软件包的修改，慢的不是某一个命令，而是每一步都要由人重新搬运信息、恢复上下文、判断下一步。

如果整个发行版就是一个上下文呢？

Anolis OS 27 Monorepo 由此登场，它开拓性地把仓库合到一起。而这只是起点，它真正带来的是： 发行版从“几千块散落的拼图”变成了一张 Agent 和人都能直接操作的完整地图 。地图里面糅合了软件包、元数据、包组、工程规则、构建工具等元素。

Anolis OS 27 Monorepo
├── packages/      软件包、spec、patch、source 与维护元数据
├── groups/        包组及系统组成
├── releases/      manifest、镜像定义、安全公告和发布快照
├── tools/         可重复执行的确定性工程工具
├── playbook/      面向 Agent 的发行版技能
└── 工程规则与 Agent 上下文复制

过去依靠 Maintainer 人脑连接的发行版知识，现在开始成为人类和 AI Agent 都能读取、计算和审查的工程结构。

统一入口可以根据任务生成 Plan，再调用确定性工具和 PengLAI 智能能力。PengLAI 全称为 Platform for ENGineering Linux with AI，是阿里云 Linux 操作系统全生命周期智能管理平台，为 Monorepo 提供远端能力扩展，支持构建、修复、发布等发行版原子能力。整个流程变成：

提出目标
  → 生成 Plan
  → 多维上游选型/补丁
  → 生成包工程数据
  → 构建与迭代修复
  → 单包验证
  → 形成变更与证据
  → 授权创建 PR
  → Maintainer 审核复制

Agent 第一次也可能失败，但日志、工程输入、修改和产物仍在同一条任务链中，失败不会让流程重新“失忆”。AI 可以接力分析、生成和修复，层层完成构建和发布等工作。

Monorepo 统一的不是文件位置，而是发行版的工程上下文。

相同的阶段，不同的瓶颈

需求、设计、实施、验证、审核发布和维护并没有因为 AI 出现而消失，发生变化的是每个阶段的主导者和时间消耗。

传统模式下，维护者人工串联各个阶段，大量时间花在寻找信息、切换系统、复制参数和等待结果上。AI 驱动模式下，Agent 承担规模化分析和重复执行，人类聚焦架构设计、深层问题、结果验证和最终发布决策。

• 传统模式：人工串行、被动维护

• AI 驱动：Agent 闭环、持续运行、人类审核兜底

新的瓶颈不再是能投入多少重复人力，而是工程规则是否准确、SPEC 是否清晰、长尾问题能否真正解决、AI 的决策能否得到充分验证。

AI 没有删除发行版研发的任何一道门禁，而是将所有繁琐步骤串联起来，减少人力接入。

尾声：从“人脑拼图”到共同工程

上午的新包和下午的 CVE，最终在同一套发行版工程上下文中形成了结果。执行过程可以由 Agent 加速，关键动作仍由确定性工具完成，串通分析、构建、修复、验证流程。将繁重工作交给 AI，开发者聚焦版本策略、风险判断和发行版整体设计。

Anolis OS 27 Monorepo 希望开源的 不只是一个容纳大量软件包的 Git 仓库 ，也是一种面向 人类 Maintainer 与 AI Agent 协作的发行版工程方法 。

Agent 可以接过重复劳动，但不能拿走发行版的责任链。

三千个软件包，不必再各说各话；一套发行版，值得拥有一个完整上下文。

快速开始

这套工程方法已经开源，你可以这样上手：

1.克隆 Anolis OS 27 Monorepo 仓库： git clonehttps://gitee.com/anolis/anolis27-monorepo.git 。

2.使用 Qoder IDE （或其他 AI Agent） 打开项目。

3.使用 /anolis-bot-config 快速完成配置（PengLAI MCP 服务处于邀测阶段，请加入下方「邀测答疑群」申请获取授权 Token）。

4. 使 用 /anolis-bot <自然语言需求> 发起任务，例如 /anolis-bot 引入 glib2 。

5.Voilà！大功告成，检查提交的 PR。

Anolis OS 27 Monorepo 已正式开源，仓库地址：
https://gitee.com/anolis/anolis27-monorepo

—— 完 ——