（来源：网易科技）
一次代码优化评估动辄 85 分钟，一次 CPU 微架构设计评估时长高达 28 小时……当 Coding Agent 提出的方案远多于系统能够验证的数量，即使搜索能力极强，获取反馈的成本会把整个搜索进程卡住。
一种自然的思路是：是否可以只评估代码中真正影响性能的部分？例如，如果修改的是某个 GPU 内核中的矩阵乘法，就先单独测量这一部分，而不是每次都运行整个工作负载；如果优化的是推理服务的调度器，就构建一个简化的负载模型，先快速判断不同调度策略的优劣。
然而，仍有两个难题亟待解决：1）系统必须找到真正值得优化的代码区域；2）局部测试或简化模型必须能够正确判断候选方案的相对优劣。
日前，谷歌团队及其合作者提出了 DuoDiscover，试图从根本上解决这个问题，其关键创新就是让 AI 同时寻找优化目标和适合这个目标的廉价评估器，并持续检验这些评估器是否仍然可靠。
论文链接：https://arxiv.org/abs/2610.17184
在 SWE-fficiency 基准上，DuoDiscover 的几何平均加速比达到 15.02 倍，是人类专家补丁（6.90 倍）的两倍多，在高度优化的 vLLM 和 SQLite 上仍取得 1.92 倍和 1.38 倍提升；在 NVIDIA SOL-Exec 的 235 个 GPU 内核中，其中 121 个排名第一；更在单次评估长达 28 小时的 CPU 微架构任务上超越基于 AlphaEvolve 的方案，仅用 16.7 天，收益就达到基于 AlphaEvolve 的方案耗时 40 多天所得的 1.65 倍。
图｜DuoDiscover 一览：(a) 快慢双循环；(b) vLLM 上 DuoDiscover 达 1.92 倍，Claude Code 为 1.07 倍；(c) SOL-Exec 榜单名次分布
研究方法
当真实评估太贵时，搜索要回答的不只是“优化什么”，还有“如何低成本地衡量进度”。DuoDiscover 让每个 Agent 自己选定一个目标区域，并为它编写一个几秒出分的代理评估器，依据代理分数高频试错，只把少数有希望的修改交给真实评估确认。
1.找到目标，量身定制代理评估器
Agent 首先分析代码和性能瓶颈，自主选择一个目标区域（target）。这个区域可以是 GPU 内核中的某个计算阶段，也可以是大型代码库中的一个函数或模块。这与 AlphaEvolve 的一种典型使用方式不同，后者通常需要用户预先在源代码中标记待演化的代码区域，而 DuoDiscover 让 Agent 自己决定从哪里入手。
目标选得是否合理，直接影响最终收益。因此，Agent 不只是寻找容易修改的代码，还要估计该区域的潜在收益，并考虑能否为它构建可靠的代理评估器。
确定目标后，Agent 会编写一个成本更低的评估脚本，用来快速比较不同修改的效果。它不必精确复现真实评估的分数，只需要尽可能正确地排出候选方案的优劣次序。以 vLLM 为例，一个 Agent 将调度器的 prefill 批处理机制选为优化目标，并构建了一个简化的 decode 步耗时模型。这个代理评估器几秒钟就能给出结果，而完整服务评估需要约 85 分钟。
这正是 DuoDiscover 强调的“协同发现”（co-discovery）：必须一起寻找优化目标和代理评估器。一个潜在收益很高、却无法被廉价而可靠地评估的目标，未必适合当前搜索预算；反过来，一个运行很快的评估器，如果不能反映真正的性能变化，也没有意义。
2.快慢双循环：廉价搜索，真实确认
DuoDiscover 将优化过程拆分为快、慢两个循环。
其中，快循环负责高频试错。Agent 修改目标区域，通过代理评估器打分；如果分数改善，就保留修改，否则回退。
慢循环负责真实验证。系统将有希望的候选方案送入完整评估，确认实际收益，并重新检查代理评估器的可靠性。
图｜DuoDiscover系统总览
两者形成互补，廉价评估负责扩大搜索范围，昂贵的真实评估负责保证最终结果可信。
3.防止代理评估器被“钻空子”
代理评估器并非始终可靠。随着 Agent 不断针对它优化，候选方案可能越来越擅长提高代理分数，却没有真正改善目标系统。这就是奖励作弊（reward hacking）的一种表现。为此，DuoDiscover 引入了保真测试（fidelity test）。
系统使用 Kendall τ 秩相关系数，检验代理评估器与真实评估对候选方案的排序是否一致。相关性阈值为 0.5，且只统计真实分数差异超过评估噪声的候选方案对；正式判定还要求满足最低样本数和统计显著性条件。每次真实评估之后，系统都会重新检查已验证的代理评估器。一旦发现排序一致性下降，就将其作废，要求 Agent 重建评估器或转向新的目标。
在 vLLM 案例中，一个基于短负载扫描的代理评估器最初通过了验证，但后来在更高负载下出现排序反转。系统识别出这一问题后，将其作废并让 Agent 重建评估器。
4.多 Agent 协作，但不依赖中央分解
DuoDiscover 的协调器不负责预先把整个问题拆成固定任务，而是管理多个自主探索的 Agent。它主要执行三类操作：终止长期没有进展的 Agent；在有前景或尚未探索的目标上启动新 Agent；将其他 Agent 已确认有效的修改传递给新 Agent，或向运行中的 Agent 通报其他 Agent 的发现。
这种自下而上的搜索方式，让系统能够在早期广泛探索，在后期集中利用已验证的成果。
实验结果
评测覆盖从软件到硬件的完整链路：两个代码库基准、四个 GPU 与 TPU 内核套件、五个真实系统。除单独注明外，所有方法在相同硬件与预算下运行，分数取最终候选多次重新评估的中位数，而非搜索中出现过的最好成绩；在所有代码库与内核基准上，DuoDiscover 的分数高于Claude Code、OpenEvolve 和 PerfAgent 等所有基线。
1.代码库优化：加速比达人类专家两倍以上
在 SWE-fficiency 的 100 项任务上，DuoDiscover 达到 15.02 倍几何平均加速比，高于人类专家补丁的 6.90 倍、Claude Code 的 12.81 倍和 PerfAgent 的 12.27 倍。
图｜代码库优化表现比较
在分析的 20 项任务样本中，代理评估器的中位耗时为 40 秒，耗时仅为真实评估的 1/22。DuoDiscover 中位耗时仅需 2.5 小时，就能达到 Claude Code 使用 8 小时取得的最终分数。
2.GPU、TPU 内核：多个基准领先
在 SOL-Exec 的 235 个 GPU 内核中，DuoDiscover 平均 SOL 得分为 79.74%，121 个排名第一，212 个进入前三。SOL 衡量的是实现达到理论硬件性能上限的程度，并非性能提升了 79.74%。
图｜50 个内核上最佳 SOL 分数随搜索时间、Token 数与真实评估次数的变化
在其他基准中，DuoDiscover 在 FA4 上取得 11.97% 的几何平均加速，在 JAXBench 上达到相对 XLA 的 4.62 倍加速，在 TPU-Inference 上达到相对优化版 Pallas 内核的 2.68 倍加速。
3.真实系统：vLLM 综合收益达到 1.92 倍
在 8 张 NVIDIA B200 GPU 上运行 GLM-5.2 推理服务时，团队同时优化解码延迟、首 Token 延迟、功耗和吞吐量。Claude Code 经 12 次真实评估后，四项目标的几何平均收益为 1.07 倍；DuoDiscover 仅用 7 次真实评估就达到 1.92 倍。
图｜真实系统案例的增益随搜索时间的变化
最终方案约有 500 行系统层改动。p99 解码延迟降低至原来的 1/2.94，首 Token 延迟降低至原来的 1/3.61，功耗降低约 21%，吞吐量基本保持不变。
在 FreeToken、SQLite 和 zstd 上，DuoDiscover 也分别取得 1.44 倍、1.38 倍和 1.16 倍的收益，均超过实验中的 Claude Code 对照结果。
4.CPU 微架构：超越最佳人类设计
在 DPC4 数据预取器设计任务中，DuoDiscover 的总体性能增益为 6.31%，超过 AlphaEvolve 驱动的 ArchAgent v2（3.82%）和最佳人类方案 BertiGO（3.52%）。
图｜DPC4数据预取器不同方法性能增益比较
DuoDiscover 在 16.7 天内评估约 8000 个候选方案；ArchAgent v2 第一阶段则耗时超过 40 天，评估超过 12000 个候选方案。需要注意的是，实验优化目标为 CPU 微架构中的数据预取器，而不是整个CPU 的设计。
当然，这项研究也存在一些局限性。
例如，如果代理评估器失效，仍需要真实评估兜底。在分析样本中，41% 的仓库任务代理评估器和 45% 的内核代理评估器后来因排序漂移被作废。如果找不到可靠的代理评估器，就只能退回昂贵的标准搜索。
同时，优势依赖评估成本和搜索预算。构建代理评估器、积累验证样本都需要预热时间。团队明确指出，在评估预算特别小的场景中，这套机制的优势会减弱。
当一次真实评估要跑几十分钟甚至一整天时，寻找一个好的代理评估器，可能与寻找一个好的优化方案同样重要。这为高性能软件、芯片微架构乃至其他评估成本高昂的工程问题提供了一条值得探索的路径。
更多技术细节，详见原论文。
作者：张佳怡
