syzbot AI 补丁生成与审阅流程：两阶段流水线与邮件指令实战指南

• 网络安全
• 开发工具
• 质量保障

导读

本文讲解 syzkaller 项目中syzbot如何利用 AI 自动调查内核缺陷并生成修复补丁，以及补丁在进入 Linux 内核社区之前所经过的"内部审核 → 上游提交"两阶段流水线。你将掌握审核者通过邮件与 AI 协作的完整操作方式（#syz upstream、#syz reject、#syz unreject三个核心指令）、补丁版本追踪与 tag 累积机制，以及背后的系统约束与源码实现依据。

背景：AI 补丁从生成到社区

syzbot是 syzkaller 项目中的持续模糊测试与缺陷报告机器人（相关说明见 docs/syzbot.md）。除了报告崩溃、自动复现与二分定位外，它还会在调查内核 bug 时尝试用 AI 生成修复补丁。

由于补丁最终要进入 Linux 内核社区，质量与流程必须符合内核社区的协作标准（例如内核文档中的 AI Coding Assistants 规范——需要有人类开发者对 AI 生成的内容负责签名）。因此整个 AI 补丁流程被设计为两阶段工作流：

1. Moderation（审核阶段）：新生成的补丁先投递到内部审核邮件列表（syzkaller-upstream-moderation@googlegroups.com），由人类审核者与 AI 协作、提出反馈、触发自动修订。
2. Upstream submission（上游提交阶段）：补丁经人类开发者审阅并签名（Signed-off-by）后，才会被发送到 Linux Kernel Mailing List（LKML）及相关子系统列表。

一旦补丁进入上游，就遵循标准内核审阅流程：签名开发者扮演提交者角色，负责处理评审反馈、讨论以及后续修订。

两阶段流水线的详细工作流

阶段 1：Moderation（内部审核列表）

新生成的补丁首先被发送到内部审核邮件列表，bot 会在该列表上主动监听并参与讨论。审核者可以通过回复邮件与 AI 交互：

提供反馈、请求修改：直接以普通文本评论回复补丁邮件。AI 模型会读取这些评论并给出文字回复，或者在必要时发送新版本补丁（例如 RFC v2）。

拒绝有根本缺陷的补丁：

#syz reject

可在邮件正文中附加拒绝原因，便于系统留痕。补丁一旦被拒绝，AI 将停止对该版本补丁后续评论的响应。

撤销误拒绝：

#syz unreject

批准补丁并推送到公开列表：

#syz upstream

阶段 2：LKML（Linux Kernel Mailing List）

补丁在审核列表获得批准并被 upstream 后，会发送到公开邮件列表（LKML / 子系统列表）。

关键约束：syzbot不会在 LKML 上自动回复评审意见，也不会自动提交补丁迭代版本。签名开发者负责回应评审反馈、回答问题并提交必要的后续版本。虽然 syzbot 管理员会主动监控上游补丁，并在内部酌情手动触发 AI 迭代，但 LKML 上的所有交互与补丁提交均保持人工驱动。

系统不变量与规则

syzbot基于邮件回复对 AI 补丁的追踪与处理维持着一套严格的规则。

我在与哪个补丁版本交互？

每个补丁版本（如 v1、v2）都作为独立的邮件线程发送。syzbot使用In-Reply-To邮件头来精确识别你正在交互的是哪个补丁版本。在源码层面，邮件线程的解析正是建立在In-Reply-To头之上：例如 pkg/email/lore/parse.go 使用 Message-ID 与 In-Reply-To 构建祖先消息图，pkg/email/action.go 也直接依赖msg.InReplyTo判断回复目标。

因此，你可以回复任意补丁版本的线程（不必是最新的）。#syz upstream、#syz reject等指令只会作用于你回复的那个具体版本。

能否同时 upstream 同一补丁的多个版本？

不能。为避免刷屏上游列表，syzbot阻止同一 bug 的多个补丁迭代同时 upstream。

例如：你先把 "v1" 送上上游，后来觉得 "v2" 更好，此时对 "v2" 执行#syz upstream会被拦截。你必须先回复之前已 upstream 的版本（"v1"）并执行：

#syz reject

拒绝后系统会清除冲突，然后你就能成功对 "v2" 执行#syz upstream了。

在实现上，determineNextStage（见 dashboard/app/ai_report.go）会检查目标阶段之后是否已有其他阶段被上报，若有则返回ErrCannotUpstream拒绝推进。

我的 Reviewed-by / Acked-by 标签会怎样？

评审过程中，审阅者经常提供标准标签，如Reviewed-by:、Acked-by:、Tested-by:、Reported-by:、Suggested-by:。syzbot会自动解析并累积这些标签；当生成补丁的新迭代版本时，这些标签会被可靠地保留，并追加到提交信息的 trailer 中。在 dashboard/app/aidb/crud.go 中可以看到，迭代作业会读取上一版本的ReviewedBy、AckedBy、TestedBy等标签作为下一轮的BaseReviewedBy等输入；补丁产出时这些字段又会经 dashboard/app/ai_report.go 的makeNewReportResult重新写入新的报告结果。

谁获得 Signed-off-by 标签？

当你回复#syz upstream批准补丁时，syzbot会把你提供的邮箱与姓名整合成标准的Signed-off-by:标签，并在补丁进入下一阶段（如 LKML）时追加到提交信息中。若补丁在公开列表上继续迭代，该Signed-off-by:标签会一直保留。

源码佐证：processUpstreamSubcommand中通过email.FormatAddress(req.AuthorName, req.Author)生成上游签名者（见 dashboard/app/ai_report.go），并存入JobReporting.UpstreamedBy字段；上报结果时这些作者会被转成邮件收件人（To/Cc）与 Git 补丁元数据Authors（dashboard/app/ai_report.go），确保签名归属与补丁头一致。

如果我回复了邮件但没有带任何指令？

在审核列表上：你的回复会被记录为该 AI 补丁作业的评审反馈。syzbot会触发一个迭代作业，由 AI 评估你的评论、回应问题或修改请求，并在适当时发送新版本补丁（同时累积你提供的Reviewed-by等标签）。普通回复不会推进（#syz upstream）或拒绝（#syz reject）补丁。实现上，handleCommentCommand（dashboard/app/ai_report.go）将评论正文存入文本存储并调用aidb.SaveJobComment，仅记录为评论，不改变上报状态。

在 LKML / 公开列表上：syzbot不会自动回复或迭代；反馈由签名开发者直接处理。

上游提交有哪些要求？

AI 作业必须成功产出了补丁。你不能对只回复了文字评论、没有代码改动的 AI 运行执行#syz upstream。实现上，checkJobUpstreamable（dashboard/app/ai_report.go）会校验作业类型必须是 patching 或 patch-iteration，并且作业结果中的PatchDiff非空，否则返回ErrCannotUpstream。

另外：如果你发送#syz upstream后没有收到回复，说明指令已成功处理。系统不会发确认邮件，它只是把补丁推送到下一个上报阶段。类似地，命令执行失败时系统会回复失败原因，例如 "Cannot upstream a rejected patch. Unreject it first."（拒绝后未撤销就 upstream）或 "Cannot unreject a patch that is not rejected."（对未拒绝的补丁执行 unreject），这些场景均有测试覆盖（见 dashboard/app/ai_report_lore_test.go）。

命令授权与防重机制

为保证指令可信，系统提供两层防护：

• 作者授权：checkActionAuthorized（dashboard/app/ai_report.go）在命名空间配置了AI.AllowedCommandAuthors时生效——邮件必须通过 DKIM 认证，且发件人邮箱或其域名必须位于允许列表中，否则命令被忽略。
• 幂等去重：apiAIReportCommand（dashboard/app/ai_report.go）会通过aidb.IsCommandProcessed检查同源同 Message-ID 的命令是否已处理，已处理则直接返回空响应（幂等 no-op），避免重复执行。

流水线的可配置化：AI 阶段配置

上述 "审核列表 → 公开列表" 的两阶段结构并非硬编码，而是由仪表盘配置驱动的（AIConfig/AIPatchStageConfig，定义见 dashboard/app/config.go）。每个阶段（stage）可配置：

上报推进逻辑依据阶段顺序：processUpstreamSubcommand通过determineNextStage找到当前阶段的下一个阶段并创建JobReporting记录（dashboard/app/ai_report.go），从而天然形成流水线。

此外还有几个整体开关：AIConfig.UploadPatchesToGerrit控制是否把补丁上传到 gerrit，AutoReproC控制是否自动为符合条件的 bug 创建 C 复现器生成作业，BaseRepository/BaseBranch/BaseCommit作为 patching 工作流的基础输入（见 dashboard/app/config.go）。

手动操作：Web UI 上的等价动作

除了邮件指令，拥有 AI 操作权限的用户（hdr.AIActions）也可以在 Web UI 上对 AI 作业执行等价操作（见 dashboard/app/ai.go）：

• restart：重启作业（需满足可重启条件）；
• push_to_reporting：将已完成的 patching 作业手动推送到上报阶段（等价于 web 来源的#syz upstream，dashboard/app/ai.go）；
• set_correctness：标记补丁正确（触发上报）或不正确（触发拒绝）。

实战总结

• 在审核列表上，普通文字回复 = 给 AI 的评审反馈；#syz reject= 拒绝（AI 停止响应此版本）；#syz unreject= 撤销拒绝；#syz upstream= 批准并推送至下一阶段。
• 版本追踪依赖In-Reply-To头，回复哪个线程就作用于哪个版本。
• 同一 bug 同时只能有一个版本在上游，先#syz reject旧版本再#syz upstream新版本。
• 标签（Reviewed-by 等）由系统自动累积并保留到新版本；#syz upstream时你的身份会成为补丁的Signed-off-by。
• 补丁一旦进入 LKML，所有交互回归人工：签名开发者负责后续一切评审沟通与修订。

• 网络安全
• 开发工具
• 质量保障