最近总有人问，为什么 agent 工具加了一堆，它还是原地打转。
简单说，它缺的不是装备，是问一句。
这个月初 arXiv 上挂了一篇论文，编号 2611.03517，归在 cs.LG。标题后半句是 Ask, Don't Equip。这篇不是教程。它讲一件更让人不舒服的事：一个工具已经堆到头的 agent，为什么还是跑不动。
对比是这样的。同一个任务，同一个评测器，同一块卡，同一周跑的。一边按现在的主流风格搭，工具丰富，跑了 133 个模型驱动的步骤，停在 0.50x FlashAttention-3。另一边叫 KernelSeek，跑到 1.13x。
这个数字我盯了一会儿。差的不在工具数量上。
论文把做 GPU kernel 优化的 agent 分成两端。一端是脚本化，用学到的策略、预设的优化菜单、固定角色，把模型每一步的动作规定死。配方对得上就极省样本，对不上就原地不动。另一端是开放式，让模型自己去改一组 kernel，代价是成千上万次评估、反复回改，还有一堆错的候选。
这两端的毛病，作者点得挺准。碰到难啃的目标，两边都会本能地加功能。去解析 profiler 输出，去反汇编，去检索文档和库，去建一个经验库。
这套动作我看着眼熟，也觉得都对。问题是它们加的全是“能看见什么”，没有一条加的是“往哪走”。
作者的说法是，缺的是方向。方向这个词他们用得很抠，指的是关于剩下的差距在哪里的一个假设。一句短问题能在对的时机给出方向，又不会把后面能走的路限死。
这句值得停一下。问题给的是方向，不是答案。
KernelSeek 就三件东西。一个通用编码 agent，一个把目标卡到可验证的最小化 harness，还有出现在决策点上的问题。问题一开始是人给的，后面 agent 拿自己的问题库自问。目标也克制，不给算子特定知识，也没有更快的现成实现让它抄，就是让已有的 CUDA kernel 变快。
我最想讲的其实不是 1.13x。是他们回头翻了自己那 162 条人写的消息和约 1.15 万次 agent 工具调用，然后发现，明显的性能提升都紧跟在某一类问题后面。就两类。一类把 agent 引到系统的另一个层次，一类直接否定它自己说的极限。直接提供信息的问题，一个都没起作用。
这条比性能数字值钱。喂资料是我最常做的动作，也是我做得最没用的动作。
所以“贴一段 profiler 输出”“甩三篇文档”“再补十行注意事项”这种 prompt，经常毫无动静，现在有了解释。你给的是材料，它缺的是“我是不是搞错层了”。
后面那串结果也得说。KernelSeek 给 Hopper 和 Blackwell 各出了一个 FlashAttention 前向 kernel，单个 CUDA 文件，不用 CUTLASS，不用 CuTe，不用 cuBLAS，也不用 cuDNN。两种架构各 182 个测试场景全过，几何平均分别是 FlashAttention-3 的 1.16x 和 FlashAttention-4 的 1.46x。
那几个“不用”是同一个意思。装备越少，越说明方向起了作用。
写到这得踩一脚刹车。这套东西能不能搬出 kernel 优化，我没把握。kernel 有个便宜之处，快不快能当场跑出来，可验证的目标很干净。换一个目标本身就模糊的活，“问一句”顶不顶用，我不知道。这部分我只看懂一半，先放在这里，搞明白了再补。
留给普通人的那点东西倒是明确。你卡住的时候，别再加要求，问两句就行。你现在改的是哪一层。你凭什么说这里到头了。
这两句不要钱，也不泄题。
我挺喜欢这篇的地方，是它没有教人怎么搭一个更强的 agent，而是把“加东西”这个本能按住了。这年头工具清单越写越长，能停手先问一句的，反而少。
作者把生成的 kernel、harness、问题库和执行轨迹都放出来了。想验证可以自己跑。我没跑，只读了。
本周就这些。上面哪条你觉得我讲错了，或者你试过类似的问法，欢迎告诉我。
下周见。