曾创立 CentOS、Rocky Linux 和容器项目 Singularity 的开源基础设施老兵 Greg Kurtzer，刚刚对自己发起的开源项目 Ginux 踩下了急刹车。他宣布永久冻结那个可以通过 UEFI 直接启动、能够跑起 Rocky Linux 10 用户态的独立 Rust 内核，把代码归档进 bootable-kernel-final 标签；重生后的 Ginux 降维成一个普通的 Linux 宿主进程，作为用户态内核夹在宿主机与受管负载之间，专门靠拦截系统调用来充当 AI Agent 沙箱。表面看这是一次优雅的架构收敛，实则是 Kurtzer 用编码 Agent 在 11 天内刷出 13.9 万行代码后，撞上底层系统安全铁板的一次务实自救。
搜 Ginux 的开发者最需要看清它的真实水位。在这场“人类指导的智能体工程（HDAE）”第一阶段实验中，AI 确实对 Linux 6.12 x86-64 的 375 个系统调用做了分类处理（82 个完整实现、245 个部分实现、48 个策略拒绝），但写得快不等于能上线。转型后的 Ginux 依靠 x86-64 解释器与原生 ptrace 后端拦截调用，相比早在 2023 年年中就因性能开销淘汰 ptrace、换用 Systrap 的同类标杆 Google gVisor，Ginux 不仅在底层拦截机制上慢了一代，其 thread-yield 基准测试也仅达到原生的 0.917–0.953 倍，还没跑进自己设定的 4% 损耗预算。
4.4 万行巨型模块与内核老兵的一盆冷水
单看项目主页，读者很容易把这次转型当成一次未雨绸缪的架构升华；但把时间线拉回 2026 年 10 月底就会发现，真正促成弃核的是 Linux 内核开发者 Richard Weinberger 的一次代码审查。Weinberger 肯定了该内核能够引导起 Rocky Linux 的成果，但随即扒开了 AI 生成代码的底裤，指出其中充斥着大量全局状态、单 CPU 假设、缺乏锁机制与对称多处理（SMP）支持，甚至塞进了一个约 44,000 行的庞大 x86-64 模块，在特权入口处理和用户态内存访问上存在明显弱点。
Kurtzer 在 2026 年 10 月 30 日把这份严厉的审查意见喂给新一轮 Agent 开发周期，并在 10 月 31 日合并了加固内核入口与 SMP 操作的 PR #7。然而仅仅过了五天，这版独立内核的贡献就在太平洋时间 11 月 4 日 23:59 永久截止，11 月 5 日项目便公开转向用户态垫片架构。
跑通 systemd 的功能门禁，拦不住特权边界上的安全漏洞。
这记急转弯给所有迷信 AI 编程的团队上了一课。用 Rust 编写加上通过可执行测试门禁，只能证明代码能跑通快乐路径（Happy Path），却无法自动换来内核级的并发安全与特权隔离。不过 Kurtzer 也借此跑通了另一种工程账本，即当 13.9 万行底层代码只需要 11 天就能由 AI 生成时，它就不再是必须死磕到底的沉没成本，而成了用完即弃、拿来探明架构边界的可执行证据。
故意打破 Linux ABI，这回是为了关住 AI Agent
想明白没必要去跟积累了数十年的 Linux 硬件与社区生态硬碰硬后，Kurtzer 找到了一个恰逢其时的切口，那就是用版本化的实例契约把 AI Agent 关进笼子。Linus Torvalds 为 Linux 立下的铁律是绝不破坏用户空间（ABI 稳定），但对一个能自己敲命令、改文件、开网络连接和拉起子进程的 AI Agent 来说，完整的宿主机 Linux ABI 反而成了过于宽泛的攻击面。
新版 Ginux 干脆反着来，核心逻辑就是故意且有选择地打破完整 Linux ABI 承诺。它作为一个受信任的普通宿主进程运行，底下托管着达到 multi-user.target 的 Rocky Linux 10 实例（虚拟 PID 1），并在契约中把系统调用拆成三条路径：由 Ginux 自身状态直接回答的模拟（Emulate）、验证翻译后做窄化宿主操作的中介（Mediate），以及直接报错或杀任务的拒绝（Deny）。运维人员可以给某个 Agent 写死一份 TOML 契约，只许它读时间、改指定的单个工作目录，同时在内核视图层直接掐断修改时钟、扫宿主目录或开未授权监听端口的通道，并把每一次契约判定写进独立的 audit.log。
- 洞见.给 AI Agent 做沙箱，与其在容器里用
seccomp给庞大的宿主机 ABI 打黑名单补丁，不如在用户态内核层给每个任务发一张最小可用契约的白名单门票。
对比 gVisor：重拾 ptrace 的性能账与直通妥协
尽管裁剪 ABI 的思路切中了 Agent 基础设施团队的痛点，但现在就把 Ginux 当成生产级沙箱还为时过早。把它和业界成熟的应用内核 Google gVisor 摆在一起，就能看清两处硬核代差：
| 对比维度 | Ginux（当前主线） | Google gVisor |
|---|---|---|
| 默认拦截后端 | x86-64 解释器 + 原生 ptrace | Systrap（2023 年中期淘汰 ptrace）或 KVM |
| 系统调用放行策略 | 默认 selective 模式允许安全调用直通宿主 | 独立实现应用内核边界，不依赖直通妥协 |
| 性能与安全成熟度 | thread-yield 为原生 0.917–0.953 倍，无第三方渗透测试 | 生产环境大规模验证 |
为了绕开 ptrace 频繁上下文切换带来的高昂代价，Ginux 把默认系统调用控制设为了 selective（选择性）模式。只要实例契约允许，且 Ginux 的版本化目录将某个操作归类为直接安全（direct-safe），该调用就会直接放行给宿主机内核执行；只有显式开启 paranoid（偏执）模式，所有系统调用才会百分百走完 Ginux 的用户态决策路径。这种拿暴露部分宿主接口去换性能的折中，加上在 macOS arm64 上跑 QEMU TCG 模拟 x86-64 时连跑一次上游 dnf update 都要耗费好几分钟的现实，决定了它目前还只是一块试验田。
- 风险.Ginux 官方安全文档已明确声明，该项目尚未经过独立安全审查、形式化验证或第三方渗透测试，宿主机执行服务与
ptrace依然是暴露的攻击面，切勿在生产环境中用它隔离不可信的 AI Agent。
对于正在为 AI Agent 选型执行沙箱的基础设施团队来说，短期内的生产预算依然应该投给 Firecracker 微虚拟机或 gVisor。Ginux 接下来真正值得盯住的指标只有两个，一是它能否修补 Gate 11 测试中 thread-yield 超出 4% 损耗预算的短板，二是那套把文件系统、网络、设备与系统调用打包在一起的单文件 TOML 契约，能不能在首轮外部攻防渗透测试中活下来。