Catching Developers in the Flow: Low-Latency Agentic Program Repair at Google Scale
Celal Ziftci, Spencer Greene, Ray Liu, Livio Dalloro, Lorenzo Dini
cs.SE, cs.AI
2026-10-06
谷歌在提交前部署 FlowAgent，用微调的 Gemini 2.5 Pro 跑 ReAct 循环，赶在开发者改代码前修失败测试。195 例人工核验正确率 67.18%，上线后 29.6 万个变更得到修复建议，2.86 万个被开发者采纳。
谷歌开发者在 Critique 建好 change 后，TAP 会扫 monorepo 里受影响的测试。失败通知到下一次改代码，中位隔 27.48 分钟，p25 为 6.72 分钟，p10 仅 2.37 分钟。人一去翻日志，这次修改的上下文就断了。
SWE-Agent、AutoCodeRover、Passerine、Meta Engineering Agent 做的是提交后的离线修复，ReAct 循环不赶「下一版编辑」的截止时间。FlowAgent 修提交前、IDE 外的 outer-loop：CI 已红，补丁未进主干。论文把它标成按此时延上线的第一套工业级预提交修复，对应 ASE 2026。
通知先过预执行过滤，被挡下的不调用模型。编译失败、库里本来就红的测试、已知 flaky、机器产生的 change 都跳过。开发者已另存一版的也跳过，避免打在旧 diff 上。图片、二进制，以及超过 100 个文件或 1000 行的改动同样不跑。规则来自内部经验和早期用户反馈。
过关的失败进沙箱。编排器读日志、change 描述和 diff，进入生成并验证循环。模型可读写删文件、搜代码、编译、跑测试。上限 100 次工具调用，以免跑太久。墙钟再限 30 分钟，对着 27.48 分钟的人工响应中位。底座是内部代码微调的 Gemini 2.5 Pro，温度 0.1，top-p 0.95。
产出 diff 后做确定性校验：最后一轮必须真跑过测试，否则系统重跑。模型自称通过不算。随后单独一次调用读完整轨迹，把根因和修法收成短摘要，最好一两句，最多五句。
展示前还有过滤。运行中人又改了 change，或已经提交，建议作废。怕和本地改动冲突，整条丢掉。
建议挂在原有 TAP 失败通知上，不新开 finding。每个 change 已有上百项分析。界面先给根因，再提供 Critique 内应用按钮和跳转 Cider 的链接。
37 个团队的 195 个真实失败，由三位五年以上经验的工程师分别判断补丁是否符合 change 意图，再开会统一分歧。131 个判对，67.18%。其余 64 个为错误，或测试能过但偏离意图。
2025 年 10 月起全库开启。
| 阶段 | 数量 | 说明 |
| 带失败测试的 change | 2,567,829 | 全集 |
| 预执行过滤丢弃 | 1,785,955 | 不调用模型 |
| 尝试修复 | 781,874 | 留下 30.45%，作者 36,479 人 |
| 生成补丁 | 421,818 | 占尝试的 53.95% |
| 提交后丢弃 | 126,310 | 人已改过或已提交 |
| 展示 | 295,508 | 占生成补丁的 70.06% |
| 预览 | 65,069 | 占展示的 22.02% |
| 应用 | 28,554 | 占预览的 43.88% |
Critique 预览 55,029、应用 20,826，比率 37.84%。Cider 预览 21,279、应用 12,702，比率 59.69%。两处可以重叠，相加会大于 28,554。
尝试修复的 change 平均 10.57 个文件、中位 6 个，失败测试平均 16.49 个、中位 2 个，均值被少数变更拉高，后缀 917 种。单次平均 21.37 次调用、424,149 token，累计 6430 亿 token。通知到补丁中位 9.85 分钟，p90 为 25.83 分钟，仍低于人工中位 27.48 分钟。
未采纳的样子包括给测试加 @Ignore、用 try/catch 吞掉断言、把等于 3 写成大于 2，以及回滚开发者改动。也有补丁正确，人仍手敲。
9 名不同组、入职至少六个月且接触过建议的工程师，各接受 45 分钟当面访谈。mock 更新和机械重构最常被说成省事。根因摘要省了翻日志。也有人确认结果正确，但建议来晚了，于是看完后自己改。
论文称这是迄今报道过的最大一份工业界修复数据，而且落在提交前。做法是失败通知一到就用规则弃权，通过后再进沙箱生成并真跑测试，建议只嵌进已有的评审界面。
墙钟上限 30 分钟，为的是赶上 27.48 分钟的人工编辑中位。温度设在 0.1，则是为了让动作稳定、方便复现。9.85 分钟的中位耗时，依赖谷歌这边能在时限内完成编译和测试。换一套更慢的构建系统，30 分钟上限会先把循环掐掉。
预览后应用率 43.88%，Cider 更高。展示到预览只剩 22.02%。67.18% 是评估正确率，不是线上采纳率。Passerine 与 Meta 的工程智能体被放在提交后场景，同一批失败上没有对照数字。
三位评估者不拥有对应代码，文中承认可能误判。样本随机，未必代表全部失败。预执行过滤只放行 30.45%，规则来自早期小范围反馈。机器改动、超大 diff、flaky、入库前已失败的测试，都不在 67.18% 的分母里。
点了应用也不等于补丁正确。人会继续改，也会在建议正确时手敲。应用后测试是否仍通过、提交里留下多少自动 diff，都没有数字。预览和应用的统计也没控制开发者对 AI 的先验态度。
访谈是 9 名志愿者。排斥 AI 辅助的人不会在场，这被列为选择偏差。模型是内部 Gemini 2.5 Pro，提示词一改就可能掉点。数据不公开，也没有外部 CI 对照。部分表格和 Colab 图由 Gemini 生成。
系统仍会建议回滚 change 或注释掉失败测试，这伤信任。展示前的拦截还在加。Critique 给不了剩余时间，工程师无法靠它决定等还是自己修。没产出补丁被归到时限。新模型能捞回多少，正文没给数字。