CentOS founder writes 139,000-line Ginux kernel in 11 days with Codex, capable of booting Rocky Linux 10

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

但现在 Gregory Kurtzer 用自己的方式回答了这个疑问。这个名字对 Linux 圈的人来说不陌生：他是 CentOS 的创始人之一，也是在 Red Hat 决定终止 CentOS Linux 之后，一手推出 Rocky Linux 的那个人。

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

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

Ginux 拥有自己的内存管理、调度器、进程模型、文件系统、网络和设备支持，全部从头编写。

最有意思的是，Ginux 虽然不是 Linux，却兼容 Linux。它实现了 Linux ABI，也就是已编译程序用来与内核通信的二进制接口，因此现有 Linux 二进制程序可以不做修改，直接在 Ginux 上运行。

1 C 编译器给了他底气，内核给了他一个问号

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

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

Kurtzer 在技术报告里把研究目标拆成了三问：在能力上，HDAE 能不能产出一个独立内核，让它启动并运行部分未经修改的 Linux 发行版工作负载？在方法上，要让这项工作持续推进，需要哪些文档、引导方式、可执行关卡和反馈循环？在结果质量上，最终系统的兼容性和性能如何？这些结论适用于什么范围？

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

2 一个智能体，11 天，13.9 万行，关键是“领域专家”引导

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

人的角色在 HDAE 的两个互相配合的循环里：

HDAE 外部引导循环： 愿景 → 架构与约束 → 验收关卡 → 人类审查观察到的行为 → 修正、调整优先级或验收。

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

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

而 Kurtzer 的领域知识则提供了愿景、优先级和成功标准。他表示，“项目需要领域知识来选择 Linux 用户空间契约、区分 OCI 传输与运行时隔离、识别损坏的 fork/exec 行为、定义域所有权、解读 systemd 故障，并判断看似可信的输出是否符合预期。”

之所以选择 systemd 作为验收关卡，是因为它依赖大量系统组件，也是启动和运行整个系统的核心进程。不过，它在容器中启动时也很挑环境，所以 Ginux 先实现了“域”，再处理容器。

在 X 上，还有人问他为什么选 Codex。Kurtzer 说，它比较少把 token 浪费在支线上。但即便如此，他还是得经常把它拉回正轨。有些大块代码他不满意，却刻意要求自己不要亲手改——“我甚至关掉了 IDE，强迫自己别打开。这样 AI 做错时，我就只能给它新的指引；很多时候，它会把写错的代码删掉。”对方追问，实际是怎么把它拉回正轨的，是列一份禁止事项清单，还是盯着输出、跑偏就拽回来？Kurtzer 的回答很简单：关卡设得多。

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

“许多故障会产生看起来很可信的输出，却违反 Linux 语义、隔离要求或生命周期行为……最终得到那种表面能运行、结构却很薄弱，常被称作‘AI 垃圾’的代码。”

“AI 也能让经验较少的工程师更快参与有边界的实际工作，例如探索不熟悉的代码、生成测试、比较接口和实现经过审查的改动。但在选择抽象、识别结果是否完整，以及判断局部成功是否会造成系统级风险时，经验仍然至关重要。”

一个智能体加上一位有足够经验的人类专家，比一堆没人管的智能体走得更远。

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

最终，Ginux 可构建为一个 GINUX.EFI 镜像，通过 UEFI 直接启动，无需依赖 Linux 宿主内核。

它可以运行彼此隔离的“域”（domain），每个域都有自己的进程、地址空间、文件系统和生命周期。项目称，这种隔离边界比 OCI 容器或 Linux 命名空间更强。

Ginux 还能拉取并校验 OCI 容器镜像，用镜像组装域的根文件系统。借助这一能力，它可以启动 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 上。

3 写在最后：代码不是护城河

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

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

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

他强调，“缺少生态，创新本身价值有限。”

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

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

参考链接：

本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：Tina，36氪经授权发布。