“就算给模型无限 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 发行版工作负载？在方法上，要让这项工作持续推进，需要哪些文档、引导方式、可执行关卡和反馈循环？在结果质量上，最终系统的兼容性和性能如何？这些结论适用于什么范围？
他想知道：当领域专家把架构、约束、里程碑和验收标准定清楚后，AI 能把系统软件推进到哪一步。
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 是靠几十年的人类工程实践，才在庞大的工作负载范围内攒下这些品质的。
参考链接：
https://zenodo.org/records/23682548
https://github.com/gmkurtzer/ginux
https://itsfoss.com/news/ginux/
https://www.it-connect.tech/ginux-centos-founder-builds-a-linux-compatible-rust-kernel-in-11-days-with-ai/