这几天 AI 社区里热了好几轮的消息是 Google 那个叫 ScientistTwo 的科学发现系统它把 86 篇顶会论文描述的研究任务用自己的一套多代理流程“重做”了一遍整体平均提升了 25%。不少人看到“重做论文”“平均提升 25%”这几个字第一反应是“AI 要抢科研饭碗了”第二反应是“25% 是不是又是苏式灌水”。我完整读完论文之后反而冷静下来不少这两个数字确实不算亮眼的“通稿标题”但真正值得琢磨的是 ScientistTwo 把“多代理协作、本体知识图、验证器、RRT 风格规划”这四件事拧在了一起拧出的是一个以前很少被完整落地的“可验证科研闭环”。这篇文章不打算把论文公式复述一遍而是想从几个不同的视角拆给三类人听正在做科研的学生和老师、想把 agent 落地成产品的工程师以及那些对“AI 自动做实验”半信半疑的围观者。你会看懂它到底怎么做 86 篇论文的重做、为什么非要用图来推理、验证器在其中扮演什么角色以及我们普通人到底能从这套设计里搬走哪些能用的东西。1. 先聊聊“重做 86 篇顶会论文”是怎么个重做法1.1 它不是学术打假工具也不是“AI 读论文”那么简单很多人一听“AI 重做论文”会以为这是用来挑论文毛病、查抄袭的工具。ScientistTwo 干的事完全不是这个方向。它的做法是把一篇顶会论文当作一组已知的“初始条件”解析出研究背景、假设、方法、评估协议这些结构化元素然后在这个基础上让多个代理重新推导、替代建模、重新验证最终得到一个新的、可被验证的研究结果链条。打个比方这就像学校老师给了一套物理题的标准解答你不是照着抄答案而是重新站在出题人的角度把每一步性质和定理重新推一遍甚至找一条也能走通的新解法。而且每一步推完都要回到实验或者已有公理库里去“验算”验不过就重来。所以这里的“重做”本质上是在既有研究框架内做结构化再发现不是简单地把论文塞回大模型然后让它“续写结论”。1.2 顶会论文为什么是合适的“试验田”拿顶会论文来测试这套系统不是随便选的。顶会论文通常具备三个特点第一任务定义非常清晰有明确的数据集和评价指标第二方法描述相对完整因果关系较为紧凑第三难度普遍不低正是因为有了难度才需要模型去“重新设计实验流程”。这三点对自动推理系统来说价值极大。你想想要是拿一些模糊的、缺失数据的普通博客文章来做测试连验证器都无从下手又能验证出什么呢顶会论文天然就是高质量的结构化约束样本。从结果来看团队在这 86 篇论文上获得的平均提升约 25%并不是说每个任务都提升了 25%而是有的任务提升多一点、有的提升少一点、有的任务甚至持平。这个分布才是做科研该有的样子——一个具备自我反思能力的系统如果每篇论文都稳定暴涨那才更可疑。2. 从架构层面拆开 ScientistTwo 这只“葫芦”2.1 为什么不是“一个大模型干到底”如果你真的搭过 agent就一定遇到过这个困境把复杂任务丢给同一个大模型前面生成得漂漂亮亮后面在某个关键步骤上它开始一本正经地胡说。这就是单模型自驱动的“自我确认偏误”——它在生成回答时往往更倾向于延续自己刚编的逻辑而不是主动去寻找证伪自己的证据。ScientistTwo 走的是多代理竞合路线一个代理负责提出研究假设另一个代理专门负责找反例、挑逻辑漏洞还有代理负责从知识图里寻找可替代方法最后由验证器体系来“终审”。这种设计其实模拟了一个运转良好的科研小组有人大胆提想法有人毒舌质疑有人翻文献最后大家统一用证据说话。我刚接触这个思路时很不屑觉得“这不就是左右手互搏吗”后来在实践里发现只要给每个代理设定足够明确的边界这种竞争带来的信息增益远比单模型自言自语靠谱得多。当然前提是必须有个强有力的验证器兜底否则就是三个人在会议室里吵一整天没结论。2.2 基于本体的图推理给模型一张“学科地图”ScientistTwo 真正有门槛的设计是它的“基于本体推理”ontology-based reasoning。通俗讲它给系统准备了一张学科知识图谱和一套本体规则而不是像常见 RAG 那样只做文本片段检索。这里的本体不仅仅是“概念关系表”它更接近一套学科公理某个概念能作用于哪类问题、某类方法不能搭配哪种约束、哪些结论在领域内是不可证的。我把这两条路线对比了一下维度普通 RAG 检索ScientistTwo 的图推理知识表示向量化文本片段图结构 本体约束检索逻辑语义相似度匹配结构关系 邻域扩展结果一致性比较依赖上下文长度由本体规定可推导关系可解释性黑盒为主可追踪图谱路径对科研任务的适配度中低高为什么科研场景特别吃这套因为科学推理对“因果合法性”极其敏感。举个例子你要研究“某种新架构能否在小样本场景超越卷积网络”普通 RAG 会给你找来一堆高相似度的论文摘要但其中很多结论的成立条件是冲突的模型很容易捡到矛盾的证据而本体知识图会把“架构改变 → 样本量变化 → 统计效力变化”这条链路画出边界让代理只在合法的邻域内探索。说人话就是普通 RAG 给模型一根钓鱼竿图推理直接递它一张标注好“哪些鱼可以钓、哪些区域禁止靠近”的专属地图。2.3 验证器不是考官而是脚手架ScientistTwo 里验证器的分工非常细论文里大致包括领域验证器负责检查产出是否落在学科公理允许的范围内代码验证器负责把代理生成的代码真正跑起来跑一个输入看一个输出模型验证器负责把结论与目标评估指标对齐。这套验证器体系和代理是平级协作的不是高高在上的“答题卡判定官”。我见过很多团队做 agent 的时候把验证器做成一个“打分类”大模型最后效果就是花着最多的钱给幻觉盖了一层保险单。ScientistTwo 的做法其实在提醒我们验证器最好做成可执行、可断言、可量化的机制。尤其是代码验证器它毫不留情、不搞气氛跑不过就是跑不过。这样的验证器价值在于它给整个科研流程不断提供“负反馈信号”——AI 系统的自我改进靠的正是这种准确、及时、不过度反馈的惩罚信号而不是“我猜应该行”。3. 让论文“被重做”的两台发动机ReThink 与 RRT 规划器3.1 ReThink失败不是终点而是要拆开重组的起点论文里有一个我特别欣赏的机制简单概括成一句话不从头再跑只在断点重推。传统的 agent 遇到流程失败通常要么整段重来要么换上一条完全不同的提示词等着大模型“灵光一现”。ScientistTwo 的 ReThink 流程要严谨得多它先把研究路径拆成一张由推理节点组成的链如果某个节点上的验证失败了系统不会推翻全盘而是定位这个“最可疑节点”生成多个替代推导路径再逐步回溯验证。这套机制我第一次看的时候就很有共鸣。我自己做实验经常遇到这种状况某个模块准确率掉 5%你根本不知道是数据增强的问题还是模型结构的问题还是评测指标本身有误差。盲目调参就是纯耗卡。ScientistTwo 的做法相当于给 agent 装了一个“归因调试器”每次失败都精确到具体节点然后再围绕断点做局部重写。这恰恰是普通人做 agent 时最容易省略的一环——失败信号常常很有价值但前提是你知道它来自哪一步。3.2 RRT 风格规划从机器人路径规划借来的探索方法RRTRapidly-exploring Random Tree快速探索随机树原本是机器人路径规划领域的经典算法核心逻辑是在一个高维空间里随机撒点但每次撒点都偏向当前树中最靠近目标方向的节点逐渐生长出一棵覆盖可行空间的树。ScientistTwo 把这种思路移植到科学研究设想空间里每个节点是一个可被验证的中间研究状态新节点会产生候选实验方案验证器负责过滤非法节点。用研究场景类比一下研究生刚开始探索课题时通常是在一个极大规模的想法空间里瞎转最怕的就是“虚假希望”——跑一个方法跑了很久才发现它根本不 work。RRT 的意义在于它迫使系统每次只扩展一小步、每步都进行合法性检查、并持续向目标方向倾斜这样既不会因为随机撒点浪费太多探索成本也不会因为路径过于直线而错过邻域里的好方案。它是偏向“足够好就逐步靠近”的实用主义搜索不是在论文里渲染出来的高深算法。3.3 把“重做 86 篇”当作持续的实验迭代“重做 86 篇论文”不是一次性事件它在论文里更像是一个持续迭代的闭环系统每重做一批论文知识图和代理策略就会更新一轮下一批任务开始之前它已经带着上一轮的验证器经验了。这意味着 25% 的平均提升不能说完全归功于单个任务上的推理能力它同时包含了系统自我演进带来的增益。这种“用任务反哺系统”的思路对做智能体的朋友尤其重要——你看那些做得好的 agent几乎都不是一次性 prompt 的胜利而是用一批真实任务把验证器、规划器、知识库一起磨出来的结果。所以如果你想在自己的场景里复刻这种能力不要一字不差地把整套图推理搬过来而是先想清楚两件事第一你的任务里哪些步骤是可以编程验证的第二你的历史任务数据能不能形成持续反馈。只要这两个环路建立起来哪怕是最简单的“生成-验证-归因-重生成”循环也能比大多数单次调 prompt 的方案稳定得多。4. 从 ScientistTwo 里三类人分别能搬走什么4.1 如果你是科研人员把“验证器思维”引入日常工作我强烈建议研究者读这篇论文时把关注点从“AI 会不会取代我”挪到“AI 帮我重新定义实验闭环”上来。很多科研新手卡住的点是他们只会做实验不会写“可验证的判断标准”。你回想一下是不是经常准备了半天、跑了一整天实验最后却靠“感觉这结果还行”来决定下一步ScientistTwo 的第一启示就是任何结论都得配一个显式可执行的评估函数最好是一段代码、一个数值指标而不是一句“肉眼可见有效”。这个启发可以直接落地你写论文、做实验之前先花 10 分钟定义清楚“哪些结果算合格、哪些算失败、哪些边界情况需要单独测试”。这 10 分钟能救回你未来两个月的糊涂账。4.2 如果你是 AI 工程师从“生成器”走向“代理工程”ScitistTwo 是一个活生生的多代理工程范本。普通 agent 开发者最容易掉进的两个坑第一是把所有逻辑塞进一个系统提示词里第二是不做任何模块隔离。ScientistTwo 其实给了我们一个更健康的模块划分范式生成、质疑、检索、验证各自独立每一块都有专门代理或验证器负责单点能力可以单独替换升级。我在项目里完全照搬过这个思路只做了一个改动把原来的“裁判大模型”替换成一组无情的单元测试脚本。结果效果立竿见影——多代理之间的争吵大幅减少因为大家终于有了共同认可的客观基准。如果科学家团队让两个 agent 争论一个实验方案争论到最后往往由“跑一下代码看看结果”来终结这在现实中同样有效。4.3 如果你是产品负责人把它当作“探索加速器”而非“自动论文机”如果你拿着 ScientistTwo 的 PPT 去问老板“我们能不能自动化生成论文”大概率会踩雷。因为当前阶段这套系统更适合的场景是在限定支架内快速探索可行方案而不是取代研究者定义问题。就好比搜索引擎极大提升了资料收集效率但它不会替你决定研究什么。ScientistTwo 这类科学 agent 也是一样它能替代的是重复推导、验证、检索这些高成本动作而“提出什么样的问题值得被验证”仍然是人类的核心工作。如果你是负责人更合理的预期是它能把“从研究想法到初步验证”的时间从几个月压缩到几周。但前提是你得先投入成本把知识图谱、验证器、数据接口维护到位这本身也是一笔不小的工程投入。5. 复现和借鉴前的避坑清单5.1 常见问题速查表症状可能原因解决思路多个代理反复辩论不出结论缺少仲裁机制或轮数上限引入外部验证器给足轮数上限验证器给出的结果前后不一致验证规则定义过松把验证标准收敛为可执行脚本图推理检索结果明显过时本体知识图长期未更新建立图谱定期增量更新机制代理生成结论不可执行只跑文本生成、缺代码执行强制每条结论关联可执行代码系统整体成本太高多代理都调用满血大模型用便宜模型处理旁支验证器区间裁剪这是我踩过不少坑之后总结的一张“急诊表”。其中最想强调的一件事验证器的可靠性优先于验证器的复杂度。宁可先只验证 30% 的硬指标也不要搭一个什么都认的大语言模型裁判后者会让整个 agent 项目的“信任基础”塌掉。5.2 四个最小可落地的实践建议如果你既没有团队也没有大量算力我建议从这四个小步骤开始按顺序做基本都能把 ScientistTwo 的核心思想复刻到你的小项目里挑一个你熟悉的小领域先用结构化 JSON 或者图谱文件建一张覆盖二三十个关键概念的微型“知识图”只描述“概念-关系-约束”三层。两个代理参与协作一个负责提方案另一个专门挑毛病每次辩论不超过三轮。第三位“裁判”不用大模型而是一个可运行的脚本直接基于你定义好的指标打分。开始时手动记录失败模式每积累十条失败就在 prompt 里增加一条对应规避规则。这套流程大约三百行代码就能搭起来但它完整包含了 ScientistTwo 的核心闭环竞争性的假设生成、结构化知识约束、可执行验证器、基于失败反馈的改进。5.3 预算紧张时怎么控制推理成本最后提一块很容易被忽略的现实问题ScientistTwo 这种架构如果完全照搬Token 消耗是非常吓人的。多代理并发调用、知识图检索、多轮验证每跑一轮都是一笔不小的开销。我的实操经验是按比例分层使用模型常规领域搜索和上下文整理用便宜的小模型关键推理和验证生成才动用强模型同时在验证器里优先做断言式快速暴毙先过滤掉 80% 的无效候选再强调把有价值的候选送进昂贵的大模型分支。这样设计下来整体系统只要能在“有效探索率”上保住底线即便经费有限也能把 86 篇论文那种批量化重做实验的节奏跑到自己场景里。我个人读完 ScientistTwo 最深的体会倒不是那个 25% 的数字。数字再好也要有足够严格的定义、验证器、任务约束在前面守着。它更像是一个提醒凡是能重复推导、能被验证器背书的科研环节都会慢慢自动化而提出值得验证的问题、构建可靠的验证标准才是人类研究者真正要发力的地方。换句话说想清楚“什么才算有效结果”的人现在比以往任何时候都更值钱。