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