一句话判断
这篇值得读，而且我觉得它不是那种“再堆几个 agent 角色”的普通系统论文。它真正有价值的点在于：作者把 长程 ML research engineering 明确看成一个 系统协调 + 持久状态管理 问题，而不是单纯再提高局部 reasoning。
如果你最近在看 research agent、coding agent、multi-agent orchestration，或者你自己就在被“任务一长、上下文一断、agent 就失忆”这个问题折磨，这篇很值得深读。
这篇论文在解决什么问题
论文瞄准的是一个比“写几段代码”更难的任务：让 agent 在 数小时到数天 的时间尺度上，连续完成机器学习研究工程。
这里的任务不是一次性回答问题，而是要完整跑通：
- 理解论文或研究规格
- 搭环境
- 获取数据和模型
- 写代码
- 跑实验
- 根据实验失败继续 debug
- 再迭代优化
作者声称
作者认为长程 ML research engineering 难，不只是因为每一步本身难，而是因为这些步骤之间存在强耦合：
- 研究规格本身通常是 欠定的，很多实现细节没写全。
- 系统搭建负担很重，不只是“会写算法”。
- 反馈是 延迟的，很多错误要跑几个小时实验后才暴露。
- 真正难的是跨轮次保持 项目状态连续性，否则前面做的分析、代码、日志、失败原因很快会在后续 handoff 中丢失。
这个判断我基本认同。现在很多 agent paper 说自己能做长任务，但只要任务进入“环境配置 + 实验失败 + 多轮修补”阶段，系统就很容易退化成：不断重说背景、重复排查旧错误、或者把失败经验压缩丢失在对话摘要里。
核心方法：AiScientist 做了什么
AiScientist 的方法其实可以压成一句话：把控制做薄，把状态做厚。
论文里的原话是 thin control over thick state。我觉得这就是整篇最值得记住的设计主张。
1. 分层 orchestration，但顶层只保留轻控制
系统最上层有一个 Orchestrator，它不负责把所有细节都塞进上下文里，而是只保留：
- 当前阶段级决策
- 简明摘要
- 一个 workspace map
然后它把具体工作分发给不同 specialist，比如：
- 论文理解
- 任务优先级规划
- 实现
- 实验
- 通用 helper
我的判断
分层 orchestrator 本身不新，很多 multi-agent 系统都这么做。真正关键的是，这篇没有把“多 agent”当答案本身，而是意识到：如果所有协作都靠对话 handoff，层级再漂亮也会失忆。
所以它的重点不是“有一个 manager”，而是 manager 只做阶段控制，不背负厚上下文。
2. File-as-Bus：把共享工作区当成系统总线
这是论文最核心的设计。
作者提出 permission-scoped File-as-Bus workspace。直白说，就是让 agent 主要通过共享文件工件来协作，而不是靠一轮轮对话总结来传状态。
论文把 workspace 分成三类主要区域：
paper_analysis/：论文理解、目标指标、歧义点、实现相关细节submission/：真正的复现仓库，包括代码、配置、setup 脚本、资源下载逻辑、最终入口agent/：计划、执行日志、实验日志和实验输出
作者声称
作者认为，长程任务里最关键的中间状态天然就是“文件值”的：
- 分析文档
- 计划
- 代码
- 配置
- 日志
- 实验结果
与其不断把这些状态压缩成对话摘要，不如直接把它们保存在共享工作区里，让后续 agent 按需回读。
我的判断
这是我觉得整篇最强的部分。
它不是在追求一个更华丽的 communication protocol，而是在承认一个现实：长程工程任务的真实状态，本来就主要存在于工件里。
很多 agent 系统的问题，不是不会 reasoning，而是把真正重要的项目状态塞进了“脆弱的聊天上下文”。这篇的 File-as-Bus 其实是在说：
- 对话适合传轻控制
- 文件适合承载厚状态
我觉得这个判断非常对，而且迁移性很强。哪怕你不做 ML research agent，只做 coding agent / browser agent / internal ops agent，这个原则也经常成立。
3. Progressive disclosure：只先看地图，不先吞完整状态
AiScientist 不是让每个 agent 上来就把整个 workspace 全吃一遍，而是先生成一个 workspace map，让 agent 从“地图”开始，再按需读取具体工件。
我的判断
这个设计看似朴素，其实很关键。因为如果每次子 agent 启动都得吞完整项目状态，成本会爆炸，而且上下文仍然会持续膨胀。用 map 做导航接口，本质上是在做一种 状态索引层。
它不是替代原始工件，而是让 agent 知道“该去哪看”。这比把所有内容都塞进 summary 要健康得多。
4. 权限隔离与 append-only 日志
作者还强调了 permission-scoped coordination：不同 specialist 只对自己需要写的区域有写权限，共享日志按迭代附加记录。
我的判断
这点在 paper 里不算 headline，但工程上很重要。多 agent 系统经常有一个隐性问题：每个 agent 都能改一切，于是状态被互相污染。权限边界虽然不能解决全部问题，但至少能减少 cross-agent interference，让状态更可追踪。
关键实验结果
论文主要在两个 benchmark 上评测：
- PaperBench：从论文出发做完整复现
- MLE-Bench Lite：更偏 competition-style 的持续实验改进
实验观察 1：PaperBench 提升明显
论文报告：
- 在 PaperBench 上，AiScientist 平均分达到 33.73
- 相比最强匹配 baseline，平均提升 10.54~11.15 分（不同 backbone 下略有差别）
- 与论文里引用的人类强 baseline 41% 相比，差距被显著缩小
正文表 1 里可以看到，这个提升不是单个任务偶然拉高，而是在不少任务上都有效。
实验观察 2：MLE-Bench Lite 上达到 81.82 Any Medal%
论文报告：
- 在 MLE-Bench Lite 上，AiScientist 达到 81.82 Any Medal%
- 相比 best matched baseline，有显著提升
- 在 controlled evaluation 中，这个结果高于表中其他匹配比较系统
实验观察 3：File-as-Bus 的 ablation 掉点很大
这部分最关键。
论文给出的 ablation 结果是：
- 去掉 File-as-Bus 后，PaperBench 平均下降 6.41 分
- MLE-Bench Lite 的 Any Medal% 下降 31.82 个点
作者还强调一个细节：去掉 File-as-Bus 后，系统在“先跑出一个能提交的版本”上未必立刻全崩，但在后续 refinement 阶段掉得特别厉害。
我的判断
这是很有信息量的结果。
它说明 File-as-Bus 的价值，不只是让系统“能开始干活”，而是让系统在多轮实验和修补里 保住累积性。也就是：
- 先做出一个勉强可运行版本，很多 agent 也许都能做到
- 但要持续迭代、根据失败证据改进，状态连续性就变成主瓶颈了
这比只报一个总体平均分更能说明论文真正抓到的问题。
我怎么看这篇论文的真实贡献
1. 它把长程 agent 的瓶颈重新定位了
这篇最大的价值，不是“又一个 SOTA system”，而是把问题重心从：
- 局部 reasoning 更强一点
转向：
- 怎样让系统跨轮次稳定保留和使用项目状态
这对 agent 研究很重要。现在很多工作还默认瓶颈主要在“模型不够聪明”，但这篇的证据更像在说：很多长程失败，本质上是状态管理失败。
2. 它给了一个很可迁移的系统原则
thin control over thick state 这句话我觉得会比具体 benchmark 数字留得更久。
因为它不只是适用于 paper reproduction：
- coding agent 需要它
- browser / computer-use agent 需要它
- research assistant 需要它
- 企业内部的长流程 automation 也需要它
只要任务跨越多阶段、状态又主要沉淀在工件里，这个原则基本都成立。
3. 它比“纯多 agent 叙事”更诚实
很多 multi-agent 论文会让你觉得：只要角色拆得够细，系统自然会变强。但这篇相对诚实的一点是，它用机制分析说明：
- 多 interaction 本身不够
- 多 agent 本身也不够
- 关键是 interaction 是否建立在 durable project state 上
我觉得这比“我们有 orchestrator + worker + reviewer 所以更强”要更有说服力。
局限性与该追问的问题
1. benchmark 仍然是特定类型的长程任务
PaperBench 和 MLE-Bench Lite 都很难，但它们仍然属于相对明确的 ML engineering 任务。这里的状态天然适合文件化，所以 File-as-Bus 在这些 benchmark 上尤其吃香。
该追问的问题是：
- 如果任务更开放、更含糊，状态不那么自然地落在文件里，这个框架是否还同样有效？
- 对更强的人机协作场景，它是否会变成过度工程化？
2. hierarchy 的真实增益边界还可以再拆
论文表明 hierarchy 有贡献，但我觉得目前更强的证据仍然落在 File-as-Bus 上。分层 orchestrator 到底在多大程度上独立贡献了性能，和 durable state 相比哪个更核心，可能还值得更细消融。
3. 文件总线也可能带来新的管理成本
文件是 durable，但不意味着文件天然好用。随着项目变大，也会出现：
- 文件过多
- 命名混乱
- map 过期
- 旧状态污染新状态
- 日志膨胀
所以 File-as-Bus 不是“把东西写进文件就万事大吉”，它其实要求一整套更严格的工件组织规范。论文展示了原则，但工程细节还值得继续看 repo 和 appendix。
值不值得深读
我的结论
值得深读。
但我建议把它当成一篇 agent systems paper 来读，不要只当“又一个 benchmark 提升论文”。
建议优先看的部分
如果你时间有限，我建议优先读三块：
- 3.1–3.2：thin control / File-as-Bus / workspace map 的设计
- 4.4：File-as-Bus ablation 和机制分析
- 实现仓库：看看它的 artifact 组织和权限边界是不是工程上真能复用
最后一句
这篇论文最值得带走的，不是“研究 agent 又强了多少分”，而是一个更朴素但更关键的结论：
长程 agent 往往不是死于不会想，而是死于不会把项目状态持续、清晰、可回读地保存下来。
这也是为什么我觉得它值得读。因为它抓到的更像是长程 agent 的真实病灶。
