Agent不是关键！人大AiScientist实现23小时、74轮长程记忆

首页

热心网友

转载

2026-04-20

新智元报道

编辑：LRST

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

自动化科学研究，正在成为人工智能领域最受关注的方向之一。

在机器学习场景下，已经有越来越多系统能够参与从想法生成、文献综述、定向实验到科学写作等研究环节。无论是从论文到代码，还是从实验到分析，AI for Research 的边界都在快速外扩。

那么，下一个关键突破口在哪里？中国人民大学团队打造的AiScientist，给出了一个颇具操作性的答案：聚焦于长程机器学习研究工程。

【新智元导读】中国人民大学团队打造的AiScientist，旨在解决长程机器学习研究工程的持续性难题。该系统从论文理解开始，跨越环境配置、代码实现与实验迭代，保持状态连续与决策连贯，显著提升科研效率。其核心在于通过File-as-Bus机制，稳定保存项目状态，使AI能真正接手科研流程，而非仅辅助单个环节。

AiScientist的切入点，是在这些已有进展的基础上，进一步关注一个更具操作性、也更接近真实科研流程的设定：长程ML research engineering。

在这一设定下，系统要完成的不是某一个孤立的环节，而是要从论文或研究目标出发，连续处理环境配置、依赖管理、资源获取、代码实现、实验执行、结果对比、错误归因和反复修复。这里既有局部环节本身的技术难度，更有跨阶段持续推进时的系统性挑战。

更关键的是，这些问题往往不会即时暴露。一个早期决策的微小偏差，可能要到数小时后的实验结果里才会显现；而一旦项目状态在多轮推进中丢失，后续阶段就很难判断问题究竟来自论文理解、实现细节、数据处理，还是基础设施配置。

中国人民大学高瓴人工智能学院此次提出的AiScientist，正是沿着这条方向，试图把AI从「能参与若干研究环节」进一步推进到「能持续接手研究工程流程」。

论文：https://arxiv.org/pdf/2604.13018

仓库：https://github.com/AweAI-Team/AiScientist

23小时、74轮实验：AiScientist在做什么？

AiScientist最直观的结果，来自MLE-Bench Lite的Detecting Insults任务。

在这一任务上，AiScientist在23小时内自主完成了74轮实验循环，将验证集AUC从0.903提升到了0.982，期间实现了18次最佳结果更新。

这一结果的意义，不只是分数提高了多少，更在于它呈现出了一条完整的研究工程链路：从读取任务、搭建环境、撰写实现，到运行实验、分析偏差、修补系统、再验证结果，整个过程并非单次生成，而是持续迭代。

换句话说，AiScientist试图解决的并不是「再做一个更强的代码助手」，而是让 AI 在真实科研流程中，开始具备持续推进任务的能力。

AiScientist在解决什么问题？

现有不少AI for Research系统，已经能在某些研究环节展现出很强能力，例如生成代码、总结论文、辅助实验设计，甚至完成一整篇论文的撰写。

AiScientist则聚焦于实验性更强的场景：ML research engineering。这并非一个单点问题，而是一条跨阶段、长时间的连续任务链。系统需要先理解论文和目标设定，再处理依赖与资源，完成实现，运行实验，并根据实验输出做归因、修正和继续迭代。

其中每一个环节，本身都已经足够困难。论文可能是不完整、欠规格化的；环境配置与依赖下载常常琐碎而脆弱；实验反馈具有明显延迟，而且错误原因往往交织在实现、数据、超参与基础设施多个层面。

论文也指出，这一困难已经在严苛评测中有所体现：在 PaperBench 这类高难度从零复现任务上，最佳已报告智能体仅达到约21%的复现评分，而顶尖ML PhD在48小时预算下可达到41%。这说明，长程研究工程的瓶颈并不只是模型能否完成局部推理，而是系统能否跨越多个阶段，保持状态连续和决策连贯。

也就是说，长程ML research engineering既包含很多高难度的局部问题，也要求把这些问题在时间线上顺序串起来、相互校正、持续推进。真正的难点，不只是「这一轮会不会推理」，而是系统能不能在不同阶段之间保持连贯的进展。

不只是「多几个Agent」

AiScientist 的核心设计理念，可以概括为一句话：轻量控制，厚重状态。

在这套系统中，顶层的协调器负责阶段级控制与任务推进，相当于一个轻量的总调度器；而真正承载项目记忆的，则不是一轮轮对话上下文，而是工作空间中持续演化的分析、计划、代码、日志与实验记录。

换句话说，AiScientist并不试图让某一个智能体把所有细节都「记在脑子里」，而是让不同角色围绕一个持续更新的项目状态展开协作。顶层控制保持轻量，底层状态保持厚实，系统因此可以在长程任务中逐步积累，而不是反复从头开始。

这也是这项工作的一个重要判断：让系统跑长的关键，不只是多智能体分工本身，而是这些分工能否建立在稳定、可继承的项目状态之上。

File-as-Bus是关键

AiScientist将这种「项目状态」进一步落实成了File-as-Bus机制。

简单理解，它不是把文件当作普通附件来存放，而是把文件系统本身当作长程协作的底座。论文分析、任务计划、实现代码、实验日志、错误记录和中间结果，都被持续写回工作空间，成为后续阶段可以重新读取和利用的持久化产物。

这意味着，系统不是依赖对话里残留的几句摘要继续工作，而是可以围绕真实存在的项目证据来推进下一步决策。对于长程研究工程来说，这一点至关重要。因为前一阶段的一个判断，可能会在几个小时后才以实验异常的形式暴露出来；如果这些中间状态无法被完整保留，后续阶段就很难准确归因，更难在正确位置做修补。

也因此，AiScientist的重点并不只是「让多个Agent配合起来」，而是让整个系统具备一种更稳定的外部记忆能力。真正需要被传递的，不是某一轮的表面结论，而是项目在不同阶段里逐步积累下来的状态本身。

实验结果

在PaperBench上，AiScientist相对最佳匹配基线平均提升约10.54 分。这一结果说明，它并不只是在某个单独案例上有效，而是能够在从论文复现到完整工程实现的高难度场景中，稳定拉开与现有方法的差距。

在MLE-Bench Lite上，AiScientist达到了81.82%的“任意奖牌”率，说明它不只擅长「把系统先跑起来」，也能在更接近真实竞赛和研究迭代的场景中持续优化结果。

更重要的是，这种提升并不是简单靠「多交互几轮」堆出来的。论文明确指出：仅仅增加交互轮次是不够的。额外的轮次只有建立在前面正确积累的状态之上，才会真正转化为长程能力。否则，更多交互反而可能带来更高成本和更多噪声。

机制分析进一步说明了这一点。移除File-as-Bus后，AiScientist在PaperBench上下降6.41分，在MLE-Bench Lite上“任意奖牌”率下降31.82个百分点。这表明，状态连续性并不是一个「锦上添花」的设计，而是长程研究工程里真正影响系统能否持续推进的关键因素之一。

与此同时，论文也没有把File-as-Bus说成唯一答案。实验同样表明，层级化协调也在性能提升中起到了重要作用。换句话说，AiScientist的价值并不来自某一个单独组件，而是来自协调机制与状态连续性共同支撑的系统设计。

启示

如果只看结果，AiScientist的贡献似乎只是「分数更高了」。但从论文给出的机制分析来看，这项工作的价值其实更立体。

第一，长程ML研究工程不只是很多局部问题的堆叠，它本身还是一个更难的系统问题。论文理解、环境配置、资源下载、代码实现、实验执行、误差诊断，这些环节单独拿出来，很多都已经是足够困难的技术任务；更难的是，要把这些环节在长时间跨度里顺序接起来、相互校正、持续推进。也正因为如此，决定系统成败的，不只是某一步做得好不好，而是整个流程能否在跨阶段推进中保持连贯。

第二，AiScientist的关键，不只是用了多智能体，而是把状态连续性做成了系统能力。层级化协调当然重要，它帮助不同角色聚焦不同阶段；但真正让这套组织形式产生复利的，是项目状态能否以持久化产物的形式被稳定保存、读取、继承和继续利用。换句话说，多智能体是组织形式，状态连续性才是这套系统真正跑长的基础。

第三，File-as-Bus的价值，更多体现在后期精炼，而不只是前期搭一个能跑的脚手架。从消融结果看，去掉File-as-Bus后，系统未必立刻连基础可运行性都失去，但在更依赖后期优化和结果逼近的指标上，会出现更明显退化。这意味着它真正带来的，不只是可执行性，更是保真度：让系统能在多轮诊断、修补、对齐和优化中，把每一轮试错都建立在前一轮留下的有效证据之上。