大模型学习之SKILL
本文是对吴恩达 Skills 教程的个人整理与笔记,结合了官方示例和自己的理解,方便以后给大模型(LLM,大语言模型)设计和编写
SKILL。
第一节:Introduction(介绍)
Agent Skills 可以简单理解为:
“让智能体反复使用的一套模块化指令与脚本集合,是解决某一类实际问题的完整方案。”
和一次性写在 prompt 里的说明不同,一个 Skill(技能)是可以:
- 被多次复用;
- 独立存放在文件系统中;
- 搭配工具(tools)、MCP(Model Context Protocol,模型上下文协议)以及子智能体(subagents,子智能体)一起工作。
从实现角度看,一个成熟的 Skill 通常需要:
- 代码执行能力(如 Bash 命令行、Python 脚本等);
- 文件系统读写权限(filesystem 文件系统);
- 清晰的输入 / 输出格式和操作流程说明。
第二节:Why Use Skills(为什么要用 Skills)
为什么不直接把所有说明都写进一次对话里,而要额外搞一套 Skill?
- 突破上下文限制:
复杂流程、业务规则、长篇模版,如果每次都塞进对话,会严重占用上下文窗口。Skill 可以单独存放,需要时再“渐进式加载”。 - 保证结果一致性:
把一套成熟的流程写进SKILL.md和脚本里,每次调用 Skill 都走同样的标准化流程,输出质量更稳定。 - 减少重复沟通:
复盘报表、法务审核、数据分析这类“重复套路”的工作,通过 Skill 固化下来,Agent 只需简单调用即可。 - 便于协作与维护:
Skill 以文件夹形式组织,适合在团队中共享与版本管理,改规则只需改文档或脚本,而不是改一堆提示词。
一句话:Skill 是把“经验 + 流程 + 代码”封装成一个可反复调用的能力包。
第三节:Skills 的结构与文件组织
Skill 采用一种轻量、开放的格式来扩展 AI Agent(智能体)的能力。一个典型的 Skill 目录大致如下:
1 | skills/ |
其中:
SKILL.md:Skill 的“说明书”,描述用途、输入输出、步骤、注意事项。scripts/:真正执行任务的脚本(Python、Bash 等)。references/:参考规则、模版、示例文件等辅助资料。
SKILL.md 通常包含:
- YAML frontmatter 元数据(如
name、description、版本等); - 详细的任务描述;
- 输入 / 输出格式定义;
- 关键步骤(workflow);
- 评估指标或质量标准。
举个极简的 frontmatter 样例(伪代码):
1 | name: analyzing-marketing-campaign |
第四节:Skills vs Tools vs MCP vs Subagents(概念对比)
这一节主要搞清楚四个概念的边界:
Tools(工具):
更像“锤子、螺丝刀和钉子”,提供底层能力,比如:- 访问文件系统;
- 运行 Bash / Python;
- 读写某个数据库;
- 调用某个外部 API。
Skills(技能):
相当于“如何用这些工具建一个书架”的整套步骤。它:- 把专业知识和操作流程组合起来;
- 可以引用多个 tools、脚本和参考文件;
- 强调“可预测、可复用的工作流”。
MCP(Model Context Protocol,模型上下文协议):
更偏“连接器”,负责把各种外部系统、底层资源(如内部服务、知识库、数据库)统一接入到 Agent 的工具体系中。Subagents(子智能体):
为执行某个单一、明确定义的任务而专门构建的 AI Agent,具有独立上下文,可并行运行,通常由上层 Orchestrator(编排器)协调多个 subagent 协同完成复杂请求。
一个简单的总结表:
| 类型 | 类比 | 主要作用 |
|---|---|---|
| tools | 锤子、螺丝刀、钉子 | 提供访问文件系统等底层能力 |
| skills | “如何建书架”的完整教程 | 封装专业知识和流程,形成可复用工作流 |
| MCP | 各种工具的万能转接头 | 连接外部数据源与服务 |
| subagent | 专业小团队成员 | 独立承担子任务,可并行协作 |
另外两个关键特性:
- 工具定义(名称、描述、参数)往往常驻在上下文中;
- Skills 则是按需加载,只有用到某个 Skill 时才被拉入上下文,可以显著节省 Token。
第五节:Exploring Pre-built Skills(探索预置 Skills)
在实际使用中,我们往往先“逛一圈”已有的 Skills,再决定是否要自己写。
常见的预置 Skill 使用场景包括:
领域专业知识(Domain Expertise,领域专业知识)
- 品牌规范与模版(Brand guidelines and templates)
- 法务审核流程(Legal review processes)
- 数据分析方法论(Data analysis methodologies)
可重复的工作流程(Repeatable Workflow,可重复工作流)
- 每周营销活动复盘(Weekly marketing campaign review)
- 客户电话准备流程(Customer call prep workflow)
- 季度业务复盘(Quarterly business review)
新能力(New Capabilities,新能力拓展)
- 制作演示文稿(Creating presentations)
- 生成 Excel 表或 PDF 报告(Generating Excel sheets or PDF reports)
- 搭建 MCP 服务器(Building MCP servers)
当你遇到一个需求时,可以优先思考:是否已有类似的 Skill 可以复用或改造?
很多时候只需要改一改 references/rules.md 或模版文件,就能快速适配自己的业务场景。
第六节:Creating Custom Skills(如何创建自己的 Skill)
创建自定义 Skill 的常见步骤:
- 明确目标任务
用一句话描述这个 Skill 要解决什么问题(例如:“自动汇总销售 Excel,并输出按地区的业绩排行榜”)。 - 设计输入 / 输出
- 输入:文件类型、字段要求、示例;
- 输出:结构化 JSON、Markdown 报告、Excel 模版等。
- 拆解操作流程
在SKILL.md中写清楚执行步骤,比如“读取 -> 清洗 -> 计算 -> 生成报告 -> 校验错误”。 - 实现脚本与工具调用
在scripts/中用 Python / Bash 等写好脚本,必要时借助 MCP 访问外部数据源。 - 准备参考资料(references)
放入示例输入、输出模版、规则说明等,既给人看,也给 Agent 作为“隐性知识”。 - 测试与迭代
用一两组真实数据跑一遍,看看 Agent 是否按预期调用 Skill、输出是否稳定可用。
第七节:Skill with the Client(Skill 与调用方的协作)
这里的“Client(调用方)”可以是:
- 直接使用 Agent 的终端用户;
- 上层编排逻辑(Orchestrator,编排器);
- 另一个 Agent 或 Subagent。
实践上要注意:
- 接口要清晰:
- 输入参数名和含义尽量稳定,例如统一使用
input_files、config、output_format等; - 在
SKILL.md中写明调用示例。
- 输入参数名和含义尽量稳定,例如统一使用
- 错误要可诊断:
- Skill 发生问题时,应尽量返回结构化的错误信息(如 JSON 错误报告),方便 Agent 再尝试自动修复或提示人类。
- 版本要可控:
- 对于重要 Skill,建议在 frontmatter 中加
version字段,并在变更时记录更新内容。
- 对于重要 Skill,建议在 frontmatter 中加
第八节:Skill with Claude Agents(Skill 与 Claude Agent 协同)
以 Claude Agent(Claude 智能体)为例,Skill 在其中的角色主要体现在:
- 作为能力扩展插件:
Agent 在对话中识别到某类任务(如“请总结一份 Excel 调研表”)时,会判断是否需要调用某个 Skill。 - 作为长记忆与规则载体:
像“如何分类用户反馈”“如何写业务复盘报告”这类长期稳定的规则,不适合每次都硬塞进 prompt,而是放在references/与SKILL.md中,需要时读入。 - 作为可调参数:
通过修改 Skill 里的配置或指导文档,可以在不改 Agent 代码的前提下,调整智能体行为(例如更严格的法务审核、不同的写作语气等)。
第九节:Agent + Subagents + Skills 的综合示例
可以用一个“客户洞察分析系统”来理解三者如何协同:
Agent(智能体) 是整个架构的大脑:
- 接收高层任务(例如:“请基于访谈和问卷,输出一份客户洞察报告”);
- 拆解子任务,安排给不同的 Subagent;
- 统一整合结果并输出给用户。
Interview Analyzer(访谈分析器) 和 Survey Analyzer(问卷分析器) 是两个 Subagent(子智能体):
Interview Analyzer负责处理非结构化的客户访谈记录,使用自然语言理解提取关键观点、情绪和深层需求;Survey Analyzer负责结构化问卷数据的统计分析、模式识别与趋势归纳;- 它们可以并行工作,各自调用 Filesystem 中的 Skills 和 LLM 能力,最后把结构化结果返回给 Agent 汇总。
Filesystem + Skills 层 则是底层“能力基础设施”:
- Filesystem 作为技能容器,组织多个可复用 Skill 模块;
- 某个指导文档(例如 “A guide for how to categorize feedback and how to summarize findings”)作为元指令(Meta‑prompt,元提示),规定了数据分类维度、总结框架和质量标准;
- 通过修改这些文档即可调整系统的行为,实现“知识即配置”,而无需动底层代码。
这一整套设计,使系统能够高效处理不同类型的数据源,并保持模块化、可扩展。
第十节:实践建议与最佳实践(Conclusion)
最后,把前面零散的建议收拢成几条落地实践:
1. 从 Agent 视角思考 Skill 设计
问自己两个问题:- Agent 现在缺什么“武器”?
- 哪些任务未来会被反复执行,值得封装成 Skill?
2. 明确输入输出,示例放进
references/- 输入 / 输出不清晰,Skill 很难稳定复用;
- 示例文件、模版、规则文档都建议集中放到
references/目录。
3. 复杂逻辑拆成脚本 + SKILL.md 主流程
SKILL.md负责解释“做什么、按什么顺序做”;- 具体实现放在
scripts/中,便于单元测试和复用。
4. 重视错误处理与中间结果
- Skill 应尽量输出错误报告与中间结果,方便 Agent 自动重试或人工排查;
- 对 Excel 这类场景,公式计算可单独用脚本处理(如
recalc.py),避免在库中直接计算。
总之:Skill 是连接“业务知识”和“工具能力”的桥梁,把它设计好,就等于给你的大模型 Agent 配了一整套成熟的“业务作战手册”。



