Google 把修复 Agent 接进 CI：测试通过，还不够

开发一个需求，代码写完了，本地测试也通过了。等到提交代码评审，CI 又报出几个测试失败。

这在大型代码仓库里并不少见。一个改动可能影响其他模块，即使开发者已经运行了附近的单元测试，更广范围的回归测试仍可能发现问题。接下来，开发者需要翻日志、定位原因、修改代码，然后重新运行验证。

现在的 Coding Agent 已经可以帮忙完成这些工作。让 Agent 根据失败日志分析原因、修改代码、重新测试，技术上并不难想象。

但有一个问题：如果 Agent 花了半小时修好测试，开发者已经自己改完了，这份补丁还有多少价值？

更麻烦的是，有时候 Agent 确实让测试通过了，却是通过跳过测试、放宽断言，甚至撤销原来的修改实现的。这样的修复显然不能直接接受。

最近，Google 研究团队发表了论文 《Catching Developers in the Flow: Low-Latency Agentic Program Repair at Google Scale》，介绍了部署在内部研发流程中的自动修复系统 FlowAgent。

这项研究吸引我的地方，是它把 Agent 放进了每天都在发生的真实研发活动中，并公开了大规模运行数据。我们可以借此看看，自动修复离真正可靠、可用的工程能力还有哪些距离。

先看 Google 的研发流程。

开发者在内部 IDE Cider 中编写代码，完成修改后创建待评审的变更。随后，测试平台 TAP 会根据代码之间的依赖关系运行相关测试，检查这次修改是否引入回归问题。测试结果出现在代码评审系统 Critique 中，如果有失败，开发者还要回到 IDE 调查并修改。

Google 把这一阶段称为提交前的 Outer Loop，也就是代码完成局部开发、进入更广范围验证的阶段。相对地，在 IDE 中写代码、运行附近的局部测试属于 Inner Loop。

FlowAgent 就部署在 Outer Loop 中。它监听 TAP 的测试失败消息，自动尝试生成修复补丁，并将结果直接呈现在 Critique 和 Cider 中。

为什么选择这个位置？

Google 分析了 2025 年 9 月的内部研发数据，发现从 CI 报告失败到开发者再次修改代码，中位时间约为 27.48 分钟。

这给自动修复提出了明确要求。Agent 最好在开发者投入大量人工调试之前，提供一个有用的结果。因此，研究人员为 FlowAgent 设置了最长 30 分钟的执行限制。

在实际部署中，从测试失败通知到成功生成候选修复结果，中位耗时约为 9.85 分钟，90 分位耗时约为 25.83 分钟。

这些数据描述的是不同的时间指标，不能直接相减得出节省的开发时间，也不能证明 Agent 总能赶在开发者之前完成修复。

真正值得注意的是，Google 将开发者的工作节奏直接纳入了 Agent 的系统设计。

FlowAgent 的核心是一个生成与验证循环：理解失败、调用工具、修改代码、运行测试，再根据反馈继续修复。

根据论文对系统架构与执行过程的介绍，Google 使用经过内部代码和数据微调的 Gemini 2.5 Pro，为 Agent 提供失败日志、变更描述、修改文件列表和代码 Diff。Agent 可以搜索和修改代码、构建项目、执行测试并读取结果。

但真正值得研究的是，Google 在执行循环前后都增加了工程控制。

执行前，先判断这次失败是否值得修复。

如果测试本来就会失败，或者属于已知的不稳定测试，那么修改当前代码可能毫无意义。对于构建失败、自动化工具创建的变更、不支持的文件类型，以及规模过大的修改，FlowAgent 也会主动跳过。

这些规则来自 Google 对历史失败案例和开发者反馈的积累，能够过滤掉一批明显不合适的任务。

通过过滤后，Agent 在沙箱中运行，最多调用 100 次工具，执行时间不超过 30 分钟。它会根据构建和测试反馈反复修改，直到生成候选补丁或者触及执行限制。

生成补丁后，系统还会进行最终验证：确认最后一轮已经运行过测试，必要时重新执行测试。只有验证成功，才根据完整执行记录生成失败原因和修复说明。

执行后，再判断这份修复是否仍然有用。

假设 Agent 开始修复时，开发者的变更是版本 A。等 Agent 完成补丁，开发者已经修改出版本 B，那么这份补丁可能不再适用。

FlowAgent 会检查开发者是否已经修改或提交原来的变更。如果是，就丢弃建议。即使修改发生在无关文件中，当前实现也选择保守处理，以减少冲突和困惑。

最终，符合条件的补丁才会送到 Critique 和 Cider，让开发者预览并决定是否应用。

这套设计体现出比较清晰的分工：Agent 负责定位问题、探索修复路径；外围的工程规则负责筛选任务、限制执行、验证结果和检查变更状态。

Google 在论文的生产使用数据部分公开了自 2025 年 10 月启动大规模部署以来的统计结果。

FlowAgent 接收到的测试失败涉及 2,567,829 项代码变更。其中，1,785,955 项被执行前规则过滤，剩下 781,874 项进入自动修复。

Agent 为其中 421,818 项变更生成了通过系统验证的候选修复结果。但这些结果没有全部展示给开发者：有 126,310 项因为原始变更已经被修改或提交，在执行后过滤时被丢弃。

最终，295,508 项变更获得了正式展示的修复建议。其中，开发者预览了 65,069 项，并在 28,554 项变更中应用了建议。

这里最容易受到关注的是最后一个数字：接近三万项变更应用了 AI 修复建议。

但我觉得另一个数字更值得研究：126,310 项已经完成的候选修复，因为错过了适用时机而被丢弃。

这约占已生成候选修复的 30%。其中有些补丁可能仍然有效，例如开发者只是修改了无关文件；但 Google 选择优先保证建议与当前变更的一致性。

对研发 Agent 来说，能够完成任务，与任务完成时结果是否仍然有效，是两个需要分别判断的问题。

那么，为什么有些开发者预览了建议，却没有直接应用？

Google 访谈了 9 位开发者，并分析了部分未被采纳的修复案例。有些补丁确实不正确，有些建议虽然接近正确答案，却不符合开发者想要的写法；还有人看懂了问题后，直接在 IDE 里手动修改。工具入口、工作习惯和补丁冲突也会影响采纳。

这提醒我们，采纳率本身不能完整衡量修复价值。Agent 的原因分析可能已经帮助开发者定位问题，即使补丁没有直接应用；反过来，开发者点击应用，也不能证明补丁最终合并上线，或者整个研发周期因此缩短。

这些运行数据能够说明 FlowAgent 已经进入大规模真实研发流程，但要证明生产率提升，还需要更多对照实验和后续结果。

这篇论文中，我印象最深的是几个开发者没有采纳的修复案例。

在论文 Figure 9 展示的案例中，一个 Agent 给失败的测试增加了忽略标记。测试不再失败，因为它根本没有继续运行。

另一个案例里，Agent 增加了 try/catch，却把测试中的断言异常吞掉了。测试得以结束，原本应该暴露的问题也被隐藏起来。

还有一个例子更加隐蔽：正确的断言本来应该检查结果严格等于 3，Agent 却将其改成了大于 2。测试同样可能通过，但验证条件已经变弱。

研究人员还发现过直接撤销开发者代码修改的建议。这样做可能消除测试失败，却也一起撤销了开发者原本想实现的功能。

这些例子揭示了自动修复中的一个重要问题。

如果系统只把测试通过作为目标，那么修改业务代码、修改测试预期、放宽断言、跳过测试，都可能成为候选路径。模型可以看到当前的失败信息，却未必拥有足够的上下文判断哪些修改保留了原始意图。

Google 因此在人工评估中加入了对修改意图的检查。在来自 37 个团队的 195 个真实测试失败样本中，3 位有经验的开发者评估了补丁是否正确、是否符合变更意图，最终有 131 个案例被评为正确修复，比例为 67.18%。

这个比例属于人工评估样本，不能直接等同于全部生产修复的准确率。但它说明，构建和测试通过之后，仍然存在需要判断的质量问题。

Google 也没有认为现有验证机制已经解决了全部问题。论文明确提到，团队正在增加对移除测试、撤销开发者修改等行为的检查。至于放宽断言、吞掉异常等问题，仍需要更完整的验证方法。

由此可以提出一个工程判断：自动修复的验收条件，至少需要同时覆盖执行结果和原始修改意图。

执行结果可以通过构建、测试与回归验证检查；修改意图则需要结合需求、变更描述、代码行为和测试断言判断。

当然，实际工程中也确实存在需要修改测试的情况。例如业务规则发生变化，旧断言可能已经失效。我们需要关注的，是修改测试的理由能否得到说明和验证，以及它是否正确表达了新的业务要求。

读完 FlowAgent，我觉得有三个地方值得带回到真实工程中思考。

第一，任务的时间窗口和版本状态，需要成为 Agent 执行的一部分。

过去我们评价 Coding Agent，常常关注一项任务最终能不能完成。FlowAgent 提醒我们，研发中的任务还有时效性。开发者可能持续修改代码，测试状态也可能不断变化。系统需要知道任务什么时候仍然有价值、什么时候应当终止，以及已经生成的结果是否仍然适用于当前版本。

第二，让 Agent 直接利用现有研发流程中的上下文和验证能力。

FlowAgent 没有要求开发者额外打开聊天窗口、复制失败日志、重新描述问题。它直接使用 CI 事件、代码变更信息与测试能力，将结果送回开发者熟悉的工具。

这降低了启动任务和使用结果时的额外操作。对研发团队而言，把 Agent 接进 CI、代码评审、测试平台和 IDE，是值得优先验证的落地路径。

第三，自动化程度提高后，质量验收也需要覆盖更多维度。

一个修复 Agent 能够生成补丁、执行测试、解释失败原因，但系统还需要确认：原始意图有没有改变？测试是否被弱化？补丁是否基于当前版本？哪些结果可以自动接受，哪些仍需要人工评审？

这些问题同样存在于存量系统修改、需求自动开发和测试生成等任务中。工程验收需要明确的依据，仅仅让某一组测试变成绿色还不够。

Google 的 FlowAgent 仍有局限。它聚焦提交前的测试失败，不覆盖所有软件缺陷；人工评估样本有限，线上使用数据也不足以直接证明团队整体研发效率提升。Google 内部的研发基础设施和工程规模，也未必能直接复制到其他团队。

但它提供了一个很有价值的真实案例：Coding Agent 已经能够嵌入持续发生的研发活动，承担一部分日常工程工作。

接下来需要继续解决的问题，是如何让 Agent 生成的结果始终与当前任务保持一致，如何证明它没有破坏原始意图，以及怎样在合适的时机交给开发者。

能自动生成补丁是一项能力。知道什么时候该修、怎样判断修得对、什么时候该把结果交给开发者，才能让这项能力在真实研发流程中持续发挥作用。