Linux内核也能造了？Codex 11天写出13.9万行新内核，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 ABI，即已编译程序与内核通信的二进制接口，因此现有的 Linux 二进制程序无需任何修改，即可直接在 Ginux 上运行。
1. C 编译器给了他信心，内核则留下一个问号
Kurtzer 的这个项目有一个参照对象：Anthropic 的 Nicholas Carlini 曾借助 16 个并行运行的 Claude 智能体，从零创建了一个 C 编译器。那项实验耗费了近 2000 个会话、约 2 万美元，生成了约 10 万行 Rust 代码，能够编译大量软件，其中包括 Linux 内核构建过程的大部分内容。编译器测试套件和参考工具提供了强有力的验证依据。
Ginux 面临的任务则更难验证：从零搭建一个内核，并让未经修改的 Linux 用户空间程序在其上运行。Linux 程序能否正常工作、systemd 能否成功启动，成为检验系统真实功能的关卡。
Kurtzer 在技术报告中将研究目标拆解为三个问题：在能力层面，HDAE 能否产出独立内核，使其启动并运行部分未经修改的 Linux 发行版工作负载？在方法层面，要持续推进这项工作，需要哪些文档、引导方式、可执行关卡和反馈循环？在结果质量层面，最终系统的兼容性与性能如何？这些结论适用于何种范围？
他试图探究：当领域专家明确架构、约束、里程碑和验收标准后，AI 能够将系统软件推进到何种程度。
Kurtzer 曾参与 Caos Linux、CentOS 和 Rocky Linux 的建设，并拥有 Singularity/Apptainer、Warewulf、Perceus 及生产基础设施运维经验。这些经历对 Ginux 的启动流程和验收标准产生了直接影响。
2. 一个智能体，11 天，13.9 万行，关键在“领域专家”引导
此次实现几乎所有工作都在一个持续运行的 Codex 任务中完成，使用的是 GPT-5.6 Sol。Kurtzer 的原话是：“作者负责设定架构、系统操作、解读结果，并作出最终验收决定。”
人类角色在 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 是依靠几十年的人类工程实践，才在庞大的工作负载范围内积累下这些品质的。
参考链接：
https://zenodo.org/records/23682548
https://github.com/gmkurtzer/ginux
https://itsfoss.com/news/ginux/
本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：Tina，36氪经授权发布。