给科研Agent加上“项目记忆”！人大高瓴开源AiScientist，23小时跑完74轮实验循环

2026-04-15 15:03:00

智猩猩AI整理

编辑：没方

从让大模型“会写代码”，到让它“会做研究”，AI Agent 的能力边界正在快速外扩。尤其在 AI for Research 方向，越来越多系统已经能够参与想法生成、文献分析、代码实现、实验辅助乃至科学写作等环节。

但如果把问题再往前推一步，会发现真正困难的部分其实还没有被完全解决。

因为现实中的机器学习研究工程，并不是某个孤立的推理步骤，也不是一次性的代码生成，而是一条持续数十小时、跨越论文理解、环境配置、资源获取、代码实现、实验执行、误差诊断与反复修复的完整任务链。系统不只要会“做某一步”，还要把每一步接起来，并在不断变化的项目状态上继续往前走。

针对这一设定，中国人民大学高瓴人工智能学院提出了一个名为AiScientist 的系统，尝试让 AI 真正具备长程研究工程能力。论文表明，AiScientist 在 MLE-Bench Lite 的 Detecting Insults 任务上可在 23 小时内自主完成74 轮实验循环，将 validation AUC 从 0.903 提升至0.982；在 PaperBench 上相对最佳匹配基线平均提升 10.54 分，并在 MLE-Bench Lite 上达到 81.82% Any Medal。更关键的是，论文的机制分析表明，长程研究工程要想真正跑起来，不仅要求系统在论文理解、实现、实验、诊断等局部任务上都具备足够强的能力，也要求它能够在跨阶段迭代中持续维护、继承并利用不断演化的项目状态。

论文标题：Toward Autonomous Long-Horizon Engineering for ML Research
论文链接：https://arxiv.org/pdf/2604.13018
代码链接：https://github.com/AweAI-Team/AiScientist

01 为什么“研究工程”会非常具有挑战性？

论文关注的是一个更具操作性的任务设定：long-horizon ML research engineering。

在这个设定下，系统的目标不是回答某个问题，也不是生成一段代码，而是从论文或研究目标出发，逐步构建、运行并改进一个可执行的机器学习系统。其难点至少来自四个方面。

（1）研究规格往往并不完整。

真实论文通常不会把所有工程细节写得面面俱到。实现时缺失的部分，需要系统自己补足决策。

（2） system setup 本身很重。

真正的研究工程不仅包含算法实现，还包括环境搭建、依赖处理、数据和模型资源获取等大量基础工作。

（3）有价值的反馈往往来得很晚。

很多问题不是在写代码时立即暴露，而是要等实验跑起来之后，才会以异常日志、指标偏差或结果不一致的形式显现。

（4）项目状态必须跨轮次保留。

每一轮实验都会产生日志、配置、结果和诊断，它们不是附属信息，而是下一轮决策的依据。一旦这些状态在多轮推进中丢失，系统就很难判断问题来源，更难进入真正有效的后续 refinement。

也正因如此，机器学习研究工程既是很多高难度 local problem 的串联，也是一个更难的 systems problem：系统不仅要在每个局部环节做出正确决策，还要让这些决策在长时间跨度中彼此衔接、相互校正，并依托持续积累的项目状态把后续迭代真正推下去。

02 AiScientist：

把“控制”与“状态”分开

AiScientist 的核心理念，可以概括为论文中的一句话：thin control over thick state。

这句话的意思是，顶层控制应当尽量轻量，而真正重要的项目状态则必须被稳定保留下来。

围绕这一点，AiScientist 做了两层关键设计。

第一层，是层级化 orchestration。

系统设置了顶层 Orchestrator 负责阶段级决策与流程推进，同时将论文理解、任务规划、代码实现、实验执行和诊断修复等工作交由不同角色处理。这样做的价值，不只是“多几个 agent”，而是让每个角色都在更合适的局部上下文中工作。

第二层，是 File-as-Bus。

这是 AiScientist 最核心的系统设计之一。它把共享工作区视为系统的“外部记忆”：论文分析、计划、实现代码、实验日志、错误记录和中间结果都会被持续写回文件系统，成为后续阶段可以重新读取和利用的 durable artifacts。

换句话说，AiScientist 并不依赖不断膨胀的对话历史来维持长期能力，而是把真正需要跨轮次传递的信息，沉淀成可追溯、可继承、可复用的项目状态。

论文还强调，这套设计让系统形成了一个 evidence-driven loop：不是简单地“再试一次”，而是在 implement、run、diagnose、patch、re-validate 的循环中，围绕真实实验反馈不断修正方向。

03 AiScientist 在评估中表现如何？

（1）在竞赛式实验改进任务中，系统可以持续把实验做下去

在 MLE-Bench Lite 的 Detecting Insults 任务上，AiScientist 在 23 小时内自主完成了74 轮实验循环，将 validation AUC 从 0.903 提升到了0.982，期间实现了18 次 best-so-far update。

这个结果的意义，不只在于数值提升，更在于它展示出了一条完整的研究工程路径：从理解任务、搭建环境、编写实现，到运行实验、诊断偏差、修补系统、再次验证，整个过程是持续迭代的，而不是一次性生成。

（2）在两个代表性 benchmark 上，AiScientist 都取得了稳定优势

在 PaperBench 上，AiScientist 相对最佳匹配基线平均提升约 10.54 分。这说明它并不只在个别样例上有效，而是在从论文复现到完整工程实现的高难度任务中，稳定拉开了与现有方法的差距。

在 MLE-Bench Lite 上，AiScientist 达到了 81.82% Any Medal。论文同时指出，这一成绩相比最佳匹配基线的平均提升达到11.37 个百分点，表明系统不仅能先把流程跑起来，还能在持续实验中不断逼近更好的结果。

这些结果也反过来说明，长程研究工程的难点并不只是把若干子任务分别完成。论文理解、环境配置、实现、实验和诊断这些环节单独看都已经足够困难，而真正拉开差距的是，系统能否让前一阶段的工作以有效状态的形式留到后一阶段继续发挥作用。

（3）论文给出了一个很重要的判断：更多交互并不自动等于更强能力

论文中有一句很值得注意的话：More interaction alone is not enough.

这背后的含义是，多做几轮尝试本身，并不会自动带来长程能力。只有当新的轮次建立在前面正确积累的项目状态之上时，额外交互才会真正转化为有效进步；否则，更多尝试反而可能意味着更高成本与更多噪声。

换句话说，长程研究工程的提升，不是靠“多跑几轮”自然涌现出来的，而是要让每一轮新增工作真正建立在前面阶段留下的正确依据之上。

04 为什么 File-as-Bus 值得重点关注？

论文的消融实验给出了一个非常直接的答案。

移除 File-as-Bus 后，AiScientist 在 PaperBench 上下降 6.41 分，在 MLE-Bench Lite 上 Any Medal 下降 31.82 个百分点。这说明，状态连续性并不是一个可有可无的辅助设计，而是长程研究工程里真正决定系统能否持续推进的关键机制之一。

更值得注意的是，这种退化并不是平均地落在所有阶段上。论文显示，去掉 File-as-Bus 后，系统未必立刻连基础可运行性都失去，但在更依赖后期优化和结果逼近的指标上，退化会更明显。

这意味着，File-as-Bus 的价值不只是帮助系统先搭一个能跑的脚手架，更重要的是让它在后续的诊断、修补、结果对齐与迭代优化中，把每一轮试错都建立在前一轮留下的有效证据之上。

从这个角度看，它解决的并不只是 executability，更是 fidelity。更进一步说，AiScientist 的关键也并不只是采用了 multi-agent 这种组织形式，而是让这种分工建立在可继承的项目状态之上。层级化 orchestration 负责把不同阶段拆给更合适的角色，而File-as-Bus 则确保这些角色之间共享的不是零散结论，而是不断演化、可继续利用的项目依据。

这也解释了为什么File-as-Bus 在后期 refinement 阶段尤其重要。真正高价值的研究工程，不只是先做出一个能运行的版本，更要在后续的诊断、修补、结果对齐与迭代优化中逐步逼近目标。没有稳定的状态连续性，系统很难真正进入这一“越做越准”的后半程。