最近一段时间，如果你关注 Agent 相关的产品和讨论，大概率会注意到一个变化：多款主流工具/平台都相继发布了对 Skills 的支持。
比如：Cursor 的 beta 版里已经开始支持 Skills，Coze 这两天也刚发布了对 Skills 的支持， 甚至在 dify 最近提交的代码里，也能看到不少和 Skills 相关的文档。
不少 Agent 相关的文章、分享，都绕不开这个词。
一开始我也有点疑惑：
Skills 又是一个新概念吗？
之前讨论得挺多的 MCP，难道不够用了？
但在真正把这些东西放到实际场景里用了一段时间之后，慢慢能理解：
Skills 的出现，并不是为了替代 MCP，而是为了解决 MCP 解决不了的那一部分问题。
更准确地说，Skills 并不是一个“新发明”，而是 Agent 开始走向工程化之后，被迫显性化的一层能力。
Skills 为什么会在这个时间点被反复提起？
一个很现实的背景是：
Agent 开始真正“干活”了。
不管是 Cursor 这种偏开发者的工具，还是 Coze 这类偏应用的平台，Agent 已经不只是陪你聊天，而是开始参与：
但问题也随之而来。同一个需求：
本质原因其实很简单：
Agent 缺的不是工具，而是“稳定的做事方式”。
下面这张图，基本能概括现在很多 Agent 的真实状态：
当任务一复杂、步骤一多，所有决策都交给模型即兴推理， 不稳定几乎是必然结果。
有了 MCP，为什么还需要 Skills？
很多人会下意识把 Skills 和 MCP 放在一起比较，但这两个东西，其实不在一个层级。
MCP 解决的是「怎么用工具」
MCP 做的事情很明确：
它解决的是：
Agent 如何安全、规范地调用外部能力
比如：
从结构上看，MCP 更像是 Agent 和真实系统之间的一层“标准接口”：
无论底层实现多复杂，对 Agent 来说， 它看到的始终是一致的“能力接口”。
Skills 解决的是 MCP 没覆盖的那一层
但现实里的问题是：
Agent 知道“能查数据库”，
并不代表它知道什么时候查、查什么、查完下一步做什么。
如果你只给 Agent 一堆 MCP Tool，事情就会变成：
Skills 的核心价值，其实是：
把“完成一类事情的经验”，从模型的自由推理中抽出来，显式地固定下来。
从分层上看，Skills 和 MCP 的关系更像这样：
Skills 到底是怎么用的？
在实际工程中，Skills 并没有那么“高大上”。
它更像是：
“遇到这类问题，一般按这个流程来”
举个很常见的例子：
生成一份业务日报
如果没有 Skills，Agent 只能靠猜：
而一个 Skill，会把这件事拆得很清楚：
这里需要强调一点：Skills 看起来像流程，但它并不等同于传统 Workflow。
Workflow 解决的是“步骤如何流转”， 而 Skill 解决的是：
它更像是一种面向具体任务场景的“动态”语义封装。 传统 Workflow 往往是写死的（A->B->C），而 Skill 允许模型在限定的框架内，根据上下文动态调整参数甚至微调路径（比如数据不够时自动增加一步“询问用户”）。
Skills 并不是“再造一套工具”
这是一个很容易被误解的点。
Skills 通常并不直接执行底层能力。
它更像是“指挥官”：
真正干活的，依然是：
这些能力，通过 MCP 暴露即可。
一个更完整的执行视角
把整个运行过程连起来，大概是这样：
注：实际场景中，Skill 可能会根据中间结果，多次、反复调度不同的 MCP 工具，而不仅仅是调一次。
也正因为如此，引入 Skills 之后：
至于“换模型不容易翻车”，更准确的说法是：
当关键决策点被显式建模后，Agent 行为对模型差异的敏感度会明显下降。
为什么说 Skills 是 Agent 走向工程化的一步？
如果只是个人玩一玩 Agent，Prompt 写得好一点，确实也能跑。
但一旦你开始：
你一定会遇到几个问题：
Skills 本质上是在解决一件事：
让 Agent 的“做事方式”可沉淀、可复用、可治理。
而 MCP 负责的，则是另一件事：
这些事能被安全、可靠地真正执行。
最后一点判断
从现在的发展趋势来看：
- • Skills 更像是 Agent 的应用层能力
真正拉开差距的，往往不是工具数量，而是：
谁把常见问题的处理方式，沉淀成了 Skills。
Skills 不是倒退回硬编码或规则引擎，
而是在LLM 的灵活推理和传统软件的稳定流程之间，
找到了一个更适合 Agent 的中间态。
这，正是 Skills 在这个时间点被反复提起的原因。
