作者 | 论文团队
编辑丨ScienceAI
如果说 AI for Science 的一个长期目标，是让模型不只回答科学问题、解释实验现象，而是真正帮助研究者完成一整条研究流程，那么机器学习研究工程无疑是最具挑战性的场景之一。
因为在这里，系统面对的并不是一道题、一次生成，或者某个孤立的编码任务，而是一条跨越论文理解、环境搭建、资源获取、代码实现、实验运行、结果诊断与反复修复的连续任务链。每个环节本身都很难，而把这些环节在数十小时的跨度中真正接起来、持续推进，则更难。
近日，中国人民大学高瓴人工智能学院提出了一个名为 AiScientist 的系统，尝试解决这一设定：long-horizon ML research engineering。
论文地址：https://arxiv.org/pdf/2604.13018
代码地址：https://github.com/AweAI-Team/AiScientist
它试图回答一个更具体、也更接近真实科研的问题：如果给 AI 一篇论文或者一道科学任务、一个基础环境和有限预算，它能否从头开始，把研究工程一步一步做下去？
答案正在变得越来越清晰。
在 MLE-Bench Lite 的 Detecting Insults 任务上，AiScientist 在 23 小时内自主完成了 74 轮实验循环，将 validation AUC 从 0.903 提升到 0.982。在更具挑战性的 PaperBench 上，它相对最佳匹配基线平均提升 10.54 分；在 MLE-Bench Lite 上，系统达到 81.82% Any Medal。进一步的机制分析还表明，真正决定长程研究工程能否持续推进的，关键不只是单步推理够不够强，而是系统能否在跨阶段迭代中维护、继承并利用不断演化的项目状态。
为什么研究工程比「会写代码」更难？
过去一年，AI for Research 的进展非常快。从 idea generation、literature synthesis，到代码实现、实验辅助、科学写作，越来越多系统已经展现出实用价值。
但研究工程和单点能力不同。它不是把几个能力模块简单拼起来就能完成的任务，而是一种典型的「长程、延迟反馈、状态敏感」问题。
论文把这种困难概括得很准确。首先，研究规格往往是不完备的。论文不会把所有实现细节都写清楚，模型需要自己补足缺失决策。其次，系统 setup 本身就很重，环境、依赖、数据和模型资源都可能成为阻塞点。再次，真正有价值的反馈往往要等实验跑起来之后才会出现，而且问题来源常常是混杂的：可能是理解偏差，也可能是代码实现、数据处理、超参选择，甚至是基础设施配置。
更关键的是，项目状态必须被持续保留。一轮实验产出的日志、配置、结果和诊断，都会直接影响下一轮决策。如果这些状态在多轮推进中丢失，系统就很难判断「哪里出了问题」，更难真正进入后续 refinement。
也正因如此，ML research engineering 不只是很多 local problem 的叠加，它本身还是一个更难的 systems problem。
AiScientist 的核心，不仅仅是「更会分工」，而且是「更会把状态存住」
AiScientist 的核心思路，可以用论文中的一句话概括：thin control over thick state。
直白来说，就是把「控制」和「状态」拆开。
一方面，系统保留一个轻量的顶层 Orchestrator，负责阶段级决策与流程推进；另一方面，真正承载项目记忆的，不是不断膨胀的对话上下文，而是 workspace 中持续演化的分析、计划、代码、实验日志和结果记录。
这套设计包含两个互相配合的关键部分。
第一，是层级化 orchestration。
AiScientist 并不是把所有事都交给同一个 agent 去完成，而是让不同角色分别处理论文理解、任务规划、代码实现、实验执行与诊断修复等环节。这样做的目的，不只是「多几个 agent」，而是让每个角色都在更合适的局部上下文里工作。
第二，是 File-as-Bus。
这是 AiScientist 更有辨识度的一点。它把共享工作区视为系统的「外部记忆」。论文分析、任务计划、实现代码、实验日志、错误记录等，都被持续写回文件系统，成为后续阶段可以重新读取和利用的 durable artifacts。系统因此不需要每一轮都把历史重新塞回 prompt，而是可以围绕真实存在的项目证据继续推进。
换句话说，AiScientist 的关键，不只是多智能体组织形式本身，而是它把状态连续性做成了系统能力。
结果之外，更值得注意的是什么？
在 PaperBench 上，AiScientist 相对最佳匹配基线平均提升约 10.54 分。这意味着，它并不是只在个别 case 上有效，而是在从论文复现到完整工程实现的高难度任务中，稳定拉开了与现有方法的差距。
在 MLE-Bench Lite 上，AiScientist 达到了 81.82% Any Medal，说明它不只擅长「先跑出一个版本」，也能在更接近真实实验优化的场景中持续改进结果。
但论文里最值得注意的，其实不只是这些数字，还有一个很重要的判断：More interaction alone is not enough.
这句话背后对应的是一个常见误解：很多人会自然地以为，只要让系统多试几次、多跑几轮，就能自动获得更强的长程能力。但论文的结论恰恰相反。额外的轮次只有建立在前面正确积累的状态之上，才会真正转化为有效进步；否则，更多交互反而可能意味着更高成本和更多噪声。
File-as-Bus 为什么值得单独看？
论文的消融实验给出了一个非常清晰的信号。
移除 File-as-Bus 后，AiScientist 在 PaperBench 上下降 6.41 分，在 MLE-Bench Lite 上 Any Medal 下降 31.82 个百分点。这说明，状态连续性并不是一个「有更好、没有也行」的辅助设计，而是长程研究工程里真正决定系统能否持续推进的重要机制。
更有意思的是，这种退化并不是平均落在所有阶段上。论文显示，去掉 File-as-Bus 后，系统未必立刻连基础可运行性都失去，但在更依赖后期 refinement 的指标上，退化会更明显。
这意味着，File-as-Bus 的价值不只是帮助系统先搭一个能跑的脚手架，更重要的是让系统在后续的诊断、修补、结果对齐与迭代优化中，真正把每一轮试错都建立在前一轮留下的有效证据之上。
从这个角度看，它解决的并不只是 executability，更是 fidelity。
这项工作对 AI for Science 意味着什么？
AiScientist 之所以值得 AI for Science 社区关注，并不只是因为它在某个 benchmark 上拿到了更高分数，而是因为它触及了一个更深层的问题：
如果 AI 想真正进入科学研究流程，它需要的不只是更强的单步能力，还需要在长程任务中维持项目状态、衔接异构阶段、持续吸收实验反馈。
对于科学研究而言，这一点非常关键。因为真正高价值的科研任务，很少是一次生成就结束的。无论是算法复现、实验设计、参数迭代，还是结果分析与修正，研究者都在和一种「不断演化的项目状态」打交道。
也正因为如此，AiScientist 给出的启示并不局限于机器学习研究工程本身。它更像是在提醒整个 AI for Science 社区：未来更强的科学智能体，也许不仅要「会推理、会生成、会调用工具」，还要学会在长时间跨度里记住什么、保留什么、继承什么、继续推进什么。
从 benchmark 走向研究工具
论文还有一点值得注意：团队并没有把 AiScientist 停留在 benchmark 评测对象上，而是在继续把它推进为真实可用的软件系统。
这件事很重要。因为 benchmark 回答的是「能不能做」，而工具真正回答的是「能不能被用起来」。
如果 AI 研究系统未来真的要进入实验、复现、调参与迭代的日常流程，那么它最终必须以工具形态存在，成为研究者工作流的一部分，而不只是论文中的一个分数。
小结
AiScientist 试图推动的，并不只是一个更强的科研 agent，而是一种对长程研究工程的新理解：在真实科研任务中，真正重要的往往不是单次生成得多漂亮，而是系统能否在跨阶段、跨轮次、跨文件的任务链中，把项目状态稳定存住，并据此持续推进。
如果这一点成立，那么 AI 进入科研流程的方式，也将从「辅助某一步」逐渐走向「接手整条链路」。
热门跟贴