10 月 1 日提交的论文 It Takes Workflows to Evolve Better Workflows（arXiv 2610.01026）点出了一个被多数多智能体工作流方法绕开的事实：它们训练大模型去「造出更好的工作流」，却只优化那个工作流生成器，而真正一起搭工作流、跑任务的其它 agent 被钉死在原地。论文换了个思路——把工作流本身当成训练用的 harness（承载框架），让参与的角色也能跟着演化。
背景：工作流越训越聪明，角色却不动
让 LLM 构造多智能体工作流来解复杂任务，是近一两年的热门打法。可现有方法有个隐含假设：只要把「生成工作流」的那个模型训好，工作流就会变好。问题在于，一个工作流的成败取决于里面所有 agent，而它们被耦合在一起，工作流的最终得分又只是单个稀疏分数，根本说不清是哪个 agent 出了错。于是训练只能改生成器，其余角色成了固定背景板，哪怕它们才是瓶颈。
做法：分层奖励让角色自演化与共演化
FloWright 的做法是把工作流当成 harness，引入一套分层、结构感知的奖励：它让一个角色自演化，也让两个及以上角色共演化，而且不引入额外模型、标签，也不额外执行。关键在「共演化」——当多个角色一起随奖励调整，原本被钉死的瓶颈就活了。论文还顺手解决了另一个痛点：工作流常在「单 agent 就能做」的数据上训练与评测，于是推出 DataWright，把现有数据集硬化成更难的工作流级任务，逼系统处理单 agent 搞不定的协作。
实测：让更多角色一起动，比只训一个更划算
在文档、幻灯片、图表、代码、数学、金融六类任务上，用 FloWright 训练的小开源模型最高提升 7.41；拆开看，只让单一角色优化约 2.83，让两个角色共演化约 5.03——角色越多一起演化，收益越高。这组数字支撑的是一个朴素判断：工作流的瓶颈常常不在生成器，而在那些被当作固定件的执行与构建角色；把它们也纳入演化，比反复只训一个模型更划算。
为什么值得写：工作流优化从「训一个」到「练一群」
把这篇和近期多智能体工作流优化的研究对照，它的增量认知在于把优化对象从「一个模型」扩到「一群角色」。与 clawpk.net 此前覆盖过的 InFlowOp（用无标签成本给每个决策定价、把纠错压到最便宜一步）相比，FloWright 走的是另一条路：不靠给开销标价，而靠结构感知的奖励让角色共演化，且零额外执行成本。对在做智能体编排框架的人，这是一条可借鉴的思路——与其只精调调度器，不如让参与的角色一起随反馈长进。
边界：小模型增益，不等于大模型也灵
需要冷静看待的是，论文验证集中在小开源模型与六类结构化任务，结论未必直接迁移到超大模型或开放域长链路。共演化的奖励设计、DataWright 的硬化策略，都还要在具体业务里调。更稳妥的读法，是把它当作「工作流优化该不该把角色一起训」的一个实证支点，而不是一套能直接套用的成品。值得记下的取舍是：让更多角色共演化收益更高，也意味着奖励设计与角色边界要更用心，否则耦合的 agent 可能一起跑偏。
结语
FloWright 给多智能体工作流这股热潮加的注脚是：更好的工作流，未必靠更会造流程的那个模型单独练出来，而可能来自让一起搭流程的角色都跟着演化。当工作流从单点聪明走向群体协同，优化的对象也该从「一个」扩到「一群」。