PatchPilot: How Kernel Patches Move from Modification to Delivery Endpoint

Delivering a kernel patch has never been as simple as applying a diff. When upstream fixes a problem, downstream products may be maintaining different kernel versions. The same patch brought over can hit function refactoring, field evolution, or missing prerequisite commits—any one obstacle can trap engineers in a loop of repeated analysis and modification. The PatchPilot Agents practice shared on Bilibili attempts to push patches from "code changed" to "actually delivered" through an orchestrated, verifiable process.

The Challenge of Patch Delivery: Successful Application Does Not Equal Problem Solved

A patch being accepted by tooling only means there is no formatting conflict—it cannot independently prove that the original problem has been resolved. The original text warns that AI may miss critical changes, produce code drift, or even generate implementations that do not exist upstream. If automatic conflict resolution only chases the disappearance of error messages, delivery quality becomes meaningless.

From an engineering perspective, the judgment can be split into three layers: whether the modification landed at the expected location, whether the target version retains the conditions needed for the fix, and whether subsequent checks support delivery. The latter two layers require code and verification evidence. This split explains why "a single command succeeded" cannot be directly equated with "task complete"—it is merely an intermediate state in the process.

Upstream vs. downstream is a fundamental relationship in kernel development: upstream typically refers to the mainline kernel maintained by Linus Torvalds and its stable branches, while downstream refers to various product kernels (such as the Android Common Kernel, distribution kernels, and vendor-customized kernels). Downstream cherry-picks patches from upstream, but because downstream may remain on an old version for a long time and accumulate extensive custom modifications, upstream patches often cannot be applied directly. Whether a patch applies cleanly depends on whether the target code context matches upstream—and even if it applies successfully, it does not mean the code paths, configurations, or dependencies required for the fix exist in the target version.

Cherry-pick is a Git operation that copies a single commit to another branch, commonly used to backport upstream fixes to downstream versions. It only transplants the changes of that commit itself and does not automatically bring along the prerequisite commits it depends on—making missing dependencies one of the most common problems in downstream porting.

Patch Palette: Breaking Delivery into a Stateful Multi-Stage Process

PatchPilot's Patch Palette organizes patch delivery into multiple stages: fetching the patch, classifying conflicts and understanding intent, feasibility triage and dependency analysis, then AI conflict resolution, semantic review, and delivery re-check. Each stage has clear inputs, outputs, and state.

The value is not in drawing a flowchart, but in having the output of the previous stage become the basis for the next. A confirmed dependency list and unfinished conflict handling should be recognized as different levels of progress. Only then can the system know where a task is stuck and what is still missing upon recovery. The original text does not disclose the complete data tables or interface implementation, but the intent of state-driven design is clear.

Automatic Triage of Failed Tasks: Directing Expensive Reasoning Where It Matters

The system first uses heuristic rules to assess conflict scale, missing symbols, dangerous changes, and patch complexity, then hands tasks in the ambiguous range to a language model for further judgment. Triage is not a premature declaration of success—it is choosing the subsequent path. For very risky changes, even if the model can propose a fix, the task may still need to be handed to an engineer.

What is reflected here is a judgment about the scope of automation. Architectural differences, semantic trade-offs, and risk decisions are routed to a human exit, keeping the model's executable scope clearly aligned with ultimate responsibility. To validate whether triage is effective, check whether each task leaves behind its triage rationale: which conflicts are involved, which rules were hit, why further analysis was needed, and which path was ultimately taken. The original text does not provide specific thresholds; a more prudent approach is to observe which types of tasks frequently require human intervention using historical tasks from your own maintained versions, then gradually adjust the boundaries.

Intent Analysis and Dependency Analysis: First Understand "Why the Change"

Before entering conflict resolution, the system first analyzes the patch intent—why the original modification exists—rather than only observing how the two sides of the conflict fit together. For example, when the location of a conditional check changes, what truly needs to be preserved may be a constraint on a certain execution path. The intent description should be able to point to relevant code, the scope of changes, and the behavior that needs to be maintained; if it is reduced to empty phrases like "fix some problem," subsequent review has no basis for judging whether the implementation deviates.

Dependency analysis is described in the original text as "state-first." Searching only for missing symbols can sometimes miss the real conflicts caused by code evolution, because the existence of a name does not mean the implementation satisfies the patch's expectations. The system compares the state deviations of function implementations, struct fields, and function signatures, then locates the necessary prerequisite commits. The key is that finding a real commit does not automatically prove it is a necessary dependency—it still needs to be cross-checked against the patch intent and the target code state.

The original text also warns that patching only based on missing symbols can cause the dependency chain to keep expanding—one patch introduces another commit, which in turn depends on a larger refactoring, and the task easily evolves from fixing a problem into hauling over a segment of upstream history. To prevent the model from filling in nonexistent prerequisite changes based on experience, the system requires precise enumeration of commit identifiers through Git tooling, letting the tool provide traceable facts while reasoning explains the relationships between facts.

Prerequisite commit refers to other commits that a patch logically depends on but that are not included in the patch's diff. For example, the target function was renamed in an earlier commit, struct fields were added or removed, or an error path was reorganized—if these changes are missing, the patch's modifications will land in the wrong place or fail to compile. The goal of dependency analysis is to locate these prerequisite commits and determine whether they are truly necessary.

Per-conflict-hunk reasoning: a "conflict hunk" corresponds to each conflict region in a Git merge conflict marked by <<<<<<<, =======, and >>>>>>>. A patch may produce multiple conflict hunks; processing them one by one breaks large-scale reasoning into small units that can be independently checked, and also makes it easier to record the approach and failure reason for each hunk.

Per-Conflict Hunk Reasoning and Structured Failure Memory

PatchPilot performs reasoning per conflict hunk, where one conflict hunk corresponds to a segment of modification in the patch that needs to be handled; narrowing the scope makes each round of proposals easier to check. The original text requires preserving the approach, failure reason, and scope of change—this means local handling does not detach from context: the previously identified fix intent, code state, and dependency relationships still constrain how each hunk is modified.

A common waste in multiple attempts is the model repeatedly walking into the same invalid path. Structured failure memory stores each round's approach, failure reason, and scope of change, so the next attempt continues with this information. The key is that failure memory must provide evidence that can change subsequent actions, not just a "failed" label. In engineering terms, you can first determine at which layer the failure occurred: when execution preconditions do not hold, regenerating the same code is likely meaningless; when necessary dependencies are missing, you should return to state analysis; only when the modification approach violates the fix objective do you need to adjust the implementation path. The original text does not disclose the maximum number of retries. What can be validated is whether the next attempt leverages the previous result, whether it explains what was changed, and whether there is a clear human escalation exit after multiple failures.

Delivery Re-Check: Residual Conflicts, Code Drift, and Semantic Review

After execution, the system first checks for residual conflict markers. This type of check is direct and important—a seemingly complete file may still retain tool-generated separators. Problems that are easy to determine and automatically detectable should be prioritized into explicit steps, avoiding having the model declare success based on reading impressions. But cleaning up markers is only the basic threshold; it cannot prove the implementation is correct.

Code drift checking focuses on: modifying code to adapt to the target version requires justification; if the model casually changes other logic, it also needs to explain why that belongs to the current task.

During review, you can compare the original patch, confirmed dependencies, and final diff, and ask item by item about the necessity of extra changes. A difference not appearing upstream is not necessarily wrong, because the target version may genuinely require adaptation, but it should be able to state its basis and accept relevant verification. The original text does not provide complete drift detection rules; implementation still requires establishing check scope based on repository characteristics.

Semantic review uses the clearly written patch intent as the reference basis. The original text places semantic review in the process but does not disclose complete evaluation samples or proof methods, so it cannot be interpreted as the system having proven all patches correct. You can list the behaviors that should be maintained around the fix objective, look for evidence that code analysis, builds, or relevant tests can provide, and leave uncovered cases in the results. For semantic trade-offs that are hard to judge automatically, escalating to an engineer is more valuable than giving an overly strong conclusion.

Code drift in this context refers to code changes introduced to resolve conflicts that go beyond the original patch intent. It may manifest as incidental formatting, changes to unrelated conditional checks, adjustments to log text, or introducing adaptation logic that the target version does not need. Drift is not always wrong—downstream versions may indeed need adaptation—but it must be explainable, traceable, and correspond to specific version differences or missing dependencies. During review, comparing the final diff item by item against the original patch and confirmed dependencies is a practical way to find unfounded changes.

Success Defined by End-to-End Delivery, Not a Single Execution

PatchPilot defines success at end-to-end delivery. After a round succeeds, the system automatically creates detection rounds, re-checks pull requests and delivery status, and links tasks, logs, review conclusions, and final conclusions. Generating modifications, submitting for review, and final merge are different events; task status should advance with subsequent evidence rather than ending when the first execution succeeds. If detection fails, the task needs to return to the corresponding processing path; if it is still awaiting review, the waiting state should also be shown truthfully. This way maintainers see what is still missing from delivery, rather than a batch of tasks that appear successful but are actually hanging in the middle.

Operational Assurance: Engineering Details of Persistent State and Recovery

PatchPilot manages execution and recovery through persistent state, preventing tasks from being silently lost after interruption. Recovery should not be simply understood as re-running all steps from scratch—before recovery, it is necessary to confirm which stage has been completed, whether the remaining code and review artifacts still correspond to the current task, and where to continue next.

If the target branch has changed, past results may need to be re-verified. The original text does not disclose the specific fields of the state machine or explain all recovery conditions, but the direction is clear: let progress, artifacts, and exceptions have persistent records, so that scheduling works based on real state rather than relying on a process staying alive.

With multiple kernel versions and large batches of patches, deduplication, scheduling recovery, and timeout handling directly affect delivery reliability. The same patch sent to different target versions may be different tasks, and repeatedly submitting the same target task may cause extra modifications or duplicate reviews. Therefore, deduplication must be based on business task identity, not just comparing a prompt. Timeouts also need to distinguish between still running, temporarily unobservable, and already failed. The acceptance requirement is that every task can find its current progress and clear next actions, and exceptions will not leave it in an intermediate state that no one knows about.

Idempotency and task deduplication are closely related in batch patch delivery: when the same business task is submitted repeatedly, the system should recognize it as the same task rather than creating a new one; otherwise, it may produce duplicate modifications, duplicate reviews, or mutually overwriting commits. Task identity should be determined based on business keys such as repository, target branch, patch identifier, and task source—not just prompt text, because prompts with the same intent may correspond to different target versions, and vice versa.

The persistent state machine writes task progress, artifact references, and exception information to disk, so the scheduler advances tasks based on the real state in storage rather than process memory. During recovery, it first reads the last consistent state, then verifies whether the remaining artifacts still correspond to the current target branch, thereby avoiding re-running from scratch or incorrectly resuming.

How to Measure Effectiveness: Avoid Looking Only at Single-Point Success Rate

The original text proposes observing efficiency, cost, delivery rate, human escalation rate, and rework rate together, rather than only single-point success rate. The article does not provide directly comparable unified online scale or quantitative benefits, so no performance promises are made here. Metrics also need clear definitions of denominator and endpoint: does the delivery rate count all enqueued tasks, or tasks that entered automatic processing after triage? The two have different meanings. An increase in human escalation rate may also mean the system is more accurately identifying risk, not necessarily capability regression. Only by looking at task type, failure stage, and human input together can you judge what the system actually helped engineering with and what additional review burden it added.

When migrating to your own team, you can first select a class of high-frequency problems with relatively complete logs, code, and task state, then establish triage, execution, inspection, and delivery records. The original text also mentions migration directions such as major SDK version upgrades, cross-branch porting, and derived repository synchronization, but each scenario requires redefining risk boundaries. The most valuable inspiration from PatchPilot is letting the model participate in an engineering process that can explain the process, check results, and recover from interruptions, so engineers can decide based on evidence whether to continue, retry, or take over—and only then can the value of automation land on final delivery rather than stopping at generating a piece of modification.