PatchPilot：内核补丁如何从修改走向交付终点

内核补丁的交付从来不是一次 diff 应用那么简单。上游修了问题，下游产品却可能维护着不同的内核版本，同一个补丁拿过来，函数重构、字段演化、前置提交缺失，任何一个障碍都可能让工程师陷入反复分析与修改的循环。B站分享的 PatchPilot Agents 实践，试图用可编排、可验证的流程把补丁从“代码改完”推进到“真正交付”。

补丁交付的难点：应用成功不等于问题解决

补丁能被工具接受，只能说明格式上没冲突，并不能独立证明原来要修的问题已经解决。原文提醒，AI 可能遗漏关键改动、产生代码漂移，甚至生成上游并不存在的实现。自动解冲突如果只盯着报错消失，交付质量就无从谈起。

工程上可以把判断拆成三层：修改是否落到预期位置，目标版本是否保留了修复所需的条件，后续检查是否支持交付。后两层需要代码与验证证据。这个拆分解释了为什么“一次命令成功”不能直接等同于“任务完成”——它只是流程中的一个中间状态。

上游（upstream）与下游（downstream） 是内核开发中的基本关系：上游通常指 Linus Torvalds 维护的主线内核及稳定分支，下游则是各类产品内核（如 Android 通用内核、发行版内核、厂商定制内核）。下游会从上游 cherry-pick 补丁，但由于下游可能长期停留在旧版本并叠加大量定制修改，上游补丁往往无法直接应用。补丁能否干净应用取决于目标代码上下文是否与上游一致，而即便应用成功，也不代表修复所需的代码路径、配置或依赖在目标版本中存在。

Cherry-pick 是 Git 中将某个提交单独复制到另一分支的操作，常用于把上游修复回移到下游版本。它只移植该提交本身的改动，不自动带上它所依赖的前置提交，因此缺失依赖是下游移植中最常见的问题之一。

Patch Palette：把交付拆成有状态的多阶段流程

PatchPilot 的 Patch Palette 将补丁交付组织为多个阶段：获取补丁、分类冲突并理解意图，做可行性分流与依赖分析，再进入 AI 解冲突、语义审查和交付回检。每个阶段都有明确的输入、产出和状态。

价值不在于画出一张流程图，而在于前一阶段的产物成为下一阶段的依据。已确认的依赖清单和尚未完成的冲突处理，应当被识别为不同进度。只有这样，系统才能知道任务卡在哪里、恢复时还缺什么。原文没有披露完整的数据表或接口实现，但状态驱动设计的意图是清晰的。

失败任务自动分流：把昂贵推理用在刀刃上

系统先用启发式规则评估冲突规模、缺失符号、危险变更和补丁复杂度，再把处于模糊区间的任务交给语言模型进一步判断。分流不是提前宣告成功，而是选择后续路径——风险很高的改动，即使模型能提出修补方案，也可能应当交给工程师。

这里体现的是自动处理范围的判断。架构差异、语义取舍和风险决策被流出人工出口，使模型的可执行范围与最终责任保持清楚的对应关系。要验收分流是否有效，可以检查每个任务是否留下分流依据：涉及哪些冲突、命中了什么规则、为什么需要进一步分析、最终进入了哪条路径。原文没有给出具体阈值，更稳妥的做法是用自己维护版本的历史任务观察哪些类型经常需要人工介入，再逐步调整边界。

意图分析与依赖分析：先理解“为什么改”

进入解冲突之前，系统先分析补丁意图——原来的修改为什么存在，而不是只观察冲突两侧怎样拼起来。比如一个条件检查的位置发生变化，真正需要保留的可能是某条执行路径上的约束。意图描述应当能指向相关代码、变更范围和需要维持的行为；如果只剩下“修复某个问题”这样的空话，后续审查就无从判断实现是否偏离。

依赖分析则被原文称为“状态优先”。只搜索缺失符号有时会漏掉代码演化带来的真实冲突，因为名字存在不等于实现满足补丁预期。系统会比较函数实现、结构体字段和函数签名的状态偏离，再定位必要的前置提交。关键在于，找到真实提交并不自动证明它就是必要依赖，仍需与补丁意图、目标代码状态相互核对。

原文还提醒，只按缺失符号打补丁可能让依赖链不断膨胀——一个补丁引入另一个提交，后者又依赖更大范围的重构，任务很容易从修复问题演变为搬运一段上游历史。为避免模型凭经验补全不存在的前置变更，系统要求通过 Git 工具精确枚举提交标识，让工具提供可追溯的事实，推理负责解释事实之间的关系。

前置提交（prerequisite commit） 指某个补丁在逻辑上依赖、但未包含在该补丁 diff 中的其他提交。例如目标函数在一个更早的提交中被重命名、结构体字段被增删、或某条错误路径被重新组织，这些变化如果缺失，补丁的修改就会落到错误位置或无法编译。依赖分析的目标是定位这些前置提交并判断它们是否真的必要。

按冲突块推理 中的“冲突块”对应 Git 合并冲突中以 <<<<<<<、=======、>>>>>>> 标记分隔的每一段冲突区域。一个补丁可能产生多个冲突块，逐块处理能把大范围推理拆成可独立检查的小单元，也便于记录每块的方案与失败原因。

按冲突块推理与结构化失败记忆

PatchPilot 按冲突块进行推理，一个冲突块对应补丁中需要处理的一段修改，缩小范围让每轮方案更容易检查。原文要求保留处理方案、失败原因与改动范围，这意味着局部处理并不脱离上下文——前面识别的修复意图、代码状态和依赖关系仍然约束着这一块怎样修改。

多轮尝试中常见的浪费是模型反复走进同一条无效路径。结构化失败记忆保存每轮方案、失败原因和改动范围，让下一次尝试带着这些信息继续。关键是失败记忆要提供能改变后续行动的证据，而不只是一个“失败”标签。工程上可以先判断失败发生在哪一层：执行前提不成立时重新生成相同代码很可能没有意义；缺少必要依赖就应回到状态分析；修改方案违反修复目标才需要调整实现路径。原文没有披露最大重试次数，可以验收的是后一次尝试是否利用了前一次结果、是否说明改变了什么、多次失败后是否有清楚的人工升级出口。

交付回检：残留冲突、代码漂移与语义审查

执行后首先检查残留冲突标记。这类检查直接而重要——看似完成的文件仍可能保留工具产生的分隔符，应当优先把容易确定、能自动检测的问题交给明确步骤，避免让模型凭阅读印象宣布通过。但清理标记只是基础门槛，不能证明实现正确。

代码漂移检查关注的是：为适配目标版本而修改代码，需要有理由；如果模型顺手改了其他逻辑，也需要解释为什么属于当前任务。

审查时可以对照原始补丁、已确认依赖和最终差异，逐项询问额外变化的必要性。某个差异没有出现在上游并不必然错误，因为目标版本可能确实需要适配，但它应当能说明依据并接受相关验证。原文没有给出漂移检测的完整规则，落地时仍需结合仓库特点建立检查范围。

语义审查则把前面写清楚的补丁意图作为对照依据。原文把语义审查放在流程中，但没有披露完整评测样本或证明方法，因此不能把它解释为系统已经证明所有补丁都正确。可以围绕修复目标列出应当维持的行为，寻找代码分析、构建或相关测试能提供的证据，并把未覆盖的情况留在结果里。对于不容易自动判断的语义取舍，升级工程师比给出过强结论更有价值。

代码漂移（code drift） 在本文语境下指为解决冲突而引入的、超出原始补丁意图的代码变化。它可能表现为顺手格式化、改动无关条件判断、调整日志文本，或引入目标版本并不需要的适配逻辑。漂移并非总是错误——下游版本确实可能需要适配——但它必须可解释、可追溯，并能对应到具体的版本差异或依赖缺失。审查时把最终差异与原始补丁、已确认依赖逐项对照，是发现无依据改动的实用手段。

成功定义在端到端交付，而不是一次执行

PatchPilot 把成功定义在端到端交付上。回合成功后，系统自动创建检测轮次、回检拉取请求与交付状态，并关联任务、日志、审查结论和最终结论。生成修改、提交审查和最终合入属于不同事件，任务状态应当随后续证据推进，而不是在第一次执行成功时就结束。如果检测失败，任务需要返回相应处理路径；如果仍在等待评审，也应如实展示等待状态。这样维护者看到的是距离交付还差什么，而不是一批表面成功、实际悬在中间的任务。

运行保障：持久化状态与恢复的工程细节

PatchPilot 通过持久化状态管理执行与恢复，避免中断后任务悄然丢失。恢复不应简单理解为把所有步骤从头再跑——恢复前需要确认已完成哪一阶段、留下的代码和审查产物是否仍然对应当前任务、接下来应当从哪里继续。

如果目标分支已经变化，过去的结果可能需要重新核对。原文没有公开状态机的具体字段，也没有说明所有恢复条件，但方向是明确的：让进度、产物和异常具有持久记录，使调度依据真实状态工作，而不是依赖某个进程一直活着。

面对多个内核版本和大批量补丁，去重、调度恢复与超时处置直接影响交付可靠性。同一个补丁送到不同目标版本可能是不同任务，重复提交同一个目标任务又可能造成额外修改或重复评审，因此去重需要依据业务任务身份，而不能只比较一段提示词。超时同样需要区分还在运行、暂时不可观测和已经失败。验收要求是每个任务都能找到当前进度和明确后续动作，异常不会把它留在无人知道的中间状态。

幂等性（idempotency）与任务去重 在批量补丁交付中紧密相关：同一个业务任务被重复提交时，系统应识别为同一任务而非新建任务，否则可能产生重复修改、重复评审或相互覆盖的提交。判断任务身份应基于仓库、目标分支、补丁标识和任务来源等业务键，而不能只比较提示词文本，因为相同意图的提示词可能对应不同目标版本，反之亦然。

持久化状态机 把任务进度、产物引用和异常信息落盘，使调度器依据存储中的真实状态而非进程内存来推进任务。恢复时先读取最后一致状态，再校验遗留产物是否仍对应当前目标分支，从而避免从头重跑或错误续跑。

如何衡量效果：避免只看单点成功率

原文提出同时观察效率、成本、交付率、人工升级率和反功率，避免只看单点成功率。文章并没有给出可直接比较的统一线上规模或量化收益，因此这里不做效果承诺。指标还需要清楚定义分母和终点：交付率统计的是全部入队任务，还是经过分流后进入自动处理的任务，两者含义不同；人工升级率提高，也可能是系统更准确地识别风险，而不一定是能力退化。结合任务类型、失败阶段和人工投入一起看，才能判断系统究竟帮助了工程，又增加了哪些检查负担。

迁移到自己的团队时，可以先选一类日志、代码和任务状态比较完整的高频问题，再建立分流、执行、检查与交付记录。原文也提到 SDK 大版本升级、跨分支移植与派生仓库同步等迁移方向，但每个场景都需要重新确定风险边界。PatchPilot 最有价值的启发，是让模型参与一个能够解释过程、检查结果、恢复中断的工程流程，工程师因此能依据证据决定继续、重试或接手，自动化的价值也才能落到最终交付，而不是停留在生成了一段修改。