失败一整条轨迹，到底该怪哪一步？SkillAdaptor 用步级归因把 Agent 的技能库改对了
核心摘要
LLM Agent 越来越依赖一个外挂的"技能库"——把成功经验沉淀成可复用的 skill card，下次遇到相似任务直接检索过来用。问题是：当一条轨迹失败了，该怎么改技能库？现在主流做法是拿整条轨迹的会话级反馈去更新，结果往往是大刀阔斧改一通——要么改得不稳定，要么改得过于宽泛，下一次反而把原本能跑通的任务也搞砸了。
SkillAdaptor 这篇论文（arXiv: 2606.01311）想干一件具体的事：把"哪一步先错了、错在哪条技能上"这件事显式地定位出来，再去做最小修订，最后还得过一道"接受检查"——只有让平均指标不下降的修改才允许写回。整个 pipeline 训练无关，骨干模型冻结。在 WebShop、PinchBench、Claw-Eval 三个 Benchmark 上跨 Kimi-K2.5、GLM-5、GPT-5.2 三个模型都跑赢了 EvoSkill、AWM、ExpeL 等技能适配基线，最大单点提升在 GLM-5/WebShop 上达到 +2.3 个点。
我的判断：这不是底层突破，而是一次相当扎实的工程整合——把"故障归因"从会话级压到步级，再用一道资格门把改坏的修改挡掉。真正值钱的是那个 Qualifier，没它整个系统的方差直接崩掉。
论文信息
- 标题：SkillAdaptor: Self-Adapting Skills for LLM Agents from Trajectories
- 作者：Zhuoyun Yu, Xin Xie, Wuguannan Yao, Chenxi Wang, Lei Liang, Xiang Qi, Shumin Deng
- 机构：浙江大学；蚂蚁数科；浙江大学-蚂蚁集团知识图谱联合实验室
- arXiv：2606.01311
- 代码：https://github.com/zjunlp/SkillAdaptor
一、为什么"会话级反馈"修技能库这条路走得不顺
我之前在做 Agent 技能复用的时候踩过一个坑：智能体跑了 20 步，最后一步报错没买到对的商品。手头的 reflection 模块拿到这条失败轨迹，给出一段反思，然后让一个 LLM 去更新技能库。
听上去挺合理。问题是——它根本不知道哪一步先错的。
可能错在第 3 步检索筛错了类目，可能错在第 11 步的支付流程，也可能压根就没到那个细分场景对应的技能。但是反思模型只看到"最后失败了"这个结果，于是给出的修订往往是"把这条技能改得更通用一点""加个保险条款"——改是改了，下一次跑别的任务直接受到牵连。
这就是论文里说的 coarse failure attribution（粗粒度故障归因）。粗在哪？粗在它把失败这件事归因到"整条轨迹用到的全部技能"上，没办法精确到"是哪条技能在哪一步真正误导了 Agent"。
说实话，我看到这篇论文 abstract 第一眼有点犹豫——"步级归因"不是什么新鲜概念，PRM（Process Reward Model）那一波早就在讲这个事了。但读下去发现，作者并不是要做一个 reward model，而是要把 step-level localization 用作"技能编辑的精确探针"。这个角度倒是挺干净的。
二、SkillAdaptor 的整体架构：三阶段 + 一道资格门
图 1：SkillAdaptor 整体架构。从一条失败轨迹出发，先做 Localize 找出最早的可操作故障步，再用 Linker 把责任分摊到候选技能，最后选择 revise 或 generate，在 Qualifier 通过后才写回技能集合。
整个 pipeline 拆成三段：
| 阶段 | 干的事 | 为什么需要 |
|---|---|---|
| Skill Initialization | 用骨干 LLM 在任务集 𝒬 上裸跑（无技能、无经验），把成功轨迹蒸馏成初始技能集 K₀ | 给系统一个干净的起点，避免一开始就学到错的东西 |
| Skill Injection | 来一个新任务时，先用 Qwen3-Embedding-8B 编码做 top-k 召回，再让骨干 LLM 重排出最相关的 S_q | 不是每条技能都对当前任务有用，召回 + 重排比纯向量检索更稳 |
| Skill Adaptation | 失败轨迹 → 定位故障步 → 链接到嫌疑技能 → revise 或 generate → 资格认证 | 这是论文真正的核心，下面单拆 |
技能注入这块论文给了一个公式：
φ(·) 是 Qwen3-Embedding-8B，d_q 是任务描述。先粗筛 top-k，再让骨干 LLM 给一遍重排——这其实就是 RAG 那一套搬过来用，没什么花活，但稳。
真正的好戏在 Skill Adaptation。
三、Skill Adaptation：把"该怪谁"这件事显式拆开
3.1 Localizer：找出"第一个可操作的故障步"
给定一条失败轨迹 τ 和这次任务用到的技能集 S_q，Localizer 输出：
t 是最早的、可以被技能修订挽回的*故障步骤，π 是观察到的故障行为描述外加改进建议。
注意"可操作"这三个字——不是任意一步都值得归因。如果一步是因为环境随机性挂的（比如网络抖动），改技能也救不回来。Localizer 做的事是把那种"换个 skill card 描述就能避免重蹈覆辙"的 step 给挑出来。
3.2 Linker：把责任分摊到具体的几条技能
定位完故障步后，Linker 负责回答"是哪条/哪几条技能害的"：
输出是一组带权重的"嫌疑技能"——w_j 越大表示这条技能在这次故障里背的锅越重。同时还会输出一个适配动作 â ∈ {revise, generate}：
- revise：故障原因是某条已有技能写得有误导，重写它
- generate：故障原因是技能库根本就没覆盖这个场景，得新写一条
这个设计挺巧的——传统做法要么只 revise（永远不长出新技能），要么只 generate（技能库无限膨胀）。SkillAdaptor 让 Linker 自己判断，相当于把"诊断"和"治疗方案"绑定输出。
3.3 Modifier：动手改
revise 路径下：把权重最高的那条技能拿出来重写后替换原版本。 generate 路径下：从 t* 周围的本地化上下文里合成一条新技能 append 进去。
为了防止技能库膨胀，加了一个去重阈值 θ_dup = 0.95——新生成的技能跟现有技能向量相似度过这条线就不让进。
3.4 Qualifier：这一步是命门
这是我觉得整篇论文最值钱的设计。
候选更新 K⁺ 不是直接写回，而是要过一道"资格认证"。怎么过？把任务集 𝒬 在两套技能下各跑一遍，比性能：
ℳ(·) 是执行反馈指标。Δ ≥ 0 才接受，否则丢弃这次修改、保留原集合。
整个适配最多迭代 10 轮，连续 3 轮技能集没变就提前停。
为什么我说这一步最值钱？做过类似项目的人都知道，一个看起来合理的修订，落到全局上很可能是负向的——因为你只看到了它修复的那条 case，没看到它打破的那 100 条 case。Qualifier 这道门相当于强制"每一次修改都必须在群体上正向"。
后面消融实验数据会证明这一点，先卖个关子。
四、一个真实的 PinchBench 案例：技能怎么从坏变好
图 2：技能修订前后对比。Localizer 定位到第 6 步出问题，Linker 把责任链接到旧 skill card 的第 4 行——那行只做了浅层校验就直接 finalize，导致权限和最终结果不一致。修订后加了"finalize 前必须重算"这条约束。
这个 case 我多看了几眼。修订动作非常外科手术式——只动了一个浅校验到最终确认之间的不一致问题，没去重写整张卡。
这就是步级归因相比会话级的核心区别：会话级反馈会让你倾向于把整张技能卡改一遍，步级归因则把改动严格框在"这一步出问题的那一行"附近。
五、实验：跨 3 个模型 × 3 个 Benchmark 都赢了
5.1 主结果（WebShop）
| 方法 | Kimi-K2.5 Score / Succ% | GLM-5 Score / Succ% | GPT-5.2 Score / Succ% |
|---|---|---|---|
| Base Model | 32.1 / 24.6 | 33.8 / 25.3 | 36.2 / 25.0 |
| A-Mem | 30.3 / 22.6 | 30.9 / 20.0 | 33.7 / 21.6 |
| AWM | 34.0 / 25.3 | 34.5 / 25.6 | 36.5 / 28.3 |
| ExpeL | 35.7 / 26.0 | 35.2 / 27.3 | 37.0 / 29.6 |
| EvoSkill | 40.4 / 31.3 | 41.6 / 32.6 | 43.1 / 33.0 |
| SkillAdaptor | 41.6 / 33.0 | 43.9 / 33.3 | 44.8 / 34.3 |
几个观察值得说一下：
第一，A-Mem 在所有三个模型上都比 Base 还差——这其实是基于会话级反馈的方法常见的"翻车现象"。粗糙的归因 + 没有质量门，改一通技能库反而把骨干模型的能力压下去了。这数据很能说明问题。
第二，SkillAdaptor 在 GLM-5 上对 EvoSkill 的提升最大（+2.3 个点 Score），在 GPT-5.2 上 +1.7 个点。这种"在更弱的模型上提升更明显"的模式挺有意思——能力差一点的模型更容易因为粗糙的技能修订翻车，所以步级归因+资格门带来的稳定性收益更显著。
第三，看一眼 Succ%——SkillAdaptor 在 Kimi-K2.5 上把成功率从 EvoSkill 的 31.3% 拉到 33.0%。这两个点对 WebShop 这种已经卷到 30%+ 的 benchmark 来说算挺能打的了。
5.2 PinchBench 和 Claw-Eval
| 方法 | PinchBench Avg Score% (Kimi/GLM/GPT) | Claw-Eval Avg Score (Kimi/GLM-Pass@3/GPT) |
|---|---|---|
| Base Model | 63.6 / 70.2 / 74.8 | 73.2 / 74.4% / 72.8 |
| OpenSpace | 66.0 / 72.3 / 75.8 | 74.0 / 75.9% / 73.6 |
| SkillAdaptor | 67.2 / 73.8 / 76.6 | 75.8 / 77.4% / 75.3 |
这两个 Benchmark 上的提升幅度比 WebShop 小（PinchBench 上 SkillAdaptor 对 OpenSpace 的最大提升约 +1.5 个点）。原因猜一下：PinchBench 和 Claw-Eval 的任务结构相对简单，Base 模型的 Score 已经在 70%+，再往上的边际收益自然就薄了。
但即使薄，方差降了——后面消融部分会看到这个证据。
六、消融：Qualifier 才是真正的"压舱石"
| 配置 | WebShop Score / Succ% | PinchBench Avg | Claw-Eval Avg / Pass@3 |
|---|---|---|---|
| (0) Base model | 32.1 / 24.6 | 63.6±8.7 | 73.2±1.3 / 74.4% |
| (1) SkillAdaptor (full) | 41.6 / 33.0 | 67.2±5.2 | 75.8±1.6 / 77.4% |
| (2) w/o Localizer & Linker | 35.8 / 28.6 | 65.3±6.8 | 74.5±1.4 / 75.9% |
| (3) w/o Qualifier | 34.0 / 26.3 | 65.8±8.1 | 74.2±2.7 / 75.9% |
| (4) initial skills only | 32.5 / 25.3 | 64.1±7.3 | 73.9±1.8 / 74.4% |
几个非常有意思的观察：
去掉 Localizer 和 Linker（配置 2）：WebShop 成功率从 33.0% 直接掉到 28.6%，掉了 4.4 个点。这证明步级归因不是花架子——你不知道是哪一步、哪条技能错的，改也是瞎改。
但真正让我皱眉的是配置 3——去掉 Qualifier： - WebShop Score 从 41.6 掉到 34.0，掉了 7.6 个点（比配置 2 还惨） - Claw-Eval 的方差从 ±1.6 飙到 ±2.7，PinchBench 方差从 ±5.2 飙到 ±8.1
5.2 个点的方差直接膨胀到 8.1——这是什么概念？意思是没有 Qualifier 的话，你今天跑出来 70 分，明天可能跑出 60 分，模型整个变得"不可预测"。
这数据其实给了一个特别工程化的洞察：没有质量门的"自动技能更新"是一个高方差陷阱。Localizer + Linker 让你"改得准"，但 Qualifier 让你"改得稳"。少了哪一个都不行。
最后配置 4——只保留初始技能不再适配——基本跟 Base 一样。这说明初始的 K₀ 没什么神奇之处，所有的提升都来自后续适配过程。
七、一些工程细节：开销和 token 增量
图 3：迭代轮次的两个曲线。前几轮接受率最高、得分增益最快；3-4 轮后逐渐收敛，对应论文里"连续 3 轮不变就提前停"的策略。
图 4：左到右是三个 Benchmark。SkillAdaptor 在 PinchBench 和 Claw-Eval 上 prompt 变长（多了技能卡注入）但平均交互步骤减少；WebShop 上 token 增长更小，绝对 step 也降到 15.5。
具体数字： - WebShop：交互步骤从 18.9（Base）降到 15.5（SkillAdaptor），但输入 token 从 1507 涨到 2651 - PinchBench：步骤 10.4 → 9.8，token 13927 → 16902 - Claw-Eval：步骤 7.3 → 5.8，token 11470 → 13933
一句话总结：用 prompt 长度换交互轮数。 在 Agent 应用场景里这个 trade-off 通常划算——多花一些注入技能的 token 成本，省下的是多步交互带来的延迟和环境调用开销。
八、我的判断
亮点
-
Qualifier 这道门是真的有用——不是论文里普通的工程细节，而是核心机制。所有做"自动技能编辑/记忆更新"的工作都应该考虑加一道资格检查，不然方差会让你一脸懵。
-
步级归因的拆分干净：Localizer（哪一步）+ Linker（哪条技能 + revise/generate）是一个很清晰的两段式诊断。这种"先定位故障再决定治疗方案"的范式，比那种端到端反思生成的做法可解释性强得多。
-
跨 3 个模型测下来都赢——这点我比较看重。很多技能适配的工作只在某一两个模型上 work，换个 backbone 就不行了。SkillAdaptor 跨 Kimi、GLM、GPT 三家都稳定提升，说明这个 pipeline 的设计不依赖特定模型的怪癖。
我觉得有问题的地方
-
Qualifier 的开销不便宜。每次候选更新都要把任务集 𝒬 在两套技能下各跑一遍——这是 O(|𝒬|) 的额外执行开销。论文没仔细讨论这块的工程成本。如果 𝒬 很大，每轮迭代的 Qualifier 成本可能比 attribution + modification 加起来还高。
-
Linker 的"权重 w_j"是怎么得到的？ 论文给了公式但没明确说是 LLM 直接估的还是用某种 attention 之类的信号。如果是 LLM 直接估，那这个 weight 的可靠性其实存疑——LLM 在打分这件事上一直不是很稳。
-
WebShop 上 A-Mem 比 Base 还差这件事，论文一笔带过，但其实值得多说两句。这反映出一个真实的产品风险：做不好的 memory/skill 系统不仅没用，而且有害。这是 Agent 长程记忆这一波工作必须正视的问题。
-
基线选择略可疑：表 1 里 PinchBench 和 Claw-Eval 上只跟 OpenSpace 一个 baseline 比，没有跟 WebShop 上那批 EvoSkill、ExpeL 比。是因为那些方法在 PinchBench/Claw-Eval 上没法直接跑，还是结果不好看？论文没说清楚。
工程启发
如果你也在做 Agent 的技能/记忆系统，这篇论文给的几条经验可以直接借鉴：
- 加一道 Qualifier：任何自动更新都不要无脑 commit。在小一点的回归集上跑一遍前后对比，跌了就回滚。这个东西工程上不复杂，但能极大提升系统稳定性。
- 把"故障归因"显式拆开：不要让一个 LLM 一口气吐出"反思 + 修订"。先定位、再分摊责任、再决定动作，每一步都更可控。
- revise / generate 二选一让 Linker 自己判断：不要写死成"每次失败都生成新技能"或"每次失败都重写旧技能"，技能库会膨胀或退化。
九、对 Agent 长程进化方向的一点联想
回头看这两年 Agent 的进化路径——从早期的 chain-of-thought，到 ReAct，到 reflection，到现在的"经验/技能复用 + 自适应更新"——其实是一条很清晰的"让模型从交互里学到东西"的路。
但学进来的东西怎么管理、怎么修订、怎么过滤，一直是这条路上没解决干净的事。SkillAdaptor 这套 step-level + Qualifier 的设计，我觉得指了一个挺务实的方向：与其让模型自己反思自己改，不如在外面套一道严格的质量控制。
说到底，Agent 的"技能库"最终是一个产品级的可维护资产，不是一次性 demo 用的玩具。任何自动更新机制都得考虑稳定性、可审计性、可回滚——这些才是真正决定一套技能系统能不能在生产环境跑住的东西。
这篇论文的 Qualifier 我觉得就是奔着这个方向去的——虽然论文里没明说"可审计性"这个词，但 Δ ≥ 0 才接受这个机制本身，就把"每一次更新"变成了一个可解释、可追溯、可回滚的事件。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新 AI 前沿，关注我。