解析 SkillsBench (arXiv:2602.12670)：给 Agent 外挂技能究竟是不是伪需求？

近日翻阅了多机构联合发表的论文《SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks》（arXiv:2602.12670）。这篇工作探讨了一个在构建大语言模型（LLM）Agent 时极其核心的工程问题：给 Agent 外挂“技能”（Skills）到底有没有用？如果有用，提升有多大？

在日常开发中，我们常说的“外挂技能”指的是结构化的过程性知识包，包括指令、代码模板、参考资源和验证逻辑等。我们习惯在推理阶段把这些文件丢给模型，希望借此跳过高昂的微调成本，让通用模型掌握垂直领域的专业操作。但社区一直缺乏标准化的基准来量化这种做法的实际收益，而 SkillsBench 刚好填补了这一空白。

核心设定与测试数据 #

SkillsBench 收集了 11 个领域的 86 个任务（实际包含 84 个评估任务），所有任务都在基于 Harbor 框架的容器中隔离运行，并带有确定性的验证器。研究团队测试了 7 种 Agent 与模型的组合结构，总共收集了 7308 条运行轨迹。

测试被分为三种对照条件：

1. 无技能（No Skills）：仅提供基础的提示词指令。
2. 精编技能（Curated Skills）：提供人类专家编写的完整领域过程性知识。
3. 自生成技能（Self-generated Skills）：不提供外部技能文件，而是让模型在执行前自行生成相关的过程性知识。

测试结果给出了一些非常反直觉且有工程指导意义的结论：

第一，技能整体有用，但存在巨大的领域差异。 从平均数据来看，人工精编的技能让任务通过率提升了 16.2 个百分点。但在不同领域的表现极度不均：医疗保健领域提升了惊人的 51.9%，而软件工程（SWE）领域仅有 4.5% 的提升。此外，在 84 个任务中，有 16 个任务在加入技能后反而出现了负优化。

第二，模型无法“左脚踩右脚”上天。 在“自生成技能”的测试条件下，模型的平均表现不仅没有提升，反而下降了 1.3 个百分点。这意味着让模型在动手前先通过自身领域知识写个操作指南是完全无效的。

第三，小模型加好技能，能打败裸奔的大模型。 数据表明，参数较小的模型在获得优质技能加持后，表现可以反超更大的模型。例如，配备了技能的 Haiku 4.5 胜率达到了 27.7%，直接击败了无技能状态下胜率仅为 22.0% 的 Opus 4.5。

核心结果数据表 #

结合工程实践的个人思考 #

看完这些数据，结合实际开发 Agent 的经验，我谈几点个人的看法。

1. 必须拆除对 LLM “自主规划”的迷信 我们经常有一种错觉：只要提示词工程做得足够深，让模型多思考一步（比如先写 Plan 再执行），它就能搞定一切。但 SkillsBench 明确戳破了这一点。本质上，模型缺乏特定领域的“过程性隐性知识”。如果你让一个不懂某项医疗设备操作规范的新手去自己写一份操作指南，他写出来的东西大概率是充满幻觉的常识拼接。拿着这种充满幻觉的指南去执行，只会错得更离谱。这告诉我们，在专业领域，人类专家沉淀的行业惯例和避坑指南是不可替代的。

2. “系统工程”的投资回报率正在超越单纯的“模型缩放” Haiku 4.5 加技能打败 Opus 4.5 的结论，对广大开发者是个极其利好的信号。与其盲目追求使用最昂贵、参数量最大的 API，不如将精力投入到上下文构建和工具链打磨上。通过将人类专家的工作流拆解为聚焦的模块化技能，配合低延迟、低成本的模型，是目前商业化落地投入产出比最高的范式。而且论文也提到，包含 2 到 3 个模块的聚焦型技能，实际上比长篇大论的完整文档效果更好。

3. 警惕上下文干扰导致的“帮倒忙” 为什么有 16 个任务在挂载技能后表现变差了？ 这在 RAG（检索增强生成）系统的开发中非常常见：过载或不精准的上下文会成为严重的干扰项。当给定的过程性知识过于复杂，或者与当前子任务不完全匹配时，模型的注意力机制会被分散。它可能会强行套用技能包里的某个看似相关但实际上并不适用的代码模板，导致原本凭直觉就能写对的代码被带偏。这就要求我们在设计 Agent Skills 时，必须遵循“高内聚、低耦合”的设计原则，宁可少给，绝不乱给。

结语 #

SkillsBench 给当前火热的 Agent 赛道提供了一份极其务实的参考报告。大模型并不是全知全能的黑盒，未来的高可用 Agent 一定是“强大推理引擎”与“优质人类经验封装”的结合体。对于工程师而言，少花点时间去玄学调优提示词，多花点时间把业务 SOP 沉淀成干净、聚焦的 Skills 技能包，才是构建系统核心壁垒的正确路径。