企业官网建设流程全解析

今天分享的论文是《Barbarians at the Gate: How AI is Upending Systems Research》

原文链接：[2510.06189] Barbarians at the Gate: How AI is Upending Systems Research

这是一篇关于使用AI赋能系统研究的论文，对于科研人员来说似乎是起到了帮助。

人工智能（AI）正通过自动化新解决方案的发现过程，改变我们所熟知的研究模式。在给定任务下，典型的AI驱动方法分为两步：（i）生成一组多样化的解决方案；（ii）验证这些解决方案并选择其中能解决问题的方案。关键在于，该方法假设存在可靠验证器——即能够准确判断某一解决方案是否解决给定问题的工具。本文认为，长期聚焦于设计和评估面向性能的新算法的系统研究，尤其适合AI驱动的解决方案发现。原因在于，系统性能问题天然具备可靠验证器：解决方案通常在真实系统或模拟器中实现，而验证过程可简化为在预定义工作负载下运行这些软件载体，并测量其性能。我们将这种方法命名为面向系统的人工智能驱动研究（AI-Driven Research for Systems, ADRS），该方法通过迭代生成、评估和优化解决方案来推进研究。

我们基于现有开源ADRS实例OpenEvolve，在多个不同领域开展案例研究，包括多区域云调度、混合专家（Mixture-of-Experts, MoE）推理负载均衡、基于大语言模型（LLM）的SQL查询以及事务调度。在多个案例中，ADRS发现的算法性能超过了最先进的人工设计方案（例如，运行时提升高达5.0倍，或成本降低26%）。我们提炼了指导算法进化的最佳实践（从提示词设计到评估器构建），适用于现有框架。随后，我们探讨了这一方法对系统社区的广泛影响：随着AI在算法设计中占据核心地位，人类研究人员将更多地聚焦于问题构建与战略指导。研究结果既凸显了AI的颠覆性潜力，也揭示了在AI时代调整系统研究实践的迫切需求。

本文的核心论点是：一类名为“面向系统的人工智能驱动研究（ADRS）”的新型AI驱动方法，已开始在自动化算法发现中展现出良好前景，并最终将促使人们重新评估系统研究人员的传统角色。为证实这一观点，我们借鉴先前研究的思路，通过现有ADRS框架（如OpenEvolve[Sharma (2025)]）开展多个案例研究，生成的算法在一系列计算机系统研究问题上，性能达到甚至超过了最先进的人工设计方案[Wu et al. (2024); AI (2024)]。例如，在混合专家（MoE）模型的负载均衡问题中，OpenEvolve发现了一种跨GPU重新均衡专家的算法，其速度比已知最佳基准方案快5.0倍；在通过跨多云区域使用抢占式实例以降低成本的作业调度问题中，OpenEvolve生成的解决方案比专家开发的基准方案节省了约30%的成本。

通过使用GPT-4o、o3和Gemini 2.5 Pro等强大的大语言模型，我们的大多数案例研究能在几小时内生成性能达到或超过当前最先进水平的解决方案，成本仅为几美元到几十美元（见表1）。需说明的是，这些结果由不同学生完成，且未进行大量消融实验，因此所报告的结果应被视为ADRS框架能力的下限。我们预计，随着研究人员对这些框架的使用经验不断积累，以及框架本身和其底层模型的持续改进，将获得更优的结果。

系统性能问题之所以特别适合AI驱动研究，一个主要原因是其解决方案的验证相对容易。AI解决问题的典型模式是：生成多样化的解决方案集合，然后验证其中哪些（若存在）能真正解决问题[Trinh et al. (2024); Silver et al. (2017)]。因此，验证准确性是AI驱动方法在特定问题领域取得成功的关键。总体而言，验证过程具有挑战性——例如，验证AI生成的程序或常识问题的答案是否正确，往往并不容易。幸运的是，系统性能问题不存在这一困扰：在这类问题中，新算法、新协议等解决方案通常会集成到网络、数据库或操作系统等载体中；随后，通过在代表性工作负载下运行集成了该解决方案的系统，并观察生成的性能指标，即可完成评估。

例如，评估新路由协议时，我们会在网络系统的路由器中实现该协议，然后针对不同工作负载测量吞吐量、延迟、丢包率等输出指标；评估新CPU调度器时，可在操作系统中实现该调度器，然后测量交互式与批处理应用混合运行时的响应时间。此外，为避免依赖真实系统进行评估的高昂开销，研究人员通常会开发模拟器——这类模拟器能捕捉真实系统的显著特征，支持快速且低成本的迭代。模拟器允许研究人员在将解决方案部署到实际系统前进行快速评估，这使得系统研究特别适合AI驱动的探索。

在AI驱动研究的更广泛背景下，本文的研究范围经过刻意收窄：我们不仅将范围限定在系统领域，还在该领域内仅聚焦于解决方案发现任务，而在很大程度上忽略了研究过程的其他方面（如问题构建、文献综述或论文撰写）。收窄研究范围具有多个优势：首先，如前所述，由于解决方案的正确性可基于实证系统性能验证，这能降低AI生成内容的“幻觉”风险；其次，这使我们能在单一领域深入研究并开发更优的解决方案，而非将精力分散到多个领域。同时，若该方法取得成功，系统领域的成果将足以通过提供更快、更高效的基础设施，推动计算机科学其他领域的进展。

最后，鉴于向AI驱动研究的转型即将到来，我们探讨了其对系统社区的影响。随着AI承担起算法发现与优化的角色，人类研究人员的工作重点可能会转向问题构建、高层构思和战略指导。在这种新模式下，研究人员将扮演强大AI研究助手的“指导者”角色：定义有意义的问题、提出创新性的起点、从生成的解决方案中提炼洞见。这种方法有望形成强大的良性循环：同样的AI驱动方法可用于改进AI系统本身，从而实现发现速度的复合式提升。

本文旨在呼吁系统社区主动思考这些变化、调整自身技能，并引导人类与AI在研究中的协同进化。为推动这一转型，我们提供了利用这些技术的最佳实践，概述了其优势，并强调了几个关键的开放问题。最终，借助AI，研究人员将能把时间投入到工作中最具创造性和成就感的部分。

2.1 大语言模型（LLM）出现前的系统优化AI技术

在LLM出现之前，机器学习已在系统领域得到广泛应用。在数据库领域，学习型模型被用于查询优化[Marcus et al. (2019)]、基数估计[Yang et al. (2022; 2020)]、学习型索引[Kraska et al. (2018)]以及自动化系统调优[Aken et al. (2017)]。强化学习（RL）及其他基于学习的技术已推动核心网络问题的发展，包括拥塞控制[Jay et al. (2018)]、数据包分类[Liang et al. (2019)]和拓扑建模[Rusek et al. (2020)]。更广泛地说，强化学习在系统领域的应用还包括数据处理工作负载调度[Mao et al. (2019)]、物理设备布局[Mirhoseini et al. (2017)]以及视频流传输[Du et al. (2020)]。

2.2 基于学习方法的自动化发现

AI领域的一系列进展表明，自动化发现在日益复杂的科学和计算领域具备强大能力。早期成功案例包括AlphaGo[Silver et al. (2017)]和AlphaZero[Silver et al. (2018)]——这两个系统证明了搜索与强化学习结合可精通博弈游戏；还有AlphaFold[Jumper et al. (2021)]，其在蛋白质结构预测领域取得了突破性进展。AlphaDev[Mankowitz et al. (2023)]将这些理念拓展到高效底层算法的发现，而AlphaChip[Goldie & Mirhoseini (2024)]则利用强化学习生成可投入生产的芯片布局。Big Sleep[Walker (2025)]通过AI智能体检测软件中的安全漏洞。最近，诸如AlgoTune[Press et al. (2025)]等基准测试工具已被开发，用于评估LLM在不同领域优化程序的能力。

2.3 基于LLM的代码助手

LLM彻底改变了代码生成方式，从而加速了研究进程。GitHub Copilot[GitHub (2021)]、Cursor[Cursor Inc. (2024)]、Codex[OpenAI (2025)]和Claude Code[Anthropic (2025)]等代码助手，帮助研究人员快速原型化想法、构建模拟器并实现基准方案。这些工具能将高层算法思路快速转化为可运行的实现代码。近期研究还探索了将LLM用于性能关键型代码[Hong et al. (2025)]，例如GPU内核代码生成与优化[Ouyang et al. (2025)]，这进一步体现了其作为ADRS构建模块的潜力。

2.4 基于LLM的驱动研究

除代码辅助外，近期研究还利用LLM实现研究过程中更大范围的自动化。例如，AlphaEvolve[Novikov et al.; Nadga et al. (2025)]和OpenEvolve[Sharma (2025)]等框架，采用多维度精英存档（MAP elites）算法和基于岛屿的种群模型来进化和发现新算法；GEPA[Agrawal et al. (2025)]通过反射式提示词进化优化LLM生成结果；LLM4AD[Liu et al. (2024a)]则提供了一个算法设计的统一平台。ShinkaEvolve[Lange et al. (2025)]强调样本高效的进化过程，EvoPrompt[Guo et al. (2023)]聚焦于使用遗传算法优化提示词，MetaMuse[Ma et al. (2025)]提出了用于算法生成的自反射框架，而PolicySmith[Dwivedula et al. (2025)]则在算法设计中筛选性能最优的解决方案。

端到端研究自动化的尝试也在不断涌现。MLGym[Nathani et al. (2025)]为AI研究智能体提供标准化基准测试，Code Researcher[Singh et al. (2025)]探索将基于LLM的智能体用于大规模软件工程任务。近期关于自进化AI智能体的研究，可系统地优化其内部组件[Fang et al. (2025)]。目前，将这些方法应用于更广泛系统问题的兴趣正不断增长[Liang et al. (2025); Zhou (2024)]。

本文研究聚焦于系统领域的自动化算法发现——该领域中，高性能评估器可实现可靠验证，而这正是高效自动化的关键前提。

本文倡导采用AI驱动方法解决系统性能问题。尽管性能优化并非系统研究的唯一重点，但仍是核心方向之一——对顶级系统、网络和数据库领域会议（NSDI、OSDI、SIGMOD、SOSP和VLDB）的简要调查显示，超过三分之一的已发表论文将性能优化算法作为核心贡献。我们认为AI驱动方法特别适合此类问题，主要原因在于：针对候选解决方案，开发稳健且经济高效的验证流程相对容易。

首先，验证特定解决方案是否能提升系统性能较为简单。这类解决方案通常会引入新的技术或算法，并直接在其旨在优化的系统中实现；验证过程可简化为在代表性工作负载下运行该系统，然后检查其在相关性能指标上是否优于基准方案。

其次，系统性能问题的解决方案通常能保留原始方案的正确性，即便无法完全保留，验证其正确性也相对容易。例如，验证负载均衡算法是否调度了所有分配的任务、网络路由器是否转发了所有接收到的数据包，这些操作都较为简便。

第三，系统代码中通常需要改进的部分规模往往较小，例如调度器、负载均衡器或资源分配器的核心逻辑。这使得生成的代码更易于人类理解，进而有助于验证其正确性。在我们所有的案例研究中，研究人员都能轻松理解生成的解决方案，并识别其核心思路与技术（见第5章）。随着这些工具能力的增强，我们预计其可修改的范围将扩大，涵盖多个组件（例如设计复杂的分布式协议时）。在这类场景下保持代码的可解释性，是未来研究的重要方向。

最后，系统研究人员在将解决方案部署到真实系统前，通常会使用模拟器进行开发和评估。基于模拟器的验证成本相对较低，因此即便搜索过程效率不高、生成的候选解决方案超出实际需求，对这些方案的评估仍具备可行性。例如，我们的每个案例研究仅需数小时即可完成，成本不超过几十美元。尽管如此，为复杂系统（如操作系统、数据库）构建既经济又能准确反映真实系统特性的模拟器并非易事，这仍是未来研究需解决的问题（见7.2.1节）。

系统研究人员采用的典型研究过程通常需要数周或数月时间。总体而言，该过程包含五个阶段（图1）：

- 问题构建：明确需要解决的问题（如提升系统吞吐量或降低延迟）。整个研究过程围绕解决该问题展开，并最终呈现研究成果。

- 评估框架：开发用于实现和评估潜在解决方案的框架——该框架可以是系统本身，也可以是近似系统行为的模拟器。即便已有可用系统，研究人员也可能构建模拟器以加速开发进程。此外，研究人员还会收集或使用现有工作负载（轨迹）或基准测试，为评估提供输入。

- 解决方案开发：针对问题设计解决方案（如算法），例如新的调度算法、资源分配算法或搜索算法。

- 评估：在模拟器或真实系统中实现解决方案，使用选定的工作负载评估其性能，并将结果与基准方案进行比较。若解决方案未体现性能提升，研究人员会返回“解决方案开发”阶段，优化现有方案或开发替代方案。

- 论文撰写：当解决方案达到预期效果后，整理研究发现并撰写论文，用于学术发表。

图 1：系统研究过程的五个阶段。本文展示了人工智能如何实现解决方案与评估阶段（灰色区域）的自动化。

图2：系统研究过程各阶段耗时分布，基于31名博士生的调查数据。算法设计（21.5%）和评估（20.1%）合计占总工作量的40%以上，这表明利用AI加速该过程具备巨大潜力。

大语言模型（LLM）已从简单的文本补全功能，发展到具备复杂推理与工具使用能力，由此催生了新的架构，提升了LLM应用的可靠性，并拓展了其适用任务范围。本文聚焦于如何利用LLM设计、实现和评估系统研究问题的新解决方案（如算法），并将这种方法命名为面向系统的人工智能驱动研究（ADRS），其架构如图3所示。本质上，ADRS实现了图1所示系统研究过程中的两个迭代阶段——“解决方案开发”与“评估”。根据对30余名系统研究人员的调查（图2），这两个阶段的耗时合计约占研究总耗时的40%。

图3：在系统研究流程（见图1）背景下展示的AI驱动系统研究（ADRS）架构。ADRS（灰色区域）实现了解决方案阶段与评估阶段的自动化。

ADRS的核心是一个循环流程：在每次迭代中，生成或优化用于LLM的提示词，以产生新解决方案或改进现有方案，随后在真实系统或模拟器中评估这些方案。这一迭代过程会持续进行，直至发现符合预期的解决方案、耗尽资源预算，或研究人员决定终止。ADRS由五个组件构成：

- 提示词生成器（Prompt Generator）：创建用于生成解决方案的提示词。该提示词包含研究人员提供的问题陈述与上下文（可能包括系统或模拟器代码），还可纳入解决方案选择器提供的往期解决方案及其评估结果，以进一步优化提示词。

- 解决方案生成器（Solution Generator）：将提示词生成器输出的提示词输入至一个或多个LLM，生成新解决方案或改进现有方案。通常，这一过程通过直接修改模拟器或真实系统中的代码实现。

- 评估器（Evaluator）：接收解决方案生成器输出的方案，在预定义的工作负载（轨迹）上运行该方案，然后根据运行性能为方案打分，并可利用LLM提供定性反馈。若得分足够高，循环即终止。

- 存储组件（Storage）：存储解决方案、方案输出结果、评分以及评估器提供的反馈。

- 解决方案选择器（Solution Selector）：从存储组件中筛选部分解决方案，提供给提示词生成器，以优化提示词并生成新的改进方案。

这些组件共同构成了一个内部自动化反馈循环，使ADRS能够针对特定问题迭代优化解决方案。该内部循环还可与外部反馈循环结合：研究人员观察生成的解决方案，提供高层指导，并将其融入后续提示词中。

在大多数情况下，ADRS会采用模拟器（而非真实系统）来实现和评估解决方案，主要原因有两点：首先，真实系统的代码库通常过于庞大，无法放入当前LLM的上下文窗口；其次，在模拟器中进行评估的速度可能比在真实系统中快几个数量级，大幅加速解决方案的进化过程。

如前所述，ADRS实现了图1研究过程中的“解决方案开发”与“评估”阶段：其中，“解决方案开发”阶段由提示词生成器和解决方案生成器共同实现，“评估”阶段由评估器实现；存储组件和解决方案选择器则是辅助组件，为提示词生成器提供支持。对于研究过程的其他阶段（问题构建、评估框架开发、论文撰写），ADRS并无影响——既不会增加也不会减少研究人员在这些阶段的工作难度。因此，ADRS能够推动研究过程的帕累托优化（即在不损害其他目标的前提下提升某一目标性能）。

ADRS并非全新概念，它旨在涵盖近年来为类似问题开发的系统架构——这类系统均支持高效验证。下文将介绍若干此类系统实例：

4.3.1 AlphaEvolve与OpenEvolve

AlphaEvolve[Novikov et al.]是谷歌DeepMind开发的系统，利用人工智能自动发现和设计新型高性能计算机科学算法。与ADRS类似，AlphaEvolve接收用户提供的问题定义、初始参考方案以及用于量化评估候选方案的程序化评估函数。它采用进化算法实现内部反馈循环，但未包含接收人类反馈的外部循环（不过此类循环可轻松添加）。该进化算法结合了多维度表型精英存档（Multi-dimensional Archive of Phenotypic, MAP）算法[Mouret & Clune (2015)]和基于岛屿的种群模型[Tanese (1989)]，确保数据库中不仅存储性能最优的程序，还包含各类具备不同属性的高质量解决方案。

OpenEvolve[Sharma (2025)]是AlphaEvolve核心概念的开源实现，它提供了一个控制器，协调用于代码生成的LLM集合、用于评分的评估器池以及用于存储和采样候选方案的程序数据库。尽管OpenEvolve包含核心关键功能，但并未实现AlphaEvolve的所有功能（如元提示词进化），同时新增了部分功能（如进化树可视化）。由于其开源属性和灵活性，OpenEvolve成为了本文研究中使用的主要框架。

4.3.2 GEPA

GEPA（Genetic-Pareto，遗传帕累托）[Agrawal et al. (2025)]是另一款近期推出的类ADRS框架，采用不同的进化流程，并通过自然语言反馈进行反射式优化，以改进提示词。其进化算法通过反射式更新迭代修改提示词、合并候选方案，并通过帕累托前沿筛选保留多样化的高性能解决方案，从而自动平衡探索与利用的关系（探索指寻找新方案，利用指优化已有方案）。

4.3.3 LLM4AD

LLM4AD[Liu et al. (2024a)]是一个通用平台，将搜索、LLM生成与评估集成到统一框架中。它提供了模块化组件，涵盖问题定义、解决方案生成、评估等环节，并通过标准接口集成了多种搜索策略（包括进化算法如NSGA-II、MOEA/D，邻域搜索和随机采样）。此外，LLM4AD还提供统一的评估沙箱、日志与性能分析工具，并支持超过20项任务，可作为端到端测试平台，帮助研究人员在不同领域对ADRS流程进行基准测试。

4.3.4 代码助手

Cursor、Windsurf等代码助手也可被视为ADRS实例。这类工具能够理解整个代码库的上下文，支持复杂的代码修改；可根据指令探索解决方案空间以进化算法、利用工具验证方案，并通过自然语言提示词协调整个反馈循环。此外，这些工具还为研究人员提供了便捷的交互方式，支持人类驱动的外部反馈循环，助力研究人员在搜索过程中提供指导。

5 评估与案例研究

为评估ADRS方法，我们研究了多个子领域的11项系统任务，包括网络、数据库和核心系统，并在表1中总结了研究结果。每个案例研究均遵循统一框架，涵盖问题设置、环境、进化流程、模型使用及最终结果，该框架的详细内容如表2所示。

表 1：项目任务目标、对应当前最优技术（SOTA）文献、相对于 SOTA 与基准方案的性能提升，以及整体时间 / 成本效率的总结。大多数任务能在数小时内、以适中成本达到接近 SOTA 的性能，证明了ADRS 方法的实用性。

表2：面向AI驱动算法发现的问题构建与评估扩展架构。每一行对应实验设置中的一个要素。

下文将介绍4个具有代表性的案例研究，提炼对其他研究人员有价值的洞见——这些洞见既包括当前框架的局限性，也涵盖使用框架的最佳实践（详见第6章）。本文案例研究主要采用OpenEvolve作为ADRS工具。

这4个案例研究涵盖分布式系统、数据库和LLM系统领域，具体如下：

1. 优化截止日期约束下的抢占式实例成本节省：在给定任务截止日期的前提下，解决方案旨在最大限度利用公有云中成本更低的抢占式实例，同时不违反截止日期要求。ADRS在单区域场景下将现有最优（SOTA）结果提升了16%，在多区域场景下相对强基准方案实现了48%的性能提升。

2. 优化MoE推理中的专家放置：解决方案通过在GPU间映射专家副本，平衡各GPU的负载。ADRS使专家重新均衡的耗时较已知最佳私有实现缩短了5倍。

3. 优化LLM SQL查询推理：解决方案通过重新排序表中的行与列，最大化LLM推理过程中KV缓存的命中率。ADRS实现了与现有最优方案相当的命中率，同时将重排序算法的运行时间缩短了3倍。

4. 优化事务调度：解决方案通过重新排序事务以减少冲突，进而缩短总完成时间（makespan）并提升吞吐量。ADRS“重现”了在线场景下的现有最优解决方案，并在无公开解决方案的离线场景下，将强基准方案的性能提升了34%。

在此需特别说明：本文介绍的案例研究由不同学生在2025年夏季并行开展，因此所使用的配置参数存在差异（有时差异较大）。这使得案例间的直接比较存在难度，同时也凸显了开展系统性消融实验的必要性——需明确不同问题对应的最优配置（详见7.2.2节）。因此，本文呈现的案例研究结果应被视为现有ADRS框架能力的下限。随着研究人员对这些框架的使用经验不断积累，以及框架本身的持续进化，我们有望获得更优的结果。

6 早期最佳实践

尽管现有ADRS框架在案例研究中展现出潜力，但这类系统仍处于起步阶段，存在诸多显著局限性（如可分析代码的规模与复杂度有限、易出现故障等）。表3对我们观察到的最常见故障进行了分类，这些故障主要分为三类：

- 运行时错误：生成的代码因编译错误或超出实验资源预算而无法运行。

- 搜索故障：进化过程停滞（如陷入局部最优、在劣质解决方案间反复切换）。

- 算法故障：最终解决方案可运行，但存在缺陷或未实现基准方案性能提升（包括忽略问题约束、利用评估器漏洞、仅进行浅层修改等）。

我们在附录B中详细讨论了这些故障。基于实践经验，下文将从ADRS的核心组件（如图3所示）出发，提出避免这些故障、缓解其他局限性的最佳实践。

表3：ADRS流程中的常见故障模式（基于420条LLM判断轨迹的估计分布）

6.1 提示词生成器（PROMPT GENERATOR）

清晰且范围明确的问题定义，是实现高效算法进化的基础。

提供结构化说明

许多“运行时错误”和“算法故障”都源于上下文缺失（如问题关键细节遗漏、代码API文档缺失）。设计精良的提示词应尽可能具体、结构化，明确界定三个核心部分：

- 问题：需解决的核心任务。

- 评估标准：解决方案的评估方式（包括优化目标与正确性约束）。

- 上下文：必要信息（如所需API）。

我们建议在启动进化前，利用外部LLM（如ChatGPT、Gemini）协助构建提示词结构。

选择合适的基础程序

基础程序的选择对算法进化轨迹有重要影响。存在漏洞或性能较差的基准方案，会将迭代资源浪费在“修复 trivial 问题”上（导致预算耗尽）；而性能优良、代码简洁的基准方案，则可加速“有意义改进”的探索。例如，在“LLM-SQL”案例研究中，已发表的基准方案已实现接近最优的前缀命中率，核心瓶颈在于运行时间——因此仅需约100次迭代，即可进化出“运行时间缩短3倍且无命中率损失”的解决方案。

反之，“性能过优”且“依赖高层API”的基准方案，会限制搜索范围，导致仅能实现浅层微优化。在“不可迟到（Can’t Be Late）”问题（5.1.1节）中，以“简单贪心策略”为起点的进化结果，优于以“性能更强的均匀进度策略”为起点的结果——后者限制了探索空间。我们建议为进化过程选择“代码简洁、质量高的最小化基准方案”，例如利用Claude Code等代码助手生成的方案。

提供适度的解决方案提示

尽管详细的问题说明始终有益，但“提供解决方案提示”（即针对“系统应如何解决问题”给出具体建议）的价值需灵活判断：过多指导可能导致过早收敛，阻碍新颖解决方案的发现；指导不足则可能降低搜索效率（如陷入循环停滞）。例如，在EPLB问题中，提示可减少“在‘极端副本策略’上浪费的迭代次数”；但在事务调度案例中，“关于批处理的提示”却使搜索偏向次优设计，而“无约束搜索”反而让OpenEvolve发现了“速度提升30%的贪心策略”。

我们发现，当搜索陷入循环停滞时，“提供中间人类反馈作为提示”尤为有效。综上，建议尝试“不同提示详细程度”的多个版本，并根据进化进展注入相关提示。

选择合适的抽象层次

建议仅暴露与目标匹配的抽象层次。若允许访问高层外部库API，有时会导致次优优化（例如，通过“用PyTorch原语替换自定义算子”实现 trivial 加速，却阻碍更深层次创新）。若目标是实现算法突破，应限制API访问，引导系统探索新策略（而非依赖预制解决方案）；反之，若目标是提升执行效率，则可提供优化库访问权限。在实践中，需精细平衡“允许有用捷径”与“强制实质性问题解决”的边界，以避免微优化。

6.2 解决方案生成器（SOLUTION GENERATOR）

采用模型集合

搜索故障通常源于解决方案生成器“过度探索”或“过度利用”。建议采用模型集合，以平衡探索与利用：一方面，GPT-o3等推理型模型可通过生成新颖解决方案促进探索——在“不可迟到”问题（5.1节）的消融实验中，o3提出的创新性想法最终带来了性能更优的解决方案，但这类模型通常速度较慢、成本较高；另一方面，非推理型模型能更高效地优化现有解决方案，使OpenEvolve在相同预算下实现更快迭代、更多探索次数。

因此，目前建议采用两种模型构建高效探索集合。实践表明，使用超过两种模型往往会引入矛盾思路，导致候选解决方案出现不稳定性与突变漂移。

6.3 评估器（EVALUATOR）

防止过拟合

若仅基于“狭窄的工作负载”进行评估，易导致“过拟合”等算法故障——解决方案可能出现“行为硬编码”或“对特定轨迹过拟合”的问题。例如，我们在“不可迟到”问题的消融实验（附录A）中发现：若仅基于“单一可用性模式”评估抢占式调度策略，该策略在“未纳入评估的工作负载”上性能会显著下降。涵盖边缘场景的“更广泛、更多样化的测试集”，可有效缓解这一问题。

防止奖励作弊

“奖励作弊”指解决方案利用评估器漏洞而非解决预期问题的现象。例如，在“多智能体系统故障检测”的进化实验中，部分候选方案绕过了评估流程的某个阶段，在未完成完整任务的情况下获得高分。为避免这一问题，评估器应结合“正确性、效率、鲁棒性”等多维度评估信号，并增加对抗性测试——这不仅能降低ADRS框架“操纵评估”的可能性，还能减少“目标错位”故障，确保候选方案满足所有约束。

6.4 解决方案选择器（SOLUTION SELECTOR）

搜索结果在很大程度上还取决于迭代间候选方案的保留方式，而这一过程由解决方案选择器决定。

平衡探索与利用

贪心选择器虽收敛速度快，但存在过早收敛的风险；而过度随机的选择器会浪费资源，导致循环停滞故障。高效的选择器需在保留多样性的同时，推动性能更优的候选方案演进。例如，AlphaEvolve通过将MAP-Elites（多维度表型精英存档算法）与基于岛屿的进化相结合，实现了这种平衡。在实践中，探索-利用的比例是一个可调节参数（如在OpenEvolve中），谨慎调整该参数是避免搜索故障的关键。

7 局限性与开放挑战

7.1 ADRS适合哪些问题，又不适合哪些问题？

基于早期实践经验，ADRS最适合需“局部修改”、“快速评估”且“验证简单”的问题；对于需“跨多系统修改”、“依赖弱验证器”或“评估成本高”的问题，ADRS的效果则较差。理解这些边界有助于研究人员将ADRS应用于最可能成功的场景，并调整系统以更好地契合其优势。综上，ADRS尤其适合具备以下特性的系统性能问题：

- 孤立修改：由于现有LLM在修改少量代码时可靠性更高，ADRS更适合用于改进“与系统其他部分隔离的策略或算法”。例如调度器、缓存管理器、负载均衡器和资源分配器。相反，现有ADRS系统难以优化“分布式于大型系统中的策略或协议”——例如涉及组件间复杂交互的共识协议（如状态管理、网络通信与故障检测逻辑[Lamport (2001); Ongaro & Ousterhout (2014)]）。

- 可靠评估：对于两个解决方案，需能轻松判断哪一个性能更优，以及两者在语义上是否等价（即产生相同输出）。例如，改进负载均衡器时，通过测量不均衡系数即可判断方案优劣；若两个方案能将每个查询路由到同一服务的副本，则其语义等价性可直接验证。但在其他场景中，验证语义等价性可能困难甚至无法实现。例如，任意修改查询计划并验证其与原始计划等价，在通常情况下是不可能的[Abiteboul et al. (1995)]——尽管某些特定转换（如重排序连接操作、重排序表的列或行）可被证明能保留语义。

- 高效评估：评估过程需同时满足快速性与成本效益。ADRS发现新解决方案可能需要数百甚至数千次迭代，若每次评估需耗时数小时、成本达数百美元，则整个过程可能持续数月甚至数年，总成本高达数十万美元。例如，权重压缩等GPU密集型工作负载，每次进化周期可能耗时超过12小时（见第5章）；或需跨数千个GPU进行的大规模分布式训练，均不适合ADRS。

最后，对于可转化为优化问题并通过现有求解器（如整数线性规划（ILP）求解器）直接解决的问题，我们认为ADRS的优势并不明显。

7.2 开放挑战

随着ADRS逐渐成为加速系统研究的潜力方向，两个核心问题随之产生：我们应构建哪些工具以更好地支持ADRS？又应如何改进ADRS本身？

7.2.1 支持ADRS：构建更优评估器

从案例研究中可反复观察到一个结论——ADRS的性能取决于其依赖的评估器。要实现成功的解决方案发现，评估器需能为搜索过程提供“准确、快速且详细”的反馈。下文提炼了设计ADRS评估器时应遵循的关键特性：

- 保真度（Fidelity）：评估器需捕捉与待解决问题相关的系统显著行为（例如网络领域的流级或包级保真度）。所需的保真度水平不仅取决于研究对象系统，还与ADRS可能探索的解决方案类型相关。

- 通用性（Generality）：评估器需支持多样化的工作负载与轨迹，以提供可靠的反馈信号，避免对单一配置或数据集的过拟合。

- 速度与可靠性（Speed and Reliability）：如前所述，可靠且高效的评估器是ADRS成功应用的关键。构建支持“快速分叉与回滚”的测试平台（例如通过轻量级虚拟机、容器快照或数据库克隆[Liu et al. (2025)]），可大幅缩短反馈周期，提升ADRS的可扩展性。

基于此，我们提出两种改进评估框架效率的方法：

问题特定模拟器（Problem-specific simulators）

模拟器虽能提供快速、低成本的评估，但设计难度大——需在保真度与简洁性间取得平衡，以支持LLM的推理过程。一个切实可行的方案是构建“领域特定模拟器”：仅捕捉与任务相关的行为。例如，在建模CPU调度时，无需包含完整的操作系统细节。OpenEvolve等工具可迭代优化此类模拟器，直至其指标（如延迟、吞吐量）与真实系统对齐。尽管模拟器构建成本较高，但可在相关问题间复用，从而分摊开发成本。

级联评估器（Cascading evaluators）

通过“级联评估器”可实现快速且准确的评估：从快速、粗粒度的成本模型，逐步过渡到更慢但高保真的评估器。例如，评估数据库查询时，可先使用简单成本模型[Siddiqui et al. (2020)]，再逐步采用粒度递增的模拟器、仿真器，最终在真实系统上进行测试。在网络领域，会话级模拟器的评估粒度比包级模拟器更粗。这种方式与标准研究流程一致：先快速构建原型，再精确验证。

7.2.2 改进ADRS

要扩大ADRS的应用范围，需在以下核心组件方向取得突破：

提示词生成器（Prompt Generator）

现有ADRS框架通常依赖相对简单的提示词，仅包含问题描述。正如人类研究人员的想法需基于先前工作，ADRS框架也应整合检索技术[Packer et al. (2023)]，从更广泛的知识体系（如学术文献、文档与相关案例）中汲取信息，以更好地指导搜索。如第6章所述，在提示词中提供更丰富的解决方案提示可提升搜索效率，而减少提示词则可能促进更广泛的探索。提示词进化技术[Novikov et al.; Agrawal et al. (2025)]（即LLM自我优化上下文）可帮助平衡这一权衡。

解决方案生成器（Solution Generator）

优秀的解决方案生成器应具备“自主开发者”的能力：能够导航、推理并修改系统代码库，而非仅处理孤立代码片段。例如，现代AI工作负载常依赖“工作负载分析”与“跨层优化”以降低硬件成本[Chung et al. (2024)]；类似地，优化通信协议的分布式系统可能需要协调修改发送方与接收方逻辑[Ongaro & Ousterhout (2014); Ng et al. (2023)]。要实现这一点，解决方案生成器需具备更强的智能体编码能力：理解依赖关系、调用分析工具，并能跨非连续代码模块进行连贯推理。

除单一模型外，ADRS框架还应支持“专业智能体集合”——通过协作生成高质量解决方案。未来研究应聚焦于开发工具，使其能根据给定问题自动优化智能体组合，类似于组建具备互补技能的研究团队。

评估器（Evaluator）

现有部分ADRS框架（如OpenEvolve）要求研究人员将直觉性权衡转化为数值权重，这在实践中往往具有挑战性。例如，在EPLB案例研究中，我们难以确定“负载均衡”与“重新均衡算法运行时间”的精确权重。未来系统可通过自动学习用户偏好来解决这一问题，潜在方法包括：

- 偏好学习（Preference Learning）：ADRS可向研究人员展示成对解决方案（例如“方案A速度更快但公平性较差；方案B公平性更优但速度较慢”），由研究人员选择偏好方案。通过观察这些选择，ADRS可推断出需优化的潜在目标函数。

- 逆强化学习（Inverse Reinforcement Learning, IRL）：若研究人员能提供若干“优质”解决方案示例（例如具备特定公平性与性能水平的方案），ADRS可反向推断出最可能生成此类方案的奖励函数。

解决方案选择器（Solution Selector）

ADRS框架发现新解决方案的过程目前仍是一个黑箱。当前的进化搜索具有整体性，仅输出单一最终程序，且常将“优秀思路”与“劣质实现”混合，导致有潜力的想法因实现问题被否定。已有研究[Tang et al. (2025)]表明，将“构思”与“代码生成”分离可解决这一问题。

此外，进化搜索效率较低，常反复尝试失败的启发式方法或重复出错（见附录B）。未来需开发更灵活的框架，支持更细粒度的反馈：允许人类或LLM锁定有效代码、通过提升多样性跳出局部最优，或在进化停滞时回滚到先前版本。

整体框架（Overall Framework）

最后，我们讨论与ADRS整体方法相关的开放挑战：

- 超参数调优（Hyperparameter Tuning）：平衡LLM的探索与利用仍具挑战性，且常依赖试错法。未来研究应聚焦于自动化调优过程。例如，可引入元学习层，使系统能在进化过程中自主学习与调整，提升框架的可靠性与易用性。

- 人机ADRS交互（Human-ADRS Interaction）：同步交互（如Cursor等交互式助手）与异步交互（如OpenEvolve等自主框架）的最优平衡仍是开放问题。ADRS的核心挑战之一是明确“何时人类指导能增加价值”与“何时ADRS应自主行动”。

8 ADRS如何影响研究过程？

尽管ADRS存在局限性（见7.1节），但其已能在两个关键方面为研究人员提供帮助：

- 加速发现（Accelerating Discovery）：ADRS工具可自动化实现、调试等繁琐任务，让研究人员得以将精力集中在问题选择、系统架构与设计上。即便并非完美的解决方案，也能通过揭示新方向创造价值。例如，在遥测修复案例研究中，AI生成的洞见为人类设计更优算法提供了参考。

- 实现超越人类的结果（Achieving Better-than-Human Results）：ADRS工具探索解决方案空间的广度远超人类。人类可能在取得突破后停止探索，而AI可继续测试变体以获取增量收益——这些微小改进会不断累积。例如，在EPLB案例研究中，OpenEvolve发现的算法通过挖掘被忽略的优化点，性能超越了现有最优方案。

因此，ADRS有望重塑我们所熟知的系统研究。

看待ADRS的一种视角是：它为研究人员提供了数量几乎无限的“可靠执行指令的助手”。与初级研究人员类似，ADRS框架在获得清晰的问题说明与明确目标时，能发挥最佳效果。

由此，ADRS为已有的研究层级增添了新维度。例如，在学术界，教授通常指导博士生或博士后，后者再指导本科生；如今，这一体系中的每个角色都可借助ADRS工具加速工作，拓展研究范围。

在此背景下，两个核心问题应运而生：

- 研究人员的角色将如何变化？ 随着ADRS工具能自主解决越来越多的问题，研究人员将有更多时间投入高价值活动——选择研究问题并精确构建问题。若能成功实现，ADRS有望提升研究体系中所有人（无论是教授还是学生）的效率，大幅提升生产力。

- ADRS会导致研究人员数量减少吗？ 我们认为情况恰恰相反。ADRS反而可能扩大研究社区规模：即使是非专业问题解决者，也能借助ADRS做出有意义的贡献。最终结果将是研究进展加速——更快、更好地解决更多问题。而且，历史经验表明，开放研究问题的数量几乎是无限的。例如，仅在AI系统领域，工作负载正变得愈发复杂（如测试时计算、在线强化学习），硬件异构性不断提升（如专用加速器、新型网络技术），对性能与可扩展性的需求也达到了前所未有的高度（如多模态训练与推理）。

做个总结

随着AI系统接管算法发现工作，人类研究人员的角色也将发生转变。正如学术导师指导学生一样，未来的研究人员将为这些AI系统充当指导者。研究人员的核心职责将继续是定义问题、引导研究过程，并对结果进行批判性评估。

这一转变最深远的影响之一，是其有望形成一个良性循环：我们可以利用ADRS来改进ADRS本身。近期研究表明，AI模型能够自主优化自身推理过程、调试代码，并发现更高效的策略[Fang et al. (2025)]。随着这些AI智能体快速实现自我改进，它们将大幅加速科学发现的步伐。

总而言之，本文阐述了ADRS在系统研究中的潜力。案例研究表明，ADRS方法已能在关键性能问题上超越人类基准方案。尽管目前仍处于早期阶段，但我们呼吁系统社区接纳这些工具——不仅将其视为研究的加速器，更应将其作为研究对象本身。改进ADRS（提升其效率、可扩展性与可靠性）本身就是一项系统领域的挑战。因此，我们认为系统构建者在塑造AI驱动发现的未来方面，具有独特的优势。

附录

在案例研究中，ADRS（面向系统的AI驱动研究）展现出推动系统研究的潜力，但目前这类系统仍需精心配置才能发挥作用。为缓解相关问题，我们首先对ADRS常见的故障模式进行分类；在下一节（见第6章）中，我们将概述解决这些局限性的最佳实践与指南。

如表格3所示，我们将故障分为三大类——运行时错误（execution errors）、搜索（进化）故障（search/evolution failures）与算法故障（algorithm failures），并报告了它们在我们评估中的出现频率。各类故障的详细描述见第6章。

运行时错误

约三分之一的故障源于直接的运行时失败。最常见的情况是语法与接口错误：生成的解决方案代码因缺少导入语句、类型不匹配或误用必需接口，导致无法编译或与评估器对接。另一种故障是预算耗尽：候选程序消耗过多内存、触发超时，或超出模型API配额。

搜索故障

约一半的故障发生在“程序可执行但搜索无法推进”的场景。过早收敛指搜索过程过早陷入局部最优，例如在多区域传输任务中执着于斯坦纳树策略，却忽略利用数据分区的潜在机会。循环停滞指生成近乎重复的解决方案且无性能改进，例如迭代仅重命名变量或添加日志代码。突变漂移指对解决方案的修改相互矛盾或随机无序，例如在多区域网络传输任务中，在广度优先搜索（BFS）树与图基方法之间反复切换，延缓甚至阻碍收敛。

算法故障

这类故障指候选解决方案可运行，但未实现算法层面的改进。常见模式包括目标错位：解决方案忽略约束条件（例如提升吞吐量却违反延迟服务等级协议（SLO））；次优优化：进化后的解决方案仅对API进行浅层修改，未实现算法创新；过拟合：解决方案行为被硬编码以适配评估轨迹（例如抢占式调度策略在未见过的抢占模式下性能骤降）；奖励作弊：解决方案利用评估器漏洞而非解决目标问题，例如在多智能体实验中，部分候选程序绕过算法必需的某个阶段，导致评估器给出高分。