AiScientist 深度解读：File-as-Bus 如何让 AI 完成 24 小时不间断科研工程

# 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 的上下文是有限且易失的，不假装它能记住一切。**