FrugalEvo：AI 如何按成本进化

本文基于论文 FrugalEvo: Towards Cost-Aware LLM-Guided Program Evolution 的摘要与公开信息整理，结论不代表论文之外的实验复现。

先说结论

很多"让大模型自己写代码、自己试错、自己优化"的系统，默认目标是：在固定迭代次数内把分数做高。FrugalEvo 反过来问了一个更接近生产的问题：每花一美元，系统到底带来了多少有效改进？

论文提出一个面向成本的 LLM 程序演化框架。它让更强、但更昂贵的模型负责探索策略，让更便宜的模型负责把策略写成代码并持续修正，同时通过缓存前缀减少重复输入成本。作者还提出 BA-AUC（Budget-Aware Area Under the Curve），用"累计成本---当前最好成绩"曲线下面积衡量固定预算内的实际收益。

公开摘要报告：在 10 个数学和系统优化任务上，FrugalEvo 的最终质量达到或超过多个基线，并在其中 9 个任务取得更高的 BA-AUC；在圆打包任务上，论文报告的成本分别约为 1.68 美元和 0.55 美元，而摘要中列出的多智能体基线平均约 50 美元。上述数字是论文摘要中的作者报告，使用时应区分"论文结果"和"独立复现"。

为什么"固定迭代次数"不够

假设两个系统都运行 100 轮：

系统 A 前 10 轮就找到好方案，后面 90 轮几乎没有改进；
系统 B 前 80 轮表现普通，但最后找到一个更高分方案。

如果只看最终分数，系统 B 可能胜出。但在真实工程里，预算不是无限的，用户可能在第 20 轮就必须停止。此时更重要的问题是：在预算逐渐消耗的过程中，系统有没有持续地产生价值？

这就是 BA-AUC 的直觉：把每个成本点的"当前最好成绩"画出来，再计算曲线下面积。一个系统越早取得稳定改进，单位成本的收益就越高。

FrugalEvo 的三个关键设计

1. 让不同价格的模型做不同工作

探索策略和实现策略不是同一件事。强模型适合提出搜索方向、发现可能的算法结构；便宜模型适合反复改代码、跑评估、修复局部错误。

这种分工不是简单地"永远用便宜模型"，而是把昂贵模型放在更值得花钱的决策点，把高频循环交给成本较低的模型。它对应一个通用工程原则：高价模型负责降低搜索空间，低价模型负责扩大试验次数。

2. 把缓存当成算法设计的一部分

LLM 程序演化通常会重复发送大量相同的上下文：任务说明、评估器、历史代码和提示模板。如果每一次都从头计费，迭代次数越多，重复成本越高。

FrugalEvo 的做法是让 harness 和 prompt 尽量共享前缀，提升缓存复用率。这里的重点不是某个 API 参数，而是把"上下文如何组织"当成系统架构问题，而不是最后才优化的请求细节。

3. 用预算曲线而不是单点成绩评估

最终分数仍然重要，但它不能单独代表系统是否实用。BA-AUC 把"何时取得改进"纳入指标，适合比较不同模型组合、不同提示策略和不同搜索调度。

对工程团队来说，这个指标也可以改写成更熟悉的版本：

text 复制代码

单位成本收益 = 在预算 B 内的累计质量收益 / B

关键是提前固定预算口径、评估次数、失败重试规则和计费方式，否则不同实验之间不能直接比较。

对普通 AI 工程项目有什么启发

第一，不要只记录最后一次成功。应该记录每次调用的模型、输入输出 Token、延迟、失败次数、评估分数和累计成本。没有这些数据，就无法知道"更聪明"到底是不是"更划算"。

第二，把任务拆成"探索"和"执行"。探索阶段可以调用更强模型，执行阶段使用更低成本模型；但要保留升级条件，例如连续若干轮没有改进时，才把问题交回强模型。

第三，先做小预算实验。FrugalEvo 的价值不在于证明所有任务都应该使用多模型，而在于提供了一种可测量的比较方式。对于自己的代码生成、测试修复或参数搜索任务，可以先设置一个固定金额，比较不同调度策略在同一预算内的结果。

第四，把缓存命中率纳入工程指标。重复上下文、过长的历史记录和不稳定的提示前缀，都会让成本模型失真。提示模板的稳定性和缓存复用率，应该像延迟一样被监控。

这项工作的边界

论文摘要覆盖的是数学、系统和算法优化任务，不能直接推导出它在所有软件开发场景都有效。尤其是开放式产品需求、主观写作和需要人工判断的任务，评分函数本身就不稳定。

另外，论文摘要中的成本数字是特定模型、任务和实验设置下的报告值。模型价格、缓存规则、工具调用次数和评估器都会改变结果。因此，实际落地时不能直接复制"0.55 美元"这样的数字，而要用自己的任务重新测量。

给开发者的落地清单

为每次模型调用记录成本、延迟、Token 和结果分数。
把探索模型和执行模型分开配置。
给每个任务设定固定预算和停止条件。
让稳定的任务前缀尽量复用，减少无效上下文。
同时看最终质量和预算曲线，不只看最后一次输出。
对失败重试、人工修改和评估器误差单独记账。

结语

FrugalEvo 最值得借鉴的地方，不是"再加一个模型"，而是改变了优化目标：从"模型能不能继续试"变成"每一单位成本能不能带来可验证的改进"。

当 AI 系统开始承担越来越多的搜索、编码和实验工作时，成本控制不应只是财务报表里的事。它应该进入算法、提示、缓存和评估指标的设计里。

来源

Chen et al., "FrugalEvo: Towards Cost-Aware LLM-Guided Program Evolution", arXiv:2610.03675v1, 2026-10-02: https://arxiv.org/abs/2610.03675v1