SKT：60 万个 Agent Skill 摆在面前，模型却不知道怎么用——那就造题教会它

你有没有遇到过这种情况：给 Agent 接了一堆 Skill 文档，每个都写得清清楚楚——输入什么、输出什么、调用哪段脚本。结果呢？模型要么压根不去翻这些文档，要么翻完了照样我行我素，该犯的错一个不落。

问题不在文档写得不好，也不在模型不够聪明。是模型从来没有被训练过"怎么用 Skill"这件事。

这周刷到的这篇 SKT 就是冲这个问题来的。说实话，我一开始以为又是一篇"合成数据 + SFT"的流水线工作，读完之后发现它最值钱的地方不在主结果，而是一个反面实验：没经过验证的合成数据，训练之后模型反而变得更差了。这个发现对所有在造合成数据的人都值得敲个警钟。

核心摘要：公开的 Agent Skill 已经超过 60 万个，但模型普遍不会用——不会挑、不会组合、不会照着执行。SKT 的思路很直接：既然没有现成的 skill 使用数据，那就从真实 skill 出发反向造题，再用一套"规则验证 + Agent 验证 + 难度控制"的三重关卡把垃圾数据筛出去，让强 teacher 模型在通过验证的任务上跑出正确轨迹，拿去 SFT。结果在 2 个模型 × 2 个 harness × 4 个 benchmark 的 16 组比较里全部上涨，SkillsBench 上从 5.80 分涨到 15.79 分。我的判断：这不是底层突破，是一套非常扎实的工程方法论，但"验证环节不可省"这个结论，比论文本身的方法更值得记住。

论文标题: SKT: Skill-Use Training at Scale via Verified Synthetic Data Generation

arXiv: 2608.02287

作者: Zelin Tan, Yiqun Zhang, Hao Li, Zhiyao Cui, Hejia Geng, Shao Zhang, Hangfan Zhang, Yang Chen, Xiaosong Wang, Lilong Wang, Zhenfei Yin, Shuyue Hu, Chen Zhang, Lei Bai

发布日期: 2026 年 8 月 3 日

🎯 Skill 越来越多，会用的人没有

先说说这个问题的背景。

Agent Skill 这东西，你可以理解成一个自包含的"技能包"——一份 Markdown 指令文档，加上可选的脚本、模板、示例资源，模型在需要的时候把它加载进上下文，照着里面的规程干活。这个形态今年火得很快，论文给出的数字是公开发布的 skill 已经超过 60 万个，还在涨。

生态是繁荣了。但有个很尴尬的事实：skill 的可获得性，不等于模型的可用性。

论文把"用好一个 skill"拆成了四个环节：从海量候选里识别出相关的那个，理解它的接口约束，把多个 skill 协调成一条连贯的工作流，再执行规程拿到结果。每一步都可能翻车。我自己的经验也印证这一点——之前在做工具调用类 Agent 的时候，最头疼的不是模型不知道答案，是它根本不知道手头有工具可用，或者知道有工具但参数填得乱七八糟。

已有的研究在干嘛呢？大部分在做 skill 检索（怎么从库里捞出对的 skill）、skill 内化（把 skill 知识蒸进参数、减少运行时依赖）、或者用 skill 辅助 agent 自我改进。这些工作解决的是"skill 怎么被找到、被表示"，恰恰绕开了最核心的问题：模型到底怎么才能学会理解、协调、执行这些技能。

这个空缺，就是 SKT 要填的。

图1 画得挺形象。左边是训练前的窘境：LLM 面对 to-prd、markdown、gif-creator、pdf、xlsx 一堆 skill 文件满头问号——"Which skill? When to use? How to use?"。右边是训练后的状态：面对"发票欺诈检测"任务，模型有条不紊地走完五步——提取 PDF 扫描件、加载 xlsx 查表、模糊匹配供应商、校验字段、生成报告，全部打勾。下方的性能柱状图更直观：SkillsBench 从 5.72 涨到 12.23，涨幅 +114%；SkillEval 从 56.00 涨到 70.56；MolBench-Bind 和 AgentSkillOS 也分别涨了 +37% 和 +10%。注意 SkillsBench 那个 +114% 是相对涨幅，绝对分其实还很低，这个后面细聊。

🏗️ 方法：一条"宁缺毋滥"的造数据流水线

SKT 的核心思路一句话能说完：从真实 skill 反向出题，把题验证到"确实可解、确实需要 skill、确实不太简单"，再让强模型做题，把做对的轨迹拿去训练。

但魔鬼在验证环节。整条 pipeline 分三段：Skill Curation（选技能）、Task Synthesis（造题）、Trajectory Synthesis（造轨迹），每一段都卡着好几道闸门。

图2 是完整架构。上半部分是 Skills Curation：从开放 skill 库出发，用 rubric-based LLM filter 检查 skill 适配性和多 skill 可组合性，选出 skill 组合。中间是 Tasks Synthesis：模板驱动的 TaskGen 生成任务包，然后连续过 rule-based verifier、agent-based verifier、difficulty controller 三道关，过不了的带着反馈回去重修。左下是 Trajectory Synthesis：模型在 harness 里跑任务，轨迹再过 rule-based validator 和 LLM validator 双重检查，通过的才进训练集。右侧展开了一个任务包的内部结构：instruction.md、environment/ 目录、task.toml 配置、test/ 评测脚本、solution/ 参考解。

选技能：不是抓到篮里都是菜

从候选集合 \(\mathcal{C}\) 里挑 skill，先看单个 skill 能不能支撑"可执行、客观可检查"的任务——一个只会输出审美观点的 skill 是没法出客观题的，直接淘汰。然后按基数 \(k\) 采样 skill 组合（实验里 \(k \in \{1, 2, 3\}\)），多 skill 组合还要过一个 composition judge，确认这几个 skill 在 workflow 里扮演不同角色、拼得起来。拼不起来的打回重采。

这一步其实决定了数据的天花板。你想想看，如果挑出来的 skill 组合本身就是牵强拼凑的，后面造出来的任务自然就是缝合怪，训练信号必然混乱。

造题：三道闸门，一道比一道严

任务合成是整条 pipeline 最重的部分。TaskGen 读取所有选中 skill 的内容，填充固定模板，产出一个完整任务包：指令、隔离运行环境、执行配置、可执行评测器、参考解，五件套齐全。

接下来是层层验证，我觉得这是全文最值得抄作业的部分。

一道是规则验证，全是确定性检查：组件齐不齐、文件路径对不对、参考解在干净环境里跑不跑得满分、有没有把答案逐字抄进指令里。这些检查零成本、零误判，先把低级错误全部拦掉。

再一道是 Agent 验证，查语义层面的东西：指令有没有说清楚要产出什么、完成任务所需的信息在本地环境里是不是真能找到、有没有变相泄漏答案。这里还有个很巧妙的设计叫 Skill Dependence 测试——同一个任务跑两遍，一遍给 skill 一遍不给，如果模型不给 skill 照样能完成，说明这题根本不考 skill，白出了，打回。

第三道是难度控制。让一个固定 solver 对任务独立跑 5 次，通过率达到 0.6（5 次里 3 次满分）就判定太简单，送回去加难度。太容易的任务没有训练价值，这个直觉做过 RL 数据的人应该都有——模型已经会的东西，再教一万遍也学不到新东西。

没过审的任务不是直接扔掉，而是带着具体错误反馈和难度建议送回 TaskRepair 修复，修完重新排队过审。这个"反馈引导修复"的循环比一扔了之的数据利用率高得多。

造轨迹：双重验证，第一个全对的才算数

任务合格了，才轮到 teacher 模型登场。四个 teacher（MiniMax-M2.5、GLM-5、Qwen3.5-397B-A17B、DeepSeek V4 Pro）分别在 DeepAgents 和 OpenCode 两种 harness 里做题。

轨迹的验收同样是双重的：规则侧要求评测器给满分、正常终止、工具调用 trace 格式良好、有明确的 skill 访问记录；LLM 侧逐个 skill 检查——是不是真的在动手前查阅了、是不是影响了具体决策、是不是被正确应用了。都过了，这条轨迹才进训练集 \(\mathcal{D}_{\mathrm{traj}}\)。

有个细节我很喜欢：失败的 rollout 重采样时，不把失败原因暴露给下一次尝试。这是为了防止 teacher 靠着错误反馈"作弊"——那样产生的轨迹里会混入本不该有的纠错信息，学生模型学不到。

训练本身倒是平平无奇，标准的 masked autoregressive SFT：

其中 \(\mathcal{A}(\tau)\) 是所有 assistant 生成的 token——推理、工具调用、回复都算，而 system 消息和工具返回的 observation 留在上下文里但不计 loss。工程上这个做法很常规但很关键：工具返回往往又臭又长（一个文件内容几千 token），如果让它们参与 loss，梯度信号会被大量"复制观察内容"的廉价目标稀释，真正值钱的决策 token 反而学不到东西。

📊 数据与实验配置

最终产出的数据规模是这样的：从 skills.sh 公共库精选 2,000 个 skill，合成 4,000 个任务包（单技能 1,520 个、双技能 1,295 个、三技能 1,185 个），再跑出 27,164 条通过验证的轨迹（DeepAgents 14,277 条、OpenCode 12,887 条）。

训练侧，基座模型选了 Qwen3.5-9B 和 Gemma 4 E4B-IT 两个开源模型，全参数 SFT，学习率 \(5 \times 10^{-6}\)，cosine schedule，序列长度上限 64k token，只训 1 个 epoch。评估用四个 benchmark：SkillsBench（77 题）、作者自己提出的 SkillEval（100 题）、MolBench-Bind（37 题）、AgentSkillOS-Bench（30 题）。

🧪 结果：16 组比较，全部上涨

主结果一句话：所有 16 个 model-harness-benchmark 组合，SKT 全部跑赢原始模型，绝对增益从 3.20 分到 18.91 分不等。

表1：主实验结果，四次运行的均值±标准差。SKT 在两个模型、两种 harness、四个 benchmark 上全部取得提升。

几个我读出来的点。

SkillsBench 上的提升幅度看着最吓人——Qwen3.5-9B 从 5.80 到 15.79，快翻三倍了。但冷静点看，这个 benchmark 满分 100，原始模型只考个位数，说明题目对 9B 模型来说难到接近地板。从"几乎全错"到"能做对一小半"，相对涨幅自然夸张，但 15.79 分的绝对水平离"能用"还有距离。这个 benchmark 更适合当难度探针，不适合当能力证明。

反过来，SkillEval 上的数字更实在：55.24 涨到 72.48，17 个点的绝对提升，而且基线本身不是地板分，这个含金量更高。当然，SkillEval 是作者自己造的 benchmark，自己出题自己涨分总要打个问号——不过它的任务来自与训练池不相交的 held-out skill 池，而且外部 benchmark（SkillsBench、MolBench-Bind、AgentSkillOS）也全涨了，过拟合自家榜单的嫌疑基本可以排除。

Gemma 4 E4B-IT 这个 4B 小模型在 AgentSkillOS 上从 42.23 涨到 47.38，只涨了 5 分出头，而 Qwen3.5-9B 在同项涨了接近 6 分但起点是 74 分。小模型天花板更低，这个趋势符合直觉，但也提示这套方法对基座能力是有要求的。

🔬 消融分析：比主结果更有意思的部分

说实话，这篇论文的消融实验比主结果更让我有感觉。每一个都回答了一个真问题。

涨的是"用 skill 的能力"，不是"记住了知识"

一个自然的质疑：SFT 之后模型变强，会不会只是因为它把 skill 内容背下来了？换 skill 池就露馅？

作者做了个对照：评测时把 skill 撤掉（withheld）vs 正常提供（provided）。

图3 是四张折线图，横轴是 withheld → provided。灰色虚线是 Original，蓝色实线是 SKT。看 SkillsBench-OpenCode 那张：skill 撤回时 SKT 只有 6.4，跟 Original 的 5.0 几乎贴着；skill 一提供，SKT 直接蹿到 15.8，Original 只挪到 5.8。SkillEval 两张图形态一样——撤回时两者差距很小（42.1 vs 36.4、35.0 vs 30.3），提供时差距拉到 17 分以上（72.5 vs 55.2、70.5 vs 51.6）。

这个图的信息量很大。SKT 模型在 skill 撤回时只有 0.53 到 5.69 分的微弱优势，skill 提供时优势立刻放大到 8.68 到 18.91 分。结论很清楚：训练学到的是"怎么用"的行为模式，不是"内容是什么"的死知识。

不过说句实话，撤回条件下那零点几到五点几的残余优势，说明知识内化也不是完全没有——少量 skill 的通用模式（比如"先读文档再动手"这类元行为）确实沉进了参数里。这不算坏事，反而是免费送的泛化。

全篇最重要的一个实验：没验证的数据是有毒的

这个实验我反复看了两遍。同样的合成任务，一组走完整的验证流程，另一组跳过验证直接让 teacher 跑轨迹，分别 SFT。

图4 是横向柱状图，零线是 Original。蓝色（SKT，验证过）在四个 benchmark 上全部为正：SkillsBench 涨 10.0 分、MolBench-Bind 涨 11.5 分、SkillEval 涨 17.2 分、AgentSkillOS 涨 5.1 分。橙色（Unverified SFT）全部为负：分别跌 1.9 分、6.1 分、5.6 分，AgentSkillOS 上直接崩了 19.5 分。一来一回，两条路线的差距拉到 11.9 到 24.6 分。

看到 AgentSkillOS 上那根暴跌 19.5 分的柱子时，我愣了一下。

这个结果的警示意义超出了 skill 训练本身：合成数据不是免费的午餐，垃圾轨迹教出来的不只是"没学会"，是"学坏了"。未经筛选的 teacher 轨迹里混着大量侥幸答对的、没看 skill 瞎蒙的、中途出错的样本，学生模型照单全收，把坏习惯学了个十成十。现在正在用自蒸馏、自博弈造数据训 Agent 的团队，这个实验值得贴在墙上。

换套 Agent 框架还管用吗？

实际部署里一个很现实的问题：我在 DeepAgents 上造的数据，模型迁到 OpenCode 环境里还有效吗？两套 harness 的工具接口、提示格式都不一样。

图5 对比了三种配置：Original（灰点）、Cross-harness（紫色三角，用另一套 harness 的数据训练）、Matched-harness（蓝色菱形，用评测同款 harness 训练）。SkillsBench 上 OpenCode 评测：Original 5.8，Cross 11.6，Matched 15.8——Cross 保留了 Matched 增益的 58%。SkillEval 上保留比例在 49% 到 52% 之间。

结论：跨 harness 训练能保留大约一半的增益（49.1% 到 58.1%），说明学到的 skill 使用行为里有个 harness 无关的通用内核——大概就是"先查文档、按规程办事"这种元能力。另一半则是 harness 特异的格式适配。

更省事的做法是混合训练：把两种 harness 的轨迹混起来训一个 checkpoint，结果在所有组合上都涨（2.64 到 18.81 分），跟各 harness 的"专精" checkpoint 比，差距最多只有 2.71 分，有几项还反超。工程上这很友好——不用为每套部署环境单独训模型。

Scaling：skill 池越大，学生越强

图6 是 scaling 曲线，横轴是训练用的 skill 数量（0 到 2k），纵轴是 SkillEval 分数。Original 是 55.2，用 100 个 skill 造数据就涨到 59.8，500 个到 67.4，1k 到 70.8，2k 到 72.5。曲线还在往上走，没有饱和的迹象。

从 100 个 skill 到 2,000 个，分数单调爬升了 12.7 分，而且 1k 到 2k 这一段还没走平。作者手上还有 60 万个 skill 没用完，这条曲线的外推空间就是这篇论文"at Scale"这个标题的底气。

不过坦率的讲，这里有个我没完全想明白的地方：skill 数量从 100 到 500 涨了 7.6 分，从 1k 到 2k 只涨了 1.7 分，边际收益递减其实已经开始了。到底是 skill 多样性到顶了，还是 9B 学生的容量到顶了？论文没有拆解，说实话这块我也不是特别确定。

多技能组合：K=2 最甜，K≥3 变难

图7 按任务所需 skill 数量分组。K=1 的任务（25 个）：Original 9.54，SKT 涨 7.4 分到 16.94。K=2（19 个）：Original 只有 3.95，SKT 暴涨 16.8 分到 20.72。K≥3（33 个）：Original 4.04，SKT 涨 8.0 分到 12.08。

K=2 是甜点区——两个 skill 刚好构成有训练价值的协调模式（比如"先解析再校验"），增益直接拉到 16.8 分。但 K≥3 时增益回落到 8.0 分，绝对分也只有 12.08。我的理解是，三个以上 skill 的协调已经逼近 9B 模型的规划能力上限，训练数据能教行为模式，但教不会超出容量的规划。多 skill 复杂编排这个坑，靠 SFT 填不平，可能得留给 RL 或者更大的基座。

🤔 我的判断

聊聊这篇论文的真实定位。

它是什么：一套非常扎实、可以抄作业的合成数据工程方法论。三重任务验证、双重轨迹验证、反馈引导修复、不向重试泄漏失败信息——这些设计单拎出来都不算惊天动地，但组装在一起形成了一个真正闭环的质量控制体系，而且每一环都有消融背书。数据质量控制做到这个颗粒度的论文，不多。

它不是什么：不是训练范式的突破。核心就是"强 teacher 造轨迹 + 验证过滤 + SFT 蒸馏"，骨架跟这两年一大批 agentic 数据工作同源。teacher 阵容（DeepSeek V4 Pro、GLM-5 这个量级）决定了学生的上限大概率超不过老师——SKT 解决的是"把 skill 使用行为从大模型搬进小模型"，不是"创造出超越现有模型的能力"。

几个我存疑的点。其一，整条 pipeline 大量依赖 LLM judge——skill 筛选要 judge、组合性要 judge、轨迹验收还要 judge，这些 judge 本身的准确率和一致性论文给的信息不够多，judge 翻车会沿着 pipeline 逐级放大。其二，所有实验都是 9B 和 4B 的学生模型，这套方法对 70B 以上的模型还有没有同样的增益？小模型提升容易，强模型上还能不能涨，才是真考验。其三，SkillsBench 上个位数的基线分数，让"翻三倍"这种叙述听起来比实际更激动人心，读这篇论文的时候建议全程盯着绝对分。

工程启发，我觉得至少有三条可以直接拿走：

造 Agent 训练数据的时候，"任务先验证、轨迹再验证"的双层结构值得照搬。只验结果不验过程的 pipeline，就是在给模型喂毒——那根跌了 19.5 分的柱子是最好的反面教材。

Skill Dependence 测试的思路可以泛化。任何"想让模型学会用 X"的训练（工具、API、知识库），都应该在出题阶段就做配对测试：不给 X 也能答对的题，根本不配进训练集。

还有混合 harness 训练这个结论——一个 checkpoint 打所有环境，丢的分不到 3 分。对需要多环境部署的团队，这直接省掉一倍的训练成本。

最后说回那个更大的图景。60 万个 skill 躺在仓库里，绝大多数模型对它们视而不见，这个gap 本身就是接下来一两年 agent 训练里最确定的机会之一。SKT 给了第一条可复现的路径，但它显然不是终点——scaling 曲线还没饱和，K≥3 的复杂编排还没解决，RL 版的 skill-use training（带着验证器当 reward）几乎是顺理成章的下一步。我赌这个方向半年内会有跟进工作把分数再抬一截。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我