但幸运的是，我聪明到可以告诉你应该如何做。安森，2026年2月16日 • 阅读时间 5分钟 图片来源：Lin Dai / Unsplash 关于Claude代码的整个生态系统非常混乱，命名约定很糟糕，变化的速度超出了我见过的任何生产工具。然而，技能可能是被最滥用的。我在工作中看到这种情况很多，但最近在Hacker News上发布了一篇文章：SkillsBench：评估代理技能在不同任务中的表现。代理技能是结构化的程序知识包，增强了推理时的LLM代理。尽管很快得到了采用，但还没有标准方法来衡量它们是否真的有效。我们提出了SkillsBench，这是一个涵盖11个领域的86个任务的基准，配备了策划过的技能和确定性验证器。每个任务在三种条件下进行评估：没有技能、策划过的技能和自生成的技能。我们测试了7种代理模型配置，通过7308条轨迹进行测试。策划的技能将平均通过率提高了16.2个百分点（pp），但效果因领域而异（软件工程增加4.5pp，医疗保健增加51.9pp），而84个任务中有16个显示负增量。自生成的技能在平均上没有提供好处，这表明模型无法可靠地生成它们所需的程序知识。集中技能（2-3个模块）优于全面文档，并且带有技能的小模型可以与不带技能的大模型相媲美。arXiv.org Xiangyi Li 这篇让我激动到写下这篇文章的论文。HN标题被编辑得有些奇怪“研究：自生成的代理技能是无用的”，但它立即吸引了我，因为我从代理编写的技能中获得了巨大价值，但我也看到我的同事们经常滥用它们。这个概念很棒，我自己也在考虑对代理生态系统的特定部分进行基准测试，所以这对我来说非常相关。总体而言，论文还不错，但有一条论点使整个东西无效：自生成的技能：没有提供技能，但提示代理在解决任务之前生成相关的程序知识。这使得LLM的潜在领域知识的影响被孤立。因此，他们所做的只是拿一个模型无法很好地解决的问题，要求它在尝试之前写出相关任务的内容。他们只是把“思考模块”重新发明了一遍，而且更糟！技能反模式 他们所做的是我不断看到的一个非常普遍的错误。我的代理在这件事情上表现不好，所以我要求代理在这件事情上写一个技能。我再强调一遍，这与思考模块是完全相同的。为了让你的代理创建有价值的东西，你必须确保它们能够看到差距。我看到这就像典型的计算机科学入门课，你要求某人写出制作PB&J的步骤，直到你挣扎着解决它时，才真正理解这个问题的难度。这直接导致了人工智能时代最大的失误，直接按字面意义向LLM提问别人的问题，并将LLM的答案粘贴为你的回应。如果我问你，你是如何与代理一起做一些酷的事情的，而你只是随便让一个新的代理根据我的问题构建一个SKILL.md，我会让你感到绝望。 什么是技能 在讨论正确用法之前，我想先介绍一下技能是什么。作为一种原始形式，它们只是包含一些元数据的markdown文件，帮助代理/工具知道何时使用它们，文档的其余部分就是技能。每个技能都有自己的文件夹，这样它不仅可以教你的代理如何做某件事，还可以为它提供更好的工具。 .claude/skills/ └── monitor-gitlab-ci/ ├── SKILL.md # 上面提到的文件 ├── monitor_ci.sh # 复杂命令 └── references/ # 额外参考 ├── api_commands.md ├── log_analysis.md └── troubleshooting.md 以上是我大量使用的技能，帮助旧版本的Claude在我的GitLab CI上工作。这是一个简单的markdown技能文件夹，主要解释了设置，并提醒代理在任务失败或所有任务通过之前需要监视CI，还有一个简单的CLI来防止代理编写脚本，以及针对边缘案例的额外参考。 上下文中的技能 代理是完全无状态的，这意味着每次新对话就像第一次见模型一样，它不知道你当前的项目是什么，也不知道你十分钟前在做什么。CLAUDE.md 做了很多来解决这个问题，但对于一个足够大的项目，它无法容纳所有内容。如果我打开一个单一代码库并告诉Claude运行SIL测试，那么它就必须四处奔忙来搞清楚如何做到这一点。它必须弄清楚项目所用的语言，然后寻找该语言的常见测试模式，会看到一个复杂的Docker Compose设置，还会看到容器需要x86，但我们在Mac上运行，然后它会查找CI等等。这些都可以通过为一般但不是通用的模式编写技能来解决。每当模型在你的项目中遇到你知道是简单基础的事情时，