性能优化智能体

为什么这个领域会打破标准循环。

补丁生成里「先出补丁、再跑测试」的循环之所以成立，是因为那个判据是二值的、确定性的、而且便宜。把它换成一个基准测试，这三条性质全部消失：判据变成一次带方差的连续测量，方差取决于机器和它的邻居，而每读一次要花几秒到几分钟。

• 噪声地板决定了野心的下限。如果你基准的运行间变异系数是 5%，那么单次跑出的「快了 8%」不构成任何证据。智能体分辨不出来，而且与人不同的是，它不会因此产生疑虑——它会径直接受，然后继续往下走。
• 候选数量之广，把噪声变成假胜利。这就是穿了帽衫的多重比较问题。生成二十个什么用都没有的补丁，各测一次，留下最好的那个：胜出者每一次都会看起来像一次舒服的提升。广度是智能体相对于人的主要优势，而它恰恰正是让一个无防护循环变得危险的东西。
• 基准自己也有这个毛病。2026 年一项针对主要几套基准的可靠性研究发现，SWE-Perf 尤其脆弱，因为它自己的许多参考补丁带来的运行时变化接近于零——专家的修法本身就落在噪声里。既然一套公开发表的基准都能这样交付，你那个临时写的计时脚本当然也能。

公开的成绩从另一个方向说了同样的话。在 GSO（102 个任务）、SWE-Perf（140 个）与 SWE-fficiency（498 个）上，模型平均取得的加速远不到专家的四分之一，过程中还经常引入正确性缺陷，并且一致地偏爱表层改动，而不是专家做出的那种结构性改动。这些都不是提示词能解决的问题。

先建测量台，再建智能体。

智能体最重要的工具是一个函数，而它的签名承载了整套纪律：

measure(workload, repetitions) -> {
  median_ms, ci95_low, ci95_high, n, machine_id, resolvable_effect
}

这个返回值里的三处设计选择，干掉了大部分的活：

• 返回区间，绝不返回标量。你递给模型一个数字，就等于教会了它「412ms 比 418ms 快」。你递给它的若是 414 [396, 433]，对照基线 419 [402, 440]，一个称职的模型会自己说出结论。这是整份手册里杠杆最高的一行，而它只是一个格式化决定。
• 把可分辨效应提前公布。用基线的方差和重复次数预算，算出这台测量装置真正能检出的最小加速幅度，并把它作为硬性下限写进智能体的系统提示词：低于它的改动一律不接受，不管那次运行说了什么。参见评测方差与统计功效——算术和你用在评测集上的那套一样，只是换成了毫秒。
• 把环境算进身份里。绑定 CPU 亲和性、能关睿频就关、固定输入数据、把热跑与冷跑分开，并拒绝比较来自不同 machine_id 的测量。让它跑在补丁运行的同一个隔离沙箱里——见沙箱与安全执行——因为一个吵闹的邻居和一次性能回退是无法区分的。

正确性是关卡，不是目标函数的一部分。

「更快但是错的」是这个领域每一个已发表系统的主导失败模式，而且它是结构性的：几乎所有真实的提速都靠减少工作量，而模型并不总能判断这些工作量里哪一份是有人依赖的。绝不要把加速幅度和正确性信号合成一个由智能体去优化的分数——要让正确性成为先跑一步的前置条件，不合格就直接出局。

• 跑全量测试，而不是快速子集。SWE-fficiency 采用的 pass-to-pass 框架是对的：此前绿的每一个测试现在必须仍然是绿的，而且轮不到智能体来挑跑哪些。
• 凡涉及数值，做输出的差分检查。在测试套件没覆盖到的输入上，对改动前后的输出做带容差的比较。把循环向量化、顺手改变累加顺序，既是一次真实的提速，也是一次真实的行为变更。
• 对「缓存家族」做显式的不变量检查。记忆化、预计算与惰性加载是模型最先伸手去拿的补丁，而它们恰恰在测试很少去看的两个地方出事：无界增长，以及在并发或重复调用下的正确性。要求补丁说明里写清淘汰策略和线程安全论证，写不出来就拒收。
• 永远用两种工作负载。在只有单一工作负载作判据时，「为基准输入优化、牺牲其他所有输入」是一个完全合法的补丁。换个规模或形状的第二种输入只多花一次测量，却能整类地干掉它。

给智能体一份剖析结果，而不是一个仓库。

这个领域已报告的最大增益，来自告诉智能体时间花在哪里，而不是换一个更好的模型。PerfAgent——一个由剖析器引导的迭代精修循环——在 GSO 上把「与专家修法相符的补丁」比例相对通用编码智能体基线大致翻了一倍（19.6% → 39.2%），在 SWE-fficiency-Lite 上从 26% 提到 74%。机理并不微妙：没有剖析结果时，智能体优化的是它最容易读懂的代码，而那与真正在跑的代码毫不相关。

• 把剖析结果作为上下文附上，而不是做成一个智能体可能忘记调用的工具。按自身耗时排名前 N 的函数、每个函数之上的调用树，以及运行时若能给出就附上的分配次数。这是仓库导航与代码上下文在性能场景下的专用答案。
• 出补丁之前必须先陈述机理。「这个函数占自身耗时的 61%；它每次调用都重新解析一遍配置；把解析提出去应当消掉这一部分。」没有假设的补丁就是一张彩票，而便宜地拒掉这类补丁，比任何提示词优化都值钱。
• 事后拿机理去对账测量结果。说法预言了一个比例，测量台量出了一个比例。两者不一致时，即使看起来是一次胜利，这个补丁也可疑——那道缝隙正是你抓住「顺手加的缓存」和「被跳过的工作」的地方。
• 每接受一个补丁就重新剖析一次。热点路径会移动。三个补丁之后还在照着最初那张火焰图干活的智能体，优化的是一个已经不存在的瓶颈。

那些看着像胜利、其实不是的补丁。

在系统提示词里维护一份显式的拒收清单，更好的做法是把它做成测量台里的自动检查。以下几类跨模型、跨代码库地反复出现：

• 地板以下的微优化。在一个占运行时 0.4% 的函数里把推导式换成生成器。它花掉评审时间，买来测量噪声，还把人类要批准的那份 diff 弄乱。
• 无声的资源置换。之所以更快，是因为现在把整份数据集都放进了内存。把峰值 RSS 和墙钟时间一起测，并把大幅回退当作未通过的关卡，否则你会在生产上才知道。
• 把工作删掉、而不是加速。删掉一趟校验、去掉一行日志、关掉一个断言。这最快，也正是正确性关卡必须跑全量套件的原因。
• 为基准量身定制的改动。一个专门特判工作负载所用尺寸或类型的分支。第 3 步里的第二种工作负载能拦住大部分，剩下的靠人读 diff。
• 叠加多个补丁却只测一次。五个被接受的改动，单看每一个都在噪声里，合起来报成 12%。在任何人相信这个加和之前，用完整的重复次数预算把整叠改动对着最初的基线重测一遍。

让测量结果跟着补丁一起交付。

这个智能体的产出不是一份 diff，而是一份 diff 加上评审者不必自己重跑一遍实验所需的证据；而评审正是剩下那些假阳性的葬身之处。

• 把数字写进 PR：工作负载、基线与打补丁后的区间、重复次数、机器身份、陈述的机理，以及峰值内存。任何一项需要评审者开口去要的，最后都会变成凭感觉批准。
• 预期 CI 硬件比你的测试机更吵。共享 runner 的方差常常是绑定机器的数倍，所以在本地好用的阈值到了 CI 会一直误报。要么把性能检查放到专用硬件上跑，要么把 CI 关卡设在一个真正可分辨的效应上，并接受它只能抓住大幅回退。
• 把每个被接受补丁的工作负载提升进回归套件。没有被守护的性能成果，两个季度之内就会被普通的功能开发消耗殆尽；而这种周期性的、无人值守的重跑，正适合交给智能体——见后台编码智能体。
• 用「是否与专家修法相符」给智能体打分，而不是用「找到了多少加速」。那些基准不约而同地收敛到这个指标是有原因的：一个稳定能找到 8%、却永远找不到 3 倍的智能体，做的和你拿来对标的那位工程师并不是同一份工作。测量台那一侧见评估编码智能体。