论文

为错误付费,而非为流程付费:无标签的流内多智能体工作流优化

为错误付费,而非为流程付费:无标签的流内多智能体工作流优化

大语言模型(LLMs)正越来越多地构建多智能体工作流:将复杂任务分解,并从智能体池中指派专家智能体。然而,要构建一个好的工作流并不容易——任务该划分得多细、每个子任务该交给哪个智能体、何时需要新建一个专家智能体,都是工作流构建者必须事先确定的关键决策;而每个子任务是否成功,只有工作流真正运行后才知晓。同时,改进工作流的代价高昂:定位故障通常需要参考答案、分级结果或训练好的评估器,而修复则要通过重新执行、重新搜索或重新训练施加到整个工作流上。 我们提出 InFlowOp,它用一种无标签的统一代价来为每一个决策定价,该代价同时权衡智能体能力与子任务需求的匹配程度,以及该智能体运行的开销。在执行之前,InFlowOp 依据这一代价双向地决定任务分解粒度与智能体分配,而非套用固定模板;在执行过程中,InFlowOp 用同一个代价以最省的方式纠正故障,使该代价在构建与运行时共同服务于工作流。 针对工作流层面的评估难题,我们提出 Braid 基准,其任务需要超出单智能体能力的多智能体协作。在多个领域与多种骨干模型上,InFlowOp 相比单智能体基线最高提升 +11.97%,在流内优化下达到 +9.64%。项目主页:https://xhguo7.github.io/InFlowOp/。

论文精读

TL;DR InFlowOp 用统一的无标签代价同步决定多智能体工作流的任务分解粒度与智能体分配,并在运行中以最小代价修正故障,无需标签或重训练;在 Braid 基准上显著超越单智能体基线。

问题

问题背景

当前 LLM 应用正从单次调用走向 多智能体工作流,通过任务分解与专家代理协作解决复杂任务。

现有方法局限

  • 工作流构建常依赖固定模板或人工经验,任务粒度与代理分配缺乏自适应调整。
  • 故障定位需要 参考答案、人工分级 或 训练评估器,成本高且依赖标签。
  • 修复策略面向整个工作流:重新执行、重新搜索或重新训练,无法只针对出错子任务做最小化修正。
  • 缺乏真正的工作流级评估基准,难以区分多代理协作的增益与单代理增强。

为什么这个问题难/重要

构建工作流时需预先确定粒度、代理选择、是否新增专家,但子任务成败在运行后才知晓,形成“先决策-后验证”的固有滞后。并且构建与运行通常使用不同评价信号,导致无法在统一目标下实现增量诊断与修复。业界对自动编排、自我优化 agent 系统的需求快速上升,但无标签、低开销、运行中纠错仍是空白。

行业类比

类似微服务架构中通过调用链成本定位故障,只替换异常服务而非重启整个系统。

核心洞察

  • InFlowOp 用一个无标签的统一成本函数同时驱动多智能体工作流的构建与运行时纠错,实现按故障点付费而非全流程重来。传统方法定位工作流故障通常依赖参考答案、打分模型或额外训练的评估器,且修复往往需要重新执行或重新搜索整个流程;InFlowOp 的成本函数内在地权衡智能体能力匹配程度与运行开销,构建阶段据此决定任务分解粒度和智能体分配,运行阶段发现故障时直接选择成本最低的局部修正动作,避免了全流程级的高昂优化代价,为多智能体系统的高效迭代提供了新思路。
  • InFlowOp 通过双向推理让任务分解粒度与智能体分配从成本中联合涌现,摆脱固定模板的束缚。现有工作流构造通常先按预设模板划分子任务,再为每个子任务挑选智能体,粒度固定且难以适应任务难度;InFlowOp 则从潜在分解与分配组合的成本出发,反向决定是否需要更细的分解、合并子任务或创建新专家,使分解与分配相互适配,从而在构建阶段就优化全局成本,对复杂多变的任务更具工程实用性。

方法

输入

  • 任务描述、候选智能体池 agents
  • 每个智能体的能力画像与运行成本(如延迟、token 消耗)

关键模块

  1. 无标签统一成本函数 cost(agent, subtask):衡量智能体能力与子任务需求之间的匹配度(可靠性成本),并叠加运行开销(延迟成本),形成一个端到端的可比较标量。
  2. 双向构建:在任务分解阶段,不采用固定模板,而是从成本函数出发,同时搜索最优的任务粒度与 agent 分配,使得全流程总成本最小。
  3. 流内动态优化:执行中若某步出错,基于同一成本函数评估局部修复动作(如更换 agent、调整子任务边界、插入重试),选择成本增量最小的操作,避免重跑、重搜索或重训练。

输出

一个按成本最优构建、并能在执行中自适应修正的多智能体工作流。

与同类方法的差异

现有方法通常依赖参考答案、评分器或训练判别器来定位故障,且修复作用于整个工作流(重执行、重新搜索、重训练);InFlowOp 用单一的无标签成本贯穿构建与运行,将故障定位和修复局部化为“最便宜的移动”,大幅降低优化开销,适合生产环境中的持续工作流调优。

实验

实验设计

InFlowOp 在自建基准 Braid 上进行评估,该基准包含需要多代理协调、超出单代理能力的任务,覆盖多个领域与多个 LLM 骨干模型。实验对比单代理基线,并验证工作流构建与流内动态优化的效果。评估指标以任务准确率为主,针对不同答案类型(数值、数学、文本、多选、列表、代码)分别评分。

关键发现

  • InFlowOp 在多个领域和骨干模型上相比单代理基线最高提升 +11.97%,在启用流内优化时整体提升 +9.64%。
  • 通过统一的无标签成本函数,工作流构建时能双向确定任务分解粒度与代理分配,运行中能以最小代价修正故障,大幅降低优化开销。
  • Braid 验证了多代理工作流存在的必要性:许多任务单代理无法完成,需要协调多个专家代理。

与基线对比解读

传统工作流优化通常需要参考答案、人工评分或训练评估器来定位故障,并需重新执行、重新搜索或重新训练整个流程。InFlowOp 的无标签成本无需这些,而是根据代理能力与子任务需求的匹配度以及运行开销来定价。运行时修正仅针对出错节点,采取最廉价步骤,而非整体重启。这使其在性能提升的同时保持低计算和人工成本,相较单代理基线展示了多代理工作流的优势;相较传统优化方法,则更敏捷、可扩展。

行业影响

落地场景

复杂业务流程自动化(如电商订单履约、金融风控报告生成、企业级工单处理)依赖多智能体分工,但工作流构建高度依赖人工经验,调优需要标注数据或训练评估器,成本高且难以及时适应任务变化。InFlowOp 提供标签无关的代价函数,可在运行前双向决定任务分解粒度和智能体分配,运行中通过最便宜的动作动态修复故障,适合智能体能力波动大、任务需求多变的场景。

商业价值

  • 降本:无需参考答案或人工评分,消除标注和再训练开销;运行中用最便宜的修复动作替代全流程重跑,直接节省 token 与 API 费用。
  • 增收:提升任务成功率和吞吐量,使自动化流程能承接更高价值、更复杂的业务。
  • 体验提升:实时纠错带来更稳定的输出,尤其在客服对话、实时风控等用户敏感场景中减少失败率。

与现有产品/工作流的接口

可作为优化中间层嵌入 LangGraph、AutoGen 或自研智能体编排框架,不改变现有智能体接口。只需提供智能体能力描述(如延迟、可靠性)和任务分解历史,InFlowOp 输出调整后的工作流配置或动态修复指令,方便通过 API 或 SDK 集成到 MLOps 流程中。

具体落地 use case

  1. 电商售后自动化工单:意图识别、订单查询、补偿方案生成等多智能体协作。InFlowOp 在运行中判断某智能体能力不足或成本过高,动态替换或细分任务,避免整单失败并减少人工干预。
  2. 内容平台多模态审核流水线:视频分析、文本审核、图片审核智能体串联。InFlowOp 根据实时表现动态调整智能体分配与分解粒度,减少昂贵的全量重审,提高审核效率。

局限

  • label-free 成本函数依赖 agent 能力与任务需求的估计,这些估计可能来自模型自评或启发式,在开放域复杂任务中容易失准,导致分解粒度或 agent 分配不够合理。同时成本中权重(能力匹配与延迟)可能需要人工设定,缺乏自动调节机制。运行时优化采用最便宜的局部移动,可能陷入局部最优,无法进行全局工作流重构,对于需要大幅调整任务分解或重新分配多个 agent 的情况效果有限。
  • 实验对比主要集中在单 agent baseline,缺乏与现有多 agent 工作流构造与优化方法(如 AutoGen、MetaGPT、DyLAN 等)的充分对比,难以全面证明 InFlowOp 相对于同类多 agent 框架的优势。此外,论文未报告在不同 backbone 下的统计显著性检验,可能影响结论稳定性。
  • Braid 基准虽然针对工作流级评估设计,但任务领域可能偏重推理、数学、编码等文本任务,对其他类型(如多模态、长程规划、环境交互等)覆盖不足。且基准中部分任务可能单 agent 也能完成,多 agent 必要性验证不够严格,可能高估工作流方法收益。数据规模有限,需扩展以增强评估可靠性。
论文Xuehang Guo2026-10-01原文

相关内容