“美好”的一天，从引包开始
上午 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
仓库部分功能需配合 PengLAI MCP 能力，该能力处于邀测阶段，请加入「邀测答疑群」申请。
Anolis OS 27 Monorepo 邀测答疑群
