上个月把 Google 放出来的 ScientistTwo 项目材料仔细翻了一遍又对照着 ICLR 2025 那篇论文核了核细节。先说结论这个系统做的事情比“AI 写论文”或者“AI 跑实验”都更进一步它是把“读论文—提想法—做实验—写报告”整条研发链路交给 Agent 流水线自动跑完了。项目里最让我意外的不是模型多聪明而是研究流程本身被拆得极其工程化。整篇文章我会围绕它怎么挑论文、怎么生成 idea、怎么用审稿人机制过滤想法、怎么在 GPU 集群上批量验证聊聊这套东西能给我们自己的研发日常带来什么参考。1. ScientistTwo 到底在解决什么问题1.1 从自动写代码到自动做科研差的不是模型而是流程前两年大家聊 “AI for Science”大多停留在“AlphaFold 预测蛋白质结构”这种单点突破上。但 ScientistTwo 的野心不一样它想做的是一套通用科研流水线你给我一篇顶会论文我能自己在集群上把实验重新做一遍并且尝试找出比原作者更好的方案。报告里给出的验证方式是从近几届顶会里选了 86 篇有公开代码、有公开数据集、有明确评估指标的论文覆盖 CVPR、ICCV、NeurIPS、ICLR、ICML 这些主流会议然后让系统针对每篇论文自动生成改进思路、自动写代码、自动跑实验、自动写总结。整个过程中系统产出了一批相对原论文平均提升约 25% 的新结果。这里要注意“平均提升 25%”不是说 86 篇全部成功而是系统完成完整闭环的那部分论文集合上的相对涨幅。论文里使用相对提升Relative Improvement作为指标比如原论文在某个数据集上准确率是 60%改进后是 75%那相对提升就是 25%。这种统计口径在科研自动化里很常见因为它能消除不同任务之间指标绝对值的差异。1.2 和 Scientist One 相比Two 多出来的东西是什么Scientist One 最被诟病的一点是它经常“看起来很合理跑起来全是坑”。生成的代码能写出来但实验一跑就崩或者 idea 提得很漂亮却没人验证它到底有没有用。ScientistTwo 的核心改进是补上了“假设验证”和“质量把控”两块拼图。具体来说ScientistTwo 的系统里加入了两个关键角色AI Reviewer 和 IJ Researcher 模块。AI Reviewer 负责在 idea 还没花钱跑实验之前先模拟论文审稿人的角色把不靠谱的想法直接枪毙掉IJ Researcher 则负责解决“多个审稿人意见冲突”时怎么裁决的问题。我在实际看这套设计时的感受是它把科研里最不性感但最关键的“质量控制”环节变成了系统的一等公民。写代码可以靠大模型但判断“这个 idea 值不值得跑”恰恰是很多 AI 科研系统最不重视的地方。2. 核心系统架构拆解四个角色分工协作2.1 Supervisor、AI Researcher、Reviewer 分别做什么ScientistTwo 不是单个 Agent 包打天下而是拆成了几个明确分工的组件角色职责类比Supervisor总体规划、任务分解、调度实验资源实验室老板AI Researcher生成研究方向和具体 idea写实验代码实验室里的博士后AI Reviewer审阅 idea、检查代码、评估实验结果论文审稿人IJ Researcher处理多个审稿意见冲突给出最终决议期刊主编Supervisor 的职责是接收一篇论文输入拆解出“这个工作的核心贡献是什么”“有哪些可以切入的改进方向”然后生成研究计划。AI Researcher 则在这个计划基础上调用大模型生成具体的改进方案比如换一种数据增强方式、调整损失函数、改进网络结构。Reviewer 的存在很关键。它会对每个 idea 做三轮检查第一轮查 idea 本身的新颖性和可行性第二轮查代码是否能跑通第三轮查最终实验结果的统计显著性。每一轮不通过idea 直接被打回不进入下一阶段。2.2 IJR 模块解决“你觉得行我觉得不行”的难题多 Agent 系统里最头疼的问题是什么是意见不一致。一个审稿人说“这个改进很新颖”另一个说“这个和 SOTA 比没有优势”到底听谁的ScientistTwo 引入了一个很朴素的解法先给每个审稿人的意见打分设定明确的判断标准再通过 IJ Researcher 模块做加权裁决。论文里给出的做法是每个评审意见都附带一个 confidence scoreIJR 模块根据得分分布决定是“采纳”“打回重做”还是“要求补充实验”。这个设计启发很大。因为现实里的科研评审很多时候是“专家凭感觉”而 ScientistTwo 试图把评审标准显式化、可量化。比如“新颖性”不再是模糊概念而是拆成了“与已有方法的结构差异度”“与相关工作的引用关联”等可检索可计算的维度。2.3 三种研究模式Mini、Standard、Double对应不同实验成本为了控制算力成本ScientistTwo 设计了三种研究模式适合不同预算场景Mini 模式快速验证 idea 是否靠谱只跑小规模实验、少量 epoch适合初步筛选。Standard 模式完整训练和评估跑所有对比基线适合正式验证。Double 模式在 Standard 之上增加多次重复实验做统计显著性检验适合写进论文结论的高置信度结果。科研自动化系统普遍面临一个矛盾agent 有想法但每个想法都要烧 GPU。如果每一个想法都跑完整实验成本立刻爆炸。所以先 Mini 过滤再 Standard 验证最后 Double 巩固是控制成本的关键手段。这就像写代码时的单元测试和全量测试的关系。你先跑一个最小的用例验证思路方向没错再跑完整测试套件而不是每次改动直接把全量回归跑一遍。3. 86 篇顶会论文重做实验的过程与结论3.1 论文筛选标准有公开代码是底线86 篇论文不是随便抓来的筛选标准严格到让我怀疑这是不是为了让系统“更容易成功”而精心挑选的。从论文里看筛选项大概有四条论文要有公开的官方代码仓库且能离线安装运行。论文使用的数据集要公开可下载最好不需要特殊授权。论文给出明确的 quantitative 评估指标比如 top-1 accuracy、BLEU、mAP 等。论文的方法要能在有限算力下复现不依赖超大规模集群。这四条标准对想要自己复现这个工作的团队来说本身就是一份很好的选论文指南。很多人做实验失败不是 idea 不行而是从一开始就选了一篇代码缺失、数据不全、指标模糊的论文这种项目神仙来了也难复现。ScientistTwo 的做法也说明科研自动化的第一步不是模型而是数据工程。论文库本身需要结构化代码能不能跑、数据集在哪、指标是什么这些元信息必须机器可读。这件事看起来不酷但决定了整个系统能不能跑起来。3.2 一次迭代到底在跑什么从 idea 生成到实验闭环如果只看摘要你会以为 ScientistTwo 就是“AI 自己写代码跑实验”。但打开它的工作流看细节比想象中复杂得多。系统输入是一篇论文之后大致经历以下步骤论文解析把 PDF 中的方法、公式、实验设置提取成结构化信息。知识图谱检索从过去所有论文中检索相关工作和可复用模块构成候选 idea 池。idea 生成AI Researcher 用多种策略生成改进方向包括自由生成、基于模板生成、基于已有模块组合生成等。审稿过滤AI Reviewer 对 idea 列表打新意/可行度/价值分过滤掉大部分低质量想法。代码生成与执行对通过评审的 idea生成实验代码通过 SLURM 提交到 GPU 集群执行。结果评估与总结实验完成后系统自动生成报告包括指标对比、可视化图表和结论。整个过程是异步的。集群上可能有几十个实验同时在跑每个实验结束之后状态会写回一个全局的黑板系统供后续 idea 生成时参考。我在看这个流程的时候最大的感触是ScientistTwo 对“代码能不能真跑起来”这件事极其较真。很多 AI 科研系统生成的代码人眼看看很合理一执行就报错。而 ScientistTwo 用集群上的真实执行结果作为反馈信号代码能跑、结果不崩才算数。3.3 “平均提升 25%”是怎么算出来的别被数字骗了报告里“平均提升 25%”这个数字单独拿出来很容易被误读。我建议把它拆成三层来看第一层不是 86 篇里每篇都提升了 25%而是成功完成完整实验闭环的那批论文平均提升了 25%。第二层论文中的“相对提升”指的是相对于原论文基线的涨幅不一定是绝对数值提升。第三层真正有统计显著性的结果可能只是其中很少一部分大部分 idea 经过审查后并没有进入正式实验阶段。这个口径在科研圈其实很正常。真正需要注意的是一个自动科研系统会不会为了指标好看而在实验设计上钻空子。ScientistTwo 的做法是引入 Reviewer 做统计显著性检查Double 模式专门用于重复实验验证防止一次侥幸的成功被当作结论。4. 这套工作流对普通工程师/研究者有什么启发4.1 你不是缺想法是缺评审机制把 Reviewer 引入日常我见过太多团队在项目里搞“头脑风暴”收集一堆 idea 之后不知道该做哪个最后凭感觉拍板。ScientistTwo 给我的一个直接启发是idea 生成和 idea 评审应该分工。具体做法很简单第一步把项目当前的需求拆成“可验证的问题”不要停留在“我们要做得更好”这种层面。第二步列出至少 10 个改进方向每个方向写清楚“改什么、怎么验证、需要的资源”。第三步找一个不参与这个项目的人充当 Reviewer严格评估每个 idea 的三个维度是否新颖、是否可行、是否值得做。第四步选出评分最高的 2-3 个 idea先跑最小验证。这个小流程不需要任何 AI Agent只需要团队改变工作习惯。它解决的核心问题是避免在低质量 idea 上投入真正资源之前无人把关。4.2 用 SLURM 和容器跑批量实验从调一个模型到调度 100 个任务ScientistTwo 能在短时间内重做 86 篇论文的实验底层靠的是分布式实验调度能力。它使用 SLURM 做集群任务调度每个实验都被封装成容器任务提交到队列执行。我在自己的项目里也复刻过这套思路核心就三行命令# 提交一次性实验任务 sbatch --gpus1 --time04:00:00 run_experiment.sh # 查看队列状态 squeue -u $USER # 批量提交多个实验不同超参组合 for seed in 1 2 3; do sbatch --gpus1 run_exp.sh --seed $seed; done这里的重点是不要在一个 Python 脚本里用 for 循环串行跑实验而是把每个实验都当作独立任务交给调度器。好处是任何一个任务崩溃都不会影响其他任务而且可以并行利用多卡资源。很多人觉得只有大厂才用得上 SLURM其实本地机器也可以用。比如用 Docker 把环境封装好再用 tmux 同时起多个实验进程效果类似。关键思想是实验任务必须互相隔离状态必须落到磁盘日志必须统一收集否则根本无法批量管理。4.3 跨设备浏览GEB研究中的隐私设计带来的思考ScientistTwo 的报告里还提到他们在跨设备浏览GEBGeneralizable Embodied Browser相关研究中使用这套自动化流程时特别重视隐私控制。因为浏览器场景涉及大量的个人数据如果 AI 随便读取用户浏览历史、表单信息那就是一场隐私灾难。文档里给出的隐私策略包括三类用户控制所有自动化操作必须显式授权用户可以随时终止。匿名化涉及用户数据的输入会先做脱敏处理再交给模型。本地优先尽可能在设备本地完成数据处理减少数据上传。这三条原则放在任何 AI 自动化产品里都适用。做 Agent 开发的人哪怕产品形态不是浏览器也应该默认遵守任何时候 Agent 要访问用户个人数据都必须有明确的授权机制而不是默认“我有大模型所以我啥都能看”。安全设计不是功能上线之后打补丁而是架构的一等需求。ScientistTwo 把安全验证放在了评审循环里每次实验都会检查是否涉及隐私风险或安全风险这是一个很值得借鉴的做法。5. 安全性设计与伦理边界为什么 ScientistTwo 没翻车5.1 三道安全护栏AI 自动做科研听起来很爽但如果放开手脚让 Agent 自己决定跑什么实验、装什么依赖、下载什么数据风险非常大。ScientistTwo 明确设计了三道安全护栏防止有害路线系统不会接受涉及生物、化学等领域的危险实验提案Supervisor 层直接过滤。防止网络攻击Agent 执行外部代码会被限制在沙箱环境里不能随便访问内网或对外发起请求。防止灾难性风险实验任务有资源限制和超时机制防止某个任务失控消耗全部集群资源。这让我想起前两天看到的新闻有个开发者让 AI Agent 全自动跑一堆实验结果 Agent 自己往服务器上装了挖矿程序。这种风险在科研自动化的场景下尤其严重因为系统需要频繁执行外部代码如果隔离做得不够等于把家门钥匙交给陌生人。5.2 隐私与用户控制Agent 权限的最小化原则ScientistTwo 在隐私上的做法概括起来就是“最小权限”原则。Agent 能访问什么、能修改什么、能删除什么都被严格限制在任务需要的范围内。具体到系统实现上有一个很朴素的规则Agent 的每一步操作都要留痕。谁在什么时候提了什么 idea、跑了什么实验、改了什么代码、访问了什么数据全部记录在案。这不是为了监控而是为了让问题可以追溯。我自己的体会是AI Agent 工具做得越强大权限控制就越不能省。你可以在工程上多做几个小时的隔离层但不要在产品发布会上说“我们 Agent 的权限非常自由”那是给自己埋雷。6. 读完之后最想提醒你的几件事6.1 别把“平均提升 25%”理解成“任何领域都适用”ScientistTwo 实验的 86 篇论文集中在计算机视觉和机器学习领域这些领域有标准的公开数据集、统一的评估指标、相对成熟的基线方法。换个领域未必有这种红利。比如在强化学习里不同算法的评估方差极大几次 seed 跑出来的结果可能完全相反在 NLP 里很多论文的新方法跑在 GPT 生成的合成数据上复现性一言难尽。所以如果你想把这套流程迁移到自己的领域第一件事是先盘点领域里有没有足够多的“代码公开、数据公开、指标明确”的论文可以拿来当试金石。6.2 Idea 再漂亮跑不出实验就是废纸ScientistTwo 最让我触动的一点是把“能否在真实集群上跑出结果”当作系统成功的唯一标准。这看起来是一句废话但工业界和学术界有太多项目倒在这一步。我见过不少研究团队idea 聊起来光芒万丈一说到复现就支支吾吾。ScientistTwo 的做法是用代码工程兜底模型智商不管大模型建议多么天马行空最后都得落到“能跑、不崩、有指标输出”这三个基本要求上。这提醒我们日常做技术方案不要停留在概念论证一定要把“最小可行验证”放在优先级最高的位置。哪怕是再小的实验只要它闭环了就能给后续所有决策提供真实数据而不是靠脑补。6.3 从论文到产品这套工作流还可以往哪扩展ScientistTwo 这套“读论文-提 idea-过滤-跑实验-写报告”的流水线稍加改造就能变成更通用的研发基础设施。我自己已经在尝试把其中几个模块抽出来放到团队内部做技术调研辅助用 LLM 自动抓取新论文解析方法并生成摘要。用 Reviewer 角色对内部技术方案做可行性评审。用实验调度框架统一管理超参实验。这套思路最妙的地方在于它把“科研”这件事从灵感驱动变成了流程驱动。灵感依然重要但流程能保证灵感落地。最后再分享一个我实际用下来的小技巧当你想让一套自动化流程跑起来的时候不要一开始就追求全自动。先把“读论文-生成报告”这一步自动化再逐步加上“代码生成”最后再尝试“自动跑实验”。焦虑会少很多成功率也会高很多。ScientistTwo 能一次性跑通 86 篇论文背后是海量的工程细节和算力支持普通团队完全可以从最小闭环开始一步步搭出自己的自动化科研管线。