把编码智能体直接怼到基准测试上，通常拿不到什么干净信号。跑出来的提升往往落在环境噪声区间里，或者干脆是散热降频造成的波动，而不是代码真的变好了。Elastic 团队在 Elasticsearch 代码库上做自动化性能优化时，遇到的第一个坎就是这个。

他们的解法是搭一套高度可信的测量回路：默认智能体有相当比例的时候会判断错误，但这套回路能可靠地把错误抓出来，也能在它判断正确时给出证明，然后引导它下一步该往哪里看。

打开网易新闻 查看精彩图片

为什么性能优化适合交给智能体

Elasticsearch 要跑的工作负载很杂，既有持续的重度索引构建，也有实时搜索和分析。想在所有场景都交出好性能，既要覆盖面铺得够广，又得钻进代码库深处，逐个理解每种负载的优化空间。

过去这个过程的瓶颈是人。工程时间就那么多，没法把庞大且不断演进的代码面上每一条热点路径都翻一遍找低效点。而编码智能体进步之后，性能优化变成了一件可以半自动推进的事。

原因在于，性能优化和很多软件工程难题不一样，它自带一个便宜且客观的验证器。让模型把代码改快，最后会有一个硬数字告诉你到底发生了什么，背后还有性能分析工具解释原因。前提是，你得真的信得过这些数字。

把"找机会"和"改代码"拆开

做任何软件工程问题，第一步都是识别出正确的高层组件。Elastic 团队在这里做了一个架构选择，后来被证明非常有用：把"判断优化机会在哪里"和"执行代码修改的循环"分开。

智能体从一个真实工作负载出发，但只用它来挖掘信息，而不是直接进入改代码的环节。这样拆开之后，测量回路承担的是验证职责，改动循环承担的是执行职责，两者不互相污染。

这套机制跑起来之后，结果自己会说话。团队把它放到代码库上，已经开始在技术栈的多个层面挖出有意义的收益。

他们提到，后续会展开几个已经找到的例子：Elasticsearch 查询语言（ES|QL）里的字符串转换低效问题、NEON 向量点积实现的一处改进，以及他们当时在用的 gzip 库存在一个升级机会。

这套回路的设计取舍，以及它和更广泛的"如何有效搭建这类工具"之间的关系，是这篇文章真正想讲的部分。