AI-Wiki

定义

Agent Skills，是指为 AI Agent 设计的结构化技能封装：把人的经验、工程方法、领域流程、操作规范与边界条件，写成 Agent 可读取、可触发、可复用的说明文件，常见载体是 SKILL.md 这类 Markdown 文档，并配合少量元数据进行声明。

它的核心不是“给 Agent 一个新接口”，而是“把做事方法编码给 Agent”。因此，Skills 解决的是 Agent 有能力但缺经验的问题：模型本身会推理、会写代码、会调用工具，但如果没有经过流程化约束，往往会直接动手、不做设计、不写测试，或者改了 A 又破坏 B。Skill 的作用，就是把成熟做法固化成 Agent 可执行的步骤。

从文中给出的表述看，Skills 的本质是“结构化的指令和方法论”，不是函数本身，也不是分发容器。它更像工程师的方法论手册，被注入 Agent 的上下文后，指导 Agent 在特定情境下按规范办事。

在本文档中的语境

本文把 Agent Skills 放在 AI Agent 从“玩具”走向“工具”的范式变化中理解，认为它正在成为 Agent 生态中的关键层。文中甚至用“Skills 正在成为 Agent 的操作系统”来强调其地位，意思不是它取代模型或工具，而是它开始承担 Agent 行为组织、流程约束、经验复用与上下文调度的角色。

在这一语境下，Agent Skills 不只是零散提示词的升级版，而是更稳定、可迁移、可标准化的工作流资产：

它把专业经验封装成可重复执行的流程；
它可在多个 Agent 产品间迁移；
它可通过插件或市场机制安装与更新；
它可按需加载，减少上下文浪费；
它开始承载自己的理论体系，特别是在 Context Engineering 方向上。

文中还将 2024—2025 年的重点概括为“怎么跟 AI 对话”，把 2026 年的新重点概括为“怎么给 AI 设计工作流”，并把这一变化与 Skill Engineering 联系起来。这里的意思很明确：Skills 面向的是工作流设计与经验编码，而不只是单轮 Prompt 编写。

典型结构

文中的直接示例显示，一个 Skill 的核心文件通常是 SKILL.md，前部使用 YAML 声明基本信息，后部用 Markdown 写执行指令。例如模型训练 Skill 的结构包含：

name：Skill 的标识名，如 hugging-face-model-trainer；
description：一句话说明 Skill 做什么、适用于什么场景；
标题区：说明这是哪个 Skill；
When to use：触发条件或适用场景；
Steps：执行步骤；
还可扩展约束、边界和示例。

文中给出的训练 Skill 示例明确写到，适用情境包括：

用户想微调模型；
用户需要硬件推荐；
用户希望估算训练成本。

其步骤则具体到：

确定基础模型与训练方法，例如 SFT、DPO、GRPO；
估算硬件需求；
生成训练脚本；
提交到 HF Jobs；
用 Trackio 监控。

这说明 Skill 不是抽象口号，而是明确规定“何时触发、先做什么、后做什么、用哪些配套能力收尾”的结构化流程。

文中还给出一个通用模板，进一步说明 Skill 常见组成包括：

触发条件：用户提到哪些关键词、处于哪些任务场景时应激活；
执行步骤：按序列拆出操作过程；
约束：明确不要做什么、边界条件是什么；
示例：提供输入输出或操作示范。

因此，Agent Skills 的关键载体虽然是文档，但它承载的是可操作流程，而不是普通说明文。

关键机制

以结构化指令封装经验

Skills 的第一机制，是把资深工程师、研究者或业务人员的经验写成结构化指令。文中明确把它称为“给 Agent 注入工程方法论”。

这类方法论可以非常实务化。例如在 Superpowers 里，Skill 不只是让 Agent 能写代码，而是强制它先做需求澄清、拆解成 2—5 分钟的小任务、建立隔离工作分支、使用子 Agent 实现、遵循测试驱动开发、请求代码审查，最后再合并与清理。这里封装的不是某个 API，而是一整套软件工程作业方式。

所以，Skill 的价值主要不在于扩展“能不能做”，而在于提升“会不会按正确方式做”。

按需加载进入上下文

文中强调，当前模型上下文窗口虽然越来越大，例如 Claude 可到 200K、Gemini 可到 2M，但“够用”不等于“会用”。一个现实问题是模型会出现 lost-in-the-middle，也就是中间信息记不住或利用效率低。

Skills 的应对方式是按需加载：

Agent 启动时，只加载技能名称等轻量信息；
真正需要某个 Skill 时，再把完整指令读入上下文。

文中给出的量级是：启动时只需要几十个 token 的技能名；需要时再加载几百个 token 的完整指令。作者据此认为，这比把所有指令一开始全部塞进提示里，高效约 10 倍。

这说明 Skill 不只是知识封装形式，也是上下文预算管理手段，因此与 Context Engineering 紧密相关。

可跨 Agent 复用

文中把“跨平台”视为一个关键亮点，明确提到 Claude Code、OpenAI Codex、Gemini CLI、Cursor 都能直接使用同一套 Skill，并认为其背后反映出统一开放标准的形成。

对应的核心口号是“一次编写，多 Agent 运行”。这意味着 Skill 的目标不是绑定单一厂商，而是把经验沉淀为可迁移资产。只要目标 Agent 能理解相应标准或约定格式，Skill 就有机会直接复用。

文中还提到 agentskills.io 的开放标准已被 20 多个 Agent 工具采纳。这一点表明，Agent Skills 正在从零散项目习惯，走向生态级标准化。

通过插件系统分发、安装、更新

虽然 Skill 本身是方法与指令，文中指出它往往通过 Plugin 基础设施获得更高效的复用能力。2025 年 10 月，Anthropic 为 Claude Code 推出 Plugin 系统，被文中视为关键转折点：此前给 Agent 增加能力，常要手动复制文件；之后则可以通过市场与安装命令一键安装、更新和复用。

文中列出的插件系统优势包括：

统一市场；
避免冲突；
版本管理；
跨项目复用。

对应的示例操作包括：添加 marketplace、安装特定 skill、更新已有 skill。这里也说明了一个边界：Skill 与 Plugin 不是同一个东西。Skill 是内容，Plugin 更像分发与管理容器。

区别于函数型工具

文中专门区分了 Skills、Tools、Plugins 三者：

Skills：结构化的指令和方法论；
Tools（MCP）：可调用的函数接口；
Plugins：分发和管理的容器。

进一步看，三者在载体上也不同：

Skills 常以 Markdown 文件如 SKILL.md 承载；
Tools 常由 JSON Schema 加代码实现构成；
Plugins 则是目录结构加 manifest。

加载方式也不同：

Skills 是按需读取并注入上下文；
Tools 是注册后按需调用；