当前位置：首页 > news >正文

SkillFlow: Flow-Driven Recursive Skill Evolution for Agentic Orchestration

news 2026/6/18 0:18:44

论文阅读：SkillFlow：面向 Agentic Orchestration 的流驱动递归技能演化

论文标题：SkillFlow: Flow-Driven Recursive Skill Evolution for Agentic Orchestration
作者：Mingda Zhang, Tiesunlong Shen, Haoran Luo, Wenjin Liu, Zikai Xiao, Erik Cambria, Xiaoying Tang
发表位置：arXiv preprint，cs.AI
arXiv 编号：arXiv:2605.14089v1
原文链接：arXiv:2605.14089
主题：LLM Agent、任务编排、GFlowNet / Flow-based Training、技能库演化、信用分配
核心问题：如何让 LLM Agent 在多步任务编排中既能从任务反馈中学习，又能保留多样化策略，并利用训练信号自动更新技能库。

1. 论文要解决什么问题？

这篇论文关注的是 agentic orchestration，也就是让 LLM Agent 把一个复杂任务拆成多步操作，并在过程中选择工具、调用技能、读取反馈，最后完成任务。

在很多 Agent 系统中，任务不再是单轮问答，而是一个连续决策过程。例如：

问答任务中，模型可能需要检索、比较、整合证据；
数学任务中，模型可能需要分阶段推理和校验；
WebShop、ALFWorld 这类交互任务中，模型要根据环境反馈不断调整动作；
SWE-bench 这类代码任务中，模型要搜索文件、阅读代码、修改、验证。

论文认为，已有任务编排方法主要有三类问题。

第一类是 策略塌缩。如果用 REINFORCE 或 GRPO 一类策略梯度方法，只根据最终奖励更新整条轨迹，那么训练会倾向于把概率质量集中到某一条高奖励轨迹上。这样虽然可能找到一条有效路线，但会损失其他同样可行的策略，一旦任务表面形式、执行器能力或环境反馈发生变化，Agent 容易失去备用解法。

第二类是 信用分配不透明。多步 Agent 任务通常只有终局奖励：最后答对了、任务成功了、代码修好了，才知道整条轨迹好不好。但一条成功轨迹中，并不是每一步都同等重要；失败轨迹中，也不一定每一步都有问题。只用终局奖励很难判断到底是哪一步真正推动了成功，哪一步只是偶然经过。

第三类是 技能演化缺少原则性信号。一些 Agent 框架会维护技能库，允许系统生成、修正或删除技能。但什么时候需要更新技能库？应该新增什么技能？哪些技能应该保留、改写或剪枝？很多方法依赖固定周期、启发式规则，或直接让 LLM 充当 judge。论文认为，这些做法没有把技能演化和训练信号真正闭环起来。

SkillFlow 的目标就是把这三件事合在一起解决：
用 flow-based training 学会多样化编排策略，用后向策略提供逐步信用分配，再用这些 flow 诊断信号驱动技能库递归演化。

2. 背景：为什么任务编排可以看成一张 DAG？

论文把 Agent 的任务编排过程建模为一个有向无环图。

每个节点表示一个交互历史 $H_t$。这个历史包含当前任务、已选技能、模型中间推理、动作、执行器返回的观察等信息。每条边表示一次编排动作，也就是从 $H_{t-1}$ 走到 $H_t$。

一次完整任务执行就是从初始状态 $H_0$ 到终止状态的一条轨迹：

$$
\tau = {(r_t, a_t, o^{{exec}*t)}*{t=1}} \Rightarrow y_q
$$

其中：

$r_t$ 是 Supervisor 在第 $t$ 步生成的推理或反思；
$a_t$ 是动作，包括动作类型和参数；
$o^{exec}_t$ 是执行器返回的反馈；
当动作类型为 accept，或达到最大步数时，轨迹终止。

论文中的动作类型主要包括三类：

动作类型	含义
`skill`	调用技能库中的某个技能或策略提示
`act`	执行具体外部动作，例如检索、浏览、修改代码、环境操作
`accept`	接受当前结果并终止任务

由于每一步都会把新的推理、动作和反馈追加到历史中，状态历史严格增长，因此这个编排过程可以自然形成无环结构。

这一步建模很重要，因为 SkillFlow 后面要在这个编排 DAG 上引入 flow。直观来说，flow 不是只找一条最优路径，而是给不同轨迹分配流量，使高奖励轨迹获得更多流量，同时仍然保留多条高质量路径。

3. 从“最大化奖励”到“按奖励比例采样”

传统强化学习常见目标是让模型更偏向最高奖励轨迹。SkillFlow 使用的是另一种目标：让轨迹采样概率与奖励成比例。

论文写作：

$$
\pi^*(\tau \mid q) \propto \tilde{R}(\tau)^\beta
$$

其中：

$R(\tau)$ 是轨迹最终任务完成质量；
$\tilde{R}(\tau)=R(\tau)+\epsilon_{min}$，用于保证奖励为正；
$\beta$ 控制质量和多样性的权衡。

这个目标的含义是：如果几条轨迹都能得到较高奖励，模型不应该只记住其中一条，而应该保留这些高奖励路径的分布。奖励越高，采样概率越大；但只要奖励不是零，轨迹仍有可能保留一定 flow。

这与论文所批评的策略塌缩形成对比。SkillFlow 并不是简单追求单一最优路径，而是希望学习一个“高奖励轨迹族”。

【Figure 1（训练前后 orchestration DAG 上 flow 分布变化）】

4. SkillFlow 总体框架

SkillFlow 采用 Supervisor-Executor 范式。系统里有一个可训练的 Supervisor，以及一个结构化环境 $E$：

$$
E = (S, \Psi, M_{exec})
$$

其中：

组件	作用
$S$	动态技能库，存放可复用的技能或策略提示
$\Psi$	Skill Creator，根据轨迹证据创建或更新技能
$M_{exec}$	冻结的执行器，负责执行动作并返回反馈

Supervisor 是训练对象。它每一步根据当前历史状态生成推理、选择动作类型，并产生动作参数。执行器本身是冻结的，论文重点不是训练执行器，而是训练“如何组织、选择和演化技能”。

初始状态 $H_0$ 由三部分组成：

当前任务 $q$；
检索到的技能 $S_{ret}$；
任务类别相关的编排指南 $\omega_q$。

之后，Supervisor 与环境多轮交互，直到输出最终答案或达到步数预算。

【Figure 3（SkillFlow 架构：Supervisor、Executor、TTB、flow diagnostics 和技能演化闭环）】

5. 核心方法一：Tempered Trajectory Balance

SkillFlow 的核心训练目标是 Tempered Trajectory Balance，TTB。

TTB 来源于 trajectory balance 的思想。它要求一条轨迹上的前向概率、后向概率、归一化项和最终奖励之间满足某种平衡关系。论文不只是训练前向 policy，还同时训练一个后向 policy。

前向策略 $P_F$ 的角色是：
在当前状态下，Supervisor 应该选择什么动作。

后向策略 $P_B$ 的角色是：
在看到执行结果之后，回过头判断某一步动作是否合理。

两者的关键区别在于信息可见性：

前向策略做决策时，还没有看到当前动作的执行反馈；
后向策略进行 hindsight 判断时，可以看到执行器返回的反馈。

这种信息不对称正是逐步信用分配的来源。当前向策略觉得某动作合理，但后向策略在看到反馈后对它评价明显变化，说明这一步可能是关键决策点。

TTB 的训练损失可以理解为一个回归式 residual。训练目标不是直接用高方差的 policy gradient 把整条轨迹往上推或往下压，而是让轨迹满足 flow balance 条件。论文认为，这种 regression-style 的 flow-matching loss 有两个好处：

它让轨迹分布趋向奖励比例分布，而不是塌缩到单一最大值；
它自然训练出一个后向策略，为每一步提供信用归因信号。

6. 核心方法二：逐步信用分配

在 TTB 收敛时，论文从 detailed balance 中得到一个 step importance：

$$
I(t)=\frac{F(H_t)}{F(H_{t-1})}
=\frac{\pi_\theta(a_t \mid r_t,H_{t-1})}
{P_\phi(a_t \mid H_{t-1}\oplus o^{exec}_t)}
$$

直观解释是：

分子是 Supervisor 在执行前选择该动作的概率；
分母是后向策略在看到执行反馈后，对这一步动作的 hindsight 概率；
二者的差异反映了执行反馈对这一步评价的改变。

论文使用 $|\log I(t)|$ 来标记关键步骤。值越大，表示这一步在执行前后的评价差异越明显，也就越可能是决定成功或失败的关键步骤。

这一点与普通终局奖励不同。终局奖励只能告诉我们“整条轨迹好不好”，而 $I(t)$ 试图告诉我们“哪一步最值得解释、修正或沉淀为技能”。

7. 核心方法三：技能边际流与递归技能演化

除了对单步动作做信用分配，SkillFlow 还计算每个技能的 marginal flow。

论文定义技能边际流 $\hat{F}(s)$，用来衡量某个技能在被调用时吸引了多少 flow。直观上，一个技能如果经常出现在高 flow、高奖励轨迹中，它就更可能是有用技能；如果某个技能贡献稳定但上下文依赖不一致，可能需要 refine；如果长期贡献为负，则可能需要 prune。

SkillFlow 的技能演化主要回答三个问题。

7.1 When：什么时候演化？

SkillFlow 使用 TTB residual 的 plateau 作为触发信号。

如果当前技能库和策略能力足够表达奖励比例 flow，那么训练 residual 应该可以继续下降。如果 residual 在某个水平附近饱和，说明当前技能库可能已经成为瓶颈。此时系统进入下一阶段，触发技能库更新。

也就是说，技能演化不是固定间隔发生，也不是随意让 LLM judge，而是由训练残差是否达到当前库的表达上限来驱动。

7.2 What：演化什么技能？

论文根据技能的 flow 统计量，把技能分成几类：

类别	含义
retain	高贡献且稳定，直接保留
refine	有贡献但上下文表现不稳定，需要改写
prune	长期负贡献或低贡献，删除
generate	在关键决策空缺处生成新技能

这里的技能不是完整长程序，而是论文所说的 atomic tip：短小、独立、可组合的策略提示。这样做的目的，是避免技能库变成冗长、难组合的经验堆积。

7.3 Where：在哪里生成新技能？

新技能来自高 $|\log I(t)|$ 的关键步骤，尤其是同一问题上的成功轨迹和失败轨迹对比。

例如，如果成功轨迹都在某个阶段执行了“搜索 → 编辑 → 验证”，而失败轨迹反复停留在搜索或查看文件，没有进入有效修改，那么这个差异就可以转化为新的代码生成 tip。Skill Creator $\Psi$ 使用这类轨迹证据，在 phase boundary 处生成新的原子技能。

因此，SkillFlow 的技能演化闭环可以概括为：

TTB residual 告诉系统什么时候当前库不够用了；
step importance 告诉系统关键决策缺口在哪里；
skill marginal flow 告诉系统哪些技能该保留、改写或删除。

8. 实验设置

论文在 14 个 benchmark 上评估 SkillFlow，覆盖四类任务：问答、数学推理、代码生成和真实交互决策。

实验分为 IID 和 OOD 两组。

设置	数据集
IID	HotpotQA, TriviaQA, MedQA, AIME 2026, WebShop, ALFWorld, SWE-bench
OOD	MuSiQue, NQ-Open, MATH-Hard, GPQA Diamond, HumanEval, ScienceWorld, Mind2Web

对比方法包括：

直接 LLM：Qwen3.5-9B, v4-flash, Claude Haiku 4.5；
微调和 RL：SFT, GRPO；
搜索式 workflow：AFlow；
Agent RL 和技能演化基线：AgentFlow, FlowSteer, SkillRL；
额外算法比较：GRPO, Tree-GRPO, HCAPO。

评价指标随任务类型不同而变化：

任务类型	指标
QA	EM / F1
AIME、MedQA、MATH、GPQA	Accuracy
WebShop、ALFWorld	Average Score / Success Rate
SWE-bench	Resolved Rate
HumanEval	pass@1
Mind2Web	Step Accuracy / Action F1

9. 主要结果

论文报告 SkillFlow 在 14 个 IID 和 OOD benchmark 上均取得领先。作者强调，SkillFlow 使用 Qwen3.5-9B 作为 Supervisor，但结果超过了一些更强的直接 LLM baseline，因此提升主要来自 orchestration policy 的训练方式，而不只是 backbone 能力。

部分主结果如下。

数据集 / 指标	Qwen3.5-9B	强基线示例	SkillFlow
HotpotQA EM	60.94	FlowSteer 89.84	92.19
TriviaQA EM	44.88	AFlow 92.97	96.09
AIME 2026 Acc.	46.67	FlowSteer 63.33	70.00
WebShop SR	32.03	SkillRL 82.81	93.75
ALFWorld SR	48.28	SkillRL 85.16	96.09
SWE-bench Resolved	17.19	FlowSteer 43.75	52.34
MuSiQue EM	39.06	FlowSteer 79.69	85.16
NQ-Open EM	21.88	FlowSteer 80.47	82.81
GPQA Diamond Acc.	61.72	FlowSteer 84.38	89.84
HumanEval pass@1	89.06	FlowSteer 93.75	98.44
ScienceWorld Success	25.78	FlowSteer 47.66	57.81
Mind2Web Step Acc.	26.64	FlowSteer 41.41	51.56

从结果分布看，SkillFlow 在交互式任务和多步任务上的提升尤其明显，例如 WebShop、ALFWorld、SWE-bench、ScienceWorld 和 Mind2Web。论文将这一点解释为：这些任务更依赖编排策略、关键步骤识别和技能库适配，因此更能体现 TTB、后向信用分配和技能演化的作用。

在 OOD 设置中，论文把训练结束后的技能库冻结，再测试未见数据集。SkillFlow 仍然保持领先。作者据此认为，演化出的技能不是单纯记住训练 benchmark，而是捕获了一些可迁移的 orchestration primitives。

10. Backbone 迁移性

论文还把 Supervisor 替换为多个 proprietary LLM backbone，比较这些模型在使用 SkillFlow 前后的表现。

Figure 4 的结论是：SkillFlow 对不同 backbone 都有提升，而且较弱 backbone 的提升更明显。论文给出的解释是，显式信用分配和多样性保留能缓解弱模型在基础编排能力上的不稳定；而对强模型来说，SkillFlow 仍能在 Agent-style 任务中带来收益，因为这些任务的瓶颈不只是单步回答能力，而是多步组织能力。

【Figure 4（不同 backbone 上有无 SkillFlow 的性能对比）】

11. 消融实验

论文的消融实验分别移除 TTB、后向策略，以及技能演化中的 when / where / what 信号。

部分结果如下。

变体	Hotpot EM	Trivia EM	AIME Acc.	WebShop SR	ALFWorld SR	SWE Resolved	MuSiQue EM	Mind2Web Step Acc.
- TTB	83.59	87.50	53.33	82.03	82.81	40.63	73.44	33.59
- Backward policy	85.94	90.63	53.33	80.47	88.28	43.75	75.00	36.72
- TTB residual for when	82.81	84.38	60.00	83.02	85.93	46.88	75.78	40.63
- I(t) for where	85.16	88.26	63.33	87.50	90.63	44.53	78.13	42.97
- F̂(s) for what	84.38	82.03	50.00	79.69	80.47	42.20	76.56	42.19
SkillFlow 完整版	92.19	96.09	70.00	93.75	96.09	52.34	85.16	51.56

论文从这组实验得出三个结论。

第一，移除 TTB 后，多样性敏感任务下降明显，说明策略塌缩是一个关键失败模式。

第二，移除后向策略后，多步任务下降更明显，说明 hindsight backward policy 对关键步骤识别有作用。

第三，技能演化中的 when、where、what 三类信号各自都不可替代。只要拿掉其中一类，性能都会下降。

12. 与其他 RL 算法和技能演化方法的比较

论文进一步在相同 backbone 和训练数据下比较 SkillFlow、GRPO、Tree-GRPO 和 HCAPO。

方法	Hotpot EM	Trivia EM	AIME Acc.	WebShop SR	ALFWorld SR	SWE Resolved
Qwen3.5	60.94	44.88	46.67	32.03	48.28	17.19
GRPO	83.59	87.50	53.33	82.03	82.81	40.63
Tree-GRPO	87.50	93.75	60.00	85.94	90.92	48.44
HCAPO	85.94	93.75	63.33	87.50	92.19	47.24
SkillFlow	92.19	96.09	70.00	93.75	96.09	52.34

成本方面，论文报告 SkillFlow 在 collection、每轮耗时和每条轨迹耗时上也有优势：

方法	collect	s/turn	s/traj
GRPO	216.8	1.79	35.6
HCAPO	137.6	1.72	48.1
Tree-GRPO	162.8	1.99	45.1
SkillFlow	130.5	1.13	33.9

论文将这种成本优势归因于 flow signal 驱动的技能演化：系统不是盲目生成或审查大量技能，而是在 TTB plateau 和关键步骤信号出现时进行针对性更新。

【Figure 5（算法比较、成本、演化事件、Pass@K 和 reward curves）】

13. 论文指出的局限性

论文在 Appendix R 中讨论了 SkillFlow 的适用范围。

第一，SkillFlow 依赖 backbone 的长上下文能力。多轮编排会持续扩展历史 $H_t$，后向策略也需要基于越来越长的上下文进行 hindsight 判断。如果基础模型对长上下文的保持和利用能力较弱，那么逐步信用信号可能随轨迹变长而退化。

第二，SkillFlow 不能替代 backbone 本身的基础推理能力。它主要提升的是 orchestration，也就是如何拆解、选择技能、使用工具和根据反馈调整；如果任务瓶颈是模型本身完全不会某类推理，那么还需要额外预训练、蒸馏或其他能力增强方法。

此外，论文 checklist 中还把 frozen executor 假设、正奖励要求与 $\beta$ 调参、技能库规模扩展等列为需要注意的限制范围。也就是说，SkillFlow 的贡献集中在“用 flow-based training 驱动任务编排和技能演化”，而不是解决执行器训练、长上下文建模或基础推理能力不足的全部问题。