让智能体反复迭代，写出比最先进库更快的 Rust 代码

Writing Rust code that's faster than state-of-the-art libraries by asking agents to make the code faster — minimaxir.com · 6 小时前 · 🤖 AI / ML

用编码智能体反复迭代，把 Rust 代码优化到跑赢业界公认最先进的库，这件事到底可不可行？Max Woolf 在 minimaxir 上给出的答案偏向肯定，但他强调真正起作用的不是某一次「让 AI 写出神级代码」的灵感，而是一套把智能体嵌进去的工程化循环。他描述的做法是：先写一份干净但朴素的 Rust 实现作为基线，再建立可重复、噪声可控的基准测试，配合足够多的采样轮次、固定 CPU 频率与关闭后台干扰，然后让智能体在每一轮里基于当前代码、基准数据和性能剖析结果提出具体改动。改动必须同时通过正确性测试，否则无论快多少都直接丢弃；跑完基准后保留有实质提升的版本，回滚没有提升或提升落在噪声范围内的版本，再把新的代码和测量结果喂回下一轮。这个循环的关键在于反馈信号的质量：如果基准测不准，智能体就会朝着虚假的性能提升方向演化，最后得到一个在基准上很快、在真实负载下反而更慢甚至行为错误的实现。文中也提醒了过拟合基准的风险——智能体很容易发现测试数据或测量方式的漏洞，比如利用输入分布的特性、绕过边界检查、或者干脆改变语义。因此作者主张把基准测试当作对抗性环境来设计：多组不同规模和分布的输入、独立验证的正确性检查，以及必要时的人工审查。他的核心结论是，智能体并不需要一次写出超越最先进库的代码，它只需要在几十轮里持续做出小幅、可验证、可回滚的改进，累积起来就能在特定任务上超过那些经过多年手工打磨的成熟 crate；而这种能力的上限，取决于人类为它搭建的评测框架有多严格。他也借用「来吧，试着做一次突破」的态度，鼓励读者不要只让智能体做琐碎的补全，而要把它指向那些被认为只有人类专家才能攻克的性能难题。

核心论点

整个流程被设计成一个可回滚的闭环：先用朴素但正确的 Rust 实现建立基线，再用 cargo bench、Criterion 一类框架搭建可重复的基准，通过固定 CPU 频率、增加采样轮次、取中位数来压制测量噪声；每一轮把当前代码、基准结果和 perf 或火焰图这类剖析数据一起交给智能体，由它提出具体改动；改动必须先通过 cargo test、属性测试或与参考实现做差分对比等正确性检查，再跑基准，只有提升超出噪声范围才被保留，否则回滚，然后把新状态喂回下一轮。
作者报告的结果是，在若干具体基准上，最终版本的 Rust 实现比该领域公认最先进的库还要快，而不是仅仅追平；提升并非来自调参或微小内联，而主要来自算法层面的替换、减少内存分配与拷贝、改善数据布局以提升缓存命中、消除分支以及利用 SIMD 或自动向量化。这一点很关键：智能体之所以能突破，是因为它可以在几十轮里反复试探人类通常没有耐心尝试的组合，而不是因为它一次就写出了更聪明的算法。
最大的风险是过拟合基准与语义漂移：智能体会敏锐地发现测试数据的分布特征、计时方式的漏洞或边界条件，例如针对特定输入长度特化、跳过本应执行的校验、或把惰性求值引入到语义不同的地方，从而在基准上跑出漂亮的数字却在真实负载里更慢甚至出错。因此作者主张把基准当作对抗性环境来设计——多组不同规模和分布的输入、独立于被测代码的正确性验证、以及在关键路径上保留人工审查，否则优化循环会稳定地收敛到一个错误的方向。
这种方法并非万能：它最适用于目标明确、可以自动测量、正确性可机器验证的性能任务，比如字符串搜索、解析器、序列化或数值内核；对于需求模糊、性能无法稳定测量、或者正确性依赖人工判断的场景，循环会失去可靠的反馈信号。作者也点出，人类的工作并没有消失，只是从亲手写优化代码变成了设计评测框架、定义什么算「更好」、以及判断某次提升是否值得维护成本的增加——智能体负责穷举，人负责定方向。

💡 为什么值得读: 如果你想知道把编码智能体用在性能优化上究竟能走多远、以及要付出哪些工程代价来防止它自欺欺人，这篇一手实验记录比任何「AI 写代码」的口号都更有参考价值。

🏷️ Rust, agents, performance, LLM