Skill与Agent相争谁输谁赢？

Skill 是什么

"技能"（Skill）这个概念，最早是由 Claude Code 提出的。

当我们经常有一些重复的工作需要让大模型去做时，每次都输入重复的提示词就成了一件麻烦事。

所以Claude Code团队里有些大聪明就想出了一个主意：给这些提示词绑定一个简短的快捷指令，每次都只需要输入快捷指令就自动将绑定的提示词提交给大模型，这样一来就省事多了，这个方式就叫Skill。

这个聪明的做法很快得到了大家的欢迎，并且大家发现：

还可以给Skill加上一些描述，告诉大模型"有需要的话你可以主动使用哦，不要客气"，这样连手工输指令都省了。

由于这些提示词是反复使用的，可以得到多次结果反馈，又有利于不断修订进化，比手工提示词好多了哇。

有些Skills逐步打磨迭代都到好几万字符了，这就不仅仅是替代手工输入这么简单了，因为几万字符手工输入早就不现实了。

这时Skill已经算是一种全新的形态了，它的用途也越来越广。

也因为此，skill这个概念在开始流行起来，各种各样的技能仓库、技能市场如雨后春笋般涌现。

skill的内容一般都会写些什么呢？

大部分skill的内容都是关于如何干一件事的描述，相当于一套工作流程——告诉大模型"做一件事应该怎么做，遵守哪些规则，按哪几个步骤，碰到异常应该如何处理等等"，工作流程往往是可重复使用的，所以很适合用技能来表示。

Skill团队

但人心都是贪婪的，光有单独的Skill还不够，很快有人用Skill集合搭配来使用以完成更复杂的工作。

比如有人在跨境领域调教了选品、抓取商品信息、分析数据、生成建议等多个skill集合，让它们配合起来去完成一整个业务链路的任务。

还有很多人设计的研发工作流程，也是将需求分析、方案设计、开发、测试、review、总结报告等一系列环节用技能来执行，将它们组合起来完成整个研发链路的工作。

在现实中，这些环节都是由不同岗位的人来完成的，所以有些人还会给这些技能加上一个角色身份背景，比如需求分析技能就会定义"你是一个专业产品经理"之类来蒙骗大模型以这个角色身份来执行任务。

这样看，这些技能集合实际上就是在模拟一个团队了。

但是，对团队的模拟其实很多平台都有做，他们并不是用技能集合，而是叫Agent Team。

当然，不同平台可能叫法不一样——专家团、Multi-Agent，本质都一样：每个环节配一个角色，各干各的，最后拼成完整任务。

一个是从技能出发组合，一个是角色出发组合。出发点不同，但本质相同：把业务流程拆成环节，每个环节配专用提示词。

每个Skill定义的是"做这件事的步骤，定义的是工作流"。Agent Team中的每个Agent定义的是"这个角色该怎么做，实际上也是工作流"。本质上，Agent能做的，Skill也能做；但Agent能做到的，Skill却未必能。

Skills 的工程困境

是不是说，Skill以后完全可以用Agent来替代呢？

有人会说，它们还是不一样的，一个Agent可以使用多个技能，比如在一个会话里可以前后调用不同的技能，Agent类比为人，一个人有多种技能不是很合理吗？

说到这个，就不得不谈谈大模型的上下文工程了。

我们在一个会话里调用了一个技能，过一会又调用另一个，会发生什么呢？

这样下去整个会话不但变得很长，前后的内容也会形成很大的差异，导致大模型出现幻觉、注意力漂移等等问题。

而这也正是上下文工程理念里要尽力避免的，用一句大俗话来说就是：一个会话只做一件事。

所以，在一个会话中调用多个技能并不是好的做法。

流行的做法是每次都创建一个subagent，让subagent去调用这个技能来干活，这样就不会污染主会话，而subagent的上下文也能得到隔离，专心执行技能。

所以，你看，兜兜转转最后还是用一个单独的Agent来执行。

关键在于每次都创建新的Agent实例。Skill的问题是在一个会话里反复调用多个技能，会话越来越长，前面聊的A技能内容还在影响后面的B技能。Agent的解法是：需要做需求分析就创建一个"需求分析师Agent"，会话结束就销毁；需要写代码就创建新的"程序员Agent"，上下文干干净净。每个会话只装一件事，自然就不会膨胀。

既然这样，不如定义好一个Agent，将技能的内容赋予它，让技能成为它的内在能力，有需要时直接创建这个Agent的会话不就行了吗？何须在创建后还要叮嘱它一句，请使用xxx技能？这不是多此一举吗？

Agent与Skill相比还不止这一个优点。

Agent的概念更完整，你可以给它定义身份、背景知识等，概念天然清晰，技能虽然也能这样来编写，但从概念上总是有点别扭。

并且，Agent是可以有记忆的，它能记住踩过的坑，吃过的苦头，技能却做不到。

Agent有工具集，有权限控制，这些都可以根据技能内容进行调整以达到最佳效果，而纯技能根本做不到这一点。

一句话：技能可以做到Agent也能，而Agent能做到的技能却未必能。

在Agent系统里面，究竟Agent是主角还是技能是主角，答案不言而喻。

Skills 的历史偶然性

Agent这个概念比Skill出现得还要早，为什么还会有Skill这种概念呢？

这又不得不说Claude Code开的坏头。

在Claude Code的设计里没有给创建Agent提供自由的空间，只能使用内置的几个Agent。所以当大家习惯后就不会生出"我要为当前工作流程创建一个专用Agent"的想法，只能退而求其次："创建一个提示词的快捷指令好了"。

有人会说：Skill也有价值啊，Skill更轻量、更简单，不需要创建Agent那么麻烦。

这话没错。但问题是——为什么"不需要创建Agent"成了优点？因为Claude Code没有给你这个选项啊。

是门槛的存在，催生了"绕过门槛"的解法。 如果一开始就能自由创建Agent，没有人会退而求其次去发明Skill快捷指令。

就像如果Windows自带包管理器，没人会在意winget；如果npm先出现，没人需要yarn.lock。工具的缺位制造了中间解法的繁荣。

当有人说将员工蒸馏成技能的时候，就没人想一想：Agent才是类比为人的概念，为什么不是蒸馏成Agent呢？

当然，这不是说Skill马上要消失。迁移需要成本，生态需要时间。但至少新项目应该直接用Agent，而不是继续套Skill的旧模式。

更重要的是，开源社区应该提供更方便的Agent创建工具——让创建Agent的门槛降到跟写一个Skill提示词一样低。到那时，Skill就完成了它的历史使命，可以功成身退了。

是时候让Skill退出历史舞台，让Agent走向前台了。