用 Codex 做 Linux 内核开发：四 Agent 工作流与崩溃留证实践

把 AI 编码工具用在内核开发上，和写业务代码是完全两回事。业务代码跑挂了看一眼堆栈就能改，内核驱动跑挂了，轻则串口刷屏后再无声息，重则整块板子卡死、要人跑去断电重启。一旦调试回路被打断，Agent 再能干也推进不下去。

有一份实践分享把这件事跑通了：在 RK3588 开发板上做 Linux 内核驱动，用 Codex 承担绝大部分编码工作，靠四个 Agent 角色分工协作，同时把「崩了也能自己爬起来、并且留下证据」当成工作流的前置条件。下面把它拆成可复用的做法，并补上几个值得提前想清楚的取舍。

四个 Agent 怎么分工

这套流程把所有 Agent 的推理强度都拉到最高档，然后用角色把职责切开：

| 角色 | 主要职责 | 关键约束 | | --- | --- | | 调度（主） | 接收需求、拆任务、分派、汇总上下文 | 全局信息只有它一份，任何结论都要回灌给它 | | 计划 | 出实现方案、评估改动范围与风险 | 先出方案再动手，不允许直接改代码 | | 执行 | 写代码、编译、加载模块、跑测试 | 只做被分派的子任务，不擅自扩大范围 | | 审核 | 复查改动、找遗漏与破坏性修改 | 独立于执行，避免自己批自己 |

角色的实现方式有两种常见选择。靠系统 prompt 或固定指令模板约定身份，成本低、上手快；用 Codex 的 subagent 机制把不同角色拆成独立会话，隔离性更好，主会话的上下文不会被中间过程撑爆。两者可以混用：调度与审核用 subagent，计划与执行在同一会话里按模板切换。具体配置方式以官方文档为准，不建议照抄别人的 prompt。

真正决定成败的不是角色数量，而是上下文纪律：执行 Agent 的输出往往是几百行编译日志，把这些原样丢回调度 Agent，几次就把它淹没了。可行做法是让执行环节自己提炼「改了什么、编译是否通过、报了什么错、下一步建议」，只把这段摘要回灌主线。

崩溃留证：三项必须提前做的准备

内核开发里 Agent 最容易浪费时间的地方，是崩溃之后没人知道发生了什么。三项准备基本属于开跑前的硬性要求。

1. 看门狗保证板子能自己起来

硬件看门狗或内核 watchdog 的作用是超时未喂狗就强制复位。配上开机自启，板子从「人肉断电」变成「等几十秒自己回来」，Agent 才能在无人值守的情况下连续试错。

注意两点：编译、烧写这类长任务期间要预留足够的超时余量，否则正常流程也会被复位打断；另外要确认复位后驱动加载、网络、串口是否都能自动恢复，否则等于白重启。

2. pstore/ramoops 保证日志不丢

内核 panic 时，串口输出是最直接的线索，但无人值守场景下没人盯着串口。pstore 的思路是把 oops/panic 日志写进一块预留内存，重启后还能读回来。典型配置是在设备树里预留一段内存并声明 ramoops 兼容节点，指定日志记录区与控制台区大小，同时打开内核配置：

CONFIG_PSTORE=y
CONFIG_PSTORE_RAM=y

重启后到 /sys/fs/pstore/ 下取文件即可。几个容易踩的坑：预留区太小会被截断；内存复用配置不当会让日志被覆盖；只留 ramoops 而没有持久化存储，掉电久一点仍然可能丢。串口日志同步落盘到另一台机器，是最稳的兜底，值得保留。

3. 驱动编译成模块，别一开机就崩

把正在开发的驱动编成 =m，而不是 =y，效果很直接：开机流程干净，出问题的只是加载那一步；改完代码 insmod / rmmod 就能迭代，不必整机重启。

代价是要管住版本匹配这件事——模块的 vermagic 必须与当前运行的内核一致，改了内核配置或版本后要重新编译并用 depmod 更新，否则会看到一堆「invalid module format」。把这套加载、卸载、看日志的动作写成一两个脚本，交给执行 Agent 调用，比让它每次自己拼命令稳得多。

调试在哪跑：QEMU 还是真板

这是新手最常问的问题，答案是两条腿走路，但顺序有讲究。

• QEMU：启动快、可快照回滚、崩溃不影响硬件，适合验证逻辑流程、寄存器读写路径、并发分支这类与硬件时序无关的部分。
• 真实开发板：能暴露时钟、电源域、DMA 一致性、中断延迟这类只有在硅片上才出现的问题。驱动最终一定要上板验证。

比较省时的流程是：先让 Agent 在 QEMU 里把逻辑跑通并自查，再上板验证硬件相关部分。反过来做，等于拿板子的重启时间换调试周期。

人的位置：技术路线必须有人守

一个容易被忽略的经验是：新项目前期必须盯。Agent 对单点问题的处理通常不差，但它不会主动质疑「这条路整体对不对」。一旦方向错了，后面所有子任务都会沿着错误方向高效推进，返工成本极高。

具体做法是并行开一个旁支会话，专门用来了解「现在代码实际是怎么实现的」，再和预期比对，有偏差就讨论方案，最后把结论更新给调度 Agent。不少工具支持在主线之外开侧边会话（例如 Codex 的 /side 一类命令），比另起一个会话更省事，也不会污染主线上下文。

等基本流程打通、编译烧写验证都自动化之后，人就可以退到提需求和抽查改动的角色。抽查不是走形式：看 diff、看编译告警、看审核 Agent 给出的结论是否站得住脚，这三件事不要全省。

额度和成本：够不够用

分享者使用的是较高的订阅档位，一周大约消耗六成额度，并没有全天候跑——任务通常是跑两三天就能产出可汇报的进展。也就是说，这类工作流的瓶颈一般不是额度，而是「有多少任务真的适合整段交给 Agent」。

额度紧张时的调整顺序建议是：降低非关键环节的推理强度、减少审核 Agent 的触发频率（只对涉及并发的补丁全量审）、把探索性任务放在侧边会话里做完再决定是否进主线。

适用边界与风险

这套方法能成立，和团队环境关系很大：规模小、目标是「功能先跑起来」、规范性要求不高。放到另一类环境里就要打折扣：

• 有强制代码规范、评审签字、合规审计的团队，AI 产出的责任仍然由人承担，人工评审不能省。
• 若要向内核社区提交补丁，提交信息格式、署名链、静态检查工具这一关相当严格，别指望一次生成就过，把它当成独立的、需要人工过一遍的工序。
• 关于「一个人加几个 Agent 是否等于两个人」，这是管理层的判断题。工程上更现实的收益是把重复劳动压缩，把人的时间挪到架构设计和验证上；把它当成减员工具，往往会在质量上还回来。

另外，如果任务需要连续跑几天，而本地机器会关机、网络会抖，长任务频繁中断会成为主要损耗。这种情况下，可以考虑把常驻的调度与审核环节放到一台长期在线的远程机器上跑（例如放在机房的独享远程 Mac，本地只负责刷板和硬件验证），把「机器在线」这件事从变量里拿掉。是否值得，取决于任务被打断的频率。

上手检查清单

准备开跑前，逐条确认：

• 看门狗已启用，复位后系统、网络、串口能自动恢复
• panic 后能从 /sys/fs/pstore/ 取到日志，且预留区大小够用
• 串口日志有第二份落盘备份
• 待开发驱动为模块形式，加载/卸载/取日志有现成脚本
• 四个角色各有明确的输入输出约定，执行结果只回灌摘要
• 新项目阶段每天人工检查一次技术路线，不只看代码能不能跑
• 每轮结束抽查 diff 与编译告警

小结

把 Codex 用于内核开发，真正的门槛不在模型能力，而在可观测性和可恢复性：板子崩了能自己起来、日志丢了能找回来、驱动坏了能单独卸掉。这三件事做好，Agent 的连续试错才有意义；再配上清晰的角色分工和上下文纪律，人才有空间退到「定方向、抽查结果」的位置上。工具和订阅档位的具体细节变化较快，涉及额度、模型和命令行功能的部分，请以官方最新说明为准。