11 天、13.9 万行：CentOS 创始人用 Codex 造出兼容 Linux 的新内核，跑起了 Rocky Linux 10

InfoQ 中文 2026-11-04T09:36:34.494665

CentOS 创始人 Gregory Kurtzer 用 11 天时间、一个持续运行的 Codex 任务，写出约 13.9 万行代码，做出以 Rust 为主的独立 x86-64 内核 Ginux。它不是 Linux 的分叉，却实现了 Linux ABI，能启动 Rocky Linux 10 并运行 systemd。真正值得看的不是“AI 写了多少代码”，而是人如何设定架构、关卡和验收标准。

一个不 fork Linux 的新内核

“就算给模型无限 token，它也做不出操作系统级别的东西。”这句话几乎是过去几年技术圈对 AI 能力上限的共识。

Gregory Kurtzer 给出了另一种回答。他是 CentOS 的创始人之一，也是在 Red Hat 宣布终止 CentOS Linux 之后推出 Rocky Linux 的人。

2026 年 10 月 27 日，他在 X 上宣布：用 11 天时间，以“人类主导的智能体工程”（Human-Directed Agentic Engineering，简称 HDAE）方式编写约 13.9 万行代码，造出一款全新的 Linux 兼容内核，能够启动 Rocky Linux 10 并运行 systemd。

项目名为 Ginux，是一款独立开发的、以 Rust 为主的 x86-64 内核。换句话说，它不是从 Linux 内核分叉出来的。

Ginux 的内存管理、调度器、进程模型、文件系统、网络和设备支持全部从零编写。它虽然不是 Linux，却兼容 Linux：实现了 Linux ABI，也就是已编译程序与内核通信所用的二进制接口。因此现有的 Linux 二进制程序无需修改，就能直接在 Ginux 上运行。

参照对象：用 Claude 从零造一个 C 编译器

这个项目有一个可比的对象。Anthropic 的 Nicholas Carlini 曾用 16 个并行运行的 Claude 智能体从零构建 C 编译器：花了近 2000 个会话、约 2 万美元，产出约 10 万行 Rust 代码，能编译大量软件，其中包括 Linux 内核构建过程的大部分内容。编译器自带测试套件和参考工具，为结果验证提供了很强的依据。

Ginux 的验收则更难：要从零搭出一个内核，再让未经修改的 Linux 用户空间程序在上面跑起来。程序能不能跑、systemd 能不能启动，才是检验系统是否真的能工作的关卡。

Kurtzer 在技术报告中把研究目标拆成三问：

他想弄清楚的是：当领域专家把架构、约束、里程碑和验收标准定清楚之后，AI 能把系统软件推进到哪一步。

Kurtzer 参与过 Caos Linux、CentOS 和 Rocky Linux 的建设，也有 Singularity/Apptainer、Warewulf、Perceus 以及生产基础设施运维的经验。这些经历直接影响了 Ginux 的启动流程和验收标准。

人的角色：外循环定方向，内循环跑实现

几乎所有实现工作都在一个持续运行的 Codex 任务中完成，用的是 GPT-5.6 Sol。用作者的话说：“作者负责设定架构、系统操作、解读结果，并作出最终验收决定。”

人的作用体现在两个互相配合的循环里：

HDAE 外部引导循环（需要人参与）：愿景 → 架构与约束 → 验收关卡 → 人观察实际行为 → 修正、调整优先级或验收。

HDAE 内部智能体循环（不依赖人工观察）：实现 → 构建并在 QEMU 中运行 → 测量并分析故障 → 修订 → 回归测试。

也就是说，Kurtzer 提供目标、架构、Linux 兼容性目标、操作模型、故障解读和停止决定；Codex 负责缩短从技术决策到可运行代码的距离。

领域知识则提供了愿景、优先级和成功标准。Kurtzer 表示，项目需要这些知识来选择 Linux 用户空间的契约、区分 OCI 传输与运行时隔离、识别出错的 fork/exec 行为、定义各部分的归属、解读 systemd 故障，并判断看似合理的输出是否符合预期。

为什么拿 systemd 当验收关卡

选择 systemd 作为验收关卡，是因为它依赖大量系统组件，是启动和运行整个系统的核心进程。但它在容器里启动时对环境相当挑剔，所以 Ginux 先实现了“域”的概念，再处理容器。

为什么是 Codex

有人在 X 上问他为什么选 Codex。Kurtzer 的回答是：它比较少把 token 浪费在支线上。但即便如此，他还是得经常把它拉回正轨。

有些大块代码他并不满意，却刻意要求自己不要亲手改：“我甚至关掉了 IDE，强迫自己别打开。这样 AI 做错时，我就只能给它新的指引；很多时候，它会把写错的代码删掉。”

对方追问具体怎么把它拉回正轨：是列一份禁止事项清单，还是盯着输出、一跑偏就拽回来？Kurtzer 的回答很简单：把每个关卡都设置好。

这也正是他强调的一点：“没有引导的‘氛围编程’不适合这个项目。”

在公布结果的同时，项目作者 Kurtzer 也给“AI 写系统软件”划了一条边界。他提到，许多故障并不会直接报错，而是产出一个看起来很可信的结果，却在 Linux 语义、隔离要求或生命周期行为上出错，最终得到表面能跑、结构薄弱的代码，也就是常说的“AI 垃圾”。

但他并不认为 AI 无用。相反，AI 能让经验较少的工程师更快参与有边界的实际工作，比如探索不熟悉的代码、生成测试、比较接口，以及实现已经审查过的改动。真正依赖经验的地方在于：选择什么样的抽象、判断结果是否完整、识别局部成功会不会演变成系统级风险。用他的话说，一个智能体加上一位有足够经验的人类专家，比一堆没人管的智能体走得更远。

11 天、1037 次提交：Ginux 交出了什么

在 11 天里，这个项目留下了约 13.9 万行保留代码，累计 1,037 次提交，包含 261 个跟踪文件、63 个 Rust 源文件。

最终产物可以构建成一个 GINUX.EFI 镜像，通过 UEFI 直接启动，不需要先有一个 Linux 宿主内核。UEFI 是现代电脑固件启动系统时使用的标准接口；换句话说，它把自己做成了一个可直接被固件拉起的系统，而不是跑在现成 Linux 上的一个程序。

Ginux 能运行彼此隔离的“域”（domain）。每个域有自己的进程、地址空间、文件系统和生命周期。项目称，这种隔离边界比 OCI 容器或 Linux 命名空间更强。OCI 镜像是 Docker 等容器工具通用的镜像格式，可以理解为“容器世界的标准安装包”。

它还能拉取并校验 OCI 容器镜像，用镜像内容组装域的根文件系统。借助这项能力，Ginux 可以启动 Rocky Linux 10，并一路运行到 systemd 的 multi-user.target，也就是通常的多用户命令行运行级别。部分 Alpine Linux 程序也能跑起来，例如 musl 和 BusyBox。

性能方面，项目做了一份与 Rocky Linux 的对比测试。测试环境是在 Apple Silicon Mac 上用虚拟机模拟，只分配 1 个 CPU 核心、2 GiB 内存，两边运行同一个测试程序。启动速度上，Ginux 把 Rocky Linux 10 带到可登录状态用了 12.9 秒，Linux 内核用了 42.6 秒，前者快约 3.3 倍。不过这个数字只能作为参考：Ginux 启动时不需要再加载内核，文件系统也是现成缓存的。真正可比的是跑分——三秒 sysbench 测试，每个系统测九次取中位数，结果如下：

在这三项测试里，Ginux 已经和 Linux 很接近：CPU 和线程项略高，内存项略低，差距都在个位数到十几个百分点之间。

这次实验的 API 调用费用约为 8000 美元。代码采用 Apache 2.0 许可证，托管在 GitHub 上。

代码不是护城河

Ginux 发布后，Kurtzer 在技术报告里写下一句判断：“更重要的启示是，AI 能够生成复杂的系统软件，但兼容性、安全性、硬件支持、标准、社区和长期维护，依然构成真正的护城河。”

做一个小型可运行内核，本身不难；维护一个生产级内核，是另一回事。要支持各种硬件和工作负载，保持接口稳定，修缺陷，协调贡献者和厂商，还要有可靠的发布节奏。真正难的是工作流、兼容性、维护和社区。

AI 生成软件带来的竞争压力，可能最先落在中间件和编排层，因为这些层级替换软件时，不必连整套硬件和系统生态一起搬。基础软件当然也能重写，但一套基础设施能不能被采用，看的是标准、接口、认证、硬件适配、社区能否延续、有没有商业支持。Kurtzer 强调：“缺少生态，创新本身价值有限。”

Linux 就是最清楚的例子。它的价值远不止启动一个 shell 所需的那点源代码——它为不同处理器、设备、文件系统、虚拟机、发行版、厂商和应用提供稳定预期。Ginux 还没有可比的硬件矩阵、标准组织或社区，没法承诺今天跑的程序明天还能跑。AI 可以造出技术组件，但要让这些组件被真正采用，还得有多个独立组织共同支持同一套契约。

在这份 13 页技术报告的结尾，Kurtzer 写道：AI 已经能写系统栈深处的代码了。但基础设施的核心价值，来自兼容性、硬件支持、审查、社区信任和长期责任。Linux 是靠几十年的人类工程实践，才在庞大的工作负载范围内攒下这些品质。

参考链接：

关键要点

查看原文