LLM让圆打包解刷新十项纪录

一个 LLM 引导的程序进化系统，最近在 Packomania 的 csqv 圆打包基准上刷新了 10 个最佳已知解。

这项工作的关键不在于让大语言模型直接计算 100 多个圆应该摆在哪里，而是让 LLM 负责改写和进化一个优化算法：模型提出程序层面的修改，独立验证器运行候选程序并打分，只有真正改善结果的版本才会被保留。根据项目作者近日公布的结果，N=101 至 N=114 的 10 个问题实例都取得了改进，目标指标为圆半径之和，提升幅度在 2.4% 至 5.4% 之间；整个过程只进行了 15 轮迭代，LLM 总成本为 27.72 美元。

Packomania 还对这些结果进行了独立接收或核验。需要强调的是，这里的最佳解是 best-known solution，也就是当前公开记录中的最佳已知解，不等于数学意义上的全局最优解。

这次实验真正改变的，是 LLM 的工作位置

LLM 引导程序进化是一种让语言模型迭代修改完整程序，并通过可执行评估结果筛选版本的优化方法。

通常说到 LLM 解优化问题，第一反应是让模型输出一个解：一组坐标、一段参数，或者一套操作步骤。但这类做法有明显上限。模型可以生成看起来合理的坐标，却很难在几十万次局部搜索、碰撞检测和随机重启之间稳定地做出选择；更不用说，圆打包这种问题对微小数值误差非常敏感，肉眼看起来更紧凑的布局，可能因为两个圆相交而直接失效。

这次方案把任务拆成了两层。

• 内层搜索负责寻找具体圆布局，包括圆心位置、半径调整和局部优化。
• 外层进化负责修改内层搜索策略，例如初始化方式、扰动幅度、接受准则、重启机制和局部搜索顺序。
• 独立验证器负责执行程序、检查约束并计算目标值，不接受模型自己的解释作为成绩。
• 历史记录与排行榜负责告诉模型哪些尝试有效、哪些尝试失败，以及当前算法卡在什么位置。

简单说，LLM 并不是那个“摆圆的人”，而更像是一个能够读代码、看实验曲线、提出新实验方案的算法研究员。真正决定结果的，仍然是程序执行和硬指标验证。

这种分工很重要。对于可验证的优化任务，模型最擅长的是提出结构化假设：是不是应该换一种初始化？是不是要把探索集中到最有潜力的搜索分支？是不是应该在接近停滞时增大扰动，而不是继续做小幅微调？至于假设是否成立，则交给评估器用真实运行结果回答。

圆打包为什么适合测试这种方法

圆打包问题是一个在给定区域内安排多个圆、同时尽量增大半径或压缩占用空间的几何优化问题。

它看起来规则，实际却非常难。假设需要在一个固定区域内放置 N 个圆，每个圆都有中心坐标和半径，系统至少要满足三类约束：圆不能越界，任意两个圆不能重叠，所有圆的半径还要尽可能大。随着 N 增加，变量数量、接触关系和局部最优结构都会快速膨胀。

当 N 达到 101 至 114 时，问题已经不是“找一个大概布局”，而是要处理大量相互牵制的几何关系。一个圆移动几乎必然会影响周围多个圆；局部区域看似还能挤进去一个圆，可能会破坏更大范围内的接触网络。这也是为什么传统优化器往往需要大量随机初始化、退火、梯度近似、约束修复和长期运行，才能把结果再向前推进一点。

Packomania csqv 基准的价值，在于它提供了可复现的公开排行榜和明确的数值评价。对这类任务而言，算法是否有效不依赖主观判断：如果圆越界或相交，候选解就会被判定为无效；如果合法，则可以根据半径之和等指标进行排序。

这使它天然适合 LLM 驱动的闭环实验。模型可以犯错，但错误会被程序快速淘汰；模型可以提出听起来很聪明的策略，但如果跑分下降，就无法进入下一轮；模型也不需要凭语言描述证明自己改进了算法，分数本身就是反馈。

15 轮迭代，为什么能得到 2.4%—5.4% 的提升

这次结果最值得关注的不是单轮提升，而是进化循环中反馈信息的组织方式。

根据作者披露的描述，系统从一个相对简单的种子求解器开始。LLM 每一轮都会看到当前程序、此前尝试过的修改、每次运行的成绩，以及哪些版本被保留。它随后提出算法级变化，由评估器独立运行。新版本只有在目标值更好且满足约束时，才会刷新当前最佳程序。

这种流程可以概括为四步：

1. 提出假设：模型分析当前搜索策略的弱点，生成代码层面的算法修改。
2. 执行实验：候选程序在固定基准和评估环境中运行。
3. 验证与排名：验证器检查合法性，并计算圆半径之和等指标。
4. 更新记忆：保留成功改动，记录失败原因，将结果反馈给下一轮。

它和普通的代码生成有本质差异。普通代码生成往往只看一次需求和一次测试；程序进化则把代码视为一个可持续实验对象。每一版程序都不是最终答案，而是下一版的实验材料。

从优化角度看，这相当于让 LLM 在算法设计空间里做一种启发式搜索。传统进化算法通常变异参数或候选解，而这里变异的是求解器本身。搜索对象从“某个布局”提升到了“如何找到布局的方法”。

这也解释了为什么单个模型调用的能力不是唯一决定因素。模型是否能读懂历史轨迹、避免重复失败、识别当前瓶颈，以及能否提出足够多样的算法变化，可能比单次回答是否精彩更重要。

成本只有 27.72 美元，但不能简单理解为低成本碾压

这次实验总 LLM 成本为 27.72 美元，15 轮迭代平均每轮约 1.85 美元。

这个数字说明，LLM 作为算法搜索外层控制器并不一定昂贵，尤其当真正耗时的是本地程序评估，而不是模型生成文本时。不过，27.72 美元并不等于整个实验的总成本。圆打包求解器需要运行候选程序，评估时间、CPU 或 GPU 资源、失败任务重试、环境维护和人工检查都没有完全体现在模型账单里。

更准确的结论是：在一个已经具备自动评估能力的优化环境中，LLM 可以用几十美元级别的语言推理成本，换取若干轮算法探索，并可能找到人类手工调参没有覆盖的组合。

这和让模型从零写出一个高性能优化器不是一回事。种子程序、目标函数、约束检查、运行环境和结果保存机制仍然需要人来准备。LLM 的价值主要集中在“提出下一步改什么”，而不是替代整个工程系统。

| 对比维度 | 传统手工优化 | 普通 LLM 代码生成 | LLM 引导程序进化 | |---|---|---|---| | 主要搜索对象 | 参数、候选解和人工设计策略 | 一次性代码实现 | 求解器结构与算法策略 | | 反馈来源 | 人工分析和实验结果 | 测试用例或人工审查 | 独立验证器与历史排行榜 | | 是否支持长期迭代 | 依赖工程师持续介入 | 通常较弱 | 原生支持多轮进化 | | 对失败的处理 | 人工定位原因 | 重新提示模型 | 自动丢弃并记录失败版本 | | 最适合的任务 | 目标清晰、经验成熟的问题 | 常规开发和重构 | 可执行、可验证、可量化优化的问题 | | 主要风险 | 搜索范围受人类经验限制 | 生成幻觉和重复错误 | 评估器漏洞、过拟合和计算成本 |

它与 AlphaEvolve、OpenEvolve 的关系是什么

AlphaEvolve 是一种由 LLM 生成、评估和筛选算法程序的进化式系统；这次圆打包实验采用的是同一类总体范式，但不应直接说它就是 AlphaEvolve。

Google 公开介绍的 AlphaEvolve 更像是一个面向大规模算法发现的完整系统：模型负责生成候选实现，自动化评估器提供可验证反馈，进化框架持续保留更好的版本。相关案例覆盖调度、底层代码优化和数学算法等场景。

OpenEvolve 则是更偏开放实现的程序进化框架，通常包含程序采样器、程序数据库、评估池和控制器，允许对完整代码文件进行多目标进化。它体现的是工程化基础设施路线：如果把 LLM 看作提出方案的研究员，那么 OpenEvolve 一类框架就是实验室的样本管理、评估和并行运行系统。

这次 Packomania 实验的意义，在于它展示了一个相对轻量的闭环也能产生可验证结果。它没有试图用一个巨型系统覆盖所有算法问题，而是从一个明确的基准、一个可运行的种子求解器和一个独立评分器出发，证明 LLM 可以在具体优化任务上参与算法层面的搜索。

| 系统或路线 | 核心特点 | 与本次实验的共同点 | 主要差异 | |---|---|---|---| | Packomania 程序进化实验 | 面向圆打包求解器的定向改进 | LLM 提议、程序执行、验证器筛选 | 任务范围较窄，实验规模较小 | | AlphaEvolve | 面向算法发现和工程优化的完整系统 | 使用 LLM 与自动评估闭环 | 更强调大规模基础设施和多领域应用 | | OpenEvolve | 可扩展的开放式程序进化框架 | 支持程序数据库和候选版本进化 | 更偏通用工具链，需要用户配置任务 | | 传统进化算法 | 对参数或候选解进行变异和选择 | 都依赖适应度评估 | 通常不直接改写求解器逻辑 |

最关键的设计：独立验证器，而不是模型自评

独立验证器是这类系统能否可信的核心组件。

如果由 LLM 自己判断代码是否更好，系统很容易陷入自我确认：模型声称算法更高效，实际上输出了非法布局；或者它修改了评分逻辑，让结果看起来更高。把候选程序交给模型之外的执行器，才能把语言层面的解释和真实性能分开。

一个合格的验证器至少需要检查以下内容：

• 所有圆是否位于规定区域内；
• 任意两个圆之间是否满足不相交约束；
• 目标函数是否按照固定规则计算；
• 运行过程是否超时、崩溃或产生非法数值；
• 随机种子、评估次数和资源限制是否一致；
• 候选程序是否修改了评估器或读取了不应访问的外部信息。

最后一项经常被低估。只要模型能编辑完整程序，就必须考虑数据泄漏、评分函数篡改和利用评估漏洞等问题。程序进化不是把代码扔进沙盒里跑完就结束，评估环境本身也需要具备隔离、可审计和可复现能力。

也许比“刷新纪录”更值得讨论的是停滞检测

停滞检测是这项工作中最值得继续研究的部分之一。

程序进化不可能无限有效。早期迭代可能很快找到明显改进，之后则会进入平台期：模型不断调整局部参数，却没有真正改变搜索行为；或者多个候选版本只是换了变量名、重排了函数顺序，实际性能几乎不变。

如果系统没有停滞检测，就会继续消耗模型调用和评估算力。作者提到的 plateau-detection stopping rule，目标就是识别一段时间内的收益是否已经趋近于零，并决定是否终止当前进化过程。

一个实用的停滞检测器可以综合观察：

• 最近若干轮的最佳成绩增量；
• 新候选与历史版本的结构差异；
• 候选程序实际改变了哪些搜索阶段；
• 不同随机种子下的平均表现，而非单次最好成绩；
• 单位成本带来的收益是否仍在下降。

但停滞判断并不简单。连续 10 轮没有提升，可能意味着算法确实触顶，也可能意味着系统正处于一次大变异之后的过渡期。过早停止会错过突破，过晚停止则会浪费资源。更稳妥的做法是把停滞检测和多样性控制结合起来：当局部微调无效时，暂时引入不同搜索范式、不同初始化策略或不同程序分支，而不是机械增加迭代次数。

这套方法的边界同样清楚

LLM 引导程序进化最适合有可靠自动评分器的任务，而不是所有开放式研究问题。

它的第一道门槛是可验证性。圆打包可以通过几何约束和数值目标直接评分，编译器优化可以用运行时间和正确性测试评分，调度问题可以用吞吐量、延迟或成本评分。但在审美、战略规划和复杂科学假设等任务中，评分器往往不稳定，模型很容易围绕代理指标投机。

第二道门槛是评估成本。如果每个候选程序都要运行数小时，即使模型调用价格很低，整个搜索过程也可能变得昂贵。系统需要并行评估、早停、低成本预筛选和分层测试，否则外层的智能建议会被内层的算力瓶颈拖住。

第三道门槛是泛化。刷新 N=101 到 114 的基准成绩，并不自动证明求解器在其他 N、其他边界形状或不同随机种子上同样优秀。一个程序可能专门适应当前排行榜的结构，甚至记住了特定实例的模式。真正有价值的验证，应当包含未参与进化的 N 值、不同初始化和独立实现的交叉测试。

第四道门槛是可解释性。模型提出的修改如果只是不断堆叠启发式规则，最终程序可能变得难以维护。研究者需要保存每轮 diff、运行日志、评估分布和失败原因，才能判断最后的提升来自有意义的算法变化，还是偶然的随机波动。

对开发者来说，最值得复用的不是圆，而是闭环

这次实验给普通开发者的启发，不是立刻让 LLM 去解决某个复杂数学问题，而是先寻找自己工作中可以被自动评分的环节。

如果你在做编译器、数据库、路径规划、推荐排序或量化策略，可以把问题拆成以下结构：

1. 准备一个能工作的基线程序，不要求它一开始就最优；
2. 把性能指标、正确性约束和资源限制写成独立评估器；
3. 让 LLM 修改算法逻辑，而不是只润色代码；
4. 保存所有候选版本和实验结果，避免重复探索；
5. 对成功改动进行多数据集、多随机种子复测；
6. 在收益停滞或出现异常时自动暂停，由人检查方向。

最重要的原则是先建评估器，再接入模型。没有可靠评分器，LLM 只能不断生成意见；有了评分器，模型才真正拥有可用于学习的反馈信号。

这也意味着，未来的高价值开发工具可能不只是代码补全器，而是能够管理长期实验的算法代理：它知道当前最好的版本是什么，知道哪些想法已经失败，知道下一轮应该探索哪个方向，也知道什么时候继续运行已经不划算。

判断：LLM 正从写代码走向改写搜索过程

这次圆打包结果并没有证明 LLM 已经取代专业优化算法，但它证明了一件更具体、也更有现实意义的事：当目标可执行、反馈可量化、失败可自动淘汰时，LLM 可以成为算法设计循环中的有效搜索算子。

2.4% 至 5.4% 的改进幅度、15 轮迭代和 27.72 美元的模型成本，足以让这项实验值得关注；但它的真正价值不在于一张排行榜，而在于把模型能力从一次性生成，推进到了长期程序进化。

短期看，这类系统会优先进入优化器调参、编译器内核、数据库执行计划、调度系统和机器人控制等拥有明确指标的领域。中期看，竞争重点将从谁能生成更多代码，转向谁能设计更好的评估器、记忆机制、分支管理和停滞检测策略。

我的判断是：LLM 不会直接替代优化算法，但会越来越多地参与设计优化算法的过程。对开发者而言，真正应该学习的不是如何让模型写出更长的代码，而是如何把一个模糊的性能目标，改造成一个模型无法轻易作弊、程序能够自动验证、结果可以持续积累的实验闭环。

参考来源

• Reddit：LLM-guided program evolution improves 10 best-known circle-packing solutions：项目作者对实验结果、迭代次数和模型成本的原始说明。
• GitHub：discovery-loop：实验代码、进化流程实现与提交的圆打包解。
• 知乎：爱可可 AI 前沿推介：对 LLM 驱动进化和分层自适应优化思路的中文整理。
• 知乎：Agentic Design Patterns 学习与适应章节：对 OpenEvolve、程序进化和长期智能体闭环的背景介绍。