智猩猩 AI 整理

论文作者投稿

Agent 正在快速进入一个 "Skill 时代 "。

越来越多框架把程序化知识封装成 SKILL.md，做 PDF、改代码、操作浏览器、跑数据分析，各有一份可以按需读取的说明书。公开 Skill 库已经从几十个涨到几千个，但上下文窗口不可能把它们全部塞进去。

于是，一个过去常被忽略的问题开始变成瓶颈，Agent 是否能够学会选对Skill？

这不是普通检索。真正执行任务时，Agent 只看得到候选 Skill 的名字和一句话描述，要在轨迹中途主动发出一次read，打开其中一个文件，再让后面几十轮乃至上万 token 的执行建立在这个选择上。

直觉上，这件事可以直接交给 outcome-rewarded RL，把 16 个候选摆在模型面前，任务做成了就奖励，做砸了就惩罚，让梯度自己回到那次选择。

但这里有一个很隐蔽、也很致命的问题，如果 Skill 选对了，后面的执行却失败了，选择 Skill 的那几个 token 仍然会被一起惩罚。反过来，如果 Skill 选错了，Agent 靠运气把任务做成，那次错误选择反而会被强化。

上海交通大学与小红书团队在 12,800 条真实在线训练轨迹上审计了这个现象，并把它命名为selector credit starvation（选择器信用饥饿）：

Skill 选择 token 只占整条轨迹 loss weight 的中位数0.14%，从短轨迹到长轨迹还会继续稀释7 倍；

接近2/5的正确 Skill 选择承受了负 advantage；轨迹超过 16k token 时，这一比例达到61.7%；

可与此同时，在 matched prompt group 中，读到正确 Skill 与+11.2 个百分点的任务成功率相关。

也就是说，一个能改变整条轨迹走向的关键决定，拿到的训练信号几乎最少，而且其中相当一部分方向还是反的。

为此，团队开源了策略内技能选择训练框架SkillGate。它不额外训练一个 Router，也不把 Skill 选择移到 Agent 外部，而是把同一条轨迹的 token 划成两个互不重叠的信用通道，任务结果只训练执行 token；Skill 选择则只训练真正写出 Skill 名字的 token。

不是 reward 不够，而是 reward 落错了token。

在 Claw-Eval、SkillsBench、SETA、SWE 和 Terminal-Bench 2.0 五个 Agent benchmark、每题 16 个候选 Skill 的设置下，SkillGate 把 9B policy 的总体 trial success 从28.6% 提升到 53.2%。同时，误读 misleading Skill 的暴露率从 SFT 初始模型的61.8% 降到 21.8%，约减少三分之二，而且 Agent 读的 Skill 反而更少。

01

Skill 越来越多，Agent

却未必越来越会用

论文把一个 Skill 写成三部分：名字 name、一句话描述 description，以及真正包含程序化知识的 body。Agent 在选择前只能看到前两项，只有主动读取之后，完整的 SKILL.md 才进入上下文。

实验里的标准 mixed slate 一共有 16 个候选：

1 个为当前任务专门编写的 oracle Skill；

5 个是主题相近、功能上却不适用的 misleading skills；

5 个是公开库中 retrieve 的语义相关 Skill；

5 个是公开库中的语义不相关 Skill。

后 10 个候选来自一个包含 2,045 个社区 Skill 的公开库。顺序对每个任务随机打乱，Agent 不知道哪一个是 oracle，也可以选择一个都不读，甚至读多个。

难点就在这里，候选往往 " 看起来都像能用 "。Agent 不是在一道静态多选题上输出 A、B、C、D，而是在长轨迹中途写出一段工具调用；一旦打开错误文件，后续推理、工具使用和环境反馈都会被它带偏。

现有两类路线都没有真正解决这个 mid-episode 决策。一类在执行前做检索或重排，把一个候选交给 Agent；另一类让 Agent 自己选，但只用最终任务结果训练整条轨迹。前者把 " 选择 " 和 " 使用 " 割开，后者则把二者混进同一个 advantage。

SkillGate 关注的是第二类路线里最根本的问题，当一条轨迹同时包含 " 选哪份说明书 " 和 " 照着说明书把事做完 " 两种完全不同的决定时，凭什么让同一个终局分数无差别地更新它们？

02

普通 outcome-only RL 为什么很难

让模型学会选择 Skill

研究团队没有先讲一个理论故事，再用额外实验去配合它，而是直接回看 outcome-only RL 已经跑完的 100 个训练 step 和 12,800 条 on-policy trajectory，重新定位每一次 read call 和其中真正选择和读取 Skill 的 token。

审计结果把 selector credit starvation 拆成了三个部分。

第一，Share：选择 token几乎分不到 loss。

序列级 advantage 在整条轨迹上广播，而 loss 又按 token 聚合，因此一个 span 得到的 loss-weight share 基本就等于它的 token share。Skill 名字通常只有几个 token，后面却可能跟着数千乃至数万个执行 token。中位数只有 0.14%，而且轨迹越长，份额越低，从最短区间的 0.381% 一路降到最长区间的 0.053%，稀释约 7 倍。

第二，Sign：好选择经常拿到坏方向。

读对 Skill 不等于后面一定执行成功。只要同组里这条 rollout 的最终结果低于其他 rollout，正确 read 也会继承负 advantage。短轨迹上已有 28.9% 的正确选择被惩罚，超过 16k token 后上升到 61.7%，甚至越过 coin-flip 线。与此同时，read 与不 read 的组内 advantage gap 的信噪比持续下降。

第三，Value：它偏偏又很重要。

在 289 个同时包含 oracle-read 与 non-oracle-read rollout 的 matched task 上，读到正确 Skill 对应 +11.2 个百分点的成功率差距。论文还用 oracle-only injection 做了因果侧的对应验证，得到几乎相同的提升。

最反直觉之处在于轨迹越长，Skill 选择越重要；但轨迹越长，它拿到的训练信号反而越少、越吵、越容易反向。

这不是简单把 reward 调大就能解决的问题。把同一个 advantage 乘十倍，只会把正确和错误方向一起放大。

03

SkillGate：把一条轨迹拆成

两条信用通道

SkillGate 的核心设计很直接，同一个 policy、同一次 forward、同一个 GRPO update，但让两类证据只到达各自应该负责的 token。

任务通道只负责执行。

终局任务结果照常在 prompt group 内归一化，得到 sequence-level 的 task advantage。但在计算这部分 loss 时，整段 Skill read call 都从 assistant mask 中删除，包括 wrapper、函数名、路径和 Skill identity。留下来的推理、其他工具调用与执行 token 才接收 outcome credit。

这样一来，任务后来做砸了可以惩罚执行，但不会反过来把一个已经做对的选择改坏。

选择通道只负责 " 选了谁 "。

系统在 rollout 时精确定位 Skill 名字占据的 identity span。若一条轨迹只读了一次，并且读的正是 oracle Skill，utility 为 1；读错、重复读，或者读完 oracle 后又去读其他候选，utility 都为 0。随后在同一个 prompt group 的所有 read action 上做中心化，得到 action-local selector advantage。

为什么一定要求 " 只读一次 "？因为只奖励 " 曾经读到 oracle"，模型最容易学出的 reward hack 是把候选全读一遍。SkillGate 奖励的是一次命中，而不是 " 在一堆读取中碰巧包含正确答案 "。

两个通道的 token support 完全不重叠。

任务通道删除整个 read call，选择通道只保留其中的 identity token；实现还会在 mask 构造、context-parallel 切分和 loss 三个位置检查二者是否相交。

选择信号不再随轨迹长度缩水。

选择信号不再随轨迹长度缩水。

SkillGate 把任务通道与选择通道的总 token weight 都重新归一到同一个 batch massN，每个被计入信用的 read action 平分选择通道的权重。于是，无论 Skill 名字被 tokenizer 切成几个 token，也无论它后面还有 3k 还是 30k token，它作为一个选择动作拿到的总权重都保持一致。

在同一个 prompt group 里存在可比较的 clean oracle read 时，这也明确了四种情况的信用语义。

Skill 选对、任务成功：选择与执行都得到正反馈；

Skill 选对、任务失败：选择得到正反馈，执行得到负反馈；

Skill 选错、任务侥幸成功：选择得到负反馈，执行得到正反馈；

Skill 选错、任务失败：两边都得到负反馈。

如果一个 group 里没有 clean oracle read，或者所有 read 都同样正确，selector utility 全部打平，选择通道就自动归零，不凭空制造梯度。

值得强调的是，这个 selector term 仍然是on-policyRL。它不是行为克隆，不是交叉熵，不是 DPO，也不是往最终 reward 里硬加一个 bonus；它只训练 policy 自己在 rollout 中真正做过的 Skill 选择和执行。

04

信用必须落到 Skill identity token，

而且 " 读对一个 " 才算对

论文把相同初始模型、相同 100 个训练 step 和相同预算固定住，只改变 selector signal 最终落在哪里。

结果像一条逐级排错链：

把信号放在 prompt group 上没用。Group-level regret 并没有触达写出 Skill 名字的 token，oracle exposure 反而从 54.3% 降到 33.6%。

把 bonus 广播到整条 trajectory也没用。它会让模型更想读 Skill，却没有告诉模型该读哪一个；oracle 与 misleading exposure 一起上升，trial success 仍是 41.8%。

把 credit 落到 oracle read action 上终于有效。Action credit 把 clean single-oracle 提升到 64.6%，trial success 到 45.0%。但如果读完 oracle 再读三个错误 Skill 仍能拿满分，模型就没有理由停下来。

最后加上 single-read 约束，才得到完整的 SkillGate。Trial success 达到 50.0%，clean single-oracle 达到 75.4%，oracle exposure 83.9%，misleading exposure 降到 21.8%，平均每条轨迹只读 1.11 个 Skill。

这组消融说明，粒度不是越细就自动越好。信号要同时满足两件事：落到真正决定 " 选谁 " 的 identity token 上，并且不能允许靠多读来购买信用。

05

为什么不直接训练一个

更强的 Router

一种自然的想法是，既然选择难，那就把它从 Agent 里拿出来，专门训练一个 Router 或 Reranker，先挑出一个 Skill，再交给冻结的 executor。

论文把这个方案也放在同一组 280-trial protocol 下做了比较。

这里有三个很有意思的结果。

只靠提示词没有用。在 system prompt 里直接要求 "read only one"，读取行为几乎没变，成功率反而从 37.1% 降到 35.0%。这不是一句指令没写清楚，而是 policy 没有被训练出这个决策。

Router 准确率更高，不代表 Agent 成功率更高。Qwen3.5-27B Router 的 Top-1 oracle 是 68.6%，高于 SFT-9B Router 的 60.0%，但接到同一个冻结 executor 后，任务成功率反而是 36.8% 对 40.7%。

原因是 " 路由选对 ""executor 真的去读了它 "" 读完以后正确执行 " 是三个不同变量。一个外置 Router 只优化第一步，后两步仍可能断开。

SkillGate 从完整 16 候选中自主选择，达到 50.0%。它甚至超过了把唯一正确 Skill 直接广告给冻结 SFT executor 的 48.2% ceiling。这不意味着 SkillGate 比 oracle 更懂答案，而是说明选择与执行必须一起训练，只把正确文件递到一个没学会使用它的 policy 面前，并不足以得到最强 Agent。

06

五个 Agent benchmark 上，

9B policy 从 40.8% 到 53.2%

（1）实验配置

训练与评测覆盖 Claw-Eval、SkillsBench、SETA、SWE 和 Terminal-Bench 2.0。训练集共 491 个任务，不包含任何 Claw-Eval 任务；训练 oracle 与评测 oracle 在 Skill identity 上也完全不重合。

所有受控训练方法都从同一个 Qwen3.5-9B SFT checkpoint 出发，进行 100 个 step 的在线 GRPO，每个 prompt 采样 8 条 rollout，global batch 为 128，SkillGate 的 selector coefficient 为 0.20。每个配置跑在 16 张 H800 上。

任务结果使用 385-trial protocol：56 个非 Claw 任务各重复 4 次，加上 161 个 Claw-Eval 任务各 1 次。更细的 read behaviour 与消融则使用 70 个任务、每题 4 次的 280-trial subset。

（2）核心结果

完整 SkillGate 的总体 trial success 为53.2%：

相比共同的 SFT 初始化 40.8%，绝对提升12.4 个百分点；

相比相同初始化、数据、step 和超参数的 outcome-only SkillRL 47.0%，提升6.2 个百分点；

在五个 benchmark 上都是所有 9B-scale 方法中的最好或并列最好；

Claw-Eval 达到 60.2%，尽管训练中没有任何 Claw-Eval 任务，也没有见过其对应的 oracle skill。

表中的 frontier model 是绝对能力参考，结果揭示了一个很清楚的分离：SkillGate 的总体成功率高于 Qwen3.5-397B-A17B 的 51.7% 和 DeepSeek-V3.2 的 47.5%，而所有 frontier model 的 oracle exposure 都不到 50%。模型规模可以靠通用能力补回一部分任务，却不会自动长出一个可靠的 Skill selector。

更重要的是，提升来自 " 选得更好 "，不是 " 读得更多 "。Outcome-only SkillRL 把 oracle exposure 提到 54.3% 的同时，也把 misleading exposure 推到 69.6%；SkillGate 则把二者拉向相反方向：oracle 83.9%，misleading 21.8%。

07

选得更准，推理反而更便宜

Skill selection 常见的另一条路是预先把多个 Skill 全塞进上下文，或者允许 Agent 边试边多读。但两者都会让上下文和交互成本随候选数量增长。

SkillGate 的结果正好相反。与 outcome-only SkillRL 相比，它的 unique skill reads 减少41.2%，Agent turns 减少5.2%；输入 token 也更少，只有输出 token 略有增加，更像是在读之前多想一点，而不是读错以后反复试错。

在上下文成本上，SkillGate 实测每条轨迹载入约 2.1k 个 Skill-body token，基本等于 " 提前装入一个 Skill" 的 2.2k；如果把 16 个候选全部预加载，则需要 34.7k，约为按需读取的16 倍。

所以这里的收益并不是拿更多推理成本换出来的。Selector 学会一次命中之后，Agent 既更准，也更少读、更少绕路。

08

从 Skill 选择再往外看：

长轨迹不该只有一个 advantage

SkillGate 研究的是 Skill，但它指向的是一个更一般的 Agentic RL 问题：一条长轨迹里经常交错着性质完全不同的决定。

选择哪个 Skill、调用哪个工具、批准哪次高风险操作、决定何时停止，以及真正执行任务，它们依赖的证据不同，时间尺度不同，错误代价也不同。把最后一个 task reward 广播给所有 token，写起来最简单，却默认这些决定应该被同一种证据、同一个方向更新。

SkillGate 给出的答案不是再训练一个 reward model 去猜每一步值多少，而是先问一个更便宜也更可验证的问题，哪些 token 属于哪一种决定？如果边界能够被工具调用结构精确识别，就可以直接把 token support 分开，让每类信用只落到它真正有资格评价的动作上。

当然，这个方法也有清楚的边界，当前每个训练配置只有一次 run；训练任务需要知道正确 Skill；action-local selector 也无法直接给 " 什么都不读 " 这种 abstention 分配正信用。但至少在 " 从一组相似 Skill 中选对一个，并用它完成长程任务 " 这个问题上，结果已经说明，可靠的选择不是模型变大以后自然溢出的能力，而是一种需要被显式训练的能力。

当 Skill 库从几十个走向几千个，真正稀缺的可能不再是知识本身，而是 Agent 在正确时刻打开正确知识的能力。

关注 + 星标，获取 AI 前沿进展与开源一线动态