ml-evolve：用于 ML 优化的多智能体自进化系统

通用的智能体算法搜索框架（AlphaEvolve、OpenEvolve、AK 风格的 AutoResearch）刷编程题和浅层 benchmark 很行，但一指向真实 ML 训练 pipeline 就开始出现问题。因为 ML 有自己的一套成本结构和失败模式，这些框架根本没考虑过。

ml-evolve：是一个专为 ML 垂直领域打造的多智能体自进化系统：每个智能体角色对应一个在生产中实实在在踩过的坑，自进化循环也按 ML 训练的经济学逻辑重新设计。这篇文章讲这些设计选择，以及它们比现有方案好在哪里。

为什么 ML 需要自己的智能体系统

现在的智能体算法搜索系统基本都是为代码搜索设计的。候选是一段代码评估器是单元测试运行器，一轮几秒钟。变异、打分、重复。

但是ML 并不是这样：

• 候选是一次训练运行，10 分钟到几小时不等。
• 评估器要在真实数据上、用真实划分来跑模型，还得防泄漏、防分布偏移、防噪声把微弱信号淹没。
• 真正能带来变化的轴不是"对函数做语法级编辑"——而是架构、训练方案、特征 pipeline、采样策略，每一项都是研究级别的决策。
• 有用的已有成果不止在 arXiv 上，更多藏在工业界团队已经上线过的技术博客里。
• 计算要真的钱；奥买单，一次粗糙的搜索可能烧掉全部预算却拿不出一个能上线的模型。

在这种条件下，通用循环很快就会出现问题，比如：同一个 LLM 三次能写出排序函数，但一百次迭代也未必能有效改进一个推荐系统架构。这不是没想法而是围在它外面的循环缺乏结构来公平检验那些想法。

四个痛点，以及对应的智能体角色

我们反过来想先列那些搞死智能体 ML 的失败模式，再设计最少量的智能体拓扑去解决它们。

1、一个 LLM 干不了架构推理又干数值优化

让 LLM同时给模型和好参数，它两样都干不好：

• 七维连续空间不是它的菜，TPE 和贝叶斯优化稳稳压它一头。
• 它会锚定在前面几轮的数值上，搜索坍缩成局部微调，就算架构明显卡住了也跳不出来。

所以拆成两个智能体，在不同层面干活。

• 变异智能体管架构/算法代码本身——它改候选程序的 EVOLVE 块。不选数值，只把数值参数化。
• 参数搜索智能体在冻结的架构上跑 Optuna TPE——试点数据上 12 次试验、5 次热启动。这是标准贝叶斯 HPO不需要 LLM 。

这样每层用自己擅长的工具，变异智能体做结构推理，参数搜索智能体做数值搜索。一个架构在最优化参数下还不行，那说明是架构的问题，不是"我们没调好"。信号质量上去了，计算浪费下来了。

2、智能体搜索会坍缩成浅层微调

如果没人管的话LLM 驱动的循环会一轮接一轮地在刚奏效的方案上修修补补。比如”Embedding 维度 64→128→96→80。排行榜上站了一排几乎一模一样的模型，这是是当一个智能体要在"这轮出活"和"试试有风险的东西"之间平衡时短期决策的结果。

所以需要一个独立的计划智能体，手里握着对搜索广度的结构性权力。

• 分支提前声明写清楚假设，计划智能体只能槽位里操作。它可以把一个槽位的具体方向翻新（"温度试过了，试试 hard negatives"），但不能把两个槽位合并成一个思路。
• 计划智能体定期被唤醒（每 K 轮），读完整排行榜、重写研究计划。它不是第 0 轮一次性出场然后慢慢沦为摆设。
• 计划智能体允许上网搜。工业 ML 里最有用的经验通常不在 arXiv 上——在已经上线过类似系统的团队博客里。它可以把"Meta 的双塔笔记说 BM25 hard negatives 加课程学习有用"直接拉进分支假设。
• 每条分支有终止条件。卡住的分支不能悄悄耗掉所有预算，它的槽位会被回收。

这样15 轮跑下来，产出不是一个模型的 15 个小变体，而是每条分支两到三个真正不同的架构，各自调到局部最优。广度不再是被贪心优化剩下来的边角料，而是系统的第一选择

3、训练成本比别的环节高 100-10000 倍

这是通用代码搜索框架完全忽略的一个问题——它们的候选毫秒级就能编译。在 ML 里这是唯一决定搜索循环能不能承受的问题。

一个嵌在自进化循环里的三阶段训练门控。

一个 3 节点 × 15 迭代 × 12 试验的任务，在 40 分钟一轮的训练上，如果每轮都跑全量，一个节点就是 360 GPU 小时。分阶段后内循环只用 10% 试点数据，一个节点变成约 36 小时加少量完整晋升。探索深度一样计算省了 10 倍。

门控不只为效率。final 阶段跟选型完全隔离，这样也堵住了报告泄漏——一种无声的破坏性偏差，保留评估集慢慢变成选择信号的一部分。临时搭的智能体循环上线一周内准会踩这个坑。所以这就需要控制器不把 final 分数拿来做父代选择。

4、信号一有噪声排行榜就撒谎

就算分了阶段，10% 试点数据的排行榜也比全量评估噪声大得多。LLM 会追第十名的假象，拿噪声当信号出方案。

这就需要一组散布在智能体角色和控制器里的小规矩。

• 参数搜索智能体用带显式 tpe_startup_trials 热启动的 TPE，防止早期轮次锚定在一颗老鼠屎上。
• 控制器定期做晋升——每 K 轮，search 阶段的前 K 名用全量数据重评。持续领先者活下来，噪声领先者露馅。
• 计划智能体不只读原始分数，还看分支健康度（多久没进步了、试验分散度如何）。它能区分"这轮噪声大了点"和"这个分支结构上已经死了"。
• 排行榜显式标出按阶段的分数，选型时始终知道分数从哪个阶段来的。试点分数不会跟完整分数被当成同一个东西比较。

这些不是多高深的技术，是有经验的 ML 工程师拿痛换来的教训，然后写进自己的脚本里。

智能体和阶段怎么配合

四个痛点的答案拼在一起就得到了系统拓扑：

                            ┌─────────────────────────────────────┐  
                           │  PLAN AGENT  (算法广度)             │  
                           │  读排行榜 + 分支健康度              │  
                           │  + 可选的网络搜索; 每个节点          │  
                           │  分配一条假设                       │  
                           └──────────────┬──────────────────────┘  
                                          │  
                                          ▼  
                           ┌─────────────────────────────────────┐  
                           │  MUTATION AGENT  (架构)             │  
                           │  重写 EVOLVE 块; 参数化数值旋钮     │  
                           │  但不选值                           │  
                           └──────────────┬──────────────────────┘  
                                          │ 冻结架构  
                                          ▼  
                           ┌─────────────────────────────────────┐  
                           │  PARAM-SEARCH AGENT  (数值)         │  
                           │  Optuna TPE, N 次试验               │  
                           │  在 PILOT (10% 数据) 上跑           │  
                           └──────────────┬──────────────────────┘  
                                          │ 最佳分数  
                                          ▼  
                           ┌─────────────────────────────────────┐  
                           │  PROMOTION (每 K 轮)                │  
                           │  top-K 试点 → 全量数据              │  
                           │  噪声过滤, 泄漏屏障                 │  
                           └──────────────┬──────────────────────┘  
                                          │ 更新排行榜  
                                           └─► 回 PLAN AGENT

每个智能体做自己擅长的事，每个阶段花该花的钱，每轮循环回到上一层闭合。这就是"自进化"的意思：这一轮的排行榜变成计划智能体下一轮的输入，计划智能体对广度的掌控保证搜索不坍缩。

与现有自进化算法对比

最接近的参考系是 AlphaEvolve、OpenEvolve 和更广泛的 AK 风格 AutoResearch 智能体。它们共享一个骨架——提出、评估、学习、重复——都靠排行榜驱动的自我改进信号。我们的差异如下：

看最右列。每一行都是一个场景：用通用智能体搜索循环跑真实 ML 训练系统时，要么烧计算、要么产出浅层结果、要么悄悄污染评估。 我们不是换了个隐喻——是对具体生产故障的针对性回应。

AlphaEvolve、OpenEvolve 和 AutoResearch 主要优化研究广度和能力天花板。它们之所以令人印象深刻，正是因为它们不受约束。ml-evolve 优化的是生产级 ML 迭代效率——可重复、可审计、可负担、抗泄漏。不同目标，互补设计。

双塔检索优化案例

场景：双塔检索 pipeline。已知基线：

TwoTower 是新基线，目标是把 Recall@50 再推高。声明了三个结构上不同的假设节点：in-batch 负样本调优、基于 ANN 的 hard negative 挖掘、多兴趣用户塔（MIND / ComiRec 风格）。每条有终止条件。

第 6 轮（共 15 轮）：

 [Stage]  search  (10% data pilot)

[Branch] hard_negative_mining  
  Plan agent     → "Round 5 converged at temperature 0.05.  
                    Meta two-tower notes recommend BM25-retrieved  
                    hard negatives + curriculum schedule.  
                    Direction: add hard_neg_ratio and pool_size."  
  Mutation agent → edits EVOLVE block, parameterizes the two knobs.  
  Param-search   → 12 Optuna TPE trials, 5 startup.  
                   best → Recall@50 = 0.1112 (pilot)  
                   cost: 12 × 4 min = 48 min on one GPU

[Branch] in_batch_neg_tuning           best → 0.1071  
[Branch] multi_interest_user_tower     best → 0.1058  (2/3 kill criterion)

[Promotion] every=5 → round-5 top-1 promoted; full-stage check  
            → Recall@50 = 0.1098 (consistent with pilot — not noise)

[Replan]   replan_every=5 fires → multi_interest_user_tower flagged  
            for hypothesis refresh next round.

这一轮暴露了系统设计的几个要点：

• 解耦搜索（痛点 1）：计划智能体从不选温度值，那是 Optuna 的事。
• 广度控制（痛点 2）：三个结构不同的分支并行推进，一条快被回收了。
• 多阶段训练（痛点 3）：试点 48 分钟 vs 全量约 8 小时——省 90%，探索深度不减。
• 噪声过滤（痛点 4）：晋升阶段用全量数据验证试点领先者，不会让噪声进入后续计划。

运行完的产物：leaderboard.md（每分支最优 + 历史）、research_plan.md（当前计划智能体指令）、param_trials/*.json（每次 Optuna 试验）、report.md（最终报告，不参与选型）。两个月后有人问为什么选了 hard negative 而不是多兴趣，答案在这几个文件里——不在某个 Slack 讨论串里。

什么时候该用

适合的场景：

• 单标量目标（NDCG@K、Recall@K、IC、AUC、利润……）
• 训练任务够长，分阶段搜索能自己回本（每个候选 ≳ 10 分钟）
• 有多个真正不同的研究方向值得并行探索
• 需要下个季度还能审计"试过什么、为什么"

不适合：

• 纯超参数网格搜索——Optuna 够了
• 在线 / 人在环评估——这是个离线循环
• 训练太便宜，分阶段增加的 overhead 比节省还多（工业界很少见）

总结

智能体 ML 领域正向更开放、能力更强的系统演进，这对研究来说很对。但有一个不那么常被讨论的平行问题：怎么设计一个多智能体系统，让它在本季度、在真实 ML 训练 pipeline 上就能把成本挣回来？

这不是模型规模的问题，是智能体设计的问题：按角色擅长的决策来分角色，按可负担的计算来分时间尺度，把广度和深度拆开免得它们互相干扰。

如果你的算法搜索循环还没挣回算力钱答案可能不是换更大的 LLM，而是把智能体系统设计得更好。

项目地址：

https://github.com/roylist/ml-evolve

by William Austin