AI 写代码前先去“做文献综述”，结果真快了：4 台云主机、3 小时，把 llama.cpp 又榨出 15%
当 AI 不再“闷头写代码”
这两年，大家已经很习惯看 AI 写代码、改 bug、提 PR 了。可一个不太被讨论的现实是：很多 agent 虽然会写，但并不真的“懂为什么要这么写”。它们更像一个手速惊人的实习生，拿到代码库之后立刻开始改，改得很勤快，思路却常常停留在表层。
SkyPilot 这篇博客有意思的地方，就在于它不再让 agent 一上来就埋头敲代码，而是先去“做研究”。说白了，就是在自动化优化循环前，先让 agent 读论文、看竞品项目、研究不同后端实现，再回来决定该改哪里。这听起来像废话——哪个老工程师不是这么干的？但把这件事系统化、自动化，并且真的跑出了结果，就不是一句“常识”能带过的了。
他们把这套研究驱动的 agent 指向了开源推理项目 llama.cpp，用 4 台云端虚拟机跑了 3 个多小时，做了 30 多轮实验，最终留下 5 个有效优化。在 TinyLlama 1.1B 的测试里，x86 平台上 flash attention 文本生成提升约 15%，ARM 上也有约 5% 的增益。总成本大约 29 美元，其中 20 美元是云主机，9 美元是 API 调用。这个数字本身就很有冲击力：不到一顿外卖的钱，让一个 agent 干了半天“性能工程师”的活。
代码会告诉你“它在做什么”，却不会告诉你“它为什么慢”
这件事最打动我的，不是 15% 这个数字，而是它揭示了一个更关键的问题：很多性能优化，靠读代码本身是不够的。
此前，Karpathy 的 autoresearch、以及后续的 pi-autoresearch，已经证明 agent 可以围绕 benchmark 自动提出想法、改代码、跑实验、保留赢家。Shopify CEO Tobi Lütke 甚至拿它去优化自家的 Liquid 模板引擎，跑出了解析和渲染速度提升 53%、内存分配下降 61% 的结果。为什么那类任务比较顺？因为瓶颈就写在代码里。你打开源码，能看到 tokenizer、能看到 StringScanner、能看到热点逻辑，优化面几乎是“裸露”的。
但 llama.cpp 的 CPU 推理路径不是这样。它的性能瓶颈不是“这里有个低效函数，换个写法就好”，而是更底层的问题：这个工作负载到底是算力受限，还是内存带宽受限？该不该融合几个算子？其他 fork 有没有已经验证过的路径？CUDA 和 Metal 后端做了哪些 CPU 还没做的事情？这些答案，一半藏在论文里，一半藏在别人的仓库里，剩下一半——是的，性能问题经常有三个“一半”——藏在资深工程师脑子里的经验模型里。
SkyPilot 的实验里，agent 第一波尝试就很典型：它从代码出发，先去做 SIMD 微优化，比如 AVX2 预取、循环展开、去掉临时 buffer、提前计算边界。结果几乎都在噪声范围内，有的甚至回归。最后它自己复盘说：问题不是算得不够快，而是内存带宽先撞上了天花板。一个 606 MiB 的模型以大约 49 token/s 的速度跑时，已经能吃掉接近 30 GB/s 的内存带宽，快摸到这台 AWS c6i.2xlarge 实例的 DRAM 极限了。CPU 在等数据，不是在等指令。
这就是关键分水岭。你如果不知道 roofline model，不知道 batch-size-1 推理在 CPU 上常常是 memory-bound，就会不断在错误的地方“抠细节”。这也是今天很多 AI 编程 agent 的真实局限：它们不是不会改，而是不知道该朝哪个方向改。
让 agent 先读论文、看 fork，像一个真正的资深工程师
SkyPilot 做的增强，本质上是在原来的“改代码—跑实验—看指标”闭环之前，又插入了一步“研究”。agent 会并行去查两类资料：一类是 arXiv 论文，比如 FlashAttention、Blockbuster、在线 softmax normalizer、Intel 关于 CPU 上 LLM 推理优化的论文；另一类是更接地气的项目情报，包括 ik_llama.cpp、llamafile 的 tinyBLAS、PowerInfer、ExLlamaV2 等分支和竞品实现。
有趣的是，真正帮上大忙的，不是论文，而是 fork 和其他后端。这个结论非常“工程”。论文提供的是方向感，告诉你什么值得考虑；可真能落地的优化，很多时候已经悄悄长在某个性能狂热开发者的仓库里了。SkyPilot 甚至直说，研究 ik_llama.cpp 和 llama.cpp 的 CUDA 后端，比单纯搜 arXiv 更有产出。
这其实也不难理解。论文的目标是提出一般性方法，工程代码的目标是把它在某种约束下跑起来。前者像地图，后者像路书。做系统优化的人都知道，真正值钱的信息经常是“某个仓库里为什么这么写、它为什么没合并主线、在哪些输入分布下收益明显、在哪些平台上会翻车”。这些经验，在论文摘要里通常是找不到的。
agent 就是在这个研究阶段完成了“认知升级”。它发现 llama.cpp 的 CPU 后端缺少某些 CUDA、Metal 已经有的算子融合；它确认了某些看起来很诱人的方向其实已经 upstream 了，没必要重复劳动；它也意识到，完整照搬论文里的 FFN 大融合方案并不现实，因为量化权重格式和模型加载器会成为真正的阻碍。这个判断很像一个老工程师会做的事：不是见到好主意就扑上去，而是先评估工程可行性和投入产出比。
真正落地的 5 个优化，说明了“研究驱动”到底改变了什么
最后留下的 5 个优化，表面上看并不“魔法”。它们大多是算子融合和并行策略调整：把 softmax 里原本分三次遍历的数据操作合成一次；把 RMS norm 的 copy 和 scale 合成一次；把 from_float 量化路径的并行切分做成自适应；在 CPU 图执行里补上 RMS_NORM + MUL 的融合；再把 flash attention 里 KQ tile 的 scale、mask、max 几步压成一趟 AVX2 FMA 循环。
但真正有意思的是，这 5 个优化背后的判断路径。它们几乎都围绕“减少内存访问次数”展开，而不是继续在指令级别精雕细刻。这代表 agent 已经从“哪里能写出更花的 SIMD”转向“哪里能少搬一次数据”。在今天的 CPU LLM 推理里，这种转向非常重要，因为内存墙才是大多数实际部署的天敌。
其中最能说明问题的，是 CPU 后端补上 RMS_NORM + MUL 融合这一条。这个融合在 CUDA 和 Metal 后端早就存在，偏偏 CPU 没有。如果只看 CPU 代码，你未必会意识到这是个缺口；但把不同后端并排一看，缺的那块拼图立刻就冒出来了。换句话说，研究阶段给 agent 的，不只是知识，而是“比较视角”。很多优化不是凭空发明出来的，而是通过横向对照发现不一致，再顺藤摸瓜把它补齐。
最亮眼的收益来自 flash attention 路径。这里 agent 把原本多次遍历 KQ tile 的操作融合成单趟 AVX2 FMA 循环，最终在开启 flash attention 的前提下，把 x86 文本生成性能拉高了约 15%。要知道，这不是从零造出 flash attention，而是在现有实现基础上继续榨性能。某种意义上，这比“发明新算法”更接近真实世界里的性能工程：大多数时候，工程师不是在写论文，而是在别人已经写好的复杂代码里，找到那些还没被拧紧的螺丝。
这件事为什么重要：它指向了 AI Agent 的下一阶段
我觉得，这篇文章真正重要的地方，不在于 llama.cpp 又快了多少，而在于它给出了一个很清晰的信号：下一代高价值 agent，不会只是“代码生成器”，而会是“会做案头研究的工程师”。
过去一年，行业里对 agent 的很多期待都建立在一个默认前提上：给它代码库、测试和 benchmark，它就能不断试错，最终找到更优解。这个前提在局部优化、业务逻辑修改、甚至一些脚本级工程任务上成立；但一旦进入系统性能、基础设施、编译器、数据库内核这种高度依赖领域知识的地方，单靠代码上下文就不够了。你需要它懂硬件特性、懂文献脉络、懂开源生态的演化，甚至懂“为什么某个 PR 没被合并”这种带点社会学色彩的背景。
这也会重新定义企业怎么使用 agent。以后真正有生产力的工作流，可能不是“把仓库扔给 AI，让它直接干”，而是先让它自动做一轮技术调研：读设计文档、读论文、读 issue、读竞品 commit、读内部事故复盘，再基于这些材料进入执行阶段。研究和编码不再是两个分开的岗位，而是 agent 工作链路中的前后两段。
当然，这里也有争议。研究驱动听起来很美，但它也可能带来另一种风险：agent 会不会被二手资料误导？会不会机械模仿别人的实现，而不是理解背后的约束？尤其在性能优化这种高度依赖上下文的任务里，别人的“最佳实践”搬到你的系统里，很可能就是灾难。SkyPilot 这次之所以成功，一个重要原因是它没有停在“读到了什么”，而是把所有想法都丢进 benchmark 和 correctness check 里做了严格验证。研究不是结论，实验才是结论。
从这个角度看，我反而觉得这套方法最像人的地方，不是“会查资料”，而是“查完资料也知道自己不一定对”。这可能正是 agent 真正变得靠谱的开始。
别把它看成一次性能秀，更像一次工作流预演
如果把视角再拉远一点，这其实是个很有时代意味的信号。过去，性能优化是少数资深工程师的手艺活，靠经验、直觉和一点点偏执。今天，agent 开始能复现其中一部分流程：先建立假设，再搜集外部信息，再在云上并行试验，最后用测试和指标筛出赢家。它当然还不是一个顶尖性能专家，但已经不像一个只会盲改代码的“补全工具”了。
我甚至觉得，这比单纯的“AI 自动写了多少行代码”更值得关注。因为真正稀缺的，从来不是打字速度，而是判断力。研究驱动的 agent，正在朝“可复制的判断流程”迈出一步。它未必立刻替代资深工程师，却很可能先把后者最耗时间的前期探索工作自动化掉。
接下来值得观察的，是这类方法能不能从 llama.cpp 这种基准明确、反馈清晰的开源项目，迁移到更脏、更复杂的真实生产系统里。数据库查询优化、编译器 pass 调优、分布式系统参数选择，都会是很自然的下一站。如果它们也能跑通，那 AI agent 的叙事可能真的要变了：不是“它会不会写代码”，而是“它能不能像工程师一样先搞清楚问题”。
而这，恰恰是所有靠谱技术工作最值钱、也最不性感的一步。