代理技能 (Agent Skills) 是什么? 解决了什么问题?

过去几个月，在 AI 工程领域中，受到最多讨论的话题之一是代理技能 (Agent Skills) 这个由 Anthropic 推出的代理模式 (agentic pattern)。

从宏观角度来看，大致可以整理出以下的时间轴

Anthropic 在 2025 年 10 月 16 号推出 Skills (连结)
社群在 10 月底左右陆续有 Skills 相关的开源项目 (连结)
OpenAI 在 12 月 12 号把 Agent Skills 加入 ChatGPT 与 Codex (连结)
Anthropic 在 12 月 18 号，进一步推出跨平台的标准化 Agent Skills (连结)

从上述时间轴可以看到，代理技能从推出到被 AI 工程社群采纳，仅花了约两个月的时间。这不禁让人问，究竟代理技能是什么、解决了什么问题，让社群会如此快速地采用这个新模式。

在这篇文章，我们会试着从开发与使用代理的痛点出发，然后一步步带着读者们，解决这些痛点，进而能够理解代理技能的价值。

什么是代理技能 (Agent Skills)?

在 Anthropic 团队公开给的第一个有关代理技能的讲座(连结) 中，代理技能的提出者 Barry Zhang 谈到一个相信大家都有过的挫折，那就是明明 AI 模型的能力很强，也能解决博士等级的难题，但为什么有时候要 AI 做事时，AI 却没有办法做好?

Barry Zhang 的观点是，就像一个通用能力很强的人，如果缺乏专业领域的知识与技能，在解决某个特定领域的问题时，可能也会无法有效做好，AI 代理有同样的问题。而代理技能就是通过赋予 AI 代理专业技能与知识，让 AI 代理能够更有效完成任务。

具体来说，代理技能的官方定义是「Skills are folders containing instructions, scripts, and resources」，意即一个包含指令、脚本与资源的资料夹。，这个资料夹能够让 AI 代理根据所面对到的情境，来选择并使用。

举例来说，Anthropic 的 Claude 最近新增了文件编辑功能，使用者可以上传 PDF，然后让 Claude 来编辑。在往下读之前，大家或许可以先暂停一下，思考一下假如你要实作的话，会如何让 Claude 这类 AI 代理编辑 PDF 档案?

Claude 的 PDF 编辑功能正式透过代理技能来做到，假如看到 PDF Skills 这个 Anthropic 团队公开的代理技能 (连结)，有以下结构：

.
├── SKILL.md
├── forms.md
├── reference.md
└── scripts/
    ├── check_bounding_boxes.py
    ├── check_bounding_boxes_test.py
    └── ...

可以看到在资料夹当中有 SKILL.md 这个 Markdown 档案 (连结)，该档案直接註明假如要处理 PDF 文件，可以使用哪些套件、如何使用那些套件。除此之外，在该资料夹中也有 /scripts子资料夹，而该资料夹中带有很多处理 PDF 文件的客制化脚本，让 AI 代理可以直接呼叫来使用。

在有了这个资料夹后，未来 AI 代理如果有遇到要处理 PDF 的情境，就可以直接进到该资料夹，按照 SKILL.md 的规范来处理 PDF，并且可以直接呼叫 /scripts 当中的脚本来做某些 PDF 的处理操作。

从概念上来说，代理技能就是上面谈到的这样，非常的简单。不过这样看似简单的设计，背后其实有不少精闢之处，以下让我们更詳細地讨论。

为什么代理技能会被提出? 代理技能解决了什么问题?

在初步理解完代理技能是什么后，相信读者们脑中应该有不少疑问。接著让我们来进一步谈代理技能被提出的脉络，从中解答一些常见问题。我们会从不同的情境切入，来谈假如没有用代理技能，在实作 AI 代理或使用 AI 代理时，会遇到什么问题，然后再透过回推可以如何解决这问题，来让大家一步步理解代理技能。

解决 AI 代理执行结果不幂等的问题

在代理技能解决的众多问题中，让我们最有感的是「让 AI 代理的执行结果幂等」这一点。众所皆知，大型语言模型是现代 AI 代理背后的大脑，而大型语言模型带有不确定性 (non-deterministic) 的特性，会让每次的生成结果都可能有不同的结果。

从比较技术的角度来看，这意味着如果没有特别处理，AI 代理针对任务的执行结果，往往是非幂等的 (备註：所谓的幂等或常听到的 idempotent，是指某个操作，不论做多少次，都会是相同的结果。这对軟體开发或某些特定类型的任务来说，能够确保稳定性，是很重要的特性。我们在要能够做到稳定，幂等 (idempotent) 是很关键的要点。所谓的幂等性，是指 API 的呼叫或者操作，不论做多少次，都会是相同的结果；或者换个角度说要做到不论请求几次，API 都不会产生副作用。当能够做到幂等性，就能够确保在重试时，不论重试几次，都能确保只有执行一次，这样能避免当遇到各类状况，导致的不必要重复。我们在这篇文章有谈及相关概念有谈过这个概念，推荐不熟的读者可以回顾)。

因为有这种不确定性，从大型语言模型兴起后，工程师会透过提示词工程 (prompt engineering) 来规范模型的输出，例如透过给予人设、风格等设定，让模型的回复能够更贴近预期。

不过，进到代理时代，因为代理开始会有行动与操作，除了提示词外，需要有方法来规范代理的行动，让代理的执行结果能更贴近幂等。代理技能就是进一步的拓展，让提示词跳脱指令，拓展到脚本与资源等其他形式，这能让代理在行动时更加贴近使用者想要的。

举例来说，如果 AI 代理要处理 PDF，如果纯下「帮我根据以下需求修改这份 PDF (附上詳細需求)」这个提示词，AI 代理可能有几种不同做法，例如自己从头写相关的函式，包含解析 PDF、解截取文字、将改写内容转回 PDF 格式等等的函式然后执行 (但每次从头实作的函式，可能写法不同，也不保证每次都会写对)；也可以选用开源套件 (但因为能用的开源套件很多，所以每次选的不一定是同一个)。

因为多元的可能性，让仅用指令型的提示词时，最终的结果会变得很不稳定，即使同一个提示词，每次可能有不同结果。但假如透过代理技能，预先把要用的套件与脚本等资源都放在技能资料夹，当代理要处理 PDF 档案时，每次都会执行同样的脚本，就会让成果变得很稳定。

解决脉络窗口有限的问题

在代理技能推出时，Anthropic 团队有附上一些范例，其中有一个是在技能的资料夹中，只有放 SKILL.md 这个带有指令的 Markdown 档案。这个范例让社群中有不少人感到困惑，毕竟假如 Skills 的资料夹中只放 SKILL.md 档案，这样跟一般的提示词 (prompt) 有什么不同?

毕竟早在两年前，Cursor 就有推出 Cursor Rules (詳見 2-1 提示词是什么? 如何透过 .cursor/rules 设置提示词? )，甚至 Anthropic 的 Claude Code 本身也有斜线命令 (Slash Commands)，也是单纯放 Markdown 档案。

在 Anthropic 的官方回覆中，有提到两个主要区別点。第一个是斜线命令是由人指定的，所以如果人没有指定，AI 代理不会主动用；不过代理技能则会由 AI 代理根据情境自行使用。

看到第一个区別，相信大家可能会问「那为什么不让 AI 代理也能自动用斜线命令就好? 何必额外创造代理技能这个新名词呢?」。

这是因为斜线命令在载入时是一次全部载入整份 Markdown 档，不只是 Anthropic 的 Claude，许多社群中热门的 AI 工具也有同样的设计。这会导致的问题是，假如要让 AI 自动挑选使用，AI 就需要扫过所有的 Markdown 档案。换句话说，如果这麼做，AI 代理在实际做任何事之前，已经消耗大量 tokens 並佔据极大部分的脉络窗口 (context window)。

消耗大量 tokens 並佔据极大部分的脉络窗口的问题在于，一来会导致成本提高 (每多消耗 tokens 就会多花钱)，二来精準度会下降。不过，假如原本的设计会导致这问题，为什么自动载入代理技能就不会有这两个问题呢?

这是因为代理技能採用了漸進式揭露 (progressive disclosure) 的模式，这是代理技能设计绝妙的地方。在每个技能的 SKILL.md 档案中都需要標注 name 與 description 来註明该技能用途为何，当代理载入技能时，会先扫过这两个欄位，而不会载入整份 SKILL.md，所以大幅降低 tokens 消耗，也只会佔据极小部分的脉络窗口。

事实上，代理技能採用资料夹的方式，也能貫彻漸進式揭露的模式。当把脚本拆到獨立的檔案，SKILL.md 中只需要註明在什么情况下要用哪个脚本，而不用把完整脚本写出来，这也让 tokens 消耗小上不少。

漸進式揭露 (progressive disclosure)

在上面提到，代理技能透过漸進式揭露这个设计模式，来减少 tokens 的消耗與佔用更少的脉络窗口。事实上，这个设计模式不仅用在代理技能上，在代理的其他面向也看得到其身影，因此我们特别拉出一个段落来谈。

虽然漸進式揭露这名词听起来有点艰涩，但相信多数前后端工程师，在工作上早已接觸过这个设计模式。常见的分页 (pagination) 就是基于这种模式。比起一次载入所有资料，先载入部分资料，等使用者需要更多资料时，再透过到下一页来载入更多资料。

除了代理技能外，目前業界也陸續把漸進式揭露用在 MCP 的加载上 (备註：不熟 MCP 的读者可以回顾 Agent 実作 — 工具 (tools) 與 MCP 伺服器。

举例来说，AI 代理的脉络窗口中，过去佔據最大空间的，多半是 MCP 相关的东西。举例来说，像 Cursor 这类 MCP 客户端，会在最开始加载所有工具，导致往往还没用任何 MCP，脉络窗口就已经消耗数萬个 tokens。

大家可能会问，在加载 MCP 时，可以先加载名称與描述就好，不用载入完整的工具，这样不就能减少 tokens 消耗吗?

这样想没有错，可惜现实没那麼单纯。以社群中有名的 GitHub MCP 来说，整个 MCP 有 35 个工具，加起来的工具名称與描述就高达 2.6 萬个 tokens。这导致 Cursor 一开始支援 MCP 时，在当时的版本中，Cursor 为了避免脉络窗口被吃光，限制最多只能载入 40 个工具。

因此 Cursor 的做法之一 (连结)，是不再一开始就载入 MCP 工具描述，而是把 MCP 的工具描述视为可延遲载入的档案，并在代理执行过程中依需求搜寻並载入特定工具，而不是一开始就全部加载。这种只在需要的时候载入的做法，让 tokens 用量大幅降低高达 46.9%。

無獨有偶，Anthropic 在《Introducing advanced tool use on the Claude Developer Platform》一文 (连结) 中有提出几乎一样概念的方法，不在一开始加载需要上萬个 tokens 的所有 MCP 工具，而是一开始仅加载约 500 tokens 的搜寻工具，然后在代理運行期間，再根据需求去搜寻需要的 MCP，每次可能找个两三个工具，頂多消耗几千个 tokens，而不是几萬个。

上面这种做法，也是漸進式揭露的体现，在实务上能帮上非常大的忙。

什么是代理技能 (Agent Skills)?

为什么代理技能会被提出? 代理技能解决了什么问题?

解决 AI 代理执行结果不幂等的问题

解决脉络窗口有限的问题

漸進式揭露 (progressive disclosure)

阅读更多