(2606) SIRI: Self-Internalizing Reinforcement Learning with Intrinsic Skills for LLM Agent Training

🌺 论文摘要

SIRI 论文摘要

参考链接

• paper, code

核心方法

• SIRI：让Agent自己挖Skill、验证Skill、再把Skill内化到模型参数。
• 三阶段训练：
  • Policy Warmup：先用GiGPO把Policy训到能产生可靠成功轨迹。
  • Self-Skill Mining：只从自己的成功轨迹中总结Skill，不依赖外部Skill生成器。
  • Skill Internalization：把真正有效的Skill轨迹蒸馏回Plain-Prompt Policy。
• Skill有效性验证：同一个任务同时做带Skill/不带Skill的配对Rollout，只有能提高Reward的Skill才保留。
• 最终部署：训练完丢掉Skill Bank + Retriever，推理时不再注入Skill。

模型效果 (Qwen2.5-7B-Instruct)

• ALFWorld：SIRI Success 0.930，高于GiGPO 0.908和SkillRL 0.899。
• WebShop：SIRI Score / Success 0.899 / 0.813，高于GiGPO 0.844 / 0.728和SkillRL 0.852 / 0.727。
• 论文没有在AppWorld上做实验，AppWorld只作为长程Agent RL相关背景引用。

重要结论

• Skill可以只做训练期Privileged Information，不一定要在推理时继续检索。
• 先Warmup很重要：从未训练Policy的低质量轨迹里总结Skill，反而会污染后续学习。
• 不能整条轨迹无脑蒸馏：
  • Trajectory层面先判断这个Skill是否真的有用。
  • Action层面只学习正优势的可执行Action Token。
• 外部强模型生成Skill主要帮助训练早期；Policy变强后，自挖掘Skill可以逐渐追上。

关键贡献

• 提出无需外部Skill Generator的自挖掘Skill RL流程。
• 提出Advantage-Weighted Skill Internalization，使最终Agent实现Retrieval-Free Inference。
• 将RL Credit用于两个对象：既优化Action，也评估“哪个Skill值得被内化”。

问题背景(外部Skill依赖)

❓问题背景

Skill增强Agent的两类依赖

训练依赖

• 现有方法常使用外部LLM、独立Trajectory Distiller或Skill Manager生成Skill。
• 训练效果部分来自辅助模型，而非Agent自身能力演化，增加工程和计算成本。

推理依赖

• Skill长期保存在Skill Bank中，每个任务都要检索并注入Prompt。
• 带来更长Context、检索延迟和额外部署组件，也会造成Train/Inference接口不一致。

核心问题

• Agent能否在RL中自己发现Skill、验证Skill，并将其吸收进Policy参数，使部署时完全不需要Skill Bank？

核心方法(SIRI三阶段课程)

📕核心方法

Phase 0: Policy Warmup

• 使用GiGPO训练Plain-Prompt Policy，获得基本交互能力。
• GiGPO同时提供Episode-level Advantage和Anchor-state Step-level Advantage。
• 只有无Skill Rollout且Return超过成功阈值的轨迹，才进入后续Skill Mining。
• 当成功轨迹数量达到阈值，或Warmup达到最大步数时，进入下一阶段。

作用

• 避免错误Skill：未训练Policy中的偶然成功，很容易被误总结成通用经验。
• 提供高质量经验：先获得足够多的成功轨迹，再进入Skill Mining。

Phase 1: Self-Skill Mining and Utilization

Self-Mining

• 冻结当前Policy的Snapshot，从成功Plain Rollout中总结Condition-Strategy形式的自然语言Skill。
• Skill状态包括candidate / active / retired，并记录在线效用、检索次数和适用场景。

Paired Validation

• 同一任务组一半使用Skill，一半不使用Skill。
• Skill宏观效用定义为两组平均回报差：

$${\mathrm{\Delta }}_g=R_g^{skill}-R_g^{base}$$

• 用EMA更新Skill效用；检索次数足够且效用为正的Skill才升级为Active，持续负效用Skill被Retire。

Phase 2: Advantage-Weighted Skill Internalization

Teacher / Student共享参数、输入不同

• Teacher使用Skill-Augmented Context生成Action。
• Student在Plain Context下学习复现Teacher Action。

两层过滤

1. Trajectory Utility Gate：仅当 ${\mathrm{\Delta }}_g>0$ 时，才蒸馏Skill分支轨迹。
2. Action Advantage Weight：只蒸馏可执行Action Token，并按GiGPO正优势加权；Reasoning文本和低优势Action不进入Internalization Loss。

也就是说：先回答这个Skill有没有用，再回答轨迹里的哪些Action值得学。

联合目标

$$L_{total}=L_{GiGPO}+\beta L_{KL}+\lambda (k)L_{int}$$

• 训练结束后丢弃Skill Bank，推理只使用原始任务Prompt。

实验设置

✍️实验设置

实验设置

基础模型

• Qwen2.5-7B-Instruct，附加实验验证Qwen2.5-1.5B。

训练与评测环境

• ALFWorld：6类具身家务任务。
• WebShop：长程商品搜索与购买任务。
• 未评测AppWorld，因此不能把SIRI数值与AppWorld方法直接比较。

训练配置

• 8张A100 80G；每批16个任务，Group Size 8。
• Warmup最少30步、最多50步；每10步进行Skill Mining和验证。
• Retriever使用Qwen3-0.6B-Embedding。

关键结果

🍑关键结果

模型效果与消融

主结果

• ALFWorld Overall：SIRI 0.930 > GiGPO 0.908 > SkillRL 0.899。
• WebShop Success：SIRI 0.813 > GiGPO 0.728 ≈ SkillRL 0.727。
• WebShop Score：SIRI 0.899 > SkillRL 0.852 > GiGPO 0.844。

消融 (WebShop)

• 去掉Warmup：Score / Success为0.850 / 0.711，说明低质量初始轨迹会污染Skill Mining。
• 去掉Internalization但推理继续带Skill：0.898 / 0.805，说明Skill Bank本身质量较高。
• 去掉Internalization且推理不带Skill：0.852 / 0.719，说明Policy尚未自动吸收外部Skill。
• 完整SIRI：0.899 / 0.813，在不带Skill推理时反而最好。

GRPO兼容性

• SIRI不仅适用于GiGPO；基于GRPO也把WebShop Success从0.568提升到0.648。
• 但GiGPO更细粒度的Credit Assignment能提供更好的Warmup轨迹，最终上限更高。

未来方向

⛳未来方向

未来展望

• 当前Skill Mining能力只是随Policy整体能力间接提升，没有专门优化“如何总结Skill”的训练信号。
• 需要在AppWorld等API交互环境验证自挖掘与无检索部署是否仍有效。
• Skill Utility依赖少量配对Rollout，未来可研究更低方差、更节省环境交互的在线评估。
• 可进一步研究与Skill-SD的差异：SIRI选择性蒸馏Action Token，Skill-SD则使用跨Prompt Importance-Weighted Reverse-KL。

(2606) GVPO: Group Verification-based Policy Optimization for Interactive Coding Agents

🌺 论文摘要

GVPO 论文摘要

参考链接

• paper

核心方法

• GVPO：最终Unit Test奖励 + 中间代码执行反馈。
• AppWorld每一步代码执行都会返回成功 / Syntax Error / Runtime Exception，这些都是免费的Process Reward Signal。
• Advantage Shaping：
  • 最终Unit Test仍决定整条Trajectory好不好。
  • 中间失败Step再做局部惩罚，避免错误代码也被正向强化。
• 训练细节：Sequence-Mean-Token-Mean + 非对称Clip + 不除以组内std + 去掉KL。
• 不需要训练额外的Reward Model。

模型效果 (Qwen2.5-32B-Instruct, AppWorld)

• Test-N：TGC 72.6 / SGC 55.4。
• Test-C：TGC 49.4 / SGC 28.8。
• 相比LOOP，在Test-C提升+3.7 TGC / +2.2 SGC；相比OpenAI o1提升+12.7 TGC / +9.4 SGC。

重要结论

• Outcome-only的Credit太粗：成功轨迹里的错误Step也会被奖励，失败轨迹里的正确探索也会被一起惩罚。
• 环境报错可以把Trajectory-level Credit进一步细化到Step-level。
• GVPO学出了更谨慎的Query-before-Act行为：先查API文档，再真正执行，Step失败率更低。
• 惩罚不能太大：过强Process Penalty会让Agent不敢探索，论文中 $b=0.2$ 最稳。

关键贡献

• 提出统一Outcome与Process Verification的Agent RL Advantage Shaping框架。
• 在不引入额外Reward Model的情况下实现Step-level Credit Assignment。
• 系统验证Loss Aggregation、Asymmetric Clip、Std Normalization和Shaping形式对AppWorld训练的影响。

问题背景(Outcome Reward过于稀疏)

❓问题背景

GRPO对长程Agent的Credit Assignment不足

Outcome-only RLVR

• AppWorld最终通过Unit Test给出任务级奖励，但奖励只在轨迹结束后出现。
• GRPO将同一条Trajectory的Group-relative Advantage广播给所有Token。

两类错误Credit

• 成功轨迹：可能包含语法错误、错误API和多余重试，但这些Step仍得到正优势。
• 失败轨迹：可能包含正确探索或正确API调用，但所有Token又被一起负向更新。

被忽略的环境信号

• Interactive Coding Agent每轮都会执行代码，环境天然返回成功、异常和错误信息。
• 这些反馈比最终Unit Test更密集、可验证，却没有被标准GRPO纳入Advantage。

核心方法(Outcome + Process Advantage Shaping)

📕核心方法

Outcome-Verifiable Reward

• 每个AppWorld任务包含 $M$ 个状态Unit Test。
• Trajectory Reward为通过测试的比例：

$$R_i=\frac{1}{M}\sum _{j=1}^M\mathrm{pass}(u_j,{\tau }_i)$$

• Group-relative Outcome Advantage使用去均值但不除以标准差：

$${\hat{A}}_{i,t}=R_i-\mathrm{mean}(\{R_i{\}}_{i=1}^G)$$

Process-Verifiable Advantage Shaping

• 将生成Token分为执行成功Step的 $I_i^{succ}$、执行失败Step的 $I_i^{fail}$；Observation Token不参与更新。
• 成功Step保持原Outcome Advantage。
• 失败Step根据Trajectory Outcome做不同修正：
  • $\hat{A}=0$：施加固定惩罚 $-b$。
  • $\hat{A}<0$：放大负优势为 $(1+b)\hat{A}$。
  • 其他情况：置0，避免成功Trajectory中的失败Token得到正强化。
• 论文使用 $b=0.2$。

GVPO目标

$$J_{GVPO}=\frac{1}{G}\sum _i\frac{1}{|{\tau }_i|}\sum _{t}min(a_{i,t}{A}_{i,t},\mathrm{clip}(a_{i,t},1-{ϵ}_{low},1+{ϵ}_{high})A_{i,t})$$

• 使用非对称Clip $(0.2,0.28)$，给正向概率更新更大空间以维持探索。

实验设置

✍️实验设置

实验设置

基础模型

• Qwen2.5-32B-Instruct。

训练任务/数据

• AppWorld Difficulty 1/2：72个任务，24个Scenario。
• 每个任务8条Rollout；最大40轮交互。

评测任务/数据

• AppWorld Test-Normal：168个任务、56个Scenario。
• AppWorld Test-Challenge：417个任务、139个Scenario，最大50轮交互。
• 指标：TGC与SGC。

算法/策略

• 与GRPO、GRPO+KL、GSPO、DAPO、Dr.GRPO、RLOO和LOOP比较。
• 使用Unit Test Outcome Reward；GVPO额外使用中间代码执行反馈。

超参

• Group Size 8，Learning Rate $1\times {10}^{-5}$，训练144步。
• Training/Eval Temperature：1.0 / 0.0。
• 8张H100，veRL + FSDP2 + vLLM。

关键结果

🍑关键结果

AppWorld主结果

方法	Test-N TGC / SGC	Test-C TGC / SGC
GRPO	61.3 / 39.3	38.5 / 21.6
Dr.GRPO	63.7 / 44.6	40.5 / 18.7
LOOP	71.3 / 53.6	45.7 / 26.6
GVPO	72.6 / 55.4	49.4 / 28.8

设计消融

• Loss聚合很重要：改为Token-Mean，Test-C直接降到34.6 / 15.1。
• 非对称Clip有效：改回Symmetric Clip后降到40.5 / 21.6。
• 不要除以组内std：加回Std Normalization后降到42.8 / 23.7，和LOOP结论一致。
• Shaping形式也重要：只用Additive Shaping时降到39.8 / 23.0。
• Sequence-Mean-Token-Sum为42.8 / 23.7，也低于完整GVPO。

行为变化

• GVPO的每Step执行失败率约0.03，低于Dr.GRPO 0.05和GRPO 0.08。
• GVPO更频繁调用show_api_docs与show_api_descriptions，形成“先查文档、再行动”的策略。
• GVPO交互数略高于Dr.GRPO，但低于GRPO，说明谨慎策略减少了后续纠错循环。

未来方向

⛳未来方向

未来方向

• GVPO依赖确定性环境和可明确识别的Process Signal；噪声反馈、模糊成功标准下尚未验证。
• 失败Step当前只按执行成功/失败二分，未来可加入Partial Test、状态变化和更细错误类型。
• Advantage Shaping后不再满足零均值无偏性质，需要进一步分析长期训练稳定性与偏差。
• Process Penalty会改变Agent行为偏好，应研究如何避免过度查询文档或过度保守。

(2604) Skill-SD: Skill-Conditioned Self-Distillation for Multi-turn LLM Agents

🌺 论文摘要

Skill-SD 论文摘要

参考链接

• paper

核心方法

• Skill-SD：GRPO结果奖励 + Skill条件下的Token级自蒸馏。
• 从Agent自己的Trajectory中总结三类Skill：成功经验、错误教训、高层Workflow。
• Skill只给Teacher看：
  • Student始终使用Plain Prompt做On-policy Rollout。
  • Teacher额外看到Skill，并给同一条Token序列重新打分。
• Teacher参数从最新Student同步，使用Importance-Weighted Reverse-KL把Skill信息蒸馏回Student。
• 测试时Student不需要Skill，避免Train/Test Prompt不一致。

模型效果 (Qwen3-4B-Instruct-2507)

• AppWorld 57-task Dev：Accuracy 64.9，Completion 84.9。
• Vanilla GRPO：Accuracy 50.9，Completion 76.3；Skill-SD提升+14.0 Accuracy。
• Skill直接注入Student的Skill-Augmented GRPO只有42.1 Accuracy，低于Vanilla GRPO。

重要结论

• Skill应该指导Teacher，而不是直接喂给Student：否则容易过拟合Skill Prompt，并造成Train/Test条件不一致。
• Rollout必须由Student产生：Teacher自己采样会变成Off-policy，训练中期容易Collapse。
• Teacher不能冻结：Frozen Teacher虽然不崩，但会逐渐落后于Student，最终平台更低。
• 蒸馏不能替代RL：
  • RL回答哪条Trajectory值得学。
  • Self-Distillation回答轨迹里哪些Token如何学得更细。

关键贡献

• 用Trajectory-derived Skill替代Agent任务中不存在的唯一Ground-truth Answer，构造动态Teacher Signal。
• 推导跨Prompt自蒸馏的Importance-Weighted Reverse-KL，修正直接微分 $k_3$ 的梯度偏差。
• 证明动态Teacher-Student共演化和On-policy采样对长程Agent自蒸馏不可缺少。

问题背景(稀疏奖励与固定Teacher Signal)

❓问题背景

Agent任务难以直接套用Self-Distillation

RL样本效率问题

• AppWorld等长程任务只有延迟Outcome Reward，很难判断哪些Action Token真正有用。
• On-policy Self-Distillation可以用Teacher提供Dense Token Supervision，但通常假设存在固定正确答案。

Agent任务的多解性

• 同一个AppWorld任务可以通过不同API顺序完成，不存在唯一标准Trajectory。
• 固定参考答案会限制Student探索，并把一种实现路径误当成唯一正确策略。

训练稳定性问题

• Teacher与Student看到不同Prompt，Token分布存在Cross-Prompt Mismatch。
• 若Teacher自己生成Rollout，随着Student更新，Off-policy Importance Ratio会逐渐失稳。

核心方法(Skill-Conditioned Self-Distillation)

📕核心方法

Trajectory-derived Skill与UCB检索

• Agent完成任务后，辅助LLM将Trajectory总结为：
  • $e_{success}$：哪些行为有效。
  • $e_{mistake}$：哪些错误需要避免。
  • $e_{workflow}$：下次可复用的高层流程。
• 不存储完整Trajectory，避免单一路径约束多解任务。
• 每个任务维护自己的Skill Buffer，通过UCB在利用高回报Skill和探索新Skill之间平衡：

$$score(e)=\overline{r}(e)+c\sqrt{\frac{\ln N_{ucb}}{n(e)}}$$

Teacher/Student分离

• Student Policy：${\pi }_{\theta }^{stu}(\cdot |x,y_{<t})$，仅看Plain Prompt，并负责On-policy Rollout。
• Teacher Policy：${\pi }_{\overline{\theta }}^{tea}(\cdot |x\oplus S(x),y_{<t})$，额外看到检索Skill。
• Teacher在每次Iteration从最新Student同步，Skill只改变条件Context，不进入测试时Student接口。

作用分工

• GRPO：根据Trajectory Reward决定哪条轨迹值得强化。
• Self-Distillation：决定轨迹内部的Token概率如何移动。

Importance-Weighted Reverse-KL

• 对Student On-policy生成的同一Token序列，分别用Plain Student和Skill Teacher重新计算Log Probability。
• 定义Student/Teacher Log Ratio：

$${\ell }_{i,t}=\log {\pi }_{\theta }^{stu}(y_{i,t}|x,y_{i,<t})-\log {\pi }_{\overline{\theta }}^{tea}(y_{i,t}|x\oplus S(x),y_{i,<t})$$

• 使用On-policy Importance Weight ${\rho }^{on}$ 修正采样分布，并优化：

$$L_{SDL}=\frac{1}{N}\sum _{i,t}{\rho }_{i,t}^{on}(e^{-{\ell }_{i,t}}-1+{\ell }_{i,t})$$

• 总目标：$L_{total}=L_{GRPO}+\lambda L_{SDL}$，论文最优 $\lambda =0.001$。

实验设置

✍️实验设置

实验设置

基础模型

• Qwen3-4B-Instruct-2507。

AppWorld

• 训练：公开的90个训练任务。
• 评测：57个Dev任务，最大40轮。
• Reward：任务Unit Test完成比例；报告Accuracy/Pass@1与Completion Rate。

Sokoban

• 训练96个6×6、2箱子关卡；测试64个较难关卡。
• 与AppWorld形成互补：AppWorld错误可恢复，Sokoban错误通常不可逆。

基线

• Base Model、Vanilla GRPO、Skill-Augmented GRPO、Vanilla OPD。

关键结果

🍑关键结果

模型效果与消融

方法	AppWorld Acc. / Comp.	Sokoban Acc. / Comp.
Base Model	8.8 / 39.1	12.5 / 32.0
Vanilla OPD	22.8 / 59.7	21.9 / 37.5
Vanilla GRPO	50.9 / 76.3	51.6 / 68.8
Skill-Augmented GRPO	42.1 / 76.1	20.3 / 37.5
Skill-SD	64.9 / 84.9	62.5 / 71.1

On-policy与Dynamic Teacher

• On-policy + Frozen：AppWorld Accuracy 49.1，比完整方法低15.8点。
• Off-policy + Frozen：45.6，训练中期Collapse。
• Off-policy + Dynamic：42.1，同样Collapse。
• Sokoban的Off-policy Collapse更严重，说明任务越不可逆，分布偏移代价越高。

Skill直接注入为何失败

• Skill-Augmented GRPO训练集Accuracy很高，但AppWorld验证只有42.1，表现出明显过拟合。
• 训练优化的是Skill条件Policy，评测却使用无Skill Policy，两者共享参数但目标不一致。

效率

• Trajectory总结异步执行，API调用与Rollout/Update重叠，减少训练主路径等待。

未来方向

⛳未来方向

未来展望

• 当前按Task-local UCB检索单个Skill，Skill库扩大后可研究Embedding或Learned Retriever。
• 只在采样Token上做Distillation，未来可研究Partial/Full Vocabulary近似与计算成本权衡。
• 理论分析停留在Token-level、Per-update梯度，需要扩展到Evolving Teacher下的Trajectory-level KL Bound。
• AppWorld只评测57个Dev任务，尚未报告官方Test-Normal/Test-Challenge，外推时需要谨慎。

(2512) Reinforcement Learning for Self-Improving Agent with Skill Library

🌺 论文摘要

SAGE 论文摘要

参考链接

• paper

核心方法 (SAGE, Skill Augmented GRPO for Self-Evolution)

• 技能库 + 持续学习 RL框架。

• Sequential Rollout：2任务链 训练，Task1生成技能被Task2使用，实现持续学习。

• 结果奖励 + 技能生成/使用奖励。仅当技能被后续任务成功复用时才给予额外奖励。

• 训练流程：Claude构造专家数据 -> SFT冷启动 -> SAGE RL训练。

模型效果(Qwen2.5-32B, SFT+RL, AppWorld)

• SAGE Test-Normal TGC 72，SGC 60。

• 性能超过基线GRPO SGC 51.8，GPT4o/Claude3.5 + React，SGC 32.1，SGC 41

• SAGE比GRPO步数Tokens更少。12.1 vs 16.4，1475 vs 3613

关键结论

• 封装技能将复杂的API调用序列简化为单函数调用，提高准确率，大幅降低推理成本。
  • SAGE 提升技能使用成功率，RL教会模型何时如何使用Skill。
• 必须做SFT+RL：仅靠Prompt无法让开源模型用好技能库。
  • 专家SFT数据提供格式先验，RL进一步优化策略。
• 必须做SFT冷启动：(SGC指标) 直接RL 25.6，SFT 41.7，SFT+RL 60.7。
• AppWorld Query简单，n-gram 检索SKill 效果就挺好。
• 3个任务链并未提升性能。

关键贡献

• 提出了 Tool-use Agent 的 SAGE 框架，同场景序列学习 + Skill思想。
• 解决了 RL Agent 在新环境中难以利用历史经验持续优化的问题。

问题背景(新场景难持续学习)

❓ 问题背景

持续学习+Skill Library 挑战

持续学习难题

• 现有的RL Agent (如CodeAct, RLVR) 往往局限于特定场景。
• 新环境时，难通过积累经验来持续自我提升。

技能库 (Skill Library) 的挑战

• 现有技能库方法主要依赖 LLM Prompting（如 Voyager, Agent Skill Induction）。
• 缺点：
  • 依赖基座模型能力：对指令遵循要求高，开源模型难以稳定生成/调用技能。
  • 格式不统一：通常将任务执行和技能提炼分开，增加了上下文开销和推理延迟。
  • 缺乏针对性优化：没有专门针对生成高质量技能进行 RL 训练。

Skill Library Agent

📕 核心方法

Skill Library Agent (技能库智能体)

统一的交互格式

• 扩展自 CodeAct 框架。
• Skill：模型在解决任务时，将常用的操作序列封装为 Python 函数 (Skill)。
• 流程：定义函数 -> 存入库 -> 后续步骤/任务中调用函数。
• 优点：相比于事后总结技能，这种方式即时生效且减少Token消耗。

Skill-Augmented GRPO

SAGE (Skill Augmented GRPO for Self-Evolution)

1. Sequential Rollout

• 利用 AppWorld 的 Scenario 结构（每个场景包含3个相似任务）。
• 构建任务链 $(q_1,q_2)$：
  • Agent 先解决 $q_1$，生成技能存入库 $M$。
  • 使用更新后的技能库 $M$ 去解决 $q_2$。
• 目的：模拟真实场景下的持续学习，强制模型学习如何复用前一个任务的经验。

2. Skill-Integrated Reward (技能集成奖励)

• 奖励公式：$R=R_{\text{outcome}}+R_{\text{skill}}$
• Outcome 奖励: 任务成功1，失败0。
• Skill 奖励:
  • 技能生成奖励：如果 $q_1$ 生成的技能帮助成功解决$q_2$，则奖励 $q_1$。
  • 技能使用奖励：如果 $q_2$ 成功使用了 $q_1$ 的技能并完成任务，则奖励 $q_2$。
• 惩罚：模型未生成代码 直接结束，给予 -1.0 惩罚。

3. 训练策略

• 算法：GRPO (Group Relative Policy Optimization)。
• 优势计算：基于任务链的期望回报，不使用 KL 惩罚。

实验设置

✍️ 实验设置

实验设置

基础模型

• Qwen2.5-32B-Instruct

数据集

• AppWorld: 模拟9个日常APP (Amazon, Gmail等) 的复杂操作环境。
• 训练集: Train Set (难度 1-2)，未使用难度3数据。24个场景。
• 评测集: Test-Normal (168任务), Test-Challenge (417任务，含未见过的APP)。
• SFT数据构造: 1.1k 轨迹数据。
  • Claude 3.5 + Skill Agent，拒绝采样，筛选任务成功+有效利用技能的数据。

训练策略

• SFT 冷启动：学会技能定义和调用格式。
• SAGE RL: 基于SFT模型做RL训练，采样 2个任务 组成链做Sequential Rollout。

评估指标

• 效果指标：TGC，SGC，
• Efficiency: 平均交互步数 (Steps) 和 Token 消耗。

训练参数

• 每一步：384个rollout。

关键结果(Qwen2.5-32B, SFT+RL, AppWorld)

🍑 关键结果

关键结果

模型效果(Qwen2.5-32B, SFT+RL, AppWorld)

• SAGE Test-Normal TGC 72，SGC 60。

  • Base GRPO： TGC 69.2，SGC 51.8。
  • GPT-4o +ReAct： SGC 32.1
  • Claude 3.5 Sonnet +ReAct ：SGC 41.1

• SAGE比GRPO步数Tokens更少。12.1 vs 16.4，1475 vs 3613

关键结论

• 封装技能将复杂的API调用序列简化为单函数调用，提高准确率，大幅降低推理成本。
  • SAGE 提升技能使用成功率，RL教会模型何时如何使用Skill。
• 必须做SFT+RL：仅靠Prompt无法让开源模型用好技能库。
  • 专家SFT数据提供格式先验，RL进一步优化策略。
• 必须做SFT冷启动：(SGC指标) 直接RL 25.6，SFT 41.7，SFT+RL 60.7。
• 3个任务链并未提升性能。

Skill 检索方式对比

• 理想情况-Same Scenario: SGC 60.7%
• Query N-gram 检索： SGC 60.1% (几乎无损)
• Embedding 检索：SGC 59.5%
• 简单的N-gram检索在AppWorld 这种指令相似度高的场景下非常有效。

未来方向

⛳ 未来方向

未来方向

技能检索增强

• 当前：依赖同一场景、简单检索。
• 未来：探索功能语义的专用检索器，以应对跨场景的技能复用。

任务链长度扩展

• 3个任务链并未提升性能，可能因为奖励分配不均、梯度方差变大等原因。
• 解决长序列信用分配问题。

更通用的技能库

• 目前技能针对AppWorld-API。
• 探索SAGE应用到更开放的 Code Agent 或 Web Agent 场景。

(2511) (通义) AgentEvolver

🌺 论文摘要

AgentEvolver 论文摘要

参考链接

• paper, code

核心方法

• AgentEvolver 框架：无需人工数据，通过环境交互实现自主进化。
• 三大核心机制：
  • Self-Questioning (自提问)：好奇心驱动探索环境 -> 合成任务 -> 任务筛选，解决数据匮乏。
  • Self-Navigating (自导航)：构建经验池 -> 检索经验 -> 混合Rollout，解决探索效率低。
  • Self-Attributing (自归因)：LLM Judge进行步骤级归因(Good/Bad) -> 细粒度奖励，解决奖励稀疏。
• 基础设施：Context Manager (支持滑动窗口、自管理上下文等模板)。

模型效果 (Qwen2.5-14B-Instruct)

• AppWorld (Test-Normal): TGC (Task Goal Completion) avg@8 达 48.7% (Base 18.0%)，best@8 达 69.4%。
• BFCL v3: avg@8 达 66.5% (Base 41.6%)。
• 样本效率：在AppWorld上，达到Baseline 90%性能所需的训练步数减少了 55% (40步 vs 90步)。

重要结论

• Self-Questioning 贡献最大，解决了"学什么"的问题。
• Self-Attributing 提供了密集的中间奖励，显著提升了样本效率。
• 经验内化 (Implicit RL) 比单纯的 In-Context Learning 效果更好且上限更高。

关键贡献

• 提出了一套完整的Agent自进化流程 (E -> Task -> Trajectory -> Policy)，不再依赖昂贵的人工标注数据。

问题背景(AgentRL训练困境)

❓问题背景

现有Agent训练困境

成本高昂与效率低下

• 依赖人工数据：现有Agent训练通常需要人工构建任务数据集(SFT数据)。
• RL探索效率低：传统RL在复杂工具调用环境中依赖随机探索，成功率低，样本利用率差。
• 奖励稀疏：长程任务通常只有最终成败反馈，缺乏中间步骤信用分配。

目标

• 实现零人工干预的Agent能力提升。
• 让Agent在未知环境中自主发现任务、积累经验并自我优化。

📕核心方法

自主任务生成 (Self-Questioning,学什么)

Self-Questioning: 学什么?

流程

• 环境探索：基于环境Profile（实体、属性、操作）进行好奇心驱动的随机游走。
• 任务合成：将探索轨迹抽象为(Query, Reference Solution) Pair。
• 任务清洗：
  • 实时过滤：词法去重。
  • 事后过滤：使用Agent重放验证可行性，剔除幻觉任务。

作用

• 将交互Sandbox(无任务环境)转化为Proxy Task Distribution(训练任务集)。
• 提供了Reference Solution，用于后续的Reward计算。

经验辅助探索 (Self-Navigating,怎么探索)

Self-Navigating: 怎么探索?

经验获取 (Offline)

• 从历史轨迹中提取成功或失败的经验（What to do / What not to do）。
• 构建经验池 (Experience Pool)，形式为自然语言描述。

经验混合 Rollout (Online)

• 检索：根据当前Task检索Top-K经验。
• 混合策略：$\eta$ 比例的Rollout使用经验指导(Prompt中插入经验)，其余为Vanilla Rollout。
• 目的：平衡利用（Exploitation，利用经验走捷径）与探索（Exploration，发现新路径）。

Mask 经验Loss

• Mask 经验Token的Loss

细粒度归因奖励 (Self-Attributing,怎么学)

Self-Attributing: 怎么学?

双通道奖励设计

• 结果奖励 ($R_{out}$)：任务最终是否成功（0/1），进行标准化。
• 过程归因奖励 ($R_{attr}$)：
  • LLM Judge 对每一步做打分：GOOD (+1) 或 BAD (-1)。
  • Trajectory-level 标准化，避免长轨迹方差过大。

合成奖励

$$R_{total}=\alpha \cdot {\hat{R}}_{attr}+\beta \cdot {\hat{R}}_{out}$$

• 提供了Dense Reward，显著加速收敛。

实验设置

✍️实验设置

实验设置

基础模型

• Policy: Qwen2.5-7B-Instruct, Qwen2.5-14B-Instruct
• Judge: Qwen-Max / Qwen3-235B

评测基准

• AppWorld: 复杂的API交互环境，指标为TGC (Task Goal Completion)。
• BFCL v3: 工具调用基准。

算法配置

• 训练算法：GRPO 变体。
• 探索配置：Self-Questioning 生成任务；经验混合比例 $\eta =0.5$。
• 奖励权重：$\alpha$ (Attribution权重) 调优，最终选取 0.1~0.2。

关键结果

🍑关键结果

关键结果

模型效果(AppWorld, Test-Normal TGC avg@8指标)

• Qwen2.5-7B TGC 由 1.8 -> 32.4
• Qwen2.5-14B TGC 由 18.8 -> 48.7

模型效果(BFCL v3, avg@8指标)

• Qwen2.5-7B 由 29.8 -> 57.9
• Qwen2.5-14B 由 41.6 -> 66.5

消融实验 (14B)

• Base: 18.0%
• +Questioning (有任务了): 44.3% (提升最大，解决了冷启动)
• +Navigating (有经验了): 45.4%
• +Attributing (有细粒度奖励了): 48.7% (最终完整版)

样本效率

• 引入Self-Attributing后，在 AppWorld 上仅需40步 即可达 90步 90%的性能。
• 证明了细粒度信用分配对加速收敛的关键作用。

未来方向

⛳ 未来方向

未来方向

上下文管理

• 针对超长任务(百步)，Context Manager 的不同模板(滑动窗口vs自主压缩)对性能影响大。
• 未来需探索更智能Memory管理机制。

经验利用的权衡

• 过度依赖检索经验：在推理时有效，但在训练时可能导致过拟合，降低泛化探索能力。
• 需要平衡 Guidance 和 Intrinsic Reasoning。

多Agent协同

• 当前主要单Agent自我进化，未来可扩展到多角色（如Planner-Executor）的联合进化。

(2510) SALT: Step-level Advantage Assignment for Long-horizon Agents via Trajectory Graph

🌺 论文摘要

SALT 论文摘要

参考链接

• SALT: Step-level Advantage Assignment for Long-horizon Agents via Trajectory Graph

核心方法

• SALT 框架：基于轨迹图构建的细粒度优势分配机制。
• 核心思想：将多个生成的轨迹合并为轨迹图 (Trajectory Graph)。
  • 合并 (Merge)：不同轨迹中相同状态和动作的节点合并。
  • 分支 (Diverge)：不同动作导致路径分叉。
• 优势重估：基于图结构计算每个Step的优势，而非简单广播整个轨迹的最终回报。
  • 共享步骤（出现在成功和失败中）-> 中性优势。
  • 关键步骤（仅出现在成功轨迹中）-> 高优势。
• 轻量级插件：无缝集成至 GRPO/RLOO，无需额外Reward Model，无需人工标注。

模型效果 (Qwen2.5-1.5B/7B/32B)

• ALFWorld: Qwen2.5-1.5B 上，GRPO 成功率从 69.0% 提升至 80.5% (+11.5%)。
• WebShop: Qwen2.5-1.5B 上，GRPO 成功率从 64.6% 提升至 66.2%。
• AppWorld: Qwen2.5-32B 上，GRPO+SALT 在 Test-Normal SGC 指标上达 20.9% (Base GRPO 17.0%)。

重要结论

• 细粒度信贷分配：解决了长程任务中好坏动作纠缠导致梯度冲突的问题。
• 计算开销极低：相比Rollout和Update，SALT引入的开销可忽略不计。
• 无需Critic模型：适用于 Group-Based RL (如 GRPO) 的纯 Policy 优化场景。

关键贡献

• 提出了基于结果稀疏奖励进行Step-level 优势估计的通用方法 SALT。

问题背景

❓问题背景

现有 Group-based RL 的局限性

长程任务挑战

• LLM Agent 在 WebShop、ALFWorld 等长程任务中，需要执行多步操作才能获得最终反馈。
• 主流方法（如 GRPO）通常依赖稀疏的最终奖励 (Outcome-based rewards)。

粗粒度信用分配 (Coarse-grained Credit Assignment)

• GRPO 将整条轨迹的最终回报直接广播给轨迹中的每一个 Step。
• 噪声问题：
  • 成功轨迹中可能包含冗余/错误步骤（被错误奖励）。
  • 失败轨迹中可能包含正确步骤（被错误惩罚）。
• 后果：导致训练不稳定，策略更新存在梯度冲突，难以收敛到最优解。

核心方法(Step-level Advantage Assignment)

📕核心方法

SALT: Step-level Advantage Assignment

1. 轨迹图构建 (Trajectory Graph Construction)

• 输入：对同一个 Prompt 采样的 $G$ 条轨迹 (Rollouts)。
• 操作：
  • 定义状态 $s_t$ 为包含过去 $h$ 步的历史窗口。
  • Merge：如果两条轨迹在某一步的 历史状态 和 当前动作 相同，则将它们视为图中的同一个节点。
  • Diverge：动作不同则产生分支。
• 结果：将独立的线性轨迹转化为有向无环图 (DAG)，揭示了哪些步骤是跨轨迹共享的，哪些是独有的。

2. 细粒度优势计算 (Step-level Advantage)

• 直觉：
  • 共享节点 (Shared Nodes)：出现在多条轨迹（包括成功和失败）中，说明该步骤对结果区分度低，应给予平均/中性优势。
  • 独有节点 (Distinct Nodes)：仅出现在高分轨迹中的步骤可能是关键成功因素，应给予高优势。
• 计算：
  • 每个节点的价值 $V(s,a)$ 估计为经过该节点的所有轨迹回报的平均值。
  • 使用该节点价值替代原有的轨迹级回报来计算优势函数。

3. 轻量化与兼容性

• Plug-and-Play：插入在 Advantage Computation 和 Policy Update 之间。
• 零额外参数：不需要训练 Value Model 或 Process Reward Model (PRM)。

实验设置

✍️实验设置

实验设置

基础模型

• Qwen2.5-Instruct 系列：1.5B, 7B, 32B。

训练/评测任务

• ALFWorld：具身智能推理任务 (6种类型)。
• WebShop：网页购物模拟，涉及搜索、选择属性等。
• AppWorld：复杂的日常API交互任务 (高难度长程)。

算法/策略

• Baseline: RLOO, GRPO。
• Ours: RLOO+SALT, GRPO+SALT。

超参配置

• Group Size: 默认为 8 (消融实验测试了 4-16)。
• State History ($h$): 默认为 3 (用于判断节点合并的上下文窗口)。
• Rollout: Temperature=1.0。

关键结果

🍑关键结果

关键结果

ALFWorld 显著提升

• Qwen2.5-1.5B:
  • GRPO: 69.0% -> GRPO+SALT: 80.5%
  • RLOO: 68.4% -> RLOO+SALT: 76.6%
• Qwen2.5-7B:
  • GRPO: 83.6% -> GRPO+SALT: 86.1%
• 结论：在小模型上提升尤为显著，帮助小模型探索并锁定正确路径。

AppWorld 高难度任务突破

• 使用 Qwen2.5-32B：
• Test-Normal (SGC): GRPO (17.0%) -> GRPO+SALT (20.9%)。
• Test-Challenge (SGC): 在难度最高的D2子集上，成功率翻倍 (8.0% -> 18.6%)。
• 结论：在需要极长推理链的任务中，SALT 能够有效识别关键步骤。

效率分析

• 计算开销：在一次迭代中，Rollout 耗时 240s，SALT 仅耗时 0.15s。相比带来的性能提升，开销几乎可以忽略不计。

消融实验

• Group Size：Group Size 越大 (如 16)，轨迹图连接越丰富，SALT 带来的相对提升越大。
• History Length：$h=3$ 效果最佳。太短($h=1$)导致错误合并，太长($h=5$)导致图退化为独立轨迹。

未来方向

⛳ 未来方向

未来方向

局限性

• 依赖 Group 多样性：如果采样的轨迹全部相同或完全不重叠，SALT 退化为标准 GRPO。需要保证一定的采样多样性 (Temperature > 0)。

潜在应用

• 代码生成与数学推理：虽然本文关注 Agent 任务，但该思想同样适用于 Code/Math 的 Reasoning 过程优化，尤其是对于中间步骤的信贷分配。
• 结合 PRM：SALT 是基于统计的无监督方法，未来可与显式的 Process Reward Model 结合，进一步校准优势估计。

(2509) ProST: Progressive Sub-task Training for Pareto-Optimal Multi-agent Systems Using Small Language Models

🌺 论文摘要

ProST: Progressive Sub-task Training 摘要

参考链接

• paper

核心方法

• ProST: 多智能体的课程学习微调策略，渐进式引入子任务。
• 多智能体：Orchestrator(规划)、Executor(执行/写代码)、Critic(反馈)。

模型效果(Qwen2.5-14B + ProSFT + 多角色)

• Test-Normal TGC 达42.3，SGC达26.8，Test-Challenge TGC 14.1, SGC 5.8。

重要结论

• ProST > SFT > Base：所有模型尺寸，ProST训练的多智能体均优于标准SFT。

• 14B-MA(ProST) 效果优于 32B-SA(Base)，小模型组合可胜单体大模型，推理FLOPs更低。

• 资源给规划者比较好：规划-执行-评估，14B-7B-7B 显著优于 7B-14B-14B。

关键贡献

• 个人感觉不是很ok，效果太差了。

问题背景(小模型在复杂场景效果不好)

❓问题背景

问题背景

小模型做复杂任务存在挑战

• AppWorld 复杂+长交互：需要规划、编码、API调用和错误恢复
• GPT4效果好但成本高。SLM小模型成本低，但效果不好。

现有SFT存在局限性

• 长轨迹学习困难：直接在完整轨迹上SFT，难学会中间的子任务，易灾难性遗忘或逻辑断层。
• 角色专业化不足：虽拆为多智能体，但单SLM难同时掌握角色的细微差别和长程依赖。

效率与效果的权衡

• 业界缺乏对多智能体在计算成本与任务完成率之间权衡的系统研究。

📕核心方法

ProST-渐进式子任务训练

ProST 训练策略

核心思想

• 借鉴课程学习，让模型先学简单的/局部的，再学复杂的/全局的。
• 训练早期，只暴露部分子任务。
• 随Epoch增加，逐步扩展输入上下文，直到覆盖完整轨迹。

训练流程

• 数据构建：包含 $N$ 个子任务的轨迹。
• 渐进式掩码 (Progressive Masking)：
  • Epoch 0：仅训练特定的子任务子集（例如子任务 2, 3），屏蔽其他。
  • Epoch i：引入更多子任务（例如从子任务 2 扩展到 1-3）。
  • Final Epoch：训练包含所有子任务的完整轨迹。
• 优势：
  • 避免模型在长序列中迷失。
  • 强制模型优先掌握核心逻辑，再处理长依赖。

Mask错误动作的Loss

• 仅计算正确步骤和自我修正成功步骤的Loss。
• Mask错误步骤的Loss，避免模型学习错误的推理路径。
• 同 SWE-Lego Mask错误动作

三角色架构与数据合成

架构设计

角色分工

• Orchestrator (规划者)：
  • 将用户Query拆解为子任务序列（ReAct模式）。
  • 处理执行失败，动态调整计划。
• Executor (执行者)：
  • 接收子任务，编写Python代码调用AppWorld API。
  • 包含自我纠错循环。
• Critic (批评者)：
  • 当Executor反复失败时介入，审查代码和环境反馈，提供自然语言建议。

数据合成Pipeline

• 源数据：用 Llama-3.3-70B 生成高质量的单智能体轨迹(Rejection Sampling)。
• 转换：用 Claude-3.7-Sonnet 把单智能体轨迹重写为多智能体训练数据。
• 验证：所有转换后的轨迹都在AppWorld环境中实际执行验证，确保正确性。

实验设置

✍️实验设置

实验设置

基础模型

• Qwen-2.5-Coder (7B, 14B, 32B) —— 核心实验模型（代码能力强）。
• Llama-3.1-8B, Phi-4 —— 验证泛化性（推理能力强）。

基准测试 (AppWorld)

• 模拟9个日常APP（Amazon, Spotify, Venmo等），457个API。
• Test-Normal (域内测试) 和 Test-Challenge (域外测试/OOD)。

评估指标

• 效果指标：TGC (任务目标完成率), SGC (场景目标完成率)。
• 效率指标：Inference FLOPs，推理时的浮点运算次数，用于衡量真实的计算开销

对比基线

• Single Agent (SA): Base, SFT
• Multi-Agent (MA): Base, SFT, ProST(Ours)

关键结果(Qwen2.5-14B+ProSFT+多角色)

🍑关键结果

关键结果

模型效果(Qwen2.5-14B + ProSFT + 多角色)

• Test-Normal TGC 达42.3，SGC达26.8，Test-Challenge TGC 14.1, SGC 5.8。

关键结论

• ProST > SFT > Base：所有模型尺寸，ProST训练的多智能体均优于标准SFT。

• 14B-MA(ProST) 效果优于 32B-SA(Base)，小模型组合可胜单体大模型，推理FLOPs更低。

• 资源给规划者比较好：规划-执行-评估，14B-7B-7B 显著优于 7B-14B-14B。

未来方向

⛳ 未来方向

未来方向

局限性

• 显存开销：虽然FLOPs（时间成本）降低了，但同时加载3个模型对GPU显存要求很高。
• 数据依赖：严重依赖闭源模型（Claude 3.7）进行数据的多智能体转换。

未来探索

• OOD 泛化：Test-Challenget提升少，如何让Agent适应未见API是关键。
• 动态资源分配：根据任务难度动态选择不同大小的模型角色。
• 更通用的课程：其他长周期Agent任务（如SWE-bench）上的ProST应用。

(2502) Leave-One-Out PPO

🌺 论文摘要

LOOP 论文摘要

参考链接

• paper, LOOP 知乎, ml-loop

核心方法

• LOOP: 留一法算优势 + 去掉std + PPO Off-Policy + PPO Clip + Token级建模
• AppWorld 训练数据筛选：去掉难度3场景、再去掉6场景

模型效果(Qwen2.5-32B-Inst, AppWorld)

• TestNormal：TGC 达71.3分，SGC 达53.6分。
• TestChallenge：TGC 达45.7分，SGC达 26.6分。
• 整体均超过其他方法。

重要结论

• per-token > per-turn > per-traj，71.3 > 64.1 > 53.3
• 组内std归一化 会降低9pt：71.3 -> 61.9
• 移除KL惩罚有效果：Test-C TGC 从 22.4 -> 26.6
• Loop 优于 GRPO：71.3 > 58。LOOP 非归一化 优于 GRPO 归一化 ?
• Loop 优于 PPO：71.3 > 50.8。Critic 不好训，易引入误差
• 出现一些涌现行为。

关键贡献

• AppWorld SOTA
• 详细的各方法对比实验

问题背景

❓问题背景

LLM Agent真实任务效果不行

Agent真实效果不行 + RLOO存在缺点

LLM Agent处理真实任务效果不行

• AppWorld
  • 单任务：agent和python环境可能交互40轮、32k长度。
  • 特点：
    • stateful、多领域、多app、环境API交互
    • 跨应用、长序列规划、动态适应、上下文长。
• 现有模型效果不好
  • 开源Qwen2.5仅40%，GPT4o 仅50%成功率。

RLOO 缺点

• 同策略算法，样本效率低。
• Trajetory-Level 建模，但Token-Level 通常更稳定一些。

基础RL算法概览及其问题

RL建模：llm token-level MDP

主流RL算法

1. REINFORCE算法

• 参考笔记：REINFORCE、REINFORC++算法、优势AC算法

• 策略梯度，优势决定更新方向。优势大于0，鼓励；优势小于0，抑制。

2. RLOO 算法

• 参考笔记：RLOO

• REINFORCE+留一法计算优势，无需Critic和Ref模型。

3. 本文LOOP 算法

• RLOO + 异策略，具体引入PPO信任域，提升样本效率。

4. GRPO 算法

• 参考笔记：GRPO, GRPO改进系列

• 组内计算优势基线，无需Critic。

5. PPO 算法

• 参考笔记：PPO, PPO改进系列。
• 标准PPO，复杂有点贵。
  • 异策略算法提升样本效率，
  • 重要性采样修正权重；
  • Clip信任域 限制更新幅度，保证稳定。

6. 其他非RL

• 迭代iSFT，通过不断筛选好样本，来微调模型。

PPO序列和Token两种建模Loss计算

PPO建模和Loss计算 (序列+token)

PPO 建模方式

• Per-轨迹：把整个序列看成1个动作，计算1个总的重要性权重。GSPO 序列级IS权重

  $${\mathrm{\nabla }}_{\theta }{J}_{\text{GSPO}}(\theta )=E_{x\in \mathcal{D},\{y_i{\}}_{i=1}^G\sim {\pi }_{{\theta }_{old}}(\cdot |x)}[\frac{1}{G}\sum _{i=1}^G\underset{\mathrm{序}\mathrm{列}IS}{\underbrace{s_i(\theta )}}\cdot \underset{\mathrm{序}\mathrm{列}\mathrm{优}\mathrm{势}}{\underbrace{{\hat{A}}_i}}\cdot \underset{\mathrm{序}\mathrm{列}\mathrm{梯}\mathrm{度}}{\underbrace{{\mathrm{\nabla }}_{\theta }\log s_i(\theta )}}]$$

• Per-Token：把每个词看成1个动作，为每个词 单独计算重要性权重。更稳定、平滑。

  $${\mathrm{\nabla }}_{\theta }{J}_{\text{GRPO}}(\theta )=E_{x\in \mathcal{D},\{y_i{\}}_{i=1}^G\sim {\pi }_{{\theta }_{old}}(\cdot |x)}[\frac{1}{G}\sum _{i=1}^G\underset{\mathrm{序}\mathrm{列}\mathrm{内}\mathrm{平}\mathrm{均}}{\underbrace{\frac{1}{|y_i|}\sum _{t=1}^{|y_i|}}}\underset{\text{token重要性权重}}{\underbrace{\frac{{\pi }_{\theta }(y_{i,t}|x,y_{i,<t})}{{\pi }_{{\theta }_{old}}(y_{i,t}|x,y_{i,<t})}}}\cdot \underset{\text{token优势}}{\underbrace{{\hat{A}}_{i,t}}}\cdot \underset{\text{token梯度}}{\underbrace{{\mathrm{\nabla }}_{\theta }\log {\pi }_{\theta }(y_{i,t}|x,y_{i,<t})}}]$$

PPO Loss 计算方式

• Seq-Level-Loss：PPO Seq-level-Loss, GSPO Seq-Level-Loss

$${\mathcal{L}}_{\text{ppo}}(\theta )=-\underset{\mathrm{样}\mathrm{本}\mathrm{间}\mathrm{平}\mathrm{均}}{\underbrace{\frac{1}{G}\sum _{i=1}^G}}\underset{\text{序列内平均}}{\underbrace{\frac{1}{|o_i|}\sum _{t=1}^{|o_t|}}}min(\frac{{\pi }_{\theta }(o_{i,t}\mid q,o_{i,<t})}{{\pi }_{{\theta }_{old}}(o_{i,t}\mid q,o_{i,<t})}\cdot {\hat{A}}_{i,t},\text{clip}(\frac{{\pi }_{\theta }(o_{i,t}\mid q,o_{i,<t})}{{\pi }_{{\theta }_{old}}(o_{i,t}\mid q,o_{i,<t})},1-ϵ,1+ϵ)\cdot {\hat{A}}_{i,t})$$

• Token-Level-Loss：DAPO Token-Level-Loss

$${\mathcal{L}}_{\text{DAPO}}(\theta )=-\underset{\text{所有Token直接做平均}}{\underbrace{\frac{1}{\sum _{i=1}^G|o_i|}\sum _{i=1}^G\sum _{t=1}^{|o_t|}}}min(\frac{{\pi }_{\theta }(o_{i,t}\mid q,o_{i,<t})}{{\pi }_{{\theta }_{old}}(o_{i,t}\mid q,o_{i,<t})}\cdot {\hat{A}}_{i,t},\text{clip}(\frac{{\pi }_{\theta }(o_{i,t}\mid q,o_{i,<t})}{{\pi }_{{\theta }_{old}}(o_{i,t}\mid q,o_{i,<t})},1-ϵ,1+ϵ)\cdot {\hat{A}}_{i,t})$$

PPO CLIP 粒度

• per-trajectory：1条轨迹计算1个IS权重。

  • 缺点：非常不稳定。

• per-turn：为每个回合计算1个IS权重。

  • 优点：

• per-token：为每个token单独计算1个IS权重。

  • 优点：最精细。

AppWorld 场景

相关场景

• 相关：text-games(2015,2023), webshop(2022), 导航(2022), 手机控制(2024)
• WebShop：
  • Yao(2022)：REINFORCE + 可学习baseline
  • ArCHer(2024)：结合off-policy + on-policy 训练
  • AgentQ(2024)：DPO + Tree搜索
  • 场景：买东西，1个app，8个动作，每回合最多1个参数

AppWorld 场景

场景和任务

• 多样化复杂逻辑：邮件、支付、音乐、购物、打电话、文件系统等。
• 9个真实app，457个API调用，单API最多17个参数。
• 250个场景，每个场景有3个任务，总计750个任务。
• 任务难度分1-3档。

训练评测数据量

• 训练：35场景，105个任务。Level 1-2-3：36, 36, 18

• Dev：20场景，60任务。Level 1-2-3：30, 24, 3

  • Level1-36条，Level2-36条，Level3-18条

• Test-Normal：56场景，168任务。Level 1-2-3：57, 48, 63

• Test-Challenge：139场景，417任务。复杂、新APP。Level 1-2-3：72, 150, 195

评测维度

• 每个任务有1套单元测试，3个维度
  • 事情已完成：任务所要求的环境状态成功执行
  • 无副作用：没有对环境或APP造成额外的修改
  • 答案正确：agent最终答案和标准答案一致

评估指标

• TGC：Task-Goal-Completion，任务目标完成率
• SGC：Scenario-Goal-Completion，场景目标完成率
  • 1场景有3任务，3个任务全部完成，才算场景完成。

部分可观测马尔可夫决策过程

POMDP

状态

• 初始隐藏状态：Python REPL状态、模拟数据库等，智能体看不见，

• 上下文：user prompt

• 所有token序列：大模型生成token + 环境返回token，是agent可观察的历史信息。

  $$[{\mathit{s}}_0,\mathit{c},x_{1:t}]$$

动作

• Agent生成下一个token$$p_{\theta }(\cdot \mid \mathit{c},x_{1:t})$$

状态转移

• 状态追加 LLM生成token $x_{t+1}$ + 环境返回token$x_{t+2:t+1+k}$$$[{\mathit{s}}_0,\mathit{c},x_{1:t}]\to [{\mathit{s}}_0,\mathit{c},x_{1:t+1+k}]$$

轨迹概率

• Token 概率乘积
• 指示函数I：轨迹和初始状态一致，则为1；否则为0。

$$p_{\theta }(\mathit{x}\mid {\mathit{s}}_0,\mathit{c})=I({\mathit{s}}_0,\mathit{c})\cdot \prod _{t=1}^T{p}_{\theta }(x_t\mid \mathit{c},x_{1:t-1})$$

优化目标

• 最大化累积期望奖励$$L_{\theta }({\mathit{s}}_0,\mathit{c})=E_{x\sim p_{\theta }(\cdot \mid {\mathit{s}}_0,\mathit{c})}[R({\mathit{s}}_0,\mathit{c},\mathit{x})]$$

Leave-One-Out PPO 算法

📕核心方法

使用 PPO Off-Policy和Clip策略

PPO Off-Policy 提高样本效率

• 多轮次训练
  • Rollout数据使用 ppo_epochs轮，训练多轮。
  • 使用重要性权重来做分布修正。
  • 如果ppo_epochs=1，则LOOP退化成RLOO。
• 小批量学习
  • train_batch分成多个mini-batch，进行多次梯度更新。

$$r_i=\frac{{\pi }_{\theta }(\mathbf{x}\mid {\mathit{s}}_0,\mathit{c})}{{\pi }_{{\theta }_{old}}(\mathbf{x}\mid {\mathit{s}}_0,\mathit{c})}=\prod _{t=1}^T\frac{{\pi }_{\theta }(x_t\mid \mathit{c},x_{<t})}{{\pi }_{{\theta }_{old}}(x_t\mid \mathit{c},x_{<t})}$$

PPO Clip 保证更新稳定

• PPO-Clip 限制更新策略幅度 保证稳定

使用留一法做优势估计

• 同1个prompt，采样k次，使用其余k-1次的平均值作为基线

• 参考笔记：RLOO 留一法

  $$A(x,y_i)=R(x,y_i)-\frac{1}{K-1}\sum _{j=1,j\ne i}^{K}R(x,y_j)$$$$A(x,y_i)=\frac{K}{K-1}(R(x,y_i)-\frac{1}{K}\sum _{j=1}^{K}R(x,y_j))$$

$$A(x,y_i)\approx R(x,y_i)-\text{mean}(R)$$

LOOP 不除以标准差

标准差

• 在不稳定的任务上，标准差大
• 除以标准差，会削弱或抑制那些偶然成功的高奖励学习信号。

差异

• GRPO：除以标准差。
• LOOP：不除以标准差。

LOOP 实验

• LOOP实验不除以标准差好，能更有效地从不稳定的、探索性的行为中学习。

相关算法

• Dr.GRPO：不除以标准差，避免难度偏差。
• REINFORCE++、LitePPO：Global std

实验设置

✍️实验设置

RL超参

奖励函数

• [0, 1]，单元测试通过比例。no sparse

训练数据

• 从原始Train中，筛选出24场景，共72任务。
• 筛选逻辑
  • 先去掉难度3场景，只用难度1和2（35 -> 30）。
    • 使用难度3会降低性能。
  • 再去掉6个场景：30 -> 24。

其他超参

• 最大轮次：训练40轮，测试50轮。
• Rollout：6次。
• Batch：40个任务、每次学习40*6=240条序列
• 固定学习率：5e-5
• Prompt：ReACT Prompt
• 长度：LLM单次 1500 token；环境单次：3000 token。
• 训练50epoch，取最好的checkpoint。

实验设置

基础模型

• Qwen2.5-32B

训练任务/数据

• AppWorld筛选后的训练数据：24个场景，共72个任务。

评测任务/数据

• AppWorld Test-normal, Test-Challenge

算法/策略

• LOOP， LORA训练

超参

• 2*8H100，训练42小时。
• 其他超参见上文

关键结果(Qwen2.5-32B-Instruct)

🍑关键结果

关键结果

模型效果(Qwen2.5-32B-Inst, AppWorld)

• TestNormal：TGC 达71.3分，SGC 达53.6分。
• TestChallenge：TGC 达45.7分，SGC达 26.6分。
• 整体均超过其他方法。

重要结论

• per-token > per-turn > per-traj，71.3 > 64.1 > 53.3
• 组内std归一化 会降低9pt：71.3 -> 61.9
• 移除KL惩罚有效果：Test-C TGC 从 22.4 -> 26.6
• Loop 优于 GRPO：71.3 > 58。LOOP 非归一化 优于 GRPO 归一化 ?
• Loop 优于 PPO：71.3 > 50.8。Critic 不好训，易引入误差
• 出现一些涌现行为。

关键贡献

• SOTA

涌现出优秀行为

• 从莽撞到谨慎：不必要代码执行减少6倍，避免了次优loop
• 从想当然到查文档：调用特定APP接口时，API文档查询增加60%
• 从瞎猜到求证：毫无根据的假设减少了30倍，虚构密码等重要位置减少了6倍
• 从脆弱到坚韧：失败后放弃次数减少3倍

未来方向

⛳未来方向

未来方向

• 性能还不够好，提升成功率。目前仅70%完成。
• 环境太理想化，需提升真实复杂情况。
  • 不确定性、暂时性故障、模棱两可的任务、对抗性场景、与用户主动交互、与真人其他agent交互等等。
• 多模态能力：看懂网页截图、图表等。