新智元报道

编辑：LRST

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

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

在机器学习场景下，已经有越来越多系统能够参与 idea generation、literature synthesis、targeted experimentation、scientific writing 等研究环节。无论是从论文到代码，还是从实验到分析，AI for Research 的边界都在快速外扩。

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轮实验循环，将validation AUC从0.903提升到了0.982，期间实现了18次best-so-far update。

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

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

AiScientist在解决什么问题？

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

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

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

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

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

不只是「多几个Agent」

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

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

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

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

File-as-Bus是关键

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

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

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

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

实验结果

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

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

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

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

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

启示

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

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

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

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

为什么这件事值得关注？

从更大的视角看，AiScientist指向的是一个比benchmark分数更值得关注的问题：AI能否真正进入科研流程，而不只是停留在某一个局部环节。

长程ML research engineering既是很多困难local problem的串联，也是一个更难的systems problem。每个局部环节都足够复杂，而把这些环节接起来、在多轮反馈里保持一致性、让前一轮决策真正服务于后一轮推进，则更难。

AiScientist给出的一个重要启示是：未来的AI科研系统，关键不只是模型会不会推理、会不会写代码、会不会调用工具，而是能否在长时间跨度里稳定保存、继承并利用项目状态。

这也是为什么这项工作值得被放在更广的AI for Research进展中来看。它讨论的不是单步能力的再增强，而是 AI 如何真正从「辅助一个环节」走向「接手一条流程」。

与此同时，团队也在将AiScientist从benchmark中的评测对象，逐步推进为真实可用的软件系统。换句话说，这项工作并不只是想回答「分数能不能提高」，也想回答「AI 能不能真正走进实验、复现、调参和迭代的日常流程里，进一步解放实验层面的生产力」。

总结

AiScientist试图推动的，并不只是一个更强的科研Agent，而是一种对长程研究工程的新理解：在真实科研任务中，真正重要的往往不是单次生成得多漂亮，而是系统能否在跨阶段、跨轮次、跨文件的任务链中，把项目状态稳定存住，并据此持续推进。

如果这一点成立，那么AI进入科研流程的方式，也将从「辅助某一步」逐渐走向「接手整条链路」。

参考资料：

https://arxiv.org/pdf/2604.13018