Skill与Agent相争究竟谁会赢？
Skill与Agent相争究竟谁会赢？
来源类型： 微信公众号文章
日期： 2026-06-02
标签： AI, 记忆系统, 编程, 大模型
原文链接： https://mp.weixin.qq.com/s/BSn0U98kYF_Mp8sVJr3-8w
摘要
最近我让Skill和Agent打了一架，将Skill的内容直接装在了Agent的定义里，需要执行任务的时候直接创建一个相应的Agent会话就完事了。这下Skill不干了：什么事都让Agent自己干，那我干什么？ ## Skill 是什么 "技能"（Skill）这个概念，最早是由 Claude Code 提出的。 当我们经常有一些重复的工作需要让大模型去做时，每次都输入重复的提示词就成了一件麻烦事。 所以Claude Code团队里有个大聪明就想出了一个主意：给这些提示词绑定一个简短的快捷指令，每次都只需要输入快捷指令就自动将绑定的提示词提交给大模型，这样一来就省事多了，这个方式就叫Ski...
核心内容
最近我让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；
...(内容截断，完整内容请查看原文)
本页由自动化脚本生成，待人工审核补充