AiScientist：自主长程 ML 研究工程系统深度解读

> 论文：Toward Autonomous Long-Horizon Engineering for ML Research > arXiv: 2604.13018 | 2026-04-14 > 作者：Guoxin Chen, Jie Chen, Lei Chen, Jiale Zhao, Fanzhe Meng, Wayne Xin Zhao, Ruihua Song, Cheng Chen, Ji-Rong Wen, Kai Jia > 机构：中国人民大学高瓴人工智能学院、AweAI 团队等 > GitHub: https://github.com/AweAI-Team/AiScientist

---

一、问题：为什么 AI 读论文容易，做科研工程这么难？

自主 AI 研究在过去两年突飞猛进。从文献综述到代码生成，从实验设计到结果分析，单点能力已经相当成熟。但当你试图让 AI 接管一个完整的 ML 科研项目——从理解论文、配置 Docker、实现算法、跑实验、调试报错、反复迭代——事情就开始崩了。

根本原因不是某个局部环节不够强，而是长程连贯性（long-horizon coherence）出了问题。

一个典型的 ML 科研项目涉及五个高度耦合的异构阶段：

1. 任务理解 — 解读论文或竞赛描述，提炼可执行的技术规格 2. 环境搭建 — 配置 Docker、安装依赖、处理数据 3. 代码实现 — 将 paper 中的方法转化为可运行的代码 4. 实验迭代 — 运行实验、收集结果、诊断问题 5. 调试优化 — 从报错和实验偏差中定位原因，修正实现

这些阶段不是线性执行的，而是反复回环的。你写代码时可能发现论文里有歧义，跑实验时可能发现环境配置有问题，调试时可能推翻之前的实现假设。一个早期的决策（比如对论文某个公式的理解）可能要过几个小时甚至几天，才会以实验偏差的形式暴露出来。

这就是论文所说的 "underspecification + delayed feedback + system setup burden" 的三重困境：

规范不足（Underspecification）：论文不会告诉你所有细节，环境不会自动配好
延迟反馈（Delayed Feedback）：实验结果出来的很慢，而且原因往往混杂（是代码 bug？环境差异？还是理解错了方法？）
系统负担（System Setup Burden）：ML 项目的依赖链条极长，一个小版本的差异就能让结果完全不同

现有的 agent 系统（如 AutoGPT、MetaGPT）把这些问题当作"加长版对话"来处理——agent 之间通过对话传递上下文。但对话上下文是易失的（transient）：context window 会满，handoff 会丢信息，多轮之后 agent 就忘了自己为什么做这个决策。就像你在一个 24 小时的电话会议里接力做项目，每个人只能记住最近 5 分钟说了什么。

这就是 AiScientist 要解决的问题：把长程 ML 研究工程从"对话接力"变成"状态工程"。

---

二、核心洞察：两个系统原则

AiScientist 的设计哲学非常简洁：强大的长程性能需要两个条件——结构化编排（orchestration）和持久状态连续性（state continuity）。

这不是什么复杂的数学定理，而是一个工程观察：

> 长程失败不是因为你不够聪明，而是因为你在第 20 轮迭代时忘了第 3 轮时的关键假设。

所以 AiScientist 做了两件事：

2.1 分层编排（Hierarchical Orchestration）

不用一个 monolithic agent 做所有事，而是用分层研究团队：

Tier-0 Orchestrator（编排器）：像 PI（Principal Investigator）一样做阶段级决策。它不做具体实现，只决定"现在该做什么阶段"、"把这个任务委派给谁"。
Tier-1 Specialists（专业 agent）：5 个专职 agent — Paper Comprehension（论文理解）、Prioritization（任务排序）、Implementation（实现）、Experimentation（实验）、Generic Helper（通用辅助）。每个有明确的角色和写入权限。
Tier-2 Subagents（子 agent）：用于结构提取、资源下载等聚焦子任务，不递归展开，保证分解有界。

这种设计的妙处在于关注点分离（separation of concerns）。Orchestrator 不用记住代码细节，Implementation agent 不用操心整体策略。就像真实实验室里 PI 不用自己调超参，博士生不用操心项目方向。

2.2 File-as-Bus 协议：把文件当作系统总线

这是 AiScientist 最核心的创新，也是论文中消融实验效果最显著的变量。

核心思想：agent 之间不通过对话传递状态，而是通过读写共享工作空间中的文件来协调。

具体来说：

Workspace 是记录系统（System of Record）：计划、代码、实验日志、验证报告都作为 durable artifacts 存在磁盘上
权限范围（Permission-scoped）：不同 agent 只能读写自己负责的区域。比如 Paper Comprehension 写 paper_analysis/，Implementation 写 code/
渐进式披露（Progressive Disclosure）：agent 从 workspace map 开始，按需读取任务相关文件，而不是一次性加载整个项目历史
重新锚定（Re-grounding）：每个 agent 被调用时，从文件中重新加载当前项目状态，而不是依赖对话上下文

这种设计产生了一个关键效果：薄控制覆盖厚状态（Thin Control over Thick State）。

Orchestrator 的控制上下文是"薄"的——它只读简洁摘要和 workspace map 做决策。而项目状态是"厚"的——详细的分析、代码、实验记录作为文件持久存在。当 Orchestrator 说"现在进入实验阶段"，Experimentation agent 会去读 code/、plan.md、exp_log.md，然后写回新的实验结果。状态不需要通过对话压缩传递，它一直在那里。

---

三、Workspace 结构：项目状态的物理布局

AiScientist 的 workspace 设计本身就是一种声明式架构——文件布局编码了项目语义。

jobs/<job_id>/
├── input/                      # 原始输入
├── workspace/                  # File-as-Bus 核心区域
│   ├── paper/ or data/         # 论文资料或竞赛数据
│   ├── code/                   # 实现代码（MLE 轨道）
│   ├── submission/             # 提交物
│   │   ├── submission.csv
│   │   ├── submission_registry.jsonl
│   │   └── candidates/         # MLE 候选方案
│   └── agent/                  # Agent 协作区域
│       ├── paper_analysis/     # 论文分析（paper 轨道）
│       ├── analysis/           # 数据分析（mle 轨道）
│       ├── prioritized_tasks.md
│       ├── plan.md
│       ├── impl_log.md         # 实现日志
│       ├── exp_log.md          # 实验日志
│       └── final_self_check.{md,json}  # 最终自检
├── logs/                       # 操作员追踪层
├── artifacts/                  # 验证/冠军报告
├── export/                     # 打包输出
└── state/                      # 主机端运行时元数据

这个结构的关键在于把 agent 的"心智模型"外化到文件系统中：

plan.md 是当前策略的 single source of truth
impl_log.md 和 exp_log.md 是项目历史的 durable record
submission_registry.jsonl 记录了所有实验过的候选方案及其性能
每个 agent 知道自己该读哪些文件、该写哪些文件

当 run 结束后，你得到的是一个完整的、可审计的、可恢复的项目快照。你可以 diff 两次 run，可以 resume 一个中断的任务，可以验证 agent 的每一个决策。

---

四、两条轨道：Paper 复现与 MLE 竞赛

AiScientist 用同一套架构支持两种长程工作负载：

轨道	入口	优化目标	验证端点
paper	`--paper-md` 或 `--zip`	将论文上下文转化为可运行的复现	最终自检 + `validation_report.json`
mle	`--zip`、`--name`、`--workspace-zip` 等	通过反复实现-实验循环改进目标指标	提交格式或评分验证

Paper 轨道

给定一篇论文（markdown 或 zip 包），AiScientist 驱动完整的复现循环：

1. 理解 — Paper Comprehension agent 分析论文，提取方法、数据集、指标 2. 计划 — Prioritization agent 将论文转化为任务列表，写入 prioritized_tasks.md 3. 实现 — Implementation agent 按任务列表写代码 4. 实验 — Experimentation agent 运行实验，记录结果到 exp_log.md 5. 调试 — 当实验与论文不符时，agent 读取日志、定位问题、修正实现 6. 自检 — 最终 final_self_check.md 和 reproduce.sh 验证可复现性

MLE 轨道

给定一个 ML 竞赛任务，AiScientist 迭代搜索更强的方案：

论文中展示了一个 Detecting Insults 任务的 23 小时自主运行轨迹：

74 个实验周期
18 次 best-so-far 更新
验证 AUC 从 0.903 提升到 0.982

这不是一个 lucky guess，而是持续改进的轨迹——agent 反复实现、测试、保留或丢弃候选方案，把"当前最佳"不断推高。

---

五、评估：数据说话

5.1 PaperBench

PaperBench 是目前最苛刻的论文复现基准之一。在 48 小时预算下：

系统	平均分
人类 PhD 基线	41%
AiScientist	33.73
最强基线	22.58
AiScientist (无 File-as-Bus)	27.32

AiScientist 比最强基线提升 10.54 点，将差距从人类 PhD 的 19 点缩小到 7.27 点。

5.2 MLE-Bench Lite

系统	Any Medal%
AiScientist	81.82%
最强匹配基线	70.45%
AiScientist (无 File-as-Bus)	50.00%

AiScientist 达到 81.82 Any Medal%，比基线提升 11.37 点。

5.3 消融实验：File-as-Bus 是关键驱动因素

移除项	PaperBench 下降	MLE-Bench Lite 下降
File-as-Bus	-6.41	-31.82

File-as-Bus 协议对 MLE-Bench Lite 的影响尤为剧烈——移除后 Any Medal% 从 81.82% 暴跌到 50%。这说明在需要反复迭代优化的竞赛任务中，持久状态连续性几乎决定了一切。

5.4 分层编排 vs 简单 agent 组织

论文还对比了非分层基线（BasicAgent 和 AIDE）：

即使移除 File-as-Bus，AiScientist 的分层变体仍比 BasicAgent 在 PaperBench 上高 4.74 点
在 MLE-Bench Lite 上 Above Median 高 22.73 点，Any Medal 高 9.09 点
仅增加交互量（IterativeAgent）不足以弥补分层结构的缺失

结论：分层编排和持久状态连续性都有独立贡献，不是二选一的关系。

---

六、深层洞察：长程研究工程的本质是什么？

AiScientist 的实验结果指向一个反直觉的结论：

> 长程 ML 研究工程本质上是系统问题，不是推理问题。

换句话说，问题不在于"模型够不够聪明"，而在于"系统能不能在多天的运行中保持状态不腐化"。

这解释了为什么：

1. 更强的单点能力不够：即使 GPT-5 能写更好的代码，如果 agent 在 20 轮后忘了最初的论文理解，项目仍然会崩 2. 更多交互不够：IterativeAgent 增加了交互量，但没有持久状态，仍然大幅落后 3. File-as-Bus 比想象中更重要：它不仅是一个"通信协议"，而是一个状态治理机制——确保每个 agent 在任何时刻都能重新锚定到正确的项目状态

这也解释了为什么 MLE-Bench Lite 对 File-as-Bus 的敏感度远高于 PaperBench：

PaperBench 是一个"目标明确但路径复杂"的任务——论文给了你方向，你只需要复现它
MLE-Bench Lite 是一个"目标明确但搜索空间巨大"的任务——你需要反复尝试、比较、淘汰，每一次迭代都依赖对历史尝试的准确记忆

在 MLE 任务中，agent 需要回答"我之前试过什么？效果怎么样？为什么这个方案比那个好？"如果这些信息只存在于对话上下文中，24 小时后它们就会面目全非。

---

七、对更广泛 AI 系统设计的启示

AiScientist 的设计原则不仅适用于 ML 研究工程，对任何长程自主系统都有参考价值：

7.1 从"对话系统"到"状态系统"

当前大多数 multi-agent 框架（包括 AutoGPT、MetaGPT、ChatDev）本质上是对话系统——agent 通过消息传递协作。AiScientist 展示了一条不同的路径：文件系统作为共享记忆。

这类似于人类科研团队的协作方式：

我们不靠口头交接做项目，而是写文档、代码、实验记录
新加入的人不需要听 10 小时的会议录音，只需要读最新的实验报告
PI 不需要记住所有代码细节，只需要读周报和项目计划

7.2 薄控制层是长程稳定的关键

Orchestrator 的设计揭示了一个重要原则：控制层越薄，系统越稳定。

如果 Orchestrator 需要记住所有代码细节才能做决策，它的上下文会迅速膨胀，推理质量下降。通过让 Orchestrator 只读摘要和 map，具体的厚状态由专业 agent 按需读取，系统可以在任意长的时间尺度上保持决策质量。

7.3 权限范围是安全性和正确性的基础

workspace 的权限范围设计不仅仅是安全考虑，更是认知隔离——每个 agent 只能写自己负责的区域，防止不同角色的推理互相污染。这比纯粹的 prompt 工程（"你扮演实现 agent"）更可靠，因为权限是系统级强制的。

---

八、局限与未来方向

论文坦诚地指出了一些局限：

1. 依赖 Docker 沙箱：环境隔离是必要的，但也增加了系统负担 2. 评估覆盖有限：只在 PaperBench 和 MLE-Bench Lite 上验证，其他长程任务（如数据收集、文献综述）尚未测试 3. 成本：24 小时的自主运行需要大量 API 调用，实际部署成本不低 4. 单点故障：Orchestrator 是关键枢纽，如果它的决策出错，整个项目可能偏离方向

未来方向可能包括：

支持更多类型的长程科研任务（如数据集构建、文献综述）
引入人类在环（human-in-the-loop）机制，在关键决策点请求人类确认
优化成本效率，比如通过缓存和增量更新减少重复调用
多 Orchestrator 架构，避免单点决策偏差

---

九、结论

AiScientist 是自主 AI 研究向"工程级可靠性"迈进的重要一步。它不追求单点能力的突破，而是解决了一个更根本的问题：如何让 AI 在多天的科研项目中不迷失方向。

核心贡献可以概括为三个：

1. File-as-Bus 协议：用文件系统替代对话传递，实现持久状态连续性 2. 分层编排架构：薄控制层 + 专业 agent 的分工模式，保证长程稳定性 3. 实证洞察：消融实验证明了状态连续性比交互量更重要，长程研究工程是系统问题而非推理问题

在 PaperBench 上 33.73 分和 MLE-Bench Lite 上 81.82% 的成绩，说明 AI 已经可以在特定条件下完成数小时到数天的自主科研工程。虽然距离"完全自主的 AI 科学家"还有距离——比如创造性发现、跨领域联想、对模糊目标的导航——但 AiScientist 证明了一个关键的前提：如果系统层面的状态管理做不好，再好的单点能力也会在长程中崩解。

先把地基打牢，才能建高楼。

---

参考与延伸阅读

论文: arXiv:2604.13018 — Toward Autonomous Long-Horizon Engineering for ML Research
代码: https://github.com/AweAI-Team/AiScientist
PaperBench: Starace et al., 2025 — 论文复现基准
MLE-Bench: Chan et al., 2025 — 竞赛式 ML 工程基准
相关系统: AutoGPT, MetaGPT, ChatDev, AIDE, RD-Agent

---

> 费曼视角补注：这篇论文的核心论点——"持久状态连续性是关键"——让我想起费曼常说的"你命名它不代表你理解它"。很多 multi-agent 系统把 agent 对话当作"协作"，但如果没有 durable state，那只是看起来像协作的轮流独白。真正的协作需要 shared context，而 AiScientist 把 context 外化到文件系统中，让每个 agent 都能随时重新锚定。这是一种工程上的诚实：承认 LLM 的上下文是有限且易失的，不假装它能记住一切。**