一个叫Sankalp的独立开发者，用Codex在GPU Mode与Core Automation联合举办的线性代数kernel竞赛里，14天内提交了超过1500次代码，最终把一道批量方阵QR分解题的运行时间从baseline的约419,000微秒压到1,805微秒，相当于232倍加速，在183名参赛者里排到第12。这个数字听起来像一场漂亮的agent胜利，但比赛真正的冠军方案跑出了约1,220.8微秒，比他快了近48%——用的还是一套完全不同的算法。这个反差，比232倍加速本身更值得琢磨。
232倍是怎么跑出来的
题目要求实现torch.geqrf那样的紧凑Householder QR分解：给一批方阵A，返回能重建出正交矩阵Q和上三角矩阵R的紧凑表示，检查器按12个不同条件数用例的几何平均运行时间打分，硬件是NVIDIA B200。
Householder QR的天然问题是串行——每一列的反射都依赖上一列处理完的结果，没法直接铺开成矩阵乘法喂给GPU的张量核心。业界的标准解法是分块Householder算法（配合WY表示），把逐列的串行工作打包成小块，让大部分计算重新变成矩阵乘法的形状。这是LAPACK这类数值库几十年前就用的老技巧，Sankalp的方案本质上是把这套经典算法用Triton和CUDA kernel重新实现了一遍，外加CUDA Graphs、混合精度和候选方案的beam式搜索。
GPU Mode这类比赛之所以适合agent自动化，关键在于它提供了popcor CLI，选手可以直接提交、测试、拿到分shape的反馈，只要错峰提交就几乎没有次数限制——比赛期间workspace甚至一度把Modal的算力credit跑光。这种近乎无限的试错环境，正是1500次提交能够发生的前提。
冠军换了赛道，不是跑得更快
Sankalp最终选择的架构，从头到尾都是分块Householder的变体，agent做的是在这个框架内不断调整实现细节、精度策略和kernel写法。而拿下第一名的方案用了一套CholeskyQR-Householder混合算法，按矩阵形状分别优化，并且针对病态条件数的情况单独设了回退机制。
agent赢的是效率，人赢的是算法路线
这两条路线的差距不是几个百分点的调参差异，而是换了一种分解数学策略换来的。Sankalp的agent循环再怎么跑1500次，本质上都是在同一个算法框架内做局部最优搜索；冠军的领先，来自一次框架级别的选择——这恰恰是当前自动化kernel优化最容易被忽略的边界。
- 结论.Agent驱动的高强度迭代能把一个可行算法磨到接近极限，但从一种分解思路跳到另一种，目前看依然需要人的数学洞察。
无限算力换来的经验，能带走多少
真正值得算工程师留心的，是这套方法论的适用边界。比赛允许近乎无限次提交，选手可以把agent当成暴力搜索器，一天跑几十上百次实验也不心疼成本。真实企业的kernel优化团队没有这种奢侈——每一次跑分都要算真实算力开销和排期成本，1500次提交在实际预算里基本不可能发生。
这不是说loop engineering没用。它更像是给了一个没有专业HPC背景的人，一条能摸到respectable加速比的路径——Sankalp自己也承认，不需要领域知识也能靠agent循环拿到不错的分数，只是到不了前十。真正决定名次上限的，还是有没有人在关键节点提出一个不一样的算法假设。
- 风险.如果把"agent能自动化kernel优化"简单理解为"agent能发现最优算法"，很容易高估当前auto-research的能力边界，把参数搜索的成果误读成算法创新。
对于正在评估要不要把agent循环搬进内部kernel优化流程的infra团队，这场比赛给出的信号相当具体：agent适合接手已经选定方向的精细化调优，但换算法框架、找新的数学结构，目前仍然是人的活儿。