如何把常用任务封装成 Skills，让 Agent 更稳定地完成复杂工作？
这道题考的是** Skills 的本质理解**。很多人以为 Skill 就是一个函数或插件，实际上 Skill 是一个完整的能力包。Anthropic 在 2025 年 10 月给出了明确定义：Skill 至少包含一个 SKILL.md 文件，用于告诉 Agent 什么时候该调用、遵循什么规则。
这篇文章会从原理、架构、对比、适用场景四个维度，把 Skills 讲透。
1. Skills 是什么？
先把一个错误观念掰过来：Skill 不是函数，不是插件，是一个"能力包"。
更准确地说，Skill 是一个目录。Anthropic 官方定义的最小结构包含三个部分：
- SKILL.md — 指令层，告诉 Agent 什么场景触发这个 Skill、具体怎么执行
- scripts/ — 脚本层，存放可执行代码，把高频动作变成确定性执行
- references/ — 参考资料层，存放团队 SOP、知识文档，从对话里剥离出来
类比一下：把 Skill 想象成厨房里的一个工具包。SKILL.md 是菜谱（什么时候做、做成什么样），scripts/ 是料理机（帮你自动执行），references/ 是食材手册（告诉你用什么原料、注意事项）。
为什么这样做？Anthropic 的核心观点是：代码处理确定性逻辑，Agent 处理需要判断的任务。高频重复的确定性动作，应该交给脚本；需要灵活判断的部分，交给 Agent 看 SKILL.md 做决策。
2. Skills 三层架构详解
刚才说了三层结构，但三层具体怎么配合干活，很多人还是懵的。
指令层（SKILL.md） 是大脑。它不做具体操作，只负责两件事：什么时候触发这个 Skill，以及触发后 Agent 要遵循什么规则。比如"当用户要求生成报告时，调用报告生成 Skill，输出格式遵循公司模板"。
脚本层（scripts/） 是手。把那些高频、重复、有明确步骤的动作写成脚本，Agent 直接调用，不用每次都思考怎么做。比如"自动发送邮件"、"批量重命名文件"，这类动作脚本写得越细，执行越稳定。
参考资料层（references/） 是知识库。团队积累的 SOP、行业知识、最佳实践，扔到这里。Agent 需要时去查，不用塞进上下文。
三层的关系是：指令层指挥，脚本层执行，资料层辅助判断。Agent 读 SKILL.md 知道该干嘛，调 scripts/ 把活干了，查 references/ 补充背景信息。
举个例子。假设你在做一个"客服问题分类" Skill：
- SKILL.md 写明：检测到用户抱怨类语句时触发，分类规则遵循公司 SOP，返回置信度低于 0.7 时转人工
- scripts/ 里有个 classify.py，专门处理文本分类逻辑
- references/ 里放客服 SOP 文档，告诉 Agent 哪些问题属于哪个类别
这样 Agent 不需要每次对话都重新学习规则，调用 Skill 就能稳定执行。
3. Skills 凭什么比 Workflow 强？
有人会说："Workflow 也能编排流程，我为什么要用 Skill？"
区别大了。Workflow 像是预制菜套餐——固定搭配、节点清晰、但调整成本高。Skill 更像是乐高积木——可以自由组合、灵活拼接。
分层按需读取是核心优势。Workflow 不管用不用，所有节点都塞进上下文。Skill 呢？按需读取，需要什么读什么，不往上下文里灌垃圾。
自然语言编排比拖拽节点更灵活。Workflow 改流程要重新拖节点，Skill 改 SKILL.md 的指令就行，改动成本低得多。
遇变化可调整，不是定死就出错。业务流程经常变，Workflow 一旦定死，参数变了就得重来。Skill 改个脚本或指令层就行，底层架构不用动。
文件级复用无平台锁定。Workflow 跟特定平台绑定，Skill 就是一堆文件，复制到哪都能用。
当然，不是说 Workflow 不好。简单线性流程、步骤固定的场景，Workflow 很合适。但面对需要 Agent 判断、流程可能调整的复杂任务，Skill 的优势就出来了。
4. 什么时候用 Skill？什么时候不用？
不是所有任务都适合封装成 Skill。判断标准就一个：这个任务是需要 Agent 判断 + 需要执行动作的混合任务吗？
适合做成 Skill 的场景：
- 高频重复流程 — 每天执行几十上百次，手写太累
- 团队隐性知识 — SOP 散落在不同人脑子里，需要固化
- 确定性执行动作 — 步骤明确，但每次执行太繁琐
- 多格式文档处理 — Word、PDF、Excel 各种格式来回转
- 流程经常调整 — 业务逻辑一变再变，Skill 改起来方便
不适合的场景：
- 金融医疗强合规 — 这类场景需要人工审核，不适合自动化
- 每秒几百次的简单操作 — 简单到不值得封装，直接调函数更快
- 纯判断任务 — 不需要执行动作，只是决策，不需要 Skill
给你一个五问判断法：
- 这个任务执行频率高吗？ → 不是高频就算了
- 每次执行步骤固定吗？ → 固定步骤才好封装
- 需要团队知识指导吗？ → 需要参考资料层才值得做
- 流程会经常调整吗？ → 会调整才体现 Skill 优势
- 涉及多种工具协同吗？ → 多工具协同才是 Skill 强项
三个以上"是"，就值得封装成 Skill。
5. Skills vs Function Calling vs MCP：核心区别
这道题面试官喜欢挖深，问你 Skill 和其他机制的区别。你得说清楚三件事的定位：
Function Calling 解决的是"会不会调"——定义函数签名，Agent 知道怎么调用。相当于工具箱里的工具。
MCP（Model Context Protocol） 解决的是"连不连得上"——标准化工具连接协议，让不同平台的工具能互通。相当于工具箱的连接器。
Skill 解决的是"做不做得稳、能不能复用"——不只是工具，还包括使用说明、维护团队、参考资料。相当于工具箱 + 说明书 + 持续服务。
类比一下：
- Function Calling 是给你一把螺丝刀
- MCP 是告诉你螺丝刀怎么插进工具箱
- Skill 是给你螺丝刀 + 安装手册 + 售后团队 + 常见问题解答
所以三个东西不矛盾，可以叠加用。MCP 连接外部工具，Function Calling 调用具体函数，Skill 封装完整能力包。
面试怎么答
基础版（100-150字）：
Skills 是一个能力包，包含三层结构：SKILL.md 负责指令，告诉 Agent 什么时候触发、遵循什么规则；scripts/ 负责脚本，把高频重复动作变成确定性执行；references/ 负责参考资料，把团队知识和 SOP 剥离出来。相比 Workflow，Skill 的优势是分层按需读取避免上下文膨胀、自然语言编排更灵活、遇变化可调整、文件级复用无平台锁定。适用场景是高频重复、需要 Agent 判断的混合任务。
加分版（200-250字）：
Skills 的本质是能力包，不是函数或插件。Anthropic 的核心观点是"代码处理确定性逻辑，Agent 处理需要判断的任务"。Skill 三层架构中，指令层通过 SKILL.md 控制触发条件和执行规则，脚本层通过 scripts/ 实现确定性动作，参考资料层通过 references/ 存储团队 SOP 和知识文档。
相比 Function Calling（解决会不会调）和 MCP（解决连不连得上），Skill 解决的是"做不做得稳、能不能复用"。相比 Workflow，Skill 通过按需读取避免上下文膨胀、自然语言编排更灵活、遇变化可调整、文件级复用无平台锁定。
落地 Skills 有个五步框架：拆分（识别高频任务）、编排（写 SKILL.md 和脚本）、存储（组织 references/）、分摊（Agent 按需读取）、迭代（持续优化 Skill）。要注意安全边界（敏感操作加确认）、维护成本（别过度封装）、触发设计（避免误触发）。
一句话总结
Skills 的本质是包含指令、脚本、参考资料三层的能力包，核心价值是分层按需读取 + 自然语言编排，用它来解决高频重复、需要 Agent 判断的混合任务。