我看到一篇 arXiv 論文〈Towards Cost-Aware LLM-Guided Program Evolution〉，它談的表面上是如何用不同價格的模型來做程式演化，實際上則提出一個更值得注意的問題：當 LLM 被放進搜尋與最佳化迴圈後，我們究竟要最佳化什麼？

FrugalEvo 的核心設計很直觀，卻有相當強的系統含義。較強但較昂貴的模型負責探索策略，提出可能的修改方向；較便宜的模型負責實作、測試與反覆改進。這不是單純把模型換成便宜版本，而是把探索與利用拆成不同角色，讓昂貴的推理能力集中在真正影響搜尋方向的決策上。論文也透過 prompt 與 harness 的共用前綴提高 cache reuse，進一步壓低每次迭代的實際成本。換句話說，成本控制不只發生在模型選擇，也發生在整個推理管線的資料流設計。

我認為最重要的貢獻，是 BA-AUC 這個評估觀點。傳統程式演化實驗常報告最後找到的分數，但這個數字忽略了兩件事：到達該分數花了多少錢，以及在搜尋早期是否已經取得有用結果。BA-AUC 以固定成本內最佳分數隨累計成本的曲線面積衡量效益，因此同時看最終品質與改善速度。對需要反覆呼叫模型的代理系統來說，這比只比較最後一個 checkpoint 更接近真實使用情境。

結果也很能說明問題。在十個數學與系統最佳化任務中，FrugalEvo 的最終品質可匹敵或超過 OpenEvolve、ShinkaEvolve、AdaEvolve 與 EvoX，並且有九個任務的 BA-AUC 更好。以 circle packing 為例，GPT-5.6 Terra 搭配 Luna 的成本是 1.68 美元，GLM-5.3 搭配 Flash 則是 0.55 美元，而多代理基線平均約 50 美元。這裡真正值得比較的不是某個模型是否在單次回答中更聰明，而是不同能力與價格組合如何改變整條搜尋軌跡。

從模型比較的角度看，這也提醒我們不要把代理架構當成模型排行榜的附屬品。強模型可以減少錯誤的探索方向，但若每個低價值迭代都由它執行，預算會快速消耗；便宜模型雖然單步能力較弱，卻可能在明確的測試回饋下高頻率累積局部改進。最佳配置因此取決於任務的回饋噪音、修改難度、快取命中率與預算限制，而不是固定的模型大小排序。

我會把這篇論文看成一個評估範式的轉向：LLM 最佳化系統不應只問最後分數是多少，也要問每一美元帶來多少進展、多久能達到可用品質，以及成本曲線是否穩定。未來若只用終點分數比較代理，很可能把昂貴但低效率的搜尋誤判成優秀方法。把模型分工與成本曲線一起納入目標，才有機會讓程式演化從展示能力，走向可部署的工程系統。