来自中科院 AI 安全国家重点实验室的反思，多智能体系统的工作流生成或许走错了方向

如果说 2023–2025 是大模型狂飙的时代，那么 2025–2026 则是多智能体系统（Multi-Agent Systems, MAS）真正开始“长出骨骼”的阶段。

大模型不再只是一个“回答问题的语言机器”，而是逐渐演化成一个能够规划、协作、执行复杂任务的智能体系统。而在这些系统背后，有一个常被忽略却至关重要的结构——工作流（Workflow）。

工作流是什么？ 它不是代码，也不是 prompt，而是 Agentic System 的“认知骨架”。

它决定了一个多智能体系统如何分工、如何协作、如何调用工具、如何拆解任务、如何在复杂环境中保持稳定的推理路径。可以说，工作流是智能体系统的“思维结构”。

随着 MAS 的爆发，学界和工业界逐渐形成了两种主流的工作流生成范式。 一种是任务级工作流（Task-level Workflow），为整个任务生成一个统一的流程； 另一种是查询级工作流（Query-level Workflow），为每个 query 单独生成一个工作流。

听起来后者更灵活、更智能、更“个性化”，但代价也更高。 于是一个关键问题浮现出来，我们是否真的需要为每个query都生成一个独立的工作流？

这项来自中国科学院计算技术研究所（ICT）人工智能安全国家重点实验室与中国科学院大学的研究团队的研究，正是从这个问题切入，试图重新定义 MAS 工作流生成的基本范式。

研究团队的背景也让这项工作显得格外扎实。 团队成员来自国家级 AI 安全重点实验室，长期深耕大模型推理优化、多智能体协作、AI 安全与可控性等方向。他们既有理论深度，也有工程落地能力，擅长从系统层面重新审视大模型的行为模式。这项研究延续了他们一贯的风格，不追热点、不堆花活，而是从根本问题入手，提出真正能改变系统设计范式的洞见。

研究的核心贡献可以概括为两句话，第一，查询级工作流并非总是必要，少量任务级工作流就能覆盖大部分query的需求。第二，任务级工作流的全量执行评估既昂贵又不可靠，需要新的低成本评估范式。

这两点看似简单，却直接挑战了当前 MAS 工作流研究的主流假设，也为未来的 Agentic System 设计提供了新的方向。

01两种工作流范式的长期争论

在多智能体系统的世界里，工作流生成一直是一个绕不开的核心问题。 但长期以来，研究者们似乎默认了两种范式的合理性，却很少有人真正去质疑它们背后的假设。

故事要从任务级工作流说起。

任务级工作流（Task-level Workflow）是最早被提出的范式。 它的思路很直接， 既然任务是固定的，那就为整个任务生成一个统一的工作流，让所有 query 都按照同一套流程执行。

图1:Aflow和我们重新思考的任务级工作流生成框架的比较。左：工作流生成过程中的总令牌数（日志尺度轴）。右：最终测试性能。我们的方法SCALE在显著减少令牌数量的同时实现了相当的性能。

Aflow、GPTSwarm、AgentPrune 等方法都是这一范式的代表。它们的优势非常明显， 统一、稳定、推理成本低。对于工业级系统来说，这种稳定性尤其重要。

但问题也同样明显，评估成本极高。为了找到一个“最优工作流”，这些方法往往需要对候选工作流进行全量执行评估，也就是在整个验证集上跑一遍。 这意味着巨量的 token 消耗，甚至比训练一个小模型还贵。

于是，查询级工作流（Query-level Workflow）应运而生。

它的逻辑是， 既然每个 query 都不同，那就为每个 query 单独生成一个工作流，让系统能够更灵活、更个性化地处理任务。

MAS-GPT、ScoreFlow 等方法就是这一方向的代表。它们的优势也很诱人， 高度适配每个query，理论上能获得更高的性能。

但代价同样巨大， 推理成本爆炸、生成不稳定、难以规模化部署。

更关键的是，学界在这两种范式之间争论了两年，却很少有人真正问过两个最根本的问题，

Query-level工作流真的必要吗？Task-level的全量执行评估真的合理吗？

这项研究的价值就在于，它终于把这两个问题摆到了台面上，并给出了系统性的实验分析与新的解决方案。

图2：任务级与查询级工作流生成及其流程反思。（1） 任务级别生成。（1） A显示搜索/训练：生成器使用验证查询生成单个工作流；（1）B显示推理：优化的工作流被重用于所有测试查询。（1）C-D展示了我们的反思：（1）C表明重复的全集评估成本非常高，（1）D表明top-k工作流具有非常相似的查询级别排名。（2）查询级别生成。（2）A表示训练：每个查询生成一个工作流；（2）B表示推理：为每个输入生成定制的工作流程。（2）C1–C3总结了我们对查询级工作流的反思：top-k任务级工作流、top-1工作流的repeat-k运行和真正的查询级生成产生了相当的覆盖率/性能。

02重新思考之一，查询级工作流真的必要吗？

当我们谈论“查询级工作流”（Query-level Workflow）时，很多人脑海里浮现的都是一种“更聪明、更灵活、更个性化”的系统想象，每个 query 都能得到一条专属的推理路径，就像每个用户都拥有一个私人助理。

但研究的实验结果却给这类想象泼了一盆冷水——至少在当前的多智能体系统中，这种“个性化”并没有带来想象中的巨大收益，甚至可能是被高估的。

为了验证这一点，研究团队设计了一套非常系统的对比实验。他们把任务级工作流和查询级工作流放在同一张桌子上，进行真正意义上的正面对决。

任务级工作流这边，他们选取了三种典型方式， Top‑1，即任务级搜索中得分最高的工作流； Top‑5，即前五个最优工作流的集合； Repeat‑5，即对同一个工作流重复执行五次，观察执行随机性带来的性能波动。

查询级工作流这边，则采用了当前最强的代表方法 ScoreFlow，它会为每个 query 单独生成一个工作流，理论上能做到“按需定制”。

为了避免“单一任务偏差”，实验覆盖了多个主流benchmark，包括 DROP、HotpotQA、GSM8K、MATH 等，涵盖了推理、阅读理解、数学、多跳问答等不同类型的任务。

结果非常耐人寻味。

首先，Top‑1 的表现就已经相当强劲。也就是说，一个任务只要找到一个足够好的工作流，它就能覆盖大量 query 的需求。这说明任务内部的结构共享度远比我们想象得高，很多 query 并不需要“个性化流程”。

更令人意外的是 Top‑5。 当任务级工作流从一个扩展到五个时，它的 query 覆盖率甚至超过了查询级方法 ScoreFlow。换句话说，少量任务级工作流的多样性，已经足以覆盖查询级工作流的“个性化优势”。

而 Repeat‑5 的结果更是让人反思。 仅仅是对同一个工作流重复执行五次，利用执行过程中的随机性，就能获得接近查询级工作流的覆盖率。这说明查询级方法的“优势”有相当一部分来自执行随机性，而不是结构本身的差异。

这些结果共同指向一个结论，查询级工作流的必要性被高估了。

任务内部的结构共享度远比我们以为的高，很多 query 并不需要独立的工作流。 而所谓的“个性化优势”，在实际系统中并没有转化为显著的性能提升。 更关键的是，查询级工作流的成本极高，却没有带来与之匹配的收益。

这意味着，在大多数实际应用场景中，少量任务级工作流就足以支撑系统的性能需求，而无需为每个 query 重新生成一条推理路径。

03重新思考之二，任务级工作流的全量执行评估是否合理？

如果说查询级工作流的问题在于“过度个性化”，那么任务级工作流的问题则在于“过度评估”。

传统的任务级工作流生成方法，如 Aflow，通常需要对候选工作流进行全量执行评估，也就是在整个验证集上跑一遍，才能判断哪个工作流最优。这种做法在早期模型规模较小时还能接受，但在大模型时代，它的成本已经高得离谱。

图3:Aflow任务级工作流生成过程中的累积令牌数与性能。

研究给出的数据非常直观， 在多个 benchmark 上，任务级工作流的全量执行评估需要消耗的token 数量达到了 10⁶到 10⁸级别。 这是什么概念？ 这意味着评估一个工作流的成本，可能比生成这个工作流还要高。 甚至在某些任务上，评估成本已经接近训练一个小模型的量级。

更糟糕的是，这种高成本评估并不可靠。

研究团队发现，在高性能区间内，不同工作流之间的性能差异极小，甚至小到无法稳定排序。也就是说，即便你花了巨量 token 去评估，最终得到的排序也可能是不稳定的，甚至是随机的。

这就像你花了几百万做了一次体检，结果医生告诉你，“你身体挺好，但具体好多少我也说不清。”

图4:Aflow在四个基准测试中生成的前5个任务级工作流的性能和排名统计。Perf表示平均测试性能。CR和DR分别表示通过测试查询计算的平均竞争排名和密集排名。

更关键的是，评估结果的区分度极低。 在多个任务上，Top‑5 工作流的性能几乎难以区分，评估结果的波动甚至超过了工作流本身的差异。这意味着全量执行评估不仅昂贵，而且在高性能区间几乎失去了意义。

这些发现共同指向一个结论，任务级工作流的全量执行评估既昂贵又不可靠。

它无法支撑大规模系统的扩展，也无法提供稳定的排序依据。 在大模型时代，这种评估方式已经不再适用，需要新的范式来替代。

研究团队在研究后续提出的 SCALE 框架，就是为了解决这一问题而设计的——用自预测和少量校准替代全量执行，让评估变得更轻、更快、更稳定。

04SCALE：一种低成本、高性能的任务级工作流生成框架

当研究团队意识到“查询级工作流并非总是必要”以及“任务级工作流的全量执行评估既昂贵又不可靠”之后，一个新的问题自然浮现出来， 如果我们不想为每个 query 生成工作流，也不想为每个候选工作流做全量执行，那有没有一种更聪明、更经济、更可扩展的方式来选择最优工作流？

SCALE 就是在这样的背景下诞生的。

它的核心思想非常优雅，甚至可以说是“反直觉的简单”，让LLM自己预测工作流的性能，再用少量真实执行结果进行校准。

这句话背后隐藏着一个重要的理念转变—— 过去我们总是把 LLM 当成一个“执行者”，让它按照工作流一步步推理； 而 SCALE 则把 LLM 变成了一个“评估者”，让它自己判断一个工作流是否优秀。

这就像从“让学生做题”变成“让学生自己判断题目难度”，然后再抽几道题验证一下判断是否准确。 这种方式不仅更轻量，也更符合大模型的能力边界。

SCALE的框架结构

SCALE 的整体结构分为两个阶段，Warm-up 和 Surrogate Evaluation。 前者负责“打底”，后者负责“发力”。

Warm-up阶段，用少量真实执行建立经验池

Warm-up 的目标不是找到最优工作流，而是让系统对任务有一个初步的“经验认知”。

研究团队采用少量 MCTS（蒙特卡洛树搜索）来生成候选工作流。 这些工作流会被完整地执行一次，用于收集真实的性能数据。 这些数据被存入经验池，包括：

• local experience，与具体 query 相关的执行表现

• global experience，与任务整体结构相关的统计特征

Warm-up 的成本远低于传统 Aflow，因为它只执行少量轮次，不追求最优，只追求“有代表性”。

它的作用更像是给系统“上第一堂课”，让它知道任务大概长什么样。

Surrogate Evaluation阶段，SCALE的核心创新

真正的魔法发生在第二阶段。

这一阶段的目标是，在不进行全量执行的前提下，准确评估每个候选工作流的性能。

研究团队提出了三步走策略。

自预测（Self Prediction），让 LLM 自己判断工作流好不好

LLM 会在一个专门设计的评估 prompt 下，对每个工作流进行性能预测。 这个预测不是随便猜，而是基于Warm-up 阶段积累的经验池进行类比推断。

预测结果记为 Spred。

这一步的意义在于， LLM 的结构理解能力很强，它能看懂工作流的逻辑结构、步骤安排、工具调用顺序，从而给出一个“结构性判断”。

但结构判断终究是判断，仍然需要真实信号来校准。

少量执行校准（Few-shot Calibration），抽取 1–3% 的 query 做真实执行

为了让预测不至于“飘”，SCALE 会从验证集中抽取 1–3% 的 query，对每个候选工作流进行真实执行。

这一步得到的分数记为 Sfew。

Few-shot 的作用是提供“真实世界的反馈”，让系统知道哪些预测是偏高的，哪些是偏低的。

校准融合（Calibrated Score），预测 + 校准的加权组合

最终得分由以下公式给出

其中 α 会根据预测误差和 few-shot 比例自适应调整。

这一步的意义在于让结构判断与真实信号结合，既不盲信LLM，也不依赖昂贵的全量执行。

为什么 SCALE 有效？

SCALE 的有效性来自三个关键因素的协同作用。

自预测提供结构性判断。 LLM 对工作流结构的理解能力远比我们想象得强，它能看出流程是否合理、步骤是否冗余、工具调用是否匹配任务需求。

Few-shot 提供真实信号。 少量真实执行就足以让系统知道预测偏差的方向。

校准机制弥补偏差。 预测 + 校准的组合让系统既轻量又可靠。

最终的效果是，SCALE的评估成本远低于全量执行，但评估质量却几乎不下降。

05实验结果，性能几乎不降，成本大幅下降

研究团队在六大 benchmark 上验证了 SCALE 的效果，结果非常亮眼。

与 Aflow 对比，SCALE 的性能下降仅 0.61%。 这意味着它几乎没有牺牲性能。

但在成本方面，SCALE 的优势堪称碾压级别， Token 成本减少了 54–83%。 这对任何需要规模化部署的 MAS 系统来说，都是巨大的工程价值。

更重要的是，SCALE 的表现非常稳定。 无论是 DROP、HotpotQA、GSM8K 还是MATH，它都能保持一致的性能优势。

表：六个基准测试的测试性能Perf和令牌数量成本比较。∆报告SCALE相对于Aflow的性能变化和成本降低。

研究团队还验证了不同 surrogate score 的有效性。 结果显示，

• 校准分数最接近真实执行

• 自信度评分完全不可靠

• 自预测 + 校准是最佳组合

这进一步证明了 SCALE 的设计是合理且必要的。

06对未来 Agentic Systems 的启示

SCALE 的提出不仅仅是一个技术优化，更像是对整个 Agentic System 设计范式的一次重新定义。

首先，Query-level 工作流不再是默认答案。 未来的系统应该更多采用“任务级 + 多样性”的策略，而不是为每个query 单独规划。

其次，工作流评估不应依赖全量执行。 SCALE 展示了一种更智能、更经济、更可扩展的评估方式。

第三，LLM 作为优化器的潜力被严重低估。 过去我们只让 LLM 执行任务，而 SCALE 证明它完全可以承担“评估者”“规划者”“优化器”的角色。

最后，Agentic System 的设计范式将发生根本变化。 从“每个 query 单独规划” 走向 “任务级共享 + 局部校准”。

这不仅更高效，也更符合大模型时代的系统工程逻辑。（END）

参考资料：https://arxiv.org/abs/2601.11147

关于波动智能——

波动智能旨在建立一个基于人类意图与反应的真实需求洞察及满足的价值体系，融合人工智能与意识科学，构建覆盖情绪识别、建模与推荐的智能引擎，自主研发面向社交、电商等场景的多模态意图识别引擎、意图标签系统及意图智能推荐算法，形成从情绪采集、意图建模到商业转化的完整解决方案。波动智能提出“意图是连接人、物与内容的新型接口”，其产品广泛应用于AI社交、个性化内容推荐、虚拟陪伴、电商体验优化等领域。波动智能正在探索“EMO-as-a-Service”技术服务架构，赋能企业实现更高效的用户洞察与精准情绪交互，推动从功能驱动到意图驱动的产业范式升级。

亲爱的人工智能研究者，为了确保您不会错过*波动智能*的最新推送，请星标*波动智能*。我们倾心打造并精选每篇内容，只为为您带来启发和深思，希望能成为您理性思考路上的伙伴！

加入AI交流群请扫码加微信