AlphaEvolve: A coding agent for scientific and algorithmic discovery

Paper: arXiv:2506.13131
Code: google-deepmind/alphaevolve_results
Code reference: main @ 4226acbf (2026-01-05)
Code note: 代码搜索未找到 AlphaEvolve 系统本体的开源实现；官方仓库只发布数学发现的结果数据与 mathematical_results.ipynb 验证代码。

速读结论

AlphaEvolve 的核心不是“让 LLM 直接给答案”，而是把可自动评分的问题改写成“可执行代码的进化搜索”：用户给初始程序、可演化代码块和 evaluator，系统用 Gemini 2.0 Flash / Pro 生成 diff，执行 evaluator 获得标量反馈，再把高分程序放回 program database 继续采样。论文最重要的证据来自三类任务：矩阵乘法张量分解中刷新 14 个目标的 upper bound，包括 56 年来首次在 characteristic 0 场景下把 (4\times4) 矩阵乘法从 Strassen 递归的 49 次复数标量乘法降到 48 次；50 多个数学构造问题中约 75% match SOTA、约 20% 超越 SOTA；Google 内部生产系统中恢复平均 0.7% fleet-wide compute、让 Gemini 训练用矩阵乘 kernel 平均快 23% 并使整体训练时间降 1%、在 TPU RTL 与 FlashAttention IR 上发现可验证优化。

这篇白皮书的贡献边界也很清楚：AlphaEvolve 强依赖机器可验证 evaluator，因此尤其适合数学构造、算法设计、compiler/kernel/硬件/调度这类可以自动打分的任务；它不是通用“科学家替代品”，也没有开源 agent 系统本身。论文可信度主要来自“代码执行 + 自动验证 + 人类专家/生产部署确认”，而不是自然语言 judge。

1. Motivation（研究动机）

传统科学与算法发现的瓶颈在于：人需要反复提出候选、实验、回退、再验证。LLM 已经可以生成代码、解释论文、提出假设，但如果直接让模型用自然语言“想出发现”，最大问题是缺少可靠 grounding：模型会幻觉，也很难在几十万次迭代后保持可验证性。AlphaEvolve 的动机是把发现问题限制在一个更可控但仍然很大的子集：候选解可以表示成程序，且候选程序可以被自动 evaluator 打分。

这个设定把 LLM 从“答案生成器”转成“变异算子”。模型不需要一次性证明答案正确，而是持续提出代码修改；正确性、性能和多目标 trade-off 由机器执行反馈决定。论文反复强调 automated evaluation 既是关键优势也是主要限制：如果一个任务需要湿实验、人工审美或无法自动模拟的物理过程，AlphaEvolve 的闭环就不完整；但在数学、计算机科学和系统优化中，大量高价值问题恰好能写成 evaluator。

与 FunSearch 的关系是理解动机的捷径。FunSearch 证明了“LLM + 进化搜索 + 自动 evaluator”可以发现数学构造，但它通常只演化单个 Python 函数、几十行代码、单一指标，并且依赖非常快的 CPU evaluator。AlphaEvolve 把这一范式扩展到更工程化的 code agent：能演化整个文件或代码库中的多个片段，支持任意编程语言，允许 evaluator 并行跑数小时甚至使用 accelerator，支持丰富上下文、多指标、meta prompt evolution，并能利用更强的 SOTA LLM。

图 1 的高层图可以概括为一个闭环：初始程序进入进化系统，LLM 产生修改，evaluator 执行并返回分数，数据库保存高分程序并继续驱动下一轮提示采样。这里的“agentic”不在于会聊天或调用通用工具，而在于它能长期、自主地维护一个程序种群，并把 execution feedback 变成 test-time compute。

2. Idea（核心思想）

AlphaEvolve 的核心思想是：把科学/算法发现问题 (P) 转成一个程序搜索问题。用户提供初始代码 (x_0)、可演化区域、评价函数 (h(x)\rightarrow {s_1,\ldots,s_k})，系统最大化一个或多个标量分数。候选程序既可以直接构造最终对象，例如图、点集、张量分解；也可以是一个搜索算法，在有限预算内寻找更好的对象；还可以同时演化中间解和搜索策略。

这种抽象带来三个关键好处。第一，候选以代码形式存在，天然可执行、可复现、可被 evaluator 检查，不容易停留在“像发现但不可验证”的自然语言层。第二，LLM 负责提出高层结构性改动，而不是在巨大离散空间里盲搜，因此比纯遗传算法更能利用代码语义、文献上下文和历史失败反馈。第三，进化数据库可以把不同局部最优、不同指标下的高分程序重新组合进 prompt，形成探索与利用的平衡。

论文对 AlphaEvolve 与 FunSearch 的差异给了一个很实用的定位表：FunSearch 更像函数级数学构造搜索器；AlphaEvolve 更像可处理工程代码的 evolutionary coding agent。它可以演化数百行代码、支持 Python 之外的 Verilog/IR/配置逻辑，evaluator 可以很慢但并行，提示可以包含论文、公式、代码片段、历史执行结果，并且能同时优化多个指标。

直觉上，AlphaEvolve 的成功依赖一个“LLM 创意—机器筛选”分工：LLM 产生多样且结构化的 diff，机器用 evaluator 过滤不可运行、错误、低分或不泛化的方案。这个分工也解释了为什么论文把它称为 test-time compute agent：能力提升不是来自模型参数更新，而是来自在测试时投入大量候选生成、执行与选择。

3. Method（方法）

3.1 总体框架

详细框架由五个角色组成：

• Task specification：用户给初始程序、被标记为可演化的代码块、评价代码和可选配置。评价函数通常是 Python evaluate，输入候选程序或其输出，返回一个标量字典；约定是数值越大越好。
• Prompt sampler：从 program database 取出历史程序、执行结果和分数，结合人工上下文、文献、模板随机化、meta prompt 等信息构造 prompt。
• LLM generators：使用 Gemini 2.0 Flash 与 Gemini 2.0 Pro 的组合。Flash 用低延迟提供候选量，Pro 提供较少但更强的高质量跃迁。
• Evaluators：把 LLM 生成的 diff 应用到代码上，运行 evaluator，必要时使用 cascade、随机输入、专家验证或并行评估集。
• Program database：保存程序、分数与输出，类似 MAP-Elites 与 island-based population 的混合，用于平衡 exploitation 与 exploration。

这个设计的重要细节是，LLM 输出不是自由文本答案，而是可应用到代码库的 diff。论文给出的格式是 SEARCH/REPLACE 块：模型先定位原代码片段，再给替换内容。这样做牺牲了一些生成自由度，但让系统能对已有代码库做局部、可审计的修改，适合工程系统中的 Verilog、Pallas kernel、XLA IR 等文本程序。

3.2 任务规格与 evaluator

设候选程序为 (x)，evaluator 为 (h)，则：

[ h(x) = {s_1(x), s_2(x), \ldots, s_k(x)}, \quad s_i \in \mathbb{R} ]

最简单场景是单目标最大化，例如构造图的大小、packing 的半径和、张量分解的负 rank。复杂场景可以同时返回多个分数：主目标、正确性罚项、泛化性能、稳定性、运行时间、可读性或中间统计。论文指出，多指标不只是“监控”，也可能让不同结构的高分程序共同进入 prompt，增加发现新结构的机会。

评价阶段包含三种重要机制：

1. Evaluation cascade：先用小规模或低成本测试过滤明显错误程序，只有早期分数足够好才进入更难、更慢的测试。矩阵分解任务中就会先检查候选算法是否值得用多随机种子继续跑。
2. LLM-generated feedback：某些理想特征难以写成精确公式，可以让 LLM 生成辅助反馈，但论文没有把它作为主路径优化。
3. Parallel evaluation：很多 evaluator 可以 embarrassingly parallel，例如多 seed 搜索或多输入形状 kernel benchmark，因此系统用异步 pipeline 提升吞吐。

3.3 Prompt sampling 与程序数据库

Prompt 不只包含当前 best program。它会从 database 取多个历史候选、对应执行输出、score、失败模式和系统指令。用户还能加入显式上下文，例如数学定义、论文 PDF、代码片段、工程约束；模板中的某些字段可以随机化，以增加生成多样性；meta prompt evolution 则让系统同时演化“如何提示 LLM”的策略。

Program database 的作用是避免系统退化成“重复问模型同一个问题”。它持续保存带分数的候选，并在未来 prompt 中重新暴露有用结构。论文说该数据库受 MAP-Elites 与 island model 启发：MAP-Elites 强调在行为/特征空间中保留多样 elite，island model 强调多个子种群并行探索，偶尔交换信息。这适合 AlphaEvolve，因为很多发现不是沿着单一 best trajectory 爬坡，而是需要保留看似次优但结构不同的候选，等待后续组合或 mutation。

3.4 异步分布式 pipeline

AlphaEvolve 用 Python asyncio 风格实现 controller、LLM samplers 与 evaluation nodes。系统目标不是让单个候选最快完成，而是在固定预算内最大化“提出并评估的想法数量”。这对慢 evaluator 很关键：如果一次 kernel benchmark、硬件验证或搜索需要很久，同步串行会让 LLM 空等；异步 pipeline 可以在某些候选等待 evaluator 时继续采样其他候选。

论文没有开源该 pipeline 的实现，因此下面伪代码是按论文机制重构的概念流程，不是 released code：

def alphaevolve(initial_program, evaluator, database, llm_ensemble, budget):
    database.add(program=initial_program, scores=evaluator(initial_program))
    while budget.remaining():
        # 1. 从数据库选择多样且有用的历史程序，构造 rich prompt
        context = database.sample_elites_and_diverse_programs()
        prompt = render_prompt(
            task_spec=evaluator.description,
            programs=context.programs,
            scores=context.scores,
            outputs=context.outputs,
            extra_context=context.user_docs,
            meta_prompt=database.sample_meta_prompt(),
        )
 
        # 2. Gemini Flash 提供吞吐，Gemini Pro 提供少量高质量跃迁
        diffs = llm_ensemble.generate_search_replace_diffs(prompt)
 
        # 3. 应用 diff，编译/运行初筛，失败候选直接丢弃
        candidates = [apply_diff(context.target_program, d) for d in diffs]
        candidates = [c for c in candidates if syntax_and_smoke_test(c)]
 
        # 4. 用 cascade evaluator 打分；慢任务并行调度
        for c in candidates:
            partial = evaluator.quick_stage(c)
            if partial.promising:
                scores = evaluator.full_stage(c)
                database.add(program=c, scores=scores, outputs=evaluator.outputs)
 
        # 5. 数据库更新 island / elite / 多指标索引，供下一轮 prompt 采样
        database.rebalance_exploration_and_exploitation()
    return database.best_programs()

3.5 代码搜索与 released code 映射

官方可访问的 GitHub 仓库是 google-deepmind/alphaevolve_results，commit anchor 为 main@4226acbf (2026-01-05)。该仓库 README 明确说明：它包含论文 Section 3 中数学发现的 Google Colab notebook 与正确性验证代码，但 does not contain the code to run AlphaEvolve。因此，笔记中的系统架构与 pipeline 来自论文描述；代码级映射只适用于结果数据和验证 notebook。

Paper concept	Released artifact / file	可信用途	不覆盖的部分
数学发现结果与验证	mathematical_results.ipynb	包含 tensor decomposition、kissing/packing/Heilbronn 等构造数据与验证代码	不包含 AlphaEvolve controller、prompt sampler、database、LLM 调用
矩阵乘法张量分解正确性	Notebook 中 verify_tensor_decomposition(...) 及 rank 数据 cell	可复跑检查低秩分解是否满足矩阵乘法张量条件	不解释 AlphaEvolve 如何搜索到这些分解
论文中的 accompanying Colab	arXiv source 的 \ResultsColabURL 指向同一 notebook	对论文 “decompositions / constructions can be found in Colab” 的出处锚定	不提供工程/生产系统代码
Borg / TPU / Pallas / XLA 优化	论文文本与图	只提供方法与结果描述	内部生产代码、benchmark harness、部署配置未发布

这意味着复现者可以验证部分数学结果，但不能从 released repo 复现 AlphaEvolve agent 本身，也无法复现实验中的 Google 内部基础设施优化。

4. Experimental Setup（实验设置）

论文的实验不是单一 benchmark，而是四组发现任务。

4.1 矩阵乘法张量分解

目标是为矩阵乘法张量 (\langle m,n,p\rangle) 找到更低 rank 的分解。Rank 对应计算 (m\times n) 与 (n\times p) 矩阵乘法所需的标量乘法次数。AlphaEvolve 不是直接输出分解，而是演化一个搜索/优化程序：该程序包含初始化、reconstruction loss、Adam optimizer、随机种子、多目标反馈等组件；evaluator 会运行该程序并检查得到的分解 rank 与精确性。

关键设置包括：

• 对每个目标 ((m,n,p))，候选程序用多随机种子运行；分数既看最低 rank，也看达到该 rank 的 seed 比例。
• 为避免数值误差，评价时把元素 round 到最近整数或半整数；prompt 中也显式要求生成 near-integral solution。
• 对部分目标会加入人工想法，例如把 stochasticity 或 evolutionary idea 放进初始程序，但 (4\times4) 等大多数表中结果来自简单初始程序。

这张 diff 图说明 AlphaEvolve 并不是只调 learning rate，而会改写较大段搜索程序。它的贡献更接近“生成一个更好的算法来找分解”，而不是直接枚举矩阵。

4.2 数学构造问题

数学部分覆盖 50 多个开放构造问题，涉及 analysis、combinatorics、number theory、geometry、packing。任务形式一般是：给定数学定义，写一个程序构造对象并由 evaluator 检查性质和分数。例如 kissing number 需要构造 11 维点集并证明可对应到不重叠球配置；Heilbronn 变体需要最大化最小三角形面积；circle packing 需要最大化半径和。

这里 evaluator 的角色尤其重要：如果构造数据可以被机器验证，LLM 输出再怪也能被过滤；如果发现超过已知 SOTA，仍需数学或程序检查确认。论文说明许多问题来自外部数学家 Javier Gomez Serrano 与 Terence Tao 的建议，强调 human expert 仍然参与了问题 formulation。

4.3 Google 计算基础设施优化

工程部分包含四个层级：

1. Borg data center scheduling：把在线 job scheduling 抽象成二维 vector bin-packing。候选 heuristic 对 pending job 与 candidate machine 的 CPU/memory residual 打分；Borg 仍只在可用机器集合内选择，因此 correctness by construction。
2. Gemini Pallas kernel tiling：优化用于 Gemini 训练的矩阵乘 kernel 的 tiling heuristic。训练/评估数据来自真实 kernel input shapes，一半用于优化，一半用于泛化测试；目标是实际 TPU runtime。
3. TPU RTL optimization：让 AlphaEvolve 直接改写高优化 Verilog arithmetic circuit，目标是降低 power/area 等指标，同时通过 robust verification 保持功能等价。
4. XLA-generated FlashAttention IR：直接优化 compiler-generated IR，包括 FlashAttention kernel 以及输入输出预/后处理。每次修改都用随机输入对照未修改代码检查数值正确性，最终由 human experts 确认全输入正确。

Borg heuristic 的论文代码片段为：

[ \text{score} = -(\text{cpu_residual}+\text{mem_residual}+\frac{\text{mem_residual}}{\text{cpu_residual}}+\frac{\text{cpu_residual}}{\text{mem_residual}}) ]

这个函数的直觉是惩罚 CPU/memory 使用不平衡，减少 stranded resource。它简单、可解释、易部署，因此论文说它比深度强化学习方案更适合 mission-critical scheduler。

4.4 Ablations

Ablation 在两个任务上进行：低秩矩阵分解和 kissing number lower bound。论文测试的组件包括 evolutionary approach、prompt 中显式 context、meta prompt evolution、full-file evolution、模型强度/ensemble 等。对照包括 “No evolution”（反复给同一初始程序）、“No context in the prompt”、“No meta prompt evolution”、“Small base LLM only” 等。

这些 ablation 的解释重点不是某个单独 trick，而是组合系统的必要性：进化数据库提供长期记忆和多样性，context 让 LLM 理解具体数学/工程约束，full-file evolution 让搜索可以改变算法结构，强模型提供跳出局部最优的候选。

5. Experimental Results（实验结果）

5.1 矩阵乘法：14 个目标超过已知 upper bound

论文表 1 给出多个矩阵乘法张量的 rank upper bound。代表性结果如下：

Tensor (\langle m,n,p\rangle)	之前 best known	AlphaEvolve	说明
(\langle2,4,5\rangle)	33	32	half-integer/integer 分解可验证
(\langle2,4,7\rangle)	46	45	超过已知构造
(\langle3,4,6\rangle)	56	54	改进 2 次乘法
(\langle3,4,7\rangle)	66	63	使用 complex-valued multiplications
(\langle4,4,4\rangle)	49	48	56 年来首次在 characteristic 0 语境下低于 Strassen 递归 rank
(\langle4,4,8\rangle)	98	96	complex-valued exact multiplication
(\langle4,5,6\rangle)	93	90	论文 note concurrent work 也发现 rank 90

最醒目的结果是 (\langle4,4,4\rangle)：Strassen 1969 后，递归得到 rank 49 的 (4\times4) 矩阵乘法长期是 characteristic 0 下的开放目标；AlphaEvolve 找到 rank 48 的复值矩阵乘法算法。论文也谨慎地区分了 field with 2 elements 的 rank 47 结果：那不是 characteristic 0 场景，不能直接代表实数/复数矩阵乘法。

5.2 数学构造：50+ 问题中约 75% match、约 20% surpass

论文报告 AlphaEvolve 在 50 多个数学问题上约 75% 匹配已知最佳构造，约 20% 超越 SOTA。几个有代表性的结果：

• Kissing number in dimension 11：把下界从 592 提高到 593。论文给出 lemma：若非零点集 (C\subset \mathbb{R}^d) 满足最小两点距离不小于最大范数，则把点投影到半径 2 的球面上可得到合法 kissing configuration。
• Heilbronn variants：单位面积凸区域中 (n=13) 的最小三角形面积从 0.0306 提高到 0.0309，(n=14) 从 0.0277 提高到 0.0278；单位面积三角形中的 11 点构造达到 (\ge 0.0365)。
• Circle packing：单位正方形中 26 个圆半径和从 2.634 到 2.635，32 个圆从 2.936 到 2.937；周长 4 的矩形中 21 个圆半径和达到 2.365。
• Erdős minimum overlap：给出新的 upper bound，略优于之前记录。

这些结果的共同点是：发现可以用少量构造数据表达，但搜索空间极大；evaluator 可以严格检查约束并计算目标值；LLM 的作用是提出人类不容易直接枚举的构造生成程序或搜索启发式。

5.3 生产系统优化：小百分比但高价值

工程结果不如数学结果那样“定理化”，但在生产规模下价值很高：

• Data center scheduling：AlphaEvolve 发现的 Borg heuristic 已部署到整个 fleet，post-deployment measurements 显示平均恢复 0.7% Google fleet-wide compute resources，否则这些资源会 stranded。0.7% 听起来小，但在全球数据中心规模上是显著容量。
• Gemini kernel engineering：针对用于 Gemini 训练的矩阵乘 kernel，AlphaEvolve 发现的 tiling heuristic 相比 expert-designed heuristic 取得平均 23% kernel speedup，并带来 1% overall training time reduction；优化周期从数月人工工程缩短到数天自动实验，且已生产部署。
• TPU circuit design：在高优化 Verilog arithmetic circuit 中，AlphaEvolve 找到去除不必要 bit 的简单 rewrite，经 TPU designers 验证正确，并集成到 upcoming TPU。论文承认 downstream synthesis tools 也独立捕获了该具体改进，但在 RTL 源级早期给出可读 Verilog 修改仍有流程价值。
• Compiler-generated IR / FlashAttention：对 XLA-generated IR 的 FlashAttention 模块，kernel 本体在目标配置上加速 32%，输入输出 pre/postprocessing 部分加速 15%。所有修改先用随机输入与 reference 对照，最终由专家确认全输入正确。

这些案例说明 AlphaEvolve 对“已经高度优化”的系统仍可能有效，但前提是 evaluator 能准确衡量真实目标，例如 real TPU accelerator runtime、simulation of fleet workload、硬件验证或 numerical equivalence。否则 agent 可能只会 exploit benchmark。

5.4 Ablation 解读

Ablation 曲线的共同趋势是 full AlphaEvolve 明显优于删减版本。几个可操作结论：

• 没有 evolution 时，系统只是重复从同一初始程序采样，缺少积累与组合，长期预算不能有效转化为发现。
• 没有 explicit context 时，LLM 不知道问题的数学结构、工程约束和历史结果，容易生成表面合理但低分的改动。
• 没有 meta prompt evolution 或 full-file evolution 时，系统仍能改进，但更难跳出“局部参数调节”，尤其在矩阵分解这种需要改写搜索算法结构的任务上更明显。
• 只用 small base LLM 时，候选质量下降；Gemini 2.0 Flash/Pro ensemble 的意义在于吞吐和质量的组合，而不是单纯堆大模型。

6. 局限性与风险

第一，AlphaEvolve 的主要限制是 evaluator。论文明确说它处理的是能设计自动 evaluator 的问题；自然科学中许多实验无法完全自动化或模拟，因此不适合直接套用。LLM 可以提供部分高层反馈，但这不是论文优化过的主路径。

第二，agent 可能 exploit evaluator。如果 evaluator 只测小规模、单分布或过窄目标，程序可能得到高分但不泛化。论文中的工程案例通过 held-out workload、随机输入等方式缓解；数学结果通过 exact verification 或专家检查缓解。但开源读者无法看到内部 evaluator 细节，因此对生产结果只能信任论文描述。

第三，复现性不完整。官方 GitHub 仓库发布了数学发现数据和验证 notebook，但没有发布 AlphaEvolve agent、prompt sampler、program database、LLM 调用配置、内部 evaluator、Borg/Pallas/Verilog/XLA 环境。读者可以验证若干数学构造，不等于复现发现过程。

第四，系统成本没有完整量化。论文强调“thousands of LLM samples suffice” 相比 FunSearch 的 millions 更高效，但没有给出每个任务的 token、wall-clock、TPU/GPU/CPU 成本。对于外部团队，搭建 evaluator 与并行执行环境可能比调用 LLM 本身更昂贵。

第五，安全与治理问题没有深入讨论。一个能自动修改生产调度、compiler IR、硬件 RTL 的 agent 必须有严格 sandbox、权限隔离、回滚、审计和专家批准流程。论文案例都保留了 correctness by construction、verification 或 human expert confirmation，但没有给出通用安全框架。

7. 对后续工作的启发

对 agent 研究而言，AlphaEvolve 的启发是：高价值 agent 不一定要追求开放式网页/工具环境；把环境做窄、把 evaluator 做硬、把反馈做密，反而更容易产生真正发现。它也提示“LLM + 进化 + 执行反馈”可以作为一种 test-time scaling 路径：不是让模型想更久，而是让系统生成更多候选、运行更多验证、维护更好的长期搜索状态。

对工程团队而言，最值得复制的不是完整系统，而是任务改写方式：选择一个高频、高价值、可自动验证的优化点；把候选表示成可执行代码；定义 quick tests、held-out tests 与最终专家验证；让 LLM 只产生小的可审查 diff；把所有候选与分数持久化，避免每次从零开始。

对科学发现而言，AlphaEvolve 显示了 human-AI partnership 的现实形态。外部数学家帮助提出可形式化问题，工程师提供 evaluator 和基础设施，LLM agent 执行大规模变异搜索，最后人类验证、解释和部署。它不是替代科学家，而是把某些“可计算构造搜索”的劳动密集部分自动化。

8. 资产与来源说明

图像来自 arXiv source tarball 的原始 figure assets，经 source-first extraction 转为 vault assets；本笔记没有使用整页 PDF screenshot。

其他保留的源图：