你可能一直在错误地使用 Agent Skills

来源：Hacker News 讨论区 作者观点：针对近期关于“Agent 自生成技能无用论”的论文提出反驳，指出其实验设计存在根本性缺陷，并详细阐述了 Agent Skills（智能体技能）的正确使用范式。

背景

围绕 Claude Code 的生态系统目前正处于一个快速迭代且命名规范混乱的阶段，其变化速度之快甚至超出了大多数生产级工具的标准。在这一生态中，Skills（技能）这一概念被广泛讨论，但也极易被误用。

近期，Hacker News 上出现了一篇题为《Study: Self-generated Agent Skills are useless》（研究：自生成的 Agent 技能毫无用处）的论文。尽管该标题带有明显的主观编辑色彩，但它迅速引发了关注。作者指出，虽然自己从 Agent 编写的 Skills 中获得了巨大价值，但在工作中经常看到同事错误地使用这一功能。

该论文的核心论点在于评估“自生成技能”的效果，其实验设置如下：

Self-Generated Skills: 不提供任何预设技能，而是提示 Agent 在解决问题前先生成相关的程序性知识。此举旨在隔离 LLM（大语言模型）潜在领域知识的影响。

作者认为，这种实验设计实际上只是让一个本身无法很好解决特定问题的模型，在尝试解决问题前先“写一写”关于该任务的思考。这不过是重新发明了“思维链（Thinking Blocks）”，而且效果更差。

核心内容

1. 技能的“反模式”：自生成的陷阱

作者指出，最常见的错误模式是：“我的 Agent 在这件事上表现不好，所以我让 Agent 为这件事写一个 Skill。”

这种做法与“思维链”无异。要让 Agent 创建出有价值的 Skill，必须确保 Agent 能够“看到”知识缺口。作者用计算机科学入门课程中的经典例子来类比：如果你让某人写出制作花生酱果酱三明治（PB&J）的步骤，如果他们没有真正经历过制作过程中的困难，他们往往无法理解哪些步骤是真正具有挑战性的。

同样，如果在新的会话中直接询问 Agent 如何构建一个 Skill，这相当于 AI 时代最大的失误之一：直接将别人的问题逐字逐句地抛给 LLM，然后将 LLM 的回答直接作为最终回复。如果作者问某人如何用 Agent 做了一件很酷的事，而对方只是当场让一个新的 Agent 根据问题生成一个 SKILL.md，作者认为这种回答毫无价值。

2. 什么是 Skills？

在深入正确使用之前，作者首先定义了 Skills 的本质。作为一种基础原语，Skills 本质上是带有元数据的 Markdown 文件，用于帮助 Agent 或工具判断何时调用它们。文档的其余部分则是技能的具体内容。

每个 Skill 拥有独立的文件夹，这不仅用于教授 Agent 如何执行某项任务，还可以为其提供更好的工具。

一个典型的 Skill 目录结构如下：

.claude/skills/
└── monitor-gitlab-ci/
    ├── SKILL.md          # 上述提到的元数据及说明文件
    ├── monitor_ci.sh     # 复杂的命令行脚本
    └── references/       # 额外参考资料
        ├── api_commands.md
        ├── log_analysis.md
        └── troubleshooting.md

作者分享了一个自己频繁使用的示例：用于让旧版本的 Claude 监控 GitLab CI。这是一个包含简单 Markdown 说明的文件夹，解释了设置流程，要求 Agent 监控 CI 直到作业失败或全部通过。此外，还包含一个简单的 CLI 工具以防止 Agent 编写冗长的脚本，以及用于处理边缘情况的额外参考资料。

3. Skills 的正确使用场景

作者提出了 Skills 的三个主要正确用途：

A. 补充上下文（Skills for Context）

Agent 是完全无状态的，意味着每次新对话都像是与模型初次见面，它不知道你的项目背景或几分钟前你在做什么。虽然 CLAUDE.md 能解决部分问题，但对于大型项目而言，它无法包含所有信息。

例如，如果在一个 monorepo（单体仓库）中让 Claude 运行 SIL 测试，Agent 需要自行摸索：

1. 识别项目使用的语言；
2. 查找该语言的常见测试模式；
3. 解析复杂的 Docker Compose 配置；
4. 发现容器需要 x86 架构，而用户使用的是 Mac（ARM 架构）；
5. 查找 CI 配置等。

这一系列摸索过程可以通过为常见但非通用的模式编写 Skills 来解决。当模型在你项目中执行某项简单基础任务遇到困难时，告诉它创建一个 Skill 来填补其完成该任务所需的知识缺口。

B. 避免重复（Skills for Repetition）

Skills 的另一个简单用途是解释经常执行的任务。例如，作者经常要求 Agent 确保 docs/、Merge Request 描述、Issue 和代码库之间的一致性。为此，作者创建了一个简单的 Skill，以避免每次都需要手动输入这些指令。

C. 解决难题（Skills for Hard Problems）

Claude 虽然能解决一些非常困难的问题，但可能需要消耗大量 Token（如 $500 的额度），并且可能需要多次干预以防止“奖励黑客”行为（Reward Hacking，即模型利用规则漏洞获取高分而非真正解决问题）。

每当作者不得不介入一个问题，一旦 Agent 摆脱困境，作者会询问 Agent：是什么知识缺口导致它无法独立解决这个问题？有时答案很琐碎，但有时则具有深刻的洞察力。在这种情况下，作者会让 Claude 创建一个 Skill 来填补这一知识缺口。

4. 实验验证与结论

作者修改了原始基准测试，按照自己的方式引入 Skills，结果正如预期：拥有 Proper Skills 的 Agent 完美通过了测试。

作者承认自己没有资金对这一结果进行完全验证，但初步结果已足够令人满意。作者推测，这种方法可能需要使基准测试的数据集规模翻倍，这可能是原始论文作者未包含此方法的原因。

核心结论： 创建 Skill 只有两个理由：

1. 记住新颖的问题（通过解决难题积累的知识）；
2. 避免重复（简化常见流程）。

如果你只是在一个新的会话中向 Agent 询问关于某事的 Skill，那么它很可能没有价值。Skill 必须包含“新鲜模型所不知道的知识”，这些知识可以来自：

• 你在提示词中解释的常见流程；
• 从难题中获得的经验汇总；
• 甚至让 Agent 去研究一些并非全新但需要整理的内容。

关键要点

• 批判“自生成”误区：让 Agent 在解决它不擅长的任务前“先生成技能”是无效的，这等同于低效的思维链，无法解决根本的知识缺失问题。
• Skill 的本质：Skill 是带有元数据的 Markdown 文件及关联资源（脚本、参考文档），旨在为无状态的 Agent 提供持久化的上下文和工具。
• 正确使用时机：
  • 上下文补充：当 Agent 在复杂项目（如多语言、多架构、Docker 环境）中摸索路径时，用 Skill 固化最佳实践。
  • 流程自动化：将高频、重复的操作指令固化为 Skill。
  • 难题复盘：在人工介入帮助 Agent 解决难题后，总结其遇到的知识缺口，将其转化为 Skill 供未来复用。
• 价值核心：Skill 的价值在于**“填补新鲜模型未知的知识缺口”**，而非让模型在真空中凭空创造流程。

意义与影响

这篇文章揭示了当前 Agentic AI（智能体 AI）应用中的一个关键痛点：如何有效地将人类经验或隐性知识转化为机器可执行的持久化资产。

1. 对基准测试的反思：指出当前许多关于 Agent 能力的评估可能因实验设计缺陷（如忽略人工引导的知识注入）而低估了 Agent 的实际潜力。
2. 工程实践指导：为开发者提供了清晰的 Skill 编写指南，强调了“人智+AI”的协作模式——人类负责识别痛点、复盘难题，AI 负责将解决方案结构化。
3. 提升 Agent 可用性：通过正确使用 Skills，可以显著降低 Agent 在复杂项目中的试错成本，提高其在生产环境中的稳定性和效率，避免陷入“每次对话都从零开始”的低效循环。

简而言之，Agent Skills 不是让 AI “自己教自己”，而是让人类将“踩过的坑”和“成功的经验”打包成标准模块