很多人装上 Claude Code 之后，第一反应都是： “好，接下来我该搞 Skill，还是写个 SubAgent？”
文档一看一大堆：SKILL.md、subagents.md、Agent、工具、工作流……
明明只是想让 Claude 帮我干点正事，结果先被概念整懵了。
但冷静想想，你真正想解决的问题，从来不是：
“我该用 Skill 还是 Subagent？”
而是：
“在我的这个场景里，谁来干活、干到什么程度、状态怎么保留，最合适？”
这篇就干一件事：
把 Skill vs Subagent 讲到你能立刻拍板，用哪个、怎么用、为什么用。
一、同样的“做饭技能”，只是谁来下厨不同
先不谈 Claude，先说吃饭。
我们来做一道红烧肉，有两种选择：
Skill 模式：
你打开菜谱，自己按步骤做红烧肉。
菜谱 = SKILL.md，厨师 = 你自己。
Subagent 模式：
你把菜谱交给餐馆，说“按这个做一份红烧肉，做好给我送来”。
菜谱 = subagents.md，厨师 = 餐馆（一个独立的“分身”）。
你会发现，两边写下来的“做红烧肉流程”几乎一样：
唯一的不同是：谁来花时间、谁在执行过程里亲自参与。
对着 Claude 来翻译就是：
1）SKILL.md 方式 = 把技能「刻进自己」
你（主 Agent）学习了一份 SKILL.md
之后在主会话中，你随时可以调用这个技能
所有思考、上下文、文件状态，都留在这一次主对话里
就像你学会红烧肉之后，以后每次做饭都能加一道这菜，而且你会越做越熟练。
2）subagents.md 方式 = 把任务「外包给分身」
就像你下班点个外卖，你只关心“好不好吃”，不关心后厨是几口锅、炒了多久。
二、本质差异：同一份“工作说明书”，不同的执行环境
再抽象一层，其实很简单：
Skill vs Subagent 的区别，不在文档写了什么，而在「执行环境」在哪。
这就是为什么，同样一个“做红烧肉”的流程：
三、Skill vs Subagent：一张表看懂关键区别
很多人迷惑的点在于：“功能看起来都能实现啊，我到底选哪个？”
从“能不能做”这个角度，两者确实都能做。
但从“体验和成本”这个维度，差别就出来了。
可以先看一张粗暴对比表：
简单解释：
Skill：
状态：记录在当前对话和文件系统里，像“长期记忆”
中断：随时可以，不影响 SKILL 的后续执行
恢复：因为在主会话中，有记忆感知，可恢复
与主会话：高度融合，天然一体，连续
Subagent：
四、一个例子
回到 Claude Code 自带的一个功能：Plan 模式。
Plan 模式本质上是一个 Plan Subagent：
当你切到“计划模式”时，Claude 会自动调用这个 Subagent 来做：研究代码库、联网检索、分解任务、生成执行计划。
为什么官方把它做成 Subagent，而不是一个 Skill？
关键在于两个字：「干净」。
如果 Plan 做成 Skill，会发生什么：
所有研究、检索、分析过程，全都塞进主对话上下文
你的主会话会被各种“思维垃圾”和中间版本污染
token 占用飞涨，窗口很快被挤爆，还影响你后面正常写代码、改文案
而做成 Subagent：
所以在这个场景下，Plan 做成 Subagent 明显更优：
对主会话更友好
对 token 更节省
对心智负担更低（你只面对最后那个“计划片段”）
五、两步选好 Skill 还是 Subagent
很多人纠结半天，其实选型逻辑可以压缩成一个简单决策树：
第一步：要不要“记住这个过程”？
第二步：需不需要「并行、隔离、特殊权限」
不要为了“酷炫”和“概念完整”而过度设计。
六、先干起来
最后一个很容易被忽略的点：
Skill 和 Subagent 之间的“形态切换成本”，其实很低。
你在大多数情况下，完全可以这样操作：
先只做 Skill：
先把任务拆清楚、流程梳顺
用 Skill 的方式，先让主 Agent 真正帮你把事儿干起来
真·跑顺了之后再问自己：
这个东西要不要隔离出去？
要不要给它单独权限？
要不要并行、多开多个？
如果答案是“要”——再把这一套 Skill 的逻辑包装成一个 Subagent，是非常容易的迁移。
同一个剧本：
剧本内容没有变，只是舞台和调度方式不同。
真正决定体验好坏的，从来不是“用了几个名词”，而是：你想把 Claude 放在什么位置、让谁来为谁打工。
所以别再卡在“我到底要 Skill 还是 Subagent？”。
更实在的做法是：
先选一个看起来靠谱的形态，
让 Claude 真的帮你把一件事做完，
然后再用数据和体验去反向校正你的设计。
——这才是工程化 Agent 的正确打开方式
粤ICP备14082021号
免费POC，
零成本试错
