只训练一个agent，为什么整个workflow还是跑不好？

你有没有想过这样一件事：如果一个团队里只有一个人在不断学习进步，其他人原地踏步，这个团队的整体表现能提升多少？

大概率不会太多。因为短板效应会卡住整体水平。可偏偏在AI多智能体系统的训练上,这几年大家一直在做这件"训练一个人,放着其他人不管"的事。

这篇论文叫FLOWRIGHT，它想解决的就是这个问题。先说说这个问题到底有多尴尬。

**workflow**：工作流,指多个AI智能体协作完成一个复杂任务的整套流程,比如一个负责规划、一个负责执行、一个负责检查,像公司里的分工合作。

一个复杂任务往往超出单个大语言模型的能力范围。想处理一份几百页的财报,想同时看懂图表又要算数字,想写代码还要调试运行,单打独斗很难搞定。于是大家开始搭建workflow,让多个AI智能体分工合作。但问题来了,这个workflow是谁设计的?通常是由一个叫"生成器"的智能体来生成整个工作流程,告诉每个角色该做什么。

现在的做法是,只去训练这个生成器,让它学会设计更好的流程图,而真正干活的那些执行智能体,还是原来的样子,一点没变。

这就像一家公司只培训了项目经理做计划,却没有培训任何一个具体执行任务的员工。项目经理画出再漂亮的流程图,如果底下干活的人水平不够,任务照样搞砸。更麻烦的是,公司最后发奖金只看一个指标:这个项目整体是成功还是失败。如果失败了,到底是经理规划错了,还是某个员工摆烂了?完全说不清楚。

这正是论文指出的核心矛盾:**workflow最终的结果,是所有参与角色共同决定的,但现在的训练方法只盯着其中一个角色,其他角色的贡献被完全忽略了**。

论文作者还做了一个挺扎心的调查。他们翻查了20篇发表在顶级会议上的workflow生成方法论文,统计它们用来评测的121个数据集,发现其中85个,占了七成,是单问题数学题、函数级编程题、简短问答这类任务。

这类任务有个共同特点:一个能力过硬的AI单独上手,一次就能答对,根本不需要什么团队协作。

论文用了一个很直接的对比实验说明这点。用同一个基础模型Qwen3-VL-8B,在原始的MMLongBench-Doc文档理解数据集上,多智能体workflow只拿到40.50%的准确率,而单个agent反而拿到48.00%,比workflow还高了7.5个百分点。在另一个财务数据集DocFinQA上也是类似的情况,workflow33.00%,单agent38.00%。

这说明什么?说明现有的很多测试,根本测不出workflow到底好不好,因为任务太简单,单打独斗就能搞定,团队协作反而因为沟通成本显得多余。

论文提出两个解决方案,一个叫FLOWRIGHT用来训练,一个叫DATAWRIGHT用来出题。先说训练方法。

把workflow本身当成训练场

FLOWRIGHT的核心想法是:别光训练那个画流程图的生成器了,workflow里的每一个角色,都应该能从任务的最终结果里学到东西。

**harness**：中文翻译是"挽具"或"套具",论文里指一套评测和执行机制,它负责运行整个workflow、给出答案、并打一个分数,这个分数既可以用来评估效果,也可以反过来当训练信号。

这个设计思路有点像给整个马车队配了一套挽具系统,而不是只给领头马配。挽具连接着每一匹马和马车,马车跑得快不快,是所有马共同拉的结果。如果你只训练领头马怎么领路,却不管后面几匹马拉不拉力,马车照样跑不快。而这套挽具系统的妙处在于,它不需要额外雇一个人去分别评价每匹马的表现,挽具本身的受力情况就能告诉你哪匹马在偷懒。

那具体怎么把"workflow整体表现"这一个分数,拆分成"每个角色该负多少责任"呢?这是整篇论文最费心思的地方,因为这个问题如果解决不好,训练就会乱套,表现差的时候根本不知道该骂谁。

论文设计了一套叫做"结构感知credit分配"的机制。

**credit**：这里指对失败结果的责任归属,简单说就是一次任务失败了,具体是哪个角色、哪个节点出的问题,这个责任该怎么量化。

具体做法是,先看workflow的执行轨迹,这个轨迹本来就是执行过程中自然留下来的记录,不需要额外跑一遍或者请一个评委来打分。每个角色在这个workflow里"署名"了哪些节点,比如生成器设计了整个流程图,那流程图里所有节点都算它署名的;某个工具创造者只负责某几个用到它发明的工具的节点,那就只算那几个。然后看这些署名节点里,有多少真的出了问题,算一个比例,这个比例就是这个角色该承担的责任分数。

如果一个角色署名的节点一个都没出问题,它的责任分数就是0,不会被冤枉。如果出问题了,这个分数就是负的,相当于一个惩罚信号,告诉这个角色的策略该往哪个方向调整。

这里有个细节处理得很细致:如果一个节点失败,是因为它依赖的上游节点先失败了,那这个失败不会算到当前节点头上,而是会顺着依赖关系一直追溯到真正出问题的那个根源节点。

这就好比流水线上,如果第五道工序出的次品,其实是因为第二道工序给的原材料就是坏的,那责任不该算在第五道工序的工人头上,得往前查到底是哪一步出的岔子。如果不做这种追溯,只要看哪个节点"表面上"失败了就定责,那所有后续环节都会被冤枉背锅,训练信号就会乱成一锅粥,每个角色都在学着躲避根本不是自己造成的问题,反而学不到真正该学的东西。

责任分配解决了,还有一个问题:workflow经常是"差一点就成功"或者"完全失败"的情况混杂在一起,如果只给一个及格或不及格的二元分数,中间那些努力的痕迹就全被抹掉了。

把一次打分拆成一个阶梯

论文把评分做成了一个层层递进的阶梯,叫做"hierarchical reward"。

**hierarchical reward**：分层奖励,指不是只打一个总分,而是把评价拆成好几层,从最基础的格式对不对,到最后答案准不准,层层累加。

具体来说这个阶梯有五层。第一层看这个角色的输出格式对不对,能不能被正常解析,这是最低门槛,如果连格式都不对,后面全都没法算。第二层看这个角色自己的贡献是不是有效,比如生成器画的流程图结构合不合理,工具发明者造的工具能不能真的跑起来。第三层看整个workflow最后有没有跑出一个答案来,别半路卡死。第四层看这个答案到底对不对,正确率多少。第五层就是前面说的责任分配,根据谁出了错来扣分。

这五层加权求和,就是最终这个角色拿到的训练信号。

这个设计的好处在哪?想象一下考试只有"满分"和"零分"两种结果,一个学生明明做对了前面八道题,只错了最后一道,也是零分,那这个学生根本没法从这次考试里学到"哪里做得好、哪里要改进"。分层打分就像老师批改试卷时,每一道小题都给了部分分,学生就知道自己哪一步是扎实的,哪一步还需要加强,而不是只拿到一个冷冰冰的"不及格"。如果不这样设计,workflow只要有一点没达标就全盘归零,模型永远学不到那些"做对了一半"的宝贵信号。

论文做了个消融实验验证这套阶梯真的有用,结果显示光靠格式分和答案分这两层,提升几乎为零,GRPO算法下只提升了0.07%。但加上"有效性"这一层评分,直接贡献了最大的单项提升,GRPO下涨了2.07%,DAPO算法下涨了2.29%。再加上责任分配这一层,又能再涨0.69%到0.75%。

这说明中间那层"你的贡献到底有没有用"的评分,才是真正撑起整个训练效果的核心部分。

有了这套评分机制,接下来一个问题是:到底该优化哪个角色,优化几个?

一个人进步快,还是一群人一起进步快

论文设计了四种"进化模式"。

第一种叫单角色自我进化,就是只挑一个角色出来训练,比如只训练生成器,其他角色不动。第二种叫智能体和技能协同进化,比如生成器和它调用的某个创造工具的技能一起训练。第三种叫上下游协同进化,负责设计流程的角色和负责执行流程的角色一起练。第四种叫多智能体协同进化,好几个角色一块儿训练。

实验结果很有意思:**协同进化的角色越多,带来的整体提升就越大**。

多智能体协同进化在域内测试集上提升了7.32%,域外分布提升6.05%,跨域泛化提升4.20%,这三个数字都是四种模式里最高的。在只用4B参数规模模型做的四种模式对比里,多智能体协同进化整体提升5.03%,领先智能体技能协同进化的4.06%、上下游协同进化的3.06%,以及单角色自我进化的2.83%。

这个结果很直观地印证了开头那个比喻,一个团队只有一个人在进步,整体表现的天花板是有限的,大家一起进步,团队能达到的高度完全不一样。

但这里有个反直觉的发现值得单独说说。论文做了个实验,让生成器用小一点的4B模型,其他角色用大一点的9B模型。结果发现,如果反过来,让生成器和工具发明者用9B这种更强的大模型,但真正执行任务的下游智能体却只用4B这种相对弱的模型,整体表现反而比全部都用4B还要差,只有29.57%,比全4B基线的32.09%还低。

这说明一个很实际的问题:**流程设计得再好,如果真正干活的执行者能力跟不上,整个系统照样被拖后腿**。

这就跟一个建筑设计师画出了惊艳绝伦的设计图,但施工队的工人水平有限,盖不出设计图里那种精细的效果,最后建筑质量照样打折扣。如果不去管执行层的能力,只顾着优化设计方案本身,那优化出来的方案很可能只是纸面上的完美,根本落不了地。

有意思的是,即便是用一个经过训练的4B小模型来执行,只要训练到位,照样能把整体表现拉到比全9B基线还高的水平,47.67%对比47.50%的基线,甚至两个角色一起训练能到48.50%。这说明训练带来的提升,有时候比单纯堆模型参数规模还管用。

讲完了训练这一环,论文还解决了另一个同样重要的问题:就算有了好的训练方法,拿什么数据来训练和检验这个方法到底行不行?

把容易题改造成难题

前面提到的那个尴尬发现,workflow常用的测试集太简单,一个agent就能搞定,这事总得有个解法。论文提出了DATAWRIGHT,专门用来把这些"太容易"的数据集改造成真正需要团队协作才能解决的难题。

DATAWRIGHT设计了三种"加硬"策略。

第一种叫Shared,把同一份资料里的好几个问题捆绑成一个任务,逼着系统学会把一个大任务拆分成小问题分别处理。第二种叫Paired,把来自不同资料的好几个问题捆成一个任务,这就要求系统能准确判断每个小问题该去哪份资料里找答案。第三种叫Decoy,只留一个真正的问题,但把它对应的真实资料藏在一堆干扰资料里,逼着系统先找到正确的那份资料,再去回答。

这三种策略分别对应着workflow真正该展现价值的三种能力:拆解任务、分配任务、定位证据。单个AI在面对一份资料一个问题的时候,这些能力根本用不上,但一旦任务被加硬,这些能力的价值立刻就显现出来了。

这就好比原来考试只考"这道题怎么做",现在变成"这堆试卷混在一起,你先找出哪张卷子是你的,再做上面的题"。单纯做题能力强的学生,如果不具备整理和定位信息的能力,面对后一种考法照样会手足无措。如果不做这种改造,继续用那种一张卷子一道题的老办法考试,根本测不出谁更擅长统筹全局。

论文还专门做了一次示范,用MMLongBench-Doc这个文档理解数据集,原始版本上workflow只有40.50%,单agent反而有48.00%,workflow输了。但经过DATAWRIGHT加硬处理之后,同样的workflow一下子涨到51.61%,而单agent这时候只剩12.33%,workflow反超了接近39个百分点。

这个反转说明的道理很直白:当需要查阅的证据量超过了一个AI单次能处理的上限,这时候"怎么分配阅读任务、怎么组织协作"这件事才真正变得重要起来,workflow的价值才真正体现出来。

DATAWRIGHT最终覆盖了12个数据集,跨越文档、幻灯片、图表、代码、数学、金融7个领域,一共构造出44个评测场景。这些场景被分成三类:训练用过的"域内"场景、训练数据的变体但没见过的"域外分布"场景、以及完全没训练过的全新领域"跨域"场景,用来系统性检验方法到底是真学到了本领,还是只是记住了训练时见过的套路。

测试时不改参数也能变聪明

除了训练阶段的改进,论文还提出了一个很巧妙的"测试时优化"方法,叫做元蒸馏。

**元蒸馏**：指不改变模型参数本身,而是从以往成功的经验里提炼出一些可复用的"套路"或"范例",让模型在遇到新任务时能参考这些范例做得更好。

这就像一个厨师并没有重新去上烹饪学校,但他把自己过去做得特别成功的几道菜的经验记在小本子上,下次遇到类似的食材,翻翻小本子,马上就能想起当年是怎么处理的。这个小本子不需要重新培训厨师的手艺,但照样能让菜做得更好。

实验显示,从自己过去的成功经验里提炼这个"小本子",整体能提升0.93%,如果从一个更强的"老师"模型那里学,能提升1.10%。而把成功经验整理成5个具体案例给模型参考,提升效果最明显,能达到2.58%,但如果只给1个案例,效果反而不如完全不给,这说明单个案例容易带偏方向,得有足够的案例才能真正归纳出规律。

如果把训练阶段的优化和测试阶段的元蒸馏叠加起来用,整体提升能到3.21%,比单独用5个案例的元蒸馏还要再高1.59%。更有意思的是,这个测试阶段的元蒸馏,即便用在那些完全没有参与训练的闭源大模型上,比如GPT-5-mini和GPT-5.4-mini,照样有效,分别提升了1.44%和1.91%。

这说明这套方法炼出来的"经验套路",不绑定具体某个模型,换一个完全没训练过的模型照样能用上。

论文还做了一系列扎实的消融实验,验证了这套方法在不同强化学习算法比如GRPO、DAPO、CISPO下都稳定有效,在四种不同的workflow书写方式(用schema、状态机、图结构、还是代码来表示流程)下都能带来提升,在"模块化拼装"和"打包成胶囊"两种资源池组织方式下也都有效。其中一个特别值得一提的发现是,**允许资源池动态扩充、并从过去成功的经验里生长出新组件,这种设计带来的提升是所有单项设计选择里最大的**,比固定不变的资源池高出4.83%。这说明让系统能从自己的成功经验里"长出"新工具这件事,价值比想象中更大。

写在后面

读完这篇论文,最让我觉得值得琢磨的,其实是那个"用小模型做执行者,大模型做设计者"反而效果更差的实验结果。

这个发现有点反常识,因为我们通常会觉得,规划能力更强的大脑应该能带动整体表现提升,就像一个优秀的指挥家应该能让普通乐手演奏出更好的曲子。但论文的数据明明白白地告诉你,如果乐手的技术本身跟不上,再好的指挥也救不回来。这提醒我一件事:**系统的能力瓶颈,往往不在最显眼的那个决策环节,而在那些具体执行的细枝末节里**。这跟很多组织管理的教训其实是相通的,顶层设计固然重要,但如果不管基层执行力,设计得再漂亮也落不了地。

另外一点让我意外的,是论文那个关于现有评测数据集的统计,121个数据集里85个单agent就能搞定。这个数字让我重新审视了一件事:很多时候我们觉得"这个领域已经很成熟了,大家做出来的提升都很有限",可能根本不是方法本身到了天花板,而是我们拿来检验方法的尺子本身就有问题,尺子太粗,根本量不出真正的差距。这种"测量工具本身限制了认知"的情况,其实在很多领域都存在,值得多留一分警惕。

论文里倒是也留了一些没说透的地方,比如这套方法目前主要在Qwen3.5这一个模型家族上做了系统的强化学习训练验证,换到别的模型家族上会不会有同样的效果,这事还得再看。另外所有实验用的任务,输入信息都是任务开始时就固定好的,如果换成一个边运行边变化的动态环境,比如需要的资料是实时更新的,这套责任分配的逻辑还成不成立,也是个开放的问题。

一个团队要变得更强,到底该先解决"谁来做决定"的问题,还是先解决"每个人手上的活干得怎么样"的问题?这篇论文给出的答案是:两个都要解决,而且解决的方式得是让所有人在同一个赛场上一起练,而不是关起门来各自为战。

Q&A

Q1：FLOWRIGHT是什么？

A：FLOWRIGHT是一种训练多智能体workflow的方法，它不只训练设计流程图的生成器，而是让workflow里所有参与的角色都能从任务的最终结果里学习进步，核心是通过执行轨迹自动分配责任，再把一个总分拆成格式、有效性、执行成功、答案正确、责任扣分五层逐步累加的评分体系。

Q2：为什么现有的多智能体workflow测试结果经常不准？

A：因为论文发现现有常用测试集里七成以上的任务，比如单题数学、函数级编程题，单个AI模型就能一次答对，根本不需要多智能体协作，这导致测试结果测不出workflow真正的协作能力，论文用DATAWRIGHT把这些数据集改造成了需要拆分任务、分配证据、定位资料的真正高难度任务。

Q3：训练多个角色一起进步，比只训练一个角色效果好多少？

A：论文实验显示，让多个智能体协同进化整体提升了5.03%，比只训练单一角色自我进化的2.83%高出不少，而且协同进化的角色数量越多，带来的提升幅度就越大，但如果执行环节的模型能力太弱，设计环节再强也带不动整体表现。