最近一段时间，如果你关注 Agent 相关的产品和讨论，大概率会注意到一个变化：多款主流工具/平台都相继发布了对 Skills 的支持。
比如：Cursor 的 beta 版里已经开始支持 Skills，Coze 这两天也刚发布了对 Skills 的支持， 甚至在 Dify 最近提交的代码里，也能看到不少和 Skills 相关的文档。
不少 Agent 相关的文章、分享，都绕不开这个词。

一开始我也有点疑惑：

Skills 又是一个新概念吗？
之前讨论得挺多的 MCP，难道不够用了？

但在真正把这些东西放到实际场景里用了一段时间之后，慢慢能理解：

Skills 的出现，并不是为了替代 MCP，而是为了解决 MCP 解决不了的那一部分问题。

更准确地说，Skills 并不是一个“新发明”，而是 Agent 开始走向工程化之后，被迫显性化的一层能力。

Skills 为什么会在这个时间点被反复提起？

一个很现实的背景是：
Agent 开始真正“干活”了。

不管是 Cursor 这种偏开发者的工具，还是 Coze 这类偏应用的平台，Agent 已经不只是陪你聊天，而是开始参与：

• • 写代码、改代码
• • 执行固定流程
• • 调用外部系统
• • 处理相对复杂的任务

但问题也随之而来。同一个需求：

• • 有时候能跑通
• • 有时候步骤顺序乱掉
• • 换个模型，效果差一截
• • 用的人一多，问题更多

本质原因其实很简单：
Agent 缺的不是工具，而是“稳定的做事方式”。

下面这张图，基本能概括现在很多 Agent 的真实状态：

用户需求Prompt / 自由推理一堆 Tools结果不稳定
当任务一复杂、步骤一多，所有决策都交给模型即兴推理， 不稳定几乎是必然结果。

有了 MCP，为什么还需要 Skills？

很多人会下意识把 Skills 和 MCP 放在一起比较，但这两个东西，其实不在一个层级。

MCP 解决的是「怎么用工具」

MCP 做的事情很明确：

• • 把各种能力用统一方式暴露出来
• • 规定调用协议和参数 Schema
• • 把真实系统和 Agent 隔离开

它解决的是：

Agent 如何安全、规范地调用外部能力

比如：

• • 查数据库
• • 读文件
• • 调接口

从结构上看，MCP 更像是 Agent 和真实系统之间的一层“标准接口”：

AgentMCP Protocol
DatabaseExternal APIFile System

无论底层实现多复杂，对 Agent 来说， 它看到的始终是一致的“能力接口”。

Skills 解决的是 MCP 没覆盖的那一层

但现实里的问题是：

Agent 知道“能查数据库”，
并不代表它知道什么时候查、查什么、查完下一步做什么。

如果你只给 Agent 一堆 MCP Tool，事情就会变成：

• • 所有流程靠模型自己猜
• • 每一步都在“即兴发挥”
• • Token 成本高
• • 稳定性差、难复现

Skills 的核心价值，其实是：

把“完成一类事情的经验”，从模型的自由推理中抽出来，显式地固定下来。

从分层上看，Skills 和 MCP 的关系更像这样：

Agent / LLMSkills能力语义 & 流程MCP协议 & 执行真实系统- • Skills 决定 该怎么做

• • MCP 决定 怎么安全地做

Skills 到底是怎么用的？

在实际工程中，Skills 并没有那么“高大上”。

它更像是：

“遇到这类问题，一般按这个流程来”

举个很常见的例子：
生成一份业务日报

如果没有 Skills，Agent 只能靠猜：

• • 要不要查数据
• • 查哪些表
• • 数据怎么汇总
• • 输出什么格式

而一个 Skill，会把这件事拆得很清楚：

生成业务日报查询核心指标数据数据汇总与校验生成日报文本
这里需要强调一点：Skills 看起来像流程，但它并不等同于传统 Workflow。

Workflow 解决的是“步骤如何流转”， 而 Skill 解决的是：

• • 在什么业务语境下
• • 需要哪些步骤
• • 哪些步骤是可选的
• • 哪些结果需要校验

它更像是一种面向具体任务场景的“动态”语义封装。 传统 Workflow 往往是写死的（A->B->C），而 Skill 允许模型在限定的框架内，根据上下文动态调整参数甚至微调路径（比如数据不够时自动增加一步“询问用户”）。

Skills 并不是“再造一套工具”

这是一个很容易被误解的点。

Skills 通常并不直接执行底层能力。

它更像是“指挥官”：

• • 串流程
• • 定步骤
• • 控顺序

真正干活的，依然是：

• • 数据库
• • 内部系统
• • 各类 API

这些能力，通过 MCP 暴露即可。

一个更完整的执行视角

把整个运行过程连起来，大概是这样：

系统MCPSkillAgent用户- 系统MCPSkillAgent用户提出需求选择并加载 Skill调用能力执行真实操作返回结果结果回传汇总结果输出结果

注：实际场景中，Skill 可能会根据中间结果，多次、反复调度不同的 MCP 工具，而不仅仅是调一次。

也正因为如此，引入 Skills 之后：
• Agent 行为更稳定

• • 流程更容易复用
• • Token 成本更可控

至于“换模型不容易翻车”，更准确的说法是：

当关键决策点被显式建模后，Agent 行为对模型差异的敏感度会明显下降。

为什么说 Skills 是 Agent 走向工程化的一步？

如果只是个人玩一玩 Agent，Prompt 写得好一点，确实也能跑。

但一旦你开始：

• • 做产品
• • 上线给别人用
• • 关心成本和稳定性

你一定会遇到几个问题：

• • 行为不可预测
• • 成本难以评估
• • 经验无法沉淀

Skills 本质上是在解决一件事：

让 Agent 的“做事方式”可沉淀、可复用、可治理。

而 MCP 负责的，则是另一件事：

这些事能被安全、可靠地真正执行。

最后一点判断

从现在的发展趋势来看：

• • MCP 更像是 Agent 的基础设施
• • Skills 更像是 Agent 的应用层能力

真正拉开差距的，往往不是工具数量，而是：

谁把常见问题的处理方式，沉淀成了 Skills。

Skills 不是倒退回硬编码或规则引擎，
而是在 LLM 的灵活推理 和 传统软件的稳定流程 之间，
找到了一个更适合 Agent 的中间态。

这，正是 Skills 在这个时间点被反复提起的原因。