NUS提出DynaFlow框架：仅训练主智能体实现多Agent编排

何时需要协作？如何分工、传递信息并验证结果？DynaFlow 将这些决策交给一个可训练的主智能体。

面对一道数学题、一个科学问题或一项多跳检索任务，多智能体系统应该安排多少个角色？

谁先推理，谁去查证，哪些结果需要交给下一步？

这些看似属于“流程设计”的问题，直接影响协作能否发挥作用。

新加坡国立大学团队提出 DynaFlow，探索一个核心问题：能否仅通过训练主智能体，让系统学会何时调用工作流，以及如何设计高质量的多智能体协作？

方法将可执行工作流的生成纳入主智能体的动作空间：根据当前问题组织角色、安排依赖、传递中间结果，并利用执行反馈决定后续行动。

在所有子智能体保持冻结的情况下，DynaFlow 在六个基准、共 688 道题上达到 88.08% 的总体准确率；动态模式有 47.1% 的问题不调用工作流，总体准确率仍达到 87.94%。

多智能体系统常使用预设角色或固定流程，例如先规划、再执行、最后审核。

但任务需要的协作形式并不一致：

数学问题可能需要不同解法之间的交叉验证；科学问题需要综合证据、判断争议；多跳问答则依赖前一步识别出的实体，引导下一步检索。

DynaFlow 让主智能体针对问题生成 JavaScript 工作流程序。

程序明确规定子智能体的任务指令、输入内容、执行顺序和结果汇总方式。

相互独立的步骤可以并行，存在依赖的步骤则接收上游输出后继续执行。

这里的“自由编排”体现在组合方式上：

系统提供智能体调用、并行执行和流水线等基础能力，主智能体据此构造适合当前问题的协作结构，无需将任务套入固定的角色与阶段模板。

例如，多跳检索可以先并行寻找候选实体，再将实体名称、证据与来源交给后续节点核实。

主智能体需要同时回答“由谁完成”和“需要提供哪些信息”，让分工与信息传递形成连贯的求解过程。

工作流运行后，主智能体会收到程序结果和执行记录，并据此判断是继续检索、补充验证、再次调用工作流，还是给出最终答案。

由此，工作流成为推理过程中可以生成和调整的一种行动。

图 1｜DynaFlow 方法框架。主智能体负责选择与生成工作流，冻结的子智能体执行任务，结果与执行记录返回主智能体，支持后续决策。来源：论文图 2。

DynaFlow 将编排能力作为独立的学习对象。

训练过程中，所有子智能体保持不变，主智能体通过两阶段监督微调，学习如何组织这些已有能力。

第一阶段：从有效示范中学习工作流设计。 

教师模型使用相同的工作流接口和固定子智能体完成任务，研究团队保留最终回答正确、符合任务委派规范的轨迹。

训练目标是主智能体的首轮任务分析与工作流动作，使其学习如何将问题转化为可执行的协作方案。

第二阶段：进一步筛选编排质量。

“最终答对”之外，还要考察协作过程中如何使用信息。

团队围绕三类问题筛选示范：是否将未经支持的判断写成既定前提；验证指令是否诱导预期结论；关键上下文或中间结果是否缺失、误传。

第二阶段在筛选后的 712 条示范上继续训练，保持首轮监督目标。

这一设计将训练重点从“最终是否答对”进一步扩展到“协作过程如何组织”。

在子智能体保持冻结的情况下，主智能体通过明确任务指令、传递必要上下文，并组织中间结果的共享与验证，构建更有效的信息流，从而提升系统整体的解题表现。

实验采用 Qwen3.5-27B，覆盖 AIME 2024、AIME 2025、AIME 2026、PolyMATH、GPQA-Diamond 和 HotpotQA，共 688 道题，涉及竞赛数学、多语言数学、科学问答与多跳检索。

论文设置三种执行模式：Direct 不调用工作流；Dynamic 由主智能体选择直接作答或调用工作流；Forced 要求先调用工作流，再由子智能体开展实质性求解。

三种模式帮助区分主智能体独立作答、选择协作和组织协作的表现。

不同训练阶段的总体准确率（%）

数据来源：论文表 2。总体准确率按全部 688 道题微平均；各工作流设置使用相同的冻结子智能体和运行时。

DynaFlow 的 Forced 准确率达到 88.08%，较本文评测中使用相同骨干模型的最强对比基线 Self-Refine（77.18%）提升 10.90 个百分点。

在相同 Forced 设置下，训练前后的准确率从 75.87% 提升至 88.08%，增幅为 12.21 个百分点。

在 AIME 2024、2025 和 2026 三个测试集上，Forced 模式均达到 100%，共答对 90 道题，每年各 30 道。

Dynamic 模式在 PolyMATH 和 HotpotQA 上分别达到 91.50% 与 84.50%。

这些结果展示了方法在不同任务类型上的应用表现。

高质量编排也包括判断什么时候需要协作。

Dynamic 模式下，DynaFlow 在 47.1% 的问题上选择不调用工作流，总体准确率为 87.94%，与 Forced 的差距仅为 0.14 个百分点。

将直接作答的问题一并计入平均值后，Dynamic 每题使用 2.44 个子智能体，Forced 约为 4.16 个，平均子智能体数量减少约 41%。

这表明主智能体可以在选择求解方式时兼顾任务需求与协作规模。

随着训练推进，Dynamic 与 Forced 的准确率差距从 Base 的 10.75 个百分点，缩小到第一阶段的 1.02 个百分点，再缩小至 0.14 个百分点。

选择是否协作，与生成怎样的工作流，共同构成编排能力：额外的智能体应当为当前问题提供有价值的推理、证据或验证。

图 2｜准确率与协作规模。图中横轴包含主智能体，因此 DynaFlow 的 Dynamic 和 Forced 分别约为 3.44 和 5.16 个角色；正文的 2.44 和 4.16 仅统计子智能体。来源：论文图 1。

为了理解训练后的变化，团队分析了 Forced 模式下生成的工作流。

结果显示，编排的提升体现在阶段之间更明确的信息依赖，以及对上游结果的使用和检查。

混合串行与并行的工作流占比，从 Base 的 3.4% 上升到 DynaFlow 的 85.6%。

传递上游结果、并明确指示下游节点使用这些结果的工作流，占比从 12.6% 上升到 97.7%。

这意味着更多协作环节围绕前序证据展开，形成相互衔接的任务链条。

从第一阶段到第二阶段，包含中间结果纠错或精炼设计的工作流占比从 28.1% 增至 35.9%，重大信息流缺陷占比从 1.9% 降至 0.9%，平均子智能体数量则由 4.35 降至 4.16。

这些变化与更有针对性的信息交换和验证设计相伴出现。

角色配置也呈现任务差异：数学任务中，求解者与验证者合计占执行节点的 90% 以上；HotpotQA 中，检索研究角色占 59.6%。

主智能体会根据任务调整分工，并为各角色指定目标、输入和上游结果的使用方式。

图 3｜Forced 模式下的工作流结构与信息使用。S1、S2 分别表示两个训练阶段；(a) 执行结构，(b) 角色专业化，(c) 依赖模式，(d) 上游输出复用，(e) 结果汇总策略，(f) 子智能体数量。来源：论文图 5。

论文用一道 AIME 2026 的回文数计数题展示了编排差异：统计各位数字非零、数字和为 13 的回文数。Base 将问题交给一个求解者，因算术错误得到 59。

DynaFlow 为这道题安排三条并行路径：通过枚举直接构造并计数，使用动态规划计算，再以容斥方法进行组合分析。

三条路径的输出共同传给验证者，供其比较并独立重算，三个求解者与验证者均得到正确答案 62。

这个案例展示了互补方法与信息依赖如何配合：前面的节点提供不同推导，后面的节点获得这些中间结果并开展独立检查。

协作的价值来自清晰的分工、可检查的依据，以及对结果的交叉验证。

图 4｜AIME 2026 回文数计数案例。三种互补计算连接到同一验证环节。

DynaFlow 表明，在子智能体能力保持不变的前提下，训练主智能体如何设计指令、连接阶段和使用信息，可以带来显著的任务表现提升。

自由生成工作流，让系统能够为具体问题组织协作；按需调用工作流，则让主智能体保留独立解决问题的灵活性。

进一步提升主智能体对争议结果的判断能力，以及子智能体的信息传递与独立验证能力，将为更复杂的协作任务提供支持。

对多智能体研究而言，DynaFlow 提供了一条可探索的路径：将工作流设计与协作调用纳入同一个主智能体策略，学习如何更有效地组织已有能力。