Skill与Agent相争究竟谁会赢？

来源：htmlDecode("机器与秩序")

原文链接：https://mp.weixin.qq.com/s/BSn0U98kYF_Mp8sVJr3-8w

最近我让Skill和Agent打了一架，将Skill的内容直接装在了Agent的定义里，需要执行任务的时候直接创建一个相应的Agent会话就完事了。 这下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定义的是"这个角色该怎么做，实际上也是工作流"。
殊途同归 Skills 组合 从抽象工作流程出发 选品 抓取 分析 Agent Team 从模拟团队协作出发 选品员 数据员 分析师 本质相同：把业务流程拆成环节，每个环节配专用提示词
图：Skills组合 vs Agent Team

Skills 的工程困境

是不是说，Skill以后完全可以用Agent来替代呢？
有人会说，它们还是不一样的，一个Agent可以使用多个技能，比如在一个会话里可以前后调用不同的技能，Agent类比为人，一个人有多种技能不是很合理吗？
说到这个，就不得不谈谈大模型的上下文工程了。
最早确实大家都把Agent当成一个人来设计，可以干这干那，但是慢慢地大家发现，大模型有时会出现幻觉，会有注意力漂移等现象。
经过仔细分析发现，原因在于会话的上下文：
当上下文的内容比较分散，前面是关于事情A的内容，后面又转到事情B的内容时就容易出问题。
所以，现在不再强调把Agent当成一个人了，而是强调一个Agent会话只聚焦在同一件事上，如果有不同的事情要处理想办法新开一个会话，相互不要干扰。
用一句大俗话来说就是：一个会话只做一件事。
这跟Skill有什么关系呢？
想想我们在一个会话里调用了一个技能，过一会又调用另一个，会发生什么呢？
这样下去整个会话不但变得很长，前后的内容也会形成很大的差异，就会出现上面所说的问题，一个会话没有聚焦到同一件事。
所以，在一个会话中调用多个技能并不是好的做法。
流行的做法是每次都创建一个subagent的会话，让subagent去调用这个技能来干活，这样就不会污染主会话，而subagent的上下文也能得到隔离，专心执行技能。
所以，你看，兜兜转转最后还是用到Agent。
既然这样，不如定义好一个Agent，将技能的内容赋予它，让技能成为它的内在能力，有需要时直接创建这个Agent的会话不就行了吗？何须在创建后还要叮嘱它一句，请使用xxx技能？这不是多此一举吗？
比如，需要做需求分析就创建一个"需求分析师Agent"，会话结束就销毁；需要写代码就创建新的"程序员Agent"，上下文干干净净。

Skill 的问题 一个会话调用多个技能 会话越来越长 上下文相互污染 大模型幻觉/漂移 → Agent 的解法 每个任务配独立Agent 上下文隔离 会话结束即销毁 每个会话只装一事 Agent 实例生命周期 需求分析师 按需创建 → 程序员 任务完成 → 测试工程师 销毁 Agent能做到的，Skill却未必能
图：上下文隔离 vs 上下文污染
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概念 早已存在 Claude Code 限制Agent创建 Skill诞生 退而求其次 是门槛的存在，催生了"绕过门槛"的解法 类比：包管理器 npm先出现 → yarn.lock不需要 Windows缺位 → winget火了
图：工具缺位制造中间解法
当有人说将员工蒸馏成技能的时候，就没人想一想：Agent才是类比为人的概念，为什么不是蒸馏成Agent呢？
** 最近在Agent特区（ https://www.agentszone.ai/ ）的群里看到大家讨论Agent应该如何设计、有人说摸到了Skill的天花板，我越来越相信：Skill不应该是未来，Agent才能扛得起重任。 **
当然，这不是说Skill马上要消失，现在创建Agent仍然是有一定成本的事，仍然存在着门槛。
开源社区应该提供更方便的Agent创建工具——让创建Agent的门槛降到跟写一个Skill提示词一样低。到那时，Skill就完成了它的历史使命，可以功成身退了。