让 AI 自己造 AI，怎么才能又快又省？
你可能见过 AI 写代码、做数学题，但你有没有想过：如果让 AI 从头到尾自己设计并训练一个新的 AI 模型，它会怎么做？是像无头苍蝇一样乱试，还是有章法地搜索？更关键的是，怎么让它在有限的 GPU 和预算下，做出最好的结果？
在「AI 自动构建 AI 模型」这件事上，我们如何在有限的算力与时间预算下，同时拿到更高的任务成功率和更低的推理成本？最近的一项研究 AIBuildAI-2.5 给出了一套相当务实的答案：它没有盲目堆大模型，而是从搜索策略、资源调度、模型选择三个环节同时下手，把自主建模的整体效率拉到了新的高度 [1]。
一、AI 造 AI 的难处：不是不会，是太费钱
先从一个大家都熟悉的痛点说起：调模型。
做过机器学习的人都知道，调参、换模型结构、试不同的数据处理方式，本质上是在一个巨大的可能性空间里摸索。你写一个训练脚本，跑几小时，结果不行，改改再跑——大部分时间和算力，都花在了验证「这个思路不行」上。人来做这件事，靠的是经验和直觉筛掉明显不靠谱的方案；如果让 AI 来做，它怎么避免把宝贵的 GPU 时间浪费在烂方案上？
现在主流的思路，是把「AI 造 AI」建模成一个**代码树搜索（code tree search）**问题：树的每个节点是一个完整的可运行训练程序，从父节点生成子节点就相当于「在现有方案基础上改一改」，搜索的目标是找到性能最好的叶子节点 [1]。
这个方向最近几年进步很快，AI agent 做模型的水平已经逐渐接近有经验的工程师，甚至能在 Kaggle 级别的任务上拿到奖牌 [6][8]。但问题也很明显：太费钱了。
为什么费钱？因为传统的搜索方法，比如蒙特卡洛树搜索（Monte Carlo Tree Search, MCTS，一种通过随机采样和回溯来评估节点价值的搜索算法），是「跑了再评」——得真的把代码跑起来拿到结果，才知道这个节点好不好。可现实预算下，能跑的节点数量非常有限，靠少数几个带噪声的实测结果来指导搜索，效率很低 [1]。
除此之外还有两个隐形的浪费：一是训练任务调度得不好，GPU 经常闲着摸鱼；二是不管什么活都调用最贵的大模型，明明写个环境配置不需要最强模型级别的能力，也花了顶级模型的钱 [1]。
AIBuildAI-2.5 就是冲着这三个浪费来的——它用三层设计，把搜索效率、硬件利用率、推理成本同时优化了一遍 [1]。
二、第一个升级：先「评」再跑，比跑了再评省算力
第一个核心升级，是把「跑了再评」改成「先评再跑」。
你可以想象一个选秀比赛：以前的做法是每个选手都上台表演一遍（跑一遍训练），评委再打分；现在呢，先让两个预审评委看简历和彩排片段，凭经验预判谁最有希望，只让最有潜力的选手上台。这样同样的时间里，你能筛掉更多烂方案，把舞台留给真正值得试的人。
在 AIBuildAI-2.5 里，这两个预审评委就是 judge（评判代理） 和 selector（选择代理），它们共同构成了 LLM 引导的树搜索（LLM-guided tree search） 的核心 [1]。
具体分工是这样的：judge 负责局部打分——对每一个候选的修改方案，从三个维度打 0 到 5 分：预期能带来多大提升、方案有没有父节点的实测结果做依据、单步修改的可行性高不高。如果方案看起来像是在「奖励作弊」（比如直接改评估指标代码），直接打 0 分 [1]。
selector 则负责全局排序——它不看单个节点，而是结合整棵树的状态、还剩多少算力预算，把所有候选排个序。它会考虑多样性（别都挤在一个分支上）、避开死胡同分支、去掉重复的方案，还会随着预算越来越少，从「多探索新方向」逐渐转向「深挖最有希望的方向」[1]。
为什么这比传统蒙特卡洛树搜索更有效？因为在预算有限、能跑的节点很少的时候，蒙特卡洛那种靠已执行结果回溯打分的方式，样本太少、噪声太大，选出来的下一个节点未必靠谱。而 LLM 的先验判断相当于把「人类工程师的经验」注入了搜索过程——虽然不是 100% 准，但比瞎蒙强太多了 [1]。
当然，实际情况比这个比喻更复杂：judge 和 selector 本身也是 LLM，它们的调用也有成本，而且它们的判断也会出错。论文里并没有单独披露这两个模块自身的成本占比，这也是一个有待验证的点 [1]。
三、第二个升级：让 GPU 不摸鱼——资源感知调度
选好了要跑的节点，下一个问题就是：什么时候跑？怎么跑才能让硬件不闲着？
你可以把 GPU 想象成餐厅后厨的灶台，训练任务就是一道道要炒的菜。如果灶台只有一个，那你只能一道一道炒；但如果有多个灶台、还有帮厨（CPU），怎么安排上菜顺序就很有讲究了——安排得好，灶台全程不熄火；安排不好，有的灶台空着等菜，有的灶台堆着做不完。
AIBuildAI-2.5 里的资源感知作业调度器（resource-aware job scheduler），就是那个管后厨出餐的领班 [1]。
它的逻辑说起来很朴素：启动下一个训练任务之前，先查一下当前 GPU 和 CPU 的占用率，如果已经超过阈值了，就等一等；等资源稳定下来，再判断能不能塞下一个任务。这样多个任务可以并行跑，又不会因为抢资源而互相拖慢 [1]。
你可能会觉得这听起来不就是个简单的队列管理吗？但在自主建模的场景里，它的作用比你想的大——因为每个训练任务的时长、资源消耗都不一样，有的训练跑几小时，有的跑几分钟就挂了。如果没有动态调度，要么保守地一个一个跑（资源浪费），要么一下全塞进去（显存不足或者互相抢占）。资源感知调度就是在中间找一个平衡点，把整体的墙钟时间（wall-clock time，即从任务开始到结束的实际经过时间）压下来 [1]。
不过论文也承认，目前这个调度器用的还是比较简单的启发式规则，还没用到更精细的策略，比如 GPU 分区（MIG）、或者考虑任务之间的干扰来搭配部署。换句话说，现在的领班只是「看锅下菜」，还没到「根据菜的火候搭配灶台」的水平 [1]。
四、第三个升级：大模型也搞「分级诊疗」——按角色路由模型
第三个升级，是关于 LLM 本身的成本控制。
不知道你有没有这种感觉：现在做 AI agent，动不动就上最强模型，好像不用顶级大模型就做不成事。但仔细想想，一个自主建模系统里有那么多不同的角色——有的负责想点子，有的负责写代码，有的负责排优先级，有的负责改 bug——这些活的难度能一样吗？
写复杂的训练代码，确实需要最强的模型；但排个任务优先级、写个环境配置文件、甚至做个格式检查，真的需要按顶级模型的价格付费吗？
AIBuildAI-2.5 的思路是「分级诊疗」：杂活给小模型，硬骨头给大模型。它实现了一套**基于智能体的模型路由（agent-based model routing）**系统，由一个 router agent 给每个角色的 agent 分配「够用的最便宜的模型」[1]。
这个路由不是静态写死的。它会根据同一个任务里历史节点的表现动态调整——如果某个角色用小模型老是出错，就给它升级成更大的模型；如果大模型做得很好但其实小模型也能搞定，就试着降级省成本。而且这些路由经验还会跨任务积累，做成「知识卡片」，下次遇到类似任务直接复用 [1]。
这和复合 AI 系统里的模型选择思路是一致的：之前的研究 LLMSelector 就发现，给复合系统里的每个模块选合适的模型，比全用同一个大模型效果更好，能带来 5% 到 70% 的性能提升 [7]。AIBuildAI-2.5 把这个思路用到了自主建模的多智能体系统里，结果是：相对全用 Claude Opus，路由系统把推理总成本降低了 56%，而且任务分数不仅没降，有的还更高了 [1]。
对，你没看错——成本砍半还多，性能反而可能更好。这是因为有时候小模型更听话、更少瞎发挥，反而适合做一些标准化的杂活；最强模型虽然聪明，但也更容易想太多、过度设计 [1]。
当然，这个结论目前只在 Claude 模型家族（Haiku / Sonnet / Opus）上验证过，换到其他模型池（比如开源模型）上是否同样有效，论文里没有说 [1]。
五、成绩单：在 Kaggle 级任务上拿到 73% 奖牌率意味着什么
说了这么多设计，效果到底怎么样？我们来看成绩单。
主要的测试基准是 MLE-Bench——一个包含 75 个 Kaggle 风格任务的基准，覆盖视觉、文本、时序、表格等各种数据类型，用真实 Kaggle 比赛的奖牌线来衡量水平 [1]。什么概念呢？Kaggle 比赛的奖牌一般是前 10% 左右拿金牌、前 20% 拿银牌、前 30% 拿铜牌——能拿到奖牌，意味着超过了绝大多数参赛的人类数据科学家。
AIBuildAI-2.5 在 MLE-Bench 上的奖牌率是 73.3%，排名第一，超过了包括 MARS、ML-Master、InternAgent、R&D-Agent、AIDE、AIRA-dojo、MLEvolve 在内的一众系统 [1]。作为对比，2025 年的 ML-Master 系统在同样基准上的奖牌率是 29.3% [8]。一年多时间，从不到三成到七成三，这个进步速度是相当快的。
再看另一个更偏研究型的基准 AIRS-Bench，一共 6 个任务，和基线系统 MLEvolve 比：分子预测任务上，QM9-Cv 的平均绝对误差降低了 20.8%，ZINC 降低了 29.8%；文本分类任务上，SICK-NLI 准确率提升了 5.1%，Yelp 提升了 1.4%；时序预测任务上，太阳能发电 MAE 降低 4.0%，维基流量 MASE 降低 3.6% [1]。可以看到，分子类任务的提升最显著，文本和时序类也有稳定但幅度小一些的进步。
而所有这些实验，都是在单张 A100 GPU、24 个 vCPU、256GB 内存、24 小时墙钟预算的条件下跑出来的 [1]。这个配置说不上多豪华——很多做研究的实验室单卡 A100 是标配。换句话说，只要你有一张 A100 和一天时间，这个系统就能帮你做出一个在 Kaggle 级任务上大概率能拿奖牌的模型。
不过这里也要诚实交代边界：这些结果都是在「给定数据集和任务描述」的设置下取得的，系统不需要自己找数据、定义问题；也没有测试多 GPU 分布式训练、超大规模数据集、或者需要查文献的原创研究任务 [1]。它更像一个「金牌调参工程师」，而不是「独立做研究的科学家」。
六、然后呢：离真正的「AI 自主搞科研」还有多远
AIBuildAI-2.5 把 AI 自主建模的效率往前推了一大步，但离真正的「AI 自己搞科研」还有不小的距离。我们可以从几个层面来看这个边界。
首先，当前的调度还是比较初级的。论文自己也承认，资源调度器目前只用了启发式规则，还没用到 GPU 分区、干扰感知的任务搭配这些更精细的策略 [1]。未来如果能把硬件感知做到代码生成层面——让写代码的 agent 自己就知道当前有多少显存、应该用多大 batch、要不要用混合精度——效率还能再上一个台阶。但这就要求 designer、coder、reviser 这些 agent 都变成「资源感知」的，目前还做不到 [1]。
其次，现在的系统本质上还是在「工程调优」的层面——给定一个任务定义和数据集，在已知的模型结构和训练技巧里搜索组合。它还不会提出全新的算法范式、不会自己定义新的研究问题。这就好比一个很厉害的工程师，能把已知方案优化到极致，但要从零开创一个新方向，还得靠人。
再者，从更广阔的 AI4AI（AI for AI）研究脉络来看，自主建模只是其中一个环节。AI 已经能帮我们做数学推理的错误分析 [5]、能帮机器人适应新的领域知识 [4]、甚至能引导用户修硬件 [3]，但这些能力目前还是分散的。什么时候 AI 能把「提出问题 → 设计方案 → 实现代码 → 训练调优 → 验证结论」整个科研闭环都串起来，那才是真正的「AI 自主搞科研」。
最后还有一个很实际的问题：成本。虽然路由已经把 LLM 推理成本砍了一半多，但如果要做更复杂的搜索、更大规模的任务，API 费用依然是一笔不小的开支。未来如果能把部分模块换成开源小模型，成本还能再降——但这又回到了前面说的，路由策略在其他模型池上的适用性还没验证 [1]。
如果你只记住一件事
AIBuildAI-2.5 告诉我们：AI 造 AI 的核心矛盾，早已不是「能不能做出来」，而是「能不能又快又省地做出来」，关键在于把最宝贵的 GPU 时间和大模型算力用在刀刃上。
参考文献
- AIBuildAI-2.5: Efficient Autonomous AI Model Development Through LLM-Guided Tree Search（arXiv、2026、全文精读）
- Evaluation of Multi-Turn Consistency in LLM Agents: Survival Analysis and Failure-Rationale Taxonomy（arXiv、2026、全文精读）
- Toward User-Mediated Self-Repair in Ubiquitous Robots Through Goal-Oriented Agentic AI（arXiv、2026、全文精读）
- ORDER: A Fictitious-World Benchmark for Domain-Adaptive Embodied AI（arXiv、2026、全文精读）
- Improving Mathematical Reasoning Capabilities in Large Language Models via Reasoning Process Error Classification（arXiv、2026、全文精读）
- ML Research Benchmark（arXiv (Cornell University)、2024、仅摘要）
- Optimizing Model Selection for Compound AI Systems（ArXiv.org、2025、仅摘要）
- ML-Master: Towards AI-for-AI via Integration of Exploration and Reasoning（ArXiv.org、2025、仅摘要）