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的时候深有体会。前三个都还能靠更好的模型、更长的上下文窗口来缓解，但第四个——状态连续性——是个系统问题，不是把模型换更大的就能解决的。
已有的方案怎么处理这个问题的？大部分是两条路：
- 单智能体死磕：AIDE用树搜索策略反复试，说到底就是让一个智能体不停地试错。上下文窗口一撑爆，前面的实验结果就丢了。
- 多智能体接力：MetaGPT、ChatDev这种模式，让不同角色的智能体通过对话交接。但对话传递是有损的——你没法在一条消息里把整个代码仓库+实验日志+错误诊断全塞进去。
这就是AiScientist要解决的真正问题：怎么让多个专业化智能体在长周期任务中，不靠对话接力也能保持状态一致？
AiScientist的核心设计：薄控制 + 厚状态
图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：Tier-0 Orchestrator通过阶段级指令和简洁摘要维持薄控制，Tier-1专家和可选的Tier-2子智能体通过权限范围的共享工作区协调。File-as-Bus让智能体从工作区映射开始，按需读取任务相关产物，写回持久化的分析、代码和日志。
Tier-0：Orchestrator。只做两件事：决定当前阶段该调用哪个专家，以及跟踪简洁的进度摘要。它的决策空间里，调用一个专家和调用一个普通工具是同构的——这就是Agent-as-Tool的设计。
Orchestrator的选择公式：
其中 \(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 |
两个关键发现：
- AiScientist在两个主干LLM上分别比最佳匹配基线高9.92和11.15分。平均下来就是论文标题里说的10.54分。
- 成本效率惊人。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左：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：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，你需要更好的系统设计。
我的判断
亮点：
- File-as-Bus是一个真正有工程洞察的设计。它不是花哨的算法创新，而是对"AI智能体该怎么管理长周期状态"这个问题的务实回答。消融数据太硬了——31.82个百分点的差距不是靠调参能解释的。
- 薄控制厚状态的分离原则。Orchestrator只看摘要和映射，不看代码细节。这跟优秀的工程管理是同构的——tech lead不需要review每一行代码，他需要知道进度、风险和下一步。
- 成本效率。用更少的交互、更便宜的模型打出更好的成绩，这才是工程落地的正确方向。
问题：
- 评估基准的公平性存疑。PaperBench用GPT-5.4打分，虽然作者说评分一致性很高，但用LLM评估LLM产出本身就有隐忧。MLE-Bench Lite的Kaggle指标是客观的，但PaperBench的主观评分可能偏向"看起来完整"而非"真正正确"的实现。
- 对论文理解专家的依赖很重。如果第一轮论文理解就出了偏差，后面的所有迭代都是在错误的方向上越走越远。论文没有讨论这个"首轮错误传播"的问题。
- File-as-Bus在更开放的任务上是否同样有效？ 论文验证的场景都是有明确目标的（复现论文、做Kaggle竞赛）。如果目标是"探索一个新方向"，没有明确的成功标准，File-as-Bus的迭代还能这么高效吗？这块我没看到讨论。
- 人类基线的差距仍然很大。AiScientist在PaperBench上拿了30-34分，ML博士是41分。近10分的差距说明，在真正需要深度理解和创造性解决方案的场景下，当前架构还有明显的天花板。
工程启发：
如果你在做任何长周期的AI Agent系统——不只是ML研究，包括软件开发、数据分析、甚至自动化运维——File-as-Bus这个思路都值得认真考虑。不要让智能体通过对话传递状态，让它们通过共享文件系统同步状态。 对话是即时的，文件是持久的。在需要跨多小时、跨多轮迭代的任务里，持久性比即时性重要得多。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我