Agent Skills 入门指南：让AI智能体像搭乐高一样扩展能力

什么是 Agent Skills

Agent Skills 是一种轻量级、开放式的格式，用于借助专业知识与工作流扩展 AI Agent 的能力。简单说，它让通用型智能体可以按需迭代技能，去完成特定项目的完整业务开发。

这套标准最早由 Anthropic 提出，随后被多家大模型厂商认可，逐渐演变为一个被广泛接受的开放标准，旨在引导新一代 AI Agent 的开发生态。它的核心价值在于：Agent 可以通过加载不同的技能包，具备不同的专业知识和工具使用能力，从而稳定完成特定任务。

从工程角度理解更直观——我们现在做所有大模型开发，本质上都依赖 DeepSeek^广告、Claude、GPT、豆包这些底层模型。这些模型本身只是一个「大脑」，具备分析推理能力，但并不知道你手头有哪些工具、方法或功能可用。Skills 的作用，就是把外部能力打包成模型可以识别和调用的模块。

Agent Skills 所依赖的底层协议生态中，MCP（Model Context Protocol）是理解其运作方式的重要背景。MCP 同样由 Anthropic 提出，是一套让 AI 模型与外部工具、数据源进行标准化通信的协议。Skills 与 MCP 的关系可以这样理解：MCP 解决的是「模型如何调用外部工具」的通信层问题，而 Skills 解决的是「把什么样的专业知识和工作流打包给模型」的内容层问题。两者相辅相成，共同构成现代 AI Agent 的扩展能力框架。此外，Skills 架构的兴起也与 Claude Code、Codex 等代码智能体工具的普及密切相关——这类工具天然支持加载外部 Skills，使得技能的跨平台复用成为现实。

Skills 到底是文件还是文件夹

网上流传一个说法：「Skills 说白了就是一个 MD 文件」。这个描述并不精准。

官方文档明确指出，一个 Skills 本质上是一个文件夹。它除了必备的 SKILL.md 之外，还可以包含多类文件：

• script：外部执行脚本，如批处理命令
• reference：额外引用，如数据文件
• 模板资源：静态页面、静态样式等其他资源

最小化要求只需要一个 SKILL.md，其他都是可选的。日常工作中你看到的很多 Skills 确实只是一个 MD 文件，但不能因此就把 Skills 等同于单个文件——它的完整目录结构可以承载更丰富的能力。

值得强调的是 SKILL.md 中的两个必备元数据：name（名字）和 description（描述）。这两个是自定义或使用线上 Skills 时至少要包含的组件。

description 为什么如此关键

很多做大模型开发的人习惯定义 tool（工具），本质就是一个函数或方法，并给它加一个包含 name 和 description 的描述符。这里的 description 在整个大模型领域都是极其重要的东西。

关键在于：description 不是给人看的，是给大语言模型看的。这和项目里的 README 完全不同——README 告诉人这个项目是干嘛的、技术架构如何；而 description 是让模型识别「你到底要完成什么功能」。当模型遇到具体场景时，正是靠 description 来发现并调用对应的 Skills。

实践中很多人反映「Skills 没被用上」，根本原因往往就是 description 写得太糟糕，模型无法判断该不该调用它。因此，凡是涉及 description 的地方都要认真对待。

从技术机制上看，模型在决定是否调用某个 Skills 时，依赖的是语义相似度匹配和意图识别。当用户输入一个任务请求时，模型会将请求内容与所有已加载 Skills 的 description 进行语义比对，判断哪个 Skills 的描述与当前意图最为吻合，再决定是否触发调用。这一过程类似于向量数据库的检索逻辑——description 质量越高、语义越精准，召回率就越高。因此，description 的写法应尽量贴近用户实际会发出的指令语言，而非使用技术文档式的抽象表述。例如，与其写「提供代码质量优化服务」，不如写「当用户要求检查代码规范、重构函数或消除重复逻辑时调用此技能」，后者更接近模型实际接收到的上下文。

用两个比喻理解 Skills 的精髓

为了让抽象概念落地，可以用两个生活化的比喻来理解。

比喻一：能干的助理。 假设你是老板，有一个聪明的助理，但他有能力短板——不懂法律写不了合同、不会 PS 做不了海报、不熟悉订票系统。传统解法有两种：送他去培训，或者额外招专业人才。这两种方式都费时费力、成本高昂。Agent Skills 提供了第三条路：把专业技能打包成插件，让助理「背上背包」就具备能力。用完了随时卸下，不占用额外资源。

比喻二：手机装 App。 早期的按键手机只能打电话发短信。如今你想 P 图就装美图秀秀，想点外卖就装美团，想学法律就装相关软件，考驾照就下驾考一点通。手机本身没变，变的只是安装的 App。

这两个比喻指向同一个核心：Agent 的底座不变，变的只是外挂的技能。这正是 Skills 的精髓——告别重资产模式，拥抱轻量化的外挂形式。哪方面能力不具备都没关系，只要有对应 Skills 就能完成工作，不需要时随时卸载。

需要明确一个概念：Agent Skills 本质是「Skills 架构下的 Agent」。设计 Agent 架构时，你可以选择 Skills 架构，也可以选择 Multi-Agent 架构，二者是不同的设计路径。

Agent Skills 解决了什么问题

归纳起来，Skills 主要解决三类痛点：

1. 避免重复训练成本：通过加载 Skills 将通用底座快速武装成垂直领域的专家 Agent，避免了为让模型具备某方面能力而进行大量训练的巨大成本。

2. 跨生态复用能力：Skills 采用轻量文件格式，一次打包即可在不同 Agent 生态间流转。你在 Claude Code 里用的 Skills，放到 Codex、DeepSeek Harness、Open Claude 里同样能用——因为它们遵循同一套标准和规范，可以像搭乐高一样共享和复用能力。

3. 固化任务执行路径：SKILL.md 提供标准化的操作指引，把任务执行路径固定化，让 Agent 像流水线一样稳定完成特定任务，从而减少幻觉和出错率。

「固化任务执行路径」这一特性背后涉及一个重要的大模型工程概念：提示词工程（Prompt Engineering）与工作流编排的结合。在没有 Skills 的情况下，Agent 每次面对任务都需要从零开始推理执行路径，容易因上下文不同而产生不一致的行为，即所谓「幻觉」（Hallucination）。SKILL.md 本质上是一份结构化的系统提示词（System Prompt），它预先定义了任务的边界、执行步骤和约束条件，相当于给 Agent 配备了一份操作手册。这种做法在 AI 工程领域被称为「确定性约束」——通过显式规则压缩模型的输出空间，让结果更可预期、更稳定，从而使 Agent 能够胜任对一致性要求较高的生产级任务。

编写 Skills 的实用原则

Skills 没有严格的固定标准。官方文档给出的更多是通用性的理论和最佳实践，实际编写要根据具体场景来定。以下几条经验值得记住：

描述要越具体越好。 大模型不是你的同事，和你之间没有默契。不要用「最好」「尽量」这类模糊量词——它不懂你说的「尽量」是什么意思。要写死具体要求，比如「对我写的每一个方法都做单元测试」，而不是「最好帮我做个测试」。

正文不要写得太长。 虽然 SKILL.md 没有文件大小限制，但内容越多，调用时占用的上下文窗口就越大。上下文窗口过大时，Agent 可能无法完整识别，也难以严格遵守规范。关键在于明确指出它能做什么，而非堆砌文字。

善用反面案例。 把效果较差的输出作为反面模板写进去，明确告诉模型「不要按这种方式写」。反面案例越多，模型在推理时越能判断哪些不符合要求，从而提升输出质量。

引用文件要指明路径。 如果 Skills 引入了额外文件夹（数据、模板、参考案例等），必须在正文中明确指向具体路径。这是因为 Skills 的内容都要占用上下文窗口，机制上遵循「能不读尽量不读、能少读尽量少读」的原则——你不告诉模型去读，它就不会主动查找。

如何高效使用现成 Skills

真正需要从零手写 Skills 的场景其实很少，通常只有涉及公司具体业务系统时才需要。对于通用技能，建议优先去开源市场搜索。

目前市面上的 Skills 数量已经非常庞大——据介绍，某些平台聚合的 Claude Skills、MCP Server 和 Agent Skills 数量最少也有十几万个。国内用户可以关注腾讯提供的 Skills Hub，它做了分类并支持按 Star、更新时间等排序，使用较为方便。

具体流程是：想做数据图表就搜「图表绘图」，能找到支持多种图表类型、多主题预设的现成 Skills。找到相符的直接拿来用，不满足需求就在其基础上修改。

修改时也不必自己动手——可以让 Claude Code、Codex，或者 Hermes Agent 帮你改写。这里提到的 Hermes Agent 是在 Open Claude 基