编译器不报错，数字悄悄错了：Google用agent群解决142个静默bug

Google发了一篇论文，题目是《XLA from the Trenches: Correctness on TPU Workloads at Scale》。他们用一群AI agent去修Google自家TPU编译器XLA的bug。推文说，框架已经推动解决了142个编译器bug，另有103个发现还在审查。论文链接放这：https://arxiv.org/abs/2611.00624

先解释一下什么叫静默miscompilation。编译器不报错，程序也能跑完，但数字悄悄偏了，或者buffer被写坏。短测试未必看得出来，放到大模型训练里，可能几周后loss不对劲；放到线上服务里，可能返回结果慢慢退化。日志干净，监控不响，最费时间。论文里说这是最危险的一类。

他们的做法分几层。fuzzing同时用合成程序和真实生产trace，生成大量输入；检查逻辑和现有autotuner并行跑；一旦发现失败，用分层差分流水线把完整workload一层层缩小，最后定位到融合kernel里的单个operation。然后agent群上场：生成压力测试、复现失败、草拟修复。团队还刻意把agent从容易的crash bug引开，让它们盯静默数据损坏。这个选择很实际，crash bug容易发现也容易修，静默bug才是真正花钱的。

有个细节值得注意。推文下有人提到，论文里多数fuzzing跑在模拟器上，真实TPU留给确认bug；修复仍然要maintainer批准。也就是说，agent没有绕过人类，它只是把候选量和复现工作拉上去了。

但论文自己也写了一个不太顺耳的结论：reviewer effort增长得比修复复杂度更快。翻译一下，agent写补丁便宜，人读补丁不便宜。补丁多了，审查就成了新瓶颈。所以他们在人类看之前加了一道对抗性预过滤。推文下有人追问，这个预过滤是拿每个补丁重跑bisect后的复现，还是让第二个模型读diff，推文和摘要里没展开。这个细节会决定它到底省不省人。

评论区里几条判断比论文摘要更直接。有开发者说，只有新测试在旧代码上失败，才敢信这个修复。还有人说，agent修编译器最需要三样东西：最小复现程序、用来对比的参考结果、加进测试套件的回归测试。没有复现的修复就是猜。另一个评论点得更透：agent群能grind，是因为有oracle。能把输出和参考结果diff，人类才只需要看不一致的那部分。很多团队想复制这套方法，缺的不是agent，是oracle。

所以这件事的价值不在“AI又会写代码了”。它更像一个真实工程案例：agent在编译器这种硬核场景里，把发现、复现、草拟修复的流水线跑通了。但它也把问题往前推了一步。写补丁的成本降下来之后，验证、审查、回归测试会成为更硬的约束。想靠agent修编译器，先准备好像样的复现、参考输出和测试，不然只是把更多猜测送到reviewer面前。

论文：https://arxiv.org/abs/2611.00624
Chat with Paper：https://academy.dair.ai/papers/xla-from-the-trenches-correctness-on-tpu-workloads-at-scale-2611.00624
原始推文：https://x.com/omarsar0/status/2117613273189376072