Skill 和 Sub Agent，到底什么时候用哪个？

什么时候用 Skill，什么时候用 Sub Agent。

看完篇文章，你会知道它们的区别，以及遇到真实任务时，到底该把这个任务做成 Skill，还是做成 Sub Agent 。

文章默认有对应的视频，如果对你有，希望一键三连。

首先，我们先从 Agent 怎么完成任务说起。

你可以把 Agent 理解成一个能接收目标、调用工具、读取上下文，并且一步步推进任务的 AI 助手。

但一个 Agent 真正要把事情做稳定，通常不只靠模型本身聪明。

它还需要两类东西。

一类是做事的方法，即某项工作的标准流程。

一类是任务的分工，即某个细分岗位，对应一个人。

Skill 主要解决前者。

Sub Agent 主要解决后者。

具体来说，可以从三个场景判断使用 Skill 还是 Sub Agent。

第一，凡是要反复遵守的规则，优先做成 Skill。

Skill，你可以把它理解成 Agent 的能力包。

它里面可以放说明、流程、参考资料、模板、例子，甚至脚本。

更专业一点说，Skill 是一种可复用的上下文工程。

说白了，就是把 AI 每次做事前应该知道的规则和资料，提前整理好。

它不是让 AI 多一个分身，而是让当前这个 Agent 在需要的时候，自动拿到一套“应该怎么做”的方法。

举个日常一点的例子。

假设你经常让 AI 帮你整理会议纪要。

你希望它每次都按同一个格式输出：先写会议结论，再写待办事项，再写负责人和截止时间，最后补风险提醒。

这个时候不需要新建一个“会议纪要 Sub Agent”。

更适合做成 Skill。

因为你真正需要的不是另一个人，而是一套稳定格式。

再比如，你做内容，每次都希望 AI 按你的账号定位、标题风格、结构要求来写。

这些也适合 Skill。

因为它们是方法，是规范，是模板。

第二，凡是会占用大量上下文的独立任务，优先交给 Sub Agent。

Sub Agent，也就是子代理。

你可以把它理解成主 Agent 临时叫来的一个独立助手。

它有自己的任务说明，有自己的上下文，也可以有自己的工具权限。

它做完之后，不会把整个执行过程的内容返回主会话，只会把结果返回给主 Agent。

这一点特别重要。

因为 AI 不是脑子无限大。

一个会话里塞太多资料、太多中间过程文本，主 Agent 就容易乱，你想想如果我们自己的大脑一下子塞满太多内容，也会分不清主次、重点。

比如你准备一次家庭旅行。

你让 AI 同时看机票、酒店、天气、景点、预算、老人小孩的体力，还要比较三条路线。

如果所有资料都堆在一个对话里，越聊越乱。

更好的方式是，主 Agent 负责统筹。

一个 Sub Agent 专门看交通。

一个 Sub Agent 专门看住宿。

一个 Sub Agent 专门看行程强度。

最后主 Agent 汇总成一份旅行方案。

这就是 Sub Agent 的价值：把一段可以独立完成的工作拆出去。

第三，凡是需要并行或者权限边界的任务，优先考虑 Sub Agent。

并行很好理解。

同一件事，如果可以分几条线同时看，就适合派 Sub Agent。

比如你要做一次选题调研。

一个 Sub Agent 看用户痛点。

一个 Sub Agent 看竞品内容。

一个 Sub Agent 看平台热度。

它们分别给结论，主 Agent 最后做取舍。

这比一个 Agent 从头看到尾更快，也更不容易把线索搅在一起。

权限边界也很重要。

说白了，就是谁只能看，谁能评论，谁能真正动手改。

比如你只想让一个助手检查内容有没有事实风险，不希望它改你的正文。

那这个 Sub Agent 就可以只给读取和评论权限。

它只负责指出问题，不负责动手修改。

这在 AI 工作流里很关键。

因为不同角色本来就不应该拥有同样的权限。

审稿的人不一定能直接改稿。

财务审核的人不一定能直接付款。

客服整理问题的人不一定直接承诺退款。

放到 Agent 里也是一样。

所以 Skill 和 Sub Agent 的区别，可以用一句话记住。

Skill 是把方法沉淀下来。

Sub Agent 是把工作委派出去。

Skill 让结果更稳定。

Sub Agent 让任务更可拆、更独立、更可控。

那两者能不能一起用？

当然可以，而且真实工作流里经常应该一起用。

比如你要让 AI 帮你做一篇内容。

主 Agent 负责统筹。

一个 Sub Agent 去整理资料。

一个 Sub Agent 去检查事实。

一个 Sub Agent 去看标题有没有吸引力。

但是所有这些 Sub Agent，都应该共同遵守同一套账号定位、写作风格和质检标准。

这套共同标准，就应该放在 Skill 里。

也就是说，Sub Agent 负责干活，Skill 负责告诉它按什么标准干活。

更准确一点说，有些 Sub Agent 上岗时，就可以预先带着指定的 Skill。

比如事实检查这个 Sub Agent，可以带着一套事实核查 Skill。

标题评估这个 Sub Agent，可以带着一套标题评分 Skill。

这样它不是空着手去干活，而是带着方法去干活。

这里有两个常见误区。

第一个误区，是把共享标准藏进某个 Sub Agent 里。

比如固定格式、固定风格、固定检查清单。

这些东西真正的问题，不是需要一个人来执行，而是所有相关任务都应该遵守同一套标准。

如果你把它们写进某个 Sub Agent 里，就会变成这个 Sub Agent 自己知道，别的 Agent 不一定知道。

结果是，同样一篇内容，整理资料的 Sub Agent 按一套标准，事实检查的 Sub Agent 按另一套标准，最后主 Agent 还要重新对齐。

更麻烦的是，标准一改，你可能要去改好几个 Sub Agent。

因此它更适合做成 Skill。

第二个误区，是把所有复杂任务都写成 Skill。

比如大量资料整理、多角度评审、并行调研、独立审核。

这些任务如果只靠 Skill，主 Agent 的上下文会越来越重，也很难保持独立视角。

它们更适合交给 Sub Agent。

最后给一个最简单的判断方法。

如果你想沉淀规范、模板、流程、风格、检查清单，用 Skill。

如果这次任务太大、资料太多，或者需要同时执行，用 Sub Agent。