1. 当科研被拆成一条流水线FARS到底在做什么第一次看到FARS这个词是在一个做多智能体方向的朋友群里。有人甩了张截图说这玩意儿把文献调研、假设生成、实验设计、代码跑通、论文初稿全串起来了底下跟了一串真的假的。我当时的第一反应是又是一个把几个API拼起来就敢叫自动化科研的玩具。但仔细扒了一圈它的设计思路之后我改主意了——它真正有意思的地方不是能不能一键出论文而是它把科研这件事拆成了一条可编排、可回滚、可审计的流水线。先把话说在前面FARS不是一个输入标题就吐出一篇SCI的魔法按钮。任何宣称能做到这一步的东西要么在骗你要么在骗审稿人。FARS的本质是一套多智能体协作框架它把一项研究工作拆解成若干个子任务每个子任务交给一个带有特定角色设定的智能体去执行智能体之间通过共享的上下文和产物进行交接。你可以把它理解成一个虚拟课题组有人负责查文献有人负责提假设有人负责写实验代码有人负责挑刺还有人负责把前面所有人的产出缝合成一篇结构完整的稿子。这套东西为什么现在能火起来得放到大背景里看。过去两年大模型在单点任务上的能力已经足够强——写代码、读论文、做数学推理单拎出来都能打。但科研的难点从来不在单点而在于长链条的连贯性你读了一篇论文产生的疑问要能转化成可验证的假设假设要能转化成可执行的实验实验结果要能反过来修正假设最后还要把整个过程写成别人能复现的文字。这条链上任何一环断了整件事就废了。FARS这类多智能体系统的价值恰恰在于它试图用工程手段去兜住这条长链让每一环的产物都结构化地传给下一环而不是靠一个人或一个模型从头记到尾。所以这篇文章我不打算写成FARS的使用说明书那种东西官方文档里都有。我更想聊的是如果你真的想用多智能体系统去做点科研相关的事哪些环节是真正决定成败的哪些坑是几乎每个人都会踩的以及这套东西的能力边界到底在哪。适合的读者是对AI Agent有基本概念、想把它用到实际研究或工程场景里的人以及那些被自动化科研这个词吸引、但还没搞清楚它到底能干嘛的人。2. 多智能体协作的骨架角色分工比模型能力更关键2.1 为什么一个全能Agent注定跑不通长任务很多人第一次尝试自动化科研思路都很朴素找一个上下文窗口够大的模型把任务从头到尾丢给它让它自己一步步想。我早期也这么干过结果非常稳定地失败。失败的原因不是模型不够聪明而是长任务的误差会累积。假设每一步有95%的正确率20步之后整体正确率就掉到36%了。科研流程动辄几十个决策点单Agent串行执行几乎必然在中途跑偏而且跑偏之后你根本不知道是哪一步开始错的。多智能体的第一个价值就在这里把长链切成短链让每个智能体只对自己那一小段负责。FARS的设计里文献调研Agent不需要懂怎么写实验代码实验Agent也不需要重新去读一遍所有文献——它只需要接收上游传来的结构化产物比如假设H1在X条件下Y指标会提升Z%然后专注把这个假设变成可运行的验证方案。责任边界清晰了误差就不会无限制地往下传。但这里有个反直觉的点角色分工的粒度比模型选型更影响最终效果。我见过太多人花大量时间纠结用哪个模型却把角色设计做得极其粗糙比如只分研究员和写手两个角色。这种粗粒度分工本质上还是单Agent思维只是换了个壳。真正有效的分工应该按照认知负荷的类型来切需要发散的是假设生成需要收敛的是假设筛选需要严谨的是实验设计需要批判的是结果审查。这几种认知模式互相冲突塞进一个Agent里必然互相干扰。2.2 FARS式角色编排的典型结构基于我对这类系统的观察和实际搭建经验一个能跑通科研长链的多智能体编排通常包含这么几类角色它们不是简单的流水线而是带有反馈回路的角色核心职责关键产物常见失效模式调研Agent检索、筛选、归纳文献结构化文献卡片检索词发散导致噪声过大假设Agent基于文献缺口生成可验证假设假设列表验证标准假设过于宏大无法证伪批判Agent对假设做可行性/新颖性审查审查意见淘汰理由过度保守扼杀所有想法实验Agent设计并执行验证方案代码运行日志结果环境依赖缺失导致跑不通写作Agent将全流程产物组织成文稿结构化初稿把过程日志当结论写这张表里最容易被低估的是批判Agent。很多人搭系统时会觉得多一个挑刺的会拖慢进度直接省掉。但实测下来没有批判环节的系统产出的假设90%是废话——要么是用更大的模型效果更好这种正确的废话要么是根本无法在有限资源内验证的空想。批判Agent的作用不是否定而是把不可执行的假设提前拦下来避免后面所有Agent在一个注定失败的方向上白干。2.3 智能体之间的交接协议才是真正的技术活角色分好了下一个问题来了Agent之间怎么传话这是我认为整个多智能体系统里最被忽视、也最决定成败的环节。如果交接的是自然语言比如调研Agent写一段话给假设Agent那么信息在传递过程中会不断失真——假设Agent可能误解了文献里的关键条件实验Agent又可能误解了假设的边界。传个三五轮原始意图早就面目全非了。FARS这类系统做得比较聪明的一点是强制结构化交接。每个Agent的输出不是一段散文而是一个带有固定字段的对象。比如假设Agent必须输出这样的结构{ hypothesis_id: H1, statement: 在数据集D上方法M相比基线B在指标X上提升至少5%, rationale: 文献[3]指出...但未验证..., falsification_condition: 若提升小于2%则假设不成立, required_resources: [GPU:1, 数据集:D, 基线代码:B] }这种结构化交接的好处是双重的。第一下游Agent拿到的是无歧义的输入不需要去猜上游想表达什么。第二整个流程变得可审计——你可以回溯每一个假设是怎么来的、被谁审查过、最终实验结果如何。这一点对科研场景尤其重要因为科研的本质要求就是可追溯、可复现。提示如果你自己搭多智能体系统哪怕不做科研也强烈建议在Agent之间用结构化数据交接而不是自然语言。自然语言交接在3个Agent以内还能凑合超过5个必然乱套。3. 从假设到可运行实验自动化科研最容易断链的地方3.1 假设生成不是让模型多想几个点子假设生成这个环节外行看起来最简单——不就是让模型根据文献提几个想法吗但真正做过研究的人都知道好的假设是稀缺品而看起来像假设的废话是过剩品。我拿FARS式的流程跑过一批文献让它生成假设结果前几轮产出的东西基本没法看典型的有使用更大的模型可以提升性能——这是常识不是假设。结合方法A和方法B可能有效——没有说明为什么结合会有效也没有说明在什么条件下有效。在更多数据上训练会更好——无法证伪因为更多没有边界。问题出在哪出在假设生成Agent缺少约束。一个没有约束的发散过程必然滑向最安全、最平庸的表达。后来我调整了策略给假设Agent加了几条硬约束效果立刻不一样必须指明对比对象假设不能是X有效而必须是X比Y在条件Z下更有效。必须给出可量化的证伪条件如果什么结果出现就说明这个假设错了。必须引用至少一篇文献作为出发点假设不能凭空产生必须建立在已有工作的缺口上。必须声明所需资源如果一个假设需要1000张GPU跑一个月那它在当前条件下就是不可执行的应该被标记出来而不是直接进入实验环节。这四条约束看起来简单但它们把假设从想法逼成了可执行的验证计划。这也是我认为FARS这类系统真正有价值的地方——它不是让AI替你想而是用工程约束逼你把想法想清楚。3.2 实验Agent的环境地狱假设通过了审查接下来就是把它变成可运行的实验。这是整个流程里最脏最累、也最容易崩的一环。我见过太多demo在这里翻车假设写得漂漂亮亮实验Agent生成的代码一跑就报错报错信息还看不懂然后整个流程就卡死在那里。问题的根源在于实验Agent面对的是一个它无法完全感知的环境。它不知道你的机器上装了什么版本的CUDA不知道你的数据集放在哪个路径不知道你的基线代码依赖了哪个已经废弃的库。它只能根据假设里的描述去猜该怎么写代码而猜错的概率极高。FARS式的系统通常会用几种手段来缓解这个问题。一种是预置环境模板提前把常用的实验环境比如PyTorch训练环境、数据预处理环境做成标准化的容器或配置实验Agent只需要在模板里填空而不是从零搭建。另一种是失败重试错误反馈代码跑挂了把错误信息喂回给实验Agent让它自己修修不好再升级给人类。实测下来简单的依赖错误比如少装一个包重试两三次能自己修好但涉及逻辑错误的比如数据泄漏、评估指标算错基本修不好必须人工介入。这里有个经验值得分享实验Agent的能力上限取决于你给它的脚手架有多厚。如果你只给它一个空白的Python环境它连import都可能写错如果你给它一套封装好的实验框架数据加载、训练循环、评估函数都现成它只需要写核心逻辑成功率会高得多。这跟带新人的道理是一样的——你不可能指望一个刚入职的人从零搭一套训练框架但你可以给他一套模板让他改。3.3 结果解读别让写作Agent把日志当结论实验跑完了产出了一堆日志和指标。这时候写作Agent上场把整个过程组织成文稿。这里有个非常隐蔽的坑写作Agent很容易把过程当成结论来写。比如它会写我们运行了实验损失从2.3降到了0.8但这只是过程描述不是科研结论。科研结论应该是在条件X下方法M相比基线B在指标Y上有显著提升这支持了假设H1。要避免这个问题写作Agent的输入不能是原始日志而必须是经过结果解读Agent处理过的结构化结论。结果解读Agent的职责是把原始指标翻译成支持/不支持/部分支持假设的判断并给出置信度。这一步看起来多余但它实际上是在强制系统对实验结果做出明确表态而不是含糊地把数据堆在那里让读者自己去猜。我自己的做法是结果解读Agent必须输出一个三值判断支持、不支持、不确定。如果是不确定必须说明缺什么信息才能确定。这个约束逼着系统去面对实验到底说明了什么这个核心问题而不是绕过去。4. 自动化科研的真实边界哪些事它能做哪些事它做不了4.1 它擅长的是结构化劳动不是创造性突破聊到这里必须泼一盆冷水。FARS这类系统再强它擅长的也是结构化劳动——文献检索、格式整理、代码模板填充、结果汇总、初稿组织。这些工作占了科研工作者大量时间但它们的共同特点是有明确的输入输出规范有可参照的先例。自动化系统在这些任务上确实能省下大量时间。但科研里真正值钱的部分——提出一个前人没想到的问题、在看似无关的领域之间建立联系、设计一个巧妙的实验来区分两种竞争性解释——这些没有先例可循的环节目前的多智能体系统基本无能为力。它可以帮你把已有想法验证得更快但它很难帮你产生那个从0到1的想法。这不是模型能力不够的问题而是这类系统的设计范式决定的它依赖已有的文献和模式而真正的突破往往来自对既有模式的打破。所以我对学术终结者这种说法一直持保留态度。它终结的不是学术而是学术里那些重复性的、机械的、本可以自动化的部分。这对科研是好事因为把研究者从这些劳动里解放出来他们才有更多时间去思考真正难的问题。4.2 可复现性自动化科研最大的信任危机自动化科研还有一个绕不开的问题可复现性。传统论文你至少能看到作者写了什么方法、用了什么数据、跑了什么实验。自动化系统产出的论文如果中间过程不透明审稿人根本无法判断这个结果是真跑出来的还是模型编出来的。这也是为什么我在前面反复强调结构化交接和全流程审计。一个负责任的自动化科研系统应该能导出完整的执行轨迹每个假设是怎么来的、被谁审查过、实验代码是什么、运行环境是什么、原始输出是什么。没有这条轨迹产出的论文就是空中楼阁。我实测下来的经验是把审计日志当成一等公民来设计而不是事后补。也就是说每个Agent在输出产物的时候同时输出一份我做了什么、基于什么、产出了什么的记录。这些记录汇总起来就是一份完整的可复现报告。这件事在系统设计初期做成本很低等到系统跑起来了再想补基本要重构。4.3 人类在回路中的位置不是监督而是决策最后一个边界问题人在这个流程里扮演什么角色很多人把人类定位成监督者站在旁边看Agent干活出错了就纠正。但实测下来这种定位效率极低——你盯着看大部分时间无事可做你不盯着出了问题又发现不了。更合理的定位是人类做关键决策Agent做执行和准备。具体来说人类应该在几个节点介入假设筛选哪个假设值得做、资源分配给哪个方向更多算力、结果解读的最终确认这个结果到底说明什么。这些节点的共同特点是需要判断力和领域知识且决策成本高。而中间的检索、编码、格式化、汇总交给Agent就好。这种分工的好处是人类的时间花在了真正需要人类的地方而Agent承担了那些量大但不需要太多判断的工作。我自己的体感是用这种方式一个研究者能同时推进的方向数量大概能翻两三倍但前提是你得忍住不去微观管理每一个Agent的每一步。5. 自己动手搭一套的实操要点5.1 从最小闭环开始别一上来就搭全套如果你看完上面这些想自己搭一套类似FARS的系统我的第一条建议是别一上来就搭全套。我见过太多人兴致勃勃地设计了七八个Agent结果跑到第二个环节就卡住了然后整个项目烂尾。正确的做法是先搭一个最小闭环一个Agent读文献提假设一个Agent审查假设一个Agent写代码验证。就这三个跑通一个完整的小任务比如复现一篇简单论文的核心实验然后再逐步加角色。最小闭环的价值在于它能让你快速暴露系统里最脆弱的地方——通常是Agent之间的交接和实验环境而不是模型能力。5.2 交接格式要早定且要严格校验前面说过结构化交接的重要性这里补充一个实操细节交接格式一旦定了就要加校验。也就是说下游Agent在接收上游产物时先检查字段是否齐全、类型是否正确、必填项是否为空。不通过就直接打回而不是凑合着用。这个校验层看起来增加了复杂度但它能拦住大量因为上游输出不规范导致的连锁错误。我自己的做法是每个Agent的输出都过一个schema校验校验失败的产物会被标记并触发上游重试。实测下来这一层能拦掉大概30%的潜在错误非常值。5.3 给实验Agent配一套标准实验模板库实验环节的稳定性很大程度上取决于你给Agent多少现成的脚手架。我的建议是提前准备一套标准实验模板库覆盖你所在领域最常见的几类实验分类训练、回归训练、消融实验、对比实验。每个模板包含数据加载、训练循环、评估函数、日志输出的标准实现Agent只需要填核心逻辑和超参数。这样做的好处是Agent生成的代码从从零写一个训练脚本变成了在模板里填空出错概率大幅下降。而且模板库是可以积累的——你每跑通一类新实验就把它沉淀成模板下次直接复用。5.4 审计日志的字段设计审计日志要记什么我的经验是至少包含这几类字段时间戳和Agent标识谁在什么时候做了什么。输入摘要这个Agent接收到了什么结构化产物的关键字段。决策理由为什么做出这个输出尤其是假设筛选、结果解读这类判断性环节。输出产物完整的结构化输出。异常记录如果这一步出错了错误信息是什么。这些字段汇总起来就是一份可追溯的执行报告。审稿人或者合作者拿到这份报告能清楚地看到整个研究是怎么一步步推进的。6. 踩过的坑与几条不成熟的经验先说一个我印象最深的坑。早期我让假设Agent和实验Agent直接对接假设Agent输出一段自然语言描述实验Agent根据描述写代码。结果实验Agent经常脑补出假设里根本没提的细节——比如假设里只说用方法M实验Agent自己决定用M的某个变体还改了超参数。最后实验结果和假设对不上排查了半天才发现是交接环节的信息丢失。这个坑的教训是Agent之间的信息传递宁可冗余不可省略。假设里该写的条件、边界、资源需求一个都不能少。你觉得这个显然的东西下游Agent不一定觉得显然。第二个坑是关于批判Agent的。我一开始把批判Agent设得太严格结果它把所有假设都否了整个流程卡在假设筛选环节出不来。后来调整了策略让批判Agent输出的是修改建议而不是通过/否决假设Agent根据建议迭代通常两三轮就能收敛到一个可执行的版本。批判的目的是改进不是淘汰这个定位很重要。第三个坑是关于成本控制的。多智能体系统跑起来token消耗是单Agent的好几倍因为每个Agent都要读上下文、写输出还有来回的审查和重试。我有一段时间没注意一个下午烧掉的钱够我吃一个月午饭。后来加了预算控制每个任务设定token上限超了就暂停等人工确认。这个机制救了我好几次。最后分享一个我觉得挺有用的小技巧给每个Agent设一个置信度字段。Agent在输出产物时同时输出它对这个产物的置信度高/中/低。低置信度的产物会被自动标记优先送人工审查。这样你不需要审查所有产物只需要关注那些Agent自己都没把握的效率高很多。这套东西还在快速演进我上面说的这些也只是基于当前阶段的观察。但有一点我比较确定多智能体做科研短期内不会取代研究者但会显著改变研究者的工作方式。会用这套工具的人和不会用的人产出效率的差距会越拉越大。至于这个差距最终会带来什么我也没有答案只能边用边看。