Code Agent 如何用 generate-and-validate 流程判断自动生成的补丁是否正确？

Code Agent 的 generate-and-validate 流程可以筛掉无法编译、不能复现修复或破坏现有测试的补丁，但不能仅凭“测试全绿”证明补丁正确。测试套件只是程序规格的一部分；候选可能针对已知输入投机取巧，遗漏未覆盖场景，甚至删除原有功能。可靠流程应把生成、快速过滤、失败测试、回归测试、额外测试生成、静态分析和人工审查组合起来，并把结果标记为不同强度的证据。

generate-and-validate 是什么

自动程序修复把寻找补丁视为搜索问题。系统先根据故障位置、修复模板、代码库中的现有片段或 LLM 建议生成候选修改，再编译并运行测试。能让所有指定测试产生预期结果的候选被称为 validated 或 plausible patch。

流程通常从至少一个能暴露缺陷的失败测试开始。该测试构成 bug oracle，说明错误行为已被消除；原有通过测试构成 regression oracle，检查既有行为是否保留。两类测试都需要，否则工具可能只让失败用例通过，却破坏其他功能。

为什么测试通过不等于正确

测试只覆盖有限输入和路径。一个补丁可以对已知测试返回特例值、吞掉异常、提前退出或删除触发故障的功能，从而全部通过，却对其他合法输入产生错误。这就是自动修复中的补丁过拟合。

来源资料引用的早期研究显示，在 ManyBugs 基准上的大量 plausible GenProg 补丁实际属于过拟合。这些历史数字来自特定工具与数据集，不能直接套用到现代 LLM Agent，但它们证明“现有测试全绿”不是充分正确性判据。

先定义修复规格

Agent 在生成代码前应明确可观察目标：哪个输入失败、期望输出是什么、哪些不变量必须保持、允许修改哪些模块、性能和安全边界是否变化。只有一句模糊 bug 描述，验证器很容易奖励表面消除错误的补丁。

规格来源可以包括失败测试、问题报告、类型与接口契约、断言、数据库约束、协议文档和历史兼容要求。每条证据都应注明强度，不能把用户示例误当成完整输入域。

候选补丁如何生成

传统系统可使用删除、替换和插入语句等 mutation operator，或按空指针、边界检查等模板生成修改。数据驱动系统从历史人类补丁学习排序。Code Agent 则能读取故障、搜索相关符号、提出多个语义候选，并调用编辑工具落地。

生成阶段应控制搜索空间。限定可疑文件和函数、限制补丁行数、优先局部修改、禁止无关格式化，都能减少验证成本。候选数量不是越多越好；大量近似补丁会浪费构建资源，并增加偶然通过弱测试的机会。

第一阶段做廉价静态过滤

补丁产生后，先验证能否解析和应用，路径是否在允许范围，是否含重叠 hunk、冲突标记或意外二进制变化。然后运行格式检查、语法解析和类型检查。这些步骤快，适合在完整测试前淘汰明显无效候选。

还可设置差异预算：修改文件数、增删行数、公共 API 变化和依赖变化超过预期时降级或拒绝。预算不是正确性证明，但能发现“为通过一个测试重写半个系统”的异常候选。

第二阶段运行失败测试

先运行原来失败的最小测试，确认候选确实影响目标行为。若失败测试仍不通过，立即淘汰。若测试由于环境不稳定偶尔通过，应先解决 flaky 性，不能把随机绿灯当作补丁效果。

理想情况下，应在未修复版本上确认测试稳定失败，再在候选上确认稳定通过。这种前后对照证明测试具有区分力，也能防止环境变化被误认为修复。

第三阶段运行回归测试

目标测试通过后，运行受影响模块、调用方和完整测试套件。依赖图、覆盖率和符号引用可以帮助选择相关测试，但不能只运行模型主动挑选的少数用例，因为模型可能避开不利证据。

回归阶段还应检查 lint、类型、构建、数据库迁移和集成契约。修改并发、缓存或网络逻辑时，需要专门的竞态、超时和重试测试；单元测试无法覆盖所有系统行为。

怎样主动寻找过拟合

测试增强是 generate-and-validate 的关键补充。围绕失败输入改变边界值、顺序、大小、编码和空值，生成邻域测试；使用性质测试验证不变量；使用模糊测试探索意外输入；必要时进行变异测试，确认测试能杀死明显错误实现。

差异测试可以把候选与已知正确实现、旧版本或另一种算法在大量输入上比较。对安全漏洞，还要验证攻击路径真正关闭，而不是只让原始 PoC 失效。

静态和动态证据如何结合

静态分析可发现不可达代码、空指针、资源泄漏、类型不一致和污点传播。动态分析提供覆盖率、内存检查、竞态检测和性能数据。两类证据能发现测试断言未直接观察的问题。

任何分析器也有误报、漏报和语言边界。验证报告应列出实际运行的工具、版本、配置和覆盖范围，不能只写“静态分析通过”。

候选排序不能只看测试

多个候选都通过测试时，可以按补丁大小、修改局部性、复杂度变化、历史修复模式、风险和额外验证结果排序。通常较小补丁更易审查，但“最小”不一定正确；完整修复可能需要同步修改多个层级。

LLM 自评可以作为弱信号，不能担任最终裁判。让同一模型生成又判定，容易共享盲点。更可靠的是独立测试、确定性分析器、另一模型的对抗审查与人类确认共同投票。

如何标记补丁状态

系统应避免只返回 success。至少区分 generated、applied、build_passed、target_tests_passed、regression_tests_passed、additional_checks_passed、approved 和 deployed。每一状态都对应可验证证据。

“plausible”表示当前验证集合没有发现错误；“correct”只有在规格充分或证据达到团队定义的门槛时才使用。多数真实软件没有完整形式规格，因此更诚实的表述是“已通过哪些验证，仍有哪些残余风险”。

验证环境必须可重复

每个候选应从同一基线构建，使用固定依赖、数据和环境变量。前一个候选留下的生成文件、缓存或数据库状态可能污染后一个候选。容器、临时工作树或可恢复快照能隔离运行。

记录候选哈希、基线 commit、测试命令、随机种子、超时和退出码。测试超时与测试失败是不同结果；基础设施故障也不能当作候选无效。

Code Agent 的实用流水线

• 复现故障并保存失败输出，确认 bug oracle 稳定。
• 读取相关代码与测试，形成明确修复约束。
• 生成少量差异化候选，并限制无关修改。
• 依次执行 patch 校验、格式、语法、类型和目标测试。
• 对幸存候选运行相关回归与完整测试。
• 生成边界、性质、模糊或差异测试寻找过拟合。
• 比较候选风险、复杂度和性能，保留完整证据。
• 由人类审查最终 diff，再进入合并或部署流程。

成本如何控制

验证应采用漏斗结构。便宜检查先运行，昂贵的全量集成、模糊和性能测试只对少数候选执行。缓存不受补丁影响的构建产物，按依赖图选择测试，并为每阶段设置资源预算。

预算用尽时不应把最佳未验证候选标成成功。系统应返回当前达到的验证阶段和未运行项目，让用户决定是否继续投入资源。

部署后验证为什么仍必要

测试环境无法完全复制真实流量、数据规模和依赖。高风险补丁应采用灰度、特性开关、监控与快速回滚。观察错误率、延迟、资源使用和业务指标，避免技术测试通过却损害真实行为。

部署监控是最后一道证据，不应成为跳过前置验证的理由。发现异常时要能关联到候选补丁和验证记录。

结论

generate-and-validate 能让 Code Agent 从多个候选中系统地淘汰明显错误补丁，但测试套件是不完整规格，全部通过只能说明候选在已知观察下 plausible。自动修复最大的风险之一，正是把过拟合补丁误认为正确。

可靠判断需要失败测试、回归测试、额外生成测试、静态与动态分析、差异约束和人工审查共同提供证据。系统应记录每个验证阶段并诚实报告残余风险，而不是用一个绿色 success 隐藏“尚未证明”的部分。