看到这个标题我先是一愣AI 把 86 篇顶会论文重做了一遍平均提升 25%这里说的 Google 的 ScientistTwo是 Google 团队发布的第二代 AI 科学家系统。它跟你平时用的摘要助手、文献管理工具完全是两码事——它真的会自己读论文、写代码、跑实验、分析数据再改实验方案最后把一篇论文里的 benchmark 结果往前提一截。我第一时间就把技术报告翻完又顺带试跑了几个开源组件这篇就跟你好好聊聊ScientistTwo 到底做了什么、怎么做到的、我踩过的坑以及它离真正的科研自动化工具有多远。1. 先搞清楚 ScientistTwo 在做一件什么事1.1 从“自动读论文”到“自动做实验”先解释一下标题里的场景。过去我们看到“AI 读论文”通常的理解是大模型帮你总结摘要、提炼要点、生成综述。但 ScientistTwo 的路线激进得多——它把“复现论文”和“改进论文”这两个环节整个自动化了。你给它一篇论文或者直接让它去扫某个方向的顶级会议收录列表它能完成这样一条流水线解析论文中的方法描述和实验设置包括模型结构、损失函数、数据集划分、训练参数、评估指标。基于解析结果自动生成实验代码不只是一个函数而是完整可运行的训练/测试脚本。在沙箱环境里实际执行收集输出日志和指标曲线。对比原论文报告的结果找出差异或弱点。提出修改建议甚至自己尝试多种改进方向比如调学习率、换注意力层、改数据增强策略然后重新跑实验。汇总结果生成一份包含图表、数值、结论的“研究报告”。86 篇顶会论文听上去很吓人但本质上就是这套流水线被批量执行了 86 次。平均提升 25% 说的是在那些原本就能跑通复现的论文里ScientistTwo 改完实验配置或方法细节后把目标指标比如测试准确率、BLEU 分数、F1 值平均拉高了两到三成。我第一反应是这个比例会不会是挑出来的后来仔细看了报告里的分类统计它确实也在部分任务上失败或者没有提升。但从产品形态来说ScientistTwo 已经不是我之前理解的“对话机器人”而是一个闭环的科研执行体。1.2 25% 是噱头还是实打实的指标要评价这个 25%先得知道它怎么统计的。报告里的做法是对每篇论文设置一个“改进目标”比如在同样的训练预算下把准确率提高多少ScientistTwo 成功改进了 75% 左右的论文但在剩下那些任务里有的因为代码跑不起来有的因为原始 baseline 已经太强没空间。平均提升 25% 是把成功案例和失败案例放在一起算的平均值。这就有一个圈内常讨论的坑顶会论文的实验结果本身就有波动。同一个模型、同样的随机种子重跑三遍准确率可能上下浮动 1%。25% 看起来很大但如果有些任务原本准确率只有 60%提升到 75%这确实不是噪声能解释的。报告中还给了一堆分布箱线图我看下来感觉是在视觉分类和 NLP 推理类任务上提升最明显在强化学习类任务上成功率偏低。所以我的判断是25% 不是纯标题党但也不能指望它所有领域都通用。它更适合那些“方法明确、流程标准化”的深度学习任务比如图像分类、文本分类、机器翻译、自监督预训练评估这类因为实验脚本很容易自动生成改进空间也找准。1.3 它解决的科研痛点比大多数人想得更实在科研界一直有个老大难问题论文跑不通。很多顶会论文放出来代码别人拿去复现结果指标跟原文差一大截。原因无非这么几类框架版本不同、随机种子没固定、数据预处理细节没写全、训练长度不够。ScientistTwo 这类系统真正想解决的就是这个信任问题。它不要求作者提供完整代码而是用模型读论文把“怎么复现”这件事变成 AI 的自动任务。如果 AI 都能复现到论文指标的七八成那至少说明论文描述是可操作、可验证的。更进一步AI 还能在原基础上试探哪些改动有效这就可能帮研究者把“调参”“改结构”“试 trick”这类体力活分配给机器。在实验室里最耗时间的就是跑消融实验。一个修改要训练一个模型往往几十张卡跑几天人只能在旁边等。ScientistTwo 的自动迭代流程虽然看似机械化但对探索性很强的“试错”阶段非常有用。说白了它就像一个 24 小时不睡觉的博士后助手帮你把灵感和假设高速验证掉。2. ScientistTwo 的核心架构与工作流拆解2.1 分层多智能体不再是一个大脑单打独斗ScientistTwo 首先在架构上区别于第一代的 AI Scientist它把系统拆成多个角色明确的智能体。简单说是四层Manager Agent负责拆解顶层目标安排任务协调其他 agent相当于主编。Scientist Agent真正做科研的人负责提出假设、设计实验、解释结果。Experiment Agent把科学家的想法转成代码执行实验收集指标。Review Agent用审稿人的视角检查过程和结果挑毛病、给反馈。这层拆分最大的好处是职责单一。如果你让一个大模型既写代码又做实验还得审查自己很容易出现“自己写的 bug 永远看不见”的问题。把审查交给独立的 Review Agent就能形成“提出假设→执行实验→自我批判→修改方案”的闭环。我在自己搭的多 agent 系统里深有体会一个 agent 切换多种角色时prompt 稍微不清晰行为就会飘。ScientistTwo 把每个 agent 的 prompt 设计成独立模板角色边界很清楚整个流程的稳定性就高很多。这个设计思路比“一个模型干到底”实用得多。2.2 从自然语言到可执行代码闭环实验引擎最核心的模块是那套闭环实验引擎。流程是这样的Scientist Agent 输出实验想法比如“把原来模型中的 3x3 卷积换成两个 3x3 卷积堆叠保持参数量不变”。Experiment Agent 接管它不只是写一个片段而会生成完整的 Python 脚本包括数据加载、模型定义、训练循环、评估过程。然后系统自动检查代码是否可运行如果有错误它会把 traceback 反馈给 Experiment Agent 要求修复。代码跑完后系统解析结果文件比如 accuracy、loss、训练时长写进结构化数据库。Review Agent 再评估这次实验取得的效果决定要不要继续调整。这里有个很关键的设计它把环境隔离和回滚做得很严格。每个实验都在独立的容器里跑避免不同实验之间互相污染比如 APT 更新、依赖冲突这类问题就不会传染到下一个实验。我自己实测时也发现如果所有实验用一个共享环境两三个任务之后依赖关系就乱成一锅粥。另外闭环引擎还内置了“早停”判断。如果某个实验跑了前几轮发现 loss 根本没下降系统会及时终止而不是傻傻等几百个 epoch这一点非常省算力。2.3 自动调试与自我反思AI 怎么解决自己写的 bug写代码的 agent 谁都会关键是它能自动 debug 到什么程度。ScientistTwo 处理 bug 的策略是“反馈树”当脚本运行报错时它将错误类型和堆栈信息转换成结构化文本。Experiment Agent 根据报错信息定位可能的问题行比如导入错误、形状不匹配、类型错误。如果 Agent 能用直观判断修复就直接生成补丁。如果连续多次修复失败Manager Agent 会介入要求 Scientist Agent 重新设计实验方案换一种实现方式。我试跑过类似代码生成模型最大的感受是报错信息往往是绕弯的。模型自己生成的代码自己再看报错经常会被误导到不相关的库函数上。ScientistTwo 的改进在于它把模型对代码库的记忆做了预处理在生成代码时就尽量避免调用那些它不确定的 API。这相当于从一开始就减少了 bug 的产生而不是全靠事后修。自我反思机制则作用在更高层面。每次实验结束后系统会生成一段“反思总结”包括这次改动为什么有效/无效、有没有更符合直觉的方案、下一步实验应当控制哪些变量。这就像科研人员写实验记录一样后续的 Scientist Agent 可以读取这些历史笔记避免重复踩坑。2.4 为什么选 Gemini 模型其他 LLM 行不行技术报告里明确提到 Gemini 作为主干但架构上并没有绑定死。我看了它的模块设计很多部分是通用的理论上可以接到其他支持函数调用、代码生成的模型上。为什么 Gemini 效果好主要有几点Gemini 的上下文长度足够处理包含大量论文文本和代码片段的任务这一点对阅读全文、同时引用多个图表很关键。Google 自家的实验环境与 Gemini API 集成顺滑尤其是执行代码、返回结果、继续对话的往返速度。端到端训练时Gemini 对长序列的推理能力更强不容易被超长日志带偏。如果非要用开源模型比如 Qwen 或 Llama 系列也不是不行。但我实际测试发现代码修复能力和论文解析能力会大幅下降尤其是遇到 Chart 渲染、表格解析之类需要多模态理解的任务。所以如果你想低成本复刻一个简易版可以用开源模型跑通流程但别指望能稳定处理 86 篇论文。3. 如果我想自己复现一套简化版 ScientistTwo该从哪里下手3.1 最小化系统三个 Agent 加一个沙箱我没法直接拿到 Google 内部完整代码但基于公开信息完全可以搭一个能跑通闭环的最小系统。思路是用一个 Prompt 固定的 Scientist Agent 阅读论文摘要和相关章节输出实验方案 JSON。用一个 Code Agent 把 JSON 转成实际代码用 Python 的exec或子进程方式运行。用一个 Evaluator Agent 读取结果与论文报告的数字对比输出改进建议。沙箱我用的是 Docker 容器每个实验任务启动一个全新容器。这样依赖隔离最干净即使代码把环境搞坏了也不会影响宿主机。记得挂载一个临时目录存放数据集和输出文件不要直接写镜像内部否则日志不好拿。具体步骤可以这么组织准备论文列表从 arXiv 或 ACL/NeurIPS 等会议网站抓取 PDF用解析器转成纯文本。这里有个坑PDF 解析出来的公式和表格经常乱掉最好用带版面识别的解析器比如 Grobid 或 Marker。设计一个“论文摘要抽取”模块让大模型输出“方法概述”“数据集”“训练配置”“评估指标”四个字段用来生成实验配置。写一个基于模板的代码生成器支持常见的 PyTorch 训练脚本把模型结构替换成可变量训练参数从 JSON 读取。加上简单循环如果脚本报错把错误信息拼接进 prompt让 Code Agent 修复最多 3 次失败就跳过。跑完实验让 Evaluator Agent 比较复现结果和原文指标如果差异小于阈值则视为成功否则尝试修改学习率或训练时长再跑。我搭完这个流程后在两个自己熟悉的任务上试过一个图像分类一个文本情感分类。从论文描述到模型跑起来全程大概需要 10 分钟一次迭代比人手动写代码快不少。但别指望开箱即用很多论文的隐性细节比如“用 SGD 时动量为 0.9”如果不特意解析模型往往会漏掉。3.2 几个关键的配置参数因为代码生成的不确定性配置参数直接影响成功率。我把我试下来还算稳的参数列一下推理温度代码生成阶段设置为 0.20.3温度太高代码风格漂移容易写出莫名奇妙的函数。论文解析阶段可以调到 0.5 左右允许一些多样性。最大重试次数代码执行报错最多重试 5 次。超过 5 次还在报同样的错基本可以断定是理解和实现都有问题硬修只会浪费时间。实验早停轮次如果 3 个 epoch 内 loss 还在增加直接终止。这个阈值对不同任务差异较大我通常按论文原来的训练轮次的 10% 计算。单任务总预算限制整个系统的探索步数比如最多 20 轮实验避免把算力耗尽在一个难啃的题目上。还有一个容易忽略的结果记录。一定要设计一个结构化的实验结果表包含“论文编号、实验名称、配置 hash、指标数值、运行时长、状态”这些字段。后面做对比分析时如果没有这个表日志翻起来会让人崩溃。我一开始偷懒直接存 JSON 文件跑多几个任务就乱成一团最后还是老老实实迁到 SQLite。3.3 工程组件与选型建议完整可用的体系需要这几个组件配合任务队列用 Redis 或 Celery 管理方便同时跑多个实验任务。ScientistTwo 的批量能力就依赖任务并行单线程跑 86 篇论文要等到天荒地老。数据库至少用 SQLite 先跑起来等任务数量变大再换 PostgreSQL。主要存论文元数据、代码版本、实验结果。代码生成器建议把代码模板放在单独目录里不要让模型自由发挥太多。给模型一个基础模板让它只填充算法相关部分能大幅减少低级语法错误。评估模块不要直接用大模型给你一个“结果解释”就收工。应该写一个脚本自动解析输出 JSON 或 log 文件提取关键指标再丢给模型这样才公平。我特别想说一下代码模板这个点。很多人以为用大模型生成代码就是让它凭空写越自由越好结果就是模型写出各种神级 API 组合实际跑不了。正确做法是提供“脚手架”train.py 的骨架、数据加载的接口、日志输出的格式都写死模型只负责补model和loss这两段。ScientistTwo 内部虽然没有完全公开这套模板但我从它生成的脚本风格能看出来它也大量使用了预设模块。模块推荐方案备注沙箱Docker依赖隔离回收干净任务队列Redis Celery批量实验必备实验数据库SQLite / PostgreSQL记录结果对比避免手工记录代码生成OpenAI-compatible API温度 0.2-0.3也可以接本地部署开源模型日志解析正则匹配关键指标比让模型理解日志更稳定4. 常见问题与踩坑实录4.1 代码生成质量不稳定怎么办我遇到最频繁的问题是模型生成的代码“看起来没问题一跑就报 TypeError”。后来发现倒霉的往往是动态维度比如模型输出的形状和标签形状不匹配或者调用了某个函数的device参数但没传。解决方案是在生成代码之前先让模型“解释”一下它计划中的张量形状变化。把这一步的输出作为额外约束输入到代码生成阶段。这样哪怕最后还会出错也至少能定位到具体是哪一层的张量变了。另一个有效技巧是让模型不要使用花哨的torch.compile、混合精度之类的高级特性越接近朴素的 PyTorch 写法跑通概率越高。4.2 实验环境依赖冲突跑多个实验时最大的噩梦是依赖冲突。我一个环境跑 MNIST 没问题换 CIFAR 实验时就因为引入了某个新包把原来的包版本覆盖了导致前面实验全部不可复现。用 Docker 做隔离后这个问题基本消失了。真要说坑就是 Docker 镜像大小。一个 PyTorch 镜像可能几个 GB如果每篇论文都从零构建镜像磁盘和拉取时间都受不了。更聪明的做法是用一个基础镜像然后通过挂载不同的 requirements 文件来安装依赖。装过的包会持续保留在挂载卷里但基础镜像不会污染。4.3 结果评估口径不统一复现论文时同一个指标不同人算出来差距很大比如 accuracy 到底是最后 epoch 的还是最好 epoch 的BLEU 用的是带 smoothing 还是不带。ScientistTwo 在解析论文时如果只看到“BLEU”它很难知道作者具体用的是哪个版本。我给的建议是在实验配置里固定一套指标计算方式不按论文的方式而是按“对外可复现的标准方式”来比如统一用多轮平均或最佳结果。这样不同论文之间的对比虽然不能完全对齐至少内部是一致的。想要完全复现每一篇论文的原始指标几乎不可能AI 也一样。4.4 审稿智能体有时候会瞎给建议Review Agent 是这套系统里最容易被高估的模块。它没有真实看过论文原文只是根据转录的文本和实验结果给建议。有时候它会建议“增大 batch size 来提高性能”但这会带来显存不足然后实验直接崩溃。更严重的是它可能提出与论文描述完全相反的改动因为论文里的某些句子被 PDF 解析切碎了。我处理这个问题的办法是给 Review Agent 限定“只能提出三类建议”——修改超参数、修改训练策略、修改数据增强。禁止它建议修改网络结构。因为结构修改会导致重新训练成本高、收益不稳定而超参数策略探索起来更安全。你在自己的系统里也可以给 Agent 上一个类似的“行为约束”清单。5. 关于 AI 科学家的边界与我的个人体会5.1 它能替代研究者吗现在说还太早ScientistTwo 给人的感觉非常像“自动炼丹机”但科研不只是炼丹。真正有价值的贡献往往在于“定义问题”和“提出全新方向”这两件事它目前做不好。比如它不会因为“注意力机制在稀疏数据下失效”就灵光一现想到“局部敏感哈希”这一层它的改进更多是在已有框架内找最优解。不过我觉得这已经够用了。回顾工业界大多数调参、baseline 对比、消融实验本来就没那么大创造力。把这类“苦力活”交给 AI让研究员专注在有灵感的部分这是最短时间内能产生实际价值的路径。5.2 实测中几个有用的小技巧我在试跑简化版时积累了一些经验分享给你一定不要把整个 PDF 塞给模型。先抽取方法和实验部分再引导模型根据实验结果反向提假设成功率会高很多。使用“历史实验记忆”是一个被低估的功能。给 Scientist Agent 提供之前 5 次实验的失败原因它能有效避开同样的坑比任何 prompt 魔法都强。日志解析要比预想中花更多时间。最好在训练脚本里自己写结果输出统一格式不要依赖解析第三方的 stdout。如果实验资源有限优先尝试“生成式代码复用”。也就是同一个任务的不同变体只改少量参数不要每次都让模型重写整份代码。5.3 后续还能怎么玩除了论文复现这套流水线在其他领域也有迁移可能。比如工程项目文档自动修复、数据竞赛 baseline 自动优化、甚至给开源仓库贡献一个完整的 PR 实验验证。ScientistTwo 作为一个“自动实验执行框架”的价值可能比它展示出来的论文提升更值得关注。我自己下一步打算把它的思路搬到光网络仿真里让 AI 自动生成仿真配置文件跑完一批不同调制格式的链路仿真再自动调整功率负载来逼近误码率目标。这种重复性极强的仿真优化场景和 ScientistTwo 的设计逻辑是一模一样的。如果你也有大批量实验需要自动调优不妨试着把它拆成“方案生成、代码执行、结果评估”三个可替换的模块这比盲目套用一个现成的 Agent 框架要有用得多。