AiScientist：扔掉对话接力棒，用文件总线撑起23小时自主科研

你有没有这种感觉——让AI智能体跑一个几十分钟的ML任务还行，但一旦让它连续干上几个小时甚至一天，它就开始"失忆"？上一轮跑出的实验结果，下一轮它就忘了读；刚写好的代码，跑完实验回来它又想重写一遍。这不是模型笨，是架构有问题。

中国人民大学团队的AiScientist直接对着这个痛点下刀：长周期ML研究工程的瓶颈不在推理，在状态连续性。他们提出了一套分层编排 + File-as-Bus 的系统，让智能体在23小时内跑了74轮实验，AUC从0.903一路拉到0.982。PaperBench上比最强基线高10.54分，MLE-Bench Lite拿到81.82%的Any Medal。

核心判断：这篇论文最大的贡献不是又搞了一个多智能体框架，而是用工程实证告诉所有人——在长周期科研任务里，文件比对话可靠，编排比堆算力有效。File-as-Bus移除后PaperBench掉6.41分、MLE-Bench Lite掉31.82个百分点，这个消融数据本身比主实验更有说服力。

论文信息

  • 标题：Toward Autonomous Long-Horizon Engineering for ML Research
  • 作者：Guoxin Chen, Jie Chen, Lei Chen, Jiale Zhao, Fanzhe Meng, Wayne Xin Zhao, Ruihua Song, Cheng Chen, Ji-Rong Wen, Kai Jia
  • 机构：中国人民大学高瓴人工智能学院
  • 日期：2026年4月14日
  • 链接：https://arxiv.org/abs/2604.13018
  • 代码：https://github.com/AweAI-Team/AiScientist

长周期ML科研到底难在哪

先说问题。OpenAI的PaperBench基准测了一件事：给AI一篇顶会论文，让它从零开始复现——理解论文、配环境、写代码、跑实验、调试迭代。结果呢？最优秀的AI智能体只能拿到21%的复现分，而ML博士48小时能拿到41%。差距肉眼可见。

为什么差这么多？论文总结了四个核心难点：

难点 具体表现
欠规范性 论文不会把每个超参、每个数据预处理细节都写清楚，智能体得自己补全决策
系统设置负担 光写算法不够，还得配环境、下数据集、装依赖、处理版本冲突
延迟反馈 跑一版实验要好几分钟甚至几十分钟，出了问题可能是代码bug、数据问题、超参不对——归因困难
状态连续性 每一轮的代码、日志、诊断结果都是下一轮决策的依据，长链条上稍有断裂就全偏了

说实话，这四个痛点我之前在搞自动化ML pipeline的时候深有体会。前三个都还能靠更好的模型、更长的上下文窗口来缓解，但第四个——状态连续性——是个系统问题，不是把模型换更大的就能解决的。

已有的方案怎么处理这个问题的？大部分是两条路：

  1. 单智能体死磕：AIDE用树搜索策略反复试，说到底就是让一个智能体不停地试错。上下文窗口一撑爆，前面的实验结果就丢了。
  2. 多智能体接力：MetaGPT、ChatDev这种模式，让不同角色的智能体通过对话交接。但对话传递是有损的——你没法在一条消息里把整个代码仓库+实验日志+错误诊断全塞进去。

这就是AiScientist要解决的真正问题：怎么让多个专业化智能体在长周期任务中，不靠对话接力也能保持状态一致？

AiScientist的核心设计：薄控制 + 厚状态

图1：AiScientist在MLE-Bench Lite的Detecting Insults任务上23小时自主迭代过程

图1：AiScientist在MLE-Bench Lite的Detecting Insults任务上跑了23小时，74轮实验循环，18次刷新最优成绩，AUC从0.903拉到0.982。注意那条不断上探的曲线——每一轮迭代都不是从零开始，而是在前一轮的产物基础上继续。

一句话概括核心思路

控制保持薄，状态保持厚。 顶层Orchestrator只管"现在该做什么"，不管"细节怎么做"；所有中间产物——论文分析、计划、代码、实验日志——全部外化到文件系统，作为整个系统的唯一真相来源。

这个思路其实不新鲜，在软件工程里叫"shared nothing + message passing"，在数据库里叫"write-ahead log"。但把它用在AI智能体编排里，并且用消融实验证明它的决定性作用，这是头一回。

分层编排：Agent-as-Tool

AiScientist的架构是三层结构：

图2：AiScientist架构图——分层编排与File-as-Bus协议

图2：Tier-0 Orchestrator通过阶段级指令和简洁摘要维持薄控制，Tier-1专家和可选的Tier-2子智能体通过权限范围的共享工作区协调。File-as-Bus让智能体从工作区映射开始，按需读取任务相关产物，写回持久化的分析、代码和日志。

Tier-0：Orchestrator。只做两件事：决定当前阶段该调用哪个专家，以及跟踪简洁的进度摘要。它的决策空间里，调用一个专家和调用一个普通工具是同构的——这就是Agent-as-Tool的设计。

Orchestrator的选择公式：

\[a_t = \pi_0(c_t, m_t, G; W_t), \quad a_t \in \mathcal{T}_0 \cup \mathcal{A}_1\]

其中 \(c_t\) 是阶段级控制上下文，\(m_t\) 是工作区映射，\(G\) 是目标，\(\mathcal{T}_0\) 是Orchestrator的原生工具集，\(\mathcal{A}_1\) 是Tier-1专家集。

Tier-1：五个专业化专家：

专家 职责 核心能力
论文理解专家 把论文转化为实现细节和目标指标 可并行调度子智能体分析不同维度
优先级排序专家 将理解转化为有序执行契约 识别依赖关系，按影响力和可行性排序
实现专家 从计划生成代码，或修复已有代码 全量模式和修复模式两种策略
实验专家 执行端到端流水线，比较产出与目标 记录结果和未解决问题
通用助手接口 处理辅助子任务 轻量级，按需创建

Tier-2：叶级子智能体。在专家的局部视野内创建，做结构提取、算法分析、环境设置这类聚焦子任务，不会递归生成更深层级。这很重要——避免了多智能体系统里常见的"无限委派"问题。

说到这个Agent-as-Tool的设计，我觉得挺巧妙的。它把委派变成了Orchestrator决策空间里的一个普通动作，而不是一个单独的协调协议。这意味着Orchestrator可以选择自己动手（用原生工具），也可以选择委派给专家，委派是选择性的而非强制的。这比那些"每个阶段都必须走一遍所有角色"的流水线架构灵活多了。

File-as-Bus：这篇文章最值钱的设计

File-as-Bus是整个系统里最核心的协议，也是消融实验里贡献最大的组件。

核心思想：在长周期ML研究工程中，关键的中间状态天然就是文件形式的——论文分析是markdown，计划是markdown，代码是python，配置是yaml，实验日志是txt。与其把这些信息压缩成对话消息传递，不如直接把文件系统当作协调总线。

工作区组织为三个权限对齐的区域：

目录 内容 谁写入
paper_analysis/ 结构化论文理解、目标指标、歧义记录 论文理解专家
submission/ 可运行复现仓库（代码、配置、reproduce.sh） 实现专家
agent/ 规划和执行工件（plan.md、impl_log.md、exp_log.md） 排序/实验专家

权限范围协调是关键——每个Tier-1专家只能写自己负责的区域，但都能读所有区域。共享日志是只追加和迭代结构化的。这减少了跨智能体干扰，提高了可追溯性。

还有一个设计叫渐进式披露。智能体不需要每次调用都摄入完整工作区内容——那会撑爆上下文窗口。而是通过一个工作区映射 \(m_t = \mathcal{M}(W_t)\) 进行导航，映射是项目状态的轻量级文本索引。智能体从映射开始，按需读取任务相关产物，写回持久输出。

你想想看，这个设计其实跟我们日常做项目的模式很像——你不会把所有代码和日志都背在脑子里，你会在需要的时候去看对应的文件。AiScientist不过是让智能体也这么做。

证据驱动的研究工程循环

AiScientist不是刚性的一次性流水线，而是一个证据驱动的循环。早期偏重论文理解和优先级排序，建立可运行的脚手架后，主导模式变成实现和实验的迭代交替。实验跑出来的失败trace、部分成功、指标差距、资源瓶颈——这些证据决定下一步该构建、修复还是测试什么。

这个设计有个细节我觉得很务实：Orchestrator不看代码细节。它只看简洁摘要和工作区映射。代码层面的决策全部交给实现专家和实验专家。这避免了Orchestrator被实现细节淹没的问题——说实话，这在工程实践中太常见了，leader一旦开始微观管理，整个系统就慢下来。

实验结果：数据说话

PaperBench完整评估

这是主战场——20篇ICML 2024 Spotlight/Oral论文的复现任务。

方法 模型 平均分 成本/任务
BasicAgent Gemini-3-Flash 19.26 $6.25
IterativeAgent Gemini-3-Flash 20.60 $27.44
AiScientist Gemini-3-Flash 30.52 $15.67
BasicAgent GLM-5 22.58 $4.90
IterativeAgent GLM-5 22.37 $54.90
AiScientist GLM-5 33.73 $12.20

两个关键发现：

  1. AiScientist在两个主干LLM上分别比最佳匹配基线高9.92和11.15分。平均下来就是论文标题里说的10.54分。
  2. 成本效率惊人。IterativeAgent靠多轮交互砸钱，成本是AiScientist的2-4倍，但分数反而更低。AiScientist靠结构化编排和File-as-Bus，用更少的交互轮次拿到了更好的结果。

说实话，看到IterativeAgent花了\(54.90还比不上AiScientist的\)12.20，我愣了一下。这说明光堆交互量是不够的，你还得交互得对。

MLE-Bench Lite：竞赛型ML任务

MLE-Bench Lite是OpenAI推出的Kaggle风格ML竞赛基准，33个任务。

方法 模型 有效提交 高于中位数 任意奖牌
AIDE Gemini-3-Flash 77.27 54.55 45.45
LoongFlow Gemini-3-Flash 77.27 77.27 77.27
AiScientist Gemini-3-Flash 100.00 86.36 81.82
AIDE GLM-5 77.27 50.00 40.91
ML-Master 2.0 GLM-5 100.00 81.82 63.64
AiScientist GLM-5 100.00 90.91 81.82

100%的有效提交率说明AiScientist每次都能产出能跑的代码，这本身就是长周期连续性的体现。对比AIDE只有77.27%的有效提交率——将近四分之一的尝试直接白费了。

消融实验：File-as-Bus到底有多关键？

这是全文最有说服力的部分。

图3：消融实验——File-as-Bus机制分析

图3左：AiScientist完整版优于简化基线和去File-as-Bus版本。图3右：File-as-Bus在后期迭代改进中更重要。

移除File-as-Bus后： - PaperBench：下降6.41分 - MLE-Bench Lite：Any Medal下降31.82个百分点

31.82个百分点。这个数字太猛了。

但更细致的发现是：在MLE-Bench Lite上，去掉File-as-Bus后，有效提交率和铜牌基本不受影响，但在银牌、金牌等更高等级上损失惨重。这说明什么？File-as-Bus的主要价值在于后期的迭代改进，而不是建立最低竞争力的起点。

这个发现很有工程直觉——你能写出第一版能跑的代码靠的是模型的代码能力，但你能把0.903的AUC拉到0.982靠的是状态连续性。没有文件系统帮你记住"第35轮实验试了什么参数、效果如何"，你每轮迭代都像在赌。

另一个消融比较也值得注意：即使去掉File-as-Bus，AiScientist仍然比BasicAgent在PaperBench上高4.74分。这说明分层编排本身也有实质贡献，不只是File-as-Bus的功劳。论文的观点是：长周期ML研究工程既是编排问题，也是状态连续性问题，两者缺一不可。

跟同行比：AiScientist站在什么位置

图4：MLE-Bench Lite排行榜对比

图4：AiScientist在MLE-Bench Lite上的受控评估结果与官方排行榜的对比。

把AiScientist放进更大的context里看：

系统 核心策略 代表结果
AIDE 树搜索式试错，单智能体 MLE-Bench Lite 45.45% Any Medal
ML-Master 2.0 指令策略优化，上交出品 MLE-Bench排行榜75.76%
R&D-Agent 研发闭环，用GPT-5 68.18% Any Medal
AI Scientist-V2 端到端论文生成，Sakana AI 目标是生成论文，不是复现
AiScientist 分层编排 + File-as-Bus 81.82% Any Medal

AIDE是单智能体路线的代表——靠树搜索反复试，但上下文窗口一满就丢失历史。ML-Master 2.0是上交的工作，走了指令策略优化的路子，效果也不错但依赖更强的模型。AI Scientist-V2走的是另一条路——它目标是自动生成论文，不是复现已有论文，跟AiScientist解决的不是同一个问题。

AiScientist的独特定位是：它不追求最强模型 + 最优prompt的暴力路线，而是靠架构设计来弥补单次推理的不足。用Gemini-3-Flash这种不是最顶级的模型，照样打出了81.82%的成绩。这个思路对工程落地的意义是：你不需要买最贵的API，你需要更好的系统设计。

我的判断

亮点：

  1. File-as-Bus是一个真正有工程洞察的设计。它不是花哨的算法创新，而是对"AI智能体该怎么管理长周期状态"这个问题的务实回答。消融数据太硬了——31.82个百分点的差距不是靠调参能解释的。
  2. 薄控制厚状态的分离原则。Orchestrator只看摘要和映射，不看代码细节。这跟优秀的工程管理是同构的——tech lead不需要review每一行代码，他需要知道进度、风险和下一步。
  3. 成本效率。用更少的交互、更便宜的模型打出更好的成绩，这才是工程落地的正确方向。

问题：

  1. 评估基准的公平性存疑。PaperBench用GPT-5.4打分，虽然作者说评分一致性很高，但用LLM评估LLM产出本身就有隐忧。MLE-Bench Lite的Kaggle指标是客观的，但PaperBench的主观评分可能偏向"看起来完整"而非"真正正确"的实现。
  2. 对论文理解专家的依赖很重。如果第一轮论文理解就出了偏差，后面的所有迭代都是在错误的方向上越走越远。论文没有讨论这个"首轮错误传播"的问题。
  3. File-as-Bus在更开放的任务上是否同样有效？ 论文验证的场景都是有明确目标的（复现论文、做Kaggle竞赛）。如果目标是"探索一个新方向"，没有明确的成功标准，File-as-Bus的迭代还能这么高效吗？这块我没看到讨论。
  4. 人类基线的差距仍然很大。AiScientist在PaperBench上拿了30-34分，ML博士是41分。近10分的差距说明，在真正需要深度理解和创造性解决方案的场景下，当前架构还有明显的天花板。

工程启发：

如果你在做任何长周期的AI Agent系统——不只是ML研究，包括软件开发、数据分析、甚至自动化运维——File-as-Bus这个思路都值得认真考虑。不要让智能体通过对话传递状态，让它们通过共享文件系统同步状态。 对话是即时的，文件是持久的。在需要跨多小时、跨多轮迭代的任务里，持久性比即时性重要得多。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我