AI Agent技能（Skill）详解：从概念、原理到实战案例-平芜编程栈

2025 年可以说是 AI Agent 从概念走向工程化的关键一年。你可能已经接触过 Agent、MCP、Function Calling 这些名词，也一定在不少项目里见过“给大模型加工具”的玩法。但如果你用过 Claude 的 Agent SDK，或者关注 Anthropic 官方博客，大概率会看到一个新词反复出现：Agent Skills，中文通常翻译为“技能”。很多刚接触这个概念的同学会困惑：这不就是写个 Prompt 吗？不就是封装一个工具吗？和 MCP 又有什么区别？

这篇文章我会围绕“什么是 AI 的 Skill”这个主题，从核心概念、技术构成、文件格式、创建方法、实战案例到最佳实践，完整梳理一遍。不管你是刚入门 AI Agent 开发的新手，还是已经在接大模型 API 的后端工程师，读完这篇文章之后，都能理解 Skill 的本质，并且亲手写出自己的第一个技能文件。

1. 背景与核心概念

1.1 为什么突然大家都在讨论 Skill

在展开定义之前，我们先看一个真实的开发痛点。

假设你正在基于大模型做一款代码审查助手。每次用户提交一段代码，你希望模型不仅能看懂语法，还能按你们团队内部的规范给出检查意见。于是你写了一长串 Prompt，把公司规范、代码风格、禁止事项全部塞进去。结果是什么呢？

一是 Prompt 越来越长，每次请求都浪费大量 token；
二是模型面对复杂任务时，经常“选择性忽略”你写在中间的某条规则；
三是这些规则很难复用，换一个业务场景就得重新写。

再换个场景。假设你希望模型能够解析一份复杂的 CSV 文件、绘制图表、生成报告。理论上你可以让模型一步步“思考”，但实际会发现，模型并不知道 pandas 的最新 API 长什么样，也不知道你本地有没有安装某个依赖库。这个时候 Skill 的出现就很有价值。

通俗理解：Skill 是一份“给模型看的说明书 + 配套工具包”。它把完成某类任务所需的专业知识、操作步骤、代码脚本、参考资料打包在一起，让模型在对话过程中，根据用户需求自动决定“我该调用哪个技能”，然后按照技能文档里的指引去执行任务。

专业定义：Agent Skill 是一种面向 AI Agent 的能力封装机制，通常以一个独立目录为载体，内部包含SKILL.md描述文件、脚本代码、参考文档和资源文件。模型在运行时会读取这些文件，理解技能的使用方法，再借助代码解释器或工具执行具体操作。

1.2 Skill 解决的是什么问题

Skill 要解决的核心问题有三个。

第一，知识。大模型的知识是有截止日期的。但一份 SKILL.md 文档可以随时更新，把最新版本的 API、最佳实践、内部规范写进去。模型每次调用技能时重新读取，相当于让模型在“当下”获取了最新的知识。

第二，能力复用。Prompt 只能解决“告诉模型怎么做”的问题，但没法把“怎么做”的过程沉淀下来。而 Skill 天然是一个文件夹、一套文件，可以像代码库一样提交到 Git 仓库，团队共享，跨项目复用。

第三，复杂任务的稳定性。当你把任务拆成“技能”，每个技能专注于自己的领域时，模型就不再需要在一个超长上下文里同时处理多种职责。模型可以按需加载技能，理解难度降低了，任务执行的准确性也会随之提升。

1.3 什么场景适合使用 Skill

根据目前的实践经验，以下几类场景非常适合用 Skill 来落地：

场景类型	典型需求	为什么适合 Skill
数据分析	读取 CSV、清洗数据、画图	技能里可以包含 pandas 脚本和列名映射规则
代码审查	按团队规范检查代码	技能文档可沉淀团队规范，比 Prompt 更稳定
文档处理	解析 PDF、提取摘要、生成报告	依赖库和解析步骤可以写死在技能里
运维排查	检查日志、定位异常、生成工单	脚本和排查流程可以标准化
业务辅助	专利撰写辅助、技术调研	技能可内置模板和检索步骤

2. Skill 与常见概念的边界

很多同学容易把 Skill 和 Prompt、Function Calling、MCP、Plugin 混为一谈。这里我用一张表格和几段描述把边界讲清楚。

2.1 Skill 与 Prompt 的区别

传统的 Prompt 工程，本质是把“如何完成任务”的指令写进对话上下文。它是一次性的、松散的，依赖模型的即时理解能力。

Skill 则不同，它具备结构化和可加载两个关键特点。Skill 文件在需要时才被模型读取，而不是全部塞进上下文；技能内的脚本可以被实际执行，而不是只靠模型“想象”。

简单说：Prompt 是“说给模型听的话”，Skill 是“交给模型的一套完整作业流程”。

2.2 Skill 与 Function Calling / Tool 的区别

Function Calling（工具调用）指的是让模型输出结构化参数，然后由程序去执行某个函数，再把结果返回给模型。Skill 不等于一个函数，它可以是“调用多个函数的流程”，也可以是“一份指导模型写代码的手册”，还可以是“一组参考文档”。

更准确地说，Skill 位于 Tool 之上。Tool 解决的是“执行动作”的问题，Skill 解决的是“知道什么时候执行什么动作、怎么执行、执行完怎么处理”的问题。

2.3 Skill 与 MCP 的区别

MCP（Model Context Protocol）是一种标准化协议，用来让模型与外部数据源、工具进行通信。你可以把 MCP 理解成“USB 接口标准”，它解决的是设备之间怎么连接的问题。

Skill 更接近“即插即用的软件包”。Skill 可以调用 MCP 工具，也可以不依赖 MCP 独立运行。两者不是替代关系，而是协作关系。

2.4 Skill 与 Plugin 的区别

Plugin（插件）通常由宿主应用管理系统，用户需要显式安装、启用和配置。Skill 则更强调“模型自主发现”。当模型读到一个技能描述，觉得当前任务合适时，就会自动使用它，不需要用户手动开启。

在 Claude 的实现中，模型会通过扫描技能目录，结合当前对话内容自主判断使用哪个 Skill。这也是 Skill 区别于传统插件的最大特点。

3. Skill 的技术构成与工作原理

3.1 一份 Skill 包含哪些文件

目前社区和 Anthropic 官方推荐的 Skill 结构基本一致。一个标准 Skill 目录如下：

skills/ my-skill-name/ SKILL.md scripts/ run.py assets/ reference.md

各部分的职责如下：

文件/目录	作用
`SKILL.md`	技能主文档，包含 Frontmatter 和正文，是模型的主要指引
`scripts/`	存放可执行脚本，模型可以调用运行
`assets/`	存放参考文档、模板、示例数据等辅助资源
其他文件	根据技能需要自由扩展，例如`requirements.txt`、配置模板等

3.2 SKILL.md 的文件格式

SKILL.md是整个技能的“灵魂”。官方推荐的格式是 Markdown 加 YAML Frontmatter。一个最简结构如下：

--- name: my-skill description: 当用户需要做 XX 时使用此技能。例如输入 XXX 数据，技能会输出 YYY 结果。 --- # My Skill ## 何时使用 解释这个技能适合处理什么类型的请求。 ## 使用步骤 1. 第一步做什么 2. 第二步做什么 3. 第三步做什么 ## 关键注意事项 - 注意事项 A - 注意事项 B

其中：

name：技能名称，建议全小写、用短横线连接；
description：技能描述，非常重要，因为模型主要靠这段描述来判断“何时使用该技能”。描述写得越具体，模型调用得越准确。

3.3 Skill 的工作原理：模型如何发现技能

当 Agent 被配置了技能目录后，运行逻辑大致如下：

用户提出请求 ↓ Agent 扫描技能目录中的 SKILL.md 描述 ↓ 模型判断哪个技能与当前任务匹配 ↓ 模型读取匹配技能的完整内容 ↓ 模型按照 SKILL.md 指引，编写代码或调用脚本完成任务 ↓ Agent 输出最终结果

这个流程的关键在于“模型自主决策”。由于模型具备意图识别能力，当技能描述足够清晰时，它可以自动匹配，不需要用户在对话中显式打出“请使用某某技能”。

3.4 为什么叫“技能”而不是“提示词”

一个常见的认知误区是：“SKILL.md 不就是一个 Markdown 文件吗，和 Write a Prompt 有什么区别？”

区别在于技能是被模型当作“可执行能力”读取的。模型阅读完技能文档之后，不只是“记住了”，而是会主动执行文档中给出的步骤、脚本和操作流程。技能文档里可以包含可运行脚本，模型可以按文档指导调用这些脚本；技能文档也可以包含“如果结果不符合预期，就尝试修正参数”这样的循环逻辑。这些能力远不是一段 Prompt 能覆盖的。

4. 创建一个最小可用的 Skill

理论讲得再多，不如动手创建一份。下面我们从一个最简单的例子开始，直观感受 Skill 的组成。

4.1 选择一个最小场景

我们的目标是创建一个“感叹号删除助手”技能：用户输入一段文本，技能负责去掉文本中的所有感叹号。这个例子没有实用价值，但结构完整，适合用来理解文件组织方式。

4.2 创建目录和 SKILL.md

首先在项目根目录下创建skills目录：

mkdir -p skills/remove-exclamation-demo cd skills/remove-exclamation-demo

然后创建SKILL.md文件：

--- name: remove-exclamation-demo description: 当用户需要从文本中删除所有感叹号（!）时使用此技能。适合处理用户输入的任意中文或英文文本。 --- # Remove Exclamation Demo ## 何时使用 当用户请求删除文本中的感叹号时使用。 ## 处理步骤 1. 读取用户提供的输入文本。 2. 用 Python 字符串替换方法，将 `!` 替换为空字符串。 3. 返回处理后的文本，并保留其他标点和格式。 ## 示例 输入：你好！欢迎来到 CSDN！ 输出：你好 欢迎来到 CSDN

4.3 完整目录结构

创建完成后，目录结构如下：

skills/ remove-exclamation-demo/ SKILL.md

现在这个“技能”还比较简单，甚至在部分 Agent 实现里，模型只需要阅读文档就能完成处理，不需要额外脚本。

4.4 测试与验证

如果你使用的是 Claude 的 Agent SDK，可以把技能目录挂载到 Agent 上，然后与 Agent 对话，输入“帮我把这句话里的感叹号去掉：今天的天气真好！”。如果一切正常，模型会读取remove-exclamation-demo技能，并按其中的步骤完成处理。

这一步做通之后，你已经掌握了 Skill 的最小闭环。接下来的实战案例，我们会加入 Python 脚本，做一个能真正执行的技能。

5. 实战：开发一个日志分析 Skill

在这个实战案例中，我们创建一个“日志分析技能”。用户给出一段后端日志文本，技能会提取关键信息（时间、日志级别、错误数量、异常堆栈摘要），并输出结构化分析结果。

5.1 需求分析

我们想要的最终效果是：模型收到一段日志后，自动调用技能脚本，执行日志解析，最后返回一份清晰的分析报告。技能中需要包含：

一个 Python 脚本，负责解析日志内容；
一份参考文档，说明日志格式和各字段含义；
一个 SKILL.md，告诉模型何时使用、如何使用。

5.2 创建技能目录

mkdir -p skills/log-analyzer/scripts

5.3 编写日志解析脚本

创建skills/log-analyzer/scripts/parse_log.py：

#!/usr/bin/env python3 """ 日志分析脚本：统计正常日志与错误日志的关键信息。 用法： python parse_log.py <log_file_path> """ import re import sys from collections import Counter from pathlib import Path def parse_log(log_text: str) -> dict: """解析日志文本，返回结构化统计信息。""" lines = log_text.strip().splitlines() total_lines = len(lines) # 匹配形如 2025-01-01 10:00:00 的时间戳 timestamp_pattern = re.compile(r"\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}") # 匹配日志级别 level_pattern = re.compile(r"\b(INFO|DEBUG|WARN|ERROR|FATAL)\b") levels = [] error_lines = [] for idx, line in enumerate(lines, start=1): level_match = level_pattern.search(line) if level_match: levels.append(level_match.group(1)) if level_match.group(1) in ("ERROR", "FATAL"): error_lines.append({"line_no": idx, "content": line.strip()}) # 提取时间范围 timestamps = timestamp_pattern.findall(log_text) time_range = {} if timestamps: time_range = { "start": timestamps[0], "end": timestamps[-1], } # 按分钟统计请求量 minute_counter = Counter() for ts in timestamps: minute = ts[:16] # 截取到分钟：YYYY-MM-DD HH:MM minute_counter[minute] += 1 return { "total_lines": total_lines, "level_distribution": dict(Counter(levels)), "error_count": len(error_lines), "error_samples": error_lines[:10], "time_range": time_range, "request_per_minute": minute_counter.most_common(10), "has_stack_trace": "Traceback" in log_text, } def main(): if len(sys.argv) != 2: print("请提供日志文件路径，例如：python parse_log.py app.log") sys.exit(1) log_path = Path(sys.argv[1]) if not log_path.exists(): print(f"文件不存在：{log_path}") sys.exit(1) log_text = log_path.read_text(encoding="utf-8", errors="ignore") result = parse_log(log_text) print(f"总行数: {result['total_lines']}") print(f"日志级别分布: {result['level_distribution']}") print(f"错误数量: {result['error_count']}") if result["error_samples"]: print("\n错误示例：") for sample in result["error_samples"]: print(f" 第 {sample['line_no']} 行: {sample['content']}") print(f"是否包含异常堆栈: {result['has_stack_trace']}") print(f"时间范围: {result['time_range']}") print("\n每分钟请求数 Top10:") for minute, count in result["request_per_minute"]: print(f" {minute}: {count} 条") if __name__ == "__main__": main()

这段脚本的核心逻辑并不复杂：

使用正则从日志中提取时间戳和日志级别；
统计 ERROR、FATAL 级别的行数，并截取示例；
按分钟统计日志量，方便后续做流量分析；
检测是否有完整异常堆栈。

5.4 编写参考文档

创建skills/log-analyzer/assets/log-format.md：

# 日志格式说明 系统生成的日志格式如下： 2025-01-01 12:00:01 INFO User login success, user_id=12345 2025-01-01 12:00:02 ERROR Database connection failed, retry=1 Traceback (most recent call last): File "/app/db.py", line 42, in connect raise ConnectionError("timeout") 字段含义： - 时间：YYYY-MM-DD HH:MM:SS - 级别：INFO / DEBUG / WARN / ERROR / FATAL - 信息：业务日志内容，可能包含异常堆栈

这份文档的作用是让模型在生成分析报告时，能准确理解日志字段含义。

5.5 编写 SKILL.md

创建skills/log-analyzer/SKILL.md：

--- name: log-analyzer description: 当用户提供后端服务日志或请求分析日志时使用此技能。技能会提取日志中的时间范围、日志级别分布、错误数量、异常堆栈等信息，并输出分析结论。 --- # Log Analyzer ## 何时使用 用户提供日志文件内容、粘贴日志文本，或者要求分析系统日志时使用。 ## 分析步骤 1. 请用户提供日志文件路径，或直接从对话内容中提取日志文本。 2. 将日志保存为文本文件。 3. 运行脚本： ```bash python scripts/parse_log.py <log_file_path>

读取脚本输出结果。
如果脚本执行报错，检查 Python 环境与脚本依赖。
根据输出撰写分析报告，报告必须包含：
- 日志时间范围
- 日志级别分布
- ERROR 数量与代表性错误信息
- 是否出现异常堆栈
- 请求量趋势简述

注意事项

日志可能包含敏感信息，分析结果中不要展示完整用户手机号、密码等字段。
如果日志量很大，只统计关键指标，不要逐行展示。
如果用户只提供部分日志，请说明分析结果的局限性。

### 5.6 完成后的目录结构 ```text skills/ log-analyzer/ SKILL.md scripts/ parse_log.py assets/ log-format.md

5.7 测试日志样例

为了方便测试，我们随便准备一份样例日志sample.log：

2025-01-01 09:00:01 INFO User login success, user_id=1001 2025-01-01 09:00:03 INFO User login success, user_id=1002 2025-01-01 09:00:05 ERROR Database connection failed, retry=1 Traceback (most recent call last): File "/app/db.py", line 42, in connect raise ConnectionError("timeout") 2025-01-01 09:00:06 WARN Retry after 2 seconds 2025-01-01 09:00:10 INFO Request /api/orders completed in 120ms 2025-01-01 09:00:15 ERROR Invalid token from user_id=1003

运行脚本：

python skills/log-analyzer/scripts/parse_log.py sample.log

预期输出：

总行数: 7 日志级别分布: {'INFO': 3, 'ERROR': 2, 'WARN': 1} 错误数量: 2 ... 是否包含异常堆栈: True 时间范围: {'start': '2025-01-01 09:00:01', 'end': '2025-01-01 09:00:15'}

当脚本出现在技能目录里之后，模型在对话中并不会自动执行它，它会先生成命令行调用指令，由 Agent 运行环境执行，再把输出结果交还给模型整理分析。所以这个技能的用户体验是：你扔一段日志给 Agent，Agent 会完成“调用脚本→读取输出→撰写报告”的完整动作。

6. 从“技能写好了”到“生产可用”

好，走到这里，你已经能够创建一份结构完整的 Skill。但如果你真的要在团队或生产环境里用起来，后面这些工程化的问题才是真正的深水区。

6.1 把脚本转成独立 CLI 工具还是直接内嵌

在上面的日志分析案例中，脚本是通过文件路径被模型调用的。这种方式的优点是直观，坏处是如果任务复杂，脚本参数一多，模型容易调用出错。更稳的做法是将脚本改造成标准 CLI 工具，并通过--input、--output这类参数控制输入输出。

实际开发中，我更推荐把技能的脚本统一封装成：

python run.py --input <输入路径> --output <输出路径> --config <配置路径>

模型只需要按照文档里的示例命令执行即可，不需要理解脚本内部的参数细节。

6.2 技能内的提示词与代码要不要分离

如果你的技能脚本需要输出某些固定格式的结果，而这些格式经常变化，建议把格式模板放在assets/目录里，让脚本负责解析数据、生成 JSON，再让模型根据模板进行格式化输出。思路是：脚本只做机械化、确定性的操作，模型负责语义化、差异化的表达。两边各干各擅长的事，整体才稳定。

在实践中，很多团队犯的错误就是让脚本承担太多“智能”职责，写一大堆 if-else 去判断业务语义；又或者反过来，让模型去处理大量精确计算。划分边界时需要记住一句话：确定性操作交给代码，不确定性判断交给模型。

6.3 技能目录版本管理与分享

Skill 本质上是文件，天然适合用 Git 管理。建议每个技能独立目录，在仓库根目录维护一份索引文档，说明每个技能的用途和负责人。版本变更时通过 Git 记录，发布时打上版本标签。这样整个技能的演进历史是可追溯的，对团队协作非常有利。

7. 常见问题与排查思路

7.1 技能没被模型调用，怎么办

这是出现频率最高的问题。现象是：你已经写好了 SKILL.md，目录结构也正确，但模型在对话中始终不使用这个技能。

可能原因：

description写得太宽泛或太模糊，模型判断不了“什么时候该用”；
技能目录没有被 Agent 正确挂载；
模型本身能力或上下文窗口限制，读取不到技能目录。

排查步骤：

打开 SKILL.md，检查description是否包含触发场景关键词和示例；
在 Agent 配置里确认技能目录路径绝对正确；
手动在对话中明确说“请使用 XX 技能处理”，测试是否能被触发；
如果手动触发也不生效，检查模型版本或 Agent SDK 版本，确认是否支持 Skills。

更合理的写法是把 description 写成这样：

description: 当用户需要分析日志、排查系统报错、统计错误率、查看异常堆栈时使用。日志可能来自 Nginx、后端服务、Python 应用或 Java 应用。

7.2 SKILL.md 文件命名或格式问题

目前社区普遍约定技能入口文件名为SKILL.md，名称全大写。目录名建议全小写、使用短横线连接。如果你的 Agent 框架对文件命名有严格约定，请以官方文档为准。

Frontmatter 里缺少name或description字段时，许多 Agent 框架可能直接跳过该技能。写完后可以用 Markdown 预览工具检查 Frontmatter 是否被正确解析。

7.3 脚本执行报错

技能内的脚本执行失败，通常原因有：

问题现象	常见原因	解决思路
提示`python: command not found`	运行环境没有安装 Python	在文档中写清楚依赖要求，或使用完整解释器路径
缺少第三方库	没有安装依赖	在技能目录中提供`requirements.txt`
路径失效	模型使用相对路径执行脚本	在 SKILL.md 中说明脚本的绝对路径引用方式
权限不足	脚本没有执行权限	执行`chmod +x`或统一用`python`调用
编码错误	日志文件编码不是 UTF-8	脚本中使用`encoding='utf-8', errors='ignore'`

7.4 上下文被技能文档撑爆

技能文档写太长，模型可能无法一次性读完，或者占用了太多上下文窗口导致后续对话效果下降。

解决思路：

每个技能只聚焦一个职责，不要做得大而全；
SKILL.md 的正文保持精简，详细资料放到assets/目录，模型按需读取；
对现代大模型来说，几百行 Markdown 通常还能接受，但如果技能内容超过几十 KB，就需要认真做精简了。

8. 最佳实践与工程建议

写 SKILL.md 这门“手艺”，和写代码一样有规律可循。以下几条建议来自大量实际项目的总结。

8.1 命名与目录规范

技能目录名使用小写字母和短横线，例如log-analyzer、excel-report-generator。SKILL.md 内部的name字段建议与目录名保持一致。避免使用中文或特殊字符作为技能名，因为不少 Agent 运行环境在读取目录时会遇到兼容性问题。

8.2 描述要包含触发词和反例

description是模型判断技能匹配度的唯一窗口。一个好的描述应该包含：

触发场景；
输入形式；
输出形式；
可能用到的同义词。

同时可以补一句“不适用场景”，防止模型误用。示例：

description: 当用户要求分析 Excel 报表、合并多个 Sheet、生成图表时使用。输入可以是 xlsx 文件路径或上传的文件。不适用于处理 CSV 纯文本格式的数据，这种情况请使用 csv-toolkit 技能。

8.3 把技能拆细，而不是做大

我见过很多新手喜欢把一个技能写到无所不能：既能分析日志、又能生成报表、还能监控报警。最后模型反而不知道该在什么时候调用。

更推荐的做法是“单一职责”：一个技能只解决一类问题。如果一个日志分析技能既要做统计又要做告警，那就拆成log-analyzer和log-alerter两个技能。这样无论是调试还是维护，都能轻松很多。

8.4 脚本必须做好错误处理与回归测试

技能内脚本要有基本的异常捕获和退出码约定。例如解析失败时，输出 JSON 格式错误信息，并设置非零退出码。脚本的输入输出尽可能标准化，最好统一用 JSON，这样模型和脚本之间就不会因为格式问题反复沟通。

在发布技能之前，建议准备一组测试用例，覆盖正常场景和异常场景。测试的时候不要只看脚本本身跑不跑得通，更要在完整 Agent 环境里跑一遍对话，确认模型能够正确触发技能、执行脚本并生成最终报告。

8.5 安全与权限控制

技能脚本可能执行任意的 shell 命令、读写文件、访问网络。在生产环境运行时，必须考虑安全边界：

技能运行环境使用容器或沙箱隔离；
脚本只允许访问指定目录，不授予全局文件系统权限；
如果技能涉及网络请求，必须进行外发域名白名单控制；
日志和中间产物及时清理，避免敏感信息残留。

轻量级方案建议在技能目录里增加一份SECURITY.md，说明该技能会访问哪些资源，方便他人审查。

8.6 记录技能调用日志

技能被调用之后，最好在 Agent 层保留运行日志：哪个技能被调用、为什么被调用、执行了什么脚本、耗时多少、成功与否。这些日志对后续优化技能描述和调整脚本非常关键。

咱们换个思路想：如果不知道模型到底有没有按照预期调用技能，那写再多的 SKILL.md 都是盲人摸象。有日志之后，你就可以快速发现描述写得不准、模型选错了技能、脚本执行报错等问题，迭代速度会快很多。

9. 总结与下一步学习路线

这篇文章从概念、边界、原理到实战，完整介绍了 AI Agent 中的 Skill 到底是什么，以及怎么创建自己的第一个技能。接下来要真正掌握这门技术，建议按下面的路线继续推进：

动手复现：按照文章第 5 节的日志分析案例，自己在本地创建一份完整技能，并用一段真实日志测试；
理解 Agent 框架：学习你正在使用的 Agent SDK 对技能目录的加载机制，搞清楚 SKILL.md 在什么时机被读取、如何被缓存；
尝试复杂技能：做一个需要调用外部 API 的技能，例如天气查询、数据库查询、GitHub 仓库操作，体会带工具调用的技能设计；
阅读优秀技能源码：去 GitHub 上找一些开源 Agent Skills 仓库，看别人怎么组织文件、怎么写描述、怎么做错误处理；
掌握 Skill 与 MCP 的组合用法：在技能内部通过 MCP 工具调用外部数据源，把“技能”和“连接器”的能力结合起来。

Skill 这个设计思想，本质上是在给模型“按需发手册 + 工具箱”。它不是某个模型的专属功能，而是 Agent 工程化的通用思路。即使不同平台的叫法不一样，甚至文件格式各不相同，只要理解了“描述文件做意图匹配、参考文档做知识补充、脚本做确定执行”这套逻辑，你就能快速迁移到任何框架里去。