Agent Skills 是一套轻量的开放格式，用文件夹把指令、脚本和参考资料封装成可复用模块，让 AI Agent 在遇到匹配任务时按需加载。 一个 Skill 的最小形态，就是一个包含 SKILL.md 文件的文件夹。
对正在建设企业级 AI Agent的团队来说，它解决的是一个具体问题：模型有通用能力，却不知道你们公司先查哪张表、用哪个指标口径、按什么格式交付。把这些程序性知识写进 Skill，Agent 就能在同类任务中重复使用。
Agent Skills 是什么，为什么会出现
通用模型能写文案、读表格、改代码，但真实业务任务常常卡在流程知识上。一份周报要先核对哪些字段，一次活动复盘要按什么口径归因，遇到异常数据该找谁确认，这些内容通常散落在文档、聊天记录和老员工的经验里。
Skill 把这些内容装进一个文件夹，带来三个直接变化：
- 能力可复用。一次写清流程，后续同类任务直接调用，不必每次重新交代。
- 上下文按需占用。启动时只读取技能名称和描述，任务匹配后才加载完整说明。
- 经验可版本管理。文件夹能进 Git，能审查、回滚、分发，也能跟着组织规则一起更新。
提示词只影响当前对话，Skill 是文件，可以随项目或组织长期维护。这也是它适合承载企业方法的原因。
这套格式由 Anthropic 在 2025 年 10 月随 Claude 推出，2025 年 12 月作为开放标准发布。Anthropic 2026 年 10 月 22 日的公告显示，Anthropic 已将 Agent Skills 的名称、标志、GitHub 组织和 agentskills.io 域名捐赠给 Linux 基金会下的 Agentic AI Foundation。截至 2026 年 10 月，已有 70 多个 Agent 平台集成该格式，包括 ChatGPT、Cursor、GitHub Copilot 和 VS Code；公开的 Skill 约 100 万个，累计安装近 2.8 亿次。
一个 Skill 文件夹由哪些部分组成
一个 Skill 至少包含一个 SKILL.md 文件。完整目录可以按用途拆分：
<code class="language-text">customer-feedback-review/
├── SKILL.md
├── scripts/
│ └── check_fields.py
├── references/
│ └── review-rules.md
└── assets/
└── report-template.md
</code>| 部分 | 作用 | 是否必需 |
|---|---|---|
| SKILL.md | 存放元数据和操作说明 | 必需 |
| scripts/ | 存放可执行代码 | 可选 |
| references/ | 存放按需读取的长文档 | 可选 |
| assets/ | 存放模板、图片、数据表 | 可选 |
SKILL.md 由 YAML frontmatter 和 Markdown 正文组成。frontmatter 是文件开头的元数据区，用两条 --- 包住：
<code class="language-markdown">--- name: customer-feedback-review description: 汇总客服对话并生成结构化复盘，按问题类型归类并附原文证据。用于周度反馈分析、版本问题归类和客服质量复盘。 --- # 客户反馈复盘 ## 输入 - 客服对话导出文件 - 统计时间范围 ## 步骤 1. 检查必填字段，缺失记录单独列出。 2. 按咨询、故障、投诉、建议四类归档。 3. 每条结论附一条原文引用。 4. 输出周报，包含问题分布、变化趋势和待跟进事项。 </code>
必填字段只有两个。name 用来标识技能，只能使用小写字母、数字和连字符，长度 1 到 64 个字符，并且要与父目录名一致。description 写清技能做什么、什么时候使用，长度 1 到 1024 个字符。 Agent 主要靠这两个字段判断是否启用技能，描述含糊会直接影响触发。
常用可选字段包括 license、compatibility、metadata 和 allowed-tools。allowed-tools 用于声明预先批准的工具，目前仍是实验性字段，不同客户端的支持程度不一样。正文可以写操作步骤、输入输出示例和常见边界情况，规范建议主文件控制在 500 行以内，正文约 5000 tokens 以内，超出的内容拆到 references。
几个目录的分工也不同。scripts 放字段校验、格式转换、批量统计这类确定性操作；references 放长规范、术语表和案例；assets 放模板、图片和数据文件。Agent Skills 规范还提供了 skills-ref 校验库，用来检查 frontmatter 是否符合命名规则。
渐进式披露如何控制上下文
Agent 读取技能分三层：
- 启动时读取所有技能的 name 和 description，每个技能约 100 tokens。
- 任务匹配后读取完整 SKILL.md，建议控制在 5000 tokens 以内。
- 执行过程中按需读取 references 或运行 scripts，未用到的文件不进入上下文。
脚本是这套机制里很实用的一环。排序、校验、格式转换交给代码执行，结果比模型逐字生成更稳定，也更省 token。脚本作为工具运行，不必把源码和输入文件完整读进上下文。
Agent 如何找到并调用 Skill
Agent 不会一次性读完所有技能，它按三步工作：
- 发现。启动时读取每个技能的名称和描述，建立可用清单。
- 激活。用户任务与描述匹配时，读取完整 SKILL.md。
- 执行。按照说明操作，必要时运行脚本或读取参考资料。
Claude Code 官方文档说明，技能可以由模型根据描述自动调用，也可以由用户输入 /skill-name 直接调用。任务型技能可以设置为只允许手动调用，避免在不合适的场景自动执行。
代码执行让技能可以处理确定性任务。比如从 PDF 中提取表单字段，脚本运行完直接返回结果，模型不需要理解整个 PDF 的排版。对于需要重复运行、结果必须一致的流程，这种方式比纯文本指令更可靠。
技能没有按预期触发时，先检查 description。描述需要同时回答做什么、什么时候用、涉及哪些任务词。描述太泛，技能可能一直不触发；描述太窄，又会错过相邻场景。
技能数量过多也会带来管理成本。启动时的元数据会占用少量上下文，相似描述也容易互相竞争。按任务场景分组启用，比一次装几十个技能更容易维护。
从零创建并使用一个 Skill
下面以一个客户反馈复盘 Skill 为例，走一遍完整流程。使用现成技能也可以参考同样的判断标准，先确认客户端支持 Agent Skills，再放到约定目录或通过界面启用，最后用真实任务验证。
步骤一：先确定任务和验收标准
选那些重复出现、步骤稳定、结果好坏有明确标准的任务。比如把客服对话按问题类型归类，输出带原文证据的周报。任务每次都要临场判断，或者一个月只做一次，先不要封装。
验收标准要能写成检查项：字段是否齐全、分类是否覆盖、每条结论是否有原文引用、异常记录是否单列。标准写不清，技能很难稳定产出。
步骤二：写 SKILL.md
先写 frontmatter，再写正文。前面的示例已经包含基本结构。description 要同时写清功能和场景，例如“汇总客服对话并生成结构化复盘，按问题类型归类并附原文证据。用于周度反馈分析、版本问题归类和客服质量复盘”。
正文只写 Agent 执行任务需要知道的内容。输入是什么、按什么顺序处理、遇到缺失或冲突怎么处理、最终输出长什么样。把操作步骤写具体，比堆一段抽象原则更有用。
步骤三：补充脚本和参考资料
只有当任务需要确定性计算、批量校验或固定格式转换时，才加脚本。长规范放 references，模板放 assets。每增加一个文件，都要考虑谁维护、什么时候更新。
如果平台已有相近的行业 Skill 库，可以先取一个模板，再按自己的流程修改。拿现成技能做起点，通常比从空白文件写起更快。
步骤四：放到 Agent 能找到的位置
Claude Code 会从两个常见位置发现技能：个人级 ~/.claude/skills/<skill-name>/SKILL.md，项目级 .claude/skills/<skill-name>/SKILL.md。个人级跨项目可用，项目级跟着仓库走，适合团队共享。企业还可以通过托管设置或插件统一分发。
其他支持 Agent Skills 的客户端通常会扫描各自约定的目录，或在界面上提供启用入口。格式相同，存放位置和权限模型可能不同，换工具前先查该客户端的文档。目录名要与 frontmatter 的 name 一致，否则可能加载失败。
步骤五：测试触发与产出
至少用三类任务测试：典型任务、边界任务、不该触发的任务。看它是否在正确的时机加载、是否按步骤执行、输出是否满足验收项。
触发过多就收紧 description，触发过少就补任务词和场景词。改完再跑一遍，不要只看一次成功。技能的价值在于稳定，一次偶然的好结果说明不了什么。
步骤六：版本管理与治理
把 Skill 目录放进版本控制，记录负责人、适用版本和变更原因。第三方 Skill 先读 SKILL.md 和脚本，检查依赖、网络访问和权限，再决定是否安装。生产环境先小范围试用，确认行为符合预期后再扩大范围。
Skill、提示词、MCP 分别解决什么问题
这几个概念经常被放在一起问，可以用一张表区分：
| 对象 | 主要作用 | 典型内容 | 加载或调用时机 |
|---|---|---|---|
| 提示词 | 说明当前这一次任务的要求 | 目标、约束、示例 | 随对话进入上下文 |
| Skill | 封装一类任务的流程与知识 | SKILL.md、脚本、参考资料 | 任务匹配时按需加载 |
| MCP | 连接外部系统与工具 | 服务器、工具、资源 | 需要访问外部能力时调用 |
| 工具 | 执行一个具体动作 | 查询、写入、发送 | 被 Agent 调用时执行 |
四者可以叠加使用。一个分析任务里，MCP 服务负责连上数据库，Skill 规定指标口径、分析步骤和报告格式，工具执行查询，模型负责判断和表达。任何一层缺失，结果都可能不稳定。
选择时看缺口在哪里。缺外部数据和操作能力，补 MCP；缺稳定流程和交付标准，写 Skill；只是一次性要求，用提示词就够。把这几种能力混为一谈，容易出现用提示词硬撑流程、用 Skill 替代系统连接的情况。
企业什么时候值得把经验做成 Skill
企业常见的错误，是把所有经验都做成 Skill，最后没人维护。更稳妥的做法是先筛任务，再决定投入。
值得做成 Skill 的任务
- 高频重复，至少每月多次出现。
- 步骤能写清，关键判断有标准。
- 输出格式固定，错误成本较高。
- 多人或多团队需要同一套做法。
- 过程需要审计，结果需要复用。
暂时不适合封装的任务
- 一次性探索，没有重复价值。
- 依赖实时人际协商，流程无法提前写定。
- 规则每周变化，维护成本高于收益。
- 没有明确验收标准，失败后说不清哪里不合格。
一个简单判断：如果任务失败后，团队说不清哪一步不合格，就先别封装。Skill 只能固化已经想清楚的方法，不能替代方法本身。
落地时要补的三件事
第一件事是所有权。每个 Skill 要有负责人和复审周期。没有负责人的技能很容易过期，描述、脚本和业务规则都会逐渐脱离实际。
第二件事是权限与审计。技能能读什么数据、能调用哪些工具、能执行哪些脚本，要有边界；运行记录要能追溯。Agent 治理要覆盖技能的分发、启用、版本和退出机制，不能只管模型和账号。
第三件事是效果评估。看触发准确率、任务完成率、返工率、耗时和 token 消耗，别只看安装量。一个被安装很多次却很少正确触发的技能，对业务很难产生价值。
在企业级场景里，Skill 还要接上真实数据和统一口径。ThinkingAI 企业级 Agent 平台把 Skill 作为能力沉淀的一层，支持把一次分析流程中验证有效的步骤沉淀为可复用 Skill，供后续任务调用，并提供私有化部署选项。模型或场景调整时，已经沉淀的流程仍可作为参考。
技能数量本身没有意义。能稳定触发、产出可验收、有人维护，才值得留在库里。
常见问题
Agent Skills 和 Claude Skills 是一回事吗
Agent Skills 是开放格式的名称，Claude Skills 是这套格式在 Claude 产品中的常见叫法。Anthropic 是主要推动者，标准现已交给 Agentic AI Foundation 治理，其他平台也可以实现。讨论具体功能时，以所在客户端的文档为准。
不会编程也能写 Skill 吗
可以。只写 Markdown 就能完成多数流程型技能。脚本用于确定性计算、格式校验或批量处理，不会写代码时可以先不写，等任务确实需要再补。
SKILL.md 可以写很长吗
规范建议主文件控制在 500 行以内，正文约 5000 tokens 以内。长规范、术语表和案例拆到 references，让 Agent 按需读取。主文件越长，激活时占用的上下文越多，维护也越困难。
Skill 和 MCP 需要二选一吗
不需要。MCP 负责连接外部系统和工具，Skill 负责告诉 Agent 何时、按什么步骤、以什么标准完成任务。一个任务可以同时用到两者，缺哪层补哪层。
为什么 Skill 没有被触发
常见原因是 description 太泛或缺少任务关键词，也可能是技能未启用、存放位置不对、同名冲突。先检查描述是否同时写清做什么和何时使用，再用代表性任务测试。触发仍然不稳定时，可以改为手动调用，先确认技能本身能正常执行。
第三方 Skill 可以直接用吗
可以先审再装。检查 SKILL.md、脚本依赖、网络访问和所需权限，只从可信来源安装。生产环境先在小范围验证，确认行为、权限和输出都符合要求后再扩大使用范围。
