谷歌Jeff Dean离职创业押注AI自动研究，清华系团队开源35B AI4AI模型

本工作由衔远科技与清华大学联合完成，其中衔远科技为唯一通讯单位。项目负责人杨峻麟（清华计算机系本科四年级）、姜澈（清华电子工程系博士三年级）， 两人现为衔远科技算法研究员 ，研究方向为 AI4AI 与 RSI，均师从上海人工智能实验室主任、清华大学惠妍讲席教授周伯文。唯一通讯作者张开颜，衔远科技 CTO、清华电子系博士，师从周伯文教授。 2026 年 8 月初，谷歌首席科学家 Jeff Dean 联合多位核心研究员集体离职，创立 Discovery Loop，目标直指递归自我改进（RSI）—— 让 AI 自己跑实验、评估结果、修正弱点，并持续迭代。 这不是孤立事件。过去一年，AI 已经开始进入 AI 研发流程本身。AlphaEvolve 用大模型和自动评测器搜索算法，部分结果已用在训练基础设施中；Darwin Gödel Machine 让 Coding Agent 修改自己的工具与工作流；SEAL 尝试让模型生成微调数据与更新指令；TTT-Discover 则在测试阶段继续更新模型。研究者开始把 AI 当作研发者，而不只是被研发的对象。这类工作通常被称作 AI for AI，或 Automated AI R&D。 RSI（Recursive Self-Improvement，递归自我改进）是其中最吸引人的方向。一个 Agent 会循环调用工具，或者在输出后做几次 Reflection，还不能算 RSI。真正棘手的是后半程：执行结果怎样被可靠验证，哪些经验值得留下，它们能否提高下一轮产生改进的能力，进而实现 AI 自我改进。 衔远科技和清华大学团队在综述《Self-Improving Agents in the Era of Experience》中把它概括为一个 Trace-to-Capability 问题：经验必须被捕获和整理，分配给正确的更新载体，经过验证，再以 Skill、Memory、Harness 或模型参数的形式进入未来行为。 在最新技术报告《Frontis-MA1: Training an AI4AI Model toward Recursive Self-Improvement》中，衔远科技与清华大学团队发布了 Frontis-MA1-35B 和 OpenMLE 开源套件，研究的是自我进化中一段具体链路：让执行反馈回到负责提出修改的模型中。Frontis-MA1 选择机器学习工程作为试验场，因为它同时满足两个条件：Agent 确实在构建另一个 AI 系统，结果又能通过真实运行和隐藏测试来验证。 先看这套方法有没有用。在 MLE-Bench Lite 上，35B 规模的 Frontis-MA1 配合标准 OpenMLE-Evo 得到 60.61% 的 Medal Average；加入 OpenMLE-Evo-Max 后，成绩升至 71.21%。GPT-5.6 Sol 与 2.8T 参数 Kimi K3 在同一组结果中为 72.73%。 图 1｜Frontis-MA1-35B + OpenMLE-Evo-Max 达到 71.21%。橙色实心部分是标准 OpenMLE-Evo 下的 60.61%，斜线部分是 Evo-Max 带来的增益。右图比较模型总参数量与成绩。 论文地址：https://arxiv.org/pdf/2607.28568 GitHub：https://github.com/FrontisAI/OpenRSI Hugging Face：https://huggingface.co/collections/FrontisAI/frontis-ma1 机器学习工程 Agent 究竟在做什么 给 Agent 一份训练数据、一套任务说明、一个评价指标和有限的 GPU 时间，它需要自己完成数据检查、验证集划分、特征处理、模型选择、训练与调参，最后提交预测结果。一次运行可能要花几分钟，也可能几小时。反馈通常只有分数、报错和日志。 代码跑通只是起点。有些错误很安静：验证集切分不当会给出过于乐观的分数，数据泄漏会让一个错误方案看起来很好，复杂模型也可能只对当前验证集有效。Agent 需要判断实验是否可信，然后决定继续改当前方案、回头修错、开一条新分支，还是把两条分支合在一起。 这也是机器学习工程比一般 Coding 任务更适合研究 AI4AI 的原因。它要求 Agent 处理代码，却不能靠单元测试判断全部结果；它还要理解数据和模型，并为每次训练付出真实算力成本。 我们把当前工作称为一次 Meta-Evolutionary Step。程序在执行反馈下演化，筛选后的轨迹用于训练提出修改的模型，更新后的模型再参与搜索。这里已经发生了 “改进者” 的更新，但任务、评测器和训练时机仍由人设定。完整 RSI 还需要多代闭环。 图 2｜左侧是 OpenMLE 的训练与搜索栈；右侧区分 Evolution、Self-Evolution、Meta-Evolution 和 RSI。本工作位于 Meta-Evolution 层。 OpenMLE 把一次实验拆成四种操作 OpenMLE 使用四种程序操作。Draft 从头生成方案；Improve 修改一个可运行方案；Debug 根据报错和日志修复程序；Crossover 把两个父方案中相容的部分重新组合。 这四种操作既用于后训练，也用于推理时的搜索。训练数据描述一次具体修改，搜索图也用同样的接口生成新节点。模型学到的动作因此可以直接放回搜索系统，而不是在训练阶段学一种任务、部署时再临时设计另一套工作流。 OpenMLE-Gym 负责提供可执行环境。按照论文的发布口径，Gym 共有 5,758 个任务：156 个精选锚点、3,362 个 Kaggle Dataset 任务和 2,240 个经过质量筛选的 Kaggle Competition 任务。任务覆盖八类数据模态，11.0% 涉及多模态数据。每个任务都把公开输入、隐藏答案、评价指标和执行脚本放进隔离沙箱，候选程序必须运行后才能得到分数。 图 3｜约 1.1 万个 Kaggle 竞赛经过许可、可执行性和语义质量检查，最终留下 2,240 个竞赛任务。右侧是统一后的任务目录。 这套环境的价值很朴素：训练、搜索和评测终于在讨论同一个结果。模型说自己的方案更好没有用，沙箱中的隐藏测试说了算。 OpenMLE-ERL 怎样从执行轨迹中学习 数据构建时，我们很快碰到一个问题：如果只保留每个任务的最终程序，模型看到的是答案，却看不到答案是怎样改出来的。 OpenMLE-ERL 保留了两类数据。并行路径收集 17,245 个完整 Draft；进化路径检查多步搜索轨迹，从高质量局部轨迹片段中筛选得到的 9,014 个进化步骤 。两部分合计 26,259 条 SFT 样本。 进化路径也没有把 “成功轨迹上的所有步骤” 一股脑标成正样本。一个早期修改只有被后续程序继承，并且最终通过质量门槛，才更可能进入训练集。这样能滤掉碰巧出现在高分轨迹中、实际没有贡献的操作。 强化学习还有一个麻烦：不同任务使用 AUC、RMSE 或自定义指标，方向和数值范围都不同。OpenMLE-ERL 根据当前 Rollout 的分数分布设置上下