两人借助编程Agent推进M4 Linux驱动

两名开发者用大约一个月，为 M4 Mac mini 和 MacBook Neo 做出了通过 OpenGL ES 3.0 一致性测试的 Linux GPU 驱动，大部分代码由 Codex 和 Claude 编写。但这个故事最有用的部分，不是「AI 一个月顶几年」，而是他们怎样让 Agent 在没有硬件文档的情况下持续验证自己的工作。

原文给出的答案很具体：已有的观测工具、前人的设计经验、成熟的测试集，再加上人类在卡住时更换方法。它展示了 AI 编程的一种有效条件，也留下了稳定性、人工审查和上游接纳等问题。

一个月做出驱动，究竟做到了哪一步

2026 年 9 月，Cody Ho 和 Niklas Sheth 发布了这项成果。Ho 用 Codex 处理内核与固件逆向，Sheth 用 Claude 推进用户态实现。

按作者报告，驱动已通过完整的 OpenGL ES 3.0 一致性测试，仍失败的测试属于可选扩展。随 Gravity Linux alpha 提供的能力还包括 OpenGL 3.3、Chrome 和 Firefox 中的 WebGL 与合成，以及 Minecraft 达到 200fps。

这些结果需要分开理解。一致性测试有明确的判定标准；200fps 则缺少分辨率、画质和测试场景，不能单独拿来衡量游戏性能。Vulkan 1.4、OpenGL 4.6、OpenGL ES 3.2、OpenCL、通过 Proton 支持 Direct3D 12，以及光线追踪，都还是待办事项。

驱动也没有进入 Linux 内核上游。它目前随 Gravity Linux 发布，这是一个从 Asahi Linux 分出的 Fedora 衍生发行版。分叉涉及贡献政策：Asahi 禁止生成式 AI 贡献，Gravity 允许，但要求披露使用情况和代码来源。

首个面向 M4 Mac mini 的 alpha 发布于 2026 年 9 月 18 日，标明「FOR DEVELOPERS」，不适合日常使用。HDMI 可用，但休眠、USB-C 显示输出、Thunderbolt 和 USB4 尚不可用；作者还提醒，alpha 到 beta 可能没有升级路径。

通过图形 API 的一致性测试，与整台机器适合日常使用，是两件需要分别验证的事。

Agent 为什么能在没有文档的情况下推进

先看驱动要打通什么。用户态的 Mesa 负责着色器编译、绘制调用转换和图形 API 实现；内核侧负责内存、调度、命令提交等工作，两侧通过 DRM 定义的 ioctl 通信。

原文用下面的结构解释各层关系：

Application (game, desktop compositor, etc.)
    |
Mesa (OpenGL / Vulkan userspace driver)
    |
DRM ioctl interface (kernel boundary)
    |
Kernel DRM driver (memory, scheduling, command submission)
    |
GPU firmware (Apple proprietary, runs on embedded processor)
    |
M4 GPU hardware

要留意 GPU firmware 这一层：Apple GPU 的固件运行在芯片内部的独立处理器上，内核驱动构造命令并交给固件，再由固件控制硬件。图里的 Vulkan 是通用架构说明，不代表这个驱动已经支持 Vulkan。

团队需要逆向的，正是这些命令和内存结构组成的协议，也就是固件 ABI。这里的 ABI 可以理解为驱动与固件约定的数据格式和调用规则。

他们报告称，实现没有查看 Apple 二进制文件，而是从真实硬件运行轨迹中推导协议；必要的 Apple 二进制组件被当作不透明对象，并由第三方记录相关信息，以支持净室逆向（clean-room reverse engineering）的过程。

具体做法有三个支点。

首先，Ho 之前已经写好了一个能运行、观测 macOS 的 hypervisor。Agent 可以直接驱动它，捕获 GPU 地址空间，并在自己的实现出错时，与已知正常样本比较。团队还自行编写小型 Metal 着色器，用尽量简单的工作负载观察内存变化。

其次，内核侧从「捕获并重放」起步：先保存完整 GPU 内存状态，重启后重放，再逐步用代码重建固件结构，直到不再需要重放。用户态则让 Agent 反复修改 Mesa，运行 Khronos 一致性测试，再处理失败项。

最后，他们沿用了 Asahi 的内核 UAPI，没有修改接口。M1、M2 驱动也帮助他们判断哪些设计方向已经得到验证。但新实现包括自己的着色器编译器和命令流构建器，并非给旧驱动调整几个偏移量。作为复杂度参照，作者称 A18 Pro 固件 ABI 的结构体数量约为 M1、M2 的 1.5 倍，指针数量约为两倍。

Agent 能持续推进的关键，是每次修改后都有工具和测试告诉它哪里错了。

最关键的人类干预，是换掉失败的方法

原文里最能说明边界的，是一次持续超过一周的失败。

Agent 捕获了一份 336 MB 的计算任务状态，但无法成功重放。它在这个方向上尝试超过一周，仍未解决。后来人类改变了采样方法：进入单用户模式，避免其他渲染任务运行，再触发一个最小 Metal 计算程序，重新捕获。

问题由此获得突破。决定性动作是减少实验中的干扰，让样本更容易解释。

作者还记录过另一次浪费：Agent 先选了最困难的子任务，损失了一天。这两件事说明，长时间无人值守的执行循环，并不自动具备可靠的任务排序和实验设计能力。

所以「一个月」必须连同前提一起读：捕获工具早已存在，Khronos 测试集早已存在，M1、M2 驱动已经探索过大量设计问题，两位开发者也能判断何时该中断 Agent、重新定义实验。

团队公开了逆向实验，供其他人核查代码来源。对于上游合入，作者表示 Mesa 侧沿用未修改的 Asahi UAPI，接口层面没有政策障碍，但仍需更多测试和人工审查；内核侧则计划等 M1、M2 驱动先进入上游。

这些条件决定了它是一项值得研究的工程成果，却还不能当作「换个模型就能复现」的通用配方。

我的判断

我认同原文强调测试基础设施的价值。GPU 驱动虽然困难，却有一个对 Agent 很有利的条件：大量行为可以交给既有的一致性测试判定。相比只凭截图判断「页面差不多了」，这种反馈更具体，也更容易形成连续迭代。

但原文没有提供人工开发、不同模型或不同工作流的对照实验，也没有披露完整的人力投入和模型成本。因此，无法据此计算 AI 提速了多少，更不能把 Asahi 的多年工作与这一个月直接相除。后来的团队已经获得了前人留下的设计地图。

测试覆盖也有边界。通过 OpenGL ES 3.0 测试，不能替代对内核内存安全、长时间运行稳定性和整机兼容性的审查。原文没有给出这些方面的系统数据。

AI 贡献政策同样不能替代技术评价。Gravity 允许使用 Agent，不等于代码天然可靠；Asahi 禁止相关贡献，也不能据此推断它的技术能力。真正值得检查的是实验能否复现、来源能否核查、失败能否解释，以及维护者是否愿意承担长期审查成本。

Ho 将成果描述为「可能是首个完全由 LLM 编写的 GPU 驱动」，但原文也记录了多次关键人工干预。更稳妥的理解是：Agent 承担了大部分代码生成，人类负责提供工具、设定目标，并在错误路径上及时转向。

能拿来做什么

• 在日常 AI 编程中，先准备可执行的验收条件，再交出大任务。例如修改 WebGL 相关逻辑时，给出最小复现、预期输出和失败样本，让 Agent 能逐步验证。
• Agent 长时间修不好问题时，检查实验是否太复杂。这个项目从 336 MB 捕获转向最小 Metal 程序的经验，可以迁移为缩减输入、隔离并发任务和减少环境干扰。
• 在 M 系列 Mac 的 Linux 虚拟机或容器里运行图形应用前，先核对虚拟化栈实际暴露了哪些 GPU 能力。原文提到 QEMU 与 VirtIO GPU 等方案存在差异，宿主机有 GPU 不等于客户环境已获得所需加速。
• 试用早期驱动时，选择专用实验环境并保留磁盘快照，用 dmesg -w 观察内核日志。这个项目是在真实硬件上借助专用 hypervisor 迭代，不能把普通虚拟机快照当成已经验证过的替代方案。